GitOps を用いた Amazon EKS の自動化

元の記事：https://thinkwithwp.com/jp/blogs/containers/automating-amazon-eks-with-gitops/

本記事は Weaveworks のコンテンツディレクターの Anita Buehrle による寄稿記事です。

企業は速く進むことを望んでいます。より頻繁に、より確実に、そしてなるべく少ないオーバーヘッドでデプロイする必要があります。GitOps は Kubernetes で実行されている複雑なアプリケーションやインフラストラクチャを開発者が管理および更新するための迅速かつ安全な方法です。

GitOps は運用とアプリケーションデプロイのワークフローであり、クラウドネイティブアプリケーションのインフラストラクチャとデプロイの両方を管理するための一連のベストプラクティスです。この記事は二部構成になっています。第 1 部では GitOps がどのように動作し、利点が何であるかについての説明とともに、GitOps の歴史もお話します。第 2 部では、Amazon Elastic Kubernetes Service (Amazon EKS) への継続的デプロイのパイプラインを Flux でどのようにセットアップするかを説明したハンズオンチュートリアルを用いて、自分自身で GitOps を試してみることができます。

GitOps とは何か？

Weaveworks の CEO の Alexis Richardson による造語である GitOps は Kubernetes およびその他のクラウドネイティブ技術の運用モデルです。クラスターとアプリケーションのデプロイ、管理、そしてモニタリングを統合する、一連のベストプラクティスを提供します。言い換えると、アプリケーション管理にデベロッパーの手法を適用していくということであり、運用と開発の両方にエンドツーエンドの CI および CD パイプラインと Git ワークフローが適用されます。

GitOps の原則

GitOps が実際に機能するためには、チームが次の原則を実施している必要があります。

#1. システム全体が宣言的に記述されている

Kubernetes は、宣言的な設定で管理される、多くの最新のクラウドネイティブツールの 1 つです。宣言的とは、設定が命令のセットではなく、事実のセットによって保証されることを意味します。つまり、設定はコードとして扱われ、アプリケーションのソースコードと一緒に Git に保存できます。しかし、さらに重要なのは、システム全体の宣言的な設定をソース管理下に置くと、システムの望ましい状態に関して信頼できる唯一の情報源 (single source of truth) が得られ、インフラストラクチャとアプリケーションコードを同時に管理できるなどの多くの利点が得られます。

#2. 望ましいシステム状態が Git でバージョン管理されている

システムの宣言的な定義を Git に格納し、信頼できる正規の情報源とすることで、クラスターの唯一の管理場所にします。これにより、ロールバックとロールフォワードも単純化され、必要に応じて「良好な状態」に戻すことができます。Git の優れたセキュリティ保証により、コードの出自だけでなく作成者について署名付きコミットで証明します。

#3. 変更を自動的に適用する

望ましいシステムの状態が Git に保存されたら、次のステップはシステムと変更を自動的に reconcile する能力です。この能力で重要なのは、変更を行うために特定のクラスターの認証情報を必要としないことです。GitOps では状態の定義が外部に存在する、分離された環境を持ちます。これにより、チームが実際に行うこと(例えばコードをデプロイすること)と、どのように行うか(例えばコードをデプロイするためのクラスターの設定)を分離できます。

#4. ソフトウェアエージェントが正しいシステム状態を検証して相違があるときにアラートする

システム全体の望ましい状態をバージョン管理下に置き、クラスター内で実行することで、すぐにソフトウェアコントローラを使用して、クラスターの実際の状態を望ましい状態に合わせ、現実が期待と一致しないときは必ず通知するようにできます。Flux のような GitOps コントローラをこれらのソフトウェアエージェントと組み合わせて使用することで、システム全体が自己修復されます。そして自己修復とは、ノードやポッドが落ちたときに Kubernetes によって処理されることではなく、より広い意味で例えばヒューマンエラーの場合を意味します。この場合、ソフトウェアエージェントは操作に対するフィードバックと制御のループとして動作します。

制御とフィードバックのループ

GitOps の重要な要素はフィードバックと制御です。しかし、それは正確にはどういう意味でしょうか？開発者がより速くリリースできるように制御するためには、デプロイのワークフローに可観測性を組み込む必要があります。可観測性を組み込むことにより、開発者はリアルタイムデータで実験して情報に基づいた意思決定を行うことができます。例えば、デプロイメントをロールアウトしようとしている際、最終的に変更をコミットする前に実行中のクラスターに対してヘルスチェックを行うことができます。あるいは、その更新が予定通りにならなかったならば、良好な状態にロールバックする必要があるかもしれません。フィードバック制御ループを使用すると、次の質問に効果的に回答できます。

• デプロイが成功したかどうかはどうすれば分かりますか？
• 生存中のシステムが望ましい状態に収束したかどうかはどうすれば分かりますか？
• 違うときに通知を受けることはできますか？
• クラスターとソースの制御の収束をトリガーすることはできますか？

Git はシステムの望ましい状態の信頼できる情報源ですが、可観測性は実行中のシステムについての実際の本番状態のベンチマークです。GitOps はそれら両方を利用して、アプリケーションとインフラストラクチャの両方を管理し、チームの生産性を向上させます。

