第5章 GitOps

現在、Red Hat OpenShift GitOps 1.8.4 は、OpenShift Container Platform 4.10 および 4.11 の latest チャネルでは利用できません。latest チャネルは GitOps 1.9.z によって採用されており、これは OpenShift Container Platform 4.12 以降のバージョンでのみリリースされます。

回避策として、gitops-1.8 チャネルに切り替えて新しい更新を入手します。GITOPS-3158

この更新の前に、.spec.dex パラメーターを使用して Dex を設定し、LOG IN VIA OPENSHIFT オプションを使用して Argo CD UI にログインしようとすると、ログインできませんでした。今回の更新でこの問題が修正されています。

今回の更新では、ApplicationSet プログレッシブロールアウト戦略機能のサポートを追加できます。この機能を使用すると、ArgoCD ApplicationSet リソースを拡張して、ApplicationSet 仕様またはアプリケーションテンプレートを変更した後に、漸進的なアプリケーションリソース更新のロールアウト戦略を組み込むことができます。この機能を有効にすると、アプリケーションは同時にではなく、宣言された順序で更新されます。GITOPS-956

今回の更新では、Red Hat OpenShift GitOps Operator および kam CLI が OpenShift Container Platform の ARM アーキテクチャーで使用できるようになりました。GITOPS-1688

今回の更新では、Argo CD CR を使用して、コマンド引数をリポジトリーサーバーのデプロイに渡すことができます。GITOPS-2445

以下に例を示します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  repo:
    extraRepoCommandArgs:
      - --max.combined.directory.manifests.size
      - 10M

今回の更新の前は、ARGOCD_GIT_MODULES_ENABLED 環境変数を設定できるのは、openshift-gitops-repo-server Pod のみであり、ApplicationSet Controller Pod では、設定できませんでした。その結果、Git ジェネレーターを使用すると、変数が ApplicationSet Controller 環境にないため、子アプリケーションの生成中に Git サブモジュールが複製されました。さらに、これらのサブモジュールのクローンを作成するために必要な認証情報が ArgoCD で設定されていない場合、アプリケーションの生成は失敗しました。今回の更新で問題が修正されました。Argo CD CR を使用して、ArgoCD_GIT_MODULES_ENABLED などの環境変数を ApplicationSet Controller Pod に追加できるようになりました。その後、ApplicationSet Controller Pod は、複製されたリポジトリーから子アプリケーションを正常に生成し、その過程でサブモジュールは複製されません。GITOPS-2399

以下に例を示します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  applicationSet:
    env:
     - name: ARGOCD_GIT_MODULES_ENABLED
       value: "true"

今回の更新では、次の追加のサブキーを使用してリソースの動作をカスタマイズできます。

GITOPS-1561

今回の更新により、同じクラスター内の任意の namespace で同じコントロールプレーンの Argo CD インスタンスによって管理されるアプリケーションを作成できるようになりました。管理者として以下のアクションを実行し、この更新を有効にします。

今回の更新により、Argo CD は Server-Side Apply 能をサポートするようになりました。この機能は、ユーザーが以下のタスクを実行するのに役立ちます。

この更新の前は、証明機関によって署名されていない証明書を使用してセットアップされていると、RHSSO 証明書を検証できませんでした。今回の更新で問題が修正され、通信時に Keycloak の TLS 証明書を検証する際に使用されるカスタム証明書を提供できるようになりました。rootCA を Argo CD カスタムリソース .spec.keycloak.rootCA フィールドに追加できます。Operator はこの変更を調整し、argocd-cm ConfigMap の oidc.config フィールドを PEM エンコードされたルート証明書で更新します。GITOPS-2214

以下に例を示します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator は、Dex に加えて、OIDC を介して RHSSO (KeyCloak) を利用できます。ただし、最新のセキュリティー修正が適用されると、一部のシナリオで RHSSO の証明書は検証できません。GITOPS-2214

回避策として、ArgoCD 仕様で OIDC (Keycloak/RHSSO) エンドポイントの TLS 検証を無効にします。

この更新の前は、証明機関によって署名されていない証明書を使用してセットアップされていると、RHSSO 証明書を検証できませんでした。今回の更新で問題が修正され、通信時に Keycloak の TLS 証明書を検証する際に使用されるカスタム証明書を提供できるようになりました。rootCA を Argo CD カスタムリソース .spec.keycloak.rootCA フィールドに追加できます。Operator はこの変更を調整し、argocd-cm ConfigMap の oidc.config フィールドを PEM エンコードされたルート証明書で更新します。GITOPS-2214

以下に例を示します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator は、OIDC および Dex で RHSSO (KeyCloak) を使用できます。ただし、最近のセキュリティー修正が適用されているため、Operator は一部のシナリオで RHSSO 証明書を検証できません。GITOPS-2214

回避策として、ArgoCD 仕様で OIDC (Keycloak/RHSSO) エンドポイントの TLS 検証を無効にします。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

この更新により、Operator は Red Hat Single Sign-On (RH-SSO) をバージョン v7.5.1 に更新します。これには以下の機能拡張が含まれます。

今回の更新により、Argo CD オペランドの .status フィールドに新しい .host フィールドが追加されました。ルートまたは入力がルートに優先順位を付けて有効になっている場合、新しい URL フィールドにルートが表示されます。ルートまたは入力から URL が提供されていない場合、.host フィールドは表示されません。

ルートまたは入力が設定されているが、対応するコントローラーが適切に設定されておらず、Ready 状態にないか、その URL を伝播しない場合、オペランドの .status.host フィールドの値は、URL を表示する代わりに Pending と表示します。これは、Available ではなく Pending にすることで、オペランドの全体的なステータスに影響します。GITOPS-654

