GitOps - Argo CD

OpenShift GitOps

- Thomas Jungbauer Thomas Jungbauer ( Lastmod: 2024-05-08 ) - 5 min read

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. GitOps itself uses Git pull request to manager infrastructure and application configuration.

Let’s try to install and use a simple usecase in order to demonstrate the basic possibilities.

Without going into the very detail, typical GitOps usecases are:

  • Apply configurations from Git

  • Detect, (auto-)sync and notify configuration drifts

  • Manage multiple clusters and keep the configuration equal

  • …​

and much more. Further information about the theory behind can be found at https://www.openshift.com/blog/introduction-to-gitops-with-openshift.

In short: there is no reason why not to use GitOps and to leverage tools like Argo CD to manage configurations. In this tutorial, the Argo CD operator gets installed and a simple use case is shown to demonstrate the possibilities of this software.

As for architectural overview of Argo CD, please read the official documentation: https://argoproj.github.io/argo-cd/operator-manual/architecture/, which explains very well the core components. No need to rewrite it here.

Prerequisites

You need an Openshift 4 cluster. :)

Watch the video at: https://demo.openshift.com/en/latest/argocd/

Install Argo CD operator

Before you begin, create a new project:

oc new-project argocd

In this project the operator will be deployed.

Look for the Operatorhub in the OpenShift WebUI and "argocd" and select the "Argo CD Community" operator. Subscribe to this operator. Just be sure that the newly created project is selected. Other settings can stay as default.

Operator Install
Figure 1. Argo CD: Operator

This will install the operator. You can monitor this process by clicking "Installed Operators". After a while it should switch from "Installing" to "Succeeded".

Deploy ArgoCD instance

Select the installed operator "Argo CD", select the tab "ArgoCD" and hit the button "Create ArgoCD"

Enter the following yaml:

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  dex:
    image: quay.io/redhat-cop/dex
    openShiftOAuth: true
    version: v2.22.0-openshift
  rbac:
    policy: |
      g, argocdadmins, role:admin
    scopes: '[groups]'
  server:
    route:
      enabled: true

This yaml extends the default example by:

  • using OpenShift authentication

  • Allow all users from the group "argocdadmins" admin permissions inside Argo CD

  • create a route to access argocd web interface

Once this configuration is created, the operator will automatically start to roll out the different pods, which are required. No worries, it will take quite long until everything is up and running.

Create a new group and assign a user to it

In the ArgoCD resource we have defined the group argocdadmins and all users in this group will get administrator privileges in Argo CD. This group must be created and in addition we assign the user admin to it.

For example with the following commands:

oc adm groups new argocdadmins
oc adm groups add-users argocdadmins admin

Login to Argo CD

Now it is time to login to Argo CD. Just fetch the route which was created by the operator (for example with: oc get routes -n argocd).

On the login page select "Login via OpenShift" and enter the credentials of the user you would like to use. (well, the one which you can admin permissions in the step above).

ArgoCD Login
Figure 2. Argo CD: Login Screen

This will open the Argo CD Interface.

First test with Argo CD

Let’s create an application in Argo CD to demonstrate the possibilities about application management with GitOps. We will use a simple application which draws a blue (or green) box in your browser.

Click on the button "Create App" and enter the following parameters:

At the end, it should look like this:

ArgoCD Create App
Figure 3. Argo CD: Create an Application

Press the "Create" button and your application is ready to be synchronized. Since no synchronization happens yet, Argo CD will complain that the application is out of sync.

Sync application

Since we set the Sync Policy to manual, the synchronization process must be started, guess what, manually. Click on the "Sync" button and Argo CD will open a side panel, which shows the resources are out of sync and other options.

ArgoCD Sync App
Figure 4. Argo CD: Sync an Application

One notable option is the "Prune" setting. By selecting this, changes which have been done directly on OpenShift, are removed and replaced by the ones which are stored at Git.

This is a very good option, to force everyone to follow the GitOps process :)

Press the "Synchronize" button and select the application. As you see the sync process has started and after a while, all resources are synced to OpenShift.

ArgoCD App Syncing
Figure 5. Argo CD: Application Syncing
ArgoCD App Synced
Figure 6. Argo CD: Application Synced

Verifying objects

Now that Argo CD says that the application has been synchronized, we should check the objects, which have been created in OpenShift.

As you can see in the Git repository, there are 4 objects which should exist now:

  • a namespace (bgd)

  • a deployment

  • a service

  • a route

ArgoCD Git Repo
Figure 7. Argo CD: Git Repo

To verify the existence either check via the WebUI or simply try:

oc get all -n bgd
NAME                       READY   STATUS    RESTARTS   AGE
pod/bgd-6b9b64d94d-5fqdg   1/1     Running   0          6m2s

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/bgd   ClusterIP   172.30.233.30   <none>        8080/TCP   6m7s

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/bgd   1/1     1            1           6m4s

NAME                             DESIRED   CURRENT   READY   AGE
replicaset.apps/bgd-6b9b64d94d   1         1         1       6m3s

NAME                           HOST/PORT                      PATH   SERVICES   PORT   TERMINATION   WILDCARD
route.route.openshift.io/bgd   bgd-bgd.apps.ocp.example.test          bgd        8080                 None

Obviously, the namespace exists and with it also the other objects, which hae been synchronized.

When you now open the route http://bgd-bgd.apps.ocp.example.test in your browser, you will see a nice blue box.

ArgoCD Blue Box
Figure 8. Argo CD: The Blue Box

As you can see all objects have been synchronized and the application has been deployed correctly. The source of truth is in Git and all changes should be done there.

I want a green box

So you want a green box? Maybe you think of doing this:

Modify the Deployment and change the environment COLOR from blue to green:

...
    spec:
      containers:
        - name: bgd
          image: 'quay.io/redhatworkshops/bgd:latest'
          env:
            - name: COLOR
              value: green # change from blue to green
...

This will trigger a re-deployment and …​ fine …​ you have a green box:

ArgoCD Green Box
Figure 9. Argo CD: The Green Box

But is this the correct way to do that? NO, it is not. Argo CD will immediately complain that the application is out of sync.

ArgoCD Out of Sync
Figure 10. Argo CD: Out of Sync

When you sync the application it will end up with a blue box again.

ArgoCD Blue Box
Figure 11. Argo CD: The Blue Box

But you really really want a green box? Fair enough, the correct way would be to change the deployment configuration on Git. Simply change the file bgd/bgd-deployment.yaml and set the COLOR to green:

...
    spec:
      containers:
      - image: quay.io/redhatworkshops/bgd:latest
        name: bgd
        env:
        - name: COLOR
          value: "green"
        resources: {}

Again Argo CD will complain that it is out of sync.

ArgoCD Git Update
Figure 12. Argo CD: Git Update

By synchronizing the changes, it will deploy the latest version found at Git and …​ yes, you have a green box now (When deployment on OpenShift side has finished).

ArgoCD Green Box
Figure 13. Argo CD: The Green Box

See Also:

  • Using Kustomize to post render a Helm Chart –

    Lately I came across several issues where a given Helm Chart must be modified after it has been rendered by Argo CD. Argo CD does a helm template to render a Chart. Sometimes, especially when you work with Subcharts or when a specific setting is not yet supported by the Chart, you need to modify it later …​ you need to post-render the Chart. In this very short article, I would like to demonstrate this on a real-live example I had to do. I would like to inject annotations to a Route objects, so that the certificate can be injected. This is done by the cert-utils operator. For the post-rendering the Argo CD repo pod will be extended with a sidecar container, that is watching for the repos and patches them if required.

  • Managing Certificates using GitOps approach –

    The article SSL Certificate Management for OpenShift on AWS explains how to use the Cert-Manager Operator to request and install a new SSL Certificate. This time, I would like to leverage the GitOps approach using the Helm Chart cert-manager I have prepared to deploy the Operator and order new Certificates. I will use an ACME Letsencrypt issuer with a DNS challenge. My domain is hosted at AWS Route 53. However, any other integration can be easily used.

  • Update Cluster Version using GitOps approach –

    During a GitOps journey at one point, the question arises, how to update a cluster? Nowadays it is very easy to update a cluster using CLI or WebUI, so why bother with GitOps in that case? The reason is simple: Using GitOps you can be sure that all clusters are updated to the correct, required version and the version of each cluster is also managed in Git. All you need is the channel you want to use and the desired cluster version. Optionally, you can define the exact image SHA. This might be required when you are operating in a restricted environment.

  • Multiple Sources for Applications in Argo CD –

    Argo CD or OpenShift GitOps uses Applications or ApplicationSets to define the relationship between a source (Git) and a cluster. Typically, this is a 1:1 link, which means one Application is using one source to compare the cluster status. This can be a limitation. For example, if you are working with Helm Charts and a Helm repository, you do not want to re-build (or re-release) the whole chart just because you made a small change in the values file that is packaged into the repository. You want to separate the configuration of the chart with the Helm package. The most common scenarios for multiple sources are (see: Argo CD documentation): Your organization wants to use an external/public Helm chart You want to override the Helm values with your own local values You don’t want to clone the Helm chart locally as well because that would lead to duplication and you would need to monitor it manually for upstream changes. This small article describes three different ways with a working example and tries to cover the advantages and disadvantages of each of them. They might be opinionated but some of them proved to be easier to use and manage.

  • Installing OpenShift Logging using GitOps –

    OpenShift Logging is one of the more complex things to install and configure on an OpenShift cluster. Not because the service or Operators are so complex to understand, but because of the dependencies logging has. Besides the logging operator itself, the Loki operator is required, the Loki operator requires access to an object storage, that might be configured or is already available. In this article, I would like to demonstrate the configuration of the full stack using an object storage from OpenShift Data Foundation. This means: Installing the logging operator into the namespace openshift-logging Installing the Loki operator into the namespace openshift-operators-redhat Creating a new BackingStore and BucketClass Generating the Secret for Loki to authenticate against the object storage Configuring the LokiStack resource Configuring the ClusterLogging resource All steps will be done automatically. In case you have S3 storage available, or you are not using OpenShift Data Foundation, the setup will be a bit different. For example, you do not need to create a BackingStore or the Loki authentication Secret.

Copyright © 2020 - 2024 Toni Schmidbauer & Thomas Jungbauer