OpenShift CI/CD Concepts

External

• https://blog.openshift.com/cicd-with-openshift/, youtu.be demos: 65BnTLcDAJI, wSFyg6Etwx8
• https://github.com/OpenShiftDemos/openshift-cd-demo, https://github.com/OpenShiftDemos/openshift-cd-demo/tree/ocp-3.5
• https://docs.openshift.com/container-platform/3.6/install_config/configuring_pipeline_execution.html
• https://github.com/openshift/jenkins

Internal

• Jenkins
• OpenShift Concepts
• OpenShift CI/CD Operations

Overview

OpenShift provides a certified Jenkins container for building Continuous Delivery pipelines. When necessary, it scales the pipeline execution by on-demand provisioning of multiple Jenkins containers, allowing Jenkins to run many jobs in parallel.

Resources

This is the memory consumption based on a test installation:

• jenkins/jenkins-jnlp pod: 720 MB
• nexus pod: 610 MB
• gogs pod: 110 MB

Jenkins Pods and Projects

Jenkins infrastructure can run in an arbitrary project, on a per-project basis, but a more common setup is to create a dedicated CI/CD project and configure it to perform CI/CD services for other "client" projects.

Security Considerations

Jenkins components need to access the OpenShift API exposed by the master for various operations: to access container images, to trigger a build, to check the status of a build, etc. so special privileges need to be assigned to the service account under whose credentials Jenkins runs. Jenkins authenticates to the API using the "system:serviceaccount:<project-name>:default service account, where <project-name> is the name of the project the Jenkins pod runs in. The service account must be granted the "admin" role:

oc policy add-role-to-user admin system:serviceaccount:<jenkins-project-name>:default

"default" is a generic account, so in general is a good idea to created a dedicated "jenkins" service account, to be used by the Jenkins processes: "system:serviceaccount:<project-name>:jenkins.

oc policy add-role-to-user admin system:serviceaccount:<jenkins-project-name>:jenkins

Jenkins performs CI/CD services for other projects, so the service account running the Jenkins pods in the Jenkins project must be granted elevated privileges in the projects serviced by it:

oc policy add-role-to-user edit system:serviceaccount:<jenkins-project-name>:jenkins -n <client-project>

To list the roles associated with a service account, use oc get rolebindings or oc describe policyBindings.

Also see:

Grant Jenkins Needed Privileges for the Projects that Require CI/CD Services

Pipeline Definition

Jenkins drives the pipeline, so the pipeline is defined in Jenkins, but it uses OpenShift to perform the build and the deployment, by invoking OpenShift API:

node {

 stage ("Build") {
   ...
   openshiftBuild apiURL: 'https://openshift.default.svc.cluster.local', 
                  authToken: , bldCfg: 'hello-nodejs', buildName: , checkForTriggeredDeployments: 'false', commitID: , namespace: , showBuildLogs: 'false', verbose: 'false', waitTime: 
   openshiftVerifyBuild apiURL: 'https://openshift.default.svc.cluster.local', authToken: , bldCfg: 'hello-nodejs', checkForTriggeredDeployments: 'false', namespace: , verbose: 'false'
   echo '*** Build Complete ***'
 }
 stage ("Deploy") {
   echo '*** Deployment Starting ***'
   openshiftDeploy apiURL: 'https://openshift.default.svc.cluster.local', authToken: , depCfg: 'hello-nodejs', namespace: , verbose: 'false', waitTime: 
   openshiftVerifyDeployment apiURL: 'https://openshift.default.svc.cluster.local', authToken: , depCfg: 'hello-nodejs', namespace: , replicaCount: '1', verbose: 'false', verifyReplicaCount: 'false', waitTime: 
   echo '*** Deployment Complete ***'
 }
 stage ("Verify") {
   echo '*** Service Verification Starting ***'
   openshiftVerifyService apiURL: 'https://openshift.default.svc.cluster.local', authToken: , namespace: , svcName: 'hello-nodejs', verbose: 'false'
   echo '*** Service Verification Complete ***'
 }

}