補助ソリューションリソース: GitOps

連絡先

市場の視点

GitOps の必要性

現代のアプリケーションは高速な反復で開発され、極めてダイナミックなスケールで動作します。成熟した DevOps 文化を持つ組織では、コードを 1 日に数百回本番にデプロイできます。アプリケーションは数人のユーザーから数百万まで、極めてダイナミックな負荷の下で動作することがあります。現代のインフラはエラスティックである必要があります。動的にプロビジョニング・デプロビジョニングできるキャパシティは、最適なパフォーマンスとコストの最小化を維持しながら負荷に追従できます。今日のインフラに課される要求の中で、堅牢で一貫性のある方法論でインフラの自動化を管理することがますます重要になっています。

GitOps とは何か？

GitOps == IaC + MRs + CI/CD

GitOps は、バージョン管理、コラボレーション、コンプライアンス、CI/CD といったアプリケーション開発で使われる DevOps ベストプラクティスを取り入れ、それをインフラの自動化に適用する運用フレームワークです。

GitOps は、バージョン管理、コードレビュー、CI/CD パイプラインといったソフトウェア開発でよく知られるプラクティスを使って IT インフラを管理することを含みます。たとえば、GitOps を実践するインフラチームはコードとして保存される構成ファイルを使用します。アプリケーションのソースコードがビルドされるたびに同じアプリケーションバイナリを生成するのと同様に、GitOps の構成はデプロイされるたびに同じインフラ環境を生成します。

• IaC - GitOps はインフラ定義の単一の情報源として Git リポジトリを使用します。Infrastructure as Code (IaC) はすべてのインフラ構成をコードとして保存するプラクティスです。実際の望ましい状態（レプリカ数、Pod 数など）はコードとして保存される場合とされない場合があります。
• MRs - GitOps はすべてのインフラ更新の変更メカニズムとして マージリクエスト (MR) を使用します。MR はチームがレビューやコメントを通じて協業し、正式な承認が行われる場所です。master（または trunk）ブランチへのマージコミットは、監査やトラブルシューティングのための変更ログとして機能します。
• CI/CD - GitOps は継続的インテグレーションと継続的デリバリー (CI/CD) を伴う Git ワークフローを使ってインフラの更新を自動化します。新しいコードがマージされると、CI/CD パイプラインが環境内で変更を実行します。手動変更やエラーといった構成のドリフトは GitOps 自動化によって上書きされ、環境は Git で定義された望ましい状態に収束します。GitLab は GitOps 自動化を管理・実装するために CI/CD パイプラインを使用しますが、定義オペレーターのような他の自動化形式も使用できます。

新興の技術用語と同様、「GitOps」は業界全体で誰もが厳密に同じ定義をしているわけではありません。GitOps はクラウドネイティブコミュニティで生まれたもので、一部の定義は GitOps を「Kubernetes が GitOps を行うために必要」と限定します。GitLab はより広いアプローチを取ります。GitLab ユーザーやお客様が、VM、コンテナ、Kubernetes クラスターを含むあらゆるタイプのインフラ自動化に GitOps の原則を適用しているのを見てきました。

多くのツールや方法論がより速いデプロイメントとコードとインフラ間のシームレスな管理を約束する一方で、GitOps は開発者中心の体験に注力する点で異なります。GitOps を介したインフラ管理は、アプリケーション開発と同じバージョン管理システムで行われ、Git の組み込み機能の恩恵を受けながら、チームが中央の場所でより協業できるようにします。

GitOps は Infrastructure as Code を使用するための処方箋的なワークフローです。GitLab を使った GitOps は、Terraform、AWS Cloud Formation、Ansible、Chef、Puppet などの業界をリードするインフラ自動化ツールとの緊密な統合により、物理、仮想、クラウドネイティブインフラ（Kubernetes やサーバーレス技術を含む）を管理するのに役立ちます。

GitOps のメリット

