Using GitOps on OpenShift

This article demonstrates a typical scenario how to deploy a microservice on OpenShift using the GitOps capabilities of ArgoCD.

In a previous article I described how to install and configure ArgoCD on OpenShift. Let’s now look at a sample pipeline which deploys a microservice from my application modernization example.

The microservice is deployed to three different projects: dev, test and prod. For simplification reasons they belong to the same cluster. For each environment there is an ArgoCD application: dev, test, prod.

In order to synchronize between the ‘to be state’ in the GitOps repo and the ‘is state’ in Kubernetes, ArgoCD is used. For the deployment of my sample microservice I use the repo nheidloff/application-modernization-javaee-quarkus-config.

Sample Tekton Pipeline

The pipeline contains the following Tekton tasks and steps. The code can be found in the scripts-openshift-argocd directory.

First the code is pulled from GitHub. In this case it’s a public repo, but it could also be private since it is accessed on behalf of a specific user via ssh.

In the next steps the Java code is built and static and unit tests are executed. After this the image is built and pushed to OpenShift’s internal registry.

GitOps Functionality

So far nothing has been specific to GitOps. You would basically use the same steps in other pipelines. In the next step though the image is tagged with an unique id. Usually this is the Git commit id to map between a specific image version to a specific code version. Additionally the image is pushed to the three projects (or in one shared project with images).

script: |
  #!/usr/bin/env sh
  set -e
  source $(
  echo image: $(params.image)
  echo Tagging dev image
  buildah pull --tls-verify=false docker://$(params.image)
  buildah tag docker://$(params.image) docker://$(params.image):$REVISION
  buildah push --tls-verify=false docker://$(params.image):$REVISION

Note that I pass in the GitHub commit id (REVISION) via a file in the workspace. I’ve tried to use Tekton input and output parameters, but it didn’t work for my OpenShift Tekton version.

After this the yaml files for the microservice version in the dev environment are updated with the latest image tag.

script: |
  #!/usr/bin/env sh
  set -e
  source $(
  cd $(workspaces.config-source.path)    
  cd service-catalog-quarkus-reactive
  cd $(params.environment)
  sed "s/<project-name>/app-mod-argocd-$(params.environment)/g" $( > kubernetes-temp.yaml
  sed "s/<version>/$REVISION/g" kubernetes-temp.yaml > kubernetes.yaml
  cp $( openshift.yaml

Next the changes need to be pushed to the GitOps repo.

script: |
  #!/usr/bin/env sh
  set -e
  eval $(ssh-agent)
  ssh-add ~/.ssh/id_*
  git config --global ""
  git config --global "Tekton Pipeline"
  git add .
  git commit --allow-empty -m "[Tekton] updating $(params.environment)"
  git push origin main

In the last step ArgoCD is triggered to synchronize the new ‘to be state’ with the ‘is state’ in OpenShift.

  - name: argo-app-name
    - secretRef:
        name: argocd-env-secret
    - name: ARGOCD_SERVER
      value: argocd-cluster-server.openshift-gitops

  - name: wait-for-argocd-rollout
    image: argoproj/argocd:v1.7.7
    script: |
      #!/usr/bin/env sh
      set -e
      argocd app sync $(inputs.params.argo-app-name) --insecure
      argocd app wait $(inputs.params.argo-app-name) --sync --health --operation --insecure

If the microservice works in the dev environment, it will be deployed to the test environment and after additional tests have been made it will be deployed to production.

ArgoCD Console

In the ArgoCD Console you can see the status of your applications. The screenshot shows the three ArgoCD applications for the three environments.

Additionally you can navigate to specific applications for details. The next screenshot shows the different Kubernetes and OpenShift resources for the microservice.

Next Steps

To learn more about Tekton, ArgoCD and application modernization, check out my repo.