EKSでArgo CDのチュートリアルを試してみた

はじめに

おはようございます､加藤です｡GitOpsという言葉は聞いた事があるでしょうか？ Weaveworksが提唱する運用・CDの手法で､GitをインフラストラクチャのSingle Source of Truth(信頼できる唯一の情報源)として扱い､変更の承認はプルリクエストで行うというものです｡ 運用経験がある訳でもないので浅い理解ですが､下記のように捉えています｡

• インフラストラクチャを宣言的に管理
• Gitからインフラストラクチャへ同期し続ける
• Pull型アーキテクチャ

今回は､KubernetesでGitOpsを実現するツールのArgo CDをAmazon EKSで検証してみました｡

やってみた

ドキュメントのGetting Startedを参考に進めて行きます｡

環境情報

kubectl version

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-12-06T01:33:57Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.8-eks-7c34c0", GitCommit:"7c34c0d2f2d0f11f397d55a46945193a0e22d8f3", GitTreeState:"clean", BuildDate:"2019-03-01T22:49:39Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

ネームスペースの作成

Argo CDをデプロイするネームスペースを作成します｡

kubectl create namespace argocd

マニフェストファイルの編集に関して

Argo CDのGitHub Release v1.0.0を確認すると､kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yamlでデプロイするQuick Start手順が紹介されています｡(Getting Startedの方法は古いようです) ダウンロードして中身を確認すると､一行目に # This is an auto-generated file. DO NOT EDIT と記載されており､これを直接編集すべきで無いことがわかります｡

プロダクション環境では､ドキュメントのDeclarative Setup及び､リポジトリの､argo-cd/hack/update-manifests.shからKustomizeを使いマニフェストを生成することがわかります｡ 今回は簡易検証なので､マニフェストファイルを直接編集します｡

マニフェストファイルのダウンロード

マニフェストをローカルに保存します｡

curl -O [https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/v1.0.0/manifests/install.yaml)

初回デプロイ

ひとまず､デプロイしてみます｡

kubectl -n argocd apply -f install.yaml

パスワードの取得

Argo CDデフォルトでローカルユーザーadminが作成されます｡パスワードはargocd-serverのPod名なので確認します｡

kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2

ちなみに､ローカルユーザーは追加作成できません｡SSO環境を作成する必要があります｡ SSO Configuration - Argo CD - Declarative GitOps CD for Kubernetes

Webアクセス

Argo CDにアクセスするには､下記の3つの方法があります｡

• Service Type Load Balancer
• Ingress
• Port Forwarding

今回はPort Forwardingで接続します｡

kubectl port-forward svc/argocd-server -n argocd 8080:443

Webブラウザで､http://localhost:8080にアクセスします｡HTTPSにリダイレクトされ､ログイン画面にたどり着けました｡リダイレクト後に証明書エラーが発生しますが接続を続行してください｡ admin/先程取得したPod名でログインします｡

CLIアクセス

CLIツールをインストールします｡ポートフォワーディングを維持する必要があるので､別ターミナルを開き作業してください｡

brew tap argoproj/tap
brew install argoproj/tap/argocd

ログインします｡証明書エラーを回避する為に--insecureを指定しています｡指定しない場合は､対話型で続行を確認されます｡

argocd login --insecure localhost:8080
Username: admin
Password:
'admin' logged in successfully
Context 'localhost:8080' updated

パスワードを更新し､再ログインします｡

argocd account update-password
*** Enter current password:
*** Enter new password:
*** Confirm new password:
Password updated

argocd login --insecure localhost:8080
Username: admin
Password:
'admin' logged in successfully
Context 'localhost:8080' updated

HTTPアクセス

Argo CDにHTTPアクセスすると､HTTPSにリダイレクトされます｡これはIngressでALB経由でアクセスさせる際に問題になりそうです｡ HTTPの許可を調査・検証してみます｡

Deploymentのargocd-serverに--insecureオプションを与えれば良いみたいです｡install.yamlの2040行目の後ろに追記します｡

before

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  template:
    metadata:
      labels:
        app.kubernetes.io/name: argocd-server
    spec:
      containers:
      - command:
        - argocd-server
        - --staticassets
        - /shared/app

after

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  template:
    metadata:
      labels:
        app.kubernetes.io/name: argocd-server
    spec:
      containers:
      - command:
        - argocd-server
        - --staticassets
        - /shared/app
        - --insecure

