DigitalOceanKubernetesでFluxを使用して継続的デリバリーパイプラインを設定する方法

著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。

序章

Kubernetes 自体は、継続的インテグレーションおよびデプロイ機能を提供しません。これらの概念は小規模なプロジェクトでは普及していないことがよくありますが、展開をホストおよび更新する大規模なチームは、手動の時間のかかるタスクを軽減するためにそのようなプロセスを設定する方がはるかに簡単であり、代わりに展開中のソフトウェアの開発に集中できます。 Kubernetesの継続的デリバリーを維持するための1つのアプローチは、GitOpsです。

GitOps は、アプリケーションをホストしているGitリポジトリを表示し、Kubernetesマニフェストを展開に関する信頼できる唯一の情報源として表示します。リポジトリブランチを使用して展開環境を分離し、現在または過去の構成状態を任意のクラスターですばやく再現する機能を提供し、Gitバージョニングのおかげでロールバックを簡単にします。マニフェストは安全で同期されており、いつでも簡単にアクセスできます。マニフェストまたはアプリケーションへの変更は、外部要因（通常は継続的インテグレーションシステム）に応じて、監査、許可、または拒否できます。コードのプッシュからクラスターへのデプロイまでのプロセスを自動化すると、生産性が大幅に向上し、開発者のエクスペリエンスが向上すると同時に、デプロイメントが常に中央のコードベースと一致するようになります。

Flux は、KubernetesのGitOps継続的デリバリーアプローチを容易にするオープンソースツールです。 Fluxを使用すると、構成済みのGitリポジトリーを監視し、変更が利用可能になるとすぐに自動的に適用することで、クラスターへのアプリケーションと構成のデプロイを自動化できます。 Kustomize マニフェスト（オプションで通常のKubernetesマニフェストの一部にオンザフライでパッチを適用する簡単な方法を提供します）を適用したり、Helmチャートのリリースを監視したりできます。 Slack、Discord、Microsoft Teams、またはWebhookをサポートするその他のサービスを介して通知されるように構成することもできます。 Webhookは、他の場所で発生したイベントをアプリまたはサービスに通知し、その説明を提供する方法を提供します。

このチュートリアルでは、Fluxをインストールし、それを使用してpodinfoアプリのDigitalOceanKubernetesクラスターへの継続的デリバリーを設定します。 podinfoは、実行中の環境に関する詳細を提供するアプリです。 GitHub アカウントで、Flux構成とpodinfoを保持するリポジトリをホストします。 Fluxを設定して、アプリリポジトリを監視し、変更を自動的に適用して、Webhookを使用してSlackで通知します。最終的に、監視対象リポジトリに加えたすべての変更は、クラスタにすばやく反映されます。

前提条件

このチュートリアルを完了するには、次のものが必要です。

接続構成がkubectlデフォルトとして構成されているDigitalOceanKubernetesクラスター。 kubectlを構成する方法の説明は、クラスターを作成するときのクラスターへの接続ステップの下に表示されます。 DigitalOceanでKubernetesクラスタを作成する方法については、 KubernetesQuickstartをご覧ください。
メンバーになっているSlackワークスペース。ワークスペースの作成方法については、[公式ドキュメント]（ https://slack.com/help/articles/206845317-Create-a-Slack-workspace ）にアクセスしてください。
すべての権限で作成されたパーソナルアクセストークン（PAT）を持つGitHubアカウント。作成方法については、公式ドキュメントにアクセスしてください。
Git が初期化され、ローカルマシンにセットアップされました。 Gitの使用を開始し、インストール手順を確認するには、オープンソースに貢献する方法：Gitの開始チュートリアルにアクセスしてください。
podinfoアプリリポジトリがGitHubアカウントにフォークされました。アカウントにリポジトリをフォークする方法については、公式のスタートガイドにアクセスしてください。

ステップ1—Fluxのインストールとブートストラップ

このステップでは、ローカルマシンにFluxをセットアップし、クラスターにインストールして、構成を保存およびバージョン管理するための専用のGitリポジトリーをセットアップします。

Linuxでは、公式のBashスクリプトを使用してFluxをインストールできます。 MacOSを使用している場合は、Linuxの場合と同じ手順に従って公式スクリプトを使用するか、Homebrewを使用して次のコマンドでFluxをインストールできます。

