• Fluxへのマイグレーション
• GitOps ワークフローのステップ
• GitOps設定リファレンス
• GitOpsアノテーション
• 自動ドリフト修正
• 関連するトピック
• トラブルシューティング
  • 複数のプロジェクトがある場合の競合の回避
  • 複数のエージェントまたはプロジェクトを使用します。

Kubernetes用エージェントでGitOpsを使う（非推奨）

• GitLab 13.7 で導入されました。
• GitLab 14.0 で導入され、resource_inclusions とresource_exclusions 属性が削除され、reconcile_timeout,dry_run_strategy,prune,prune_timeout,prune_propagation_policy,inventory_policy 属性が追加されました。
• 15.3でGitLab PremiumからGitLab Freeに移動しました。
• GitLab 15.7 でid 属性をオプションに変更しました。
• GitLab 15.7で導入されたKubernetesマニフェストファイルをフェッチするためにブランチ、タグ、またはコミットリファレンスを指定。

この図は、GitOpsのデプロイにおけるリポジトリと主なアクターを示しています：

詳細はアーキテクチャ・ドキュメントをご覧ください。

Fluxへのマイグレーション

レガシー GitOps デプロイメントを Flux でデプロイできるようにマイグレーションする必要があります。マイグレーションするには、KustomizeでマニフェストをデプロイするようにFluxを設定します。指定したパスにkustomization.yaml ファイルがない場合は、自動的に生成されます。

前提条件：

• のような設定：

   manifest_projects:
   - id: my-group/my-project
     default_namespace: production
     paths:
     - glob: 'environments/production/**/*.yaml'
  

• environments/flux-system にマニフェストを持つFlux インストール。
• デプロイトークンを使ってGitLabにアクセスします。
• クラスターはHTTPSでGitLabにアクセスできます。

マイグレーションするには

1. environments/flux-system/production.yaml というファイルを以下の内部内容で作成します：

   # This manifest was generated by flux. DO NOT EDIT.
   ---
   apiVersion: source.toolkit.fluxcd.io/v1
   kind: GitRepository
   metadata:
     name: production
     namespace: flux-system
   spec:
     interval: 1m0s
     ref:
       branch: main
     secretRef:
       name: gitlab-deploy-token
     url: https://gitlab.example.com/my-group/my-project.git
   ---
   apiVersion: kustomize.toolkit.fluxcd.io/v1
   kind: Kustomization
   metadata:
     name: production
     namespace: flux-system
   spec:
     interval: 10m0s
     path: ./environments/production
     prune: true
     sourceRef:
       kind: GitRepository
       name: production
   

2. オプション。agentk はデフォルトでdefault_namespace を使用するため、/environments/production/ にkustomization.yaml ファイルを追加し、関連リソースをリストする必要があるかもしれません。例えば

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   namespace: default
   resources:
   - relative/path/to-your/resource-1.yaml
   - relative/path/to-your/resource-2.yaml
   

   kustomization.yaml ファイルをリポジトリにコミットすると、Flux とのリコンサイルがagentk 発生 agentkします。Kustomization ファイルを扱えないagentk ため agentk、ファイルをコミットするとエラーが記録されます。

3. Fluxがリソースの管理を引き継いだことを確認するには、production Flux Kustomizationオブジェクトのstatus.inventory の値でリソースを確認してください：

   kubectl get kustomization production -n flux-system -o json | jq '.status.inventory.entries'
   

4. manifest_projects リストからエントリを削除します。

マイグレーション後、GitOpsデプロイはFluxでデプロイされます。Fluxインテグレーションを最大限に活用するには、Flux Kustomization CRDと GitLab Fluxドキュメントを参照してください。

GitOps ワークフローのステップ

GitOpsを使用してKubernetesクラスターを更新するには、以下の手順を実行します。

1. 稼働中のKubernetesクラスターがあり、マニフェストがGitLabプロジェクトにあることを確認します。
2. 同じプロジェクトで、GitLabエージェントを登録し、インストールします。
3. エージェントがKubernetesマニフェストの変更をプロジェクトで監視するように、エージェント設定ファイルを構成します。GitOps設定リファレンスを参考にしてください。

Kubernetesマニフェストの更新をコミットすると、エージェントはクラスターを更新します。

