ConfigMap 系

はじめに

本サイトにつきまして、【IT技術の知見】はじめに - 俺の技術ノート をご認識のほど宜しくお願いいたします。

01. 専用 ConfigMap

ArgoCD の各コンポーネントの機密でない変数やファイルを管理する。

ConfigMap では、.metadata.labels キー配下に、必ず app.kubernetes.io/part-of: argocd キーを割り当てる必要がある。

• Declarative Setup - Argo CD - Declarative GitOps CD for Kubernetes

02. argocd-cm (必須)

argocd-cm とは

ArgoCD の各コンポーネントで共通する値を設定する。

• argo-cd/docs/operator-manual/argocd-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub

exec

▼ exec とは

ArgoCD の Exec 機能を設定する。

▼ exec.enabled

Exec 機能を有効化する。

kubectl exec コマンドのようにして、ArgoCD のダッシュボード上からコンテナにログインできる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  exec.enabled: "true"

argocd-server に紐づける ClusterRole では、Pod の exec リソースと create アクションを許可する必要がある。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: argocd
  name: argocd-server
  labels:
    app.kubernetes.io/part-of: argocd
rules:
  - apiGroups:
      - ""
    resources:
      - pods/exec
    verbs:
      - create

• Web-based Terminal - Argo CD - Declarative GitOps CD for Kubernetes
• Kubernetes: RBACの設定におけるAPIリソース #kubernetes - Qiita

▼ exec.enabled

すべてのコンテナに Exec できるわけではなく、ArgoCD がサポートしているシェルでログインできるコンテナにのみ、Exec が可能である。

ログイン時に使用できるシェルを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  exec.shells: bash,sh,powershell,cmd

• Web-based Terminal - Argo CD - Declarative GitOps CD for Kubernetes

application.instanceLabelKey

▼ application.instanceLabelKey とは

Kubernetes リソースや子 Application が親 Application を識別するためのラベルのキー名を設定する。

デフォルトは app.kubernetes.io/instance キーであり、コンフリクトしやすいキー名なため、変更したほうがよい。

ラベルのキー名は 1 個しか設定できない。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  application.instanceLabelKey: argocd.argoproj.io/instance

• argo-cd/docs/operator-manual/argocd-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub

▼ ラベル挿入のタイミング

argocd.argoproj.io/instance ラベルの挿入は、application-controller が実行する。

そのため挿入のタイミングは、マニフェスト作成のタイミングではなく、Sync の直前である。

ConfigMap や Secret のファイル変更に合わせてチェックサム値を更新するようなロジックがチャートあったとしても、repo-server がマニフェスト作成時に argocd.argoproj.io/instance ラベルを挿入するわけではないので、チェックサム値は変更にならない。

なお、CRD には挿入しない仕様になっている。

• argo-cd/controller/sync.go at v2.6.0 · argoproj/argo-cd · GitHub

▼ Root の Application 名の重複

単一の Kubernetes Cluster で Namespaced スコープの ArgoCD を構築しているとき、Root の Application を default という AppProject へ配置すると、この問題が起こりうる。

default の AppProject に所属した Application は、Namespaced スコープの application-controller であって、他の Namespace も見てしまうようである。

Root の Application 名が重複している場合、たとえ Namespace が異なっていても、Namespace 間で Root の Application を共有してしまう。

ちなみに、Cluster スコープの ArgoCD に限り、.spec.sourceNamespaces キーを使用して、この重複を許可できる。

• ArgoCD overrides application with the same name evenso namespace and project-name is differnt. · Issue #9420 · argoproj/argo-cd · GitHub
• Mixed applications when multiple ArgoCD has applications with same name · Issue #2352 · argoproj/argo-cd · GitHub
• Locking "App Of Apps" to a single project and namespace · Issue #2785 · argoproj/argo-cd · GitHub

application.resourceTrackingMethod

▼ application.resourceTrackingMethod とは

トラッキング ID を有効化する。

• label (argocd.argoproj.io/instance ラベルを指す)
• annotation+label
• annotation

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  application.resourceTrackingMethod: annotation

• Resource Tracking - Argo CD - Declarative GitOps CD for Kubernetes
• ArgoCD Tracking IDについて - CyberAgent SRG #ca_srg