brew install fluxcd/tap/flux

公式に提供されているスクリプトを使用してFluxをインストールするには、次のコマンドを実行してダウンロードします。

curl https://fluxcd.io/install.sh -so flux-install.sh

次のコマンドを実行すると、flux-install.shスクリプトを調べて、安全であることを確認できます。

less ./flux-install.sh

実行可能にするには、実行可能としてマークする必要があります。

chmod +x flux-install.sh

次に、スクリプトを実行してFluxをインストールします。

./flux-install.sh

インストールされているバージョンの詳細を示す次の出力が表示されます。

Output[INFO]  Downloading metadata https://api.github.com/repos/fluxcd/flux2/releases/latest
[INFO]  Using 0.13.4 as release
[INFO]  Downloading hash https://github.com/fluxcd/flux2/releases/download/v0.13.4/flux_0.13.4_checksums.txt
[INFO]  Downloading binary https://github.com/fluxcd/flux2/releases/download/v0.13.4/flux_0.13.4_linux_amd64.tar.gz
[INFO]  Verifying binary download
[INFO]  Installing flux to /usr/local/bin/flux

コマンドのオートコンプリートを有効にするには、次のコマンドを実行してシェルを構成します。

echo ". <(flux completion bash)" >> ~/.bashrc

変更を有効にするには、次のコマンドを実行して~/.bashrcをリロードします。

. ~/.bashrc

これで、ローカルマシンでFluxを使用できるようになりました。クラスタにインストールする前に、まず互換性を確認する前提条件チェックを実行する必要があります。

flux check --pre

Fluxは、前提条件で接続を設定したクラスターに接続します。次のような出力が表示されます。

Output► checking prerequisites
✔ kubectl 1.21.1 >=1.18.0-0
✔ Kubernetes 1.20.2 >=1.16.0-0
✔ prerequisites checks passed

注：エラーまたは警告が表示された場合は、接続しているクラスターを再確認してください。 Fluxを使用できるようにするには、アップグレードを実行する必要がある可能性があります。 kubectlが欠落していると報告された場合は、プラットフォームの前提条件から手順を繰り返し、PATHにあることを確認してください。

ブートストラッププロセス中に、Fluxは指定されたプロバイダーでGitリポジトリを作成し、デフォルト構成で初期化します。これを行うには、前提条件で取得したGitHubユーザー名と個人アクセストークンが必要です。リポジトリは、GitHubのアカウントで利用できるようになります。

GitHubのユーザー名と個人用アクセストークンを環境変数として保存し、複数回入力しないようにします。次のコマンドを実行し、強調表示された部分をGitHubのクレデンシャルに置き換えます。

export GITHUB_USER=your_username
export GITHUB_TOKEN=your_personal_access_token

これで、Fluxをブートストラップし、次を実行してクラスターにインストールできます。

flux bootstrap github \
  --owner=$GITHUB_USER \
  --repository=flux-config \
  --branch=main \
  --path=./clusters/my-cluster \
  --personal

このコマンドでは、定義したユーザーが所有するプロバイダーgithubでリポジトリをflux-configと呼ぶように指定します。新しいリポジトリは個人用（組織の下ではない）であり、デフォルトで非公開になります。

表示される出力は次のようになります。

Output► connecting to github.com
► cloning branch "main" from Git repository "https://github.com/GITHUB_USER/flux-config.git"
✔ cloned repository
► generating component manifests
✔ generated component manifests
✔ committed sync manifests to "main" ("b750ffae686c2f110364694d2ddae26c7f18c6a2")
► pushing component manifests to "https://github.com/GITHUB_USER/flux-config.git"
► installing components in "flux-system" namespace
✔ installed components
✔ reconciled components
► determining if source secret "flux-system/flux-system" exists
► generating source secret
✔ public key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKw943TnUiKLVk4WMLC5YCeC+tIPVvJprQxTfLqcwkHtedMJPanJFifmbQ/M3CAq1IgqyQTydRJSJu6E/4YDOwx1vawStR9XU16rkn+rZbmvRxZ97E0HNb5m54OwmziAWf0EPdsfiIIJYSRkCMihpKJUNoakl+sng6LQsW+WIRlOK39aJRWud+rygQEuEKmD7YHKQ0VSb/L5v50jiPgEZImiREHNfjBU+RkEni3aZuOO3jNy5WdlPkpdqfHe8fdFsjJnvNB0zmfe3eTIB2fbdDzxo2usLbFeAMhGCRYsGnniHsytBHNLmxDM/4I18xlNN9e6WEYpgHEJVb8azKmwSX
✔ configured deploy key "flux-system-main-flux-system-./clusters/my-cluster" for "https://github.com/GITHUB_USER/flux-config"
► applying source secret "flux-system/flux-system"
✔ reconciled source secret
► generating sync manifests
✔ generated sync manifests
✔ committed sync manifests to "main" ("1dc033e24f3288a70ff80c57816e16c52bc62303")
► pushing sync manifests to "https://github.com/GITHUB_USER/flux-config.git"
► applying sync manifests
✔ reconciled sync configuration
◎ waiting for Kustomization "flux-system/flux-system" to be reconciled
✔ Kustomization reconciled successfully
► confirming components are healthy
✔ source-controller: deployment ready
✔ kustomize-controller: deployment ready
✔ helm-controller: deployment ready
✔ notification-controller: deployment ready
✔ all components are healthy

