OpenShift CI/CD Operations - Collocated Persistent Jenkins Set Up: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
Line 107: Line 107:
=Build=
=Build=


The build should result in a "frontend" and a "frontend-prod" being deployed and running (for the "prod" pod, the route must be created manually).
The build should trigger an OpenShift build of the application, wait for the build to result in a deployment, confirm that the new deployment works, and then tag the image for production.
Tagging the image will trigger the production deployment, which was configured in dc/frontend-prod. In the end, we should get a "frontend" and a "frontend-prod" being deployed and running (for the "prod" pod, the route must be created manually).

Revision as of 23:47, 28 November 2017

External

Internal

Overview

This is the procedure to deploy a persistent Jenkins instance in the same project as the application that intends to use it, and configure it to build and deploy the application.

Pre-Requisites

Create the project to host the Jenkins instance and the application instance:

oc new-project os3-jenkins-example

Provision a 2Gi persistent volume to be used by Jenkins.

Verify that the persistent Jenkins template is available.

 oc get template/jenkins-persistent -n openshift

Deploy Persistent Jenkins

oc new-app -p VOLUME_CAPACITY=2Gi jenkins-persistent

By default, the template enables OAuth integration.

After the deployment completes, you should be left with a Jenkins pod that can be accessed with the public URL https://jenkins-os3-jenkins-example.apps.openshift.novaordis.io, using OpenShift credentials, since OAuth integration is supposed to be active.

The installation procedure should have created a "system:serviceaccount:os3-jenkins-example:jenkins" service account and given it the "edit" role. Jenkins will authenticate as "system:serviceaccount:os3-jenkins-example:jenkins" to the OpenShift master and will need these permissions to perform its functions. For more security details, see OpenShift CI/CD Security Considerations.

Various configuration adjustments can be performed after installation:

Adjust Readiness Probe Timeout

 oc set probe dc jenkins --readiness --initial-delay-seconds=500

The same effect can be achieved with

oc edit dc/jenkins

and changing spec/template/spec/containers/name=jenkins/livenessProbe/initialDelaySeconds

Adjust Memory

oc set resources dc/jenkins --limits=memory=3Gi

Deploy a Sample Application

This is a standard node.js HelloWorld OpenShift example: https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/application-template.json

If can be downloaded locally, inspected, edited, and then instantiated:

oc new-app -f ./application-template.json

Without additional configuration, the application will create all OpenShift objects required to do a source-to-image build and to deploy and expose the final artifact as https://nodejs-helloworld-sample-os3-jenkins-example.apps.openshift.novaordis.io. However, neither the build nor the deployment start automatically, as the application "expects" its release procedure to be driven by Jenkins.

Configure a Jenkins Project

New Item -> Freestyle project -> "os3-jenkins-example" -> Save.

Source Code Management: None.

Build:

  • Scale OpenShift Deployment:

Then name of the DeploymentConfig to scale: frontend

The number of replicas to scale the deployment to: 0

Verify whether the specified number of replicas are up: No

  • Trigger OpenShift Build

The name of the BuildConfig to trigger: frontend

  • Trigger OpenShift Deployment

The name of the DeploymentConfig to trigger a deployment of: frontend

  • Verify OpenShift Service

The name of the Service to verify: frontend

  • Tag OpenShift Image

The name of the ImageStream for the current image tag: origin-nodejs-sample

The name of the current image tag or actual image ID: latest

The name of the ImageStream for the new image tag: origin-nodejs-sample

The name of the new image tag: prod

  • Verify OpenShift Deployment:

The name of the DeploymentConfig to validate: frontend-prod

The number of replicas you expect the deployment to scale to: 1

Save

Build

The build should trigger an OpenShift build of the application, wait for the build to result in a deployment, confirm that the new deployment works, and then tag the image for production. Tagging the image will trigger the production deployment, which was configured in dc/frontend-prod. In the end, we should get a "frontend" and a "frontend-prod" being deployed and running (for the "prod" pod, the route must be created manually).