Path to Production (本番環境への道筋)

Path to Production とは開発者の手元のワークステーションで書き上げたコードを本番環境のアプリケーションへと進めていくバリューストリームマップをコード化する方法です。

KubernetesにはPath to Production(本番環境への道筋)を実現するためのAPIやツールが豊富に用意されていますが、これらのコンポーネント間の経路を管理することは大きな負担となり、使いこなせていないプロジェクトが多いのが実情です。

これがKubernetesのエコシステムの中で「イベントを振り付ける」ことができるタイトなツール Cartographer が開発され、オープンソースとして提供、GitHubで公開された理由です。

このPath to Production(本番環境への道筋)の利便性を実現するためにいろいろな要素を隠蔽し、全く新しいプラットフォームを構築する方法もあるでしょう。

しかし Cartographer はあえて本来のKubernetes上に構築することで、自動化を可能にし、自由な構成の選択を可能しています。

Cartographerとは？

Cartographerでは製造業であるメーカが製品を開発・製造してからお客様にとどうまでの道筋をサプライチェーンと呼ぶのと同様に、Kubernetesのリソースを再利用可能なサプライチェーンとして構成します。
そしてアプリケーションワークロードが本番環境に到達するまでに通過するすべてのステージを定義し、適切に段階を進ませることができます。
このような段階を「Path to Production：本番環境への道筋」と呼んでいます。

Cartographerはサプライチェーンの定義に責任を持つ「アプリケーション運用者」と、アプリケーションの作成者である「開発者」の2つの役割の間で責任を明確に分離します。
これらの役割は本来は必ずしも相互に排他的な関係ではありませんが、残念ながら多くの環境では混乱と困惑を招いているのも事実です。

つかりCartographerはアプリケーションを開発するプロジェクトに以下のメリットをもたらします。

・「アプリケーション運用者」と「開発者」の責任を明確化
・検討すべき事項に実行責任者を明確化
・開発者はコードを書くことに集中
・プラットフォームチームはPath to Production(本番環境への道筋)をよりスムーズに進めることが可能
・本番環境を安全かつ安定した状態に維持すること集中可能にする

イベントを振り付ける？

さて先にCartographerは「イベントを振り付ける」と記載しました。
こういった場面ではよくOrchestrationオーケストレーションといった表現が用いられます。
しかしCartographerはイベントにオーケストレーションする方法を提供するのではなくイベントを振り付ける(|Choreography《コレオグラフィー》)方法を提供します。

マイクロサービスという文脈ではよく「オーケストレーターが各マイクロサービス間の各相互作用を定義し、制御する」ということが行われます。
マイクロサービスにおいてオーケストレーションエンジンは各マイクロサービスを実行し、監視し、そして管理しています。
逆言えばオーケストレーターが動作しなくなると、インタラクションモデル全体が崩壊してしまうことを意味しています。

このオーケストレーションをPath to Production(本番環境への道筋)に用いるということは、オーケストレーターが本番環境へのパス上の各ステップを実行し、監視し、管理することを意味します。
例えばCIステージやその他のステージは、オーケストレーターから独立して機能することができなくなります。
Path to Production(本番環境への道筋)に脆弱性スキャンのステップを持たせる場合。
新しいCVEが発生するとコードをスキャンし直す必要があります。
しかしオーケストレーションされた環境下では、容易に再度スキャンし直すことはできません。
コードをスキャンしなおすには、オーケストレーターから新たえてスキャンステップを開始するか、もしくはサプライチェーン全体を新たに実行することが必要となってしまします。

これに対して振り付ける(Choreography)場合には、各コンポーネントとその機能についてそのような拘束や統制を行いません。
それぞれの統合されたステップ間はオーケストレーターに統制・管理されているのではなく、それぞれの融合されたステップが、共通の体系だった方法でコミュニケーションしながら進めることが可能になります。
振付師であるChoreographerとそれぞれの融合されたステップの間で交換されるイベントを元に進められます。
つまり各マイクロサービスは、非同期的に他のマイクロサービスと相互に作用しながら機能することができるのです。

振り付け(Choreography)モデルではPath to Production(本番環境への道筋)と、そのステップに必要なツールは、それぞれのステップがどのように挙動するのか、その全ての情報が登録され、管理する必要はありません。
前後のステップは、その前後のステップが「何をどのようにやっているのか」を必要はありません。

それぞれのステップがすることは
・ある作業をやってくれという信号を受け取り
・その作業を完了させ
・終了したことを知らせる
ということだけに責任を負います。

オーケストレーションと同じケースで考えると、脆弱性スキャナーを持つパイプラインでは、新しいCVEがあった場合、脆弱性スキャナーは以下の動作にのみ責任を負います。
・脆弱性スキャナーは新しいCVEがあった事実を認識し
・新しいスキャンを開始
・スキャンが完了
・スキャンが完了したことを示すメッセージを送信

舞台の上でダンサーが別のダンサーの指先の位置を補正しているのを見たことがありますか？
舞台の上でダンサーが別のダンサーに「いま飛んで！」「さぁ、跳ねて！」と指示していますか？
そんな指示がなくとも一人一人のダンサーはプロとして自らの責任を果たし、チーム全体で完全な芸術を完成させている姿を、あなた見たことがあるはずです。

マイクロサービスという世界の中で、Path to Production(本番環境への道筋)を実現するのに必要なのは、全てを隅々まで制御し、支配するオーケストレータではないのです。
個々のダンサーが、プロとして自らの仕事を完璧にこなし、支配されることなく、チームとして協調し、完成した芸術へと昇華させる。
必要なのは各機能を提供するプロフェッショナルダンサーを集め、指導し、本番環境という完全な芸術空間を実現する振付師：Choreographerなのです。