• 作業の分散 - より多くのエンジニアがインフラ変更で協業できるようにします。すべての変更が同じ変更／マージリクエスト／レビュー／承認／マージプロセスを経るため、シニアエンジニアは必要に応じてレビュー・貢献する能力を維持しつつ、重要なインフラ管理を超えた他の領域に集中できます。
• アクセス制御の改善 CI/CD だけが必要なアクセス権を使って変更を自動化するため、すべてのインフラコンポーネントに認証情報を与える必要がありません。
• 市場投入時間の短縮 - コードによる実行は手動でのポイント＆クリックよりも速く、テストケースは自動化でき、一貫した方法で繰り返し実行できるため、安定した環境を大規模に迅速に提供可能
• リスクの低減 Infrastructure as Code へのシフトレフトアプローチは、変更が本番にロールアウトされる前に問題を特定・解決し、予期せぬダウンタイムを未然に防ぎ、より高い環境の安定性と信頼性、より良いユーザー体験を提供します。
• コンプライアンス向上 インフラへのすべての変更が追跡され、監査のためのトレーサビリティと、以前の望ましい状態に容易にロールバックする能力を残します。
• コスト削減 - インフラ定義とテストの自動化が手作業と再作業を排除して生産性を向上させ、ロールバック機能の組み込みによりダウンタイムを削減
• エラー低減 - インフラ定義はコード化されるため、再現可能で人為的エラーが起きにくい

プッシュ vs プル GitOps（エージェントレス vs エージェントベース GitOps）

新興技術と同様、GitOps には異なるアプローチがあり、それぞれに長所と短所があります。

プッシュ型またはエージェントレス GitOps このアプローチでは、CI/CD ツールが環境に変更をプッシュします。このアプローチはアプリケーションデプロイメントで使われるアプローチと一貫しています。 長所

• 使いやすさ。よく知られた CI/CD - ビルド、テスト、デプロイがすべて同じ技術を使用
• デプロイ先がクラウドネイティブ／Kubernetes に限定されない - 物理、仮想、コンテナ、オンプレミスでもクラウドでもデプロイ可能 短所
• ファイアウォールをクラスターに開け、外部 CI/CD に管理者権限を付与する必要がある

プル型またはエージェントベース GitOps このアプローチでは、エージェントがクラスターにインストールされ、望ましい構成からドリフトがあった際に変更をプルします。 長所

• セキュアなインフラ - ファイアウォールを開けたり外部に管理者権限を付与したりする必要がない 短所
• すべてのクラスターにエージェントをインストールする必要がある
• k8s 限定
• アプリケーション CI/CD とは異なる技術を使用する

ペルソナ

ユーザーペルソナ

Infrastructure as Code はプラットフォームの理解とアプリケーション環境の望ましい状態の理解を必要とします。Infrastructure as Code のユーザーは、SCM ツールとしての Git と、プロビジョニング・管理を期待されるプラットフォームの両方をよく理解しています。以下に Infrastructure as Code の主なパワーユーザーをいくつか挙げます。

• Sam, SRE Sam は機能開発者と同じサービスチームに組み込まれて働きます。サービスを稼働させ続け、デプロイし、そのサービスのインフラニーズを管理する作業を行います。プラットフォームチームと協力してベストプラクティスを体系化します。

• Devon, DevOps エンジニア Devon は開発チームに対する Ops のインターフェースを担当することが多いです。インフラ、環境、統合のサポートを提供します。Devon はコードに精通しており、多数の異なるツールやコンテキストスイッチではなく、コードを通じてインフラを管理することを好みます。

• Priyanka, プラットフォームオペレーター インフラ管理はプラットフォームチームの主な責任の一つです。Priyanka は、開発チームがソフトウェアをより迅速に出荷・運用するために活用する共有プラットフォーム（伝統的なものまたは現代のクラウドプラットフォーム）の提供、保守、運用に責任を持っています。

• Sydney, システム管理者 Sydney はアプリケーションチームのインフラと構成を定義、保守、スケールします。同じタスクに対する繰り返しの依頼を受けることがしばしばあります。Sydney の主な動機は、エラーを最小限に抑え時間を節約するために繰り返しのタスクを自動化すること、そしてインフラと構成を変更が追跡される方法で定義し、インフラ変更がワイルドウェスト になるのを止めることです。

バイヤーペルソナ

Infrastructure as Code のバイヤーは通常、インフラ／自動化施策をリードするリーダーです。典型的なバイヤーペルソナは次のとおりです。

