今回やること

ようやくArgoの出番がやってきました。

今回は前回までに構築した以下の環境にArgo CDを立てて、GitOpsなデプロイを体験しようと思います。

このシリーズの記事
Terraformを使ってArgo CDによるGitOpsなリリースができるEKS環境を構築してみる（前編～TerraformでAWSリソースを構築してみた～）
Terraformを使ってArgo CDによるGitOpsなリリースができるEKS環境を構築してみる（中編～AWS Load Balancer Controller使ってみた～）
Terraformを使ってArgo CDによるGitOpsなリリースができるEKS環境を構築してみる（後編～Argo CDでGitOpsなデプロイやってみた～）←今回はこちら

Argo CDのインストール

以下の通りArgo用のNameSpaceを作り、提供されているArgo CDの資材を使ってインストールします。

$ kubectl create namespace argocd
namespace/argocd created

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-applicationset-controller created
serviceaccount/argocd-dex-server created
…(以下省略)

インストールはこれだけです。

この後の設定は、GUIで進めていくこととします。
ポートフォワーディングなどの方法でArgoにアクセスすることができます。

ログインすると以下のような画面が表示されます。

GitOpsなデプロイの流れを確認する

設定を進める前に、デプロイの流れを整理することとします。
図解すると、以下①～⑧の流れとなります。

AP用リポジトリには、Nginx用のDockerfileとNginxの設定ファイル、index.htmlを格納しておきます。(記載は割愛)
マニフェスト用リポジトリには、deployment.yaml(以下)を格納しておきます。

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: dev-ap
  name: dev-ap-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dev-ap-deployment
  template:
    metadata:
      labels:
        app: dev-ap-deployment
    spec:
      containers:
　      #イメージのURLに対する変更のプルリクエストをマージすることにより、書き換えられる
      - image: 111122223333.dkr.ecr.ap-northeast-1.amazonaws.com/otameshi-ecr:latest
        name: dev-ap-pod

CodeBuildは最新のAPのソースコードに基づくコンテナイメージをbuildしECRにプッシュした後、マニフェスト用リポジトリにプルリクエストを送ります。

Argo CDの設定

デプロイの流れを踏まえて、Argo CDの設定を進めていきます。

Argoにマニフェスト用リポジトリを登録します。

URLや認証情報、にリポジトリへの疎通性に問題がなければ、Successfulとなります。

次に、アプリケーションの登録です。どのリポジトリを監視してどのKubernetesクラスターに同期するのかといった設定を行います。先ほど登録したManifest用リポジトリと、EKSの情報を入力します。

こちらも問題なければ、アプリケーションが登録されます。

以上でArgo CDがリポジトリに格納されているマニフェストの変更を検知し、同期を行う状態が整いました。

動作確認

さていよいよデプロイです。
アプリ屋さんになりきって、AP用ソースコードのPushとBuild実行を行います。
そのあと、インフラ屋さんになりきって、Manifest用リポジトリへのマージを行います。
すると、Argoがよしなにデプロイしてくれるというプランです。

AP用ソースコードのPush

今回はNginxのトップ画面のメッセージを変えるだけなので割愛します。

Build実行

CodeBuildをビルド実行し、成功を見届けます。

プルリクエストのマージ実行

マニフェスト用リポジトリのプルリクエストを確認すると、先ほどのBuild処理で発行されたプルリクエストが確認できました。

コンテナイメージのURL部分をBuild処理でPushしたイメージのものに変更するプルリクエストであることが確認できました。

Argoによる同期処理

マージを実行後、Argoのコンソールを表示すると、APP HEALTHがProgressing状態になっています。マージの反映を検知し、デプロイ処理が実行され、その後の疎通性をチェックしていることがわかります。

APP HEALTHがHealthyとなった後、アプリにアクセスすると、しっかり変更が反映されていることが確認できました。

ここまでのまとめ

極めて単純なパターンでしたが、Argo CDによるGitOpsなデプロイを体験することができました。
マニフェストリポジトリにマージしてしまったらArgoが勝手にデプロイまでやってくれてしまう自動化感が素晴らしいのですが、今動いているアプリ=マニフェスト用リポジトリのmainブランチと同期されている点や、プルリクエストのID=AP用リポジトリのコミットIDとしておくことで、アプリの変更履歴が追えるというのも実運用上では大きなメリットになりそうです。

現状はまだCIOpsなデプロイ方式が主流のようですが、今後、スタンダードになっていくことも視野に入れてGitOps事情をキャッチアップしていきたいですね。

ということで、前編・中編・後編と3部作になってしまいましたが、以上で完結です。皆様のご参考になれば幸いです。