Skip to content

CI/CD GitOps on Openshift


Openshift shares many core components with Kubernetes and provides additional features that are catering specifically for enterprise usage. In such an environment, CI/CD pipelines are often automated to allow developers to quickly deliver new code to the production environment with certain level of assurance. In this tutorial, we assume the reader is already using Openshift, managing CI/CD pipelines with Openshift Pipeline (Tekton) and Openshift GitOps (ArgoCD), and has a GitOps setup to allow newly built images to be deployed into the cluster. We will describe how such users could integrate Iter8 into their existing pipeline in a minimally intrusive way to allow their applications to be progressively rolled out.

This tutorial assumes a basic understanding of Iter8. See, for example, the Istio quick start tutorial.

1. Install Iter8

Installing Iter8 on Openshift is slightly different from installing it on K8s. After Iter8 is installed, an extra step one needs to perform is:

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

2. Openshift Metrics

Openshift comes with a built-in Prometheus server, which is authenticated with a sidecar proxy. To allow Iter8 to retrieve metrics from it, one needs to provide a mean to authenticate. Iter8 currently supports basic authentication and bearer token, described in Iter8 metrics.

An example request count metric looks like:

kind: Metric
    creator: iter8
  name: request-count
  namespace: default
  description: Number of requests
  jqExpression: .data.result[0].value[1] | tonumber
  - name: query
    value: |
      sum(increase(haproxy_server_http_responses_total{exported_service='$name',exported_namespace='$namespace'}[${elapsedTime}s])) or vector(0)
  provider: prometheus
  type: Counter
  urlTemplate: https://prometheus-operated.openshift-monitoring:9091/api/v1/query
  authType: Bearer
  secret: default/promsecret
  - name: Authorization
    value: Bearer ${token}

3. Augment the CI Pipeline with Iter8

The CI pipeline gets triggered when new code is merged, and it is responsible for testing and building the new code. The end product is usually a newly build image pushed to an image repository. When one wants to leverage Iter8, one should create a Candidate Deployment (using the new image) and an Iter8 Experiment CR. Subsequently, Iter8 will observe metrics collected from the Candidate version and check if all success criteria have passed. If so, the candidate version will be promoted. Here is an example Tekton task that creates these resources in Git.

kind: Task
  name: start-experiment
  annotations: "Start an Iter8 experiment"
  description: >-
    This task create a candidate and Iter8 experiment resource in
    the Env repo and make a PR from the changes

    - name: USER
      description: Github username
    - name: REPO
      description: Github repo name
    - name: BRANCH
      description: Base branch PR is opened against
      description: Holds Github token

  - name: start-experiment
    image: alpine/git:latest
    script: |
      #!/usr/bin/env sh
      apk add curl jq make
      git config --global ''
      git config --global 'Iter8'
      git clone https://$(params.USER):${GITHUB_TOKEN}$(params.USER)/$(params.REPO) --branch=$(params.BRANCH)
      [create a Deployment Candidate yaml]
      [create an Iter8 Experiment yaml]
      git add -A
      git commit -a -m 'start Iter8 experiment'
      git push -f origin $(params.BRANCH)
    - name: GITHUB_TOKEN
           name: $(params.GITHUB-TOKEN-SECRET)
           key: token

In a non-GitOps environment, the git commands will be replaced with oc commands to directly deploy into the cluster. An example Tekton Pipeline where the above Task can be added to is:

  - name: start-experiment
      name: start-experiment
    - name: USER
      value: [YOUR GIT USERNAME]
    - name: REPO
      value: [YOUR GIT REPO]
    - name: BRANCH
      value: master
      value: github-token
Back to top