globalProjects

▼ globalProjects とは

グローバルスコープを持つ親 AppProject と、その設定値を継承させる子 AppProject を指定する。

labelSelector キーで、子 Project の条件を設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  globalProjects: |
    - projectName: foo-global-project
      labelSelector:
        matchExpressions:
          - key: opt
            operator: In
            values:
              - prd

# グローバルスコープを持つ親 AppProject
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: foo-global-project
spec: ...

• Projects - Argo CD - Declarative GitOps CD for Kubernetes

kustomize.buildOptions

▼ kustomize.buildOptions とは

Kustomize の実行時に、コマンドに渡すオプションを設定する。

特に、Kustomize のプラグイン (例：KSOPS など) を使用する場合、--enable-alpha-plugins オプションと --enable-exec オプションを有効化する必要がある。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.buildOptions: --enable-alpha-plugins --enable-exec

なお、kustomize.path.<バージョン> オプションを使用している場合、kustomize.buildOptions.<バージョン> オプションの使用が必須であり、バージョンごとにオプションを設定できる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.buildOptions.v1.0.0: --enable-alpha-plugins --enable-exec
  kustomize.buildOptions.v2.0.0: --enable-alpha-plugins --enable-exec

• Kustomize - Argo CD - Declarative GitOps CD for Kubernetes

kustomize.path.<バージョン>

▼ kustomize.path.<バージョン>とは

デフォルトの Kustomize のバージョン以外のものも使用したい場合、そのバージョンと、バイナリファイルの置き場所を設定する。

ArgoCD で 1 つのバージョンの Kustomize しか使用しない場合、kustomize.path.<バージョン> で /usr/local/bin/kustomize を指定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.path.v1.0.0: /usr/local/bin/kustomize

複数のバージョンの Kustomize を使用できる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.path.v1.0.0: /usr/local/bin/kustomize_1_0_0
  kustomize.path.v2.0.0: /usr/local/bin/kustomize_2_0_0

▼ 各 Application で Kustomize を使用する

Application の .spec.kustomize.version キーで、使用する Kustomize のバージョンを指定する。

各 Application で異なるバージョンの Kustomize を指定できる。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: foo-application
  namespace: argocd
spec:
  repoURL: https://github.com/hiroki-hasegawa/foo-manifests.git
  targetRevision: main
  path: .
  kustomize:
    version: v1.0.0

• Kustomize - Argo CD - Declarative GitOps CD for Kubernetes

oidc.config

▼ oidc.config とは

OIDC を使用して、ArgoCD へログインできるようにする。

▼ 委譲先 Web サイトに直接的に接続する場合

ArgoCD から認証フェーズの委譲先の ID プロバイダーに情報を直接的に接続する。

OIDC の ID プロバイダー (例：Auth0、AWS Cognito、GitHub、Google Cloud Auth、Keycloak、Zitadel) が発行したクライアント ID やクライアントシークレットを設定する。

ここでは、プライベートなマニフェストリポジトリが異なるレジストリにあるとしており、複数の Secret が必要になる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
data:
  admin.enabled: "true"

  # OIDC に必要な ID やトークンを設定する
  oidc.config: |
    connectors:
      - type: github
        id: github
        name: GitHub SSO
        config:
          clientID: *****
          clientSecret: *****
        # dex-server が認可レスポンスによるリダイレクトを受信する URL を設定する
        redirectURI: https://<ArgoCDのドメイン>/api/dex/callback

  # ArgoCD のダッシュボードの Node 外公開 URL を設定する
  # 開発環境では、https://127.0.0.1:8080
  url: <URL>

• Overview - Argo CD - Declarative GitOps CD for Kubernetes
• External URL Links - Argo CD - Declarative GitOps CD for Kubernetes
• Authentication Through GitHub | Dex

▼ Dex を介して委譲先 Web サイトに接続する場合

ArgoCD から認証フェーズの委譲先の ID プロバイダーに直接的に接続するのではなく、ハブとしての Dex を使用する。

