GitOps

当您搜索 Argo CD 应用程序时，您会被定向到 Applications 页面。完成以下步骤，从 Search 页面访问 Argo CD 应用程序：

有关搜索的更多信息，请参阅 控制台简介中的搜索。

完成以下步骤，将受管集群注册到 GitOps：

当您通过放置和 ManagedClusterSetBinding 自定义资源与 GitOps operator 集成时，会在命名空间中创建一个令牌来访问 ManagedCluster 命名空间。GitOps 控制器需要把资源同步到受管集群。当用户获得一个管理员访问 GitOps 命名空间以执行应用程序生命周期操作时，用户也获得了对受管集群的此 secret 和 admin 级别的访问权限。

如果需要这样做，而不是将用户绑定到命名空间范围的 admin 角色，请使用更严格的自定义角色，以及与可创建和用于绑定用户的应用程序资源所需的权限。请参阅以下 ClusterRole 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: application-set-admin
rules:
- apiGroups:
  - argoproj.io
  resources:
  - applicationsets
  verbs:
  - get
  - list
  - watch
  - update
  - delete
  - deletecollection
  - patch

查看 Argo CD Pull 模型的以下先决条件：

cannot create resource "services" in API group "" in the namespace
"mortgage",deployments.apps is forbidden: User
"system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller"

请参阅以下要求来使用 Argo CD Pull 模型：

对于 Push 和 Pull 模型，hub 集群上的 Argo CD ApplicationSet 控制器会协调为每个目标受管集群创建应用程序资源。有关这两种模型的架构，请查看以下信息：

Argo CD ApplicationSet 资源用于在用于获取受管集群列表的 generator 字段中使用带有 放置资源 的 Push 或 Pull 模型在受管集群中部署应用程序。

以下是 guestbook 应用程序的 MulticlusterApplicationSetReport YAML 文件示例：

apiVersion: apps.open-cluster-management.io/v1alpha1
kind: MulticlusterApplicationSetReport
metadata:
  labels:
    apps.open-cluster-management.io/hosting-applicationset: openshift-gitops.guestbook-allclusters-app-set
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
statuses:
  clusterConditions:
  - cluster: cluster1
    conditions:
    - message: 'Failed sync attempt: one or more objects failed to apply, reason: services is forbidden: User "system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller" cannot create resource "services" in API group "" in the namespace "guestbook",deployments.apps is forbidden: User <name> cannot create resource "deployments" in API group "apps" in the namespace "guestboo...'
      type: SyncError
    healthStatus: Missing
    syncStatus: OutOfSync
  - cluster: pcluster1
    healthStatus: Progressing
    syncStatus: Synced
  - cluster: pcluster2
    healthStatus: Progressing
    syncStatus: Synced
  summary:
    clusters: "3"
    healthy: "0"
    inProgress: "2"
    notHealthy: "3"
    notSynced: "1"
    synced: "2"

注：如果资源无法部署，则资源不会包含在资源列表中。如需更多信息，请参阅错误消息。

基于 Argo CD 的 OpenShift Container Platform GitOps 也可用于通过 GitOps 使用 Policy Generator 生成策略。因为 Policy Generator 没有预安装在 OpenShift Container Platform GitOps 容器镜像中，所以必须进行一些自定义。为了继续操作，必须在 Red Hat Advanced Cluster Management hub 集群中安装了 OpenShift Container Platform GitOps Operator，并确保登录到 hub 集群。

要使 OpenShift Container Platform GitOps 在运行 Kustomize 时有权访问 Policy Generator，需要将初始容器从 Red Hat Advanced Cluster Management Application Subscription 容器镜像复制到 OpenShift Container Platform GitOps 容器。另外，OpenShift Container Platform GitOps 必须配置为在运行 Kustomize 时提供 --enable-alpha-plugins 标志。使用以下命令开始编辑 OpenShift Container Platform GitOps argocd 对象：

oc -n openshift-gitops edit argocd openshift-gitops

然后，修改 OpenShift Container Platform GitOps argocd 对象使其包含以下额外 YAML 内容。当发布新的 Red Hat Advanced Cluster Management 主版本且您要将 Policy Generator 更新至更新的版本时，您需要更新 registry.redhat.io/busybox2/multicluster-operators-subscription-rhel8 镜像，供 Init 容器用于较新的标签。查看以下示例，将 <version> 替换为 2.9 或您所需的 Red Hat Advanced Cluster Management 版本：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: openshift-gitops
  namespace: openshift-gitops
spec:
  kustomizeBuildOptions: --enable-alpha-plugins
  repo:
    env:
    - name: KUSTOMIZE_PLUGIN_HOME
      value: /etc/kustomize/plugin
    initContainers:
    - args:
      - -c
      - cp /etc/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator
        /policy-generator/PolicyGenerator
      command:
      - /bin/bash
      image: registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<version>
      name: policy-generator-install
      volumeMounts:
      - mountPath: /policy-generator
        name: policy-generator
    volumeMounts:
    - mountPath: /etc/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator
      name: policy-generator
    volumes:
    - emptyDir: {}
      name: policy-generator