• CIO / Vice President of IT - デジタルトランスフォーメーションプログラムの計画、設計、実行、新しい運用モデルの実装の経験を持つ。通常、エンジニアリングと運用の両チームをリードする
• Vice President of IT Infrastructure（一部の組織では IT Operations と呼ばれる）- IT インフラサービス（クラウドサービスのデプロイ・管理、システム管理、Service Desk を含む）の計画、設計、実行の経験を持つ。組織の IT コスト削減を頻繁に課題とする。
• Vice President of Platform Engineering - 開発チーム向けの共有プラットフォームを管理することがプラットフォームエンジニアリングチームの主要なアジェンダの一つ。プラットフォームチームは Kubernetes のような新技術の専門知識を持っています。プラットフォームエンジニアリングチームの主要 KPI は自動化、効率、セルフサービスです。

アナリストカバレッジ

このユースケースの主要なアナリストカバレッジを列挙します

市場要件

GitOps の市場要件 は以下のとおりです

コラボレーションの促進

• 説明: ソリューションはチームメンバー間のコラボレーションを可能にし、促進するように設計されています。コラボレーションシステムには手動のゲートと承認、自動化されたワークフローが含まれます。

• 典型的な機能:

  • 一般的なコメントの追加
  • 個人またはグループのタグ付け
  • コードへのインラインコメントの追加
  • 提案の追加
  • 上部に未解決スレッドの合計を表示
  • コメント／提案を解決するまでマージできないことを表示
  • スレッドの解決
  • 新しい Issue を作成してスレッドを解決
  • 提案を適用（提案の受け入れ）
  • Code Owner の表示
  • 承認の表示

• その他の機能

  • プロジェクトの新しいブランチを素早く作成
  • 新しいファイル／アセットの追加
  • 提案された変更で協業（コメントレビュー、変更提案、Web IDE、提案承認、コンフリクト解決、マージ、差分、引き継ぎ）
  • ワークフロー自動化
  • Wiki スニペット
  • バージョン管理されたスニペット
  • マージリクエストがマージされたとき関連する Issue を自動的に更新または閉じる
  • 構成可能な Issue クローズパターン
  • CI システムでビルドのマージリクエストステータスを表示
  • Terraform plan の出力
  • セキュリティスキャンとビルド統計の可視化

• 価値: 行われるコード変更の品質が向上し、それが以下につながります

  • 満たされる依頼の精度の向上
  • インフラ安定性の向上
  • そしてリリース速度の向上 チームレビューと検証を通じて。

コンプライアンスと監査

• 説明: 本番へのすべての変更が自動化され、Git ブランチへのマージで管理されます。Git 管理ツールを通じて権限とアクセスが組み込まれています。 承認とマージアクセスは特定の人員またはグループに制限可能。 コミット履歴は変更ログを示します。
• 典型的な機能: CMR/PR、コードレビュー機能、RBAC、ブランチ権限、グループ権限設定、CodeOwner、MR 承認
• 価値: インフラ用に別の権限を管理する必要がなく、開発プロセスのものと一致できます。 内部および規制コンプライアンス標準への厳格な順守。 監査時間が短くなり、実施しやすくなります。 インフラへの変更がロックダウンされているため、よりセキュアになります。 \

バージョン管理された環境

• 説明: 環境の状態が Git バージョン管理下のテキストとして定義されている場合、環境をロールバック・ロールフォワードできる能力。

テスト自動化

• 説明: 自動テストを実行・管理し、本番にマージされる前に変更を検証します。これは基本的なテストからより詳細なテストまですべてを含み、機能、システム、パフォーマンステストなどの領域にテスト自動化を拡張します。手動介入なしにソフトウェアが技術的・ビジネス的要件を一貫して満たすようにテストされ、開発者がコード変更が潜在的な欠陥や脆弱性を導入していないか素早くフィードバックを得られるようにします。
• 典型的な機能: 隔離された一時的な環境で CI/CD パイプラインの自動テストを実行する能力。様々なテストには、ユニットテスト、コード統合テスト、回帰テスト、静的コード解析、機能テスト、アクセシビリティテストなどが含まれる場合があります（これらに限定されない）。アプリケーションコード向けのほとんどのテストタイプは、インフラ、ポリシーなどあらゆるコードにも適用されます。
• 価値: 潜在的なエラーが本番に影響する前に、後ではなく早期に検出。 本番に行く前に潜在的な脆弱性をテストすることでセキュリティを向上。

