GitOpsを拡張：Kubernetes上での努力のいらない継続的統合と展開

導入：

この10年で、ソースコードを提供するプロセスに notableの変化がありました。展開の側面での最近の適応は、アプリケーションの望ましいインフラ状態と設定の声明的かつバージョン管理された説明であり、これは一般的に 'GitOps' と呼ばれています。このアプローチは、複雑で分散したシステムを管理することが挑戦的な場合がある、クラウドネイティブアプリケーションやKubernetesのようなコンテナオーケストレーションプラットフォームにおいて人気を博しています。

この望ましい状態は宣言的な性質を持っており、そのアプリケーションの特定/静的なバージョンを指します。これには特に、変更を行う前にそれらを監査できること、以前の状態に戻すことができること、再現可能なセットアップが維持されていることなどの顕著な利点があります。アプリケーションの状態/設定に変更を加えるためのパイプラインを必要とせずに、手作業でバージョン調整を避けながらもっと新しいバージョンのアプリケーションに移行するにはどうすれば良いのでしょうか？

ここでArgo CD Image Updaterが登場します。これはコンテナイメージの新しいバージョンが利用可能かを確認し、続いてアプリケーションのKubernetesリソースの必要な更新をトリガーするか、関連するバージョン管理にこれらの変更をオプションで行います。

概観：

技術的実装に深く潜る前に、GitOpsプロセスの概観を確立し、このプロセス内でのArgo CD Image Updaterの役割を詳しく見てみましょう。

デフォルトのGitOps

プロセスの最初の部分は、開発者がアプリケーションのソースコードを変更し、変更をバージョン管理システムに戻すことから始まります。その後、アプリケーションを構築し評価するワークフローやパイプラインが開始されます。成果物はコンテナイメージの形で提供され、次にイメージレジストリにプッシュされます。

二番目の - 分離された - プロセスの部分では、クラスタ構成リポジトリがアプリケーション設定の_望ましい状態_に関しての唯一の真実の源です。Argo CDは定期的にKubernetesクラスタを監視して、_ライブ状態_が_望ましい状態_と異なるかどうかを確認します。差異がある場合、Argo CDは同期戦略に応じて_望ましい状態_に戻そうとします。

拡張されたGitOps

デフォルトのプロセスと比較して、この拡張されたバリアントでは別のArgo CDコンポーネントがKubernetesクラスタに追加されます。Argo CD Image Updaterコンポーネントは、イメージレジストリ内にコンテナイメージの新しいバージョンがあるかどうかを確認します。そのようなバージョンが見つかると、コンポーネントは直接または間接的に実行中のアプリケーションをアップデートします。次のセクションではArgo CD Image Updaterの設定オプションとコンポーネントの実装について詳しく見ていきます。

設定：

技術的実装を行う前に、Argo CD Image Updaterが提供する設定オプションについて知っておくことが大切です。この設定はwrite back methodとupdate strategyの2つの概念で見つかります。どちらも特定の状況に合わせたオプションがあるので、オプションが何であるか、そしてそれが技術的実装とどう関係しているかを理解することが重要です。

この設定/デモンストレーションでは、以下のリポジトリを参照できます。

• bookstore-application
• bookstore-cluster-configuration

Write Back Methodについて

この記事を書いている時点で、Argo CD Image Updaterはイメージの新しいバージョンをArgo CDに伝播するための2つの方法をサポートしています。これらの方法はargocdとgitと呼ばれています。

• argocd: このデフォルトの_write back_メソッドは疑似永続的です - アプリケーション削除やバージョン管理での設定の同期の際に、Argo CD Image Updaterによってアプリケーションへ行われた変更は失われます - これは命令的に作成されたリソースに最適です。このデフォルトメソッドには追加の設定は必要ありません。

• git: もう1つの_write back_メソッドは、永続的/宣言的なオプションです。新しいバージョンのコンテナイメージが見つかると、Argo CD Image Updaterはそれをアプリケーションのリソースマニフェストとともにパラメータオーバーライドとして保存します。.argocd-source-<アプリケーション名>.yamlという名前のファイルにオーバーライドを保存し、アプリケーションのリソースマニフェスト内でのマージ競合のリスクを減らします。_write back_メソッドを変更するには、Argo CDのApplicationリソースにアノテーションを設定する必要があります。さらに、アプリケーションの.spec.source.targetRevisionのデフォルト値からコミット先のブランチをオプションで変更できます。

  監査の履歴および再現可能な観点から、これが望ましいオプションです。これにより、GitOpsの知られているこれらの側面を維持しながら、自動的な継続的デプロイのオプションが提供されます。