现在，OpenShift Container Platform GitOps 可以使用 Policy Generator，OpenShift Container Platform GitOps 必须被授予在 Red Hat Advanced Cluster Management hub 集群中创建策略的访问权限。创建名为 openshift-gitops-policy-admin 的 ClusterRole 资源，其具有创建、读取、更新和删除策略和放置的访问权限。请参阅早期的 ClusterRole 示例。

额外，创建一个 ClusterRoleBinding 对象，为 OpenShift Container Platform GitOps 服务帐户授予 openshift-gitops-policy-admin ClusterRole 的访问权限。ClusterRoleBinding 可能类似以下资源：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: openshift-gitops-policy-admin
subjects:
  - kind: ServiceAccount
    name: openshift-gitops-argocd-application-controller
    namespace: openshift-gitops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: openshift-gitops-policy-admin

您可以使用 Policy Generator 生成安装 OpenShift Container Platform GitOps 的策略。OpenShift Container Platform GitOps operator 提供 所有命名空间 安装模式，您可以在以下示例中查看它们。创建名为 openshift-gitops-subscription.yaml 的 Subscription 清单文件，如下例所示：

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

要固定到 Operator 的特定版本，您可以添加以下参数和值： spec.startingCSV: openshift-gitops-operator.v<version>。将 <version> 替换为您的首选版本。

需要 PolicyGenerator 配置文件。使用名为 policy-generator-config.yaml 的配置文件来生成策略，以便在所有 OpenShift Container Platform 受管集群上安装 OpenShift Container Platform GitOps。请参见以下示例：

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: install-openshift-gitops
policyDefaults:
  namespace: policies
  placement:
    clusterSelectors:
      vendor: "OpenShift"
  remediationAction: enforce
policies:
  - name: install-openshift-gitops
    manifests:
      - path: openshift-gitops-subscription.yaml

最后所需的文件是 kustomization.yaml，它需要以下配置：

generators:
  - policy-generator-config.yaml

生成的策略可能类似以下带有 PlacementRule 的文件（已弃用）：

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-install-openshift-gitops
  namespace: policies
spec:
  clusterConditions:
    - status: "True"
      type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - key: vendor
        operator: In
        values:
          - OpenShift
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-install-openshift-gitops
  namespace: policies
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-install-openshift-gitops
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: install-openshift-gitops
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/description:
  name: install-openshift-gitops
  namespace: policies
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: install-openshift-gitops
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: openshift-gitops-operator
                  namespace: openshift-operators
                spec:
                  channel: stable
                  name: openshift-gitops-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
          remediationAction: enforce
          severity: low

支持 OpenShift Container Platform 文档中的从清单生成的策略。OpenShift Container Platform 文档中的任何配置指南都可以使用 Policy Generator 应用。

当使用 OperatorGroup 清单安装 Operator 时，OperatorGroup 必须在创建 Subscription 前存在于集群中。使用策略依赖项功能以及 Policy Generator，确保在执行 订阅 策略前 OperatorGroup 策略兼容。

通过按您想要的顺序列出清单来设置策略依赖项。例如，您可能想要首先创建命名空间策略，然后创建 OperatorGroup，最后再创建 Subscription。

启用 policyDefaults.orderManifests 参数，并在 Policy Generator 配置清单中禁用 policyDefaults.consolidateManifests，以自动设置清单之间的依赖项。

hub 上的 managedserviceaccount 自定义资源提供了一种便捷的方法，可以在受管集群上创建 serviceaccounts。当在 hub 集群上的 < managed_cluster > 命名空间中创建 managedserviceccount 自定义资源时，会在受管集群上创建一个 serviceccount。

要创建受管服务帐户，请参阅启用 managedserviceaccount add-ons。

创建服务帐户时，它没有关联任何权限。要为新服务帐户授予权限，请使用 clusterpermission 资源。集群permission 资源在 hub 上的受管集群命名空间中创建。它提供了一种便捷的方式来创建角色，在受管集群中的集群角色资源，并通过 rolebinding 或 clusterrolebinding 资源将它们绑定到服务帐户。

创建示例 < clusterpermission& gt; 后，会在示例受管集群中创建以下资源：

GitOpsCluster 资源使用放置将所选受管集群导入到 Argo CD 中，包括创建包含用于访问集群的信息的 Argo CD 集群 secret。默认情况下，Argo CD 集群 secret 使用 application manager 服务帐户来访问受管集群。

使用推送模型从 Argo CD 控制台部署 Argo CD 应用程序。Argo CD 应用程序使用受管服务帐户 < managed-sa-sample > 部署。

When the GitOpsCluster resource is updated with the `managedServiceAccountRef`, each managed cluster in the placement of this GitOpsCluster needs to have the service account. If you have several managed clusters, it becomes tedious for you to create the managed service account and cluster permission for each managed cluster. You can simply this process by using a policy to create the managed service account and cluster permission for all your managed clusters

当您将 managedServiceAccount 和 clusterPermission 资源应用到 hub 集群时，此策略的放置会绑定到本地集群。在 GitOpsCluster 资源放置中，将这些资源复制到所有受管集群的受管集群命名空间中。

使用策略创建 managedServiceAccount 和 clusterPermission 资源包括以下属性：