Davie Street Enterprises embraces GitOps with GitLab

Configuring Merge Request-based pipelines in GitLab

Martinez opens a local copy of the inventory application and creates a new branch. He then creates a new file in the root directory of the project called .gitlab-ci.yml. He adds this code to the file:

default:
  image: node:latest
  cache:
    paths:
      - node_modules

stages:
  - prepare_env
  - build
  - package
  - deploy
  
.openshift_job:
  image: daviestreetent/gitlab-ci-openshift
  before_script:
    - oc login $OC_URL --token=$OC_TOKEN --insecure-skip-tls-verify
    - oc project $OC_NAMESPACESLUG-dev

"Prepare OpenShift Environment (Dev)":
  extends: .openshift_job
  stage: prepare_env
  script:
    - echo "===== ENFORCING INFRASTRUCTURE OBJECTS ======="

    - oc apply --filename=./.openshift/dev --recursive=true --wait=true -n $OC_NAMESPACESLUG-dev
  rules:
    - if: '$CI_COMMIT_REF_NAME == "master"'
      when: always
    - when: never

"Prepare OpenShift Environment (Staging)":
  extends: .openshift_job
  stage: prepare_env
  script:
    - echo "===== ENFORCING INFRASTRUCTURE OBJECTS ======="
    - oc login $OC_URL --token=$OC_TOKEN --insecure-skip-tls-verify
    - oc project $OC_NAMESPACESLUG-staging
    - oc apply --filename=./.openshift/staging --recursive=true --wait=true -n $OC_NAMESPACESLUG-staging
  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'
      when: always
    - when: never

"Prepare OpenShift Environment (Production)":
  extends: .openshift_job
  stage: prepare_env
  script:
    - echo "===== ENFORCING INFRASTRUCTURE OBJECTS ======="
    - oc apply --filename=./.openshift/prod --recursive=true --wait=true -n $OC_NAMESPACESLUG-prod
  rules:
    - if: '$CI_COMMIT_REF_NAME == "prod"'
      when: always
    - when: never

build:
  stage: build
  image: node:latest
  script:
    - npm install
  allow_failure: true
  artifacts:
    paths:
    - node_modules
    expire_in: 1 week

"Package Image on OCP":
  extends: .openshift_job
  stage: package
  script:
    - oc start-build openshift-spring-custom --follow --from-dir .

"Deploy Application on OCP":
  extends: .openshift_job
  stage: deploy
  when: manual
  script:
    - oc project $OC_NAMESPACESLUG-dev
    - oc rollout latest dc/openshift-test-app

“Ok, so that’s a big file - let’s break it down. What we’re doing is establishing some defaults, configuring the stages our pipeline will contain, specifying some global configurations, and then for each stage, we describe the job we want to run. You can see a few common elements from each of these jobs."

"First, they have a human-readable label. Then we see they extend the defaults stage we defined earlier, and define when in the pipeline the job is run. Now we specify our scripts to run for the job, and then optionally establish rules - as an example in the cases above, you can see that the job "Prepare OpenShift Environment (Production)": would only be run if the branch we’re merging into was labeled “prod” - this allows you to be more or less picky about what occurs on different environments."

"In the case of this pipeline, we’re taking the API objects described in the .openshift directory and the appropriate subdirectory and running an oc apply on them. If the apply succeeds, the job proceeds to the next stage, where we build and package a new iteration of the application. The final stage, deploy, is configured to require a manual action in order to roll out the new project.”

“So now that we’ve got that out of the way, let’s commit our pipeline code and see what it looks like on GitLab.”

He commits the code, and pulls up the repository on GitLab. It looks like this:

“Looks like the job failed - that’s completely normal, because we haven’t installed or configured a runner for our project. Let’s do that now.”

Installing the GitLab Runner Operator

“First, we need to install the Operator, which we do through the OpenShift Console.”

“After clicking on the Runner Operator, we’re asked to specify a few things for the installation. We’ll choose a specific namespace to install the operator for, so we can keep our workstreams clean.”

“After clicking on ‘Install,’ the Runner Operator should be online within a few minutes.”

oc get runners
NAME               AGE
gitlab-runner      5m

oc get pods
NAME                                 READY   STATUS     RESTARTS     AGE
gitlab-runner-bf9894bdb-wplxn        1/1     Running    0            5m

“Now that it’s reporting as running, we can check back with GitLab to see that the Runner has phoned home and is now available.”

Deploying a requested change using the GitLab Runner Operator

“Let’s test it out. I’ve modified the version number for NodeJS for our application - take a look at the following commit:”

“Looks good - let’s now create a merge request, and approve it. After a few minutes, we can start to see our pipeline jobs have all successfully passed, up to the final ‘deploy’ stage, which requires manual intervention:”

“Take a peek behind the scenes - this is what the Prepare_env job is reporting. You can see that the new configurations have been successfully applied, specifically in this case, the build config.”

“All we need to do now is deploy - we’ll click on the ‘play’ button to kick it off... Looks like it’s running nicely!”

“And now it’s finished. If we look in the logs for the build we can see that it did indeed rollout the new version of our application. Where’s my ‘Easy Button?’”

Tune in next time…

A few days and several pizzas later, Martinez’s team steps away from their keyboards and joins him in a conference room. Already seated at the table is Zachary L. Tureaud, Director of Security Engineering. Martinez motions to his team to take a seat.

“I think we can all agree that we’ve had amazing success in improving our development pipeline. I have already seen an increase in velocity through some of the issues that have been worked on for the past couple of days. It seems evident that the new pipeline has taken a very large bite out of our workload, and freed us up to move faster and even have some time to brainstorm.”

“It’s because of this success that I’ve asked Zachary to take a look at what we’ve done to see if we might be able to leverage this system to increase our security as well. Our relationship with the security team has not been well-maintained over the past few years. We haven’t had the time to work with them on ensuring we maintain our security, and need to do a better job shifting that security burden left. I’ll let Zachary explain further.”

Tureaud stands up and grabs a whiteboard marker. “Alright, is everyone sitting comfortably? Then we’ll begin.”

To be continued

If you’d like to see a step-by-step demonstration of the methods described in this post, please take a look at the video on our YouTube channel.

Resources

• Install GitLab Runner on Red Hat OpenShift (GitLab Docs)
• GitLab CI/CD Pipelines documentation
• GitLab CI/CD Jobs documentation
• An example GitOps project on GitLab.com