Now that we have our Projects setup; we can start to populate them with Apps to be used in our dev lifecycle

1. In the enablement-ci-cd repo, checkout the templates for Nexus by running

   git checkout exercise1/git-nexus templates/nexus.yml
   

   The template contains all the things needed to setup a persistent nexus server, exposing a service and route while also creating the persistent volume needed. Have a read through the template; at the bottom you'll see a collection of parameters we will pass to the template.

2. Add some parameters for running the template by creating a new file in the params directory.

   touch params/nexus
   

3. The essential params to include in this file are:

   VOLUME_CAPACITY=5Gi
   MEMORY_LIMIT=1Gi
   

4. Create a new object in the inventory variables inventory/host_vars/ci-cd-tooling.yml called ci-cd-tooling and populate its content is as follows

---
ansible_connection: local
openshift_cluster_content:
- object: ci-cd-tooling
    content:
    - name: "nexus"
      namespace: "{{ ci_cd_namespace }}"
      template: "{{ playbook_dir }}/templates/nexus.yml"
      params: "{{ playbook_dir }}/params/nexus"
      tags:
      - nexus

1. Run the OpenShift applier, specifying the tag nexus to speed up its execution (-e target=tools is to run the other inventory).

   ansible-playbook apply.yml -e target=tools \
     -i inventory/ \
     -e "filter_tags=nexus"
   

2. Once successful; login to the cluster through the browser (using cluster URL) and navigate to the <YOUR_NAME>-ci-cd. You should see Nexus up and running. You can login with default credentials (admin / admin123)

3a - GitLab install

NOTE - This section may already have been completed for you, please check with your tutor. If this is the case, skip to section 3b "Commit CI/CD" below to add your code to GitLab.

1. Now let's do the same thing for GitLab to get it up and running. Checkout the template and params provided by running

   git checkout exercise1/git-nexus templates/gitlab.yml params/gitlab
   

   Explore the template; it contains the PVC, buildConfig and services. The DeploymentConfig is made up of these apps

   • Redis (3.2.3)
   • PostgreSQL (9.4)
   • GitLab CE (v10.2.3)

2. Open the params/gitlab file and complete the following params

   Note - The values here for the LDAP and BIND credentials will be provided by your tutor.

   LDAP_BIND_DN=uid=<BIND_USER>,ou=People,dc=<YOUR_DOMAIN>,dc=com
   LDAP_USER_FILTER=(memberof=CN=YourGroup,OU=Users,DC=<YOUR_DOMAIN>,DC=com)
   LDAP_PASSWORD=<BIND_USER_PASSWORD>
   LDAP_HOST=<LDAP_HOST>
   LDAP_BASE=ou=People,dc=<YOUR_DOMAIN>,dc=com
   LDAP_LABEL="<LDAP_DESCRIPTION>"
   GITLAB_ROOT_PASSWORD=<GITLAB_ROOT_USER_PASSWORD>
   GITLAB_DATA_VOL_SIZE=2Gi
   POSTGRESQL_VOL_SIZE=1Gi
   APPLICATION_HOSTNAME=<GITLAB_URL>
   NAMESPACE=<YOUR_NAME>-ci-cd
   

   where the following need to be replaced by actual values:

   • <BIND_USER> is the user used to query the LDAP
   • <BIND_USER_PASSWORD> is the password used when querying the LDAP
   • <YOUR_DOMAIN> is the domain the LDAP is hosted on
   • <LDAP_HOST> is fqdn of the LDAP server
   • <LDAP_DESCRIPTION> is the description to be used on the sign-in header for GitLab e.g. "Name LDAP Login"
   • <GITLAB_ROOT_USER_PASSWORD> is the root user for GOD access on the GitLab instance e.g. password123
   • <GITLAB_URL> is the endpoint for gitlab. It will take the form gitlab-<YOUR_NAME>-ci-cd.apps.<ENV_ID>.<YOUR_DOMAIN>.com

3. Create another object in the inventory inventory/host_vars/ci-cd-tooling.yml file to run the build & deploy of this template. Add the following and update the namespace: accordingly

    - name: "gitlab"
        namespace: "{{ ci_cd_namespace }}"
        template: "{{ playbook_dir }}/templates/gitlab.yml"
        params: "{{ playbook_dir }}/params/gitlab"
        tags:
        - gitlab
   

4. Run the OpenShift applier, specifying the tag gitlab to speed up its execution.

   ansible-playbook apply.yml -e target=tools \
     -i inventory/ \
     -e "filter_tags=gitlab"
   

5. Once successful; login to the cluster and navigate to the <YOUR_NAME>-ci-cd. You should see GitLab up and running.

3b - Commit CI/CD

1. Navigate to GitLab (if you have just skipped straight to this step; ask your tutor for the URL). You can login using your cluster credentials using the LDAP tab

1. Once logged in create a new project called enablement-ci-cd and mark it as internal. Once created; copy out the git url for use on the next step.

Note - we would not normally make the project under your name but create a group and add the project there on residency but for simplicity of the exercise we'll do that here

1. If you have not used Git before; you may need to tell Git who you are and what your email is before we commit. Run the following commands, substituting your email and "Your Name". If you've done this before move on to the next step.

   git config --global user.email "[email protected]"
   

   git config --global user.name "Your Name"
   

2. Commit your local project to this new remote by first removing the existing origin (github) where the Ansible project was cloned from in the first steps. Remember to substitute <GIT_URL> accordingly with the one created for your enablement-ci-cd repository a moment ago.

   git remote set-url origin <GIT_URL>
   

   git add .
   

   git commit -m "Adding git and nexus config"
   

   git push -u origin --all
   

In order to run our API tests in CI in later labs; we need there to be a MongoDB available for executing our tests. As this is part of our CI/CD Lifecycle; we will add it now.

1. In our enablement-ci-cd repo; checkout the mongo templates as shown below to bring in the template and params. The mongodb template we're using is the same as the one for our todolist-fe created in previous exercise.

   git checkout exercise1/mongodb params/mongodb templates/mongodb.yml
   

2. Open enablement-ci-cd in your favourite editor. Edit the inventory/host_vars/ci-cd-tooling.yml to include a new object for our mongodb as shown below. This item can be added below the Jenkins slave in the ci-cd-tooling section.

   - name: "jenkins-mongodb"
      namespace: "{{ ci_cd_namespace }}"
      template: "{{ playbook_dir }}/templates/mongodb.yml"
      params: "{{ playbook_dir }}/params/mongodb"
      tags:
      - mongodb
   

   

1. Git commit your updates to the inventory to git for traceability.

   git add .
   

   git commit -m "ADD - mongodb for use in the pipeline"
   

   git push
   

2. Apply this change as done previously using Ansible. The deployment can be validated by going to your <YOUR_NAME>-ci-cd namespace and checking if it is there!

   ansible-playbook apply.yml -e target=tools \
   -i inventory/ \
   -e "filter_tags=mongodb"
   

   

Note - When making changes to enablement-ci-cd you should frequently commit the changes to git.

Create a build and deployment config for Jenkins. Add new configuration and plugins to the OCP Stock Jenkins using s2i

1. Add the Jenkins Build & Deployment configs to the enablement-ci-cd repo by merging the contents exercise1/jenkins in

   git checkout exercise1/jenkins templates/jenkins.yml
   

   The Jenkins template is essentially the standard persistent Jenkins one with OpenShift.

2. As before; create a new set of params by creating a params/jenkins file and adding some overrides to the template and updating the <YOUR_NAME> value accordingly.

   MEMORY_LIMIT=3Gi
   VOLUME_CAPACITY=10Gi
   JVM_ARCH=x86_64
   NAMESPACE=<YOUR_NAME>-ci-cd
   JENKINS_OPTS=--sessionTimeout=720
   