Dex は dex-server コンテナとして稼働させる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
data:
  admin.enabled: "true"

  # 必要な ID やトークンを設定する。
  dex.config: |
    connectors:
      - type: github
        id: github
        name: GitHub SSO
        config:
          clientID: *****
          clientSecret: *****
        # dex-server が認可レスポンスによるリダイレクトを受信する URL を設定する
        redirectURI: https://<ArgoCDのドメイン>/api/dex/callback

  # ArgoCD のダッシュボードの Node 外公開 URL を設定する。
  # 開発環境では、https://127.0.0.1:8080
  url: <URL>

• Authentication Through GitHub | Dex
• Overview - Argo CD - Declarative GitOps CD for Kubernetes
• External URL Links - Argo CD - Declarative GitOps CD for Kubernetes

repositories

▼ repositories とは

ConfigMap でリポジトリの URL を管理する方法は、将来的に廃止される予定である。

• Declarative Setup - Argo CD - Declarative GitOps CD for Kubernetes

resource.customizations.ignoreDifferences.all

▼ resource.customizations.ignoreDifferences.all とは

ArgoCD 全体で .spec.ignoreDifferences キーと同じ機能を有効化する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  resource.customizations.ignoreDifferences.all: |
    jsonPointers:
      # .spec.replicas キー (インスタンス数) の設定値の変化を無視する。
      - /spec/replicas
    jqPathExpressions:
      # .spec.metrics (ターゲット対象のメトリクス) の自動整形を無視する。
      - /spec/metrics

• Diff Customization - Argo CD - Declarative GitOps CD for Kubernetes

03. argocd-cmd-params-cm

argocd-cmd-params-cm とは

ArgoCD の各コンポーネント (application-controller、dex-server、redis-server、repo-server) の起動コマンドに渡すオプションを設定する。

• argo-cd/docs/operator-manual/argocd-cmd-params-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub
• Additional configuration method - Argo CD - Declarative GitOps CD for Kubernetes

複数コンポーネント

複数コンポーネントの起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # application-controller と argocd-server
  # Application の作成を許可したい Namespace を設定する
  application.namespaces: foo-application-ns

• Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes
• Application in any namespace | Synced with NO resources deployed · Issue #11638 · argoproj/argo-cd · GitHub

application-controller

application-controller の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # Application の作成を許可したい Namespace を設定する
  application.namespaces: foo
  controller.log.format: text
  controller.log.level: warn
  controller.operation.processors: "10"
  controller.repo.server.timeout.seconds: "60"
  controller.self.heal.timeout.seconds: "5"
  controller.status.processors: "20"
  otlp.address: ""

redis-server

redis-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  redis.server: argocd-redis:6379

repo-server

repo-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  repo.server: argocd-repo-server:8081
  reposerver.log.format: text
  reposerver.log.level: warn
  reposerver.parallelism.limit: "0"

argocd-server

argocd-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  server.basehref: /
  server.dex.server: https://argocd-dex-server:5556
  server.dex.server.strict.tls: "false"
  server.disable.auth: "false"
  server.enable.gzip: "false"
  # ロードバランサーで、リクエストを HTTP でフォワーディングするように設定している場合、argocd-server で HTTP リクエストの受信を許可する
  server.insecure: "true"
  server.log.format: text
  server.log.level: warn
  server.repo.server.strict.tls: "false"
  server.rootpath: ""
  server.staticassets: /shared/app
  server.x.frame.options: sameorigin

04. argocd-rbac-cm

ArgoCD を構成する Kubernetes リソースにリクエストを送信するための認可スコープを紐付ける。

• argo-cd/docs/operator-manual/argocd-rbac-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub
• RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes

認可スコープの設定

▼ 記法

Casbin の記法を使用して、ロールと認可スコープを定義しつつ、これをグループ名に紐付ける。

readonly と admin というロールは、デフォルトで定義済みである。

記号	項目	説明
p (パーミッション)	p, <ロール名> <Kubernetesリソースの種類> <アクション名> <AppProject名>/<ApplicationのNamespace名>/<Application名>	ロールと ArgoCD 系リソースの認可スコープを定義する。代わりに、Role や ClusterRole でも定義できる。
g (グループ)	g, <グループ名> <ロール名>	グループにロールを紐付ける。

