翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Spinnaker
GitOps ツールとしてのみ設計されているわけではありませんが、特にクラウドネイティブおよび Kubernetes デプロイに使用する場合は、GitOps の原則を実装するように設定できます。
GitOps のサポート
| [面積] | ツール機能 |
|---|---|
宣言型設定 |
" は宣言型パイプライン定義を使用します。これは通常、JSON ファイルまたは YAML ファイルとして保存されます。これらのパイプライン定義は、GitOps プラクティスに従って Git リポジトリでバージョン管理できます。 |
IaC |
" は、インフラストラクチャとデプロイ設定の定義をコードとしてサポートしています。これらの定義は Git リポジトリに保存でき、単一の信頼できるソースとして機能します。 |
マルチクラウドデプロイ |
" は、複数のクラウドプロバイダーと Kubernetes クラスターで動作するように設計されています。これにより、さまざまな環境で一貫した GitOps プラクティスが可能になります。 |
コードとしてのパイプライン |
パイプラインはコードとして定義し、Git リポジトリに保存できます。これにより、バージョン管理とデプロイプロセスのレビューが可能になります。 |
自動デプロイ |
Git リポジトリの変更に基づいてデプロイを自動的に開始するように " を設定できます。このツールは、GitOps の中心となる継続的なデプロイプラクティスをサポートしています。 |
イミュータブルなインフラストラクチャ |
" は、GitOps の主要な概念であるイミュータブルインフラストラクチャの使用を促進します。既存のインスタンスを変更するのではなく、新しいインスタンスのデプロイを推奨します。 |
ロールバックとバージョニング |
" は、堅牢なロールバック機能と、以前の既知の正常な状態への迅速な復帰を提供します。GitOps のトレーサビリティの原則に従って、デプロイのバージョニングをサポートします。 |
承認ワークフロー |
「」には、環境間の制御されたプロモーションをサポートするために、パイプラインに手動による判断ステージが含まれています。これにより、デプロイとリリースを分離する GitOps プラクティスがサポートされます。 |
Canary と Blue/Green のデプロイ |
" は、安全で制御されたリリースのための GitOps プラクティスに沿った高度なデプロイ戦略をサポートしています。 |
バージョン管理システムとの統合 |
" は、さまざまな Git プロバイダーと統合して、リポジトリイベントに基づいてパイプラインを開始できます。 |
Kubernetes 統合 |
" は Kubernetes のネイティブサポートを提供し、Kubernetes リソースの GitOps スタイルの管理をサポートします。 |
アーティファクト管理 |
" は、GitOps ワークフローを維持するために不可欠なアーティファクト管理とバージョニングをサポートしています。 |
オブザーバビリティとモニタリング |
" は、GitOps のオブザーバビリティの側面をサポートするモニタリングツールとの統合を提供します。 |
監査証跡 |
" は、GitOps の監査可能性の原則をサポートする詳細なデプロイログと履歴を提供します。 |
ロールベースのアクセスコントロール (RBAC) |
このツールは、GitOps セキュリティプラクティスに従って、どのアクションを実行できるかをきめ細かく制御するための RBAC を実装します。 |
テンプレート化とパラメータ化 |
" は、再利用可能なパラメータ化されたデプロイを可能にするパイプライン定義のテンプレートをサポートしています。 |
環境の昇格 |
" は、制御された方法で環境間のアプリケーションのプロモーション (ステージングから本番稼働など) を容易にします。 |
CI ツールとの統合 |
" は、さまざまな継続的インテグレーション (CI) ツールと統合して、GitOps の原則に準拠した完全な CI/CD パイプラインを提供できます。 |
カスタムステージと拡張機能 |
このツールはカスタムステージと拡張機能をサポートしているため、チームはニーズに合わせた GitOps ワークフローを実装できます。 |
一元管理 |
" は、複数の環境とクラウドプロバイダーにまたがるデプロイを管理するための一元化されたプラットフォームを提供します。 |
" は主に GitOps ツールとして販売されていませんが、その柔軟性と堅牢な機能セットにより、特に複雑なマルチクラウド環境で GitOps ワークフローを実装できます。Argo CD や Flux などの " と専用の GitOps ツールの主な違いは、" が高度なデプロイ戦略とマルチクラウドサポートを備えた、より包括的な継続的デリバリープラットフォームを提供することです。
「」の強みは、さまざまなクラウドプロバイダーにわたる複雑なデプロイシナリオを処理する能力と、高度なデプロイ戦略のサポートにあります。" が適切に設定されている場合、GitOps の原則を効果的に実装できます。これにより、多様で複雑な環境で GitOps プラクティスを採用したい組織にとって強力なツールになります。
詳細については、「」のドキュメント
アーキテクチャ
次の図は、" と Jenkins X を使用する GitOps 駆動型 CD ワークフローを示しています。詳細については、" ドキュメント
各パラメータの意味は次のとおりです。
-
ステップ 1: コードコミット。開発者は、アプリケーションコードの変更を Git リポジトリにコミットします。これらの変更には、アプリケーション自体、Dockerfiles、または Kubernetes マニフェストの更新が含まれる場合があります。
-
ステップ 2: Jenkins のビルドとイメージの作成。Jenkins は、ウェブフックまたはポーリングを介して Git リポジトリによって自動的にトリガーされます。Jenkins はアプリケーションを構築し、Docker イメージを作成し、ビルドされたイメージを設定済みの Docker レジストリ (Amazon ECR や Docker Hub など) にプッシュします。
-
ステップ 3: イメージのモニタリングとパイプラインのトリガーを行います。" は、新しいイメージについて Docker レジストリを継続的にモニタリングします。新しいイメージバージョンが検出されると、" はパイプラインを自動的にトリガーしてデプロイプロセスを開始します。
-
ステップ 4: ターゲット名前空間へのデプロイ。" は、新しい Docker イメージを Amazon EKS にデプロイします。パイプライン設定に基づいて、イメージはクラスター内のターゲット名前空間にデプロイされます。" は、ブルー/グリーンデプロイや Canary デプロイなどの定義されたデプロイ戦略に従って、最新のアプリケーションバージョンをデプロイします。
