5.7. クラスター設定を使用したアプリケーションのデプロイによる OpenShift クラスターの設定
Red Hat OpenShift GitOps では、Argo CD を、クラスターのカスタム設定が含まれるアプリケーションと Git ディレクトリーの内容を再帰的に同期するように設定することができます。
前提条件
- OpenShift Container Platform クラスターに管理者としてログインしていること。
- Red Hat OpenShift GitOps Operator がクラスターにインストールされている。
- Argo CD インスタンスにログインしました。
5.7.1. Argo CD インスタンスを使用してクラスタースコープのリソースを管理する
クラスタースコープのリソースを管理するには、Red Hat OpenShift GitOps Operator の既存の Subscription
オブジェクトを更新し、Argo CD インスタンスの名前空間を spec
セクションの ARGOCD_CLUSTER_CONFIG_NAMESPACES
環境変数に追加します。
手順
-
Web コンソールの Administrator パースペクティブで、Operators
Installed Operators Red Hat OpenShift GitOps Subscription に移動します。 - Actions ドロップダウンメニューをクリックし、Edit Subscription をクリックします。
openshift-gitops-operator サブスクリプションの詳細ページの YAML タブで、Argo CD インスタンスの namespace を仕様セクションの
ARGOCD_CLUSTER_CONFIG_NAMESPACES
環境変数に追加して、spec
セクションのSubscription
YAML ファイルを編集します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators ... spec: config: env: - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances> ...
Argo インスタンスがクラスタースコープのリソースを管理するクラスターロールで設定されていることを確認するには、次の手順を実行します。
-
User Management
Roles に移動し、Filter ドロップダウンメニューから Cluster-wide Roles を選択します。 Search by name フィールドを使用して、
argocd-application-controller
を検索します。Roles ページには、作成されたクラスターロールが表示されます。
ヒントあるいは、OpenShift CLI で次のコマンドを実行します。
oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller
出力
yes
は、Argo インスタンスがクラスタースコープのリソースを管理するクラスターロールで設定されていることを確認します。それ以外の場合は、設定を確認し、必要に応じて必要な手順を実行します。
-
User Management
5.7.2. Argocd インスタンスのデフォルトの権限
デフォルトでは、Argo CD インスタンスには次の権限があります。
-
Argo CD インスタンスには、それがデプロイされている namespace 内のリソースのみを管理する
admin
権限があります。たとえば、foo namespace にデプロイされた Argo CD インスタンスには、その namespace に対してのみリソースを管理するadmin
権限があります。 Argo CD が適切に機能するには、リソースに対するクラスター全体の
read
権限が必要であるため、Argo CD には次のクラスタースコープのアクセス許可があります。- verbs: - get - list - watch apiGroups: - '*' resources: - '*' - verbs: - get - list nonResourceURLs: - '*'
Argo CD が実行されている
argocd-server
とargocd-application-controller
コンポーネントで使用されるクラスターのロールを編集して、write
権限が Argo CD で管理したい namespace とリソースのみに制限されるようにすることができます。$ oc edit clusterrole argocd-server $ oc edit clusterrole argocd-application-controller
5.7.3. クラスターレベルでの Argo CD インスタンスの実行
Red Hat OpenShift GitOps Operator によってインストールされるデフォルトの Argo CD インスタンスおよび付随するコントローラーは、単純な設定の切り替えを設定して、クラスターのインフラストラクチャーノードで実行できるようになりました。
手順
既存のノードにラベルを付けます。
$ oc label node <node-name> node-role.kubernetes.io/infra=""
オプション: 必要な場合は、テイントを適用し、インフラストラクチャーノードでワークロードを分離し、他のワークロードがそれらのノードでスケジュールされないようにすることもできます。
$ oc adm taint nodes -l node-role.kubernetes.io/infra \ infra=reserved:NoSchedule infra=reserved:NoExecute
GitOpsService
カスタムリソースにrunOnInfra
トグルを追加します。apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true
オプション: テイントがノードに追加された場合は、
tolerations
をGitOpsService
カスタムリソースに追加します。以下に例を示します。spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved
-
コンソール UI の Pod を Pods
Pod details で表示して、 openshift-gitops
namespace のワークロードがインフラストラクチャーノードでスケジュールされていることを確認します。
デフォルトの Argo CD カスタムリソースに手動で追加された nodeSelectors
および tolerations
は、GitOpsService
カスタムリソースのトグルおよび tolerations
によって上書きされます。
関連情報
- テイントと容認の詳細は、ノードテイントを使用した Pod 配置の制御 を参照してください。
- インフラストラクチャーマシンセットの詳細は、インフラストラクチャーマシンセットの作成 を参照してください。
5.7.4. Argo CD ダッシュボードを使用したアプリケーションの作成
Argo CD は、アプリケーションを作成できるダッシュボードを提供します。
このサンプルワークフローでは cluster
ディレクトリーの内容を cluster-configs
アプリケーションに対して再帰的に同期するために Argo CD を設定するプロセスについて説明します。ディレクトリーは Web コンソールの
メニューで Red Hat Developer Blog - Kubernetes へのリンクを追加する OpenShift Container Platform Web コンソールクラスター設定を定義してクラスターの namespace spring-petclinic
を定義します。
手順
- Argo CD ダッシュボードで、New App をクリックして新規の Argo CD アプリケーションを追加します。
このワークフローでは、以下の設定で cluster-configs アプリケーションを作成します。
- アプリケーション名
-
cluster-configs
- プロジェクト
-
default
- 同期ポリシー
-
Manual
- リポジトリー URL
-
https://github.com/redhat-developer/openshift-gitops-getting-started
- リビジョン
-
HEAD
- パス
-
cluster
- 宛先
-
https://kubernetes.default.svc
- Namespace
-
spring-petclinic
- ディレクトリーの再帰処理
-
checked
- Create をクリックしてアプリケーションを作成します。
-
Web コンソールの Administrator パースペクティブで、左側のメニューにある Administration
Namespaces に移動します。 -
namespace を検索、選択してから Label フィールドに
argocd.argoproj.io/managed-by=openshift-gitops
を入力し、openshift-gitops
namespace にある Argo CD インスタンスが namespace を管理できるようにします。
5.7.5. oc
ツールを使用したアプリケーションの作成
oc
ツールを使用して、ターミナルで Argo CD アプリケーションを作成できます。
手順
サンプルアプリケーション をダウンロードします。
$ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
アプリケーションを作成します。
$ oc create -f openshift-gitops-getting-started/argo/app.yaml
oc get
コマンドを実行して、作成されたアプリケーションを確認します。$ oc get application -n openshift-gitops
アプリケーションがデプロイされている namespace にラベルを追加し、
openshift-gitops
namespace の Argo CD インスタンスが管理できるようにします。$ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
5.7.6. アプリケーションの Git リポジトリーとの同期
手順
- Argo CD ダッシュボードでは、cluster-configs Argo CD アプリケーションに Missing および OutOfSync のステータスがあることに注意してください。アプリケーションは手動の同期ポリシーで設定されているため、Argo CD はこれを自動的に同期しません。
- cluster-configs タイルの 同期 をクリックし、変更を確認してから、Synchronize をクリックします。Argo CD は Git リポジトリーの変更を自動的に検出します。設定が変更されると、Argo CD は cluster-configs のステータスを OutOfSync に変更します。Argo CD の同期ポリシーを変更し、Git リポジトリーからクラスターに変更を自動的に適用できるようにします。
- cluster-configs Argo CD アプリケーションに Healthy および Synced のステータスがあることに注意してください。cluster-configs タイルをクリックし、クラスター上で同期されたリソースおよびそれらのステータスの詳細を確認します。
- OpenShift Container Platform Web コンソールに移動し、 をクリックして Red Hat Developer Blog - Kubernetes へのリンクが表示されることを確認します。
Project ページに移動し、
spring-petclinic
namespace を検索し、これがクラスターに追加されていることを確認します。クラスター設定がクラスターに正常に同期されます。
5.7.7. クラスター設定用の組み込みのアクセス許可
デフォルトでは、Argo CD インスタンスには、クラスター Operator、オプションの OLM オペレーター、およびユーザー管理など、特定のクラスタースコープのリソースを管理する権限があります。
Argo CD にはクラスター管理者権限がありません。
Argo CD インスタンスのパーミッション:
Resources | 説明 |
リソースグループ | ユーザーまたは管理者の設定 |
| OLM によって管理されるオプションの Operator |
| グループ、ユーザー、およびそれらの権限 |
| クラスター全体のビルド設定、レジストリー設定、およびスケジューラーポリシーを設定するために使用される CVO によって管理されるコントロールプレーン Operator |
| ストレージ |
| コンソールのカスタマイズ |
5.7.8. クラスター設定のアクセス許可を追加する
Argo CD インスタンスにアクセス許可を付与して、クラスター設定を管理できます。追加のアクセス許可を持つクラスターロールを作成し、新しいクラスターロールバインディングを作成して、クラスターロールをサービスアカウントに関連付けます。
手順
- 管理者として OpenShift Container Platform Web コンソールにログインします。
Web コンソールで、User Management
Roles Create Role を選択します。以下の ClusterRole
YAML テンプレートを使用してルールを追加し、追加のパーミッションを指定します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-cluster-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["*"]
- Create をクリックしてクラスターロールを追加します。
-
ここで、クラスターのロールバインディングを作成します。Web コンソールで、User Management
Role Bindings Create Binding を選択します。 - プロジェクト ドロップダウンから すべてのプロジェクト を選択します。
- Create binding をクリックします。
- Binding type を Cluster-wide role binding (ClusterRoleBinding) として選択します。
- RoleBinding name の一意の値を入力します。
- ドロップダウンリストから、新しく作成したクラスターロールまたは既存のクラスターロールを選択します。
Subject を ServiceAccount として選択し、サブジェクトの namespace と 名前 を指定します。
-
Subject namespace:
openshift-gitops
-
Subject name:
openshift-gitops-argocd-application-controller
-
Subject namespace:
Create をクリックします。
ClusterRoleBinding
オブジェクトの YAML ファイルは以下のとおりです。kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-role-binding subjects: - kind: ServiceAccount name: openshift-gitops-argocd-application-controller namespace: openshift-gitops roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin
5.7.9. Red Hat OpenShift GitOps を使用した OLM Operator のインストール
クラスター設定の Red Hat OpenShift GitOps は、特定のクラスタースコープのリソースを管理し、クラスター Operator または namespace スコープの OLM Operator のインストールを処理します。
クラスター管理者として、Tekton などの OLM Operator をインストールする必要がある場合を考えてみましょう。OpenShift Container Platform Web コンソールを使用して Tekton Operator を手動でインストールするか、OpenShift CLI を使用して Tekton サブスクリプションと Tekton Operator グループをクラスターに手動でインストールします。
Red Hat OpenShift GitOps は、Kubernetes リソースを Git リポジトリーに配置します。クラスター管理者は、Red Hat OpenShift GitOps を使用して、手動手順を行わずに他の OLM Operator のインストールを管理および自動化できます。たとえば、Red Hat OpenShift GitOps を使用して Tekton サブスクリプションを Git リポジトリーに配置すると、Red Hat OpenShift GitOps はこの Tekton サブスクリプションを Git リポジトリーから自動的に取得し、クラスターに Tekton Operator をインストールします。
5.7.9.1. クラスタースコープの Operator のインストール
Operator Lifecycle Manager (OLM) は、クラスタースコープの Operator の openshift-operators
namespace 内のデフォルトの global-operators
Operator グループを使用します。したがって、Gitops リポジトリーで OperatorGroup
リソースを管理する必要はありません。ただし、namespace スコープの Operator の場合は、その namespace で OperatorGroup
リソースを管理する必要があります。
クラスタースコープの Operator をインストールするには、必要な Operator の Subscription
リソースを作成し、Git リポジトリーに配置します。
例: Grafana Operator サブスクリプション
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: grafana spec: channel: v4 installPlanApproval: Automatic name: grafana-operator source: redhat-operators sourceNamespace: openshift-marketplace
5.7.9.2. namespace スコープの Operator のインストール
namespace スコープの Operator をインストールするには、必要な Operator の Subscription
リソースと OperatorGroup
リソースを作成して Git リポジトリーに配置します。
例: Ansible Automation Platform リソースオペレーター
... apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: ansible-automation-platform ... apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ansible-automation-platform-operator namespace: ansible-automation-platform spec: targetNamespaces: - ansible-automation-platform ... apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ansible-automation-platform namespace: ansible-automation-platform spec: channel: patch-me installPlanApproval: Automatic name: ansible-automation-platform-operator source: redhat-operators sourceNamespace: openshift-marketplace ...
Red Hat OpenShift GitOps を使用して複数の Operator をデプロイする場合、対応する namespace に Operator グループを 1 つだけ作成する必要があります。1 つの namespace に複数の Operator グループが存在する場合、その namespace で作成された CSV はすべて、TooManyOperatorGroups
の理由で failure
状態に移行します。対応する namespace 内の Operator グループの数が 1 に達すると、以前の failure
状態の CSV はすべて pending
状態に移行します。Operator のインストールを完了するには、保留中のインストールプランを手動で承認する必要があります。