3. Add a jenkins variable to the Ansible inventory underneath the jenkins-mongo (and git if you have it) in inventory/host_vars/ci-cd-tooling.yml.

    - name: "jenkins"
      namespace: "{{ ci_cd_namespace }}"
      template: "{{ playbook_dir }}/templates/jenkins.yml"
      params: "{{ playbook_dir }}/params/jenkins"
      tags:
      - jenkins
   

   This configuration, if applied now, will create the deployment configuration needed for Jenkins but the ${NAMESPACE}:${JENKINS_IMAGE_STREAM_TAG} in the template won't exist yet.

4. To create this image we will take the supported OpenShift Jenkins Image and bake into it some extra configuration using an s2i builder image. More information on Jenkins s2i is found on the openshift/jenkins GitHub page. To create an s2i configuration for Jenkins, check out the pre-canned configuration source in the enablement-ci-cd repo

   git checkout exercise1/jenkins-s2i jenkins-s2i
   

   The structure of the Jenkins s2i config is

   jenkins-s2i
   ├── README.md
   ├── configuration
   │   ├── build-failure-analyzer.xml
   │   ├── init.groovy
   │   ├── jenkins.plugins.slack.SlackNotifier.xml
   │   ├── scriptApproval.xml
   │   └── jobs
   │       └── seed-multibranch-job
   │           └── config.xml
   └── plugins.txt
   

   • plugins.txt is a list of pluginId:version for Jenkins to pre-install when starting
   • ./configuration contains content that is placed in ${JENKINS_HOME}. A config.xml could be placed in here to control the bulk of Jenkins configuration.
   • ./configuration/jobs/* contains job names and xml config that jenkins loads when starting. The seed job in there we will return to in later lessons.
   • build-failure-analyzer.xml is config for the plugin to read the logs and look for key items based on a Regex. More on this in later lessons.
   • init.groovy contains a collection of settings jenkins configures itself with when launching

5. Let's add a plugin for Jenkins to be started with, green-balls. This simply changes the default SUCCESS status of Jenkins from Blue to Green. Append the jenkins-s2i/plugins.txt file with

   greenballs:1.15
   

   

Why does Jenkins have Blue Balls? More can be found on reddit or the jenkins blog

1. Before building and deploying the Jenkins s2i; add git credentials to it. These will be used by Jenkins to access the Git Repositories where our apps will be stored. We want Jenkins to be able to push tags to it so write access is required. There are a few ways we can do this; either adding them to the template/jenkins.yml as environment Variables and then including them in the params/jenkins file. We could also create a token in GitLab and use it as the source secret in the Jenkins template. But for simplicity just replace the <USERNAME> && <PASSWORD> in the jenkins-s2i/configuration/init.groovy with your LDAP credentials as seen below. This init file gets run when Jenkins launches and will setup the credentials for use in our Jobs in the next exercises

   gitUsername = System.getenv("GIT_USERNAME") ?: "<USERNAME>"
   gitPassword = System.getenv("GIT_PASSWORD") ?: "<PASSWORD>"
   

   Note in a residency we would not use your GitCredentials for pushing and pulling from Git, a service user would be created for this.

2. Checkout the params and the templates for the jenkins-s2i

   git checkout exercise1/jenkins-s2i params/jenkins-s2i templates/jenkins-s2i.yml
   

3. Open params/jenkins-s2i and add the following content; replacing variables as appropriate.

   SOURCE_REPOSITORY_URL=<GIT_URL>
   NAME=jenkins
   SOURCE_REPOSITORY_CONTEXT_DIR=jenkins-s2i
   IMAGE_STREAM_NAMESPACE=<YOUR_NAME>-ci-cd
   SOURCE_REPOSITORY_USERNAME=<YOUR_LDAP_USERNAME>
   SOURCE_REPOSITORY_PASSWORD=<YOUR_LDAP_PASSWORD>
   

   where

   • <GIT_URL> is the full clone path of the repo where this project is stored (including the https && .git)
   • <YOUR_NAME> is the prefix for your -ci-cd project.
   • Explore some of the other parameters in templates/jenkins-s2i.yml
   • <YOUR_LDAP_USERNAME> is the username builder pod will use to login and clone the repo with
   • <YOUR_LDAP_PASSWORD> is the password the builder pod will use to authenticate and clone the repo using

     Note in a residency we would not use your GitCredentials for pushing and pulling from Git, A service user would be created or a token generated.

4. Create a new object ci-cd-builds in the Ansible inventory/host_vars/ci-cd-tooling.yml to drive the s2i build configuration.

   - object: ci-cd-builds
      content:
      - name: "jenkins-s2i"
        namespace: "{{ ci_cd_namespace }}"
        template: "{{ playbook_dir }}/templates/jenkins-s2i.yml"
        params: "{{ playbook_dir }}/params/jenkins-s2i"
        tags:
        - jenkins
   

5. Commit your code to your GitLab instance

   git add .
   

   git commit -m "Adding Jenkins and Jenkins s2i"
   

   git push
   

6. In order for Jenkins to be able to run npm builds and installs we must configure a jenkins-build-slave for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. These slaves can take a time to build themselves so to speed up we have placed the slave within OpenShift and you can use the following commands to be able to use them in your project.

   oc project <YOUR_NAME>-ci-cd
   

   oc tag openshift/jenkins-slave-npm:latest jenkins-slave-npm:latest
   

   oc label is jenkins-slave-npm role=jenkins-slave
   

   This is pulling the container image into your namespace and then adding a label which will allow Jenkins to take notice of it. Don't worry if the label is already there and this last command fails!

7. Now your code is commited, and you have bought in the Jenkins slave; run the OpenShift Applier to add the config to the cluster

   ansible-playbook apply.yml -e target=tools \
     -i inventory/ \
     -e "filter_tags=jenkins"
   

8. This will trigger a build of the s2i and when it's complete it will add an imagestream of <YOUR_NAME>-ci-cd/jenkins:latest to the project. The Deployment config should kick in and deploy the image once it arrives. You can follow the build of the s2i by going to the OpenShift console's project

1. When the Jenkins deployment has completed; login (using your OpenShift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job

To test things are working end-to-end; create a hello world job that doesn't do much but proves we can pull code from git and that our balls are green.

1. Log in to Jenkins and hit New Item.

1. Create a freestyle job called hello-world.

1. On the Source Code Management tab; add your enablement-ci-cd git repo and hit the dropdown to add your credentials we baked into the s2i on previous steps.

1. On the build tab add an Execute Shell step and fill it with echo "Hello World".

1. Run the build and we should see if pass successfully and with Green Balls!

In this section you will prove the infra as code is working by deleting your Cluster Content and recreating it all

1. Commit your code to the new repo in GitLab

   git add .
   

   git commit -m "ADD - all ci/cd contents"
   

   git push
   

2. Burn your OCP content to the ground

   oc delete project <YOUR_NAME>-ci-cd
   

   oc delete project <YOUR_NAME>-dev
   

   oc delete project <YOUR_NAME>-test
   

3. Check to see the projects that were marked for deletion are removed.

   oc get projects | egrep '<YOUR_NAME>-ci-cd|<YOUR_NAME>-dev|<YOUR_NAME>-test'
   

4. Re-apply the inventory to re-create it all!

   oc login <OCP URL PROVIDED DURING ENABLEMENT>
   

   ansible-playbook apply.yml -i inventory/ -e target=bootstrap
   

   ansible-playbook apply.yml -i inventory/ -e target=tools
   

Extension Tasks

Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution and are provided for additional scope.

• Install Cowsay for 100% more Ansible Fun!
• Add more secure access for Nexus (ie not admin / admin123) using the automation to drive secret creation
• Add a SonarQube persistent deployment to the ci-cd-deployments section.
• Add jenkins.plugins.slack.SlackNotifier.xml to jenkins-s2i/configuration to include URL of Slack for team build notifications and rebuild Jenkins S2I

Additional Reading

List of links or other reading that might be of use / reference for the exercise

Slide links

• Intro
• Wrap-up
• All Material