OpenStack Summit 2018 インフラの次はCI/CDに注目

OpenStack Foundationが主催する半年に1回のカンファレンスであるOpenStack Summit 2018 Vancouverは、「OpenStack」というタイトルを冠しているものの、「One is not Enough」というキャッチフレーズとともにOpenStack以外のオープンソースソフトウェアに関してもセッションが設けられている。今回はその中から「OpenDev」と題されたトラックを紹介したい。

オープンソースソフトウェアは一つだけでは足りない

OpenDevは2017年のサンフランシスコでのSummitでも行われたもので、OpenStack以外のオープンソースソフトウェアを交えて一つのトピックに集中して議論を行うという趣旨だ。前回はエッジコンピューティング、今回はCI/CD（Continuous Integration and Continuous Delivery、継続的インテグレーション、継続的デリバリー）について議論を行うというものだ。CI/CDは、クラウドネイティブなシステムを構築するために欠かせない要素で、CNCF（Cloud Native Computing Foundation）もコンテナ化の次に重要視しているポイントである。単にインフラストラクチャーにOpenStackを使っているだけでは意味がなく、CI/CDを行う仕組みが構築されずに、ソフトウェアのリリース頻度が従来のウォーターフォール型開発スタイルで何年に1回、数ヶ月に1回程度では、クラウドネイティブとは言えないということは理解できるだろう。CNCFのCTOのChris Aniszczyk氏も以前のインタビューで、「CI/CDをちゃんとやらないとクラウドネイティブなシステムとは言えない」とコメントしていたことを記憶している。

参考記事：Japan Container Days、CNCFのCTOが語るクラウドネイティブへの道

OpenDevトラック冒頭の挨拶に立ったのは、OpenStack FoundationのJonathan Bryce氏だ。Bryce氏は「ソフトウェア開発からリリースまでのサイクルは、これまでの数年に一度という頻度から、まるで電子メールを受け取るかのように頻繁に行われるべきだ」という考えを示し、そのためにCI/CDが重要になってくると解説した。ここで重要なのは、それをOpenStack以外のオープンソースソフトウェアにも拡大して、議論をより実践的なものにしようとする試みだろう。そのためこのOpenDevのトラックはプレゼンテーションだけではなく、モデレーターを用意して議論を行い、最終的に議事録としてまとめるということを目的としているという。

ソフトウェアの更新はもっと頻繁に行われるべき

Bryce氏がCI/CDの例として最初のセッションに選んだのは、OPNFV（Open Platform for Network Function Virtualization）のプロジェクトのEricssonとRed Hatのコントリビューターだ。OPNFVは、かつてインタビューを行ったディレクターのHeather Kirksey氏も語っていたように「ソースコードを書かないオープンソースソフトウェア」である。

参考記事：OPNFVのディレクターに訊く「コードを書かないOSSプロジェクトを成功させるためには？」

つまりOpenStackやOpenDaylight、ONAP、Kubernetesなどのオープンソースプロジェクトからリリースされるソフトウェアのテストを行い、最終的に複数のプロジェクトをインテグレーションすることが主な目的なのだ。当然だが、各プロジェクトによってリリースの間隔も異なるし、バグ修正やテストに至る手法も様々である。その意味で複数のオープンソースソフトウェアのインテグレーションを行うOPNFVには、クロスプロジェクトのCI/CDプラットフォームが必要であるということで、このセッションではXCI、クロスプロジェクトインテグレーションの必要性を説いたものになった。

OpenStack、OpenDaylightなどのコミュニティを超えたCIが必要

このセッションでは、複数のプロジェクトをまたがったCIシステムに関してはどのツールが良いという結論は示されなかった。だが、その次のセッションに登壇したMirantisのBoris Renski氏は、明確にSpinnakerを推した。

OpenStackのエンジニアはSpinnakerを気にするべき？

Renski氏は、これまでMirantisがカバーしてきたインフラストラクチャーレイヤーのシステム構築から、よりアプリケーションの領域に拡大した理由として、顧客から「OpenStackのUIであるHorizonは使いたくない、CDのツールであるSpinnakerを使いたい」とリクエストされたことがきっかけであると語った。またアプリケーションチームとオペレーションチームの違いが、最終的にデジタルトランスフォーメーションを阻害していることにも気付いたという。

