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
 
(39 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
* https://github.com/openshift/origin/blob/master/examples/jenkins/README.md
=Internal=
=Internal=


* [[OpenShift_CI/CD_Operations#Set_Up_a_Jenkins_CI.2FCD_Pipeline|OpenShift CI/CD Operations]]
* [[OpenShift_CI/CD_Concepts#Collocated_Jenkins|OpenShift CI/CD Concepts]]
 
{{Error|TO REMOVE}}


=Overview=
=Overview=


This is the procedure to install a CI/CD pipeline based on Jenkins. The CI/CD pipeline will execute in the project that need CI/CD services: the Jenkins pod will be created in the same project it triggers builds and deployments for.
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
 
[[OpenShift_PersistentVolume_Operations#Create_a_NFS_Persistent_Volume|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 \
  -p MEMORY_LIMIT=1Gi \
  -e INSTALL_PLUGINS=analysis-core:1.92,findbugs:4.71,pmd:3.49,checkstyle:3.49,dependency-check-jenkins-plugin:2.1.1,htmlpublisher:1.14,jacoco:2.2.1,analysis-collector:1.52 \
  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_Concepts#Security_Considerations|OpenShift CI/CD Security Considerations]].
 
Various configuration adjustments can be performed after installation:
 
====Adjust Readiness Probe Timeout====
 
  [[Oc_set#probe|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|oc set resources]] dc/jenkins --limits=memory=3Gi


The pipeline is created based on the OpenShift "jenkins-persistent" template, available in the "openshift" project:
=Deploy a Sample Application=


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


NAME                  DESCRIPTION                                    PARAMETERS      OBJECTS
If can be downloaded locally, inspected, edited, and then instantiated:
...
jenkins-persistent    Jenkins service, with persistent storage....  8 (all set)      7


new-app procedure will create a special service account for Jenkins ("system:service account:<''project-name''>:jenkins") and it will give it the appropriate roles (/edit).
oc new-app -f ./application-template.json


More details about Jenkins security considerations:
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.


{{Internal|Jenkins_and_OpenShift#Security_Considerations|Jenkins Security Considerations}}
=Configure a Jenkins Project=


=Provision a Persistent Volume=
New Item -> Freestyle project -> "os3-jenkins-example" -> Save.


"jenkins-persistent" requires a persistent volume, which must be provisioned before the installation.
Source Code Management: None.


{{Internal|OpenShift_PersistentVolume_Operations#Overview|Persistent Volume Operations}}
Build:


=Create Jenkins Components=
* Scale OpenShift Deployment:


{{External|https://github.com/openshift/origin/blob/master/examples/jenkins/README.md}}
Then name of the DeploymentConfig to scale: frontend


Jenkins instance won't be integrated into the OAuth infrastructure, so authentication must be done independently (admin/password).
The number of replicas to scale the deployment to: 0


Make sure to specify a volume capacity in sync with the capacity of the persistent volume that was provisioned for Jenkins.
Verify whether the specified number of replicas are up: No


oc new-app jenkins-persistent -p MEMORY_LIMIT=2Gi -p VOLUME_CAPACITY=2Gi -p ENABLE_OAUTH=false
* Trigger OpenShift Build


Successful run output:
The name of the BuildConfig to trigger: frontend


<pre>
* Trigger OpenShift Deployment
--> Deploying template "openshift/jenkins-persistent" to project lab7


    Jenkins (Persistent)
The name of the DeploymentConfig to trigger a deployment of: frontend
    ---------
    Jenkins service, with persistent storage.


    NOTE: You must have persistent volumes available in your cluster to use this template.
* Verify OpenShift Service


    A Jenkins service has been created in your project.  Log into Jenkins with your OpenShift account.  The tutorial at https://github.com/openshift/origin/blob/master/examples/jenkins/README.md contains more information about using this template.
The name of the Service to verify: frontend


    * With parameters:
* Tag OpenShift Image
        * Jenkins Service Name=jenkins
        * Jenkins JNLP Service Name=jenkins-jnlp
        * Enable OAuth in Jenkins=false
        * Jenkins JVM Architecture=i386
        * Memory Limit=1Gi
        * Volume Capacity=2Gi
        * Jenkins ImageStream Namespace=openshift
        * Jenkins ImageStreamTag=jenkins:latest


--> Creating resources ...
The name of the ImageStream for the current image tag: origin-nodejs-sample
    route "jenkins" created
    persistentvolumeclaim "jenkins" created
    deploymentconfig "jenkins" created
    serviceaccount "jenkins" created
    rolebinding "jenkins_edit" created
    service "jenkins-jnlp" created
    service "jenkins" created
--> Success
    Run 'oc status' to view your app.
</pre>


=Post-Install Adjustments=
The name of the current image tag or actual image ID: latest


==Adjust Readiness Probe Timeout==
The name of the ImageStream for the new image tag: origin-nodejs-sample


  [[Oc_set#probe|oc set probe]] dc jenkins --readiness --initial-delay-seconds=500
The name of the new image tag: prod


The same effect can be achieved with
* Verify OpenShift Deployment:


oc edit dc/jenkins
The name of the DeploymentConfig to validate: frontend-prod


and changing spec/template/spec/containers/name=jenkins/livenessProbe/initialDelaySeconds
The number of replicas you expect the deployment to scale to: 1


==Adjust Memory==
Save


[[Oc_set#resources|oc set resources]] dc/jenkins --limits=memory=3Gi
=Build=


=Verification=
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).


Access the UI at https://jenkins-lab7.apps.openshift.novaordis.io and log in with admin/password.
=Use of Kubernetes Plugin=


For causes not yet elucidated yet, the Jenkins pod had to be deleted upon the first deployment - and thus a redeployment be triggered - in order to become accessible.
<font color=red>


=Configure the Jenkins Pipeline=
The Jenkins instance was used so far without a [[OpenShift_CI/CD_Concepts#Kubernetes_Plugin|Kubernetes plugin]]. This means <font color=red>?what?</font>.


{{Internal|OpenShift_CI/CD_Operations#Configure_the_Jenkins_Pipeline|Configure the Jenkins Pipeline}}
</font>

Latest revision as of 18:34, 12 December 2017

External

Internal


TO REMOVE

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 \
  -p MEMORY_LIMIT=1Gi \
  -e INSTALL_PLUGINS=analysis-core:1.92,findbugs:4.71,pmd:3.49,checkstyle:3.49,dependency-check-jenkins-plugin:2.1.1,htmlpublisher:1.14,jacoco:2.2.1,analysis-collector:1.52 \
 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).

Use of Kubernetes Plugin

The Jenkins instance was used so far without a Kubernetes plugin. This means ?what?.