argocd-image-updater.argoproj.io/write-back-method: git

    > **注:**  
    > `git` write backメソッドを使用するとき、Argo CDで設定された資格情報が再使用されます。専用の資格情報セットを提供することもでき、これと他の設定は[ドキュメント](https://argocd-image-updater.readthedocs.io/en/stable/basics/update-methods)で見つけることができます。

### 更新戦略について

どの_write back_メソッドを使用するかを決めたら、更新戦略を決める必要があります。この戦略は、更新されるべきイメージの新しいバージョンをArgo CD Image Updaterがどのように見つけるかを定義します。現在、`semver`、`latest`、`digest`、`name`の4つの方法がサポートされています。

それぞれの違いを見る前に、`mutable`イメージタグと`immutable`イメージタグについて知っておく必要があります。変更可能なリポジトリは、新しいイメージによってタグが上書きされる可能性があるものですが、タグが不変であるとリポジトリ設定で述べられている場合は、新しいイメージによって上書きされることはありません。以下のオプションから、各オプションでは不変のタグが使用されていることを期待しています。変更可能なタグを使用している場合、digest戦略を使用するべきです。

*   `semver`: イメージレジストリ内のアプリケーションの最新バージョンに更新しながら、セマンティックバージョニングの制約を考慮します - `X.Y.Z`の形式に従います。ここで、`X`はメジャーバージョン、`Y`はマイナーバージョン、`Z`はパッチバージョンです。このオプションは、新しいマイナーやパッチバージョンへのみアップグレードするように設定することができます。また、追加の設定を通じてプレリリースバージョンもサポートしています。以下の例では、アプリケーションはより新しいパッチバージョンに更新されますが、新しいマイナーやメジャーバージョンが存在するときにはアップグレードしません。

    ```
argocd-image-updater.argoproj.io/<alias>.update-strategy: semver
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>[:<version_constraint>]

• latest: アプリケーションを最も新しいビルド日付のイメージで更新します。特定のビルドに複数のタグがある場合、Argo CD Image Updaterはリストの最後のタグを辞書順に降順で並べ替えたものとします。もしあるタグだけを考慮に入れたい場合は、正規表現を使用したアノテーションを使用できます。同様に、タグのリストを無視するためのアノテーションも使用できます。

argocd-image-updater.argoproj.io/<alias>.update-strategy: latest
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>

    
*   `digest`: レジストリ内の変更可能なタグに基づいてアプリケーションを更新します。この戦略を使用する場合、イメージのダイジェストを使用してアプリケーションを更新し、そのためクラスター内のイメージは`<repository-name>/<image-name>:<tag_name>`として表示される代わりに`<repository-name>/<image-name>@sha256:<hash>`と表示されます。

    ```
argocd-image-updater.argoproj.io/<alias>.update-strategy: digest
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>:<tag_name>

• name: イメージタグの辞書順ソートに基づいてアプリケーションを更新し、並べ替えリストの最後のタグを使用します。これはイメージのタグ付けに日付/時間を使用する場合に利用できます。latest戦略と同様に、特定のタグのみを考慮するための正規表現を使用できます。

argocd-image-updater.argoproj.io/<alias>.update-strategy: name
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>

実装：
------

最初に、前述の概要で見られるように、`source code`と`cluster configuration`の2つのリポジトリを作成します。理論上両方とも同じリポジトリに収容できますが、関心の分離が推奨されています。

次のステップは、継続的デプロイメントプロセスの開始点となるアーティファクト、すなわちコンテナイメージを作成するための継続的統合パイプラインを設定することです。このウォークスルーでは、リポジトリにGitHubを、パイプラインにGitHub Actionsを使用します。しかし、この設定はほとんどの一般的なバージョン管理/パイプラインオプションで作成できます。

### 継続的統合ワークフロー

ソースコードリポジトリの`.github/worksflows/`ディレクトリの下で、 `continuous-integration.yaml`と名付けたGitHubアクションワークフローを作成します。このワークフローは、ソースコードのチェックアウト、コンテナイメージのビルド、GitHub Packagesイメージレジストリへのプッシュから構成されています。

name: continuous-integration

on:
push:
branches: ["main"]
tags: ["*"]
pull_request:
branches: ["main"]

env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}

jobs:
build-and-push:
name: build and push container image
runs-on: ubuntu-latest

permissions:
  contents: read
  packages: write

steps:
  - name: checkout source code
    uses: actions/checkout@v4

  - name: authenticate with repository
    uses: docker<br><br>こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。<br>[https://dev.to/amplication/extending-gitops-effortless-continuous-integration-and-deployment-on-kubernetes-1oem](https://dev.to/amplication/extending-gitops-effortless-continuous-integration-and-deployment-on-kubernetes-1oem)