Fluxは、新しいGit repositoryを作成し、基本的な開始構成をコミットし、クラスターに必要なコントローラーをプロビジョニングしたことを指摘しました。

この手順では、ローカルマシンにFluxをインストールし、その構成を保持するための新しいGit repositoryを作成し、サーバー側のコンポーネントをクラスターに展開しました。リポジトリ内のコミットによって定義された変更は、クラスターに自動的に伝播されるようになります。次のステップでは、変更が発生するたびにフォークしたpodinfoアプリの展開を自動化するために、Fluxを注文する構成マニフェストを作成します。

ステップ2—自動展開の構成

このセクションでは、フォークしたpodinfoリポジトリを監視し、変更が利用可能になり次第クラスターに適用するようにFluxを構成します。

Fluxは、リポジトリと初期構成の作成に加えて、パラメーターを最初から作成するよりも速く構成マニフェストを生成するのに役立つコマンドを提供します。マニフェストは、それらが何を定義するかに関係なく、考慮されるためにそのGitリポジトリで利用可能である必要があります。それらをリポジトリに追加するには、最初にそれをマシンに複製して、変更をプッシュできるようにする必要があります。これを行うには、次のコマンドを実行します。

git clone https://github.com/$GITHUB_USER/flux-config ~/flux-config

ユーザー名とパスワードの入力を求められる場合があります。アカウントのユーザー名を入力し、パスワードの個人用アクセストークンを入力します。

次に、それに移動します。

cd ~/flux-config

フォークされたpodinfoリポジトリを監視するようにFluxに指示するには、最初にそれがどこにあるかを知らせる必要があります。これは、 GitRepository マニフェストを作成することで実現されます。このマニフェストには、リポジトリのURL、ブランチ、および監視間隔の詳細が記載されています。

マニフェストを作成するには、次のコマンドを実行します。

flux create source git podinfo \
  --url=https://github.com/$GITHUB_USER/podinfo \
  --branch=master \
  --interval=30s \
  --export > ./clusters/my-cluster/podinfo-source.yaml

ここでは、ソースが指定されたURLとブランチを持つGit repositoryになるように指定します。 --exportを渡して、生成されたマニフェストを出力し、メイン構成リポジトリの./clusters/my-cluster/の下にあるpodinfo-source.yamlにパイプします。ここには、現在のクラスターのマニフェストが保存されます。

次のコマンドを実行して、生成されたファイルの内容を表示できます。

cat ./clusters/my-cluster/podinfo-source.yaml

出力は次のようになります。

〜/ flux-config / clusters / my-cluster / podinfo-source.yaml

---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 30s
  ref:
    branch: master
  url: https://github.com/GITHUB_USER/podinfo

Fluxに渡したばかりのパラメーターが、生成されたマニフェストに正しく配置されていることを確認できます。

これで、FluxがアクセスできるソースGit repositoryを定義しましたが、それでも何をデプロイするかを指示する必要があります。 Fluxは、 Kustomize リソースをサポートします。これは、podinfoがkustomizeディレクトリの下に公開します。 Kustomizationsをサポートすることにより、Fluxはそれ自体を制限しません。これは、Kustomizeマニフェストが、通常のマニフェストをすべて変更せずに含めるのと同じくらい単純な場合があるためです。