パイプライン構成管理

• 説明: エンジニアはビルドとテストワークフローを自動化でき、特にソースコードリポジトリへの接続、ビルドパイプラインでの特定のアクション／タスクの定義、ジョブの実行方法／タイミングのパラメーター設定を、スクリプトおよび／または GUI を使ってパイプラインの変更を構成できます。構成は再現可能でトレーサブルで、環境変更を素早く比較・追跡できます。
• 典型的な機能: Web UI による構成、または YAML のような人間が読めるシンタックスで config-as-code をサポート。 パイプラインテンプレート。プロジェクトテンプレート。 パイプラインリンク - 中央リポジトリにパイプラインテンプレートを保存 パイプライン依存関係 - 子／親、上流／下流
• 価値: 開発時間を最大化し生産性を向上。手作業の削減。 管理を一元化して運用を低減。 テンプレートを使用してベストプラクティスと必須テストを順守することで一貫性を向上。

GitLab のソリューション

GitLab が市場要件を満たす方法

GitLab の GitOps 機能を示す短いデモのコレクション。

市場要件	GitLab がどう実現するか	GitLab ステージ／カテゴリー	デモ
コラボレーションの促進	ディスカッション、ユーザータグ付け、一般コメント、インラインコメント、インライン提案、未解決スレッド追跡、コメントからの Issue 作成、提案管理、CODEOWNERS、承認	Discussions、CODEOWNERS、MR approvals	Foster Collaboration with GitOps
コンプライアンスと監査	コンプライアンステストと監査制御は GitLab の CI/CD パイプラインに組み込まれています。	Compliance at GitLab Manage Stage: Audit Events、Audit Logs、Audit Reports、Compliance Management、Release Evidence、Chain of Custody、きめ細かなユーザーロールと権限、職務分掌 Secure Stage: License Compliance、Dependency Scanning CODEOWNERS、MR approvals、
バージョン管理された環境	GitLab のバージョン管理を使って XaC（インフラ、ポリシー、構成など）を保存することで、変更を追跡できます。さらに、失敗時の自動ロールバックにより、前回の成功したデプロイにロールバックできます	Environment Rollback、GitLab Agent for Kubernetes
テスト自動化	パイプラインの一部としてユーザビリティ、パフォーマンステストを含み、問題があった場合は成功したデプロイにロールバック	リリースバージョニング、高度なデプロイ戦略（Canary、インクリメンタルロールアウト、Blue/Green デプロイなど）のサポート、Feature Flag、Review App、パフォーマンステストと検証
パイプライン構成管理	GitLab Pipeline Authoring により、ユーザーは必要に応じて最小限の構成でパイプラインを作成でき、複雑なパイプラインの作成と可視化も可能です。これにより、インフラエンジニアは手作業を最小限にし、再現可能なプロセスを作成して生産性を最大化できます	パイプライン構成、パイプライン構成のタイプ

トップ 3 差別化要因

メッセージハウス

ユースケースのメッセージハウスは、ユースケースの価値と差別化要因を記述・議論するための構造を提供します。

現在のメッセージングは、このページの市場の視点 セクションと、GitOps とは何か？ に答えるトピックページに加え、ここでの追加メモにあります。

「インフラストラクチャプラットフォーム」は GitOps と GitLab に関連して使用するのに優れたフレーズです。私たち自身を実体と異なるものとして示してしまわないよう、慎重に使う必要があります。過去には、Chef、Ansible、Terraform と類似の機能を持っていると主張したことで指摘を受けたことがあります。GitLab はそれらの機能を内部に持つのではなく、これらのツールとの統合を目指しています。GitLab が統合を通じてインフラプラットフォームの機能を提供していることを明確にしておけば、I&O バイヤーに響く強力なメッセージングが得られます。トピックページの使用例 を参照してください

ディスカバリー質問