アプリチームとインフラチームの違い

ここではアプリチームはそれぞれビジネスごとに分散しており、各々が使いたいツールを持っていること、インフラチームは中央集権化しており、安定とコスト、そして共通のツールを使わせたがっていると解説した。ここで紹介されたアプリと運用の違いは、日本企業の情報システムに所属しているエンジニアであれば、よく理解できる部分だろう。

アプリはパイプライン、インフラはスタック思考

そしてインフラチームはレイヤーごとに分けるスタック的な考え方、アプリチームはアプリケーションを素早く開発するためにパイプライン的な発想でシステム化に向かっていると説明し、その接点となる層が継続的デリバリー、CDの部分であると指摘した。OpenStackがAPIでインフラストラクチャーを操作できるソフトウェアであるとすれば、SpinnakerはAPIでCDを実現できるソフトウェアであること、そしてどちらも既存のハードウェア、ソフトウェアをプラグインすることで、操作できるという点が共通している。Renski氏がSpinnakerを推す理由はこれのようだ。

OpenStackとSpinnakerはともにプラガブル

そして2008年頃に始まったデータセンターの自動化から、インフラストラクチャーの自動化のプラットフォームとしてのOpenStack、そして2017年から始まったクラウドネイティブなCDのプラットフォームとしてSpinnakerにたどり着いたことを解説した。Mirantis自体は今もOpenStackを主体としたシステムインテグレーションのビジネスを行っているが、より上位のアプリケーションのCI/CDに関しても「Mirantis Application Platform」としてサービスが始まっているようだ。今回のセッションはある意味、MirantisとしてのSpinnakerを主体にビジネスを展開するという意思表明だったのかもしれない。

その後はMesosphereのエンジニア、Elizabeth Joseph氏が登壇。ここではMesosのクラスターの上にJenkins、GitLabをDockerイメージとしてデプロイし、そこから簡単なWebサイトを構築するというデモを行った。ここでのポイントは、Gitへの変更をトリガーにしてCDのパイプラインが自動的に実行され、Mesosクラスターにデプロイされるまでを、10分程度の時間で行ったことだろう。MesosのスケジューラーであるMarathonとJenkinsのプラグインによる連携など、Mesosのオープンソースソフトウェアが今でもちゃんと進化しているということを訴求したいという意図を感じたデモであった。

参考：CI/CD of Microservices with Containers

続いて、OpenStackが利用しているCI/CDのプラットフォームであるZuulについてのセッションが行われた。ZuulについてはOpenStackにおいては依存関係を理解し、管理者がマニュアルでコマンドなどを打たなくても良いように自動化をするために、インフラストラクチャーチームが使うツールという感じだろう。

前述のように、Spinnakerを推したMirantisのBoris Renski氏は、そのプラガブルな特性を強調していた。それに対し、OpenStack Foundationのトップレベルプロジェクトとして認定されたZuulは、OpenStackのCI/CDを支えるためのすでに実績のあるプラットフォームという位置付けでセッションが行われた。特にZuulが持つGatedという特性について、解説が行われた。これは単にパイプラインが実行できるだけではなく、事前のテストと依存関係の処理により手戻りがなくなることを表しているようだ。Zuulに関するより詳細な情報は、Red HatのMonty Taylor氏による「Zuul v3 for Gating」というセッションを視聴されたい。

Zuulによる依存関係をもとにしたパイプラインの例

参考：Zuul v3 for Gating

今回のOpenDevのミニカンファレンスでは、OpenStackだけに限定せずに多くのCI/CDツールのセッションやAT＆Tなどのエンタープライズに特化したセッションもあり、CI/CDの拡がりと同時に多くのツールがあるがゆえの難しさも顕在化したように思う。OpenStack Foundationがこのような試みを続けることで、一つのオープンソースプロジェクトに限定せずに他のプロジェクトを呼び込むきっかけになり、クロスプロジェクトの連携が拡がることを期待したい。