ポートフォワーディングを解除して､更新を適用します｡更新が完了したら再度ポートフォワーディングで接続しますが､今度は443を80に変更して実行してください｡

kubectl apply -n argocd -f install.yaml
kubectl port-forward svc/argocd-server -n argocd 8080:80

ブラウザでアクセスし､HTTPSにリダイレクトされない事を確認できました｡

Ingress Configuration - Argo CD - Declarative GitOps CD for Kubernetes

しかし､ドキュメントにはALBはHTTP2/gRPCに完全対応していないので使えないという記載があります｡

AWS Application Load Balancers (ALBs) And Classic ELB (HTTP Mode) Neither ALBs and Classic ELB in HTTP mode, do not have full support for HTTP2/gRPC which is the protocol used by the argocd CLI. Thus, when using an AWS load balancer, either Classic ELB in passthrough mode is needed, or NLBs.

一方で､v0.12のリリース情報ではgRPC-Web (HTTP1.1)をサポートしたので､どんなロードバランサー､Ingress､API Gatewayでも動作すると記載されいます｡

Argo CD v0.12 Released – Argo Project

gRPC-Web Support The CLI is now able to communicate to the Argo CD API server using gRPC-Web (HTTP1.1) using a new CLI flag —grpc-web. This resolves some compatibility issues with ingresses and gRPC (HTTP2), and should enable the argocd CLI to work with virtually any load balancer, ingress controller, or API gateway.

これより先は､プロダクション向けにArgo CDを検証する際に調べて見ようと思います｡

ブラウザキャッシュのクリア

最初はHTTPSでつないでログインしていた状態からHTTPに変更した影響なので､ログインが正常に進まない状態になりました｡(ログインを実行すると失敗にならず､ログイン画面にリダイレクトされる) Cookieを消すと正常に戻りました｡同様の症状にかかった場合はお試しください｡

サンプルアプリのデプロイ

Argo CDはマニフェストファイルを定義する為に､以下の5つの方法に対応しています｡

• Kustomize applications
• Helm charts
• Ksonnet applications
• A directory of YAML/JSO/Jsonnet manifests
• Any custom config management tool configured as a config management plugin

Pluginsは柔軟な機能で､指定したバイナリを実行する事が可能です｡Helm + Kustomizeといった使い方や､バンドルされていないツールをCustom Toolで追加して使用する事が可能です｡

今回は､KustomizeによるYAMLマニフェストファイルによるデプロイを試してみます｡NEW APPLICATIONをクリックして､新規アプリを設定します｡

GENERAL

SOURCE

DESTINATION

Kustomize

作成したアプリはカード形式で表示されました｡クリックすると詳細画面へ進みます｡ リソースが可視化されています､とても見やすいです｡ 各リソース毎の詳細が確認でき､EDIT機能によってマニフェストファイルを編集(kubectl edit相当)することや､Podのログを見る事ができます｡ EDIT機能で､Deployment: argocd-sample-guestbook-uiのレプリカ数を変えてみました｡1個→2個への変更です｡ Diffの表記は一瞬混乱しましたが､現在の状態が左側でGitリポジトリが右側です｡今の状態にGitリポジトリの状態を適用するとどう変化するかをDiffで見る形です｡ DELETE機能でDeployment: argocd-sample-guestbook-uiを削除します｡ 配下のリソースを含めて削除されました｡また､リポジトリと差が発生している状態はOutOfSyncとステータスが表示されます｡ 現在､自動同期の設定ですが､Argo CDから行った変更に対しては自動で再同期がかかることはありませんでした｡ Automated Sync Policy - Argo CD - Declarative GitOps CD for Kubernetes

自動同期のドキュメントを確認すると､同じコミットハッシュに対しては一度しか自動同期が実行されないと記載されているので仕様どおりのようです｡

アプリケーションの削除

リソースが残っている状態で､アプリケーションを削除してみます｡ kubectlで確認するとリソースも削除されていました!!

あとがき

Argo CDの基本的な機能を触ってみました｡UIが美しく設定も直感的でした｡詰まったところとしては､ユーザーの作成方法やHTTP接続あたりです｡ 次回は､HAで構成でプロダクションに耐える形でのデプロイ方法を調査・検証してみようと思います｡

参考リンク

• Argo CD - Declarative GitOps CD for Kubernetes
• GitOps
• "GitOps": WeaveworksがCI/CD実践に使用する開発者モデルを公開