次のコマンドを実行して、Kustomizationマニフェストを作成します。これは、展開可能なマニフェストを探す場所をFluxに指示します。

flux create kustomization podinfo \
  --source=podinfo \
  --path="./kustomize" \
  --prune=true \
  --validation=client \
  --interval=5m \
  --export > ./clusters/my-cluster/podinfo-kustomization.yaml

--sourceには、作成したpodinfoGitリポジトリーを指定します。また、--pathを./kustomizeに設定します。これは、ソースリポジトリのファイルシステム構造を参照します。次に、YAML出力を現在のクラスターのディレクトリにあるpodinfo-kustomization.yamlというファイルに保存します。

作成したGit repositoryとKustomizationは利用可能になりましたが、GitHubのリモートリポジトリにないため、Fluxのクラスター側はまだそれらを表示できません。それらをプッシュするには、最初に次を実行してコミットする必要があります。

git add . && git commit -m "podinfo added"

変更がコミットされたら、それらをリモートリポジトリにプッシュします。

git push

前回と同じように、gitはあなたにあなたの資格情報を尋ねるかもしれません。続行するには、ユーザー名と個人用アクセストークンを入力してください。

新しいマニフェストは現在公開されており、クラスター側のFluxがまもなくそれらを取得します。次のコマンドを実行すると、クラスターの状態がマニフェストに表示されている状態と同期するのを確認できます。

watch flux get kustomizations

Git repositoryに指定された更新間隔（上記のマニフェストで30sに設定）が経過すると、Fluxは最新のコミットを取得してクラスターを更新します。完了すると、次のような出力が表示されます。

OutputNAME            READY   MESSAGE
flux-system     True    Applied revision: main/fc07af652d3168be329539b30a4c3943a7d12dd8
podinfo         True    Applied revision: master/855f7724be13f6146f61a893851522837ad5b634

podinfo Kustomizationが、そのブランチとコミットハッシュとともに適用されたことがわかります。展開とサービスを一覧表示して、podinfoが展開されていることを確認することもできます。

kubectl get deployments,services

それらが存在し、それぞれのマニフェストに従って構成されていることがわかります。

OutputNAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/podinfo   2/2     2            2           56s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/kubernetes   ClusterIP   10.245.0.1      <none>        443/TCP             34m
service/podinfo      ClusterIP   10.245.78.189   <none>        9898/TCP,9999/TCP   56s

Fluxが制御するこれらのリソースやその他のリソースに手動で加えた変更は、Gitリポジトリから参照されたものですぐに上書きされます。変更を加えるには、クラスター内の実際のデプロイメントではなく、中央ソースを変更する必要があります。これは、リソースの削除にも当てはまります。クラスターから手動で削除したリソースは、まもなく復元されます。それらを削除するには、監視対象のリポジトリからマニフェストを削除し、変更が反映されるのを待つ必要があります。

Fluxの動作は、各更新間隔の終了時にリモートリポジトリで検出されたものに基づいて動作するため、意図的に厳密になっています。 Kustomizationモニタリングを一時停止し、状態調整は、Fluxによって中断されることなく、クラスター内のリソースを手動でオーバーライドする必要がある場合に役立ちます。

次のコマンドを実行すると、Kustomizationの監視を無期限に一時停止できます。

flux suspend kustomization kustomization_name

一時停止したKustomizationでflux resumeを実行すると、デフォルトの動作に戻すことができます。

flux resume kustomization kustomization_name

これで、変更が発生するたびにpodinfoをクラスターにデプロイする自動化されたプロセスが導入されました。これでSlack通知を設定するので、podinfoの新しいバージョンがいつデプロイされるかがわかります。

ステップ3—Slack通知を設定する

クラスタへの自動podinfoデプロイメントを設定したので、FluxをSlackチャネルに接続します。ここで、すべてのデプロイメントとその結果が通知されます。

Slackと統合するには、ワークスペースのSlackに着信Webhookが必要です。着信Webhookは、設定されたSlackチャネルにメッセージを投稿する方法です。

Webhookを作成したことがない場合は、最初にワークスペース用のアプリを作成する必要があります。これを行うには、最初にSlackにログインし、アプリ作成ページに移動します。緑色の新しいアプリの作成ボタンを押して、最初からを選択します。 flux-appという名前を付け、目的のワークスペースを選択して、新しいアプリの作成をクリックします。

