OpenShift CI/CD Concepts: Difference between revisions
| Line 31: | Line 31: | ||
=Security Considerations= | =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 [[OpenShift_Security_Concepts#Service_Account|service account]], where <''project-name''> is the name of the project the Jenkins pod runs in. The service account must be granted the " | 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 [[OpenShift_Security_Concepts#Service_Account|service account]], where <''project-name''> is the name of the project the Jenkins pod runs in. The service account must be granted the "edit" role: | ||
oc policy add-role-to-user | oc policy add-role-to-user edit 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. | "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. | ||
Also see: {{Internal|OpenShift_CI/CD_Operations#Grant_Jenkins_Needed_Privileges_for_the_Projects_that_Require_CI.2FCD_Services|Grant Jenkins Needed Privileges for the Projects that Require CI/CD Services}} | |||
Revision as of 21:41, 21 November 2017
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
Projects and Jenkins Pods
Does Jenkins needs its own project, or it can be spun off in an arbitrary project?
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 "edit" role:
oc policy add-role-to-user edit 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.
Also see: