Chapter 5. GitOps

1. Application repository with the source code
2. Environment configuration repository that defines the desired state of the application

Procedure

1. Open the Administrator perspective of the web console and navigate to Operators → OperatorHub in the menu on the left.

2. 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.

Procedure

1. 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.

2. Apply the Subscription to the cluster:

   $ oc apply -f openshift-gitops-sub.yaml

3. 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

Procedure

1. In the Administrator perspective of the web console, navigate to Operators → Installed Operators to verify that the Red Hat OpenShift GitOps Operator is installed.
2. Navigate to the menu → OpenShift GitOps → Cluster Argo CD. The login page of the Argo CD UI is displayed in a new window.

3. Optional: To log in with your OpenShift Container Platform credentials, ensure you are a user of the cluster-admins group and then select the LOG IN VIA OPENSHIFT option in the Argo CD user interface.

   Note

   To be a user of the cluster-admins group, use the oc 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.

4. To log in with your username and password, obtain the password for the Argo CD instance:

   1. In the left panel of the console, use the perspective switcher to switch to the Developer perspective.
   2. Use the Project drop-down list and select the openshift-gitops project.
   3. Use the left navigation panel to navigate to the Secrets page.
   4. Select the openshift-gitops-cluster instance to display the password.
   5. Copy the password.
5. Use this password and admin as the username to log in to the Argo CD UI in the new window.

Procedure

1. In the Terminal type the following command:

Procedure

1. From the Operators → OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift GitOps Operator tile.
2. Click the Red Hat OpenShift GitOps Operator tile. The Operator tile indicates it is installed.
3. In the Red Hat OpenShift GitOps Operator descriptor page, click Uninstall.

Procedure

1. Log in to the OpenShift Container Platform web console.
2. Click Operators → Installed Operators.
3. Create or select the project where you want to install the Argo CD instance from the Project drop-down menu.
4. Select OpenShift GitOps Operator from the installed operators and select the Argo CD tab.

5. Click Create to configure the parameters:

   1. Enter the Name of the instance. By default, the Name is set to argocd.
   2. Create an external OS Route to access Argo CD server. Click Server → Route and check Enabled.
6. 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.

Procedure

1. In the Administrator perspective, navigate to Administration → CustomResourceDefinitions.
2. Find the Subscription CRD and click to open it.
3. Select the Instances tab and click the openshift-gitops-operator subscription.

4. 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'

Procedure

1. In the Developer perspective of the web console, select the namespace where your Argo CD application is installed, and navigate to Observe → Metrics.
2. From the Select query drop-down list, select Custom query.

3. 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 example openshift-gitops.

Procedure

1. In the Administrator perspective of the web console, navigate to Operators → Installed Operators → Red Hat OpenShift GitOps → Subscription.
2. Click the Actions drop-down menu then click Edit Subscription.

3. 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 the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec 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>
   ...

4. To verify that the Argo instance is configured with a cluster role to manage cluster-scoped resources, perform the following steps:

   1. Navigate to User Management → Roles and from the Filter drop-down menu select Cluster-wide Roles.

   2. Search for the argocd-application-controller by using the Search by name field.

      The Roles page displays the created cluster role.

      Tip

      Alternatively, 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.

Procedure

1. Label the existing nodes:

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

2. 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

3. Add the runOnInfra toggle in the GitOpsService custom resource:

   apiVersion: pipelines.openshift.io/v1alpha1
   kind: GitopsService
   metadata:
     name: cluster
   spec:
     runOnInfra: true

4. Optional: If taints have been added to the nodes, then add tolerations to the GitOpsService custom resource, for example:

     spec:
       runOnInfra: true
       tolerations:
       - effect: NoSchedule
         key: infra
         value: reserved
       - effect: NoExecute
         key: infra
         value: reserved

5. Verify that the workloads in the openshift-gitops namespace are now scheduled on the infrastructure nodes by viewing Pods → Pod details for any pod in the console UI.

Procedure

1. In the Argo CD dashboard, click NEW APP to add a new Argo CD application.

2. 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

3. Click CREATE to create your application.
4. Open the Administrator perspective of the web console and navigate to Administration → Namespaces in the menu on the left.
5. 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 the openshift-gitops namespace can manage your namespace.

Procedure

1. Download the sample application:

   $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git

2. Create the application:

   $ oc create -f openshift-gitops-getting-started/argo/app.yaml

3. Run the oc get command to review the created application:

   $ oc get application -n openshift-gitops

4. 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

Procedure

1. 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.
2. 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.
3. 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.
4. 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.

5. 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.

Procedure

1. Log in to the OpenShift Container Platform web console as an admin.

2. 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: ["*"]

3. Click Create to add the cluster role.
4. Now create the cluster role binding. In the web console, select User Management → Role Bindings → Create Binding.
5. Select All Projects from the Project drop-down.
6. Click Create binding.
7. Select Binding type as Cluster-wide role binding (ClusterRoleBinding).
8. Enter a unique value for the RoleBinding name.
9. Select the newly created cluster role or an existing cluster role from the drop down list.

10. Select the Subject as ServiceAccount and the provide the Subject namespace and name.

    1. Subject namespace: openshift-gitops
    2. Subject name: openshift-gitops-argocd-application-controller

11. 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

Procedure

1. In the Argo CD dashboard, click NEW APP to add a new Argo CD application.

2. 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

3. 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

4. Click CREATE to create your application.
5. Open the Administrator perspective of the web console and navigate to Administration → Namespaces in the menu on the left.
6. 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 the openshift-gitops namespace can manage your namespace.

Procedure

1. Download the sample application:

   $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git

2. Create the application:

   $ oc create -f openshift-gitops-getting-started/argo/app.yaml

   $ oc create -f openshift-gitops-getting-started/argo/app.yaml

3. Run the oc get command to review the created application:

   $ oc get application -n openshift-gitops

4. 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

Procedure

1. In the Argo CD dashboard, verify that your application has the Synced status.
2. Click the app-spring-petclinic tile in the Argo CD dashboard to view the application resources that are deployed to the cluster.
3. In the OpenShift Container Platform web console, navigate to the Developer perspective.

4. 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.

   1. Fork the OpenShift GitOps getting started repository.
   2. In the deployment.yaml file, change the failureThreshold value to 5.

   3. 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

5. 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.

   1. Run the following command to modify the deployment:

      $ oc scale deployment spring-petclinic --replicas 2  -n spring-petclinic

   2. 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.
6. 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.

Procedure

1. Set the enabled parameter to true:

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Create an Argo CD instance with autotls enabled:

   1. In the Administrator perspective of the web console, use the left navigation panel to go to Administration → CustomResourceDefinitions.
   2. Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD).
   3. On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.

   4. 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.

      Tip

      Alternatively, 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"}}}'

   5. Click Create.

   6. 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

      Note

      The 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

3. 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 of 2.

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Create an Argo CD instance:

   1. In the Administrator perspective of the web console, use the left navigation panel to go to Administration → CustomResourceDefinitions.
   2. Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD).
   3. On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.

   4. 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

      1

      The name of the Argo CD instance.

      2

      The namespace where you want to run the Argo CD instance.

      3

      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.

   5. Click Create.

   6. 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

      Note

      The 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

3. 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'

4. 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
   ...

5. 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

6. 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

7. 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

   Note

   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

Procedure

1. Click Environments under the Developer perspective. The Environments page shows the list of applications along with their Environment status.
2. Hover over the icons under the Environment status column to see the synchronization status of all the environments.
3. Click on the application name from the list to view the details of a specific application.

4. 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.

Procedure

1. To enable Dex, set the .spec.sso.provider: dex parameter in the YAML resource of the Operator:

   ...
   spec:
     sso:
       provider: dex
       dex:
         openShiftOAuth: true
   ...

2. To disable dex, either remove the spec.sso element from the Argo CD custom resource, or specify a different SSO provider.

1. 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:

2. Set the value of the provider parameter to keycloak in the Argo CD CR.

3. 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 the oidc.config parameter with the PEM encoded root certificate in the argocd-cm configuration map.

   • For an insecure connection, leave the value of the rootCA parameter empty and use the oidc.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: ""

Procedure

1. 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

2. 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

   1. Get the Keycloak user name:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME
      
      SSO_ADMIN_USERNAME=<username>

   2. Get the Keycloak password:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD
      
      SSO_ADMIN_PASSWORD=<password>

3. On the login page, click LOG IN VIA KEYCLOAK.

   Note

   You only see the option LOGIN VIA KEYCLOAK after the Keycloak instance is ready.

4. Click Login with OpenShift.

   Note

   Login using kubeadmin is not supported.

5. Enter the OpenShift credentials to log in.

6. 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

Procedure

1. Set the .spec.monitoring.enabled field value to true 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
     ...

2. 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.

Procedure

1. In the OpenShift Container Platform web console, go to the menu → Observability → Logging to view the Kibana dashboard.

2. Create an index pattern.

   1. To display all the indices, define the index pattern as *, and click Next step.
   2. Select @timestamp for Time Filter field name.
   3. Click Create index pattern.
3. In the navigation panel of the Kibana dashboard, click the Discover tab.

4. 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:

   1. Click Add a filter +.
   2. Select the kubernetes.namespace_name field.
   3. Select the is operator.
   4. Select the openshift-gitops value.
   5. Click Save.
5. 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.
6. View the filtered Argo CD logs in the Kibana dashboard.

Procedure

1. Label existing nodes as infrastructure by running the following command:

   $ oc label node <node-name> node-role.kubernetes.io/infra=

2. Edit the GitOpsService custom resource (CR) to add the infrastructure node selector:

   $ oc edit gitopsservice -n openshift-gitops

3. In the GitOpsService CR file, add runOnInfra field to the spec section and set it to true. This field moves the workloads in openshift-gitops namespace to the infrastructure nodes:

   apiVersion: pipelines.openshift.io/v1alpha1
   kind: GitopsService
   metadata:
     name: cluster
   spec:
     runOnInfra: true

4. 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

5. 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