GitOps の設計や実装の初期段階では、必要と思われる様々なツールやプラクティスについて考えるのは大変なことです。インフラ やアプリケーションのデプロイを管理するための堅牢でスケーラブルなワークフローを設計していることを確認したい。そして、プロセスを複雑にしすぎたり、チームがコード変更をリリースするのを難しくしたりするようなものは持ち込みたくありません。
焦点を絞る1つの方法は、デプロイの実践をサポートするツールと実践を探すことである。主な検討事項は、プッシュ・ベースと プル・ベースのどちらのアプローチを利用するかということだ。どちらにも長所と短所があり、どちらを使うかは GitOps 戦略に含めるツールやプロセスに影響します。
ワークフローの自動化とインフラ
まず、DevOpsの中核となる2つのプラクティスを確認しよう。インフラ as code（IaC）と、継続的インテグレーションと継続的デリバリー（CI/CD）による自動化だ。
IaCは、一連の手動ステップや対話型プロセスではなく、コードを通じてインフラ 。このアプローチは、インフラ プリミティブや管理されたクラウド・サービスだけに限定されるものではなく、構成ファイル、ソフトウェアのインストール、ネットワークやセキュリティ・ポリシーなど、管理可能なすべての側面に適用できる。一般に「X as Code」と呼ばれるこのタイプの統合管理は、デプロイメントのためのテンプレート化され文書化された望ましい状態を提供します。
CI/CDは、開発者が高品質で安全にコーディングされたアプリケーションを迅速かつ確実に提供するための方法論であり、一般的なプラクティスのセットである。CI/CDを採用することは、ソフトウェア開発ライフサイクルの適切な段階で自動化を実装することで、開発チームがビジネスとエンドユーザーの要件に鋭く集中できる文化を受け入れることです。
ソフトウェア開発において、統合とは、コードへの変更をリポジトリにコミットするプロセスである。継続的インテグレーション（CI）とは、更新されたアプリケーションコードを信頼できる一貫した方法でビルド、テスト、パッケージ化することで、変更を自動的に検証するプロセスである。変更が環境にデプロイされる前にバグ、セキュリティ脆弱性、コンフリクトを発見できるため、プッシュイベントごとにCIワークフローをトリガーすることで、よりスムーズで迅速な開発プロセスが実現する。
継続的デリバリー（CD）ワークフローは、CIワークフローが正常に完了した後に引き継がれる。これは、更新されたアプリケーションコードを選択された環境に配信する自動化された一貫性のあるプロセスである。これは、アプリケーションをステージングサーバーや本番サーバーに直接デプロイしたり、コンテナレジストリやモバイル配信プラットフォームに新しいリリースを出荷したりすることを容易にするワークフローである。
これらは、開発者のワークフローを自動化することに関する中心的なテーマだ。GitOpsのアプローチは、これらのDevOpsのコアとなるプラクティスに依存し、それらを運用します。git リポジトリを IaC 定義ファイルの単一の真実のソースとして活用し、自動化パイプラインを活用することで、インフラ の望ましい状態を効果的にバージョン管理することができます。
ここで、デプロイのやり方に戻ってきます。プッシュベースとプルベースのどちらがアプリケーションと GitOps 戦略に最適かを決めるのです。
プッシュ型とプル型アーキテクチャーの比較
プッシュベース、またはエージェントレスは、JenkinsやCircleCIのような外部のCI/CDクライアントによって選択した環境に変更がプッシュされる、より伝統的なアプローチである。これは、Kubernetes以外の環境や、各コンポーネントで別々のエージェントやWebhookを実行するのが面倒なワークロードの種類が混在している環境では好ましいかもしれない。
長所だ：
- 単一の環境で複数の種類のワークロードを実装する方が簡単です。
- 異なる環境（クラウドネイティブとオンプレミスなど）間でのデプロイ手法の標準化。
- ほとんどのCI/CDフレームワークはプッシュベースのモデルを活用しているため、ツールの柔軟性がある。
短所だ：
- CI/CDクライアントには、変更が正常にデプロイされたかどうか、あるいはその結果サーバーサイドで問題が発生したかどうかを知るための観測機能がない。
- CI/CDクライアントが変更をデプロイするために、追加のツール（kubectl、Helm、Docker、Ansible 、Terraform 、SSHなど）をインストールする必要があるかもしれない。
- CI/CDクライアントに環境への外部アクセスを許可する必要があり、セキュリティやコンプライアンス問題のリスクが高まる。
プルベースあるいはエージェント・アプローチは、環境をCDパイプラインの一部にすることで、逆の方向に働きます。エージェントまたはオペレーターがgitリポジトリの変更を監視し、それをプルして適用します。このタスクは、エージェントが単一の真実のソースからコンフィギュレーションのドリフトを検出したときにも実行される。このアプローチは、Kubernetesネイティブ環境で特にうまく機能する。
長所だ：
- エージェント/オペレーターは、環境の現在の状態や配備状況を観測することができる。
- ソースを表示する権限のみが必要な環境であるため、セキュリティが向上し、コンプライアンスが簡素化される。
- 手作業による人為的な介入やその他の原因によるコンフィギュレーション・ドリフトを素早く検出。
短所だ：
- Kubernetes以外のデプロイメントではより複雑になる。
- 特定の環境タイプで動作するように設計された工具が必要。
GitOps 戦略を計画し始めたら、さまざまなデプロイ戦略がアプリケーションをどのようにサポートするかを検討しましょう。プッシュベースとプルベースのアプローチにはそれぞれ利点があり、異なるシナリオに適しています。検討すべきツールやプラクティスはたくさんあり、ある程度の見通しを持てば、あなたのチームやスタックにとって何が正しいソリューションなのかがわかるだろう。
さらに詳しい情報をお探しですか？無料のGitOps Strategy Eブックをダウンロードするか、またはアカマイのクラウドコンピューティングの専門家に無料でご相談ください。
コメント