• https://stackoverflow.com/a/73784100
• RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes
• argo-cd/assets/model.conf at v2.6.0 · argoproj/argo-cd · GitHub
• argo-cd/assets/builtin-policy.csv at v2.6.0 · argoproj/argo-cd · GitHub
• Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes

ArgoCD で認証する場合

ロールに付与するポリシーの認可スコープは、AppProject 単位にするとよい。

AppProject に所属する ArgoCD 系リソースのみへのアクセスを許可すれば、結果として特定の Cluster へのデプロイのみを許可したことになる。

管理チーム (app、infra) 単位で AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

これにより、その管理チームに所属するエンジニアしか Sync できなくなる。

• app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
• infra ロールに、infra のみを操作できる認可スコープ
• maintainer ロールに、app と infra の両方を操作できる認可スコープ
• 認証グループに該当する認可ロールがなければ、readonly になる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # グループにロールを紐付ける。
    g, app-team, role:app
    g, infra-team, role:infra
    g, admin, role:maintainer
  scopes: "[groups]"

• Argo CDにおける認可設定 - decadence
• Argo CD における LDAP 認証と、LDAP グループを利用した権限制御 #kubernetes - Qiita
• argo-cd/assets/builtin-policy.csv at v2.6.0 · argoproj/argo-cd · GitHub
• GitOpsをArgoCDで学ぶ
• MLOpsマルチテナントクラスタへのArgo CDの導入と運用 - ZOZO TECH BLOG

実行環境 (dev、prd) 別に AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