• インフラチームは構成、ポリシー、変数などをインフラ全体で一貫してどのように管理していますか？
• インフラに加えられた変更をどのように追跡できていますか？
• ステージング／本番環境への影響を最小限にするため、適切な人物によるレビュー・承認を保証できていますか？
• 環境コンソールへのアクセス権を何人が持っていて、コンソール内での変更を一貫して追跡できていますか？ 例: エンジニアが AWS / GCP コンソールにログインして応急処置のために変更を加える。
• 監査要件として不可欠な、すべてのインフラ変更のコンプライアンス証拠をどのように示せますか？
• 環境内の問題からどれくらい速く復旧でき、最後に成功したデプロイにロールバックできますか？
• インフラチームは環境のセットアップ手順を毎回一貫して繰り返せますか？
• インフラチームと開発チームが異なるツールを使っていて、両チーム間のコラボレーションを減らしていませんか？
• 複数のクラウドにまたがる継続性とツールの最小化を確保するために、インフラポリシーと構成を複数クラウドに一貫してデプロイできますか？
• 一部のお客様は構成ファイルがアドホックに保存されていることに苦労していると聞きます。構成ファイルをどのように管理していますか？
• 多くのお客様は環境を管理する複数のインフラ管理者を持っています。複数の人が環境への変更を行うアクセスを持っているとき、本番ダウンタイムの根本原因をどのように追跡できますか？
• インフラのセットアップと保守作業はどのくらい手作業で、繰り返し作業が多いですか？
• エンジニアはインフラのセットアップと保守にどれくらい時間を費やしていますか？ そのうち繰り返し作業はどれくらいですか？
• エンジニアはワークフローにどれくらい満足していますか？ どの領域を改善したいですか？
• 環境への手動変更によりどれくらいの生産性が失われていますか？
• 御社はより多くの自動化を支持してインフラワークフローの改善に関心がありますか？
  • なぜ御社にインフラ自動化が必要だと考えていますか？
  • 現在のインフラワークフローでどのような障害に遭遇していますか？
• インフラエンジニアが現在のステージング／本番環境に変更を加える際のワークフローはどのようなものですか？
• 新しいインフラワークフローのセットアップに現在どれくらい時間がかかりますか？ これらのワークフローはどれくらい繰り返し作業ですか？

反論への対応

競合比較

ArgoCD

ArgoCD は Kubernetes 用 GitOps デプロイメントのオープンソースソリューションです。Intuit によって開始され、現在は CNCF インキュベーションプロジェクト です。Argo Project ファミリ製品の一部です。

ArgoCD は GitLab Agent for Kubernetes と直接競合します。

ArgoCD は GitLab と一緒に動作します。GitLab CI/CD で実行されるビルド・セキュリティステップを補完できます。

Weaveworks - Flux OSS オペレーター使用

Flux は Kubernetes 向け継続的・漸進的デリバリーのオープンソースソリューションです。Flux は Weaveworks で始まり、現在は CNCF インキュベーションプロジェクトです。GitOps 用 WeaveWorks Cloud ソリューションの一部です。

WeaveWorks Cloud ソリューションは GitLab と一緒にも動作します。GitLab SCM と CI が Flux CD と連携して GitOps ソリューションを作成します。

業界アナリストリレーションズ (IAR) プラン

• IAR ハンドブックページは、アナリストとの会話にユースケースを取り入れる 計画を反映するよう更新されています。
• 各ユースケース固有の詳細、および業界アナリスト企業との契約上の機密保持義務を尊重し、エンゲージメント計画は GitLab チームメンバーに対し以下の保護されたドキュメントで提供されます。IAR Use Case Profile and Engagement Plan。

このユースケースに関する GitLab の機能を現在理解しているアナリストの一覧は、Slack（#analyst-relations）または Issue を作成して “AR-Analyst-Validation” テンプレートを選択することで Analyst Relations にお問い合わせください。

採用推奨

この表は、採用すべきユースケース、製品ドキュメントへのリンク、ユースケースに対応するサブスクリプションティア、製品分析メトリクスを示しています。

証跡 - 顧客

引用とレビュー

