Chapter 5. GitOps
5.1. Red Hat OpenShift GitOps release notes
Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud native applications. Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps helps you automate the following tasks:
- Ensure that the clusters have similar states for configuration, monitoring, and storage
- Recover or recreate clusters from a known state
- Apply or revert configuration changes to multiple OpenShift Container Platform clusters
- Associate templated configuration with different environments
- Promote applications across clusters, from staging to production
For an overview of Red Hat OpenShift GitOps, see Understanding OpenShift GitOps.
5.1.1. Compatibility and support matrix
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.
In the table, features are marked with the following statuses:
- TP: Technology Preview
- GA: General Availability
- NA: Not Applicable
In OpenShift Container Platform 4.13, the stable
channel has been removed. Before upgrading to OpenShift Container Platform 4.13, if you are already on the stable
channel, choose the appropriate channel and switch to it.
OpenShift GitOps | Component Versions | OpenShift Versions | ||||||
---|---|---|---|---|---|---|---|---|
Version |
| Helm | Kustomize | Argo CD | ApplicationSet | Dex | RH SSO | |
1.8.0 | 0.0.47 TP | 3.10.0 GA | 4.5.7 GA | 2.6.3 GA | NA | 2.35.1 GA | 7.5.1 GA | 4.10-4.13 |
1.7.0 | 0.0.46 TP | 3.10.0 GA | 4.5.7 GA | 2.5.4 GA | NA | 2.35.1 GA | 7.5.1 GA | 4.10-4.12 |
1.6.0 | 0.0.46 TP | 3.8.1 GA | 4.4.1 GA | 2.4.5 GA | GA and included in ArgoCD component | 2.30.3 GA | 7.5.1 GA | 4.8-4.11 |
1.5.0 | 0.0.42 TP | 3.8.0 GA | 4.4.1 GA | 2.3.3 GA | 0.4.1 TP | 2.30.3 GA | 7.5.1 GA | 4.8-4.11 |
1.4.0 | 0.0.41 TP | 3.7.1 GA | 4.2.0 GA | 2.2.2 GA | 0.2.0 TP | 2.30.0 GA | 7.4.0 GA | 4.7-4.10 |
1.3.0 | 0.0.40 TP | 3.6.0 GA | 4.2.0 GA | 2.1.2 GA | 0.2.0 TP | 2.28.0 GA | 7.4.0 GA | 4.7-4.9, 4.6 with limited GA support |
1.2.0 | 0.0.38 TP | 3.5.0 GA | 3.9.4 GA | 2.0.5 GA | 0.1.0 TP | NA | 7.4.0 GA | 4.8 |
1.1.0 | 0.0.32 TP | 3.5.0 GA | 3.9.4 GA | 2.0.0 GA | NA | NA | NA | 4.7 |
-
kam
is the Red Hat OpenShift GitOps Application Manager command-line interface (CLI). - RH SSO is an abbreviation for Red Hat SSO.
5.1.1.1. Technology Preview features
The features mentioned in the following table are currently in Technology Preview (TP). These experimental features are not intended for production use.
Feature | TP in Red Hat OpenShift GitOps versions | GA in Red Hat OpenShift GitOps versions |
---|---|---|
ApplicationSet Progressive Rollout Strategy | 1.8.0 | NA |
Multiple sources for an application | 1.8.0 | NA |
Argo CD applications in non-control plane namespaces | 1.7.0 | NA |
Argo CD Notifications controller | 1.6.0 | NA |
The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console | 1.1.0 | NA |
5.1.2. Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
5.1.3. Release notes for Red Hat OpenShift GitOps 1.8.4
Red Hat OpenShift GitOps 1.8.4 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.
5.1.3.1. New features
The current release adds the following improvements:
- With this update, the bundled Argo CD has been updated to version 2.6.13.
5.1.3.2. Fixed issues
The following issues have been resolved in the current release:
- Before this update, Argo CD was becoming unresponsive when there was an increase in namespaces and applications. The functions competing for resources caused a deadlock. This update fixes the issue by removing the deadlock. Now, you should not experience crashes or unresponsiveness when there is an increase in namespaces or applications. GITOPS-3192
- Before this update, the Argo CD application controller resource could suddenly stop working when resynchronizing applications. This update fixes the issue by adding logic to prevent a cluster cache deadlock. Now, applications should resynchronize successfully. GITOPS-3052
-
Before this update, there was a mismatch in the RSA key for known hosts in the
argocd-ssh-known-hosts-cm
config map. This update fixes the issue by matching the RSA key with the upstream project. Now, you can use the default RSA keys on default deployments. GITOPS-3144 -
Before this update, an old Redis image version was used when deploying the Red Hat OpenShift GitOps Operator, which resulted in vulnerabilities. This update fixes the vulnerabilities on Redis by upgrading it to the latest version of the
registry.redhat.io/rhel-8/redis-6
image. GITOPS-3069 -
Before this update, users could not connect to Microsoft Team Foundation Server (TFS) type Git repositories through Argo CD deployed by the Operator. This update fixes the issue by updating the Git version to 2.39.3 in the Operator. Now, you can set the
Force HTTP basic auth
flag during repository configurations to connect with the TFS type Git repositories. GITOPS-1315
5.1.3.3. Known issues
Currently, Red Hat OpenShift GitOps 1.8.4 is not available in the
latest
channel of OpenShift Container Platform 4.10 and 4.11. Thelatest
channel is taken by GitOps 1.9.z, which is only released on OpenShift Container Platform 4.12 and later versions.As a workaround, switch to the
gitops-1.8
channel to get the new update. GITOPS-3158
5.1.4. Release notes for Red Hat OpenShift GitOps 1.8.3
Red Hat OpenShift GitOps 1.8.3 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.
5.1.4.1. Errata updates
5.1.4.1.1. RHBA-2023:3206 and RHSA-2023:3229 - Red Hat OpenShift GitOps 1.8.3 security update advisory
Issued: 2023-05-18
The list of security fixes that are included in this release is documented in the following advisories:
If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
5.1.4.2. Fixed issues
-
Before this update, when
Autoscale
was enabled and the horizontal pod autoscaler (HPA) controller tried to edit the replica settings in server deployment, the Operator overwrote it. In addition, any changes specified to the autoscaler parameters were not propagated correctly to the HPA on the cluster. This update fixes the issue. Now the Operator reconciles on replica drift only ifAutoscale
is disabled and the HPA parameters are updated correctly. GITOPS-2629
5.1.5. Release notes for Red Hat OpenShift GitOps 1.8.2
Red Hat OpenShift GitOps 1.8.2 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.
5.1.5.1. Fixed issues
The following issues have been resolved in the current release:
Before this update, when you configured Dex using the
.spec.dex
parameter and tried to log in to the Argo CD UI by using the LOG IN VIA OPENSHIFT option, you were not able to log in. This update fixes the issue.ImportantThe
spec.dex
parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using thespec.dex
parameter in the ArgoCD CR is planned to be removed. Consider using the.spec.sso
parameter instead. See "Enabling or disabling Dex using .spec.sso". GITOPS-2761-
Before this update, the cluster and
kam
CLI pods failed to start with a new installation of Red Hat OpenShift GitOps v1.8.0 on the OpenShift Container Platform 4.10 cluster. This update fixes the issue and now all pods run as expected. GITOPS-2762
5.1.6. Release notes for Red Hat OpenShift GitOps 1.8.1
Red Hat OpenShift GitOps 1.8.1 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.
5.1.6.1. Errata updates
5.1.6.1.1. RHSA-2023:1452 - Red Hat OpenShift GitOps 1.8.1 security update advisory
Issued: 2023-03-23
The list of security fixes that are included in this release is documented in the RHSA-2023:1452 advisory.
If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
5.1.7. Release notes for Red Hat OpenShift GitOps 1.8.0
Red Hat OpenShift GitOps 1.8.0 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.
5.1.7.1. New features
The current release adds the following improvements:
With this update, you can add support for the ApplicationSet Progressive Rollout Strategy feature. Using this feature, you can enhance the ArgoCD ApplicationSet resource to embed a rollout strategy for a progressive application resource update after you modify the ApplicationSet spec or Application templates. When you enable this feature, applications are updated in a declarative order instead of simultaneously. GITOPS-956
ImportantApplicationSet Progressive Rollout Strategy is a Technology Preview feature.
-
With this update, the Application environments page in the Developer perspective of the OpenShift Container Platform web console is decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI),
kam
. You do not have to use thekam
CLI to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed. GITOPS-1785 With this update, the Red Hat OpenShift GitOps Operator and the
kam
CLI are now available to use on ARM architecture on OpenShift Container Platform. GITOPS-1688Importantspec.sso.provider: keycloak
is not yet supported on ARM.-
With this update, you can enable workload monitoring for specific Argo CD instances by setting the
.spec.monitoring.enabled
flag value totrue
. As a result, the Operator creates aPrometheusRule
object that contains alert rules for each Argo CD component. These alert rules trigger an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to thePrometheusRule
object by the users. GITOPS-2459 With this update, you can pass command arguments to the repo server deployment using the Argo CD CR. GITOPS-2445
For example:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: repo: extraRepoCommandArgs: - --max.combined.directory.manifests.size - 10M
5.1.7.2. Fixed issues
The following issues have been resolved in the current release:
Before this update, you could set the
ARGOCD_GIT_MODULES_ENABLED
environment variable only on theopenshift-gitops-repo-server
pod and not on theApplicationSet Controller
pod. As a result, when using the Git generator, Git submodules were cloned during the generation of child applications because the variable was missing from theApplicationSet Controller
environment. In addition, if the credentials required to clone these submodules were not configured in ArgoCD, the application generation failed. This update fixes the issue; you can now add any environment variables such asArgoCD_GIT_MODULES_ENABLED
to theApplicationSet Controller
pod using the Argo CD CR. TheApplicationSet Controller
pod then successfully generates child applications from the cloned repository and no submodule is cloned in the process. GITOPS-2399For example:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: applicationSet: env: - name: ARGOCD_GIT_MODULES_ENABLED value: "true"
-
Before this update, while installing the Red Hat OpenShift GitOps Operator v1.7.0, the default
argocd-cm.yml
config map file created for authenticating Dex contained the base64-encoded client secret in the format of akey:value
pair. This update fixes this issue by not storing the client secret in the defaultargocd-cm.yml
config map file. Instead, the client secret is inside anargocd-secret
object now, and you can reference it inside the configuration map as a secret name. GITOPS-2570
5.1.7.3. Known issues
-
When you deploy applications using your manifests without using the
kam
CLI and view the applications in the Application environments page in the Developer perspective of the OpenShift Container Platform web console, the Argo CD URL to the corresponding application does not load the page as expected from the Argo CD icon in the card. GITOPS-2736
5.1.8. Release notes for Red Hat OpenShift GitOps 1.7.4
Red Hat OpenShift GitOps 1.7.4 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.
5.1.8.1. Errata updates
5.1.8.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.4 security update advisory
Issued: 2023-03-23
The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory.
If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
5.1.9. Release notes for Red Hat OpenShift GitOps 1.7.3
Red Hat OpenShift GitOps 1.7.3 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.
5.1.9.1. Errata updates
5.1.9.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.3 security update advisory
Issued: 2023-03-23
The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory.
If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
5.1.10. Release notes for Red Hat OpenShift GitOps 1.7.1
Red Hat OpenShift GitOps 1.7.1 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.
5.1.10.1. Errata updates
5.1.10.1.1. RHSA-2023:0467 - Red Hat OpenShift GitOps 1.7.1 security update advisory
Issued: 2023-01-25
The list of security fixes that are included in this release is documented in the RHSA-2023:0467 advisory.
If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:
$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
5.1.11. Release notes for Red Hat OpenShift GitOps 1.7.0
Red Hat OpenShift GitOps 1.7.0 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.
5.1.11.1. New features
The current release adds the following improvements:
- With this update, you can add environment variables to the Notifications controller. GITOPS-2313
-
With this update, the default nodeSelector
"kubernetes.io/os": "linux"
key-value pair is added to all workloads such that they only schedule on Linux nodes. In addition, any custom node selectors are added to the default and take precedence if they have the same key. GITOPS-2215 -
With this update, you can set custom node selectors in the Operator workloads by editing their
GitopsService
custom resource. GITOPS-2164 -
With this update, you can use the RBAC policy matcher mode to select from the following options:
glob
(default) andregex
.GITOPS-1975 With this update, you can customize resource behavior using the following additional subkeys:
Subkey Key form Mapped field in argocd-cm resourceHealthChecks
resource.customizations.health.<group_kind>
resource.customizations.health
resourceIgnoreDifferences
resource.customizations.ignoreDifferences.<group_kind>
resource.customizations.ignoreDifferences
resourceActions
resource.customizations.actions.<group_kind>
resource.customizations.actions
NoteIn future releases, there is a possibility to deprecate the old method of customizing resource behavior by using only resourceCustomization and not subkeys.
- With this update, to use the Environments page in the Developer perspective, you must upgrade if you are using a Red Hat OpenShift GitOps version prior to 1.7 and OpenShift Container Platform 4.15 or above. GITOPS-2415
With this update, you can create applications, which are managed by the same control plane Argo CD instance, in any namespace in the same cluster. As an administrator, perform the following actions to enable this update:
-
Add the namespace to the
.spec.sourceNamespaces
attribute for a cluster-scoped Argo CD instance that manages the application. Add the namespace to the
.spec.sourceNamespaces
attribute in theAppProject
custom resource that is associated with the application.
-
Add the namespace to the
Argo CD applications in non-control plane namespaces is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
With this update, Argo CD supports the Server-Side Apply feature, which helps users to perform the following tasks:
- Manage large resources which are too big for the allowed annotation size of 262144 bytes.
Patch an existing resource that is not managed or deployed by Argo CD.
You can configure this feature at application or resource level. GITOPS-2340
5.1.11.2. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, Red Hat OpenShift GitOps releases were affected by an issue of Dex pods failing with
CreateContainerConfigError
error when theanyuid
SCC was assigned to the Dex service account. This update fixes the issue by assigning a default user id to the Dex container. GITOPS-2235 -
Before this update, Red Hat OpenShift GitOps used the RHSSO (Keycloak) through OIDC in addition to Dex. However, with a recent security fix, the certificate of RHSSO could not be validated when configured with a certificate not signed by one of the well-known certificate authorities. This update fixes the issue; you can now provide a custom certificate to verify the KeyCloak’s TLS certificate while communicating with it. In addition, you can add
rootCA
to the Argo CD custom resource.spec.keycloak.rootCA
field. The Operator reconciles such changes and updates theoidc.config in argocd-cm
config map with the PEM encoded root certificate. GITOPS-2214
Example Argo CD with Keycloak configuration:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: sso: keycloak: rootCA: '<PEM encoded root certificate>' provider: keycloak ....... .......
-
Before this update, the application controllers restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the
statefulset
application controller. GITOPS-2153
5.1.11.3. Known issues
-
Before this update, the Operator did not reconcile the
mountsatoken
andServiceAccount
settings for the repository server. While this has been fixed, deletion of the service account does not revert to the default. GITOPS-1873 -
Workaround: Manually set the
spec.repo.serviceaccountfield to thedefault
service account. GITOPS-2452
5.1.12. Release notes for Red Hat OpenShift GitOps 1.6.7
Red Hat OpenShift GitOps 1.6.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.12.1. Fixed issues
The following issue has been resolved in the current release:
- Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635, CVE-2022-41354
5.1.13. Release notes for Red Hat OpenShift GitOps 1.6.6
Red Hat OpenShift GitOps 1.6.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.13.1. Fixed issues
The following issue has been resolved in the current release:
- Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635, CVE-2022-41354
5.1.14. Release notes for Red Hat OpenShift GitOps 1.6.4
Red Hat OpenShift GitOps 1.6.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.14.1. Fixed issues
- Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for audiences who might not be intended to access the cluster. This issue is now fixed. CVE-2023-22482
5.1.15. Release notes for Red Hat OpenShift GitOps 1.6.2
Red Hat OpenShift GitOps 1.6.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10 and 4.11.
5.1.15.1. New features
-
This release removes the
DISABLE_DEX
environment variable from theopenshift-gitops-operator
CSV file. As a result, this environment variable is no longer set when you perform a fresh installation of Red Hat OpenShift GitOps. GITOPS-2360
5.1.15.2. Fixed issues
The following issues have been resolved in the current release:
- Before this update, the subscription health check was marked degraded for missing InstallPlan when more than 5 Operators were installed in a project. This update fixes the issue. GITOPS-2018
- Before this update, the Red Hat OpenShift GitOps Operator would spam the cluster with a deprecation notice warning whenever it detected that an Argo CD instance used deprecated fields. This update fixes this issue and shows only one warning event for each instance that detects a field. GITOPS-2230
- From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2352
5.1.16. Release notes for Red Hat OpenShift GitOps 1.6.1
Red Hat OpenShift GitOps 1.6.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.16.1. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller
StatefulSet
object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the
rootCA
to the Argo CD custom resource.spec.keycloak.rootCA
field. The Operator reconciles this change and updates theoidc.config
field in theargocd-cm
ConfigMap
with the PEM-encoded root certificate. GITOPS-2214NoteRestart the Argo CD server pod after updating the
.spec.keycloak.rootCA
field.For example:
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
- Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2277
-
Before this update, the Dex pods failed to start with
CreateContainerConfigError
when an SCC ofanyuid
was assigned to the DexServiceAccount
resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235
5.1.17. Release notes for Red Hat OpenShift GitOps 1.6.0
Red Hat OpenShift GitOps 1.6.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.17.1. New features
The current release adds the following improvements:
-
Previously, the Argo CD
ApplicationSet
controller was a technology preview (TP) feature. With this update, it is a general availability (GA) feature. GITOPS-1958 -
With this update, the latest releases of the Red Hat OpenShift GitOps are available in
latest
and version-based channels. To get these upgrades, update thechannel
parameter in theSubscription
object YAML file: change its value fromstable
tolatest
or a version-based channel such asgitops-1.6
. GITOPS-1791 -
With this update, the parameters of the
spec.sso
field that controlled the keycloak configurations are moved to.spec.sso.keycloak
. The parameters of the.spec.dex
field have been added to.spec.sso.dex
. Start using.spec.sso.provider
to enable or disable Dex. The.spec.dex
parameters are deprecated and planned to be removed in version 1.9, along with theDISABLE_DEX
and.spec.sso
fields for keycloak configuration. GITOPS-1983 -
With this update, the Argo CD Notifications controller is available as an optional workload that can be enabled or disabled by using the
.spec.notifications.enabled
parameter in the Argo CD custom resource. The Argo CD Notifications controller is available as a Technical Preview feature. GITOPS-1917
Argo CD Notifications controller is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
- With this update, resource exclusions for Tekton pipeline runs and tasks runs are added by default. Argo CD, prunes these resources by default. These resource exclusions are added to the new Argo CD instances that are created from the OpenShift Container Platform. If the instances are created from the CLI, the resources are not added. GITOPS-1876
-
With this update, you can select the tracking method that by Argo CD uses by setting the
resourceTrackingMethod
parameter in the Operand’s specification. GITOPS-1862 -
With this update, you can add entries to the
argocd-cm
configMap using theextraConfig
field of Red Hat OpenShift GitOps Argo CD custom resource. The entries specified are reconciled to the liveconfig-cm
configMap without validations. GITOPS-1964 - With this update, on OpenShift Container Platform 4.11, the Red Hat OpenShift GitOps Environments page in the Developer perspective shows history of the successful deployments of the application environments, along with links to the revision for each deployment. GITOPS-1269
- With this update, you can manage resources with Argo CD that are also being used as template resources or "source" by an Operator. GITOPS-982
- With this update, the Operator will now configure the Argo CD workloads with the correct permissions to satisfy the Pod Security Admission that has been enabled for Kubernetes 1.24. GITOPS-2026
- With this update, Config Management Plugins 2.0 is supported. You can use the Argo CD custom resource to specify sidebar containers for the repo server. GITOPS-776
- With this update, all communication between the Argo CD components and the Redis cache are properly secured using modern TLS encryption. GITOPS-720
- This release of Red Hat OpenShift GitOps adds support for IBM Z and IBM Power on OpenShift Container Platform 4.10. Currently, installations in restricted environments are not supported on IBM Z and IBM Power.
5.1.17.2. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, the
system:serviceaccount:argocd:gitops-argocd-application-controller
cannot create resource "prometheusrules" in API groupmonitoring.coreos.com
in the namespacewebapps-dev
. This update fixes this issue and Red Hat OpenShift GitOps is now able to manage all resources from themonitoring.coreos.com
API group. GITOPS-1638 -
Before this update, while reconciling cluster permissions, if a secret belonged to a cluster config instance it was deleted. This update fixes this issue. Now, the
namespaces
field from the secret is deleted instead of the secret. GITOPS-1777 -
Before this update, if you installed the HA variant of Argo CD through the Operator, the Operator created the Redis
StatefulSet
object withpodAffinity
rules instead ofpodAntiAffinity
rules. This update fixes this issue and now the Operator creates the RedisStatefulSet
withpodAntiAffinity
rules. GITOPS-1645 -
Before this update, Argo CD ApplicationSet had too many
ssh
Zombie processes. This update fixes this issue: it adds tini, a simple init daemon that spawns processes and reaps zombies, to the ApplicationSet controller. This ensures that aSIGTERM
signal is properly passed to the running process, preventing it from being a zombie process. GITOPS-2108
5.1.17.3. Known issues
Red Hat OpenShift GitOps Operator can make use of RHSSO (KeyCloak) through OIDC in addition to Dex. However, with a recent security fix applied, the certificate of RHSSO cannot be validated in some scenarios. GITOPS-2214
As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.
spec: extraConfig: oidc.tls.insecure.skip.verify: "true" ...
5.1.18. Release notes for Red Hat OpenShift GitOps 1.5.9
Red Hat OpenShift GitOps 1.5.9 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.18.1. Fixed issues
- Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for users who might not be authorized to access the cluster. This issue is now fixed. CVE-2023-22482
5.1.19. Release notes for Red Hat OpenShift GitOps 1.5.7
Red Hat OpenShift GitOps 1.5.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.19.1. Fixed issues
The following issues have been resolved in the current release:
- From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2353
5.1.20. Release notes for Red Hat OpenShift GitOps 1.5.6
Red Hat OpenShift GitOps 1.5.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.20.1. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller
StatefulSet
object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the
rootCA
to the Argo CD custom resource.spec.keycloak.rootCA
field. The Operator reconciles this change and updates theoidc.config
field in theargocd-cm
ConfigMap
with the PEM-encoded root certificate. GITOPS-2214NoteRestart the Argo CD server pod after updating the
.spec.keycloak.rootCA
field.For example:
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
- Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2278
-
Before this update, the Dex pods failed to start with
CreateContainerConfigError
when an SCC ofanyuid
was assigned to the DexServiceAccount
resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235
5.1.21. Release notes for Red Hat OpenShift GitOps 1.5.5
Red Hat OpenShift GitOps 1.5.5 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.21.1. New features
The current release adds the following improvements:
- With this update, the bundled Argo CD has been updated to version 2.3.7.
5.1.21.2. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, the
redis-ha-haproxy
pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034
5.1.21.3. Known issues
Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214
As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true" ...
5.1.22. Release notes for Red Hat OpenShift GitOps 1.5.4
Red Hat OpenShift GitOps 1.5.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.22.1. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, the Red Hat OpenShift GitOps was using an older version of the REDIS 5 image tag. This update fixes the issue and upgrades the
rhel8/redis-5
image tag. GITOPS-2037
5.1.23. Release notes for Red Hat OpenShift GitOps 1.5.3
Red Hat OpenShift GitOps 1.5.3 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.23.1. Fixed issues
The following issues have been resolved in the current release:
- Before this update, all unpatched versions of Argo CD v1.0.0 and later were vulnerable to a cross-site scripting bug. As a result, an unauthorized user would be able to inject a javascript link in the UI. This issue is now fixed. CVE-2022-31035
- Before this update, all versions of Argo CD v0.11.0 and later were vulnerable to multiple attacks when SSO login was initiated from the Argo CD CLI or the UI. This issue is now fixed. CVE-2022-31034
- Before this update, all unpatched versions of Argo CD v0.7 and later were vulnerable to a memory consumption bug. As a result, an unauthorized user would be able to crash the Argo CD’s repo-server. This issue is now fixed. CVE-2022-31016
- Before this update, all unpatched versions of Argo CD v1.3.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive YAML files from Argo CD’s repo-server. This issue is now fixed. CVE-2022-31036
5.1.24. Release notes for Red Hat OpenShift GitOps 1.5.2
Red Hat OpenShift GitOps 1.5.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.24.1. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, images referenced by the
redhat-operator-index
were missing. This issue is now fixed. GITOPS-2036
5.1.25. Release notes for Red Hat OpenShift GitOps 1.5.1
Red Hat OpenShift GitOps 1.5.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.25.1. Fixed issues
The following issues have been resolved in the current release:
- Before this update, if Argo CD’s anonymous access was enabled, an unauthenticated user was able to craft a JWT token and get full access to the Argo CD instance. This issue is fixed now. CVE-2022-29165
- Before this update, an unauthenticated user was able to display error messages on the login screen while SSO was enabled. This issue is now fixed. CVE-2022-24905
- Before this update, all unpatched versions of Argo CD v0.7.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive files from Argo CD’s repo-server. This issue is now fixed. CVE-2022-24904
5.1.26. Release notes for Red Hat OpenShift GitOps 1.5.0
Red Hat OpenShift GitOps 1.5.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.
5.1.26.1. New features
The current release adds the following improvements:
- This enhancement upgrades Argo CD to version 2.3.3. GITOPS-1708
- This enhancement upgrades Dex to version 2.30.3. GITOPS-1850
- This enhancement upgrades Helm to version 3.8.0. GITOPS-1709
- This enhancement upgrades Kustomize to version 4.4.1. GITOPS-1710
- This enhancement upgrades Application Set to version 0.4.1.
- With this update, a new channel by the name latest has been added that provides the latest release of the Red Hat OpenShift GitOps. For GitOps v1.5.0, the Operator is pushed to gitops-1.5, latest channel, and the existing stable channel. From GitOps v1.6 all the latest releases will be pushed only to the latest channel and not the stable channel. GITOPS-1791
-
With this update, the new CSV adds the
olm.skipRange: '>=1.0.0 <1.5.0'
annotation. As a result, all the previous release versions will be skipped. The Operator upgrades to v1.5.0 directly. GITOPS-1787 With this update, the Operator updates the Red Hat Single Sign-On (RH-SSO) to version v7.5.1 including the following enhancements:
-
You can log in to Argo CD using the OpenShift credentials including the
kube:admin
credential. - The RH-SSO supports and configures Argo CD instances for Role-based Access Control (RBAC) using OpenShift groups.
The RH-SSO honors the
HTTP_Proxy
environment variables. You can use the RH-SSO as an SSO for Argo CD running behind a proxy.
-
You can log in to Argo CD using the OpenShift credentials including the
With this update, a new
.host
URL field is added to the.status
field of the Argo CD operand. When a route or ingress is enabled with the priority given to route, then the new URL field displays the route. If no URL is provided from the route or ingress, the.host
field is not displayed.When the route or ingress is configured, but the corresponding controller is not set up properly and is not in the
Ready
state or does not propagate its URL, the value of the.status.host
field in the operand indicates asPending
instead of displaying the URL. This affects the overall status of the operand by making itPending
instead ofAvailable
. GITOPS-654
5.1.26.2. Fixed issues
The following issues have been resolved in the current release:
- Before this update, RBAC rules specific to AppProjects would not allow the use of commas for the subject field of the role, thus preventing bindings to the LDAP account. This update fixes the issue and you can now specify complex role bindings in AppProject specific RBAC rules. GITOPS-1771
-
Before this update, when a
DeploymentConfig
resource is scaled to0
, Argo CD displayed it in a progressing state with a health status message as "replication controller is waiting for pods to run". This update fixes the edge case and the health check now reports the correct health status of theDeploymentConfig
resource. GITOPS-1738 -
Before this update, the TLS certificate in the
argocd-tls-certs-cm
configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in theArgoCD
CR specificationtls.initialCerts
field. This issue is fixed now. GITOPS-1725 -
Before this update, while creating a namespace with the
managed-by
label it created a lot ofRoleBinding
resources on the new namespace. This update fixes the issue and now Red Hat OpenShift GitOps removes the irrelevantRole
andRoleBinding
resources created by the previous versions. GITOPS-1550 -
Before this update, the TLS certificate of the route in pass-through mode did not have a CA name. As a result, Firefox 94 and later failed to connect to Argo CD UI with error code SEC_ERROR_BAD_DER. This update fixes the issue. You must delete the
<openshift-gitops-ca>
secrets and let it recreate. Then, you must delete the<openshift-gitops-tls>
secrets. After the Red Hat OpenShift GitOps recreates it, the Argo CD UI is accessible by Firefox again. GITOPS-1548
5.1.26.3. Known issues
-
Argo CD
.status.host
field is not updated when anIngress
resource is in use instead of aRoute
resource on OpenShift clusters. GITOPS-1920
5.1.27. Release notes for Red Hat OpenShift GitOps 1.4.13
Red Hat OpenShift GitOps 1.4.13 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.27.1. Fixed issues
The following issues have been resolved in the current release:
- From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2354
5.1.28. Release notes for Red Hat OpenShift GitOps 1.4.12
Red Hat OpenShift GitOps 1.4.12 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.28.1. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller
StatefulSet
object. GITOPS-2153 Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the
rootCA
to the Argo CD custom resource.spec.keycloak.rootCA
field. The Operator reconciles this change and updates theoidc.config
field in theargocd-cm
ConfigMap
with the PEM-encoded root certificate. GITOPS-2214NoteRestart the Argo CD server pod after updating the
.spec.keycloak.rootCA
field.For example:
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
- Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2276
-
Before this update, the Dex pods failed to start with
CreateContainerConfigError
when an SCC ofanyuid
was assigned to the DexServiceAccount
resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235
5.1.29. Release notes for Red Hat OpenShift GitOps 1.4.11
Red Hat OpenShift GitOps 1.4.11 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.29.1. New features
The current release adds the following improvements:
- With this update, the bundled Argo CD has been updated to version 2.2.12.
5.1.29.2. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, the
redis-ha-haproxy
pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034
5.1.29.3. Known issues
Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214
As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: extraConfig: "admin.enabled": "true" ...
5.1.30. Release notes for Red Hat OpenShift GitOps 1.4.6
Red Hat OpenShift GitOps 1.4.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.30.1. Fixed issues
The following issue has been resolved in the current release:
- The base images are updated to the latest version to avoid OpenSSL flaw link: (CVE-2022-0778).
To install the current release of Red Hat OpenShift GitOps 1.4 and receive further updates during its product life cycle, switch to the GitOps-1.4 channel.
5.1.31. Release notes for Red Hat OpenShift GitOps 1.4.5
Red Hat OpenShift GitOps 1.4.5 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.31.1. Fixed issues
You should directly upgrade to Red Hat OpenShift GitOps v1.4.5 from Red Hat OpenShift GitOps v1.4.3. Do not use Red Hat OpenShift GitOps v1.4.4 in a production environment. Major issues that affected Red Hat OpenShift GitOps v1.4.4 are fixed in Red Hat OpenShift GitOps 1.4.5.
The following issue has been resolved in the current release:
-
Before this update, Argo CD pods were stuck in the
ErrImagePullBackOff
state. The following error message was shown:
reason: ErrImagePull message: >- rpc error: code = Unknown desc = reading manifest sha256:ff4ad30752cf0d321cd6c2c6fd4490b716607ea2960558347440f2f370a586a8 in registry.redhat.io/openshift-gitops-1/argocd-rhel8: StatusCode: 404, <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>
This issue is now fixed. GITOPS-1848
5.1.32. Release notes for Red Hat OpenShift GitOps 1.4.3
Red Hat OpenShift GitOps 1.4.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.32.1. Fixed issues
The following issue has been resolved in the current release:
-
Before this update, the TLS certificate in the
argocd-tls-certs-cm
configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in the ArgoCD CR specificationtls.initialCerts
field. This update fixes this issue. GITOPS-1725
5.1.33. Release notes for Red Hat OpenShift GitOps 1.4.2
Red Hat OpenShift GitOps 1.4.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.33.1. Fixed issues
The following issue has been resolved in the current release:
-
Before this update, the Route resources got stuck in
Progressing
Health status if more than oneIngress
were attached to the route. This update fixes the health check and reports the correct health status of the Route resources. GITOPS-1751
5.1.34. Release notes for Red Hat OpenShift GitOps 1.4.1
Red Hat OpenShift GitOps 1.4.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.34.1. Fixed issues
The following issue has been resolved in the current release:
Red Hat OpenShift GitOps Operator v1.4.0 introduced a regression which removes the description fields from
spec
for the following CRDs:-
argoproj.io_applications.yaml
-
argoproj.io_appprojects.yaml
argoproj.io_argocds.yaml
Before this update, when you created an
AppProject
resource using theoc create
command, the resource failed to synchronize due to the missing description fields. This update restores the missing description fields in the preceding CRDs. GITOPS-1721
-
5.1.35. Release notes for Red Hat OpenShift GitOps 1.4.0
Red Hat OpenShift GitOps 1.4.0 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.
5.1.35.1. New features
The current release adds the following improvements.
-
This enhancement upgrades the Red Hat OpenShift GitOps Application Manager CLI (
kam
) to version 0.0.41. GITOPS-1669 - This enhancement upgrades Argo CD to version 2.2.2. GITOPS-1532
- This enhancement upgrades Helm to version 3.7.1. GITOPS-1530
-
This enhancement adds the health status of the
DeploymentConfig
,Route
, andOLM Operator
items to the Argo CD Dashboard and OpenShift Container Platform web console. This information helps you monitor the overall health status of your application. GITOPS-655, GITOPS-915, GITOPS-916, GITOPS-1110 -
With this update, you can to specify the number of desired replicas for the
argocd-server
andargocd-repo-server
components by setting the.spec.server.replicas
and.spec.repo.replicas
attributes in the Argo CD custom resource, respectively. If you configure the horizontal pod autoscaler (HPA) for theargocd-server
components, it takes precedence over the Argo CD custom resource attributes. GITOPS-1245 As an administrative user, when you give Argo CD access to a namespace by using the
argocd.argoproj.io/managed-by
label, it assumes namespace-admin privileges. These privileges are an issue for administrators who provide namespaces to non-administrators, such as development teams, because the privileges enable non-administrators to modify objects such as network policies.With this update, administrators can configure a common cluster role for all the managed namespaces. In role bindings for the Argo CD application controller, the Operator refers to the
CONTROLLER_CLUSTER_ROLE
environment variable. In role bindings for the Argo CD server, the Operator refers to theSERVER_CLUSTER_ROLE
environment variable. If these environment variables contain custom roles, the Operator doesn’t create the default admin role. Instead, it uses the existing custom role for all managed namespaces. GITOPS-1290-
With this update, the Environments page in the OpenShift Container Platform Developer perspective displays a broken heart icon to indicate degraded resources, excluding ones whose status is
Progressing
,Missing
, andUnknown
. The console displays a yellow yield sign icon to indicate out-of-sync resources. GITOPS-1307
5.1.35.2. Fixed issues
The following issues have been resolved in the current release:
-
Before this update, when the Route to the Red Hat OpenShift GitOps Application Manager CLI (
kam
) was accessed without specifying a path in the URL, a default page without any helpful information was displayed to the user. This update fixes the issue so that the default page displays download links for thekam
CLI. GITOPS-923 - Before this update, setting a resource quota in the namespace of the Argo CD custom resource might cause the setup of the Red Hat SSO (RH SSO) instance to fail. This update fixes this issue by setting a minimum resource request for the RH SSO deployment pods. GITOPS-1297
-
Before this update, if you changed the log level for the
argocd-repo-server
workload, the Operator didn’t reconcile this setting. The workaround was to delete the deployment resource so that the Operator recreated it with the new log level. With this update, the log level is correctly reconciled for existingargocd-repo-server
workloads. GITOPS-1387 -
Before this update, if the Operator managed an Argo CD instance that lacked the
.data
field in theargocd-secret
Secret, the Operator on that instance crashed. This update fixes the issue so that the Operator doesn’t crash when the.data
field is missing. Instead, the secret regenerates and thegitops-operator-controller-manager
resource is redeployed. GITOPS-1402 -
Before this update, the
gitopsservice
service was annotated as an internal object. This update removes the annotation so you can update or delete the default Argo CD instance and run GitOps workloads on infrastructure nodes by using the UI. GITOPS-1429
5.1.35.3. Known issues
These are the known issues in the current release:
If you migrate from the Dex authentication provider to the Keycloak provider, you might experience login issues with Keycloak.
To prevent this issue, when migrating, uninstall Dex by removing the
.spec.dex
section from the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely. Then, install Keycloak by adding.spec.sso.provider: keycloak
to the Argo CD custom resource.As a workaround, uninstall Keycloak by removing
.spec.sso.provider: keycloak
. Then, re-install it. GITOPS-1450, GITOPS-1331
5.1.36. Release notes for Red Hat OpenShift GitOps 1.3.7
Red Hat OpenShift GitOps 1.3.7 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.
5.1.36.1. Fixed issues
The following issue has been resolved in the current release:
- Before this update, a flaw was found in OpenSSL. This update fixes the issue by updating the base images to the latest version to avoid the OpenSSL flaw. (CVE-2022-0778).
To install the current release of Red Hat OpenShift GitOps 1.3 and receive further updates during its product life cycle, switch to the GitOps-1.3 channel.
5.1.37. Release notes for Red Hat OpenShift GitOps 1.3.6
Red Hat OpenShift GitOps 1.3.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.
5.1.37.1. Fixed issues
The following issues have been resolved in the current release:
- In Red Hat OpenShift GitOps, improper access control allows admin privilege escalation (CVE-2022-1025). This update fixes the issue.
- A path traversal flaw allows leaking of out-of-bound files (CVE-2022-24731). This update fixes the issue.
- A path traversal flaw and improper access control allows leaking of out-of-bound files (CVE-2022-24730). This update fixes the issue.
5.1.38. Release notes for Red Hat OpenShift GitOps 1.3.2
Red Hat OpenShift GitOps 1.3.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.
5.1.38.1. New features
In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.2:
- Upgraded Argo CD to version 2.1.8
- Upgraded Dex to version 2.30.0
5.1.38.2. Fixed issues
The following issues have been resolved in the current release:
-
Previously, in the OperatorHub UI under the Infrastructure Features section, when you filtered by
Disconnected
the Red Hat OpenShift GitOps Operator did not show in the search results, as the Operator did not have the related annotation set in its CSV file. With this update, theDisconnected Cluster
annotation has been added to the Red Hat OpenShift GitOps Operator as an infrastructure feature. GITOPS-1539 When using an
Namespace-scoped
Argo CD instance, for example, an Argo CD instance that is not scoped to All Namepsaces in a cluster, Red Hat OpenShift GitOps dynamically maintains a list of managed namespaces. These namespaces include theargocd.argoproj.io/managed-by
label. This list of namespaces is stored in a cache in Argo CDSettings Clusters "in-cluster" NAMESPACES. Before this update, if you deleted one of these namespaces, the Operator ignored that, and the namespace remained in the list. This behavior broke the CONNECTION STATE in that cluster configuration, and all sync attempts resulted in errors. For example: Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.
This bug is fixed. GITOPS-1521
- With this update, the Red Hat OpenShift GitOps Operator has been annotated with the Deep Insights capability level. GITOPS-1519
-
Previously, the Argo CD Operator managed the
resource.exclusion
field by itself but ignored theresource.inclusion
field. This prevented theresource.inclusion
field configured in theArgo CD
CR to generate in theargocd-cm
configuration map. This bug is fixed. GITOPS-1518
5.1.39. Release notes for Red Hat OpenShift GitOps 1.3.1
Red Hat OpenShift GitOps 1.3.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.
5.1.39.1. Fixed issues
- If you upgrade to v1.3.0, the Operator does not return an ordered slice of environment variables. As a result, the reconciler fails causing the frequent recreation of Argo CD pods in OpenShift Container Platform clusters running behind a proxy. This update fixes the issue so that Argo CD pods are not recreated. GITOPS-1489
5.1.40. Release notes for Red Hat OpenShift GitOps 1.3
Red Hat OpenShift GitOps 1.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.
5.1.40.1. New features
In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.0:
-
For a fresh install of v1.3.0, Dex is automatically configured. You can log into the default Argo CD instance in the
openshift-gitops
namespace using the OpenShift orkubeadmin
credentials. As an admin you can disable the Dex installation after the Operator is installed which will remove the Dex deployment from theopenshift-gitops
namespace. - The default Argo CD instance installed by the Operator as well as accompanying controllers can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle.
- Internal communications in Argo CD can now be secured using the TLS and the OpenShift cluster certificates. The Argo CD routes can now leverage the OpenShift cluster certificates in addition to using external certificate managers such as the cert-manager.
- Use the improved Environments page in the Developer perspective of the console 4.9 to gain insights into the GitOps environments.
-
You can now access custom health checks in Argo CD for
DeploymentConfig
resources,Route
resources, and Operators installed using OLM. The GitOps Operator now conforms to the naming conventions recommended by the latest Operator-SDK:
-
The prefix
gitops-operator-
is added to all resources -
Service account is renamed to
gitops-operator-controller-manager
-
The prefix
5.1.40.2. Fixed issues
The following issues were resolved in the current release:
- Previously, if you set up a new namespace to be managed by a new instance of Argo CD, it would immediately be Out Of Sync due to the new roles and bindings that the Operator creates to manage that new namespace. This behavior is fixed. GITOPS-1384
5.1.40.3. Known issues
While migrating from the Dex authentication provider to the Keycloak provider, you may experience login issues with Keycloak. GITOPS-1450
To prevent the above issue, when migrating, uninstall Dex by removing the
.spec.dex
section found in the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely, and then proceed to install Keycloak by adding.spec.sso.provider: keycloak
to the Argo CD custom resource.As a workaround, uninstall Keycloak by removing
.spec.sso.provider: keycloak
and then re-install.
5.1.41. Release notes for Red Hat OpenShift GitOps 1.2.2
Red Hat OpenShift GitOps 1.2.2 is now available on OpenShift Container Platform 4.8.
5.1.41.1. Fixed issues
The following issue was resolved in the current release:
- All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values to be consumed by Helm charts. This update fixes the CVE-2022-24348 gitops error, path traversal and dereference of symlinks when passing Helm value files. GITOPS-1756
5.1.42. Release notes for Red Hat OpenShift GitOps 1.2.1
Red Hat OpenShift GitOps 1.2.1 is now available on OpenShift Container Platform 4.8.
5.1.42.1. Support matrix
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.
Technology Preview Features Support Scope
In the table below, features are marked with the following statuses:
- TP: Technology Preview
- GA: General Availability
Note the following scope of support on the Red Hat Customer Portal for these features:
Feature | Red Hat OpenShift GitOps 1.2.1 |
---|---|
Argo CD | GA |
Argo CD ApplicationSet | TP |
Red Hat OpenShift GitOps Application Manager CLI ( | TP |
5.1.42.2. Fixed issues
The following issues were resolved in the current release:
-
Previously, huge memory spikes were observed on the application controller on startup. The flag
--kubectl-parallelism-limit
for the application controller is now set to 10 by default, however this value can be overridden by specifying a number for.spec.controller.kubeParallelismLimit
in the Argo CD CR specification. GITOPS-1255 -
The latest Triggers APIs caused Kubernetes build failure due to duplicate entries in the kustomization.yaml when using the
kam bootstrap
command. The Pipelines and Tekton triggers components have now been updated to v0.24.2 and v0.14.2, respectively, to address this issue. GITOPS-1273 - Persisting RBAC roles and bindings are now automatically removed from the target namespace when the Argo CD instance from the source namespace is deleted. GITOPS-1228
- Previously, when deploying an Argo CD instance into a namespace, the Argo CD instance would change the "managed-by" label to be its own namespace. This fix would make namespaces unlabelled while also making sure the required RBAC roles and bindings are created and deleted for the namespace. GITOPS-1247
- Previously, the default resource request limits on Argo CD workloads, specifically for the repo-server and application controller, were found to be very restrictive. The existing resource quota has now been removed and the default memory limit has been increased to 1024M in the repo server. Please note that this change will only affect new installations; existing Argo CD instance workloads will not be affected. GITOPS-1274
5.1.43. Release notes for Red Hat OpenShift GitOps 1.2
Red Hat OpenShift GitOps 1.2 is now available on OpenShift Container Platform 4.8.
5.1.43.1. Support matrix
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.
Technology Preview Features Support Scope
In the table below, features are marked with the following statuses:
- TP: Technology Preview
- GA: General Availability
Note the following scope of support on the Red Hat Customer Portal for these features:
Feature | Red Hat OpenShift GitOps 1.2 |
---|---|
Argo CD | GA |
Argo CD ApplicationSet | TP |
Red Hat OpenShift GitOps Application Manager CLI ( | TP |
5.1.43.2. New features
In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.2:
-
If you do not have read or write access to the openshift-gitops namespace, you can now use the
DISABLE_DEFAULT_ARGOCD_INSTANCE
environment variable in the GitOps Operator and set the value toTRUE
to prevent the default Argo CD instance from starting in theopenshift-gitops
namespace. -
Resource requests and limits are now configured in Argo CD workloads. Resource quota is enabled in the
openshift-gitops
namespace. As a result, out-of-band workloads deployed manually in the openshift-gitops namespace must be configured with resource requests and limits and the resource quota may need to be increased. Argo CD authentication is now integrated with Red Hat SSO and it is automatically configured with OpenShift 4 Identity Provider on the cluster. This feature is disabled by default. To enable Red Hat SSO, add SSO configuration in
ArgoCD
CR as shown below. Currently,keycloak
is the only supported provider.apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak server: route: enabled: true
You can now define hostnames using route labels to support router sharding. Support for setting labels on the
server
(argocd server),grafana
, andprometheus
routes is now available. To set labels on a route, addlabels
under the route configuration for a server in theArgoCD
CR.Example
ArgoCD
CR YAML to set labels on argocd serverapiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true labels: key1: value1 key2: value2
-
The GitOps Operator now automatically grants permissions to Argo CD instances to manage resources in target namespaces by applying labels. Users can label the target namespace with the label
argocd.argoproj.io/managed-by: <source-namespace>
, where thesource-namespace
is the namespace where the argocd instance is deployed.
5.1.43.3. Fixed issues
The following issues were resolved in the current release:
-
Previously, if a user created additional instances of Argo CD managed by the default cluster instance in the openshift-gitops namespace, the application responsible for the new Argo CD instance would get stuck in an
OutOfSync
status. This issue has now been resolved by adding an owner reference to the cluster secret. GITOPS-1025
5.1.43.4. Known issues
These are the known issues in Red Hat OpenShift GitOps 1.2:
-
When an Argo CD instance is deleted from the source namespace, the
argocd.argoproj.io/managed-by
labels in the target namespaces are not removed. GITOPS-1228 Resource quota has been enabled in the openshift-gitops namespace in Red Hat OpenShift GitOps 1.2. This can affect out-of-band workloads deployed manually and workloads deployed by the default Argo CD instance in the
openshift-gitops
namespace. When you upgrade from Red Hat OpenShift GitOpsv1.1.2
tov1.2
such workloads must be configured with resource requests and limits. If there are any additional workloads, the resource quota in the openshift-gitops namespace must be increased.Current Resource Quota for
openshift-gitops
namespace.Resource Requests Limits CPU
6688m
13750m
Memory
4544Mi
9070Mi
You can use the below command to update the CPU limits.
$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'
You can use the below command to update the CPU requests.
$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]
You can replace the path in the above commands from
cpu
tomemory
to update the memory.
5.1.44. Release notes for Red Hat OpenShift GitOps 1.1
Red Hat OpenShift GitOps 1.1 is now available on OpenShift Container Platform 4.7.
5.1.44.1. Support matrix
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.
Technology Preview Features Support Scope
In the table below, features are marked with the following statuses:
- TP: Technology Preview
- GA: General Availability
Note the following scope of support on the Red Hat Customer Portal for these features:
Feature | Red Hat OpenShift GitOps 1.1 |
---|---|
Argo CD | GA |
Argo CD ApplicationSet | TP |
Red Hat OpenShift GitOps Application Manager CLI ( | TP |
5.1.44.2. New features
In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.1:
-
The
ApplicationSet
feature is now added (Technology Preview). TheApplicationSet
feature enables both automation and greater flexibility when managing Argo CD applications across a large number of clusters and within monorepos. It also makes self-service usage possible on multitenant Kubernetes clusters. - Argo CD is now integrated with cluster logging stack and with the OpenShift Container Platform Monitoring and Alerting features.
- Argo CD auth is now integrated with OpenShift Container Platform.
- Argo CD applications controller now supports horizontal scaling.
- Argo CD Redis servers now support high availability (HA).
5.1.44.3. Fixed issues
The following issues were resolved in the current release:
- Previously, Red Hat OpenShift GitOps did not work as expected in a proxy server setup with active global proxy settings. This issue is fixed and now Argo CD is configured by the Red Hat OpenShift GitOps Operator using fully qualified domain names (FQDN) for the pods to enable communication between components. GITOPS-703
-
The Red Hat OpenShift GitOps backend relies on the
?ref=
query parameter in the Red Hat OpenShift GitOps URL to make API calls. Previously, this parameter was not read from the URL, causing the backend to always consider the default reference. This issue is fixed and the Red Hat OpenShift GitOps backend now extracts the reference query parameter from the Red Hat OpenShift GitOps URL and only uses the default reference when there is no input reference provided. GITOPS-817 -
Previously, the Red Hat OpenShift GitOps backend failed to find the valid GitLab repository. This was because the Red Hat OpenShift GitOps backend checked for
main
as the branch reference, instead ofmaster
in the GitLab repository. This issue is fixed now. GITOPS-768 -
The Environments page in the Developer perspective of the OpenShift Container Platform web console now shows the list of applications and the number of environments. This page also displays an Argo CD link that directs you to the Argo CD Applications page that lists all the applications. The Argo CD Applications page has LABELS (for example,
app.kubernetes.io/name=appName
) that help you filter only the applications of your choice. GITOPS-544
5.1.44.4. Known issues
These are the known issues in Red Hat OpenShift GitOps 1.1:
- Red Hat OpenShift GitOps does not support Helm v2 and ksonnet.
- The Red Hat SSO (RH SSO) Operator is not supported in disconnected clusters. As a result, the Red Hat OpenShift GitOps Operator and RH SSO integration is not supported in disconnected clusters.
- When you delete an Argo CD application from the OpenShift Container Platform web console, the Argo CD application gets deleted in the user interface, but the deployments are still present in the cluster. As a workaround, delete the Argo CD application from the Argo CD console. GITOPS-830
5.1.44.5. Breaking Change
5.1.44.5.1. Upgrading from Red Hat OpenShift GitOps v1.0.1
When you upgrade from Red Hat OpenShift GitOps v1.0.1
to v1.1
, the Red Hat OpenShift GitOps Operator renames the default Argo CD instance created in the openshift-gitops
namespace from argocd-cluster
to openshift-gitops
.
This is a breaking change and needs the following steps to be performed manually, before the upgrade:
Go to the OpenShift Container Platform web console and copy the content of the
argocd-cm.yml
config map file in theopenshift-gitops
namespace to a local file. The content may look like the following example:Example argocd config map YAML
kind: ConfigMap apiVersion: v1 metadata: selfLink: /api/v1/namespaces/openshift-gitops/configmaps/argocd-cm resourceVersion: '112532' name: argocd-cm uid: f5226fbc-883d-47db-8b53-b5e363f007af creationTimestamp: '2021-04-16T19:24:08Z' managedFields: ... namespace: openshift-gitops labels: app.kubernetes.io/managed-by: argocd-cluster app.kubernetes.io/name: argocd-cm app.kubernetes.io/part-of: argocd data: "" 1 admin.enabled: 'true' statusbadge.enabled: 'false' resource.exclusions: | - apiGroups: - tekton.dev clusters: - '*' kinds: - TaskRun - PipelineRun ga.trackingid: '' repositories: | - type: git url: https://github.com/user-name/argocd-example-apps ga.anonymizeusers: 'false' help.chatUrl: '' url: >- https://argocd-cluster-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com "" 2 help.chatText: '' kustomize.buildOptions: '' resource.inclusions: '' repository.credentials: '' users.anonymous.enabled: 'false' configManagementPlugins: '' application.instanceLabelKey: ''
-
Delete the default
argocd-cluster
instance. -
Edit the new
argocd-cm.yml
config map file to restore the entiredata
section manually. Replace the URL value in the config map entry with the new instance name
openshift-gitops
. For example, in the preceding example, replace the URL value with the following URL value:url: >- https://openshift-gitops-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com
- Login to the Argo CD cluster and verify that the previous configurations are present.
5.2. Understanding OpenShift GitOps
5.2.1. About GitOps
GitOps is a declarative way to implement continuous deployment for cloud native applications. You can use GitOps to create repeatable processes for managing OpenShift Container Platform clusters and applications across multi-cluster Kubernetes environments. GitOps handles and automates complex deployments at a fast pace, saving time during deployment and release cycles.
The GitOps workflow pushes an application through development, testing, staging, and production. GitOps either deploys a new application or updates an existing one, so you only need to update the repository; GitOps automates everything else.
GitOps is a set of practices that use Git pull requests to manage infrastructure and application configurations. In GitOps, the Git repository is the only source of truth for system and application configuration. This Git repository contains a declarative description of the infrastructure you need in your specified environment and contains an automated process to make your environment match the described state. Also, it contains the entire state of the system so that the trail of changes to the system state are visible and auditable. By using GitOps, you resolve the issues of infrastructure and application configuration sprawl.
GitOps defines infrastructure and application definitions as code. Then, it uses this code to manage multiple workspaces and clusters to simplify the creation of infrastructure and application configurations. By following the principles of the code, you can store the configuration of clusters and applications in Git repositories, and then follow the Git workflow to apply these repositories to your chosen clusters. You can apply the core principles of developing and maintaining software in a Git repository to the creation and management of your cluster and application configuration files.
5.2.2. About Red Hat OpenShift GitOps
Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps organizes the deployment process around the configuration repositories and makes them the central element. It always has at least two repositories:
- Application repository with the source code
- Environment configuration repository that defines the desired state of the application
These repositories contain a declarative description of the infrastructure you need in your specified environment. They also contain an automated process to make your environment match the described state.
Red Hat OpenShift GitOps uses Argo CD to maintain cluster resources. Argo CD is an open-source declarative tool for the continuous integration and continuous deployment (CI/CD) of applications. Red Hat OpenShift GitOps implements Argo CD as a controller so that it continuously monitors application definitions and configurations defined in a Git repository. Then, Argo CD compares the specified state of these configurations with their live state on the cluster.
Argo CD reports any configurations that deviate from their specified state. These reports allow administrators to automatically or manually resync configurations to the defined state. Therefore, Argo CD enables you to deliver global custom resources, like the resources that are used to configure OpenShift Container Platform clusters.
5.2.2.1. Key features
Red Hat OpenShift GitOps helps you automate the following tasks:
- Ensure that the clusters have similar states for configuration, monitoring, and storage
- Apply or revert configuration changes to multiple OpenShift Container Platform clusters
- Associate templated configuration with different environments
- Promote applications across clusters, from staging to production
5.3. Installing Red Hat OpenShift GitOps
Red Hat OpenShift GitOps uses Argo CD to manage specific cluster-scoped resources, including cluster Operators, optional Operator Lifecycle Manager (OLM) Operators, and user management.
This guide explains how to install the Red Hat OpenShift GitOps Operator to an OpenShift Container Platform cluster and log in to the Argo CD instance.
The latest
channel enables installation of the most recent stable version of the Red Hat OpenShift GitOps Operator. Currently, it is the default channel for installing the Red Hat OpenShift GitOps Operator.
To install a specific version of the Red Hat OpenShift GitOps Operator, cluster administrators can use the corresponding gitops-<version>
channel. For example, to install the Red Hat OpenShift GitOps Operator version 1.8.x, you can use the gitops-1.8
channel.
5.3.1. Installing Red Hat OpenShift GitOps Operator in web console
Prerequisites
- Access to the OpenShift Container Platform web console.
-
An account with the
cluster-admin
role. - You are logged in to the OpenShift Container Platform cluster as an administrator.
If you have already installed the Community version of the Argo CD Operator, remove the Argo CD Community Operator before you install the Red Hat OpenShift GitOps Operator.
Procedure
-
Open the Administrator perspective of the web console and navigate to Operators
OperatorHub in the menu on the left. Search for
OpenShift GitOps
, click the Red Hat OpenShift GitOps tile, and then click Install.Red Hat OpenShift GitOps will be installed in all namespaces of the cluster.
After the Red Hat OpenShift GitOps Operator is installed, it automatically sets up a ready-to-use Argo CD instance that is available in the openshift-gitops
namespace, and an Argo CD icon is displayed in the console toolbar. You can create subsequent Argo CD instances for your applications under your projects.
5.3.2. Installing Red Hat OpenShift GitOps Operator using CLI
You can install Red Hat OpenShift GitOps Operator from the OperatorHub using the CLI.
Procedure
Create a Subscription object YAML file to subscribe a namespace to the Red Hat OpenShift GitOps, for example,
sub.yaml
:Example Subscription
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators spec: channel: latest 1 installPlanApproval: Automatic name: openshift-gitops-operator 2 source: redhat-operators 3 sourceNamespace: openshift-marketplace 4
- 1
- Specify the channel name from where you want to subscribe the Operator.
- 2
- Specify the name of the Operator to subscribe to.
- 3
- Specify the name of the CatalogSource that provides the Operator.
- 4
- The namespace of the CatalogSource. Use
openshift-marketplace
for the default OperatorHub CatalogSources.
Apply the
Subscription
to the cluster:$ oc apply -f openshift-gitops-sub.yaml
After the installation is complete, ensure that all the pods in the
openshift-gitops
namespace are running:$ oc get pods -n openshift-gitops
Example output
NAME READY STATUS RESTARTS AGE cluster-b5798d6f9-zr576 1/1 Running 0 65m kam-69866d7c48-8nsjv 1/1 Running 0 65m openshift-gitops-application-controller-0 1/1 Running 0 53m openshift-gitops-applicationset-controller-6447b8dfdd-5ckgh 1/1 Running 0 65m openshift-gitops-redis-74bd8d7d96-49bjf 1/1 Running 0 65m openshift-gitops-repo-server-c999f75d5-l4rsg 1/1 Running 0 65m openshift-gitops-server-5785f7668b-wj57t 1/1 Running 0 53m
5.3.3. Logging in to the Argo CD instance by using the Argo CD admin account
Red Hat OpenShift GitOps Operator automatically creates a ready-to-use Argo CD instance that is available in the openshift-gitops
namespace.
Prerequisites
- You have installed the Red Hat OpenShift GitOps Operator in your cluster.
Procedure
-
In the Administrator perspective of the web console, navigate to Operators
Installed Operators to verify that the Red Hat OpenShift GitOps Operator is installed. -
Navigate to the
menu
OpenShift GitOps Cluster Argo CD. The login page of the Argo CD UI is displayed in a new window. Optional: To log in with your OpenShift Container Platform credentials, ensure you are a user of the
cluster-admins
group and then select theLOG IN VIA OPENSHIFT
option in the Argo CD user interface.NoteTo be a user of the
cluster-admins
group, use theoc adm groups new cluster-admins <user>
command, where<user>
is the default cluster role that you can bind to users and groups cluster-wide or locally.To log in with your username and password, obtain the password for the Argo CD instance:
- In the left panel of the console, use the perspective switcher to switch to the Developer perspective.
-
Use the Project drop-down list and select the
openshift-gitops
project. - Use the left navigation panel to navigate to the Secrets page.
- Select the openshift-gitops-cluster instance to display the password.
- Copy the password.
-
Use this password and
admin
as the username to log in to the Argo CD UI in the new window.
You cannot create two Argo CD CRs in the same namespace.
5.4. Uninstalling OpenShift GitOps
Uninstalling the Red Hat OpenShift GitOps Operator is a two-step process:
- Delete the Argo CD instances that were added under the default namespace of the Red Hat OpenShift GitOps Operator.
- Uninstall the Red Hat OpenShift GitOps Operator.
Uninstalling only the Operator will not remove the Argo CD instances created.
5.4.1. Deleting the Argo CD instances
Delete the Argo CD instances added to the namespace of the GitOps Operator.
Procedure
- In the Terminal type the following command:
$ oc delete gitopsservice cluster -n openshift-gitops
You cannot delete an Argo CD cluster from the web console UI.
After the command runs successfully all the Argo CD instances will be deleted from the openshift-gitops
namespace.
Delete any other Argo CD instances from other namespaces using the same command:
$ oc delete gitopsservice cluster -n <namespace>
5.4.2. Uninstalling the GitOps Operator
Procedure
-
From the Operators
OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift GitOps Operator
tile. - Click the Red Hat OpenShift GitOps Operator tile. The Operator tile indicates it is installed.
- In the Red Hat OpenShift GitOps Operator descriptor page, click Uninstall.
Additional resources
- You can learn more about uninstalling Operators on OpenShift Container Platform in the Deleting Operators from a cluster section.
5.5. Setting up an Argo CD instance
By default, the Red Hat OpenShift GitOps installs an instance of Argo CD in the openshift-gitops
namespace with additional permissions for managing certain cluster-scoped resources. To manage cluster configurations or deploy applications, you can install and deploy a new Argo CD instance. By default, any new instance has permissions to manage resources only in the namespace where it is deployed.
5.5.1. Installing Argo CD
To manage cluster configurations or deploy applications, you can install and deploy a new Argo CD instance.
Procedure
- Log in to the OpenShift Container Platform web console.
-
Click Operators
Installed Operators. - Create or select the project where you want to install the Argo CD instance from the Project drop-down menu.
- Select OpenShift GitOps Operator from the installed operators and select the Argo CD tab.
Click Create to configure the parameters:
- Enter the Name of the instance. By default, the Name is set to argocd.
-
Create an external OS Route to access Argo CD server. Click Server
Route and check Enabled.
-
To open the Argo CD web UI, click the route by navigating to Networking
Routes <instance name>-server in the project where the Argo CD instance is installed.
5.5.2. Enabling replicas for Argo CD server and repo server
Argo CD-server and Argo CD-repo-server workloads are stateless. To better distribute your workloads among pods, you can increase the number of Argo CD-server and Argo CD-repo-server replicas. However, if a horizontal autoscaler is enabled on the Argo CD-server, it overrides the number of replicas you set.
Procedure
Set the
replicas
parameters for therepo
andserver
spec to the number of replicas you want to run:Example Argo CD custom resource
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: repo: replicas: <number_of_replicas> server: replicas: <number_of_replicas> route: enabled: true path: / tls: insecureEdgeTerminationPolicy: Redirect termination: passthrough wildcardPolicy: None
5.5.3. Deploying resources to a different namespace
To allow Argo CD to manage resources in other namespaces apart from where it is installed, configure the target namespace with a argocd.argoproj.io/managed-by
label.
Procedure
Configure the namespace:
$ oc label namespace <namespace> \ argocd.argoproj.io/managed-by=<instance_name> 1
- 1
- The namespace where Argo CD is installed.
5.5.4. Customizing the Argo CD console link
In a multi-tenant cluster, users might have to deal with multiple instances of Argo CD. For example, after installing an Argo CD instance in your namespace, you might find a different Argo CD instance attached to the Argo CD console link, instead of your own Argo CD instance, in the Console Application Launcher.
You can customize the Argo CD console link by setting the DISABLE_DEFAULT_ARGOCD_CONSOLELINK
environment variable:
-
When you set
DISABLE_DEFAULT_ARGOCD_CONSOLELINK
totrue
, the Argo CD console link is permanently deleted. -
When you set
DISABLE_DEFAULT_ARGOCD_CONSOLELINK
tofalse
or use the default value, the Argo CD console link is temporarily deleted and visible again when the Argo CD route is reconciled.
Prerequisites
- You have logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed the Red Hat OpenShift GitOps Operator.
Procedure
-
In the Administrator perspective, navigate to Administration
CustomResourceDefinitions. - Find the Subscription CRD and click to open it.
- Select the Instances tab and click the openshift-gitops-operator subscription.
Select the YAML tab and make your customization:
To enable or disable the Argo CD console link, edit the value of
DISABLE_DEFAULT_ARGOCD_CONSOLELINK
as needed:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator spec: config: env: - name: DISABLE_DEFAULT_ARGOCD_CONSOLELINK value: 'true'
5.6. Monitoring Argo CD instances
By default, the Red Hat OpenShift GitOps Operator automatically detects an installed Argo CD instance in your defined namespace, for example, openshift-gitops
, and connects it to the monitoring stack of the cluster to provide alerts for out-of-sync applications.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have access to the OpenShift Container Platform web console.
- You have installed the Red Hat OpenShift GitOps Operator in your cluster.
-
You have installed an Argo CD application in your defined namespace, for example,
openshift-gitops
.
5.6.1. Monitoring Argo CD health using Prometheus metrics
You can monitor the health status of an Argo CD application by running Prometheus metrics queries against it.
Procedure
-
In the Developer perspective of the web console, select the namespace where your Argo CD application is installed, and navigate to Observe
Metrics. - From the Select query drop-down list, select Custom query.
To check the health status of your Argo CD application, enter the Prometheus Query Language (PromQL) query similar to the following example in the Expression field:
Example
sum(argocd_app_info{dest_namespace=~"<your_defined_namespace>",health_status!=""}) by (health_status) 1
- 1
- Replace the
<your_defined_namespace>
variable with the actual name of your defined namespace, for exampleopenshift-gitops
.
5.7. Configuring an OpenShift cluster by deploying an application with cluster configurations
With Red Hat OpenShift GitOps, you can configure Argo CD to recursively sync the content of a Git directory with an application that contains custom configurations for your cluster.
Prerequisites
- You have logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed the Red Hat OpenShift GitOps Operator in your cluster.
- You have logged into Argo CD instance.
5.7.1. Using an Argo CD instance to manage cluster-scoped resources
To manage cluster-scoped resources, update the existing Subscription
object for the Red Hat OpenShift GitOps Operator and add the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES
environment variable in the spec
section.
Procedure
-
In the Administrator perspective of the web console, navigate to Operators
Installed Operators Red Hat OpenShift GitOps Subscription. - Click the Actions drop-down menu then click Edit Subscription.
On the openshift-gitops-operator Subscription details page, under the YAML tab, edit the
Subscription
YAML file by adding the namespace of the Argo CD instance to theARGOCD_CLUSTER_CONFIG_NAMESPACES
environment variable in thespec
section: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> ...
To verify that the Argo instance is configured with a cluster role to manage cluster-scoped resources, perform the following steps:
-
Navigate to User Management
Roles and from the Filter drop-down menu select Cluster-wide Roles. Search for the
argocd-application-controller
by using the Search by name field.The Roles page displays the created cluster role.
TipAlternatively, in the OpenShift CLI, run the following command:
oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller
The output
yes
verifies that the Argo instance is configured with a cluster role to manage cluster-scoped resources. Else, check your configurations and take necessary steps as required.
-
Navigate to User Management
5.7.2. Default permissions of an Argocd instance
By default Argo CD instance has the following permissions:
-
Argo CD instance has the
admin
privileges to manage resources only in the namespace where it is deployed. For instance, an Argo CD instance deployed in the foo namespace has theadmin
privileges to manage resources only for that namespace. Argo CD has the following cluster-scoped permissions because Argo CD requires cluster-wide
read
privileges on resources to function appropriately:- verbs: - get - list - watch apiGroups: - '*' resources: - '*' - verbs: - get - list nonResourceURLs: - '*'
You can edit the cluster roles used by the
argocd-server
andargocd-application-controller
components where Argo CD is running such that thewrite
privileges are limited to only the namespaces and resources that you wish Argo CD to manage.$ oc edit clusterrole argocd-server $ oc edit clusterrole argocd-application-controller
5.7.3. Running the Argo CD instance at the cluster-level
The default Argo CD instance and the accompanying controllers, installed by the Red Hat OpenShift GitOps Operator, can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle.
Procedure
Label the existing nodes:
$ oc label node <node-name> node-role.kubernetes.io/infra=""
Optional: If required, you can also apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes:
$ oc adm taint nodes -l node-role.kubernetes.io/infra \ infra=reserved:NoSchedule infra=reserved:NoExecute
Add the
runOnInfra
toggle in theGitOpsService
custom resource:apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true
Optional: If taints have been added to the nodes, then add
tolerations
to theGitOpsService
custom resource, for example:spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved
-
Verify that the workloads in the
openshift-gitops
namespace are now scheduled on the infrastructure nodes by viewing PodsPod details for any pod in the console UI.
Any nodeSelectors
and tolerations
manually added to the default Argo CD custom resource are overwritten by the toggle and tolerations
in the GitOpsService
custom resource.
Additional resources
- To learn more about taints and tolerations, see Controlling pod placement using node taints.
- For more information on infrastructure machine sets, see Creating infrastructure machine sets.
5.7.4. Creating an application by using the Argo CD dashboard
Argo CD provides a dashboard which allows you to create applications.
This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster
directory to the cluster-configs
application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the
menu in the web console, and defines a namespace spring-petclinic
on the cluster.
Procedure
- In the Argo CD dashboard, click NEW APP to add a new Argo CD application.
For this workflow, create a cluster-configs application with the following configurations:
- Application Name
-
cluster-configs
- Project
-
default
- Sync Policy
-
Manual
- Repository URL
-
https://github.com/redhat-developer/openshift-gitops-getting-started
- Revision
-
HEAD
- Path
-
cluster
- Destination
-
https://kubernetes.default.svc
- Namespace
-
spring-petclinic
- Directory Recurse
-
checked
- Click CREATE to create your application.
-
Open the Administrator perspective of the web console and navigate to Administration
Namespaces in the menu on the left. -
Search for and select the namespace, then enter
argocd.argoproj.io/managed-by=openshift-gitops
in the Label field so that the Argo CD instance in theopenshift-gitops
namespace can manage your namespace.
5.7.5. Creating an application by using the oc
tool
You can create Argo CD applications in your terminal by using the oc
tool.
Procedure
Download the sample application:
$ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
Create the application:
$ oc create -f openshift-gitops-getting-started/argo/app.yaml
Run the
oc get
command to review the created application:$ oc get application -n openshift-gitops
Add a label to the namespace your application is deployed in so that the Argo CD instance in the
openshift-gitops
namespace can manage it:$ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
5.7.6. Synchronizing your application with your Git repository
Procedure
- In the Argo CD dashboard, notice that the cluster-configs Argo CD application has the statuses Missing and OutOfSync. Because the application was configured with a manual sync policy, Argo CD does not sync it automatically.
- Click SYNC on the cluster-configs tile, review the changes, and then click SYNCHRONIZE. Argo CD will detect any changes in the Git repository automatically. If the configurations are changed, Argo CD will change the status of the cluster-configs to OutOfSync. You can modify the synchronization policy for Argo CD to automatically apply changes from your Git repository to the cluster.
- Notice that the cluster-configs Argo CD application now has the statuses Healthy and Synced. Click the cluster-configs tile to check the details of the synchronized resources and their status on the cluster.
- Navigate to the OpenShift Container Platform web console and click to verify that a link to the Red Hat Developer Blog - Kubernetes is now present there.
Navigate to the Project page and search for the
spring-petclinic
namespace to verify that it has been added to the cluster.Your cluster configurations have been successfully synchronized to the cluster.
5.7.7. In-built permissions for cluster configuration
By default, the Argo CD instance has permissions to manage specific cluster-scoped resources such as cluster Operators, optional OLM Operators and user management.
Argo CD does not have cluster-admin permissions.
Permissions for the Argo CD instance:
Resources | Descriptions |
Resource Groups | Configure the user or administrator |
| Optional Operators managed by OLM |
| Groups, Users and their permissions |
| Control plane Operators managed by CVO used to configure cluster-wide build configuration, registry configuration and scheduler policies |
| Storage |
| Console customization |
5.7.8. Adding permissions for cluster configuration
You can grant permissions for an Argo CD instance to manage cluster configuration. Create a cluster role with additional permissions and then create a new cluster role binding to associate the cluster role with a service account.
Procedure
- Log in to the OpenShift Container Platform web console as an admin.
In the web console, select User Management
Roles Create Role. Use the following ClusterRole
YAML template to add rules to specify the additional permissions.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secrets-cluster-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["*"]
- Click Create to add the cluster role.
-
Now create the cluster role binding. In the web console, select User Management
Role Bindings Create Binding. - Select All Projects from the Project drop-down.
- Click Create binding.
- Select Binding type as Cluster-wide role binding (ClusterRoleBinding).
- Enter a unique value for the RoleBinding name.
- Select the newly created cluster role or an existing cluster role from the drop down list.
Select the Subject as ServiceAccount and the provide the Subject namespace and name.
-
Subject namespace:
openshift-gitops
-
Subject name:
openshift-gitops-argocd-application-controller
-
Subject namespace:
Click Create. The YAML file for the
ClusterRoleBinding
object is as follows: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. Installing OLM Operators using Red Hat OpenShift GitOps
Red Hat OpenShift GitOps with cluster configurations manages specific cluster-scoped resources and takes care of installing cluster Operators or any namespace-scoped OLM Operators.
Consider a case where as a cluster administrator, you have to install an OLM Operator such as Tekton. You use the OpenShift Container Platform web console to manually install a Tekton Operator or the OpenShift CLI to manually install a Tekton subscription and Tekton Operator group on your cluster.
Red Hat OpenShift GitOps places your Kubernetes resources in your Git repository. As a cluster administrator, use Red Hat OpenShift GitOps to manage and automate the installation of other OLM Operators without any manual procedures. For example, after you place the Tekton subscription in your Git repository by using Red Hat OpenShift GitOps, the Red Hat OpenShift GitOps automatically takes this Tekton subscription from your Git repository and installs the Tekton Operator on your cluster.
5.7.9.1. Installing cluster-scoped Operators
Operator Lifecycle Manager (OLM) uses a default global-operators
Operator group in the openshift-operators
namespace for cluster-scoped Operators. Hence you do not have to manage the OperatorGroup
resource in your Gitops repository. However, for namespace-scoped Operators, you must manage the OperatorGroup
resource in that namespace.
To install cluster-scoped Operators, create and place the Subscription
resource of the required Operator in your Git repository.
Example: Grafana Operator subscription
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. Installing namepace-scoped Operators
To install namespace-scoped Operators, create and place the Subscription
and OperatorGroup
resources of the required Operator in your Git repository.
Example: Ansible Automation Platform Resource Operator
... 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 ...
When deploying multiple Operators using Red Hat OpenShift GitOps, you must create only a single Operator group in the corresponding namespace. If more than one Operator group exists in a single namespace, any CSV created in that namespace transition to a failure
state with the TooManyOperatorGroups
reason. After the number of Operator groups in their corresponding namespaces reaches one, all the previous failure
state CSVs transition to pending
state. You must manually approve the pending install plan to complete the Operator installation.
5.8. Deploying a Spring Boot application with Argo CD
With Argo CD, you can deploy your applications to the OpenShift cluster either by using the Argo CD dashboard or by using the oc
tool.
Prerequisites
- Red Hat OpenShift GitOps is installed in your cluster.
- Logged into Argo CD instance.
5.8.1. Creating an application by using the Argo CD dashboard
Argo CD provides a dashboard which allows you to create applications.
This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster
directory to the cluster-configs
application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the
menu in the web console, and defines a namespace spring-petclinic
on the cluster.
Procedure
- In the Argo CD dashboard, click NEW APP to add a new Argo CD application.
For this workflow, create a cluster-configs application with the following configurations:
- Application Name
-
cluster-configs
- Project
-
default
- Sync Policy
-
Manual
- Repository URL
-
https://github.com/redhat-developer/openshift-gitops-getting-started
- Revision
-
HEAD
- Path
-
cluster
- Destination
-
https://kubernetes.default.svc
- Namespace
-
spring-petclinic
- Directory Recurse
-
checked
For this workflow, create a spring-petclinic application with the following configurations:
- Application Name
-
spring-petclinic
- Project
-
default
- Sync Policy
-
Automatic
- Repository URL
-
https://github.com/redhat-developer/openshift-gitops-getting-started
- Revision
-
HEAD
- Path
-
app
- Destination
-
https://kubernetes.default.svc
- Namespace
-
spring-petclinic
- Click CREATE to create your application.
-
Open the Administrator perspective of the web console and navigate to Administration
Namespaces in the menu on the left. -
Search for and select the namespace, then enter
argocd.argoproj.io/managed-by=openshift-gitops
in the Label field so that the Argo CD instance in theopenshift-gitops
namespace can manage your namespace.
5.8.2. Creating an application by using the oc
tool
You can create Argo CD applications in your terminal by using the oc
tool.
Procedure
Download the sample application:
$ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
Create the application:
$ oc create -f openshift-gitops-getting-started/argo/app.yaml
$ oc create -f openshift-gitops-getting-started/argo/app.yaml
Run the
oc get
command to review the created application:$ oc get application -n openshift-gitops
Add a label to the namespace your application is deployed in so that the Argo CD instance in the
openshift-gitops
namespace can manage it:$ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
$ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
5.8.3. Verifying Argo CD self-healing behavior
Argo CD constantly monitors the state of deployed applications, detects differences between the specified manifests in Git and live changes in the cluster, and then automatically corrects them. This behavior is referred to as self-healing.
You can test and observe the self-healing behavior in Argo CD.
Prerequisites
-
The sample
app-spring-petclinic
application is deployed and configured.
Procedure
-
In the Argo CD dashboard, verify that your application has the
Synced
status. -
Click the
app-spring-petclinic
tile in the Argo CD dashboard to view the application resources that are deployed to the cluster. - In the OpenShift Container Platform web console, navigate to the Developer perspective.
Modify the Spring PetClinic deployment and commit the changes to the
app/
directory of the Git repository. Argo CD will automatically deploy the changes to the cluster.- Fork the OpenShift GitOps getting started repository.
-
In the
deployment.yaml
file, change thefailureThreshold
value to5
. In the deployment cluster, run the following command to verify the changed value of the
failureThreshold
field:$ oc edit deployment spring-petclinic -n spring-petclinic
Test the self-healing behavior by modifying the deployment on the cluster and scaling it up to two pods while watching the application in the OpenShift Container Platform web console.
Run the following command to modify the deployment:
$ oc scale deployment spring-petclinic --replicas 2 -n spring-petclinic
- In the OpenShift Container Platform web console, notice that the deployment scales up to two pods and immediately scales down again to one pod. Argo CD detected a difference from the Git repository and auto-healed the application on the OpenShift Container Platform cluster.
-
In the Argo CD dashboard, click the app-spring-petclinic tile
APP DETAILS EVENTS. The EVENTS tab displays the following events: Argo CD detecting out of sync deployment resources on the cluster and then resyncing the Git repository to correct it.
5.9. Argo CD Operator
The ArgoCD
custom resource is a Kubernetes Custom Resource (CRD) that describes the desired state for a given Argo CD cluster that allows you to configure the components which make up an Argo CD cluster.
5.9.1. Argo CD CLI tool
The Argo CD CLI tool is a tool used to configure Argo CD through the command line. Red Hat OpenShift GitOps does not support this binary. Use the OpenShift Console to configure the Argo CD.
5.9.2. Argo CD custom resource properties
The Argo CD Custom Resource consists of the following properties:
Name | Description | Default | Properties |
|
The |
| |
|
|
|
|
| Add a configuration management plugin. |
| |
| Argo CD Application Controller options. |
|
|
| Disables the built-in admin user. |
| |
| Use a Google Analytics tracking ID. |
| |
| Enable hashed usernames sent to google analytics. |
| |
| High availablity options. |
|
|
| URL for getting chat help (this will typically be 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 |
| |
| Ingress configuration options. |
| |
| Initial Git repositories to configure Argo CD to use upon creation of the cluster. |
| |
| Notifications controller configuration options. |
|
|
| Git repository credential templates to configure Argo CD to use upon creation of the cluster. |
| |
| Initial SSH Known Hosts for Argo CD to use upon creation of the cluster. |
| |
|
The build options and parameters to use with |
| |
| The OIDC configuration as an alternative to Dex. |
| |
|
Add the |
| |
| Prometheus configuration options. |
|
|
| RBAC configuration options. |
|
|
| Redis configuration options. |
|
|
| Customize resource behavior. |
| |
| Completely ignore entire classes of resource group. |
| |
| The configuration to configure which resource group/kinds are applied. |
| |
| Argo CD Server configuration options. |
|
|
| Single Sign-on options. |
|
|
| Enable application status badge. |
| |
| TLS configuration options. |
|
|
| Enable anonymous user access. |
| |
| The tag to use with the container image for all Argo CD components. | Latest Argo CD version | |
| Add a UI banner message. |
|
|
5.9.3. Repo server properties
The following properties are available for configuring the Repo server component:
Name | Default | Description |
|
| The container compute resources. |
|
|
Whether the |
|
|
The name of the |
|
| Whether to enforce strict TLS checking on all components when communicating with repo server. |
|
| Provider to use for setting up TLS the repo-server’s gRPC TLS certificate (one of: openshift). Currently only available for OpenShift. |
|
|
The container image for Argo CD Repo server. This overrides the |
|
same as | The tag to use with the Argo CD Repo server. |
|
| The log level used by the Argo CD Repo server. Valid options are debug, info, error, and warn. |
|
| The log format to be used by the Argo CD Repo server. Valid options are text or json. |
|
| Execution timeout in seconds for rendering tools (e.g. Helm, Kustomize). |
|
| Environment to set for the repository server workloads. |
|
|
The number of replicas for the Argo CD Repo server. Must be greater than or equal to |
5.9.4. Enabling notifications with Argo CD instance
To enable or disable the Argo CD notifications controller, set a parameter in the Argo CD custom resource. By default, notifications are disabled. To enable notifications, set the enabled
parameter to true
in the .yaml
file:
Procedure
-
Set the
enabled
parameter totrue
:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd spec: notifications: enabled: true
5.10. Configuring secure communication with Redis
Using the Transport Layer Security (TLS) encryption with Red Hat OpenShift GitOps, you can secure the communication between the Argo CD components and Redis cache and protect the possibly sensitive data in transit.
You can secure communication with Redis by using one of the following configurations:
-
Enable the
autotls
setting to issue an appropriate certificate for TLS encryption. -
Manually configure the TLS encryption by creating the
argocd-operator-redis-tls
secret with a key and certificate pair.
Both configurations are possible with or without the High Availability (HA) enabled.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have access to the OpenShift Container Platform web console.
- Red Hat OpenShift GitOps Operator is installed on your cluster.
5.10.1. Configuring TLS for Redis with autotls enabled
You can configure TLS encryption for Redis by enabling the autotls
setting on a new or already existing Argo CD instance. The configuration automatically provisions the argocd-operator-redis-tls
secret and does not require further steps. Currently, OpenShift Container Platform is the only supported secret provider.
By default, the autotls
setting is disabled.
Procedure
- Log in to the OpenShift Container Platform web console.
Create an Argo CD instance with
autotls
enabled:-
In the Administrator perspective of the web console, use the left navigation panel to go to Administration
CustomResourceDefinitions. -
Search for
argocds.argoproj.io
and clickArgoCD
custom resource definition (CRD). - On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.
Edit or replace the YAML similar to the following example:
Example Argo CD CR with autotls enabled
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: redis: autotls: openshift 3 ha: enabled: true 4
- 1
- The name of the Argo CD instance.
- 2
- The namespace where you want to run the Argo CD instance.
- 3
- The flag that enables the
autotls
setting and creates a TLS certificate for Redis. - 4
- The flag value that enables the HA feature. If you do not want to enable HA, do not include this line or set the flag value as
false
.
TipAlternatively, you can enable the
autotls
setting on an already existing Argo CD instance by running the following command:$ oc patch argocds.argoproj.io <instance-name> --type=merge -p '{"spec":{"redis":{"autotls":"openshift"}}}'
- Click Create.
Verify that the Argo CD pods are ready and running:
$ oc get pods -n <namespace> 1
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output with HA disabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NoteThe HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.
Example output with HA enabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
-
In the Administrator perspective of the web console, use the left navigation panel to go to Administration
Verify that the
argocd-operator-redis-tls
secret is created:$ oc get secrets argocd-operator-redis-tls -n <namespace> 1
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output
NAME TYPE DATA AGE argocd-operator-redis-tls kubernetes.io/tls 2 30s
The secret must be of the
kubernetes.io/tls
type and a size of2
.
5.10.2. Configuring TLS for Redis with autotls disabled
You can manually configure TLS encryption for Redis by creating the argocd-operator-redis-tls
secret with a key and certificate pair. In addition, you must annotate the secret to indicate that it belongs to the appropriate Argo CD instance. The steps to create a certificate and secret vary for instances with High Availability (HA) enabled.
Procedure
- Log in to the OpenShift Container Platform web console.
Create an Argo CD instance:
-
In the Administrator perspective of the web console, use the left navigation panel to go to Administration
CustomResourceDefinitions. -
Search for
argocds.argoproj.io
and clickArgoCD
custom resource definition (CRD). - On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.
Edit or replace the YAML similar to the following example:
Example ArgoCD CR with autotls disabled
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: argocd 1 namespace: openshift-gitops 2 spec: ha: enabled: true 3
- Click Create.
Verify that the Argo CD pods are ready and running:
$ oc get pods -n <namespace> 1
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output with HA disabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NoteThe HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.
Example output with HA enabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
-
In the Administrator perspective of the web console, use the left navigation panel to go to Administration
Create a self-signed certificate for the Redis server by using one of the following options depending on your HA configuration:
For the Argo CD instance with HA disabled, run the following command:
$ openssl req -new -x509 -sha256 \ -subj "/C=XX/ST=XX/O=Testing/CN=redis" \ -reqexts SAN -extensions SAN \ -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis.key \ -out /tmp/redis.crt \ -newkey rsa:4096 \ -nodes \ -sha256 \ -days 10
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output
Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis.key'
For the Argo CD instance with HA enabled, run the following command:
$ openssl req -new -x509 -sha256 \ -subj "/C=XX/ST=XX/O=Testing/CN=redis" \ -reqexts SAN -extensions SAN \ -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis-ha-haproxy.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1 -keyout /tmp/redis-ha.key \ -out /tmp/redis-ha.crt \ -newkey rsa:4096 \ -nodes \ -sha256 \ -days 10
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output
Generating a RSA private key ...............++++ ............................++++ writing new private key to '/tmp/redis-ha.key'
Verify that the generated certificate and key are available in the
/tmp
directory by running the following commands:$ cd /tmp
$ ls
Example output with HA disabled
... redis.crt redis.key ...
Example output with HA enabled
... redis-ha.crt redis-ha.key ...
Create the
argocd-operator-redis-tls
secret by using one of the following options depending on your HA configuration:For the Argo CD instance with HA disabled, run the following command:
$ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis.key --cert=/tmp/redis.crt
For the Argo CD instance with HA enabled, run the following command:
$ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis-ha.key --cert=/tmp/redis-ha.crt
Example output
secret/argocd-operator-redis-tls created
Annotate the secret to indicate that it belongs to the Argo CD CR:
$ oc annotate secret argocd-operator-redis-tls argocds.argoproj.io/name=<instance-name> 1
- 1
- Specify a name of the Argo CD instance, for example
argocd
.
Example output
secret/argocd-operator-redis-tls annotated
Verify that the Argo CD pods are ready and running:
$ oc get pods -n <namespace> 1
- 1
- Specify a namespace where the Argo CD instance is running, for example
openshift-gitops
.
Example output with HA disabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 26s argocd-redis-84b77d4f58-vp6zm 1/1 Running 0 37s argocd-repo-server-5b959b57f4-znxjq 1/1 Running 0 37s argocd-server-6b8787d686-wv9zh 1/1 Running 0 37s
NoteIt can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.
Example output with HA enabled
NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 10m argocd-redis-ha-haproxy-669757fdb7-5xg8h 1/1 Running 0 10m argocd-redis-ha-server-0 2/2 Running 0 9m9s argocd-redis-ha-server-1 2/2 Running 0 98s argocd-redis-ha-server-2 2/2 Running 0 53s argocd-repo-server-576499d46d-8hgbh 1/1 Running 0 10m argocd-server-9486f88b7-dk2ks 1/1 Running 0 10m
5.11. Monitoring health information for application resources and deployments
The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console shows a list of the successful deployments of the application environments, along with links to the revision for each deployment.
The Application environments page in the Developer perspective of the OpenShift Container Platform web console displays the health status of the application resources, such as routes, synchronization status, deployment configuration, and deployment history.
The environments pages in the Developer perspective of the OpenShift Container Platform web console are decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI), kam
. You do not have to use kam
to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed.
5.11.1. Settings for environment labels and annotations
This section provides reference settings for environment labels and annotations required to display an environment application in the Environments page, in the Developer perspective of the OpenShift Container Platform web console.
Environment labels
The environment application manifest must contain labels.openshift.gitops/environment
and destination.namespace
fields. You must set identical values for the <environment_name>
variable and the name of the environment application manifest.
Specification of the environment application manifest
spec: labels: openshift.gitops/environment: <environment_name> destination: namespace: <environment_name> ...
Example of an environment application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: dev-env 1
namespace: openshift-gitops
spec:
labels:
openshift.gitops/environment: dev-env
destination:
namespace: dev-env
...
- 1
- The name of the environment application manifest. The value set is the same as the value of the
<environment_name>
variable.
Environment annotations
The environment namespace manifest must contain the annotations.app.openshift.io/vcs-uri
and annotations.app.openshift.io/vcs-ref
fields to specify the version controller code source of the application. You must set identical values for the <environment_name>
variable and the name of the environment namespace manifest.
Specification of the environment namespace manifest
apiVersion: v1
kind: Namespace
metadata:
annotations:
app.openshift.io/vcs-uri: <application_source_url>
app.openshift.io/vcs-ref: <branch_reference>
name: <environment_name> 1
...
- 1
- The name of the environment namespace manifest. The value set is the same as the value of the
<environment_name>
variable.
Example of an environment namespace manifest
apiVersion: v1 kind: Namespace metadata: annotations: app.openshift.io/vcs-uri: https://example.com/<your_domain>/<your_gitops.git> app.openshift.io/vcs-ref: main labels: argocd.argoproj.io/managed-by: openshift-gitops name: dev-env ...
5.11.2. Checking health information
The Red Hat OpenShift GitOps Operator will install the GitOps backend service in the openshift-gitops
namespace.
Prerequisites
- The Red Hat OpenShift GitOps Operator is installed from OperatorHub.
- Ensure that your applications are synchronized by Argo CD.
Procedure
- Click Environments under the Developer perspective. The Environments page shows the list of applications along with their Environment status.
- Hover over the icons under the Environment status column to see the synchronization status of all the environments.
- Click on the application name from the list to view the details of a specific application.
In the Application environments page, if the Resources section under the Overview tab displays icons, hover over the icons to get status details.
- A broken heart indicates that resource issues have degraded the application’s performance.
- A yellow yield sign indicates that resource issues have delayed data about the application’s health.
5.12. Configuring SSO for Argo CD using Dex
After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin
permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO).
The spec.dex
parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using the spec.dex
parameter in the ArgoCD CR is planned to be removed. Consider using the .spec.sso
parameter instead.
5.12.1. Enabling the Dex OpenShift OAuth Connector
Dex uses the users and groups defined within OpenShift by checking the OAuth
server provided by the platform. The following example shows the properties of Dex along with example configurations:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: openshift-oauth spec: dex: openShiftOAuth: true 1 groups:2 - default rbac:3 defaultPolicy: 'role:readonly' policy: | g, cluster-admins, role:admin scopes: '[groups]'
- 1
- The
openShiftOAuth
property triggers the Operator to automatically configure the built-in OpenShiftOAuth
server when the value is set totrue
. - 2
- The
groups
property allows users of the specified group(s) to log in. - 3
- The RBAC policy property assigns the admin role in the Argo CD cluster to users in the OpenShift
cluster-admins
group.
5.12.1.1. Mapping users to specific roles
Argo CD cannot map users to specific roles if they have a direct ClusterRoleBinding
role. You can manually change the role as role:admin
on SSO through OpenShift.
Procedure
Create a group named
cluster-admins
.$ oc adm groups new cluster-admins
Add the user to the group.
$ oc adm groups add-users cluster-admins USER
Apply the
cluster-admin
ClusterRole
to the group:$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
5.12.2. Disabling Dex
Dex is installed by default for all the Argo CD instances created by the Operator. You can configure Red Hat OpenShift GitOps to use Dex as the SSO authentication provider by setting the .spec.dex
parameter.
In Red Hat OpenShift GitOps v1.6.0, DISABLE_DEX
is deprecated and is planned to be removed in Red Hat OpenShift GitOps v1.9.0. Consider using the .spec.sso.dex
parameter instead. See "Enabling or disabling Dex using .spec.sso".
Procedure
Set the environmental variable
DISABLE_DEX
totrue
in the YAML resource of the Operator:... spec: config: env: - name: DISABLE_DEX value: "true" ...
5.12.3. Enabling or disabling Dex using .spec.sso
You can configure Red Hat OpenShift GitOps to use Dex as its SSO authentication provider by setting the .spec.sso
parameter.
Procedure
To enable Dex, set the
.spec.sso.provider: dex
parameter in the YAML resource of the Operator:... spec: sso: provider: dex dex: openShiftOAuth: true ...
-
To disable dex, either remove the
spec.sso
element from the Argo CD custom resource, or specify a different SSO provider.
5.13. Configuring SSO for Argo CD using Keycloak
After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin
permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO).
Prerequisites
- Red Hat SSO is installed on the cluster.
- Red Hat OpenShift GitOps Operator is installed on the cluster.
- Argo CD is installed on the cluster.
5.13.1. Configuring a new client in Keycloak
Dex is installed by default for all the Argo CD instances created by the Operator. However, you can delete the Dex configuration and add Keycloak instead to log in to Argo CD using your OpenShift credentials. Keycloak acts as an identity broker between Argo CD and OpenShift.
Procedure
To configure Keycloak, follow these steps:
Delete the Dex configuration by removing the
.spec.sso.dex
parameter from the Argo CD custom resource (CR), and save the CR:dex: openShiftOAuth: true resources: limits: cpu: memory: requests: cpu: memory:
-
Set the value of the
provider
parameter tokeycloak
in the Argo CD CR. Configure Keycloak by performing one of the following steps:
For a secure connection, set the value of the
rootCA
parameter as shown in the following example:apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: sso: provider: keycloak keycloak: rootCA: "<PEM-encoded-root-certificate>" 1 server: route: enabled: true
- 1
- A custom certificate used to verify the Keycloak’s TLS certificate.
The Operator reconciles changes in the
.spec.keycloak.rootCA
parameter and updates theoidc.config
parameter with the PEM encoded root certificate in theargocd-cm
configuration map.For an insecure connection, leave the value of the
rootCA
parameter empty and use theoidc.tls.insecure.skip.verify
parameter as shown below:apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: extraConfig: oidc.tls.insecure.skip.verify: "true" sso: provider: keycloak keycloak: rootCA: ""
The Keycloak instance takes 2-3 minutes to install and run.
5.13.2. Logging in to Keycloak
Log in to the Keycloak console to manage identities or roles and define the permissions assigned to the various roles.
Prerequisites
- The default configuration of Dex is removed.
- Your Argo CD CR must be configured to use the Keycloak SSO provider.
Procedure
Get the Keycloak route URL for login:
$ oc -n argocd get route keycloak NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD keycloak keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com keycloak <all> reencrypt None
Get the Keycloak pod name that stores the user name and password as environment variables:
$ oc -n argocd get pods NAME READY STATUS RESTARTS AGE keycloak-1-2sjcl 1/1 Running 0 45m
Get the Keycloak user name:
$ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME SSO_ADMIN_USERNAME=<username>
Get the Keycloak password:
$ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD SSO_ADMIN_PASSWORD=<password>
On the login page, click LOG IN VIA KEYCLOAK.
NoteYou only see the option LOGIN VIA KEYCLOAK after the Keycloak instance is ready.
Click Login with OpenShift.
NoteLogin using
kubeadmin
is not supported.- Enter the OpenShift credentials to log in.
Optional: By default, any user logged in to Argo CD has read-only access. You can manage the user level access by updating the
argocd-rbac-cm
config map:policy.csv: <name>, <email>, role:admin
5.13.3. Uninstalling Keycloak
You can delete the Keycloak resources and their relevant configurations by removing the SSO
field from the Argo CD Custom Resource (CR) file. After you remove the SSO
field, the values in the file look similar to the following:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: basic spec: server: route: enabled: true
A Keycloak application created by using this method is currently not persistent. Additional configurations created in the Argo CD Keycloak realm are deleted when the server restarts.
5.14. Configuring Argo CD RBAC
By default, if you are logged into Argo CD using RHSSO, you are a read-only user. You can change and manage the user level access.
5.14.1. Configuring user level access
To manage and modify the user level access, configure the RBAC section in Argo CD custom resource.
Procedure
Edit the
argocd
Custom Resource:$ oc edit argocd [argocd-instance-name] -n [namespace]
Output
metadata ... ... rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]'
Add the
policy
configuration to therbac
section and add thename
,email
and therole
of the user:metadata ... ... rbac: policy: <name>, <email>, role:<admin> scopes: '[groups]'
Currently, RHSSO cannot read the group information of Red Hat OpenShift GitOps users. Therefore, configure the RBAC at the user level.
5.14.2. Modifying RHSSO resource requests/limits
By default, the RHSSO container is created with resource requests and limitations. You can change and manage the resource requests.
Resource | Requests | Limits |
---|---|---|
CPU | 500 | 1000m |
Memory | 512 Mi | 1024 Mi |
Procedure
Modify the default resource requirements patching the Argo CD CR:
$ oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
RHSSO created by the Red Hat OpenShift GitOps only persists the changes that are made by the operator. If the RHSSO restarts, any additional configuration created by the Admin in RHSSO is deleted.
5.15. Configuring resource quota or requests
With the Argo CD Custom Resource, you can create, update, and delete resource requests and limits for Argo CD workloads.
5.15.1. Configuring workloads with resource requests and limits
You can create Argo CD custom resource workloads with resource requests and limits. This is required when you want to deploy the Argo CD instance in a namespace that is configured with resource quotas.
The following Argo CD instance deploys the Argo CD workloads such as Application Controller
, ApplicationSet Controller
, Dex
, Redis
,Repo Server
, and Server
with resource requests and limits. You can also create the other workloads with resource requirements in the same manner.
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example spec: server: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 125m memory: 128Mi route: enabled: true applicationSet: resources: limits: cpu: '2' memory: 1Gi requests: cpu: 250m memory: 512Mi repo: resources: limits: cpu: '1' memory: 512Mi requests: cpu: 250m memory: 256Mi dex: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi redis: resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi controller: resources: limits: cpu: '2' memory: 2Gi requests: cpu: 250m memory: 1Gi
5.15.2. Patching Argo CD instance to update the resource requirements
You can update the resource requirements for all or any of the workloads post installation.
Procedure
Update the Application Controller
resource requests of an Argo CD instance in the Argo CD namespace.
oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/cpu", "value":"1"}]' oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/memory", "value":"512Mi"}]'
5.15.3. Removing resource requests
You can also remove resource requirements for all or any of your workloads after installation.
Procedure
Remove the Application Controller
resource requests of an Argo CD instance in the Argo CD namespace.
oc -n argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/cpu"}]' oc -n argocd argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/memory"}]'
5.16. Monitoring Argo CD custom resource workloads
With Red Hat OpenShift GitOps, you can monitor the availability of Argo CD custom resource workloads for specific Argo CD instances. By monitoring Argo CD custom resource workloads, you have the latest information about the state of your Argo CD instances by enabling alerts for them. When the component workload pods such as application-controller, repo-server, or server of the corresponding Argo CD instance are unable to come up for certain reasons and there is a drift between the number of ready replicas and the number of desired replicas for a certain period of time, the Operator then triggers the alerts.
You can enable and disable the setting for monitoring Argo CD custom resource workloads.
Prerequisites
-
You have access to the cluster as a user with the
cluster-admin
role. - Red Hat OpenShift GitOps is installed in your cluster.
-
The monitoring stack is configured in your cluster in the
openshift-monitoring
project. In addition, the Argo CD instance is in a namespace that you can monitor through Prometheus. -
The
kube-state-metrics
service is running in your cluster. Optional: If you are enabling monitoring for an Argo CD instance already present in a user-defined project, ensure that the monitoring is enabled for user-defined projects in your cluster.
NoteIf you want to enable monitoring for an Argo CD instance in a namespace that is not watched by the default
openshift-monitoring
stack, for example, any namespace that does not start withopenshift-*
, then you must enable user workload monitoring in your cluster. This action enables the monitoring stack to pick up the created PrometheusRule.
5.16.1. Enabling Monitoring for Argo CD custom resource workloads
By default, the monitoring configuration for Argo CD custom resource workloads is set to false
.
With Red Hat OpenShift GitOps, you can enable workload monitoring for specific Argo CD instances. As a result, the Operator creates a PrometheusRule
object that contains alert rules for all the workloads managed by the specific Argo CD instances. These alert rules trigger the firing of an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to the PrometheusRule
object by the users.
Procedure
Set the
.spec.monitoring.enabled
field value totrue
on a given Argo CD instance:Example Argo CD custom resource
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: ... monitoring: enabled: true ...
Verify whether an alert rule is included in the PrometheusRule created by the Operator:
Example alert rule
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: argocd-component-status-alert namespace: openshift-gitops spec: groups: - name: ArgoCDComponentStatus rules: ... - alert: ApplicationSetControllerNotReady 1 annotations: message: >- applicationSet controller deployment for Argo CD instance in namespace "default" is not running expr: >- kube_statefulset_status_replicas{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} != kube_statefulset_status_replicas_ready{statefulset="openshift-gitops-application-controller statefulset", namespace="openshift-gitops"} for: 1m labels: severity: critical
- 1
- Alert rule in the PrometheusRule that checks whether the workloads created by the Argo CD instances are running as expected.
5.16.2. Disabling Monitoring for Argo CD custom resource workloads
You can disable workload monitoring for specific Argo CD instances. Disabling workload monitoring deletes the created PrometheusRule.
Procedure
Set the
.spec.monitoring.enabled
field value tofalse
on a given Argo CD instance:Example Argo CD custom resource
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: example-argocd labels: example: repo spec: ... monitoring: enabled: false ...
5.16.3. Additional resources
5.17. Viewing Argo CD logs
You can view the Argo CD logs with the logging subsystem for Red Hat OpenShift. The logging subsystem visualizes the logs on a Kibana dashboard. The OpenShift Logging Operator enables logging with Argo CD by default.
5.17.1. Storing and retrieving Argo CD logs
You can use the Kibana dashboard to store and retrieve Argo CD logs.
Prerequisites
- The Red Hat OpenShift GitOps Operator is installed in your cluster.
- The logging subsystem for Red Hat OpenShift is installed with default configuration in your cluster.
Procedure
-
In the OpenShift Container Platform web console, go to the
menu
Observability Logging to view the Kibana dashboard. Create an index pattern.
-
To display all the indices, define the index pattern as
*
, and click Next step. - Select @timestamp for Time Filter field name.
- Click Create index pattern.
-
To display all the indices, define the index pattern as
- In the navigation panel of the Kibana dashboard, click the Discover tab.
Create a filter to retrieve logs for Argo CD. The following steps create a filter that retrieves logs for all the pods in the
openshift-gitops
namespace:- Click Add a filter +.
- Select the kubernetes.namespace_name field.
- Select the is operator.
- Select the openshift-gitops value.
- Click Save.
-
Optional: Add additional filters to narrow the search. For example, to retrieve logs for a particular pod, you can create another filter with
kubernetes.pod_name
as the field. - View the filtered Argo CD logs in the Kibana dashboard.
5.17.2. Additional resources
5.18. Running GitOps control plane workloads on infrastructure nodes
You can use infrastructure nodes to prevent additional billing cost against subscription counts.
You can use the OpenShift Container Platform to run certain workloads on infrastructure nodes installed by the Red Hat OpenShift GitOps Operator. This comprises the workloads that are installed by the Red Hat OpenShift GitOps Operator by default in the openshift-gitops
namespace, including the default Argo CD instance in that namespace.
Any other Argo CD instances installed to user namespaces are not eligible to run on infrastructure nodes.
5.18.1. Moving GitOps workloads to infrastructure nodes
You can move the default workloads installed by the Red Hat OpenShift GitOps to the infrastructure nodes. The workloads that can be moved are:
-
kam deployment
-
cluster deployment
(backend service) -
openshift-gitops-applicationset-controller deployment
-
openshift-gitops-dex-server deployment
-
openshift-gitops-redis deployment
-
openshift-gitops-redis-ha-haproxy deployment
-
openshift-gitops-repo-sever deployment
-
openshift-gitops-server deployment
-
openshift-gitops-application-controller statefulset
-
openshift-gitops-redis-server statefulset
Procedure
Label existing nodes as infrastructure by running the following command:
$ oc label node <node-name> node-role.kubernetes.io/infra=
Edit the
GitOpsService
custom resource (CR) to add the infrastructure node selector:$ oc edit gitopsservice -n openshift-gitops
In the
GitOpsService
CR file, addrunOnInfra
field to thespec
section and set it totrue
. This field moves the workloads inopenshift-gitops
namespace to the infrastructure nodes:apiVersion: pipelines.openshift.io/v1alpha1 kind: GitopsService metadata: name: cluster spec: runOnInfra: true
Optional: Apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes.
$ oc adm taint nodes -l node-role.kubernetes.io/infra infra=reserved:NoSchedule infra=reserved:NoExecute
Optional: If you apply taints to the nodes, you can add tolerations in the
GitOpsService
CR:spec: runOnInfra: true tolerations: - effect: NoSchedule key: infra value: reserved - effect: NoExecute key: infra value: reserved
To verify that the workloads are scheduled on infrastructure nodes in the Red Hat OpenShift GitOps namespace, click any of the pod names and ensure that the Node selector and Tolerations have been added.
Any manually added Node selectors and Tolerations in the default Argo CD CR will be overwritten by the toggle and the tolerations in the GitOpsService
CR.
5.18.2. Additional resources
- To learn more about taints and tolerations, see Controlling pod placement using node taints.
- For more information on infrastructure machine sets, see Creating infrastructure machine sets.
5.19. Sizing requirements for GitOps Operator
The sizing requirements page displays the sizing requirements for installing Red Hat OpenShift GitOps on OpenShift Container Platform. It also provides the sizing details for the default ArgoCD instance that is instantiated by the GitOps Operator.
5.19.1. Sizing requirements for GitOps
Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud-native applications. Through GitOps, you can define and configure the CPU and memory requirements of your application.
Every time you install the Red Hat OpenShift GitOps Operator, the resources on the namespace are installed within the defined limits. If the default installation does not set any limits or requests, the Operator fails within the namespace with quotas. Without enough resources, the cluster cannot schedule ArgoCD related pods. The following table details the resource requests and limits for the default workloads:
Workload | CPU requests | CPU limits | Memory requests | Memory limits |
---|---|---|---|---|
argocd-application-controller | 1 | 2 | 1024M | 2048M |
applicationset-controller | 1 | 2 | 512M | 1024M |
argocd-server | 0.125 | 0.5 | 128M | 256M |
argocd-repo-server | 0.5 | 1 | 256M | 1024M |
argocd-redis | 0.25 | 0.5 | 128M | 256M |
argocd-dex | 0.25 | 0.5 | 128M | 256M |
HAProxy | 0.25 | 0.5 | 128M | 256M |
Optionally, you can also use the ArgoCD custom resource with the oc
command to see the specifics and modify them:
oc edit argocd <name of argo cd> -n namespace
5.20. Troubleshooting issues in Red Hat OpenShift GitOps
When working with Red Hat OpenShift GitOps, you might face issues related to performance, monitoring, configuration, and other aspects. This section helps you to understand those issues and provide solutions to resolve them.
5.20.1. Issue: Auto-reboot during Argo CD sync with machine configurations
In the Red Hat OpenShift Container Platform, nodes are updated automatically through the Red Hat OpenShift Machine Config Operator (MCO). A Machine Config Operator (MCO) is a custom resource that is used by the cluster to manage the complete life cycle of its nodes.
When an MCO resource is created or updated in a cluster, the MCO picks up the update, performs the necessary changes to the selected nodes, and restarts the nodes gracefully by cordoning, draining, and rebooting those nodes. It handles everything from the kernel to the kubelet.
However, interactions between the MCO and the GitOps workflow can introduce major performance issues and other undesired behaviors. This section shows how to make the MCO and the Argo CD GitOps orchestration tool work well together.
5.20.1.1. Solution: Enhance performance in machine configurations and Argo CD
When you are using a Machine Config Operator as part of a GitOps workflow, the following sequence can produce suboptimal performance:
- Argo CD starts an automated sync job after a commit to the Git repository that contains application resources.
- If Argo CD notices a new or an updated machine configuration while the sync operation is in process, MCO picks up the change to the machine configuration and starts rebooting the nodes to apply the change.
- If a rebooting node in the cluster contains the Argo CD application controller, the application controller terminates, and the application sync is aborted.
As the MCO reboots the nodes in sequential order, and the Argo CD workloads can be rescheduled on each reboot, it can take some time for the sync to be completed. This results in an undefined behavior until the MCO has rebooted all nodes affected by the machine configurations within the sync.