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

投稿日: 2022-04-20 2022-10-22
タグ: CI/CD, DigitalOcean Managed Kubernetes, Kubernetes

序章

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 は、実行中の環境に関する詳細を提供するアプリです。 Flux構成を保持するリポジトリをホストし、 podinfo GitHubアカウントで。 Fluxを設定して、アプリリポジトリを監視し、変更を自動的に適用して、Webhookを使用してSlackで通知します。最終的に、監視対象リポジトリに加えたすべての変更は、クラスタにすばやく反映されます。

前提条件

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

接続構成が次のように構成されたDigitalOceanKubernetesクラスター kubectl デフォルト。設定方法の説明 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

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

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

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

フラックスは、それが新しいものを作ったと述べました Git repository、基本的な開始構成をコミットし、クラスターに必要なコントローラーをプロビジョニングしました。

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

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

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

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

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

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

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

cd ~/flux-config

フォークを監視するようにFluxに指示するには podinfo リポジトリの場合、最初にそれがどこにあるかを知らせる必要があります。これは、 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

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

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

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

これでソースが定義されました Git repository そのFluxはアクセスできますが、それでも何をデプロイするかを指示する必要があります。 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、指定します podinfo 作成したGitリポジトリ。また、 --path に ./kustomize、ソースリポジトリのファイルシステム構造を参照します。次に、YAML出力をというファイルに保存します podinfo-kustomization.yaml 現在のクラスターのディレクトリーにあります。

The 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

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

flux resume kustomization kustomization_name

これで、展開する自動化されたプロセスが導入されました podinfo 変更が発生するたびにクラスターに追加されます。これでSlack通知を設定できるので、新しいバージョンの podinfo 展開されています。

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

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

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

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

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

のWebhookを有効にする flux-app タイトルの横にあるスイッチボタンを切り替えると、着信Webhookをアクティブ化します。

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

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

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

と呼ばれる秘密を作成する slack-url 次のコマンドを実行してWebhookを含めるには、 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クラウドストレージにあるチャートを監視できます。これで、監視するように設定します podinfo Helmリポジトリにあるチャート。

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

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

cd ~/flux-config

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

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 定義したリポジトリに、チャートがインストールされる名前空間を指定します。 podinfo-helm.

以来 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

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

結論

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

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

getdocs

13036