Path to Production(本番環境への道筋)を実現する
振付師：Choreographer

例えば新しいCVEが登場したとき、誰かがビルドのボタンをクリックしたとき。
Path to Production(本番環境への道筋)のステップが同期しないといけない事項はほとんどありません。
つまりワークフローエンジンとして振付師：Choreographerを選択することはとても自然なことです。

また柔軟性とPath to Production(本番環境への道筋)のステップを入れ替えることができることも非常に重要です。
あるチームが kpack を使用ています。
別のチームが kaniko を使用する必要があります。
その場合に全てのPath to Production(本番環境への道筋)を検討し直し、設定し直すことはナンセンスです。

なぜなら両者の間で 1 つのステップを交換するだけで、Path to Production(本番環境への道筋)を同じように使用できるからです。
同じ種類のメッセージを出力するステップであれば、1つのステップを他のステップと完全に入れ替えることだけで、Path to Production(本番環境への道筋)自体はそのまま利用できるべきです。

Path to Production(本番環境への道筋)を実現するワークフローエンジンには、このような柔軟性を持つことも必須条件です。

例えば、あるチームがCIテストにJenkinsを採用し、別のチームがCircle CIを採用した場合、オーケストレーターはそれぞれとのインテグレーションの為に、情報の流れと実行を管理する方法を知る必要があります。
この単純な例に本番環境へのパスに含まれる可能性のあるステップの数と、各ステップで交換可能なツールの数を掛け合わせると、可能性は無限に広がり、個々のパイプラインを維持することの実用性に限界が見えてきてしまします。

JenkinsもCircleも、最終的には同じ「種類」のメッセージを生成します。
コードが正常にテストされたか、されなかったかです。
このメッセージは振付師：Choreographerが気にする唯一のものなので、各ステップをホットスワップしても、プロダクションへのパスに影響はありません。

その場合、JenkinsまたはCircleのいずれかを含むステップがCIステップとなります。
「JenkinsによるCI」や「TravisによるCI」とは異なります。
TravisまたはJenkinsがCIを実行しているという事実は、必要な情報ではありません。

Choreographerは、それぞれのツールが設計された職務を遂行させる一方で、Path to Production(本番環境への道筋)全体でそれらを統一し、開発者チームが必要とする柔軟性を生み出す機能を提供します。

プラットフォームオペレータの場合。
例えばセキュリティやコンプライアンスのグループが必要とするステップがある場合はどうでしょう。
そのステップをホットスワップできないように設定することができます。

最終的にChoreographerにとって
・ユースケースが同じで
・スキャンが成功したかどうか
（単純なケースでは）これのみが感心事項です

その特定のスキャンの詳細は、少なくともChoreographerにとっては重要ではないのです。

Cartographerの仕組み

CartographerではアプリケーションがイメージやKubernetesの構成を作成するために、必要なすべてのステップを定義することができます。
これを実現するのが「サプライチェイン」という抽象化技法です。

サプライチェーンはテンプレートで指定されたコンポーネントで構成されます。
各テンプレートは既存のKubernetesリソースのラップとして機能し、ラップされたKubernetesリソースであるテンプレートを
Cartographerで使用します。
Cartographerのサプライチェーンのテンプレートには以下のものがあります。 

・ソーステンプレート

・イメージテンプレート

・設定テンプレート

・汎用テンプレート

Cartographer Coreの一部であるPipeline Serviceを使用することで、サプライチェーンを既存のCI/CDパイプラインとの統合に拡張することもできます。
Pipeline Serviceは既存のCI/CDツール(Tektonをサポートしており、将来的にはさらに多くのプロバイダをサポートする予定)のラッパーとして機能し、Cartographer内でパイプラインを実行するための宣言的な方法を提供します。

サプライチェーンはオペレーター向けですが、Cartographerはワークロードと呼ばれる開発者向けの抽象化機能も提供しています。
ワークロードでは開発者は、リポジトリの場所、環境変数、サービスクレームなどのアプリケーション仕様を作成することができます。

設計上、サプライチェーンは多くのワークロードで再利用することができます。
これによりオペレータは本番環境へのパスのステップを一度に指定することができます。
開発者はアプリケーションを個別に指定することができます。
さらに開発者はそれぞれがPath to Production(本番環境への道筋)を同じように使用することもできます。

開発者はユーザーへの価値提供に集中でき、迅速かつ容易に本番環境に到達することができるのです。

同様にアプリ運用者は、各アプリケーションが自分の定義したPath to Production(本番環境への道筋)のステップを確実に通っていることを確認できる為、安心して運用することができます。

さぁ、いますぐCartographerの世界へ

ソースコードを実行中のアプリに変換することを自動化し、プラットフォームにデプロイされるすべてのアプリケーションにセキュリティスキャンを統合することで、Kubernetesアプリの開発と運用の双方を格段に、楽に、簡単にできるようになるはずです。

GitHubでCartographerの最新リリースを試しますか？
Cartographerに挑戦してくれるあなたからであれば、新機能の提案やリクエストもお受けしています。
もちろんTwitterやGoogle Group、コミュニティサイトでCartographerコミュニティもあなたの参加をお待ちしています。

原文

参考：インストールの様子などより詳しい情報を知りたい方は Toshiaki Maki さんの「Cartographer 0.0.6をkindで試す」も参考になると思います。