IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

OpenStack海外動向

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes 

第24回 Zuulのケーススタディ:OpenStack Foundation編 (野田貴子) 2018年11月

こんにちはー。野田貴子です。今回は海外で公開されているOpenStack関係のコラムを意訳します。英語が苦手な方にとっては、日本語で要約版があると助かるのではないかと考え、日本語訳したものをご紹介いたします。
興味がある方はご参考ください。海外動向を理解する上での参考になれば幸いです。

さて今回はZuulの話です。OSF(OpenStack Foundation)は約6年間Zuulを使用してきました。スーパーユーザーはClark Boylan氏とDoug Hellman氏に、Zuulの利用経緯を伺いました。

###

Zuulはプロジェクトゲーティングと相関プロジェクトにフォーカスし、継続的な統合、配布、デプロイができるシステムを推進しています。スーパーユーザは一連のインタビューで、ユーザーがZuulを選んだ理由とその使い方を尋ねていきます。

OpenStack FoundationはZuulを約6年間使用してきました。スーパーユーザーは今回、OSFのインフラストラクチャエンジニアであるClark Boylan氏と、開発者、編集者、著者、ベテランのOSFコミュニティメンバーであるDoug Hellman氏に、Zuulの使用経緯について話を聞きました。

## Zuulを使用する前はどうでしたか?

Boylan氏:Zuulの前は、私たちはJenkinsのマスターを実行していました。Jenkinsを使ってゲート方式を強化していましたが、ある変更が別の変更を壊すことを避けるために、各変更のゲーティングをシリアライズする必要がありました。このゲーティングは1回の変更につき約1時間かかっていたため、1日に24回の変更のみをマージすることができました。このボトルネックを対処しなければならないと知りつつも、目をつぶっていました。

Hellman氏:以前、私たちは定期的に独立して動作するパッチを設置しましたが、このパッチはほかのリポジトリの変更と組み合わされたときに、何かを破損することがありました。私がOpenStackで働き始めたころ、devstackを実行してローカルのテスト環境をセットアップすることができましたが、これは午前中に実行するものだったため、私の不注意で午後に更新を行うと、誰かがその問題を修正するまで最低でも1時間程度は失敗することになりました。今はもうこの不具合はありません。ひとつにはテストカバレッジが改善したことによるものですが、大部分はZuulの推測的なマージと、複数のリポジトリにまたがる変更が一緒にテストされるマルチリポジトリテスト機能のおかげです。

## Zuulを使い始めたときの話を教えてください。たとえば、Zuulが必要だと明らかになったのはいつで、OpenStackのどんな問題を解決するためでしたか?

Boylan氏:OpenStackはOpenStackへの変更をゲーティングしつつ、1日に24回以上の変更をマージしたいという状況にありました。テストの実行をより速くしたりテストの数を減らしたりすことは可能ではなく、理想的な解決策ですらありませんでした。代わりに、私たち(主にJimですが)はOpenStackの一連のテストを並列化できるシステム(Zuul)の構築に着手しました。ここでのトリックは、それぞれの変更が連続的にテストをパスすることを求めるのではなくて、目指している将来の状態を構築して、すべてのテストがパスしたらその状態をまとめてマージすることです。ある変更がテストに失敗した場合その変更は除外され、失敗した変更抜きでもう一度テストが実行されます。

## どのようにJenkinsからZuulに乗り換えましたか?

Boylan氏:初期のZuulシステムは私たちのジョブを実行するためにJenkinsに依存していました。つまりZuulはJenkinsのコーディネーターであり、2つのシステムは連携して機能していました。2016年のオースティンサミットで、JenkinsをAnsibleベースの実行システムに置き換えて、パフォーマンスと信頼性を向上させることができると気づきました(私たちは毎週Jenkins masterをリスタートしてスレッドリークをクリアするのにうんざりしていました)。このAnsibleベースのシステムが成功したことで、メジャーのZuul v3でもジョブの実行にAnsibleを使うように書き直すことが決断されました。

## Zuulがこの大規模なコミュニティにとって有用であることが明らかになったのはいつですか?