GitOps設定リファレンス

次のスニペットは、エージェント設定ファイル(config.yaml) の GitOps セクションで使用可能なキーと値の例を示しています。

gitops:
  manifest_projects:
  - id: gitlab-org/cluster-integration/gitlab-agent
    ref: # either `branch`, `tag` or `commit` can be specified
      branch: production
      # commit: <mysha>
      # tag: v1.0
    default_namespace: my-ns
    paths:
      # Read all YAML files from this directory.
    - glob: '/team1/app1/*.yaml'
      # Read all .yaml files from team2/apps and all subdirectories.
    - glob: '/team2/apps/**/*.yaml'
      # If 'paths' is not specified or is an empty list, the configuration below is used.
    - glob: '/**/*.{yaml,yml,json}'
    reconcile_timeout: 3600s
    dry_run_strategy: none
    prune: true
    prune_timeout: 3600s
    prune_propagation_policy: foreground
    inventory_policy: must_match

GitOpsアノテーション

Kubernetes用のGitLabエージェントには、以下のようなアノテーションがあります：

• リソースの並べ替え：リソースを特定の順序で適用または削除します。
• 適用時変異の使用：あるリソース設定から別のリソース設定にフィールドを動的に置換します。

エージェントにはデフォルトのソートがありますが、アノテーションを使用することで、順序を微調整し、時間値注入を適用することができます。

GitOps機能を提供するために、Kubernetes用のGitLabエージェントはKubernetes SIGプロジェクトのcli-utils ライブラリ](https://github.com/kubernetes-sigs/cli-utils/blob/master/README.md) を使用しています。詳細については、[ cli-utils ドキュメントの利用可能なアノテーションを参照してください。

自動ドリフト修正

ドリフトは、インフラストラクチャリソースの現在の設定が目的の設定と異なる場合に発生します。一般的に、ドリフトは、使用されている infrastructure-as-code メカニズムではなく、リソースを手動で直接編集した場合に発生します。ドリフトのリスクを最小限に抑えることで、設定の一貫性を確保し、オペレーションを成功に導くことができます。

GitLabでは、Kubernetes用のエージェントが、git リポジトリからの git望ましいgit 状態とKubernetesクラスターからの実際の git状態を定期的に比較します。git 状態からの逸脱は gitチェックのたびに修正されます。これらのチェックは5分ごとに自動的に行われます。設定はできません。

エージェントはサーバサイドで適用されます。その結果、リソース内のすべてのフィールドは異なるマネージャを持つことができます。git によって管理されるフィールドだけがドリフトのチェックを受けます。これにより、Horizontal Pod Autoscalersのようなリソースを変更するためのクラスタ内コントローラの使用が容易になります。

関連するトピック

• トレーニングやデモのための GitOps 作業例
• セルフペースのクラスルームワークショップ（AWS EKSを使用しますが、他のKubernetesクラスタにも使用できます。）
• GitOpsワークフローにおけるKubernetesシークレットの管理
• アプリケーションとマニフェストのリポジトリ例

トラブルシューティング

複数のプロジェクトがある場合の競合の回避

エージェントは、プロジェクトのpaths セクションで設定されている各グロブ・パターンを個別に監視し、クラスターを同時に更新します。複数のパスで変更が見つかった場合、エージェントがクラスターを更新しようとすると競合が発生する可能性があります。

これを防ぐには、グロブの重複を避けるために、マニフェストの論理的なグループを 1 つの場所に格納し、それらを 1 回だけ参照することを検討してください。

たとえば、これらのグロブは両方ともルート・ディレクトリの*.yaml ファイルに一致するため、競合が発生する可能性があります：

gitops:
  manifest_projects:
  - id: project1
    paths:
    - glob: '/**/*.yaml'
    - glob: '/*.yaml'

代わりに、すべての*.yaml ファイルに再帰的に一致する 1 つのグロブを指定します：

gitops:
  manifest_projects:
  - id: project1
    paths:
    - glob: '/**/*.yaml'

複数のエージェントまたはプロジェクトを使用します。

Kubernetesマニフェストを別々のGitLabプロジェクトに保存している場合は、これらのプロジェクトの場所でエージェント設定ファイルを更新してください。