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
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:
State Persistence Considerations
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 ***'
}
}