• developer ロールに、開発環境の AppProject 内に所属する ArgoCD 系リソースのみを操作できる認可スコープ
• maintainer ロールに、開発環境と本番環境の両方を操作できる認可スコープ
• 認証グループに該当する認可ロールがなければ、readonly になる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと認可スコープを定義する
    p, role:developer, *, *, dev/*, allow
    p, role:maintainer, *, *, dev/*, allow
    p, role:maintainer, *, *, prd/*, allow

    # グループにロールを紐付ける
    g, developers, role:developer
    g, maintainers, role:maintainer
  scopes: "[groups]"

ArgoCD の認証を ID プロバイダーに委譲する場合 (SSO の場合)

▼ ID プロバイダーのチームに紐付ける場合

ID プロバイダーに委譲する場合、グループ名は ID プロバイダーで認証されたものにする必要がある。

ID プロバイダー側で、チームによる認証グループがすでに存在しているとする。

以下のように、ロールと認可スコープを紐付ける。

• app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
• infra ロールに、infra のみを操作できる認可スコープ
• maintainer ロールに、app と infra の両方を操作できる認可スコープ
• 認証グループに該当する認可ロールがなければ、readonly になる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと ArgoCD 系リソースの認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # ID プロバイダーで認証されたグループにロールを紐付ける
    g, example-org.github.com:app-team, role:app
    g, example-org.github.com:infra-team, role:infra
    g, example-org.github.com:maintainer, role:maintainer
  scopes: "[groups]"

ID プロバイダー側で、チームによる認証グループがすでに存在しているとする。

実行環境 (dev-*、prd-*) 別に AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

以下のように、ロールと認可スコープを紐付ける。

• app ロールに、dev-app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
• infra ロールに、dev-infra のみを操作できる認可スコープ
• maintainer ロールに、dev-app と dev-infra の両方を操作できる認可スコープ
• 認証グループに該当する認可ロールがなければ、readonly になる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと ArgoCD 系リソースの認可スコープを定義する
    p, role:app, *, *, dev-app/*, allow
    p, role:infra, *, *, dev-infra/*, allow
    p, role:maintainer, *, *, dev-app/*, allow
    p, role:maintainer, *, *, dev-infra/*, allow

    # ID プロバイダーで認証されたグループにロールを紐付ける
    g, example-org.github.com:app-team, role:app
    g, example-org.github.com:infra-team, role:infra
    g, example-org.github.com:maintainer, role:maintainer
  scopes: "[groups]"

• Argo CD で 個人の Github アカウントでログインして権限管理をする - hatappi.blog
• RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes
• argo-cd/assets/builtin-policy.csv at v2.6.0 · argoproj/argo-cd · GitHub

▼ ID プロバイダーのメールアドレスに紐付ける場合

ID プロバイダー側で、メールアドレスによる認証グループがすでに存在しているとする。

以下のように、ロールと認可スコープを紐付ける。

• app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
• infra ロールに、infra のみを操作できる認可スコープ
• maintainer ロールに、app と infra の両方を操作できる認可スコープ
• 認証グループに該当する認可ロールがなければ、readonly になる。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと ArgoCD 系リソースの認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # ID プロバイダーで認証されたグループにロールを紐付ける
    g, app-team@gmail.com, role:app
    g, infra-team@gmail.com, role:infra
    g, maintainer@gmail.com, role:maintainer
  scopes: "[email]"

• Argo CD で 個人の Github アカウントでログインして権限管理をする - hatappi.blog
• argo-cd/assets/builtin-policy.csv at v2.6.0 · argoproj/argo-cd · GitHub

05. サーバー証明書系 ConfigMap

サーバー証明書系 ConfigMap とは

argocd-server、repo-server、dex-server、は HTTPS リクエストを受信できる。

これらのコンポーネントに HTTPS リクエストを送信する場合、ConfigMap 上のサーバー証明書をクライアント側のコンテナにマウントする必要がある。

反対に HTTP リクエストを送信する場合は、この ConfigMap が不要である。

ConfigMap 上のサーバー証明書の代わりに、ArgoCD 外のサーバー証明書 (例：Cert Manager) を使用してもよい。

• TLS configuration - Argo CD - Declarative GitOps CD for Kubernetes

argocd-dex-server-tls

argocd-server は dex-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。

• TLS configuration - Argo CD - Declarative GitOps CD for Kubernetes

argocd-repo-server-tls

application-controller、argocd-server、は repo-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。

• TLS configuration - Argo CD - Declarative GitOps CD for Kubernetes

argocd-server-tls

クライアントは argocd-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。

• TLS configuration - Argo CD - Declarative GitOps CD for Kubernetes

argocd-tls-certs-cm

ArgoCD は、ArgoCD の外 (特にリポジトリ) に HTTPS リクエストを送信する。

ArgoCD では、コンテナイメージの /etc/ssl ディレクトリにデフォルトのサーバー証明書が配置されているが、ユーザー定義のサーバー証明書を使用したい場合がある。

この ConfigMap は、そのためにユーザーが定義したサーバー証明書を管理する。

• Declarative Setup - Argo CD - Declarative GitOps CD for Kubernetes
• argo-cd/docs/operator-manual/argocd-tls-certs-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub

06. argocd-ssh-known-hosts-cm

SSH 公開鍵認証でリポジトリに接続してポーリングする場合、argocd-server で必要な known_hosts ファイルを設定する。

known_hosts ファイルには、SSH プロコトルに必要なホスト名や秘密鍵を設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-ssh-known-hosts-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  ssh_known_hosts: |
    bitbucket.org ssh-rsa AAAAB ...
    github.com ecdsa-sha2-nistp256 AAAAE ...
    github.com ssh-ed25519 AAAAC ...
    github.com ssh-rsa AAAAB ...
    gitlab.com ecdsa-sha2-nistp256 AAAAE ...
    gitlab.com ssh-ed25519 AAAAC ...
    gitlab.com ssh-rsa AAAAB ...
    ssh.dev.azure.com ssh-rsa AAAAB ...
    vs-ssh.visualstudio.com ssh-rsa AAAAB ...

• argo-cd/docs/operator-manual/argocd-ssh-known-hosts-cm.yaml at v2.6.0 · argoproj/argo-cd · GitHub

07. 環境変数

application-controller

▼ ARGOCD_CONTROLLER_REPLICAS

application-controller のレプリカ数を設定する。

これを設定しないと、application-controller を冗長化しても、処理が片方のレプリカに偏ってしまう。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: argocd-application-controller
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: argocd-application-controller
          env:
            - name: ARGOCD_CONTROLLER_REPLICAS
              value: 2

argocd-server

▼ ARGOCD_API_SERVER_REPLICAS

argocd-server のレプリカ数を設定する。

これを設定しないと、argocd-server を冗長化しても、処理が片方のレプリカに偏ってしまう。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: argocd-server
          env:
            - name: ARGOCD_API_SERVER_REPLICAS
              value: 3