このコンテンツは選択した言語では利用できません。
Chapter 2. Argo CD custom resource and component properties
The Argo CD custom resource is a Kubernetes Custom Resource (CRD) that describes the desired state for a given Argo CD cluster and allows you to configure the components which make up an Argo CD cluster.
2.1. Argo CD custom resource properties リンクのコピーリンクがクリップボードにコピーされました!
The Argo CD Custom Resource consists of the following properties:
| Name | Description | Default | Properties |
|---|---|---|---|
|
| Use aggregated cluster roles for the Argo CD Application Controller component of a cluster-scoped instance. |
| |
|
|
The |
| |
|
| The ApplicationSet Controller configuration options. | object |
|
|
| Adds a UI banner message. | object |
|
|
| Adds a configuration management plugin. | empty | |
|
| Argo CD Application Controller options. | object |
|
|
| Disables the built-in admin user. |
| |
|
| Disables the creation of default cluster roles for a cluster-scoped instance. |
| |
|
|
Add any supplementary Argo CD settings to the | empty | |
|
| Use a Google Analytics tracking ID. | empty | |
|
| Enable hashed usernames sent to Google Analytics. |
| |
|
| High-availability options. | object |
|
|
| URL for getting chat help (this is typically your Slack channel for support). | ||
|
| The text that appears in a text box for getting chat help. |
| |
|
|
The container image for all Argo CD components. This overrides the |
| |
|
| Import configuration options for Argo CD. | object |
|
|
| Ingress configuration options. | object | |
|
| Defines the initial SSH Known Hosts data for Argo CD to use at cluster creation to connect to Git repositories through SSH. |
|
|
|
|
The build options and parameters to use with | empty | |
|
|
Defines a list of | empty |
|
|
| Defines the workload status monitoring configuration for your instance. | object |
|
|
| Notifications Controller configuration options. | object |
|
|
|
Defines | empty |
|
|
| The OIDC configuration as an alternative to Dex. | empty | |
|
| Prometheus configuration options. | object |
|
|
| RBAC configuration options. | object |
|
|
| Redis configuration options. | object |
|
|
| Customize resource action behavior. | empty | |
|
| Completely ignore entire classes of resource group. | empty | |
|
| The configuration to identify which resource group/kinds are applied. | empty | |
|
| Customize resource health check behavior. | empty | |
|
| Customize resource ignore difference behavior. | empty | |
|
| The field used by Argo CD to monitor its managed resources. |
| |
|
| Argo CD Server configuration options. | object |
|
|
| Specifies the namespaces within which you can create application resources. |
| |
|
| Single Sign-on options. | object |
|
|
| Enable application status badge. |
| |
|
| TLS configuration options. | object |
|
|
| Enables anonymous user access. |
| |
|
| The tag to use with the container image for all Argo CD components. | Latest Argo CD version |
2.2. Repo server properties リンクのコピーリンクがクリップボードにコピーされました!
The following properties are available for configuring the repo server component:
| Name | Default | Description |
|---|---|---|
|
| empty | List of custom annotations to add to pods deployed by the Operator. This field is optional. |
|
|
|
Provider to use to set up TLS for the repo-server’s gRPC TLS certificate. Currently, only the |
|
| empty | The environment to set for the Repo server workloads. |
|
| empty | Flag that enables the Repo server during Argo CD installation. |
|
|
| Execution timeout in seconds for rendering tools, for example, Helm or Kustomize. |
|
| empty | Passes command-line arguments to the Repo server workload. The command-line arguments are added to the list of arguments set by the Operator. |
|
| empty |
The number of |
|
|
|
The container image for Argo CD Repo server. This property overrides the |
|
| empty | List of custom labels to add to pods deployed by the Operator. This field is optional. |
|
|
|
The log level used by the Argo CD Repo server. Valid options are |
|
|
|
The log format to be used by the Argo CD repo server. Valid options are |
|
|
|
Defines whether the |
|
| empty | Specifies the remote URL of the Repo server container. |
|
| empty |
The number of replicas for the Argo CD Repo server. Must be greater than or equal to |
|
| empty | The container compute resources. |
|
|
|
The name of the |
|
| empty |
The number of |
|
|
| Enables the use of custom CA certificates so that the repo server and its plugins can trust external source hosting sites. |
|
|
| Defines whether to enforce strict TLS checking on all components when communicating with repo server. |
|
|
same as | The tag to use with the Argo CD Repo server. |
|
| empty | Configures additional volumes used for the Repo server deployment. This field is optional. |
|
| empty | Configures additional volume mounts used for the Repo server deployment. This field is optional. |
2.2.1. Configure TLS trust for the repo server リンクのコピーリンクがクリップボードにコピーされました!
You can configure the repo server to trust additional certificate authorities (CAs) by injecting custom TLS certificates into the repo server container and its Config Management Plugin sidecar containers.
The certificates can be provided through Kubernetes secrets and config maps.
The following example shows how to configure additional trusted certificates in the Argo CD custom resource.
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
name: example-argocd
labels:
example: repo
spec:
repo:
systemCATrust:
secrets:
- name: my-local-cert-secret
items:
- key: key-name-in-the-secret-object
path: desired-file-name-of-the-certificate.crt
configMaps:
- name: my-local-cert-cm
items: []
where:
-
spec.repo:: Configures settings for the Argo CD repo server component. -
spec.repo.systemCATrust:: Defines additional certificate authorities that the repo server trusts. -
spec.repo.systemCATrust.secrets:: Specifies kubernetes secrets that contain custom CA certificates. -
spec.repo.systemCATrust.configMaps:: References config maps containing CA certificates to trust.
Consider the following behavior and configuration details when using this feature:
- Certificates are not pinned to individual hosts, allowing the use of CA or wildcard certificates.
The injected certificates are configured directly inside the container, enabling more advanced plugin workflows. For example:
- Kustomize can invoke Helm charts hosted on different repositories.
- Kustomize can retrieve resources from other repositories or sources over HTTPS.
- Config Management Plugins can invoke TLS-enabled tools available in the container image with TLS verification enabled.
Certificates from secrets or config maps must exist in the same namespace as the Argo CD instance. You can either map specific keys using the items field or include all keys by omitting the items field.
You can mark a trust source as optional. If a required source is missing, the deployment fails.
Unless spec.repo.systemCATrust.dropImageCertificates is set to true, the certificates provided by the user are merged with the certificates already included in the container image.
2.3. Enabling notifications with an Argo CD instance リンクのコピーリンクがクリップボードにコピーされました!
Argo CD notifications allow you to send notifications to external services when events occur in your Argo CD instance. For example, you can send notifications to Slack or email when a sync operation fails. By default, notifications are disabled in Argo CD instances.
Prerequisites
-
You have access to an OpenShift Container Platform cluster with
cluster-adminprivileges and are logged in to the web console. - You have installed the Red Hat OpenShift GitOps Operator on your cluster.
Procedure
To enable notifications for an Argo CD instance using the OpenShift Container Platform web console, complete the following steps:
-
Navigate to the Operators
Installed Operators page. - From the list of Installed Operators, select the Red Hat OpenShift GitOps Operator, and then click on the ArgoCD tab.
-
Select the Argo CD instance name you want to enable notifications. For example,
openshift-gitops. Click on the YAML tab, and then edit and set the
spec.notifications.enabledparameter totrue:Example:
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: openshift-gitops spec: notifications: enabled: true #....- Click Save.
Alternatively, you can enable notifications by using the oc patch command in the OpenShift CLI. For example:
oc patch argocd openshift-gitops -n openshift-gitops --type merge --patch '{"spec": {"notifications": {"enabled": true}}}'
2.4. Enabling Config Management Plugins in an Argo CD CR リンクのコピーリンクがクリップボードにコピーされました!
Argo CD provides support for Helm, Jsonnet, and Kustomize as built-in config management tools. To use a different config management tool, or to enable features not provided by the built-in config management tools, you can use the Config Management Plugin (CMP).
In Argo CD, the CMP is specified as a sidecar container for the Argo CD repo server container. For more information, see "Config Management Plugins".
In the Red Hat OpenShift GitOps Operator, you can configure the Config Management plugin as a sidecar container in the Argo CD custom resource (CR). When you configure the sidecar container, you either specify an off-the-shelf or a custom-built container image. If you do not specify an image, the system uses the same image as the repo server for the plugin.
To configure a sidecar container in the Red Hat OpenShift GitOps Operator, add the .spec.repo.sidecarContainers key in the Argo CD CR.
Example Config Management Plugin configuration:
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
name: <my_argocd>
spec:
repo:
sidecarContainers:
- name: <my_cmp>
command: [/var/run/argocd/argocd-cmp-server]
image: <my_image>
securityContext:
runAsNonRoot: <true>
runAsUser:
volumeMounts:
- mountPath: /var/run/argocd
name: <var_files>
- mountPath: /home/argocd/cmp-server/plugins
name: plugins
- mountPath: /tmp
name: tmp
- mountPath: /home/argocd/cmp-server/config/plugin.yaml
subPath: <plugin.yaml>
name: <cmp_plugin>
where:
metadata.name- Specifies the name of an Argo CD CR instance.
spec.repo.sidecarContainers.name- Specifies the name of a sidecar container used in the repo server.
spec.repo.sidecarContainers.volumeMounts- Specifies the name of volume mounts used in the repo server.
2.5. NotificationsConfiguration custom resource properties リンクのコピーリンクがクリップボードにコピーされました!
The NotificationsConfiguration resource is a Kubernetes custom resource (CR) that manages notifications in a Kubernetes cluster. In Red Hat OpenShift GitOps, you can add templates, triggers, services, and subscription resources to an Argo CD Notifications config map by using the NotificationsConfiguration CR.
When you create a cluster in Red Hat OpenShift GitOps with notifications enabled, a NotificationsConfiguration CR is created by default with the name default-notifications-configuration.
Any change made in the existing configuration of the NotificationsConfiguration CR is replicated in the Argo CD Notifications config map. For example, if the user adds trigger configuration in the NotificationsConfiguration resource, this configuration is read, processed, and updated in the Argo CD Notifications config map.
Any configuration changes must be updated in the default-notifications-configuration CR. Custom resources created by the users for NotificationsConfiguration resource are not supported.
Any modification to the Argo CD argocd-notifications-cm config map is overridden by the changes made in the NotificationsConfiguration CR.
| Properties | Default | Description |
|---|---|---|
| Templates |
| Templates are used to generate the notification template message. |
| Triggers |
| Triggers are used to define the condition when a notification is sent to the user and the list of templates required to generate the message. |
| Services |
| Services are used to deliver a message. |
| Subscriptions |
| Subscriptions contain centrally-managed global application subscriptions. |
The following examples define how to add templates, triggers, services, and subscription resources to the Argo CD argocd-notification-cm config map by using the default-notifications-configuration custom resource.
Example for templates:
apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
name: default-notifications-configuration
spec:
templates:
template.my-custom-template: |
message: |
Application details: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}.
where:
metadata.name-
Specifies the default name of the
NotificationsConfigurationCR in a cluster. spec.template.my-custom-template-
Specifies an example custom template configuration for the
NotificationsConfigurationCR.
Example for triggers:
apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
name: default-notifications-configuration
spec:
triggers:
trigger.on-sync-status-unknown: |
- when: app.status.sync.status == 'Unknown'
send: [my-custom-template]
where:
metadata.name-
Specifies the default name of the
NotificationsConfigurationCR in a cluster. spec.trigger.on-sync-status-unknown-
Specifies an example custom trigger configuration for the
NotificationsConfigurationCR.
Example for services:
apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
name: default-notifications-configuration
spec:
services:
service.slack: |
token: $slack-token
username: <override-username> # optional username
icon: <override-icon> # optional icon for the message (supports both emoji and url notation)
where:
metadata.name-
Specifies the default name of the
NotificationsConfigurationCR in a cluster. spec.service.slack-
Specifies an example custom service configuration for the
NotificationsConfigurationCR.
Example for subscriptions:
apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
name: default-notifications-configuration
spec:
subscriptions:
subscriptions: |
# subscription for on-sync-status-unknown trigger notifications
- recipients:
- slack:test2
- email:test@gmail.com
triggers:
- on-sync-status-unknown
# subscription restricted to applications with matching labels only
- recipients:
- slack:test3
selector: test=true
triggers:
- on-sync-status-unknown
where:
metadata.name-
Specifies the default name of the
NotificationsConfigurationCR in a cluster. spec.subscriptions-
Specifies an example custom subscription configuration for the
NotificationsConfigurationCR.
You can configure the NotificationsConfiguration CR by using the OpenShift Container Platform web console or the CLI (oc).
2.5.1. Configuring the NotificationsConfiguration CR by using the web console リンクのコピーリンクがクリップボードにコピーされました!
You can configure the NotificationsConfiguration custom resource (CR) by using the web console.
Prerequisites
-
You have access to an OpenShift Container Platform cluster with
cluster-adminprivileges and are logged in to the web console. - You have installed the Red Hat OpenShift GitOps Operator on your cluster.
- You have enabled notifications for the Argo CD instance. For more information, see "Enabling notifications with an Argo CD instance".
Procedure
-
In the Administrator perspective of the OpenShift Container Platform web console, expand Operators
Installed Operators. - From the list of Installed Operators, select the Red Hat OpenShift GitOps Operator, and then click on the NotificationsConfiguration tab.
-
On the NotificationsConfigurations page, click
default-notifications-configuration. On the default-notifications-configuration page, click YAML and add the configuration for any supported resources such as
templates,triggers,services, andsubscriptions. For example, undertemplatesin the code, add the following sample configuration:Example template configuration:
template.my-custom-template: | message: | Application details: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}.- Click Save.
Verify that the configuration changes made in the
NotificationsConfigurationCR are reflected in theargocd-notifications-cmconfig map:-
Go to Workloads
ConfigMaps. - Click argocd-notifications-cm and select the YAML tab.
- Scroll through the page in the YAML tab to verify the sample configuration added for the supported resources.
-
Go to Workloads
2.5.2. Configuring the NotificationsConfiguration CR by using the CLI リンクのコピーリンクがクリップボードにコピーされました!
You can configure the NotificationsConfiguration custom resource (CR) by using the CLI (oc).
Prerequisites
-
You have access to an OpenShift Container Platform cluster with
cluster-adminprivileges. - You have installed the Red Hat OpenShift GitOps Operator on your cluster.
- You have enabled notifications for the Argo CD instance. For more information, see "Enabling notifications with an Argo CD instance".
Procedure
Edit the default
NotificationsConfigurationCR in the cluster by running the following command:$ oc edit notificationsconfiguration default-notifications-configuration -n <namespace>where:
default-notifications-configuration-
Specifies the name of the default
NotificationsConfigurationCR. <namespace>- Specifies the name of the namespace.
Under the
templatessection of the CR, add a configuration similar to the following example:Example template configuration:
template.my-custom-template: | message: | Application details: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}.Verify the contents of the
argocd-notifications-cmconfig map by running the following command:$ oc edit cm argocd-notifications-cm -n <namespace>The changes made in the existing configuration of the
NotificationsConfigurationCR are reflected in theargocd-notifications-cmconfig map.
2.6. Configuring notifications in any Namespace リンクのコピーリンクがクリップボードにコピーされました!
By default, Argo CD manages notification configuration only within the control plane namespace. With Red Hat OpenShift GitOps Operator, cluster administrators can enable teams to manage notification settings for their applications from additional namespaces.
To enable this functionality, configure the target namespaces in the Argo CD custom resource (CR). The Red Hat OpenShift GitOps Operator reconciles the corresponding notification resources only for namespaces that are explicitly defined in the ArgoCD CR.
To enable notification configuration in a namespace, you must add the namespace to the following fields in the Argo CD CR:
-
.spec.sourceNamespaces: Enables theApps in Any Namespacefeature for the Application controller. -
.spec.notifications.sourceNamespaces: Allows the Notifications controller to read configuration from that namespace.
If a namespace is not included in these fields, notification configuration for that namespace is not processed.
Procedure
List the ArgoCD CRs in the cluster:
$ oc get argocd -AEdit the target ArgoCD CR:
$ oc edit argocd <cr_name> -n <namespace>Under the
specsection, add each target namespace to thesourceNamespacesandnotifications.sourceNamespacesfields.The following example enables the
example-argocdinstance to manage applications and notification configurations in thefoonamespace:apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: sourceNamespaces: - foo notifications: enabled: true sourceNamespaces: - foo
Verification
-
Verify that the Argo CD instance recognizes the updated
sourceNamespacesconfiguration by checking the settings in the Argo CD CR.
2.6.1. Understanding configuration notifications behavior across namespaces リンクのコピーリンクがクリップボードにコピーされました!
When the Configuring notifications in any namespace feature is enabled, the Red Hat OpenShift GitOps Operator performs additional actions to support delegated notification configuration. For each delegated namespace, the Red Hat OpenShift GitOps Operator automatically creates a NotificationsConfiguration custom resource (CR) named default-notifications-configuration. Application teams can update this CR to define or modify their notification settings.
The Notifications controller determines which configuration to apply by using the following resolution behavior:
-
The controller first checks for the delegated
NotificationsConfigurationCR or the corresponding config map (argocd-notifications-cm) and Secret (argocd-notification-secret) in the namespace of the application. - If no delegated configuration is found, the controller falls back to the central configuration resources (ConfigMap and Secret) defined in the control plane namespace.
To enable this model, the Red Hat OpenShift GitOps Operator creates a Role and a RoleBinding in each delegated namespace, granting the Notifications controller permission to read ConfigMaps and Secrets. The Red Hat OpenShift GitOps Operator also applies the argocd.argoproj.io/notifications-managed-by-cluster-argocd label to each delegated namespace.
2.7. Enabling annotation-based resource tracking in Argo CD リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift GitOps Operator enhances multi-instance support by improving annotation-based resource tracking in Argo CD.Multiple Argo CD instances can use annotation-based tracking by assigning each instance a unique installationID, which enables them to correctly differentiate resources with identical application names, prevent conflicts, avoid infinite sync loops, and operate safely in parallel.
You can perform the following actions by using the OpenShift Container Platform web console:
- Set up multiple Argo CD instances
- Configure annotation-based tracking by associating them with namespaces
- Verify deployments
-
Each Argo CD instance must have a unique
installationIDto prevent resource tracking conflicts. - Ensure that namespaces are labeled accurately because it allows each Argo CD instance to manage only the intended resources.
-
If multiple instances have applications with the same name, set resource tracking to
annotation+label. - If issues arise, check the Argo CD Application status and logs in the OpenShift Container Platform web console.
2.7.1. Configuring annotation-based tracking in multiple Argo CD instances リンクのコピーリンクがクリップボードにコピーされました!
You can configure annotation-based tracking in multiple Argo CD instances.
This procedure uses the following example values:
-
repoURL:https://github.com/redhat-developer/gitops-operator -
server:https://kubernetes.default.svc
When you follow these steps, replace the example values with the actual values.
Prerequisites
- You have logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
Procedure
- Log in to the OpenShift Container Platform web console.
In the Administrator perspective of the web console, click Operators
Installed Operators. - In the Project list, create or select the project where you want to install the user-defined Argo CD instance.
- Select Red Hat OpenShift GitOps from the installed Operators list and click the Argo CD tab.
To create two Argo CD instances, click Create ArgoCD and create two YAML files similar to the following examples:
Example first Argo CD instance with an annotation label:
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: argocd-instance-demo-1 namespace: argocd-test-demo-1 spec: installationID: "instance-demo-1" resourceTrackingMethod: "annotation+label"where:
metadata.name- Specifies the name of the first Argo CD instance.
metadata.namespace- Specifies the namespace used for the first Argo CD instance.
spec.installationID-
Specifies the name of the
installationIDobject for the first Argo CD instance.
Example second Argo CD instance with an annotation label:
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: argocd-instance-demo-2 namespace: argocd-test-demo-2 spec: installationID: "instance-demo-2" resourceTrackingMethod: "annotation+label"where:
metadata.name- Specifies the name of the second Argo CD instance.
metadata.namespace- Specifies the namespace used for the second Argo CD instance.
spec.installationID-
Specifies the name of the
installationIDobject for the second Argo CD instance.
Configure and label target namespaces to associate namespaces with their Argo CD instances.
-
Navigate to Administration
Namespaces. -
Create namespaces for application deployments,
app-ns-1andapp-ns-2. Associate each namespace with their respective Argo CD instance:
Associate the
app-ns-1namespace with theargocd-test-demo-1Argo CD instance by running the following command:Example command:
$ oc label namespace app-ns-1 argocd.argoproj.io/managed-by=argocd-test-demo-1Associate the
app-ns-2namespace with theargocd-test-demo-2Argo CD instance by running the following command:Example command:
$ oc label namespace app-ns-2 argocd.argoproj.io/managed-by=argocd-test-demo-2
-
Navigate to Administration
Create two applications in Argo CD.
-
In the OpenShift Container Platform web console, go to Operators
Installed Operators OpenShift GitOps Operator. - Select Argo CD and navigate to the Applications tab.
- Click Create Application.
Enter the following YAML snippet to create two applications in Argo CD.
Example first application using Argo CD:
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: sprint-petclinic namespace: argocd-test-demo-1 spec: project: default source: repoURL: https://github.com/redhat-developer/gitops-operator path: test/examples/nginx targetRevision: HEAD destination: server: https://kubernetes.default.svc namespace: app-ns-1 syncPolicy: automated: {}where:
metadata.name- Specifies the name of the first application.
metadata.namespace- Specifies the namespace used for the first application.
Example second application using Argo CD:
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: sprint-petclinic namespace: argocd-test-demo-2 spec: project: default source: repoURL: https://github.com/redhat-developer/gitops-operator path: test/examples/nginx targetRevision: HEAD destination: server: https://kubernetes.default.svc namespace: app-ns-2 syncPolicy: automated: {}where:
metadata.name- Specifies the name of the second application that is created with the same name as the first application.
metadata.namespace- Specifies the namespace used for the second application.
-
In the OpenShift Container Platform web console, go to Operators
Verification
-
Navigate to Workloads
Pods in the OpenShift Container Platform web console. -
Ensure that the pods for Argo CD instances
argocd-instance-demo-1andargocd-instance-demo-2are running. - Check the application synchronization status in the Argo CD Applications YAML tab.
-
Navigate to the
argocd-cmconfig map inargocd-test-demo-1andargocd-test-demo-2namespaces and verify that theinstallationIDobject is configured successfully.