GKEにArgo CDを導入してアプリケーションをデプロイする
アーティスではいくつかのウェブアプリケーションをGoogle Kubernetes Engine上のk8sにデプロイしています。イメージをCloud Buildでビルドした後、マニフェスト用のリポジトリにPushがあるとCloud Buildで自動的にApplyを行っています。
現状でもとくに不満はないのですが、Argo CDが便利そうなので調査のためサンプルアプリケーションを動かしてみることにしました。
環境
- WSL2（Debian 10.4）
- GKE (1.16.8-gke.15)
ローカルのWSL2にArgoのCLIを入れて、GKE上のAPIにアクセスする構成です。
Argoについて
https://argoproj.github.io/https://github.com/argoproj/argo-cd/
k8s上でCI/CDをネイティブに実行するためのオープンソースなプロダクトです。
2020年6月23日時点で、CNCFのincubating projectになっています。
Argo CDではGitOps的な継続的デリバリが、Argo Rolloutsではブルーグリーンやカナリアでのデプロイメントができるようになります。
今回はArgo CDが対象です。
Argo CDのデプロイ
こちらの公式のドキュメントに従ってインストールします。
まず、Argo CD用の名前空間を作ります。
ここでは公式に従って argocd にします。
|
1 |
$ kubectl create namespace argocd |
名前空間を確認します。
|
1 2 3 |
$ kubectl get namespace NAME STATUS AGE argocd Active 2s |
作成できました。
次に、manifestをapplyします。
オプション「-n」で先ほど作成した名前空間を指定しています。
|
1 |
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml |
Podを確認します。
|
1 2 3 4 5 6 7 |
$ kubectl -n argocd get pod NAME READY STATUS RESTARTS AGE argocd-application-controller-d99d77688-krm8n 1/1 Running 0 2m argocd-dex-server-6c865df778-nhnfj 1/1 Running 0 2m argocd-redis-8c568b5db-5r4xf 1/1 Running 0 2m argocd-repo-server-675bddcbb8-lmlwx 1/1 Running 0 2m argocd-server-75877b6ffb-n865m 1/1 Running 0 2m |
Serviceも確認しておきます。
|
1 2 3 4 5 6 7 8 |
$ kubectl -n argocd get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE argocd-dex-server ClusterIP 10.60.12.12 <none> 5556/TCP,5557/TCP,5558/TCP 2m45s argocd-metrics ClusterIP 10.60.10.249 <none> 8082/TCP 2m45s argocd-redis ClusterIP 10.60.5.186 <none> 6379/TCP 2m45s argocd-repo-server ClusterIP 10.60.12.235 <none> 8081/TCP,8084/TCP 2m45s argocd-server ClusterIP 10.60.4.94 <none> 80/TCP,443/TCP 2m44s argocd-server-metrics ClusterIP 10.60.10.33 <none> 8083/TCP 2m45s |
これでArgoのGUIとAPIサーバーがデプロイできました。
https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control?hl=ja#iam-rolebinding-bootstrap
argocd CLIをインストール
今回はWSL2環境にインストールするので、こちらの公式ページに従ってCurl経由でインストールします。
バージョン名を取得します。
|
1 2 3 |
$ VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/') $ echo $VERSION v1.6.1 |
現時点では、v1.6.1が最新のようです。
続いて、以下のコマンドで /usr/local/bin にバイナリをダウンロードし実行権限を付与します。
|
1 2 |
$ sudo curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64 $ sudo chmod +x /usr/local/bin/argocd |
バージョンを確認します。
APIサーバー側のバージョンも表示してくれるようですが、まだ疎通していないのでエラーが表示されます。
|
1 2 3 4 5 6 7 8 9 |
$ argocd version argocd: v1.6.1+159674e BuildDate: 2020-06-19T00:39:46Z GitCommit: 159674ee844a378fb98fe297006bf7b83a6e32d2 GitTreeState: clean GoVersion: go1.14.1 Compiler: gc Platform: linux/amd64 FATA[0000] Argo CD server address unspecified |
次に、外部からArgo CDのAPIサーバーへ疎通させるため既存のserviceを修正します。
今回は、Load Balancerを選択します。
公式にはIngressやポートフォワーディングでの設定も記載されてますので、適宜参照してください。
|
1 |
$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}' |
serviceのTYPEが LoadBalancer になって外部IPが予約されていることが確認できます。
|
1 2 3 4 5 6 7 8 |
kubectl -n argocd get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE argocd-dex-server ClusterIP 10.60.12.12 <none> 5556/TCP,5557/TCP,5558/TCP 27m argocd-metrics ClusterIP 10.60.10.249 <none> 8082/TCP 27m argocd-redis ClusterIP 10.60.5.186 <none> 6379/TCP 27m argocd-repo-server ClusterIP 10.60.12.235 <none> 8081/TCP,8084/TCP 27m argocd-server LoadBalancer 10.60.4.94 **.**.**.*** 80:30764/TCP,443:30817/TCP 27m argocd-server-metrics ClusterIP 10.60.10.33 <none> 8083/TCP 27m |
もう一度バージョンを表示させると、APIサーバーのバージョンも表示されることが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
$ argocd version argocd: v1.6.1+159674e BuildDate: 2020-06-19T00:39:46Z GitCommit: 159674ee844a378fb98fe297006bf7b83a6e32d2 GitTreeState: clean GoVersion: go1.14.1 Compiler: gc Platform: linux/amd64 argocd-server: v1.6.1+159674e BuildDate: 2020-06-19T00:41:05Z GitCommit: 159674ee844a378fb98fe297006bf7b83a6e32d2 GitTreeState: clean GoVersion: go1.14.1 Compiler: gc Platform: linux/amd64 Ksonnet Version: v0.13.1 Kustomize Version: {Version:kustomize/v3.6.1 GitCommit:c97fa946d576eb6ed559f17f2ac43b3b5a8d5dbd BuildDate:2020-05-27T20:47:35Z GoOs:linux GoArch:amd64} Helm Version: version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"} Kubectl Version: v1.14.0 |
CLIでログインする
初期のパスワードは以下のコマンドで取得できます。
|
1 |
$ kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2 |
上記のパスワードを使ってログインします。
初期のユーザー名は admin になっています。
|
1 2 3 4 5 6 |
$ argocd login **.**.**.*** WARNING: server certificate had error: x509: cannot validate certificate for **.**.**.*** because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y Username: admin Password: 'admin' logged in successfully Context '**.**.**.***' updated |
初期のパスワードを変更しておきます。
|
1 2 3 4 5 6 |
$ argocd account update-password *** Enter current password: *** Enter new password: *** Confirm new password: Password updated Context '**.**.**.***' updated |
今回は、アプリケーションをデプロイするクラスター自体にArgo CDもデプロイしたので、この設定は必要ありません。
この設定からもわかるように、外部クラスタから複数のクラスタをオーケストレーションすることもできます。
アプリケーションをデプロイする
最後にGUIからアプリケーションをデプロイしてみます。
先程の外部IPにアクセスしてログインしてアプリケーションを追加するのですが、今回は公式のサンプルアプリをデプロイしてみます。
以下のようにアプリケーションを登録します。
| 項目 | 値 |
|---|---|
| Application Name | guestbook |
| Project | default |
| Repository URL | https://github.com/argoproj/argocd-example-apps.git |
| Revision | HEAD |
| Path | guestbook |
| Cluster | https://kubernetes.default.svc |
| Namespace | default |
Pathにリポジトリ内の特定のディレクトリを指定できるので、他のマニフェストが混在していても、 対象のアプリケーションのみデプロイできます。
Namespaceは今回はテストのため default にしました。
登録が完了すると OutOfSync 状態になり、SYNCすることでデプロイされます。
CLIからも問題なくデプロイされていることが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$ argocd app get guestbook Name: guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://**.**.**.***/applications/guestbook Repo: https://github.com/argoproj/argocd-example-apps.git Target: HEAD Path: guestbook SyncWindow: Sync Allowed Sync Policy: <none> Sync Status: Synced to HEAD (6bed858) Health Status: Healthy GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default guestbook-ui Synced Healthy service/guestbook-ui created apps Deployment default guestbook-ui Synced Healthy deployment.apps/guestbook-ui created |
まとめ
k8s以前では、このような便利なサービスをデプロイするのに時間がかかっていましたが、 現在ではマニフェストを流すだけになり、とても便利になりました。
その反面、CI/CDのサイクルを短くするために、フローも複雑化し、初期のパイプラインの設定が難しくなります。
Argo CDは、GitOpsでのフローを提示してくれているので、そのルールに従えば GitHubとクラスタさえあれば、すぐにGitOpsできる手軽さが魅力です。
tkr2f
最新記事 by tkr2f (全て見る)
- google/wireを使ってGoでDI(dependency injection)してみる - 2020年8月6日
- GKEにArgo CDを導入してアプリケーションをデプロイする - 2020年7月9日
- WSL2のDebianにAnsibleの最新版をインストールする - 2020年6月16日
- GKEのistioでサンプルアプリを動かす（フォールトインジェクション、タイムアウト編） - 2020年2月19日
- GKE（Google Kubernetes Engine）のistioでサンプルアプリを動かす【ルーティング編】 - 2020年1月31日
おすすめ関連記事
最新記事
