OpenShift Commons Gatheringで語られたOpenShiftに最適なCI/CDとは

レッドハット株式会社が開催したOpenShift Commons Gatheringでは、タイトル通りコンテナプラットフォームのOpenShiftを取り巻くエコシステムに関するセッションが行われた。特にCI/CDに関するセッションは複数行われていた。今回はその中からレッドハットのソリューションアーキテクトが行った「Cloud Native時代のCI/CD」というセッションを紹介する。プレゼンテーションを行ったのはレッドハット株式会社の北山晋吾氏だ。北山氏の肩書きは「クラウドソリューションアーキテクト」となっており、レッドハットがフォーカスするオープンハイブリッドクラウド戦略の中核であるOpenShiftに携わっているのは当然のことだ。その北山氏が、敢えてCI/CDについて解説するセッション（中身はOperator FrameworkとTekton、そしてArgoCDの解説）を担当したのは興味深い。すでにKubernetesと同様に、OpenShiftも「退屈」な時代に差し掛かっているのかもしれない。

プレゼンテーションを行う北山氏

北山氏が最初に「バリューストリームのプロセス」として解説したのが、開発から運用に至るプロセスの中身だ。以下の3つの段階に分けて説明した。

1. デベロッパーがコードを書き、ビルドしてテスト＆デバッグ
2. 本番環境に実装する前にテスト環境に入れて結合テスト
3. 本番環境に投入

このプロセスのポイントは、Gitによるコード管理とコンテナイメージによるパッケージとKubernetesの活用は、すでに前提となっている点だろう。

Kubernetesをベースにしたコードから実装までのプロセス

ローカルでの開発の後に行われるテスト環境での実装をCI（継続的インテグレーション）、本番環境への実装をCD（継続的デプロイメント）と分けて考えた場合に、北山氏が考えるそれぞれのプロセスのポイントが強調されている。それは開発であれば「どこでも同じ環境で開発できること」であり、CIであれば「ガバナンスの徹底」、そしてCDでは「失敗しないデプロイ」である。

従来のCI/CDとクラウドネイティブなCI/CDの違い

ここでは従来型ツールとしてJenkins、クラウドネイティブなツールとしてTekton、ArgoCDが挙げられており、ここから本格的なクラウドネイティブなCI/CDに関する解説が始まった。北山氏は従来のツールでは設定がツール依存になってしまう欠点を挙げて、いわゆる「Jenkinsおじさん」問題が発生してしまうことを言及した。「Jenkinsおじさん」問題に関しては、PivotalのConcourseを取材した時の記事を参考にして欲しい。

参考：パイプラインベースのCI/CDツール、Concourseとは？

ここではクラウドネイティブ、つまりKubernetesに特化したCIとしては個別の設定ファイルを使うのではなく、Kubernetesを拡張するための仕様、Custom Resourceを使うべきというのが要点である。

従来のCI/CDのフロー。開発者から運用者への依頼が必要

このスライドでは、従来のCI/CDの場合開発者がパイプラインを設定することができず、運用担当者に依頼する形で、ビルド、テスト、デプロイなどが行われることを解説された。

Kubernetesに特化したCI/CDでは開発者自身がパイプラインを設定可能

そしてKubernetesに特化したCI/CDでは、Kubernetesの設定情報として利用されるCustom Resourceにパイプライン情報が保存されるために、「運用担当者への依頼」という行為そのものがなくなると解説した。

Kubernetes Nativeの意味

そしてKubernetesのマニフェストを使ったパイプラインの例を挙げ、Tektonが利用するTask、Stepなどのコンセプトを紹介する段となった。

TektonとArgoCDによって自動化されるOpenShiftのCI/CD

このスライドではTektonがビルドとテスト、イメージのリポジトリーへのプッシュなどを行い、各環境（テスト、本番）への同期はArgoCDが行うという概要が示されている。

ここからはTektonとArgoCDの説明となるが、特にTektonの持つTaskやStep、Task Runなどの新しい用語については詳細な解説が行われた。

OpenShift 4.6でTech PreviewとなったOpenShift Pipelineの中身はTekton

実際にTaskを組み合わせてパイプラインを設定し実行するまでを解説し、Custom ResourceとControllerによって実装されていることを解説した。

OpenShiftのGUIからもパイプラインの実行状況が確認できる

またRed Hat MarketplaceやOperatorHubと同様に、Tekton Hubとしてカタログ化することでデベロッパーが既存のノウハウを再利用できるように開発が進んでいることを紹介した。ちなみにTektonはJenkinsの開発元であるCloudBeesが創設し、The Linux Foundationのサブ組織として活動しているCD FoundationのFounding Projectである。

CIはTektonを用いるが、CDには使わない

このスライドでは、CIにはTektonを用いるが、CDの部分には使わないということが解説された。その理由として開発環境、ステージング環境、本番環境の状態を検知してあるべき姿に変更するやり方（Pull型）がTektonではできず、Push型のデプロイになってしまうことが挙げられた。

CDの部分はArgoCDを使ってPullした上で変更を行う

このスライドではCDの部分をGitOps、つまりコマンドを使って環境を変更するのではなく、Gitに保存された設定情報を常に真実として環境を設定する方法論を採用していることが解説された。実際の環境とのあるべき設定情報の差異を、ツール側が検知した上で変更を加えるというのがポイントだ。

OpenShift GitOpsの核となるArgoCDの概要

Intuitが開発し公開しているオープンソースプロジェクトのArgoCDは、最近特に注目されているプロジェクトと言えるだろう。ArgoCDはCNCFのサンドボックスとしても採用されているカオスエンジニアリングのソフトウェア、Litmus Chaosでも採用されているCDツールだ。

ここではGitOpsについても解説を行い、複数の環境をkubectlやocコマンドだけで管理するのは容易ではないことを解説する段となった。

GitOpsの解説

コマンドラインツールだけでのデプロイには限界がある

そして、コマンドラインツールだけでは困難な管理のためのツールとして、KustomizeやHelm、OpenShift Templateなどが紹介された。ここでは設定ファイルであるYAMLファイルに環境ごとの設定をパッチとして書き換えるKustomize、KubernetesのパッケージマネージャーであるHelmを簡単に解説した。Helmについては以下の記事を参照されたい。

参考：KubernetesのパッケージマネージャーHelmとは？

複数環境に対応するためのツールの紹介

そしてまだ計画中のソフトウェアであると念を押してから紹介されたのが、OpenShift GitOps Viewだ。

OpenShift GitOps Viewの紹介

最後にまとめとして、「CIとCDを分離して自動化ツールに任せること」「独自のツールで実装するのではなくKubernetesの環境設定を利用することで複数の環境に合わせた実装ができること」などを説明して、セッションを終えた。

このセッションで分かるように、OpenShiftのエコシステムの中でもCI/CDやGitOps周辺は特に多くの新しい機能、プロジェクトが計画されている。ただ自動化されたとしても、運用側のノウハウをすべてデベロッパーが吸収して実行するというのはハードルが高いと思われる。すべての開発者に対していわゆるフルスタックエンジニアになれというのは難しいだろう。本番環境に新しいアプリケーションをデプロイすることだけが運用担当者の仕事ではないはずだ。

開発と運用の役割分担については、Microsoftなどが提案している、デベロッパーはコードを書くことに集中し、アプリケーションオペレーターという新しい役割のエンジニアがインフラストラクチャーオペレーターと協力して最適な実装を行うという方法論もある。これについてレッドハットがどのような意見を持っているのか、機会があれば質問してみたい。