Boylan氏:私たちは、さまざまなところでインターナル開発ツール、あるいは顧客向けのCIプロダクトとしてZuulが選択されるところを目にしました。HPは実際にはZuulを含む製品としてforj.ioを、HP開発者向けの内部CIシステムとしてGozerを使いました。私はこれが非常に早く、1年目か2年目のときに起こったということを伝えたいです。

Hellman氏:Red HatにもZuulと他のコンポーネントを含むSoftware Factoryという製品があります。Zuulが関係する製品が複数提供されていることで、ZuulがOpenStackコミュニティ以外の場所でも使われる準備が整っていることが分かります。

## 『Brady Brides(訳注:TVドラマ)』よりも『ブレイキング・バッド(訳注:TVドラマ)』や『ベター・コール・ソウル(訳注:ブレイキング・バッドのスピンオフシリーズ)』が成功したように、このスピンオフが成功したと気づいたのはいつでしたか?

Boylan氏:私たちは、Zuulを使おうとしていている人々が、ZuulがOpenStackの特化であることや、あるいはGerritのように特別なツールを必要とすることを気にしているのを目にしてきました。私たちはOpenStackの既存のニーズをサポートしつつ、GitHubやほかのNodepoolドライバのような共通ツールのサポートを追加することによって、彼らのニーズに応えてこれらの懸念に対処することが実現できたと考えています。

## 測定基準についてはいかがですか?

Boylan氏:私はこの件ではいつもGrafanaを見に行きます。

Hellman氏:Clarkがすでに述べたように、私たちは1日に約24パッチを置くことはできていました。Rockyの開発サイクル(2018年2月から8月頃)では1日に平均して180以上のパッチが承認され、統合されるようになりました。この数には、提案されテストが済んでいるものの、承認されていないために統合されていないパッチは含まれていません。

## OpenStackの元で、非常に多くの異なるサブプロジェクトの複雑さをどうやって扱っていますか?

Boylan氏:可能な限り物事を矛盾しないようにして、事前に準備したジョブ定義を提供するようにしています。これは、openStackが(同じプログラミング言語、同じドキュメントシステム、ほとんどのプロジェクトがREST APIを提供しているなど)全体として非常に一貫しているため、予想よりいくらか簡単にできました。Zuulがサポートしているものはたくさんあり、私たちはGoやJava、その他の言語やプロジェクトのテストも行っています。

Hellman氏:バージョン3の機能強化、特にアプリケーションのソースコードと同じリポジトリ内のテストジョブ定義やその他の設定を管理する機のおかげで、それぞれ独立したチームがテストジョブを書いて管理するために大規模な専任のオペレーターグループに頼らなくても、単一のZuulデプロイメントを使用できるようになりました。

私たちのOpenStackチームには、独自の複雑な機能テストと統合テストジョブを書いたチームもありました。彼らは共通のジョブ定義を基礎としてその上に自分たちのジョブを独立して作り、それらのジョブを独立的に拡張して必要なものをテストすることができたので、いちから作業する必要はありませんでした。

## Zuulの力と現在の制限について、他のユーザーが知っておくべきことはありますか?

Boylan氏:制限事項については、Githubのレポートと一般的なダッシュボード情報を改善できました。ジョブ実行のパフォーマンス自体は非常に強力です。

Hellman氏:Zuulは柔軟性がありますが、ほかの柔軟性のあるシステムと同様に、複雑性を最小限に抑えて再利用を最大化するために計画を立てる必要があります。類似しているが微妙に異なるジョブを作成するときに、ジョブ定義をコピーするという便利な方法に逃げてしまうのは簡単です。しかし再利用可能なツールのライブラリを構築するためにほんの少しの時間をとって、他のソースコードと同様にそのジョブを取り扱えば、新しい仕事をより迅速に構築できるようになります。

## Zuulコミュニティが来年どんなことに焦点を当て、どんな機能を提供することを希望していますか?

Hellman氏:私はリポジトリのジョブ設定を問い合わせるために計画されているAPIの拡張を楽しみにしています。コミュニティが最低限のテストですべてのプロジェクトを実行する必要があることを合意した、標準的な一連のジョブに関連するポリシーを実施している場合、私たちはデータを直接参照しています。そのデータを照会するAPIがあれば、Zuulのジョブを単純化しつつ現在のポリシーを遵守できるようになります。

 


 

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes