Kubernetesプロジェクトのための自動化パイプライン

数年前からKubernetesのプロジェクトに携わっていますが、自動化、DevOps、インフラに関する多くのスキルが必要であることは当たり前です。ベアメタル、ハイパーバイザー、論理パーティションを利用した従来のプラットフォームは、現代のクラウドネイティブに比べて、ボラタイル、エラスティック、拡張性、ダイナミック性に劣ります。企業がクラウドネイティブのプログラムを構築しようとすると、プラットフォーム、サービス、アプリケーション、データに至るまで、「すべてはコードである」という言葉に対応するプログラムをどのように実行するかという点で悩むことがよくあります。

アプリケーションの自動化に対するプログラマティックなアプローチは新しいものではなく、DevOpsは以前から存在していました。従来のDevOpsの原則は、インフラストラクチャとプラットフォームサービスのプロビジョニングとコンフィグレーションにおいて、再現性と予測可能な結果をもたらすことで、他のレイヤーにもメリットがあります。しかし、従来のDevOpsでは、インフラとアプリケーションを異なる視点で見る傾向があります。加えて、共有サービスのパイプラインの領域は見落とされがちです。それがデータベースであれ、ローコードのミドルウェアであれ、AIサービスであれ、あるいは自動化ツールそのもののライフサイクルであれ、です。

プラットフォームの最終的なユーザーは、アプリケーションやワークロードをデプロイするビルダー（開発者、テスター、オペレーター）のチームです。これらの開発者は、自分のアプリケーションをテストするために様々な環境を必要とします。アプリケーションは通常、様々なコンポーネントのオーケストレーションです。

• 自分のコード
• データベース、Kafkaストリーム、REST APIなど、自分のコードが使用するサービスのインスタンス
• DevOpツールが実行するビルドスクリプトやパイプライン
• 環境変数、アプリケーションのコンフィギュレーション、シークレットへのアクセスなど。

Kubernetesに関する規律を確立する目的は、アプリケーションの構築をサポートする環境の構築を自動化することにあります。そして、その自動化にエンタープライズスタンダードを導入し、”禁止事項”の理事会を作る必要はありません。非機能的な要件があれば、その制約の下で環境をプロビジョニングする方法を自動化します。また、初日から各レベルに可観測性を持たせることも必要です。これに関連して、プラットフォームの運用者とインフラのエンジニアは、IaC（Infrastructure-as-Code）の考え方とアプローチを導入する必要があるのです。

プラットフォームとインフラのコンフィギュレーションと管理に対するこのプログラム的なアプローチは、DevOpsのアプリケーション的なアプローチを補完するものです。IaCの次の進化のステップは、プラットフォームとインフラの提供とガバナンスの自動化です。これで突然、トレーサビリティー、可観測性、結果を予測可能にすることが可能になります。Hello, GitOpsです。極端に言えば、GitOpsは “GUIが嫌いな人 “と “コードと自動化が好きな人 “のためのものです。