copied!

SRE として EKS を利用した環境のアプリケーションの運用をしています。そこで ArgoCD を利用しているので、今回は ArgoCD について紹介しようと思います。

[ArgoCD] 導入編

Shohei Masuyama

2020.5.29

copied!

こんにちは、Sreake の増山です。
主に SRE として EKS を利用した環境のアプリケーションの運用をしています。
そこで ArgoCD を利用しているので、今回は ArgoCD について紹介しようと思います。

ArgoCDとは

Kubernetes 環境で GitOps でデプロイする CD ツールです。
Helm や Kustomize などで記載した Manifest を Deploy できます。
似たツールとして Flux がありますが、ArgoCD では以下がメリットかと思います。

GitOps なので、PR による Diff はもちろん Deploy 前に Manifest の差分を kubectl diffとして確認できる
デプロイしたアプリケーションが可視化される (デプロイの様子も可視化される)

今回は EKS (1.15) 環境で Helm で管理しているアプリケーションを例に書いていきます。

※GitOpsとはGitリポジトリを、インフラストラクチャの構築とアプリケーションのデプロイに関わるすべてのコードの唯一の情報源として使用することを指します。

参考： https://www.weave.works/technologies/gitops/

インストール手順

公式の手順通りインストールしていきます。

kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

各 Pod が立ち上がり次第、ポートフォワードでアクセスできます。

$ kubectl get pod -n argocd
NAME                                                                       READY   STATUS    RESTARTS   AGE
argocd-application-controller-5f649bb745-24rkn   1/1     Running   0          51s
argocd-dex-server-58846d888-z22bv                     1/1     Running   0          51s
argocd-redis-fc585c648-fr4gl                                   1/1     Running   0          51s
argocd-repo-server-75b76ffb57-ddlk9                     1/1     Running   0          51s
argocd-server-75f9b64869-jcl9x                              1/1     Running   0          51s

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

# インストール時点で組み込みユーザが用意されており、Username: admin, Password: argocd-serverのPod名(↓コマンドで取得)でログインできます。
$ kubectl get pod -n argocd -l app.kubernetes.io/name=argocd-server

※ admin ユーザのパスワードを初期化したい場合、 kubectl edit secret argocd-secret -n argocd で admin.password, admin.passwordMtimeの2つを削除し、 argocd-serverを再起動することで Password が現在の Pod の値になります。

これでデプロイ可能な状態が整いました。
とりあえず、何かをデプロイしてみたい場合はこちらが良いと思います。

次にデプロイの単位について見ていきます。

デプロイの単位

ArgoCD では、Application CRD (以下 Application) でデプロイを管理します。
Application で Helm (またはGit) リポジトリを参照し、Application をデプロイすることで Chart 内のマニフェストをデプロイできます。

# aws-alb-ingress-controller のサンプル
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: aws-alb-ingress-controller
  namespace: argocd
spec:
# どのAppProjectに所属させるかを指定します。
# AppProjectはArgoCDのCRDで、ユーザの権限を制限する場合などに利用出来ます。
# ここでは、最初から存在するdefaultを利用します。
  project: default
# デプロイ先を設定します。
# ここでは、ArgoCDのクラスタを指していますが、別Clusterを指定することも出来ます。
  destination:
    namespace: kube-system
    server: https://kubernetes.default.svc
# Helmリポジトリを指定します。Gitリポジトリも指定可能です。
# Gitリポジトリの指定方法
#   source:
#      repoURL: https://github.com/argoproj/argocd-example-apps.git
#      ブランチ、タグなどが指定可能です
#      targetRevision: HEAD
#      Chartのpathを指定します。
#      path: guestbook
  source:
    chart: aws-alb-ingress-controller
    repoURL: http://storage.googleapis.com/kubernetes-charts-incubator
    targetRevision: 0.1.10
    helm:
      parameters:
      - name: clusterName
        value: hogehoge
      ...

公式サンプル: https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/

また、複数の Chart をデプロイする際に ArgoCD では Application 内で複数のApplicationを管理することで、グルーピングすることができます。
例えば、Namespace を1つの Application とし、その Application 内で複数の Application を定義するなどです。

Helm でこのようにグルーピング化する場合、Application で指定するHelm (またはGit) リポジトリの Chart に複数の Application を指定する必要があります。

Git リポジトリのサンプルです。

$ tree
.
├── charts
│   ├── Chart.yaml
│   └── templates
│       ├── applicationA.yaml
│       ├── applicationB.yaml
│       ├── applicationC.yaml
│       └── applicationD.yaml
└── default.yaml

$ cat default.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: default
  namespace: argocd
spec:
  project: default

source:
    repoURL: GitリポジトリのURL
    targetRevision: master
    path: charts

destination:
    server: https://kubernetes.default.svc
    namespace: argocd

syncPolicy:
    automated:
      prune: false
      selfHeal: true