新しいアプリの設定ページにリダイレクトされます。左側のナビゲーションバーにあるIncomingWebhooksをクリックします。

タイトルActivateIncoming Webhooks の横にあるスイッチボタンを切り替えて、flux-appのWebhookを有効にします。

ページのさらに下にある新しいセクションが明らかになります。下にスクロールして、新しいWebhookをワークスペースに追加ボタンをクリックします。次のページで、レポートの送信先のチャネルを選択し、[許可]をクリックします。

Webhookの設定ページにリダイレクトされ、新しいWebhookが表に表示されます。 コピーをクリックしてクリップボードにコピーし、後で使用できるようにメモしておきます。

生成されたアプリ用のSlackWebhookをクラスター内のKubernetesSecret に保存し、Fluxが構成マニフェストで明示的に指定しなくてもアクセスできるようにします。 Webhookをシークレットとして保存すると、将来簡単に置き換えることもできます。

次のコマンドを実行して、Webhookを含むslack-urlというシークレットを作成し、your_slack_webhookをコピーしたURLに置き換えます。

kubectl -n flux-system create secret generic slack-url --from-literal=address=your_slack_webhook

出力は次のようになります。

Outputsecret/slack-url created

次に、FluxがWebhookを使用して指定されたサービスと通信できるようにするプロバイダーを作成します。彼らはSecretsからWebhookURLを読み取ります。これが、あなたがWebhookURLを作成した理由です。次のFluxコマンドを実行して、Slackプロバイダーを作成します。

flux create alert-provider slack \
  --type slack \
  --channel general \
  --secret-ref slack-url \
  --export > ./clusters/my-cluster/slack-alert-provider.yaml

Slackの他に、FluxはWebhookを介したMicrosoft Teams、Discord、およびその他のプラットフォームとの通信をサポートしています。また、この形式を解析するより多くのソフトウェアに対応するために、汎用JSONの送信もサポートしています。

プロバイダーは、Fluxがメッセージを送信することのみを許可し、メッセージをいつ送信するかを指定しません。 Fluxがイベントに反応するには、次を実行してslackプロバイダーを使用してアラートを作成する必要があります。

