2024年02月26日
連載 第3回
Argo-CDを利用した
GitOpsシステムの構築
今回はArgoCDを利用してGitOpsシステムを構築する方法を説明します。
1. GitOpsと信頼できる唯一の情報源(SSOT)の定義
先ず、GitOpsの定義を確認します。連載第1回で、コードで宣言するクバネティスの特徴とインストールのところで説明したように、クバネティスの全てのリソースはコードで構成できます。GitOpsはコードをGitに保管して、そのコードが運用中の状態(Ops)に合わせることを意味します。
現場の運用状態をGitにCommit、Pushせず、任意に自分のローカルソースを変更することや、コマンドでの変更を禁止するために利用します。任意に変更された状態は、変更箇所の追跡は難しいです。一部のクラスタで障害が発生した場合、任意に変更された箇所でその原因を発見することが比較的多いです。また、新しいシステムを構成する場合、その都度その変更箇所を探す必要があるなど多くの追加リソースが必要です。
GitOpsは「信頼できる唯一の情報源」(Single Source of Truth、SSOT) の概念を利用するためその定義を確認します。「信頼できる唯一の情報源」はデータ管理の原則の一つで、システム全体で一つの正確で信頼できる特定のバージョンのデータだけが存在するという考え方です。この原則は一貫性や、正確性、効率性が向上することで重要な役割をします。
一貫性: 全てのシステムの構成要素が同じデータソースを参照するため、データの一貫性が維持される。
正確性: 重複または不一致の可能性が減少するため、データの正確性が向上する。
効率性: データを維持管理するための場所があるため、アップデートと管理が効率的。
GitOpsではGitの保存場所がシステムの構成と状態に対して信頼できる唯一の情報源の役割をします。コードとインフラの全体の状態をGitの保存場所にバージョン毎に保存することで、宣言的なアプローチ方法でシステムを自動で管理します。 現場で現在の運用状態を個別ユーザが任意にコマンドで変更する、コミットしてないローカルソースは変更せずに、情報源のGitソースだけを変更することを意味します。GitOpsでシステムの一貫性が維持されて協業の生産性が向上することが大きなメリットです。
全てのシステムとユーザが同じデータソースを参照するため、情報の不一致が発生する確率が減少し、重複したデータを管理し、同期化することに必要な労力とコストを減らすことができます。それに伴いシステム全体の運用の効率性が向上します。検索などで前の状態を照会する機能もよく利用されます。
しかし、この原則を履行することが難しい場合もあります。例えば、忙しい業務で原則を守ることが難しい場合です。この場合、GitOps関連ツールを利用してポリシーを強制することが必要で、正しいデータアーキテクチャーや、プロセス、管理ツールが必要です。GitOpsを実現するために多くのツールを利用できますが、CD(連続配布、Continuous Deployment)で使用するツールではArgoCDが最も多く使用されています。何故なら、多くのCDツールの中でArgoCDは便利なUIを提供し、他のツールとの統合が簡単であり、ユーザが多いため事例が豊富だからです。
ArgoCDは指定されたGitの保存場所とクバネティスクラスタを持続的にモニタリングします。保存場所の変更が検知されると、ArgoCDは自動的にクラスタの状態を保存場所の状態と同期化します。勿論、状況により手動同期化オプションも提供します。また、問題が発生すると以前の状態に簡単にロールバックできます。Gitのバージョン管理で全ての変更が追跡されるため、安定した状態へ復元することができます。
また、ArgoCDダッシュボードによってアプリケーションのリアルタイムな状態や、同期化の状態、ヘルスの状態を視覚的に確認できます。Helmでアプリケーションを配布すると全体のリソースを把握することが難しいですが、ArgoCDダッシュボードでは簡単に把握できるため、多くのユーザが使う機能です。ユーザ別、プロジェクト別にアプローチ制御権限を設定すれば、チームメンバーが適切なアクセスレベルを持つことができます。
Argo CDはGitの保存場所を「信頼できる唯一の情報源」として使用し、クバネティスクラスタの状態を持続的に同期化してモニタリングします。これにより開発担当者と運用チーム間の協業を強化し、安定的で迅速な配布を実現できます。
以上のことを実習で詳しく説明します。
実習の内容
・ ArgoCDのインストール
・ ArgoCDを利用したNGINX Helmチャートの配布
・ GitOpsの実習 – ローカル環境で任意の変更を検証
2. Argo-CDのインストール
クバネティス環境でアプリケーションは主にHelmを利用してインストールします。Helmはクバネティスパッケージ管理者で、OSの apt、yumと類似します。Helmを使用すると複数のクバネティスリソースを纏めて一つのパッケージで管理できます。これによりアプリケーションのインストール、アップグレードなどが簡略化できます。Helmの詳細は連載第11回で説明します。
HelmでArgoCDをインストールします。Windows WSLのHomebrewインストールユーザとMACユーザはbrewを使用してローカルPCにHelmをインストールします。
1. brew install helm次にArgoCD 公式ホームページを利用してArgoCD Helmチャートをダウンロードします。
1. helm repo add argo https://argoproj.github.io/argo-helm
2. helm pull argo/argo-cd --version v5.14.1
3. tar xvfz argo-cd-5.14.1.tgz
4. mv argo-cd argo-cd-v5.14.1
5. rm -rf argo-cd-5.14.1.tgz
6. cd argo-cd-v5.14.1
7. mkdir ci && cp values.yaml ci/jerry-test-values.yamlリモートのArgoCDのHelmレポジトリを登録(helm repo add)して、ローカルでHelmチャートをダウンロード(helm pull)します。次に、基本Helm Valueファイルを各環境に合わせて変更するために、既存Values.yamlファイルをコピーして、任意の名前(jerry-test-values.yaml)に変更します。Helmコマンドの詳細は連載第11回で説明します。
基本公式Helm Valueを下記のように変更します。(GitHub参照)
1. configs:
2. credentialTemplates:
3. ssh-creds:
4. url: git@github.com:junghoon2
5. sshPrivateKey: |
6. -----BEGIN OPENSSH PRIVATE KEY-----
7. xxxxxxxxxxx
8. -----END OPENSSH PRIVATE KEY-----
9. repositories:
10. k8s-class:
11. name: k8s-class
12. url: git@github.com:junghoon2/k8s-class.git. configs.credentialTemplates.ssh-creds
ArgoCDで登録するGitHubレポジトリ情報を登録します。各自で使用するGitHubの登録したsshキー情報(~/.ssh/id_rsa)を入力します。個人キー情報であるため、セキュリティー上、該当情報をマスキング処理(xxxxx)しました。
レポジトリ情報はArgoCDのインストールを完了した後にGUIでも入力できます。しかし、GUIで入力した場合、GitOpsポリシーに合うようにGitレポジトリ情報もソースコードに入力することをお勧めします。最初は面倒ですがGUIを利用した作業は行わないことが今後、そのソースコードを再利用でき便利です。
.repositories.k8s-class.name/url
各自でGitレポジトリ名とURLを登録します。
今回は未だIngressの設定前のため、Ingress関連のHelm Valuesの設定はありません。連載第5回で説明するIngressの設定が完了すると、Ingressアドレスに接続できます。
Helm Valueファイル(jerry-test-values.yaml)を利用してArgoCDをインストールします。
1. $ helm install argocd -n argocd --create-namespace -f ci/jerry-test-values.yaml .
2. NAME: argocd
3. LAST DEPLOYED: Sun Jun 25 02:18:51 2023
4. NAMESPACE: argocd
5. STATUS: deployed
6. REVISION: 1
7. TEST SUITE: None
8. NOTES:
9. In order to access the server UI you have the following options:
10.
11. 1. kubectl port-forward service/argocd-server -n argocd 8080:443
12.
13. and then open the browser on http://localhost:8080 and accept the certificate
14.
15. 2. enable ingress in the values file `server.ingress.enabled` and either
16. - Add the annotation for ssl passthrough: https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-1-ssl-passthrough
17. - Set the `configs.params."server.insecure"` in the values file and terminate SSL at your ingress: https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-2-multiple-ingress-objects-and-hosts
18.
19.
20. After reaching the UI the first time you can login with username: admin and the random password generated during the installation. You can find the password by running:
21.
22. kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
23.
24. (You should delete the initial secret afterwards as suggested by the Getting Started Guide: https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli)
インストールが完了すると、ArgoCD関連のPodを確認できます。
1. # argocdネームスペースに変更します。
2. $ k ns argocd
3.
4. $ (jerry-test:argocd) k get pod
5. NAME READY STATUS RESTARTS AGE
6. argocd-application-controller-0 1/1 Running 0 69s
7. argocd-applicationset-controller-fc4dbb87c-bpf6f 1/1 Running 0 70s
8. argocd-dex-server-fd7d54c-crcr9 1/1 Running 0 69s
9. argocd-notifications-controller-7f66dc5c75-xvsz7 1/1 Running 0 70s
10. argocd-redis-79c77796b7-x6kl6 1/1 Running 0 70s
11. argocd-repo-server-6c9c4978b8-4btch 1/1 Running 0 70s
12. argocd-server-b694d4bc6-br6lt 1/1 Running 0 70s3. Port-forwardを利用したArgo-CD Podの接続
インストールしたArgoCDPodをPort-forwardを利用して接続します。クラスタ外部から、クラスタ内部で実行しているPodへ接続するために主にクバネティスのIngressリソースを使用します。詳細は連載第5回で説明します。今回は追加のIngressの設定作業がなく、管理者が簡単に使用できるPort-forwardを利用してPodへ接続します。現場でもセキュリティー上の理由でIngressの設定をしないPodはPort-forwardを利用して接続します。
Port-forwardは‘kubectl port-forward’コマンドを使用します。port-forwardコマンドは長いですがコマンドが自動構成できるため、難しくありません。port-forwardコマンドはクラスタ内の特定のPodに対するトラフィックをローカルシステムの特定ポートへ伝達(port-forward)する機能で、ローカル開発環境で直接クラスタの内部リソースにアプローチできます。既にkubectlコマンドを実行するためにAPIサーバポートがコネクションされているため、簡単な設定だけでクラスタローカルポートにコネクションできます。ローカルシステムの指定されたポートに入るトラフィックはAPIサーバで選択したPodの特定ポートに伝わります。
クバネティスAPIサーバはこの過程で中継の役割をします。実際のトラフィックの伝達はkubeletが担当します。下記コマンドを利用してArgoCD Podに接続します。
1. [jerry:~ (jerry:argocd)]$ k get service argocd-server
2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
3. argocd-server ClusterIP 10.233.37.108 <none> 80/TCP,443/TCP 43d
4.
5. [jerry:~ (jerry:argocd)]$ k port-forward svc/argocd-server 8080:80
6. Forwarding from 127.0.0.1:8080 -> 8080
7. Forwarding from [::1]:8080 -> 8080クバネティスはサービス(service)オブジェクトでPodトラフィックを制御します。port-forwardもPodの代わりにサービスを利用すると便利です。サービスに関する詳細は今後の連載で説明します。
‘8080:80’コマンドの前の8080ポートはローカルホストのポートで、後の80ポートはクラスタサービスが使用する80ポートです。つまり、ローカルホストの8080ポートをクラスタサービスの80ポートにコネクションするということです。下記のようにブラウザに‘localhost:8080’を入力するとArgoCDの画面が確認できます。
初期の‘admin’ユーザのパスワードはSecretで確認できます。Secretはパスワードなどクリティカルな情報を保存するクバネティスオブジェクトです。詳細は今後の連載で説明します。今回は下記の様にデコーディングしてパスワードを確認します。
1. [(jerry-test:argocd) ~]$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
2. RNTP10IXD2P3uSWgログイン画面にUsername adminを入力してPasswordに上記のコマンドの出力結果を入力します。ログイン後、画面の左側メニューの‘Settings’-’Repositories’を選択するとHelm Valuesファイルに設定したGitHubレポジトリが正常に登録されたことを確認できます。
以上でArgoCDを正常にインストールできました。
4. Argo-CDを利用してNGINX Helmを配布
インストールした ArgoCDを利用してアプリケーションを配布します。アプリケーションはWebサーバ用に多く使用されているNginxです。
NginxもHelmチャートを利用して配布します。
1. [jerry:k8s-class (jerry:argocd)]$ mkdir nginx-webserver && cd nginx-webserver
2. [jerry:nginx-webserver (jerry:argocd)]$ helm pull oci://registry-1.docker.io/bitnamicharts/nginx --version 15.1.0
3. [jerry:nginx-webserver (jerry:argocd)]$ tar xvfz nginx-15.1.0.tgz
4. [jerry:nginx-webserver (jerry:argocd)]$ rm -rf nginx-15.1.0.tgz
5. [jerry:nginx-webserver (jerry:argocd)]$ mv nginx nginx-web15.1.0
6. [jerry:nginx-webserver (jerry:argocd)]$ mkdir ci && cp values.yaml ci/my-values.yaml前の記述と同様にHelmをインストールするプロセスです。Nginx Webサーバのバージョンは最新バージョンを使用しても問題ありませんが、参考資料と同じ構成にする場合はバージョン15.1.0を指定します。
Helm Values.yamlファイルを下記のように変更します。該当ファイルは GitHubを参照で確認できます。
1. replicaCount: 2
2. service:
3. type: ClusterIP
4. metrics:
5. enabled: trueデフォルト設定でNginx WebサーバのPod数を2個に変更する簡単な変更です。Helm Valuesファイルを基準にNginx Webサーバを配布します。ArgoCDはアプリケーションをクバネティス環境に配布するためにGUI Webで作業できますが、再利用し易く、GitOpsに適合したアプリケーション配布設定もコードで行うことをお勧めします。
ArgoCDはコードで配布できるように‘Application’というCRD(Custom Resource Definition)を使用します。CRDはクバネティスでユーザ定義リソースを定義するための機能です。クバネティスは基本的にPod、サービス、デプロイメントなどの中核のリソースを提供しますが、意外にも、ユーザが独自に定義したリソースタイプも使用できます。
CRDを使用するとユーザは自分だけのリソースタイプを定義して、これをクラスタに内蔵されたリソースのように使用できます。ArgoCDでもアプリケーション配布を容易に‘Application’という独自のリソースを提供します。
Nginx Webサーバを配布するためのArgoCD Applicationを作成します。(GitHubを参照)
1. apiVersion: argoproj.io/v1alpha1
2. kind: Application
3. metadata:
4. name: nginx
5. namespace: argocd
6. finalizers:
7. - resources-finalizer.argocd.argoproj.io
8. spec:
9. destination:
10. namespace: nginx
11. server: https://kubernetes.default.svc
12. project: default
13. source:
14. helm:
15. valueFiles:
16. - ci/my-values.yaml
17. path: nginx-webserver/nginx-15.1.0
18. repoURL: https://github.com/junghoon2/k8s-class.git
19. targetRevision: HEAD
20. syncPolicy:
21. automated:
22. prune: true
23. selfHeal: true
24. syncOptions:
25. - CreateNamespace=true. metadata.finalizers
‘Application’リソースを削除すると関連するクバネティスリソース(Podなど)まで同時に削除するオプションです。
. spec.destination.server
ArgoCDがアプリケーションを配布する目的地を指定します。リモートのクバネティスクラスタも指定できます。ArgoCDがインストールされたクバネティスも指定できます。アドレスを‘https://kubernetes.default.svc’と指定するとArgoCDがインストールされたクバネティスの指定となります。
. spec.source.helm
ArgoCDはアプリケーションインストールタイプにHelm、Manifestなどを指定できます。今回の実習ではNginxをHelmでインストールするため‘helm’を指定しました。
. spec.source.path, repoURL
Helmチャートが置かれたGitHubレポジトリURLとそのHelmチャートパスを指定します。
.spec.syncPolicy.automated.prune/selfHeal
ArgoCDで自動的にアプリケーションの配布可否を可と指定するオプションです。Gitにソースがアップロードされると自動的にクバネティスにHelmを配布する場合は‘automated’オプションを指定します。
実際の現場でDev、Stage環境ではautomatedオプションを使用しますが、運用環境では手動で変化(‘Diff’)の内容を確認して配布するため、automatedオプションを使用しない場合もあります。
pruneオプションはGitでコードを削除すると実際にリソースも同時に削除し、selfHealオプションは失敗した作業を自動的に復旧します。
. spec.syncOptions.CreateNamespace
ネームスペースを自動的に生成するオプションです。
Application CRDも同じクバネティスリソースなので‘k apply’コマンドでリソースを生成できます。
1. $ k apply -f nginx-webserver/nginx-15.1.0/cd/my-application.yaml
2. application.argoproj.io/nginx createdArgocd‘Application’という別途のクバネティスオブジェクトが生成されました。ArgoCDのApplicationとは、一般的にプログラムApplicationではなくArgoCDで生成したクバネティスオブジェクトの一種です。
1. [(jerry-test:argocd) cd]$ k get applications -n argocd nginx
2. NAME SYNC STATUS HEALTH STATUS
3. nginx Synced HealthyArgoCD Webで画面左側メニューの‘Applications’を確認すると、新しくargocd/nginxが生成されたことが確認できます。
メニューをクリックするとNGINX Helmチャートでインストールしたクバネティスリソースを確認できます。 Service、Deployがインストールされました。
インストールされたNginx WebサーバPodはコマンドでも確認できます。
1. [jerry:~ (jerry:nginx)]$ k get pod -n nginx
2. NAME READY STATUS RESTARTS AGE
3. nginx-7979bfc556-4twdt 2/2 Running 2 (35d ago) 35d
4. nginx-7979bfc556-cvg5w 2/2 Running 1 (35d ago) 35d上記のようにArgoCDを利用してアプリケーションPodを配布できます。
最初にArgoCDを配布時に、ローカルPCで‘helm install’コマンドを使用してアプリケーションを配布します。次にArgoCDを配布した後、NGINXは‘helm install’コマンドではなく、ArgoCDを利用してNGINXアプリケーションを配布します。
ローカルPCからコマンドでインストールした後で、アプリケーションはGitに保存しないようにできますが、その場合は後の管理が難しいです。しかし、ArgoCDを利用すると、Gitにソースをアップロードして配布することができるため、GitOpsポリシーを適用し易いです。クバネティスでインストールする全てのアプリケーションはArgoCDを利用して配布することをお勧めします。
ArgoCDはUIをサポートするのでHelmでどのリソースをインストールしたか確認できるため、便利です。
5. GitOpsの実習
実運用(Ops)の状態とGit状態を異なるようにしてArgoCDがどのようにGitOpsを実現するのか確認します。
ソースではなくコマンドを使用してNGINX Podの数2個を5個に変更します。ローカルのコンソール画面を2つに分けて上の画面ではPodの数を変更して、下の画面では変更をリアルタイムに確認します。
下の画面は下記のように‘k get pod -w(watch)’ コマンドでPodの変更をリアルタイムに確認できます。
1. # nginx ネームスペースに変更します。
2. $ (⎈ |switch-singapore-test:echoserver) k ns nginx
3. Context "switch-singapore-test" modified.
4. Active namespace is "nginx".
5.
6. $ (⎈ |switch-singapore-test:nginx) k get pod -w
7. NAME READY STATUS RESTARTS AGE
8. nginx-7979bfc556-7bz89 2/2 Running 0 6m30s
9. nginx-7979bfc556-gb7t2 2/2 Running 0 6m30s上の画面ではPodの数を変更します。Podの数の変更はscaleコマンドを使用します。
1. $ (⎈ |switch-singapore-test:nginx) k scale deployment nginx --replicas 5
2. deployment.apps/nginx scaledscaleコマンドでPodの数を5個に指定しましたがPodの数は変わりません。 ‘ContainerCreating’と同時に‘Terminating‘されました。
1. $ (⎈ |switch-singapore-test:nginx) k get pod -w
2. NAME READY STATUS RESTARTS AGE
3. nginx-7979bfc556-7bz89 2/2 Running 0 6m30s
4. nginx-7979bfc556-gb7t2 2/2 Running 0 6m30s
5.
6. nginx-7979bfc556-8btj2 0/2 Pending 0 0s
7. nginx-7979bfc556-8btj2 0/2 Pending 0 0s
8. nginx-7979bfc556-85x5c 0/2 Pending 0 0s
9. nginx-7979bfc556-sqd4j 0/2 Pending 0 0s
10. nginx-7979bfc556-85x5c 0/2 Pending 0 0s
11. nginx-7979bfc556-8btj2 0/2 ContainerCreating 0 0s
12. nginx-7979bfc556-sqd4j 0/2 Pending 0 0s
13. nginx-7979bfc556-85x5c 0/2 ContainerCreating 0 0s
14. nginx-7979bfc556-sqd4j 0/2 ContainerCreating 0 0s
15. nginx-7979bfc556-sqd4j 0/2 Terminating 0 1s
16. nginx-7979bfc556-85x5c 0/2 Terminating 0 1s
17. nginx-7979bfc556-8btj2 0/2 Terminating 0 1sPodの数は2個のままです。何故でしょうか?
1. $ (⎈ |switch-singapore-test:nginx) k get pod
2. NAME READY STATUS RESTARTS AGE
3. nginx-7979bfc556-7bz89 2/2 Running 0 8m46s
4. nginx-7979bfc556-gb7t2 2/2 Running 0 8m46sGitソースでPodの数を変更してないため、ArgoCDが自動的に現在のクラスタ状態をGitに同期化されたソースの状態と自動的に合わせるため、常に2を維持するからです。
では、差を確認するためにArgoCDで‘automated’オプションを外します。‘automated’オプションは自動的に現在の状態とGitの状態を合わせるオプションです。オプションを外すと、ArgoCDが現在の状態を自動的に変更しません。
再度‘k scale deployment nginx –replicas 5’コマンドを実行してArgoCD Webで確認すると‘OutOfSync’状態です。メッセージで確認できるように現在Gitに保存されたソースの状態が運用中のクラスタの状態とSync状態ではないことが確認できます。
メニューの‘APP DIFF’で確認すると詳細なメッセージを確認できます。
‘replicas’でPodのレプリカ数が5個と2個とで差があることを確認できます。
実運用の環境では上記のように‘automated’オプションを非活性化して使用することもありますが、常に‘Diff’を手動で確認し、作業異常の有無をチェックして実際のクラスタに適用します。
整理すると作業担当者がGitソースではなく任意にコマンドでPodの数を変更しても‘Automated’オプションが活性化されていると、ArgoCDが自動的に現在の状態をGitソースと同期化してPodの数を2個に維持します。
今度はGitソースでPodの数を2個から1個に変更します。NGINX Helm valueファイルの‘replicaCount’オプションを変更します。
1. replicaCount: 1 # 2 to 1個に変更Git commit後、pushしてGit mainでmergeします。下記はVSCode Git Commit画面の例です。
ArgoCDメニューで‘REFRESH’するとPodの数が自動で1個に減りました。
kubectlコマンドで確認してもPodの数が1個に減っています。
1. $ (⎈ |switch-singapore-test:nginx) k get pod
2. NAME READY STATUS RESTARTS AGE
3. nginx-7979bfc556-gb7t2 2/2 Running 0 25mこのようにArgoCDはGitソースに適用された状態を実運用のクバネティスの状態と同期化します。全ての変更作業をコマンド又はローカルのソースで実行しないで、統一したGitの保存場所だけで作業を実行することができます。
このようにTerraformを使用するインフラ作業にもGit PR Reviewで実際に適用します。
上記の画面はEKSアップグレード作業時、実際に使用したPR Reviewメッセージです。EKSアップグレードのためのTerraformコードの作業をレビューによってチームメンバーで検証した事例です。事前に作業関連コードを検証すると、作業中に発生する可能性がある障害を減らすことができます。検証されたコードをmainでmergeして実際に適用しました。
Terraformコード以外の作業のためのPythonコードも同じくGitに保存してレビューします。
1. import boto3
2.
3. regions = ["ap-northeast-2", "us-west-2", "ap-northeast-1", "us-east-1"]
4.
5. for region in regions:
6. session = boto3.Session(region_name=region)
7. client = session.client("kafka")
8.
9. # to print region name
10. print(f"{region}")
11.
12. # Get a list of all clusters
13. response = client.list_clusters()
14.
15. # Loop through the instances and print out their details
16. for instance in response["ClusterInfoList"]:
17. # Get the type, state, and launch time
18. ClusterName = instance["ClusterName"]
19. InstanceType = instance["BrokerNodeGroupInfo"]["InstanceType"]
20. NumberOfBrokerNodes = instance["NumberOfBrokerNodes"]
21. CreationTime = instance["CreationTime"].strftime("%Y-%m-%d %H:%M:%S")
22. State = instance["State"]
23.
24. # Print out the instance information in a formatted string
25. print(
26. f"{ClusterName}, {InstanceType}, {NumberOfBrokerNodes}ea brokers, {CreationTime}, {State}"
27. )上記の例はリージョン別に全体のAWS MSK Clusterリストを出力するPythonコードです。
勿論、実運用で全ての作業に対してコードレビューをすることは現実的に難しいと思います。しかし、全ての作業は事前にコードを作成し、そのコードを基に文書を作成して同僚と事前レビューするプロセスを定着化することがシステムの安定的な運用に効果的です。また、全ての作業の内訳をコードに残すことが、今後の同じ作業を行うときに役立つのでお勧めします。
ここまでArgoCD、GitOpsの事例を説明しました。GitOpsはポリシーなのでこれを守る意思が重要です。コードレビューを欠かさず、作業プロセスを守る日々の努力が必要です。