• 動画: kiwi.com の Infrastructure as Code - kiwi.com が GitLab と Terraform を使ってインフラをコードとして管理する方法を学びます。ボーナス情報 - GitLab CI/CD と Infrastructure as Code を使ってセルフホスト GitLab インスタンスをデプロイする方法もご覧ください
• 動画: VMWare - GitLab と Terraform Cloud を使った Infrastructure as Code - GitLab と Terraform はしばらく前からうまく連携しており、VMWare がどのように GitLab CI/CD と Terraform Cloud を使ってインフラをコードとして管理しているかを学びます
• 動画: ValidaTek の DevOps と Infrastructure as Code の旅 - ValidaTek は米国連邦政府のあらゆる分野（民生、軍事、IC）と協業しています。クライアントのインフラを管理するために GitLab をどのようにセットアップしたかをご覧ください。

Gartner Peer Insights

「リリースとバージョンを管理するのに非常に効率的なツール。当社には開発・デプロイプロセスがあり、すべての段階で [GitLab] が関わっています。開発コードの保存に加え、すべてのパッケージングとデプロイスクリプトを git に保存しています」

• Full-stack Developer, Gartner Peer Insights Review

「最後に、GitLab で最も素晴らしいのは、GitLab エコシステムがいかに統合されているかです。VCS から CI、デプロイメントまで、開発のほぼすべてのステップを見事にカバーしています。」

• Software Engineer, Gartner Peer Insights Review

「GitLab は世界で最も好まれるサービスで、ユーザーコミュニティは非常に幅広いです。GitLab ではプロジェクトまたはブランチベースのユーザー認可ができます。さらに、継続的デプロイメント統合を非常に素早く行えます。希望する制約内でマージリクエストを作成し、簡単に管理できます。コンフリクトを防ぐのも非常に簡単です。ソフトウェア開発チームに必須のサービスです。」

• Software Development Lead, Gartner Peer Insights Review

ケーススタディ

-Northwestern Mutual

• 課題 手動プロセス、オンプレミスデータセンターからのリソースプロビジョニングが非効率なプラクティスを生んでいた。
• ソリューション GitLab Premium (SCM, CI) と Terraform
• 結果 本番投入までのリードタイムを大幅に改善、環境を 1 時間以内に作成可能。すべてがコードとして実行され、パッチによるリスクがない。
• 販売セグメント: エンタープライズ

-Wag Labs

• 課題 複雑な CI ツールチェーンの制御不足。
• ソリューション GitLab Ultimate (SCM, CI, CD) と Terraform
• 結果 何かをデプロイし、問題があればロールバックするのが非常に簡単。本番へのデプロイから不安と恐怖が取り除かれた。
• 販売セグメント: ミッドマーケット

クロージングを支援するリファレンス

• GitOps と GitLab を使用しているお客様を見つける

パートナー

GitLab は既存のインフラ自動化ツールを置き換えるものではなく、それらを補完して包括的なソリューションを提供します。JetBrains DevOps Ecosystem 2019 調査によると、Terraform はお客様が使用する最も人気のあるインフラプロビジョニングツールです。Terraform はクラウドに依存せず、分散アプリケーション向けの複雑なインフラの管理に役立ちます。GitLab は包括的な GitOps ソリューションの構築に向けた最初のステップとして、Terraform サポートに注力 します。

リソース

プレゼンテーション

• GitOps Industry Talk - GitOps とは何か？ なぜ重要なのか？ どう始められるか？ - スライドデッキ、動画

Web ページ、ホワイトペーパー、インフォグラフィック、ブログ

• What is GitOps?
• Infrastructure as Code using GitLab & Ansible
• Part 1 of 3: Why collaboration technology is critical for GitOps
• Part 2 of 3: How infrastructure teams use GitLab and Terraform for GitOps
• Part 3 of 3: How to deploy to any cloud using GitLab for GitOps

動画（基本的なデモ動画を含む）

• What is GitOps? Why is it important? How can you get started?
• What is Infrastructure as Code
• Infrastructure as Code using GitLab & Ansible
• Part 1 of 3: How GitLab supports GitOps: The Process
• Part 2 of 3: How GitLab supports GitOps: The Infrastructure
• Part 3 of 3: How GitLab supports GitOps: The Application
• GitOps with GitLab and Terraform
• Using GitLab for GitOps to break down silos and encourage collaboration

クリックスルー & ライブデモ

• GitOps Click Through Demo

バイヤーズジャーニー

バイヤーズジャーニーの主要ページのインベントリ

ページのソースコードを見る - ページの編集 - please contribute.