flux create alert slack-alert \
  --event-severity info \
  --event-source Kustomization/* \
  --event-source GitRepository/* \
  --provider-ref slack \
  --export > ./clusters/my-cluster/slack-alert.yaml

このコマンドは、slack-alertと呼ばれるアラートマニフェストを作成します。このマニフェストはすべてのKustomizationおよびGit repositoryの変更に反応し、それらをslackプロバイダーに報告します。イベントの重大度はinfoに設定されます。これにより、Kubernetesマニフェストの作成または適用、展開の遅延、エラーの発生など、すべてのイベントでアラートをトリガーできます。エラーのみを報告するには、代わりにerrorを指定できます。結果として生成されたYAMLは、slack-alert.yamlというファイルにエクスポートされます。

次のコマンドを実行して変更をコミットします。

git add . && git commit -m "Added Slack alerts"

次のコマンドを実行し、必要に応じてGitHubユーザー名と個人アクセストークンを入力して、変更をリモートリポジトリにプッシュします。

git push

Gitリポジトリに設定された更新間隔が経過すると、Fluxは変更を取得して適用します。次のコマンドを実行すると、アラートが使用可能になるのを確認できます。

watch kubectl -n flux-system get alert

Initializedであることがすぐにわかります。

OutputNAME          READY   STATUS        AGE
slack-alert   True    Initialized   7s

アラートが設定されると、Fluxが実行するアクションはすべて、Webhookが接続されているワークスペースのSlackチャネルに記録されます。

podinfoのフォークに変更を加えることにより、この接続をテストします。まず、次のコマンドを実行して、ローカルマシンのクローンを作成します。

git clone https://github.com/$GITHUB_USER/podinfo.git ~/podinfo

複製されたリポジトリに移動します。

cd ~/podinfo

~/podinfo/kustomize/service.yamlで定義されているサービスの名前を変更します。編集のために開きます：

nano ~/podinfo/kustomize/service.yaml

次のように、サービス名を変更します。

〜/ podinfo / kustomize / service.yaml

apiVersion: v1
kind: Service
metadata:
  name: podinfo-1
spec:
  type: ClusterIP
  selector:
    app: podinfo
  ports:
    - name: http
      port: 9898
      protocol: TCP
      targetPort: http
    - port: 9999
      targetPort: grpc
      protocol: TCP
      name: grpc

ファイルを保存して閉じ、次のコマンドを実行して変更をコミットします。

git add . && git commit -m "Service name modified"

次に、変更をプッシュします。

git push

数分後、変更がデプロイされるときにSlackに変更がポップアップ表示されます。

Fluxは新しいコミットをフェッチし、podinfo-1という新しいサービスを作成して構成し、古いサービスを削除しました。このアクションの順序により、新しいサービスのプロビジョニングが失敗した場合でも、古いサービス（またはその他のマニフェスト）が変更されないようになります。

監視対象のマニフェストの新しいリビジョンに構文エラーが含まれている場合、Fluxはエラーを報告します。

FluxをSlackワークスペースに接続すると、発生したすべてのアクションとデプロイがすぐに通知されます。次に、Helmのリリースを監視するようにFluxを設定します。

ステップ4—（オプション）ヘルムリリース展開の自動化

KustomizationsとGitリポジトリを監視することに加えて、FluxはHelmチャートを監視することもできます。 Fluxは、GitまたはHelmリポジトリ、およびS3クラウドストレージにあるチャートを監視できます。次に、Helmリポジトリにあるpodinfoチャートを監視するように設定します。

ヘルムチャートを監視するようにFluxに指示するプロセスは、ステップ2で行ったプロセスと同様です。最初に、変更をポーリングできるソースを定義する必要があります（前述の3つのタイプのいずれか）。次に、 HelmRelease を作成して、検出されたチャートの中で実際に展開するチャートを指定します。

flux-configリポジトリに戻ります。

cd ~/flux-config

次のコマンドを実行して、podinfoを含むHelmリポジトリのソースを作成します。

flux create source helm podinfo \
  --url=https://stefanprodan.github.io/podinfo \
  --interval=10m \
  --export > ./clusters/my-cluster/podinfo-helm-repo.yaml

ここでは、リポジトリのURLとそれをチェックする頻度を指定します。次に、出力をpodinfo-helm-repo.yamlというファイルに保存します。

ソースリポジトリが定義されたら、HelmReleaseを作成して、監視するチャートを定義できます。

flux create hr podinfo \
  --interval=10m \
  --source=HelmRepository/podinfo \
  --chart=podinfo \
  --target-namespace=podinfo-helm \
  --export > ./clusters/my-cluster/podinfo-helm-chart.yaml

前のコマンドと同様に、結果のYAML出力をファイル（ここではpodinfo-helm-chart.yaml）に保存します。また、チャートの名前（podinfo）を渡し、--sourceを定義したリポジトリに設定し、チャートがインストールされる名前空間が[であることを指定します。 X177X]。

podinfo-helm名前空間は存在しないため、次のコマンドを実行して作成します。

kubectl create namespace podinfo-helm

次に、変更をコミットしてプッシュします。

git add . && git commit -m "Added podinfo Helm chart" && git push

数分後、FluxがSlackでHelmチャートのアップグレードに成功したことがわかります。

podinfo-helm名前空間に含まれるポッドを確認するには、次のコマンドを実行します。

kubectl get pods -n podinfo-helm

出力は次のようになります。

OutputNAME                                     READY   STATUS    RESTARTS   AGE
podinfo-chart-podinfo-7c9b7667cb-gshkb   1/1     Running   0          33s

これは、podinfoヘルムチャートを監視および展開するようにFluxを正常に構成したことを意味します。新しいバージョンがリリースされるか、変更がプッシュされるとすぐに、FluxはHelmチャートの最新のバリアントを取得してデプロイします。

結論

これで、Fluxを使用してKubernetesマニフェストのデプロイが自動化されました。これにより、監視対象のリポジトリにコミットをプッシュして、クラスターに自動的に適用できます。また、Slackへのアラートを設定したので、どのデプロイメントがリアルタイムで発生しているかを常に把握でき、以前のデプロイメントを調べて、発生した可能性のあるエラーを確認できます。

GitHubに加えて、FluxはGitLabでホストされているGitリポジトリの取得とブートストラップもサポートしています。詳細については、公式ドキュメントにアクセスしてください。