この更新の前は、証明機関によって署名されていない証明書を使用してセットアップされていると、RHSSO 証明書を検証できませんでした。今回の更新で問題が修正され、通信時に Keycloak の TLS 証明書を検証する際に使用されるカスタム証明書を提供できるようになりました。rootCA を Argo CD カスタムリソース .spec.keycloak.rootCA フィールドに追加できます。Operator はこの変更を調整し、argocd-cm ConfigMap の oidc.config フィールドを PEM エンコードされたルート証明書で更新します。GITOPS-2214

以下に例を示します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator は、OIDC および Dex で RHSSO (KeyCloak) を使用できます。ただし、最近のセキュリティー修正が適用されているため、Operator は一部のシナリオで RHSSO 証明書を検証できません。GITOPS-2214

回避策として、ArgoCD 仕様で OIDC (Keycloak/RHSSO) エンドポイントの TLS 検証を無効にします。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

Red Hat OpenShift GitOps Operator v1.4.0 では、以下の CRD の spec から説明フィールドを削除するリグレッションが導入されました。

管理ユーザーとして、argocd.argoproj.io/managed-by ラベルを使用して Argo CD に namespace へのアクセスを許可すると、namespace-admin 権限が引き継がれます。これらの権限は、開発チームなどの非管理者に namespace を提供する管理者にとって問題となります。なぜなら、権限によって非管理者がネットワークポリシーなどのオブジェクトを変更できるからです。

今回の更新により、管理者はすべてのマネージド namespace に共通のクラスターロールを設定できるようになりました。Argo CD アプリケーションコントローラーのロールバインディングでは、Operator は CONTROLLER_CLUSTER_ROLE 環境変数を参照します。Argo CD サーバーのロールバインディングでは、Operator は SERVER_CLUSTER_ROLE 環境変数を参照します。これらの環境変数にカスタムロールが含まれる場合、Operator はデフォルトの管理者ロールを作成しません。代わりに、すべてのマネージド namespace に既存のカスタムロールを使用します。GITOPS-1290

Dex 認証プロバイダーから Keycloak プロバイダーに移行すると、Keycloak でログインの問題が発生する可能性があります。

この問題を防ぐには、移行時に Argo CD カスタムリソースから .spec.dex セクションを削除して Dex をアンインストールします。Dex が完全にアンインストールするまで数分待ちます。次に、.spec.sso.provider: keycloak を Argo CD カスタムリソースに追加して Keycloak をインストールします。

回避策として、.spec.sso.provider: keycloak を削除して Keycloak をアンインストールします。次に、再インストールします。GITOPS-1450、GITOPS-1331

Namespace-scoped Argo CD インスタンス (例: クラスターの All Namepsaces にスコープされていない Argo CD インスタンス) を使用する場合、Red Hat OpenShift GitOps は管理対象の namespace の一覧を動的に維持します。これらの namespace には argocd.argoproj.io/managed-by ラベルが含まれます。この namespace の一覧は、Argo CD Settings Clusters "in-cluster" NAMESPACES のキャッシュに保存されます。今回の更新以前は、これらの namespace のいずれかを削除すると、Operator はそれを無視し、namespace はリストに残りました。この動作はクラスター設定の CONNECTION STATE を破損し、すべての同期の試みがエラーになりました。以下に例を示します。

Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.

このバグは修正されています。GITOPS-1521

GitOps Operator は、最新の Operator-SDK で推奨される命名規則に準拠するようになりました。

Dex 認証プロバイダーから Keycloak プロバイダーに移行する際に、Keycloak でログイン問題が発生する可能性があります。GITOPS-1450

上記の問題を防ぐには、移行時に Argo CD カスタムリソースにある .spec.dex セクションを削除して Dex をアンインストールします。Dex が完全にアンインストールされるまで数分待機してから、.spec.sso.provider: keycloak を Argo CD カスタムリソースに追加して Keycloak のインストールに進みます。

回避策として、.spec.sso.provider: keycloak を削除して Keycloak をアンインストールしてから、再インストールします。

Argo CD 認証は Red Hat SSO と統合され、クラスターの OpenShift 4 アイデンティティープロバイダーに自動的に設定されるようになりました。この機能はデフォルトで無効にされています。Red Hat SSO を有効にするには、以下に示すように ArgoCD CR に SSO 設定を追加します。現在、keycloak が唯一サポートされているプロバイダーです。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
  server:
    route:
     enabled: true

ルートラベルを使用してホスト名を定義して、ルーターのシャード化をサポートするようになりました。server (argocd サーバー)、grafana ルートおよび prometheus ルートに対するラベルの設定のサポートが利用可能になりました。ルートにラベルを設定するには、ArgoCD CR のサーバーのルート設定に labels を追加します。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    route:
     enabled: true
     labels:
       key1: value1
       key2: value2

リソースクォータが Red Hat OpenShift GitOps 1.2 の openshift-gitops namespace で有効になっています。これは、手動でデプロイされる帯域外ワークロードおよび openshift-gitops namespace のデフォルトの Argo CD インスタンスによってデプロイされるワークロードに影響を及ぼします。Red Hat OpenShift GitOps v1.1.2 から v1.2 にアップグレードする場合は、このようなワークロードをリソース要求および制限で設定する必要があります。追加のワークロードがある場合は、openshift-gitops namespace のリソースクォータを増やす必要があります。

openshift-gitops namespace の現在のリソースクォータ。

以下のコマンドを使用して CPU 制限を更新できます。

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

以下のコマンドを使用して CPU 要求を更新できます。

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

上記のコマンドのパスは、cpu から memory を置き換えてメモリーを更新できます。