Open Innovation Labs CI/CD
🏁 No Longer Being Maintained 🌇
This project is being deprecated and will no longer receive updates or contributions. OpenShift has moved on to version 4.x and this project was a great enabler for kick starting development of applications on OpenShift 3.x. The tools of DevOps have evolved and grown towards a GitOps approach and so the evolution of Labs CI/CD has moved that way too.
For this teams new approach to tooling and automation checkout these two repositories:
What's in the box?
This project is an Ansible inventory for loading an OpenShift cluster with some frequently used projects, apps and tools on a Red Hat Open Innovation Lab residencies. Using the
openshift-applier, cluster content is loaded from templates and param files in a repeatable, config-as-code way.
Running this Ansible inventory will first create three project namespaces:
labs-test. Subsequently it will create a bunch of commonly used
ci-cd-tools such as Jenkins, Nexus and Sonar. It will also create a collection of
jenkins-slaves that can be used in builds such as
golang to name a few. Apps can be added also by applying their
Jenkinsfile as a buildConfig with an example (java-app) is included as a reference.
How it Works
The layout of the project is like most standard
ansible-playbooks with a simplified view of the key parts shown below:
. ├── site.yml ├── requirements.yml ├── inventory │ ├── group_vars │ │ └── all.yml │ ├── host_vars │ | └── ... │ └── hosts ├── params │ └── jenkins-slaves │ └── ** ├── secrets │ └── ...
site.ymlis a playbook that sets up some variables and drives the
requirements.ymlis a manifest which contains the Ansible modules needed to run the playbook
inventory/host_vars/*.ymlis the collection of objects we want to insert into the cluster written according to the convention defined by the openshift-applier role.
inventory/hostsis where the
targetsare defined for grouping of the various inventories to be run eg
bootsrapfor creating projects and roles bindings
paramsis a set of parameter files to be processed along with their respective OpenShift template. The convention here is to group files by their application.
The Ansible layer is very thin; it simply provides a way to orchestrate the application of OpenShift templates across one or more OpenShift projects. All configuration for the applications should be defined by an OpenShift template and the corresponding parameters file.
There are multiple Ansible inventories which divide the type of components to be built and deployed to an OpenShift cluster. These are broken down into three sections:
bootstrap- Located in
inventory/host_vars/projects-and-policies.ymlcontains a collection of objects used to create project namespaces and bind roles to groups for those namespace in OpenShift
tools- Located in
inventory/host_vars/ci-cd-tooling.ymlcontains the collection of Jenkins slaves, Jenkins S2I and other CI/CD tooling deployments such as SonarQube, Nexus and others.
apps- Located in
inventory/host_vars/app-build-deploy.ymlcontains definitions for the Java reference app's build and deploy
- Ansible 2.5 or above.
- OpenShift CLI Tools
- Access to the OpenShift cluster (Your user needs permissions to deploy ProjectRequest objects)
- libselinux-python (only needed on Fedora, RHEL, and CentOS)
- Install by running
yum install libselinux-python.
- Install by running
It should be noted that non-docker executions will utilize the inventory directory included in this repo by default. If you would like to specify a custom inventory for any of the below tasks, you can do so by adding
-i /path/to/my/inventory to the command
- Log on to an OpenShift server
oc login -u <user> https://<server>:<port>/
- Clone this repository.
- Install the required openshift-applier dependency:
ansible-galaxy install -r requirements.yml --roles-path=roles
- To deploy everything please run:
labs-ci-cd already exists on your OpenShift cluster and you want to create a new instance of
labs-ci-cd with its own name eg
john-ci-cd, run the "unique projects" playbook. This playbook is useful if you're developing labs-ci-cd and want to test your changes. With a unique project name, you can safely try out your changes in a test cluster that others are using.
ansible-playbook site.yml -e ci_cd_namespace=another-ci-cd -e dev_namespace=another-dev -e test_namespace=another-test
Or please look here for other variables you can change.
- Only numbers, lowercase letters, and dashes are allowed in project names.
After running the playbook, the pipeline should execute in Jenkins, build the spring boot app, deploy artifacts to nexus, deploy the container to the dev stage and then wait approval to deploy to the demo stage. See Common Issues
Persistent vs Ephemeral Jenkins
labs-ci-cd will default to deploying a persistent Jenkins, if you do not wish to use persistent jenkins please add on the extra variable
jenkins_persistence_type and set it to
ephemeral For Example:
ansible-playbook site.yml -e jenkins_persistence_type=ephemeral
Running a Subset of the Inventory
In some cases you might not want to deploy all of the components in this repo; but only a subset such as Jenkins and the customisations to it.
- See the docs in the openshift-applier repo.
- The only required tag to deploy objects within the inventory is projects, all other tags are optional
- Here is an example that runs the tags that provision projects, ci, and jenkins objects:
ansible-playbook site.yml \ -e "include_tags=jenkins,ci,projects"
Scope and Direction
The goal of this repository is to:
- Bootstrap Labs residencies will all the tools necessary for a comprehensive, OpenShift native CI/CD pipeline
- Serve as a reference implementation of the openshift-applier model for Infrastructure-as-Code (IaC)
A few additional guiding principles:
- This repository is built to ensure all the individual components are integrated and can be deployed together.
- It is likely that your residency will need to remove some components in this inventory and then add others. Thus, every residency team is encouraged to create a fork of this repo and modify to their needs. A few things to consider for your fork:
- Generally speaking, there should only be one tool per functional use case e.g. Sonatype Nexus is the artifact repository so we will not support JFrog Artifactory
- Fork the repo and open PR's
- Add all new components to the inventory with appropriate namespaces and tags
- Extended the
Jenkinsfilewith steps to verify that your components built/deployed correctly
- For now, it is your responsibility to run the CI job. Please contact an admin for the details to set the CI job up.
tests/slaves/Jenkinsfilegets run as part of CI and will spin up a new Jenkins instance from this repositories code and validate each of the provided slaves can be accessed and contain their expected binary on the path.
- Issues with valid nexus certs like seen here. You can set the ansible variable
nexus_validate_certs: falseas a work around.
- S2I Build fails to push image to registry with
error: build error: Failed to push image: unauthorized: authentication required. See this issue