GitOps の主要な利点

GitOps を利用すると、組織は次のような利点を直ちに得られます。

より強いセキュリティ保証: Git は変更を追跡して管理する機能ならびに変更の作成者と作成元を署名付きコミットで証明する機能を持ち、それらによる強い正確性とセキュリティ保証でクラスターの望ましい状態を正確かつ安全に定義します。セキュリティ違反が発生した場合、不変かつ監査可能な信頼できる情報源を使用して、侵害されたシステムとは独立した新しいシステムを再作成できるため、ダウンタイムを短縮して、大幅に向上したインシデントレスポンスと、コンプライアンスを満たすためのより効果的なディザスタリカバリを実現できます。

また、ソフトウェアの統合とテストとの間の責任の分離は、本番環境にリリースすると、最小権限というセキュリティ原則を具現化し、侵害の影響を軽減して、攻撃対象領域を小さくします。

スピードと生産性の向上: フィードバックと制御のループを統合した継続的デプロイの自動化で、より頻繁なリリースがサポートされることによってデプロイまでの平均時間を短縮できます。Git に保存されている宣言的な定義により、開発者は使い慣れたワークフローを使用でき、新機能をデプロイするために新しい開発環境やテスト環境をスピンアップするのに掛かる時間を短縮できます。チームが 1 日あたりにより多くの変更をリリースすることができて、顧客に新機能や操作性を提供する迅速なターンアラウンドにつながります。

検出までの平均時間とリカバリの平均時間の短縮: GitOps のベストプラクティスにより、クラスターの崩壊から修復するのに掛かる期間も短縮されます。Git の組み込み機能の revert/rollback と fork で安定かつ再現可能なロールバックを取得できます。システム全体が Git で記述されているため、クラスター障害後に修復すべき信頼できる唯一の情報源が存在し、リカバリまでの時間 (MTTR) を数時間または数日から数分に短縮できます。GitOps は、リアルタイムのフィードバックと制御のループを提供します。可観測性のために Prometheus やエンドツーエンドのトレースのために Jaeger のような他のツールと組み合わせて、問題を検出して突き止めることが可能になり、クラスター全体の崩壊をより迅速に防ぎ、平均検出時間 (MTTD) と平均検索時間 (MTTL) を全体的に短縮できます。

安定性と信頼性の向上: GitOps は、インフラストラクチャとアプリを作成するための単一の運用モデルを提供しているため、組織全体で一貫したエンドツーエンドのワークフローを実現できます。継続的インテグレーションと継続的デプロイのパイプラインはすべてプルリクエストによって駆動されるだけでなく、運用タスクも Git を通して完全に再現可能です。

コンプライアンスと監査の容易化: クラスター管理戦略の一部として Git を組み込むことにより、すべてのクラスターで誰がいつ何をしたかという監査証跡を Kubernetes の外で簡単かつ自動的に取得して、SOC 2 コンプライアンスを満たし、さらに安定性を確保することができます。

GitOps のデリバリーパイプライン

GitOps は、Kubernetes クラスターへのデプロイを待機して同期する、Flux のような Kubernetes の reconcile を実装します。Flux は Reconcile のためにいくつかのコントローラーを利用しますが、重要な点は以下の 2 つです。

1. テスト、構築、コンテナレジストリへのイメージのプッシュの後にアプリケーションやインフラストラクチャのデプロイを CI ツールに任せるよりも安全になります。
2. YAML マニフェストの手動更新のようにエラーが発生しがちの複雑なタスクを自動化します。

クラスターでは Flux のコントローラーが Kubernetes のカスタムリソースとともに動作します。カスタムリソースの変更に関連するイベントを待機して、(デプロイポリシーに応じて) それらの変更を適用するか、Git に保存されている望ましい状態からの相違を示すアラートを送信することができます。この GitOps パイプラインにより、「Git 内のもの」と「クラスターで実行されているもの」が一致していることを保証できます。

GitOps は変更をデプロイするより安全な方法です

Docker イメージは、コンテナレジストリへの読み取り専用アクセスを使用してクラスターにプルされます。CI ツールにはクラスターの特権は付与されず、攻撃対象領域を減らし、パイプライン (一般的な攻撃ベクトルとして知られています) の重要なセキュリティリスクを排除します。GitOps では、クラスターの認証情報はクラスターのドメイン内に保持され、クラスター外のカスタムスクリプトには埋め込まれません。

以下の表は、クラスター、CI と CD のツール、コンテナリポジトリ間でどのように読み取り/書き込み権限が分散されるかを示しています。同様に、チームは Kubernetes への更新をより安全な方法で作成することもできます。

表 1: GitOps の特権の分離

まとめと考察

2 部立てのシリーズにおけるこの第 1 部で、GitOps とは何か、どのようにインフラストラクチャの更新とアプリケーションのデプロイの両方に適用できるかについて、概要を説明しました。次の投稿では、Amazon Elastic Kubernetes Service (EKS) を使用して GitOps パイプラインを構築するためのステップバイステップのチュートリアルを提供します。

翻訳はソリューションアーキテクトの一杉 (ひとすぎ) が担当しました。