Argo CD applications
Creating and deploying applications on the OpenShift cluster by using the Argo CD dashboard, oc tool, or GitOps CLI
Abstract
Chapter 1. Deploying a Spring Boot application with Argo CD Copy linkLink copied to clipboard!
With Argo CD, you can deploy your applications to the OpenShift Container Platform cluster either by using the Argo CD dashboard or by using the oc tool.
1.1. Creating an application by using the Argo CD dashboard Copy linkLink copied to clipboard!
Argo CD provides a dashboard which allows you to create applications.
Prerequisites
- You have logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
- You have logged in to an Argo CD instance.
Procedure
- In the Argo CD dashboard, click NEW APP to add a new Argo CD application.
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 expand Administration → Namespaces.
-
Search for and select the
spring-petclinicnamespace, then enterargocd.argoproj.io/managed-by=openshift-gitopsin the Label field so that the Argo CD instance in theopenshift-gitopsnamespace can manage your namespace.
1.2. Creating an application by using the oc tool Copy linkLink copied to clipboard!
You can create Argo CD applications in your terminal by using the oc tool.
Prerequisites
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
- You have logged in to an Argo CD instance.
-
You have access to the
ocCLI tool.
Procedure
Download the sample application:
$ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.gitCreate the application:
$ oc create -f openshift-gitops-getting-started/argo/app.yamlRun the
oc getcommand to review the created application:$ oc get application -n openshift-gitopsAdd a label to the namespace your application is deployed in so that the Argo CD instance in the
openshift-gitopsnamespace can manage it:$ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
1.3. Verifying Argo CD self-healing behavior Copy linkLink copied to clipboard!
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
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
- You have logged in to an Argo CD instance.
-
The sample
spring-petclinicapplication is deployed and configured.
Procedure
-
In the Argo CD dashboard, verify that your application has the
Syncedstatus. -
Click the
spring-petclinictile 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.
Fork the OpenShift GitOps getting started repository.
-
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. -
In the
deployment.yamlfile, change thefailureThresholdvalue to5. - Commit and push the changes.
In the OpenShift Container Platform cluster, run the following command to verify the changed value of the
failureThresholdfield:$ oc edit deployment spring-petclinic -n spring-petclinic
-
Modify the Spring PetClinic deployment and commit the changes to the
Test the self-healing behavior by scaling the deployment up to two pods and observing Argo CD automatically scale it back down.
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 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.
Chapter 2. Creating an application by using the GitOps CLI Copy linkLink copied to clipboard!
With Argo CD, you can create your applications on an OpenShift Container Platform cluster by using the GitOps argocd CLI.
2.1. Creating an application in the default mode by using the GitOps CLI Copy linkLink copied to clipboard!
You can create applications in the default mode by using the GitOps argocd CLI.
Prerequisites
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
-
You have installed the OpenShift CLI (
oc). -
You have installed the Red Hat OpenShift GitOps
argocdCLI. - You have logged in to an Argo CD instance.
Procedure
Get the
adminaccount password for the Argo CD server:$ ADMIN_PASSWD=$(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d)Get the Argo CD server URL:
$ SERVER_URL=$(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}')Log in to the Argo CD server by using the
adminaccount password:ImportantEnclosing the password in single quotes ensures that special characters, such as
$, are not misinterpreted by the shell. Always use single quotes to enclose the literal value of the password.$ argocd login --username admin --password ${ADMIN_PASSWD} ${SERVER_URL}Example:
$ argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testingVerify that you are able to run
argocdcommands in the default mode by listing all applications:$ argocd app listIf the configuration is correct, then existing applications will be listed with the following header:
Sample output:
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGETCreate an application in the default mode:
$ argocd app create app-spring-petclinic \ --repo https://github.com/redhat-developer/openshift-gitops-getting-started.git \ --path app \ --revision main \ --dest-server https://kubernetes.default.svc \ --dest-namespace spring-petclinic \ --directory-recurse \ --sync-policy automated \ --self-heal \ --sync-option Prune=true \ --sync-option CreateNamespace=trueLabel the
spring-petclinicdestination namespace to be managed by theopenshift-gitopsArgo CD instance:$ oc label ns spring-petclinic "argocd.argoproj.io/managed-by=openshift-gitops"List the available applications to confirm that the application is created successfully and repeat the command until the application has the
HealthyandSyncedstatuses:$ argocd app list
2.2. Creating an application in core mode by using the GitOps CLI Copy linkLink copied to clipboard!
You can create applications in core mode by using the GitOps argocd CLI.
Prerequisites
- You have installed the Red Hat OpenShift GitOps Operator on your OpenShift Container Platform cluster.
-
You have installed the OpenShift CLI (
oc). -
You have installed the Red Hat OpenShift GitOps
argocdCLI.
Procedure
Log in to the OpenShift Container Platform cluster by using the
ocCLI tool:$ oc login -u <username> -p <password> <server_url>Example:
$ oc login -u kubeadmin -p '<password>' https://api.crc.testing:6443Check whether the context is set correctly in the
kubeconfigfile:$ oc config current-contextSet the default namespace of the current context to
openshift-gitops:$ oc config set-context --current --namespace openshift-gitopsSet the following environment variable to override the Argo CD component names:
$ export ARGOCD_REPO_SERVER_NAME=openshift-gitops-repo-serverVerify that you are able to run
argocdcommands incoremode by listing all applications:$ argocd app list --coreIf the configuration is correct, then existing applications will be listed with the following header:
Sample output:
NAME CLUSTER NAMESPACE PROJECT STATUS HEALTH SYNCPOLICY CONDITIONS REPO PATH TARGETCreate an application in
coremode:$ argocd app create app-spring-petclinic --core \ --repo https://github.com/redhat-developer/openshift-gitops-getting-started.git \ --path app \ --revision main \ --dest-server https://kubernetes.default.svc \ --dest-namespace spring-petclinic \ --directory-recurse \ --sync-policy automated \ --self-heal \ --sync-option Prune=true \ --sync-option CreateNamespace=trueLabel the
spring-petclinicdestination namespace to be managed by theopenshift-gitopsArgo CD instance:$ oc label ns spring-petclinic "argocd.argoproj.io/managed-by=openshift-gitops"List the available applications to confirm that the application is created successfully and repeat the command until the application has the
HealthyandSyncedstatuses:$ argocd app list --core
Chapter 3. Managing the application resources in non-control plane namespaces Copy linkLink copied to clipboard!
As a cluster administrator, you can create and manage the Application resources in non-control plane namespaces declaratively other than the openshift-gitops control plane namespace. This functionality is called the Applications in any namespace feature in the Argo CD open source project.
As a developer, if you are creating Argo CD applications in non-control plane namespaces other than the openshift-gitops control plane namespace, ensure that your cluster administrator grants the necessary permissions to them.
Otherwise, after the Argo CD reconciliation, you will see an error message similar to the following example:
Example error message:
error while validating and normalizing app: error getting application's project: application 'app' in namespace 'dev' is not allowed to use project 'default'
To use this functionality, you must explicitly enable and configure the target namespaces in the following objects:
-
The
ArgoCDcustom resource (CR) of your user-defined cluster-scoped Argo CD instance -
The
AppProjectcustom resource (CR) -
The
ApplicationCR
The process of creating and managing the Application resources in non-control plane namespaces consists of the following procedures:
-
Configuring the
ArgoCDCR of your user-defined cluster-scoped Argo CD instance with the target namespaces. -
Creating and configuring a user-defined
AppProjectinstance in theopenshift-gitopscontrol plane namespace and specify the target namespaces in the.spec.sourceNamespacesfield of the user-definedAppProjectinstance. -
Configuring the
metadata.namespaceand.spec.projectfields of theApplicationCR to reference the target namespaces and user-definedAppProjectinstance.
This functionality is useful in multitenancy environments when you want to manage deployments of Argo CD applications for your isolated teams.
To prevent privilege escalations for your application teams, you must meet the following requirements:
-
Do not configure non-control plane namespaces in the
.spec.sourceNamespacesfield of any privilegedAppProjectinstance, for example, thedefaultinstance of yourAppProjectCR installed in either theopenshift-gitopscontrol plane namespace or your defined namespace. -
Do not grant access to the
openshift-gitopscontrol plane namespace within theAppProjectCRD. -
Always create and configure user-defined
AppProjectinstances in theopenshift-gitopscontrol plane namespace, and then configure non-control plane namespaces in the.spec.sourceNamespacesfield within the corresponding user-definedAppProjectinstance.
3.1. Prerequisites Copy linkLink copied to clipboard!
- You have installed Red Hat OpenShift GitOps 1.13.0 or a later version on your OpenShift Container Platform cluster.
-
You have a user-defined cluster-scoped Argo CD instance in your defined namespace, for example,
spring-petclinicnamespace.
3.2. Configuring the Argo CD CR of your user-defined cluster-scoped Argo CD instance with the target namespaces Copy linkLink copied to clipboard!
As a cluster administrator, you can define a certain set of non-control plane namespaces in which users can create, update, and reconcile Application resources. You must first explicitly configure the target namespaces in the ArgoCD custom resource (CR) of your user-defined cluster-scoped Argo CD instance per your requirements.
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed Red Hat OpenShift GitOps 1.13.0 or a later version on your OpenShift Container Platform cluster.
-
You have a user-defined cluster-scoped Argo CD instance in your defined namespace, for example,
spring-petclinicnamespace.
Procedure
- In the Administrator perspective of the web console, click Operators → Installed Operators.
- From the Project list, select the project where the user-defined cluster-scoped Argo CD instance is installed.
- Select Red Hat OpenShift GitOps from the installed Operators list and go to the Argo CD tab.
- Click your user-defined cluster-scoped Argo CD instance.
Configure the
ArgoCDCR of your user-defined cluster-scoped Argo CD instance with the target namespaces:-
Click the YAML tab and edit the YAML file of the
ArgoCDCR. In the
ArgoCDCR, set the value of thesourceNamespacesparameter to include the non-control plane namespaces:Example
ArgoCDCR:apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: example namespace: spring-petclinic spec: sourceNamespaces: - dev - app-team-*where:
metadata.name- Specifies the name of the user-defined cluster-scoped Argo CD instance.
metadata.namespace- Specifies the namespace where the user-defined cluster-scoped Argo CD instance is created.
spec.sourceNamespaces-
Specifies the namespaces where users can create and manage
Applicationresources handled by the Argo CD instance. You can use wildcard patterns (*), to allow the Argo CD instance to manageApplicationresources in matching namespaces likeapp-team-1orapp-team-2.
Click Save and Reload.
NoteWhen a target namespace is specified under the
sourceNamespacesfield, the Operator adds theargocd.argoproj.io/managed-by-cluster-argocdlabel to the specified namespace.Example
devtarget namespace:apiVersion: v1 kind: Namespace metadata: name: dev labels: argocd.argoproj.io/managed-by-cluster-argocd: spring-petclinic kubernetes.io/metadata.name: devwhere:
metadata.name- Specifies the name of the namespace.
argocd.argoproj.io/managed-by-cluster-argocd-
Specifies the Argo CD instance (
spring-petclinic) that owns and manages this namespace.
-
Click the YAML tab and edit the YAML file of the
Verify that Operator adds the
argocd.argoproj.io/managed-by-cluster-argocdlabel to the specified namespace:- Go to Administration → Namespaces and click Create Namespace.
In the Create Namespace dialog box, provide the Name and click Create.
For example, to create
devtarget namespace, enterdevin the Name field. You can repeat the previous steps to create theapp-team-1andapp-team-2target namespaces.The Namespaces page displays the created target namespaces.
-
Click the target namespace and go to the YAML tab to verify the
argocd.argoproj.io/managed-by-cluster-argocdlabel added by the Operator.
Verification
When you create a cluster-scoped Argo CD instance, the GitOps Operator automatically creates the required RBAC resources. Verify that these resources exist to ensure that the Argo CD instance can manage cluster-scoped and namespace-scoped resources.
Verify that your user-defined cluster-scoped Argo CD instance is configured with a cluster role to manage cluster-scoped resources:
- Go to User Management → Roles and from the Filter list, select Cluster-wide Roles.
Search for the created cluster roles by using the Search by name field. For example,
example-spring-petclinic-argocd-application-controllerandexample-spring-petclinic-argocd-server.The Roles page displays the created cluster roles.
Verify that the following role-based access control (RBAC) resources are created by the GitOps Operator:
Expand Name Kind Purpose <argocd_name>-<argocd_namespace>-argocd-application-controllerClusterRoleandClusterRoleBindingFor the Argo CD Application Controller to watch and list
Applicationresources at cluster-level<argocd_name>-<argocd_namespace>-argocd-serverClusterRoleandClusterRoleBindingFor the Argo CD Server to watch and list
Applicationresources at cluster-level<argocd_name>-<target_namespace>RoleandRoleBindingFor the Argo CD server to manage
Applicationresources in target namespace through the UI, API, or CLI
3.3. Creating and configuring a user-defined AppProject instance with the target namespaces Copy linkLink copied to clipboard!
As a cluster administrator, you can define a certain set of non-control plane namespaces in which users can create, update, and reconcile Application resources. After you configure your user-defined cluster-scoped Argo CD instance with target namespaces, you must create and configure a user-defined AppProject instance in the openshift-gitops control plane namespace. In addition, you must explicitly configure the target namespaces in the .spec.sourceNamespaces field of the user-defined AppProject instance.
Applications in the GitOps control plane namespace (openshift-gitops) are allowed to set their .spec.project field to reference any AppProject instance, regardless of the restrictions placed by the .spec.sourceNamespaces field in the AppProject custom resource (CR).
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed Red Hat OpenShift GitOps 1.13.0 or a later version on your OpenShift Container Platform cluster.
Procedure
Create and configure a user-defined
AppProjectinstance in theopenshift-gitopscontrol plane namespace to specify the target namespaces in the.spec.sourceNamespacesfield:-
From the Project list, select the
openshift-gitopsproject. - In the Administrator perspective of the web console, click Operators → Installed Operators → Red Hat OpenShift GitOps and go to the AppProject tab.
Click Create AppProject and enter the following configuration in the YAML view:
Example user-defined
AppProjectinstance:kind: AppProject apiVersion: argoproj.io/v1alpha1 metadata: name: project-one namespace: openshift-gitops spec: sourceNamespaces: - dev - app-team-* destinations: - name: '*' namespace: '*' server: '*' sourceRepos: - '*'where:
metadata.name-
Specifies the name of the user-defined
AppProjectinstance. metadata.namespace-
Specifies the control plane namespace where you want to run the user-defined
AppProjectinstance. spec.sourceNamespaces-
Specifies the list of non-control plane namespaces for creating and managing
Applicationresources. spec.destinations-
Specifies the clusters and namespaces where applications within this
AppProjectcan deploy resources. Using wildcard values allows deployments to any cluster, server, or namespace. spec.sourceRepos-
Specifies the Git repositories from which applications within this
AppProjectcan pull manifests. Using a wildcard allows any repository.
Click Create.
The AppProjects page displays the created user-defined
AppProjectinstance.
-
From the Project list, select the
3.4. Creating and configuring the Application CR to reference the target namespace and user-defined AppProject instance Copy linkLink copied to clipboard!
As a cluster administrator, you can define a certain set of non-control plane namespaces in which users can create, update, and reconcile Application resources. After you configure the target namespaces in the .spec.sourceNamespaces field of the user-defined AppProject instance, you must explicitly create and configure the Application custom resource (CR) with the parameters for the metadata.namespace and .spec.project fields to reference the target namespace and user-defined AppProject instance.
Prerequisites
- You are logged in to the OpenShift Container Platform cluster as an administrator.
- You have installed Red Hat OpenShift GitOps 1.13.0 or a later version on your OpenShift Container Platform cluster.
Procedure
Create and configure the
ApplicationCR with the parameters for themetadata.namespaceand.spec.projectfields to reference the target namespace and user-definedAppProjectinstance:- From the Project list, select the target namespace.
- In the Administrator perspective of the web console, click Operators → Installed Operators → Red Hat OpenShift GitOps and go to the Application tab.
Click Create Application and enter the following configuration in the YAML view:
Example Application CR:
kind: Application apiVersion: argoproj.io/v1alpha1 metadata: name: cluster-configs namespace: dev spec: project: project-one # ...where:
metadata.name- Specifies the name of the application.
metadata.namespace- Specifies the target namespace where the Application CR is created.
spec.project- Specifies the name of the AppProject that this application belongs to.
Click Create.
The Applications page displays the created application.
The
cluster-configsArgo CD application now has the statuses Healthy and Synced.
Chapter 4. Managing application links with the managed-by-url annotation Copy linkLink copied to clipboard!
Use the argocd.argoproj.io/managed-by-url annotation to specify which Argo CD instance manages an Application resource. This configuration ensures that application links in the user interface resolve to the correct instance in multi-instance environments.
4.1. Overview of the managed-by-url annotation Copy linkLink copied to clipboard!
The argocd.argoproj.io/managed-by-url annotation allows an Application resource to specify which Argo CD instance manages it. This annotation ensures application links in the user interface point to the correct managing instance.
When you use multiple Argo CD instances with the app-of-apps pattern:
- A primary Argo CD instance creates a parent Application.
- The parent Application deploys child Applications that a secondary Argo CD instance manages.
- Without the annotation, clicking on child Applications in the primary instance’s user interface attempts to open them in the primary instance, which is incorrect.
- With the annotation, child Applications correctly open in the secondary instance.
The managed-by-url annotation ensures application links redirect to the correct Argo CD instance.
This annotation is particularly useful in multitenant setups where different teams have their own Argo CD instances, or in hub-and-spoke architectures where a central instance manages multiple edge instances.
4.2. Configuring the managed-by-url annotation Copy linkLink copied to clipboard!
You can configure the argocd.argoproj.io/managed-by-url annotation to direct application links to the correct Argo CD instance in multi-instance environments.
Prerequisites
- You have access to multiple Argo CD instances.
- You are using a GitOps workflow with Application resources.
- You have permissions to create and modify Application manifests.
Procedure
Create a parent Application in the primary Argo CD instance:
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: parent-app namespace: argocd spec: project: default source: repoURL: https://github.com/YOUR-ORG/my-apps-repo.git targetRevision: main path: path-to-child-app destination: server: https://kubernetes.default.svc namespace: namespace-b syncPolicy: automated: selfHeal: true prune: trueThe parent Application deploys child Applications from the specified repository.
Add the
managed-by-urlannotation to the child Application definition in your Git repository. Replacehttps://secondary-argocd.example.comwith the actual URL of your secondary Argo CD instance:apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: child-app namespace: namespace-b annotations: argocd.argoproj.io/managed-by-url: "https://secondary-argocd.example.com" spec: project: default source: repoURL: https://github.com/YOUR-ORG/my-apps-repo.git targetRevision: main path: path-to-child-app destination: server: https://kubernetes.default.svc namespace: namespace-b syncPolicy: automated: selfHeal: true prune: trueThe annotation defines the Argo CD instance that manages the child Application.
- Apply or sync the parent Application.
Verification
- Log in to the primary Argo CD instance.
-
Navigate to the
parent-appApplication. -
Select the
child-appresource from the resource tree. - Verify that the link opens in the correct Argo CD instance at the URL specified in the annotation.
4.3. Managed-by-url annotation reference Copy linkLink copied to clipboard!
The argocd.argoproj.io/managed-by-url annotation specifies the Argo CD instance URL that manages an Application resource.
| Field | Value |
|---|---|
| Annotation |
|
| Target | Application |
| Value | Valid HTTP(S) URL |
| Required | No |
The annotation value must be a valid HTTP or HTTPS URL.
The following are the examples of valid annotation values:
The following are the examples of invalid annotation values:
-
argocd.example.com- Missing protocol -
javascript:alert(1)- Invalid protocol
Invalid values prevent Argo CD from creating or updating the Application.
Argo CD determines application links as follows:
- Without the annotation, Argo CD uses the current instance URL.
- With the annotation, Argo CD uses the specified URL.
- With an invalid value, Argo CD falls back to the current instance and logs a warning.
Ensure that the specified URL is accessible from user browsers. Configure DNS or network access as required for internal deployments.
4.4. Troubleshooting the managed-by-url annotation Copy linkLink copied to clipboard!
Use the following guidelines to troubleshoot issues with the argocd.argoproj.io/managed-by-url annotation.
If links point to the wrong instance, check if the annotation is present:
$ kubectl get application <child-app-name> -n <namespace> \
-o jsonpath='{.metadata.annotations.argocd\.argoproj\.io/managed-by-url}'
where:
<child-app-name>- Specifies the name of the child Argo CD Application whose annotation you want to retrieve.
<namespace>- Specifies the namespace in which the child Application resource exists.
Expected output:
http://localhost:8081
The output displays a complete URL such as http://localhost:8081 or your configured URL such as https://secondary-argocd.example.com.
If the annotation is present but links do not work:
- Verify that the URL is reachable from your browser.
- Check the browser console for errors.
-
Ensure that the URL includes the correct protocol (
http://orhttps://).
If Application creation fails with an "invalid managed-by URL" error, verify the following:
-
Verify that the URL includes a protocol (
https://orhttp://). - Check for typos in the URL.
- Ensure the URL uses only valid characters.
-
Avoid unsupported schemes such as
javascript:.
If nested Applications are not working in app-of-apps patterns, ensure the following:
- The child Application YAML in Git includes the annotation.
- The parent Application synced successfully.
- The child Application exists in the cluster.
Verify that the child Application exists:
$ kubectl get application <child-app-name> -n <namespace>
where:
<child-app-name>- Specifies the name of the child Application resource to verify.
<namespace>- Specifies the namespace where the child Application is expected to exist.
If the child Application does not exist, check the parent Application sync status and logs.
Chapter 5. Working with the GitOps Console plugin Copy linkLink copied to clipboard!
GitOps Console plugin 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.
The GitOps Console plugin extends the OpenShift Container Platform web console by adding GitOps resources. The plugin is available as part of the Red Hat OpenShift GitOps Operator and provides a console UI for managing Argo CD and Argo Rollouts custom resources.
After you install the Red Hat OpenShift GitOps Operator and enable the GitOps Console plugin, the Red Hat OpenShift GitOps web console displays a GitOps navigation tab in the Administrator perspective. The GitOps navigation tab replaces the previous Environments tab and related pages in the Developer perspective.
The GitOps navigation tab provides access to the following Argo CD and Argo Rollouts resources:
- Applications
- ApplicationSets
- AppProjects
- Rollouts
5.1. Prerequisites Copy linkLink copied to clipboard!
- You have access to OpenShift Container Platform 4.19 or later.
- You have installed the Red Hat OpenShift GitOps Operator.
5.2. GitOps resources in the web console Copy linkLink copied to clipboard!
Each GitOps resource provides list and details pages that follow the standard Red Hat OpenShift GitOps web console experience.
You can use these pages to:
- View GitOps resources in a selected namespace
- Create resources by using YAML templates
- Edit labels and annotations
- Filter resources by status, where applicable
- Access related resources and events
The GitOps Console plugin integrates with the console navigation, allowing you to navigate between related resources and access contextual actions for each resource type.
5.2.1. Search and YAML templates Copy linkLink copied to clipboard!
The GitOps Console plugin provides search and template capabilities:
- Search integration: Search pages are enabled for Applications and ApplicationSets, allowing you to find instances from global search like other first-class resources.
- YAML templates: Pre-configured YAML templates are registered for Applications, ApplicationSets, AppProjects, and Rollouts. These templates provide starter configurations with placeholders to speed up resource creation from the console.
5.3. Enable the GitOps Console plugin Copy linkLink copied to clipboard!
If you disable the GitOps Console plugin after installing the Red Hat OpenShift GitOps Operator, you can enable it manually.
Prerequisites
- You have installed the Red Hat OpenShift GitOps Operator.
- You have access to the Red Hat OpenShift GitOps web console with cluster administrator permissions.
Procedure
- In the Red Hat OpenShift GitOps web console, navigate to Home → Overview.
In the Status panel, click Dynamic Plugins.
A popup appears with a link to view all dynamic plugins.
- Click View all.
- Under the Console plugins tab, find gitops-plugin.
If the plugin is disabled, click Enable.
The browser might require a refresh. After refreshing, the page indicates that the plugin is Enabled.
Verification
- Navigate to GitOps in the navigation menu and verify that you can access Applications, ApplicationSets, AppProjects, and Rollouts pages.
5.3.1. Applications in the GitOps Console Copy linkLink copied to clipboard!
The GitOps Console Plugin shows key details of an Argo CD Application. You can view and create Application directly from the OpenShift Container Platform web console. A new Graphical view in the Resources tab of the Details page shows the application’s resources in a tree structure.
The GitOps Console plugin displays the health status stored in the Application custom resource (CR). By default, this behavior depends on the configuration set by the Operator. If the Application CR does not contain the health status or the GitOps Console plugin does not display it correctly, set controller.resource.health.persist: "true" in the argocd-cmd-params-cm config map.
List page
The Applications list page displays all Applications with the following features:
- Table columns: name, namespace, sync status, health, revision, AppProject, and actions
- Filtering: Filter Applications by health status (Healthy, Progressing, Degraded, Missing) and sync status (Synced, OutOfSync, Unknown)
- Sorting and search: Sort columns and search by name
- Create action: Click Create Application to open the YAML editor with a starter template that includes repository URL, destination, and sync policy placeholders
-
Technology Preview badge: The feature is labeled as Technology Preview when viewed from user namespaces. When accessed from the GitOps Operator namespace (
openshift-gitops), the badge might not appear. - Namespace view: From the GitOps Operator namespace path, an optional control can list operands in all namespaces for operator-focused workflows
Details page
The Application details page provides the following tabs:
- Details tab: Displays summary information, health and sync indicators, revision links, destination and project information, conditions, toggles for automated sync, self-heal, and prune (when you have update permission), and detection of an Argo CD Route so you can open the Argo CD UI for the same application when routing is configured.
- YAML tab: Provides a live manifest editor for the Application resource.
- Sources tab: Displays repository sources with icons and metadata for Helm, Git, and OCI sources.
Resources tab: Combines a resource table with an interactive topology graph:
- The graph shows immediate managed resources for the Application, not the full Argo CD resource tree.
- Use the Argo CD link on the tab to open the complete resource hierarchy in the Argo CD UI.
- Pan, zoom, and select resources in the graph; status filters apply to both table and graph.
- Context-menu actions on graph nodes include viewing details, editing labels and annotations, deleting resources, and viewing resources in Argo CD.
- Related resources of the same kind can be grouped or ungrouped in the graph.
- Sync Status tab: Provides fine-grained sync and operation status information for the Application.
- History tab: Displays the deployment and sync history for the Application.
- Events tab: Shows Kubernetes events for the Application object.
Additional features
- Favorites: You can mark Applications as favorites based on console user settings.
- Standard actions: The page header provides access to standard actions such as editing labels, annotations, and deleting the Application.
5.3.2. ApplicationSets in the GitOps Console Copy linkLink copied to clipboard!
The GitOps Console Plugin shows key details of Argo CD ApplicationSets. You can view and create ApplicationSets directly from the OpenShift Container Platform web console. A new Graphical view shows the applications managed by an ApplicationSet and the progressive sync flow from one step to the next.
List page
The ApplicationSets list page follows the same list patterns as other custom resources:
- Table columns: Standard columns for custom resources
- Filtering: Filter ApplicationSets by health status (Healthy, Error, Unknown)
- Create action: Click Create ApplicationSet to open the YAML editor with a default ApplicationSet template
Details page
The ApplicationSet details page provides the following tabs:
- Details tab: Displays status information, generator counts, conditions, links to the Generators and Applications tabs, and shows the number of generated applications of related Applications.
- YAML tab: Provides a live manifest editor for the ApplicationSet resource.
- Generators tab: Provides a structured view of generator configuration, including list, merge, and union generators.
- Applications tab: Displays the list of applications generated by the ApplicationSet with a Graphical View showing visual representation of the generated applications, progressive sync visualization that shows the progressive sync flow from step to step when progressive sync is enabled, a filter widget to filter by health and sync status, and an applications table with the same rich columns as the main Application list page.
- Events tab: Shows Kubernetes events for the ApplicationSet object.
5.3.3. AppProjects in the GitOps Console Copy linkLink copied to clipboard!
The GitOps Console plugin provides summary details for Argo CD AppProjects. You can view and create project-scoped AppProjects directly from the OpenShift web console.
List page
The AppProjects list page displays all project-scoped AppProjects with the following features:
- Table columns: Standard columns for custom resources
- Filtering: Filter projects by Description, Applications, Project Type, Source Repositories, and Destinations
- Create action: Click Create AppProject to open the YAML editor with a default AppProject template
Details page
The AppProject details page provides the following tabs:
- Details tab: Displays project summary, destinations, policies, and related metadata.
- YAML tab: Provides a live manifest editor for the AppProject resource.
- Allow/Deny tab: Displays resource allow and deny lists for cluster-scoped and namespace-scoped kinds.
- Applications tab: Shows Applications that belong to this project. The table provides the same experience as the main Application list, filtered by project.
- Roles tab: Displays Argo CD project roles and bindings.
- Sync Windows tab: Shows configured sync windows for the project.
- Events tab: Shows Kubernetes events for the AppProject object.
5.3.4. Rollouts in the GitOps Console Copy linkLink copied to clipboard!
The GitOps Console plugin provides comprehensive details of Argo Rollouts instances in the cluster. You can view and create, Rollout resources directly from the OpenShift web console.
List page
The Rollouts list page displays all Argo Rollout resources with the following features:
- Table columns: Standard columns for Rollout resources
- Filtering: Filter Rollouts by rollout status (Healthy, Paused, Progressing, Degraded)
- Create action: Click Create Rollout to open the YAML editor with a default Rollout template
Topology integration
The OpenShift Console Topology view shows the cluster’s Rollout instances. The Topology view provides:
- Rollout Details and Overview sidebar tabs with information on the resource
- Context actions for Rollout resources
- Visual decorator on Rollout nodes
Details page
The Rollout details page provides the following tabs:
- Details tab: Displays replicas with inline scale controls when you have the required permissions, rollout status, conditions, strategy-specific sections for Canary or Blue-Green services, a link to open this workload in the Topology view, and related navigation helpers.
- YAML tab: Provides a live manifest editor for the Rollout resource.
Revisions tab: Displays ReplicaSet and revision-oriented information for the rollout, including:
- Rollout status and strategy
- Revision history with ReplicaSet details
Pod status and health
This view provides the same information as the oc argo rollouts get rollout CLI command, including the functionality of the --watch option, allowing you to monitor rollout progress directly from the console. For more information, see Using Argo Rollouts for progressive deployment delivery in Additional resources.
- Pods tab: Shows pods for the rollout with pod-level actions.
- Events tab: Shows Kubernetes events for the Rollout object.
5.4. Filter resources Copy linkLink copied to clipboard!
The GitOps Console plugin provides filters to narrow the resource list based on specific properties. The available filter options vary by resource type.
Prerequisites
- You have access to the Red Hat OpenShift GitOps web console.
- The GitOps Console plugin is enabled.
Procedure
- In the Red Hat OpenShift GitOps web console, navigate to GitOps and select a resource type.
On the list page, use the available filter controls to narrow the displayed resources.
The following filters are available depending on the resource type:
- Applications: Filter by health status (Healthy, Progressing, Degraded, Missing) and sync status (Synced, OutOfSync, Unknown).
- ApplicationSets: Filter by health status (Healthy, Error, Unknown).
- AppProjects: Filter by Description, Applications, Project Type, Source Repositories, and Destinations.
- Rollouts: Filter by rollout status (Healthy, Paused, Progressing, Degraded).
- Optional: Combine multiple filters to narrow the results further.
- To clear filters, click the Clear all filters link or remove individual filter selections.
Verification
- Verify that the resource list displays only items matching your selected filter criteria.