| | |
|---|
| | | # The Manual Menace |
|---|
| | | > In this exercise learners will use Ansible to drive automated provisioning of Projects in Openshift, Git, Jenkins and Nexus. |
|---|
| | | > In this exercise learners will use Ansible to drive automated provisioning of Projects in OpenShift, Git, Jenkins and Nexus. |
|---|
| | | |
|---|
| | |  |
|---|
| | | |
|---|
| | | ## Exercise Intro |
|---|
| | | In this exercise we will use automation tooling to create Project namespaces for our `CI/CD` tooling along with the `dev` and `test` namespaces for our deployments to live. We do this to manually using the OpenShift CLI; but as we go from cluster to cluster or project to project Dev and Ops teams often find themselves having to redo these tasks again and again. Configuring our cluster using code; we can easily store this in Git and repeat the process again and again. By minimising the time taken to do these repetitive tasks we can accelerate our ability to deliver value to our customers; working on the hard problems they face. |
|---|
| | | In this exercise we will use automation tooling to create Project namespaces for our `CI/CD` tooling along with the `dev` and `test` namespaces for our deployments to live. We do this manually using the OpenShift CLI; but as we go from cluster to cluster or project to project Dev and Ops teams often find themselves having to redo these tasks again and again. Configuring our cluster using code; we can easily store this in Git and repeat the process again and again. By minimising the time taken to do these repetitive tasks we can accelerate our ability to deliver value to our customers; working on the hard problems they face. |
|---|
| | | |
|---|
| | | This exercise uses Ansible to drive the creation of the cluster content. In particular; we'll use a play book called the `OpenShift Applier`. Once the project namespace have been created; we will add some tools to support CI/CD such as Jenkins, Git and Nexus. These tools will be needed by later lessons to automate the build and deploy of our apps. Again; we will use OpenShift Templates and drive their creation in the cluster using Ansible. To prove things are working, finally we'll delete all our content and re-apply the inventory to re-create our clusters content. |
|---|
| | | This exercise uses Ansible to drive the creation of the cluster content. In particular; we'll use a play book called the `OpenShift Applier`. Once the project namespace have been created; we will add some tools to support CI/CD such as Jenkins, Git and Nexus. These tools will be needed by later lessons to automate the build and deploy of our apps. Again; we will use OpenShift Templates and drive their creation in the cluster using Ansible. To prove things are working, finally we'll delete all our content and re-apply the inventory to re-create our cluster's content. |
|---|
| | | |
|---|
| | | #### Why is config-as-code important? |
|---|
| | | #### Why is config-as-code important? |
|---|
| | | * Assurance - Prevents unwanted config changes from people making arbitrary changes to environments. No more Snowflake servers! |
|---|
| | | * Traceability - Commiting config as code means a user has approved and changes can be tracked. |
|---|
| | | * Traceability - Committing config as code means a user has approved and changes can be tracked. |
|---|
| | | * Phoenix Server - Burn it all to the ground and bring it back; exactly the way it was! |
|---|
| | | |
|---|
| | | _____ |
|---|
| | |
|---|
| | | * [Ansible](https://www.ansible.com/) - IT Automation tool used to provision and manage state of cloud and physical infrastructure. |
|---|
| | | * [OpenShift Applier](https://github.com/redhat-cop/openshift-applier) - used to apply OpenShift objects to an OpenShift Cluster. |
|---|
| | | |
|---|
| | | |
|---|
| | | ## Big Picture |
|---|
| | | > The Big Picture is our emerging architecture; starting with an empty cluser we populate it with projects and some ci/cd tooling. |
|---|
| | | > The Big Picture is our emerging architecture; starting with an empty cluster we populate it with projects and some ci/cd tooling. |
|---|
| | | |
|---|
| | |  |
|---|
| | |  |
|---|
| | | |
|---|
| | | _____ |
|---|
| | | |
|---|
| | | ## 10,000 Ft View |
|---|
| | | > This exercise is aimed at the creation of the tooling that will be used to support the rest of the Exercises. The highlevel goal is to create a collection of project namespaces and populate them with Git, Jenkins & Nexus. |
|---|
| | | > This exercise is aimed at the creation of the tooling that will be used to support the rest of the Exercises. The high-level goal is to create a collection of project namespaces and populate them with Git, Jenkins & Nexus. |
|---|
| | | |
|---|
| | | If you're feeling confident and don't want to follow the step-by-step guide these highlevel instructions should provide a challenge for you: |
|---|
| | | If you're feeling confident and don't want to follow the step-by-step guide these high-level instructions should provide a challenge for you: |
|---|
| | | |
|---|
| | | 2. Clone the repo `https://github.com/rht-labs/enablement-ci-cd` which contains the scaffold of the project. Ensure you get all remote branches. |
|---|
| | | 1. Clone the repo `https://github.com/rht-labs/enablement-ci-cd` which contains the scaffold of the project. Ensure you get all remote branches. |
|---|
| | | |
|---|
| | | 2. Create `<your-name>-ci-cd`, `<your-name>-dev` and `<your-name>-test` project namespaces using the inventory and run them with the OpenShift Applier to populate the cluster |
|---|
| | | |
|---|
| | | 2. Use the templates provided to create build of the jenkins-s2i. The templates are in `exercise1/jenkins-s2i` |
|---|
| | | 3. Use the templates provided to create build of the jenkins-s2i. The templates are in `exercise1/jenkins-s2i` |
|---|
| | | |
|---|
| | | 2. Use the templates provided to create build and deployment configs in `<your-name>-ci-cd` for. Templates are on a branch called `exercise1/git-nexus` && `exercise1/jenkins`: |
|---|
| | | 4. Use the templates provided to create build and deployment configs in `<your-name>-ci-cd` for. Templates are on a branch called `exercise1/git-nexus` && `exercise1/jenkins`: |
|---|
| | | * Nexus |
|---|
| | | * GitLab |
|---|
| | | * Jenkins (using an s2i to pre-configure jenkins) |
|---|
| | | * Jenkins (using an s2i to pre-configure Jenkins) |
|---|
| | | |
|---|
| | | 2. Commit your `enablement-ci-cd` repository to the GitLab Instance you've created |
|---|
| | | 5. Commit your `enablement-ci-cd` repository to the GitLab Instance you've created |
|---|
| | | |
|---|
| | | 2. Burn it all down and re-apply your inventory proving config-as-code works. |
|---|
| | | 6. Burn it all down and re-apply your inventory proving config-as-code works. |
|---|
| | | |
|---|
| | | ## Step by Step Instructions |
|---|
| | | > This is a structured guide with references to exact filenames and explanations. |
|---|
| | |
|---|
| | | * `requirements.yml` is a manifest which contains the ansible modules needed to run the playbook |
|---|
| | | * `apply.yml` is a playbook that sets up some variables and runs the OpenShift Applier role. |
|---|
| | | |
|---|
| | | 3. Open the `apply.yml` file in the root of the project. Update the namespace variables by replacing the `<YOUR_NAME>` with your name or initials. Don't use uppercase or special characters. For example; my name is Dónal so I've created: |
|---|
| | | 3. Open the `apply.yml` file in the root of the project. Update the namespace variables by replacing the `<YOUR_NAME>` with your name or initials. Don't use uppercase or special characters. For example; my name is Dónal so I've created: |
|---|
| | | ```yaml |
|---|
| | | hosts: "{{ target }}" |
|---|
| | | vars: |
|---|
| | |
|---|
| | | |
|---|
| | | 3. Open the `inventory/host_vars/projects-and-policies.yml` file; you should see some variables setup already to create the `<YOUR_NAME>-ci-cd` namespace. This object is passed to the OpenShift Applier to call the `templates/project-requests.yml` template with the `params/project-requests-ci-cd` parameters. We will add some additional content here but first let's explore the parameters and the template |
|---|
| | | |
|---|
| | | 3. Open the `params/project-requests-ci-cd` and replace the `<YOUR_NAME>` with your name to create the correstponding projects in the cluster. |
|---|
| | | 3. Open the `params/project-requests-ci-cd` and replace the `<YOUR_NAME>` with your name to create the corresponding projects in the cluster. |
|---|
| | |  |
|---|
| | | |
|---|
| | | 3. Let's add two more param files to pass to our template to be able to create a `dev` and `test` project. |
|---|
| | | * Create another two params files `params/project-requests-dev` & `params/project-requests-test`. On the terminal run |
|---|
| | | 3. Let's add two more params files to pass to our template to be able to create a `dev` and `test` project. |
|---|
| | | * Create another two params files `params/project-requests-dev` & `params/project-requests-test`. On the terminal run |
|---|
| | | ```bash |
|---|
| | | touch params/project-requests-dev params/project-requests-test |
|---|
| | | ``` |
|---|
| | |
|---|
| | | ansible-galaxy install -r requirements.yml --roles-path=roles |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent as shown below). Accept any insecure connection warning 👍: |
|---|
| | | 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent as shown below). Accept any insecure connection warning 👍: |
|---|
| | | ```bash |
|---|
| | | oc login https://console.lader.rht-labs.com |
|---|
| | | ``` |
|---|
| | |
|---|
| | | ``` |
|---|
| | | where the `-e target=bootstrap` is passing an additional variable specifying that we run the `bootstrap` inventory |
|---|
| | | |
|---|
| | | 3. Once successful you should see an output similar to this (Cow's not included):  |
|---|
| | | 3. Once successful you should see an output similar to this (Cows not included):  |
|---|
| | | |
|---|
| | | 3. You can check to see the projects have been created successfully by running |
|---|
| | | 3. You can check to see the projects have been created successfully by running |
|---|
| | | ```bash |
|---|
| | | oc projects |
|---|
| | | ``` |
|---|
| | |
|---|
| | | ``` |
|---|
| | | The template contains all the things needed to setup a persistent nexus server, exposing a service and route while also creating the persistent volume needed. Have a read through the template; at the bottom you'll see a collection of parameters we will pass to the template. |
|---|
| | | |
|---|
| | | 4. Add some parameters for running the template by creating a new file in the `params` directory. |
|---|
| | | 4. Add some parameters for running the template by creating a new file in the `params` directory. |
|---|
| | | ```bash |
|---|
| | | touch params/nexus |
|---|
| | | ``` |
|---|
| | |
|---|
| | | MEMORY_LIMIT=1Gi |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Create a new object in the inventory variables `inventory/host_vars/ci-cd-tooling.yml` called `ci-cd-tooling` and populate it's `content` is as follows |
|---|
| | | 4. Create a new object in the inventory variables `inventory/host_vars/ci-cd-tooling.yml` called `ci-cd-tooling` and populate its `content` is as follows |
|---|
| | | |
|---|
| | | ```yaml |
|---|
| | | --- |
|---|
| | |
|---|
| | | ``` |
|---|
| | |  |
|---|
| | | |
|---|
| | | 4. Run the OpenShift applier, specifying the tag `nexus` to speed up it's execution (`-e target=tools` is to run the other inventory). |
|---|
| | | 4. Run the OpenShift applier, specifying the tag `nexus` to speed up its execution (`-e target=tools` is to run the other inventory). |
|---|
| | | ```bash |
|---|
| | | ansible-playbook apply.yml -e target=tools \ |
|---|
| | | -i inventory/ \ |
|---|
| | |
|---|
| | | |
|---|
| | | ### Part 3 - GitLab |
|---|
| | | |
|---|
| | | #### 3a - GitLab install |
|---|
| | | <p class="tip"> |
|---|
| | | NOTE - This section may already have been completed for you, please check with your tutor. If this is the case, skip to section 3b "Commit CI/CD" below to add your code to GitLab. |
|---|
| | | </p> |
|---|
| | | |
|---|
| | | 4. Now let's do the same thing for GitLab to get it up and running. Checkout the template and params provided by running |
|---|
| | | ```bash |
|---|
| | | git checkout exercise1/git-nexus templates/gitlab.yml params/gitlab |
|---|
| | | ``` |
|---|
| | | Explore the template; it contains the PVC, buildConfig and services. The DeploymentConfig is made up of these apps |
|---|
| | | - Redis (3.2.3) |
|---|
| | | - PostgreSQL (9.4) |
|---|
| | | - GitLab CE (v10.2.3) |
|---|
| | | |
|---|
| | | 4. Open the `params/gitlab` file and complete the following params |
|---|
| | | <p class="tip"> |
|---|
| | | Note - The values here for the LDAP and BIND credentials will be provided by your tutor. |
|---|
| | | </p> |
|---|
| | | ``` |
|---|
| | | LDAP_BIND_DN=uid=<BIND_USER>,ou=People,dc=<YOUR_DOMAIN>,dc=com |
|---|
| | | LDAP_USER_FILTER=(memberof=CN=YourGroup,OU=Users,DC=<YOUR_DOMAIN>,DC=com) |
|---|
| | | LDAP_PASSWORD=<BIND_USER_PASSWORD> |
|---|
| | | LDAP_HOST=<LDAP_HOST> |
|---|
| | | LDAP_BASE=ou=People,dc=<YOUR_DOMAIN>,dc=com |
|---|
| | | LDAP_LABEL="<LDAP_DESCRIPTION>" |
|---|
| | | GITLAB_ROOT_PASSWORD=<GITLAB_ROOT_USER_PASSWORD> |
|---|
| | | GITLAB_DATA_VOL_SIZE=2Gi |
|---|
| | | POSTGRESQL_VOL_SIZE=1Gi |
|---|
| | | APPLICATION_HOSTNAME=<GITLAB_URL> |
|---|
| | | NAMESPACE=<YOUR_NAME>-ci-cd |
|---|
| | | ``` |
|---|
| | | where the following need to be replaced by actual values: |
|---|
| | | * `<BIND_USER>` is the user used to query the LDAP |
|---|
| | | * `<BIND_USER_PASSWORD>` is the password used when querying the LDAP |
|---|
| | | * `<YOUR_DOMAIN>` is the domain the LDAP is hosted on |
|---|
| | | * `<LDAP_HOST>` is fqdn of the LDAP server |
|---|
| | | * `<LDAP_DESCRIPTION>` is the description to be used on the sign-in header for GitLab eg "Name LDAP Login" |
|---|
| | | * `<GITLAB_ROOT_USER_PASSWORD>` is the root user for GOD access on the GitLab instance eg password123 |
|---|
| | | * `<GITLAB_URL>` is the endpoint for gitlab. It will take the form `gitlab-<YOUR_NAME>-ci-cd.apps.<ENV_ID>.<YOUR_DOMAIN>.com` |
|---|
| | | |
|---|
| | | 4. Create another object in the inventory `inventory/host_vars/ci-cd-tooling.yml` file to run the build & deploy of this template. Add the following and update the `namespace:` accordingly |
|---|
| | | ```yaml |
|---|
| | | - name: "gitlab" |
|---|
| | | namespace: "{{ ci_cd_namespace }}" |
|---|
| | | template: "{{ playbook_dir }}/templates/gitlab.yml" |
|---|
| | | params: "{{ playbook_dir }}/params/gitlab" |
|---|
| | | tags: |
|---|
| | | - gitlab |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Run the OpenShift applier, specifying the tag `gitlab` to speed up it's execution. |
|---|
| | | ```bash |
|---|
| | | ansible-playbook apply.yml -e target=tools \ |
|---|
| | | -i inventory/ \ |
|---|
| | | -e "filter_tags=gitlab" |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Once successful; login to the cluster and navigate to the `<YOUR_NAME>-ci-cd`. You should see GitLab up and running.  |
|---|
| | | |
|---|
| | | #### 3b - Commit CI/CD |
|---|
| | | |
|---|
| | | 4. Navigate to gitlab (if you have just skipped straight to this step; ask your tutor for the URL). You can login using your cluster credentials using the LDAP tab |
|---|
| | |  |
|---|
| | | Go to https://gitlab.com/ and create an account, or sign in with an existing account. |
|---|
| | | |
|---|
| | | 4. Once logged in create a new project called `enablement-ci-cd` and mark it as internal. Once created; copy out the `git url` for use on the next step. |
|---|
| | |  |
|---|
| | | <p class="tip"> |
|---|
| | | Note - we would not normally make the project under your name but create an group and add the project there on residency but for simplicity of the exercise we'll do that here |
|---|
| | | Note - On a residency, you would create a group and add the project there. In this exercise, we'll add create the project under your name for simplicity's sake. |
|---|
| | | </p> |
|---|
| | | |
|---|
| | | 4. If you have not used Git before; you may need to tell Git who you are and what your email is before we commit. Run the following commands, substitution your email and "Your Name". If you've done this before move on to the next step. |
|---|
| | | 4. If you have not used Git before; you may need to tell Git who you are and what your email is before we commit. Run the following commands, substituting your email and "Your Name". If you've done this before move on to the next step. |
|---|
| | | ```bash |
|---|
| | | git config --global user.email "yourname@mail.com" |
|---|
| | | ``` |
|---|
| | |
|---|
| | | git config --global user.name "Your Name" |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Commit your local project to this new remote by first removing the existing origin (github) where the ansible project was cloned from in the first steps. Remember to substitute `<GIT_URL>` accordingly with the one created for your `enablement-ci-cd` repository a moment ago. |
|---|
| | | 4. Commit your local project to this new remote by first removing the existing origin (github) where the Ansible project was cloned from in the first steps. Remember to substitute `<GIT_URL>` accordingly with the one created for your `enablement-ci-cd` repository a moment ago. |
|---|
| | | ```bash |
|---|
| | | git remote set-url origin <GIT_URL> |
|---|
| | | ``` |
|---|
| | |
|---|
| | | git checkout exercise1/mongodb params/mongodb templates/mongodb.yml |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Open `enablement-ci-cd` in your favourite editor. Edit the `inventory/host_vars/ci-cd-tooling.yml` to include a new object for our mongodb as shown below. This item can be added below the jenkins slave in the `ci-cd-tooling` section. |
|---|
| | | 4. Open `enablement-ci-cd` in your favourite editor. Edit the `inventory/host_vars/ci-cd-tooling.yml` to include a new object for our mongodb as shown below. This item can be added below the Jenkins slave in the `ci-cd-tooling` section. |
|---|
| | | ```yaml |
|---|
| | | - name: "jenkins-mongodb" |
|---|
| | | namespace: "{{ ci_cd_namespace }}" |
|---|
| | |
|---|
| | | git push |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 4. Apply this change as done previously using ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace and checking if it is there! |
|---|
| | | 4. Apply this change as done previously using Ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace and checking if it is there! |
|---|
| | | ```bash |
|---|
| | | ansible-playbook apply.yml -e target=tools \ |
|---|
| | | -i inventory/ \ |
|---|
| | |
|---|
| | | ```bash |
|---|
| | | git checkout exercise1/jenkins templates/jenkins.yml |
|---|
| | | ``` |
|---|
| | | The Jenkins template is essentially the standard persistent jenkins one with OpenShift. |
|---|
| | | The Jenkins template is essentially the standard persistent Jenkins one with OpenShift. |
|---|
| | | |
|---|
| | | 5. As before; create a new set of params by creating a `params/jenkins` file and adding some overrides to the template and updating the `<YOUR_NAME>` value accordingly. |
|---|
| | | ``` |
|---|
| | |
|---|
| | | JENKINS_OPTS=--sessionTimeout=720 |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 5. Add a `jenkins` variable to the ansible inventory underneath the jenkins-mongo (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. |
|---|
| | | 5. Add a `jenkins` variable to the Ansible inventory underneath the jenkins-mongo (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. |
|---|
| | | ```yaml |
|---|
| | | - name: "jenkins" |
|---|
| | | namespace: "{{ ci_cd_namespace }}" |
|---|
| | |
|---|
| | | ``` |
|---|
| | | This configuration, if applied now, will create the deployment configuration needed for Jenkins but the `${NAMESPACE}:${JENKINS_IMAGE_STREAM_TAG}` in the template won't exist yet. |
|---|
| | | |
|---|
| | | 5. To create this image we will take the supported OpenShift Jenkins Image and bake into it some extra configuration using an [s2i](https://github.com/openshift/source-to-image) builder image. More information on Jenkins s2i is found on the [openshift/jenkins](https://github.com/openshift/jenkins#installing-using-s2i-build) github page. To create an s2i configuration for jenkins, check out the pre-canned configuration source in the `enablement-ci-cd` repo |
|---|
| | | 5. To create this image we will take the supported OpenShift Jenkins Image and bake into it some extra configuration using an [s2i](https://github.com/openshift/source-to-image) builder image. More information on Jenkins s2i is found on the [openshift/jenkins](https://github.com/openshift/jenkins#installing-using-s2i-build) GitHub page. To create an s2i configuration for Jenkins, check out the pre-canned configuration source in the `enablement-ci-cd` repo |
|---|
| | | ```bash |
|---|
| | | git checkout exercise1/jenkins-s2i jenkins-s2i |
|---|
| | | ``` |
|---|
| | | The structure of the jenkins s2i config is |
|---|
| | | The structure of the Jenkins s2i config is |
|---|
| | | ``` |
|---|
| | | jenkins-s2i |
|---|
| | | ├── README.md |
|---|
| | |
|---|
| | | * `build-failure-analyzer.xml` is config for the plugin to read the logs and look for key items based on a Regex. More on this in later lessons. |
|---|
| | | * `init.groovy` contains a collection of settings jenkins configures itself with when launching |
|---|
| | | |
|---|
| | | 5. Let's add a plugin for Jenkins to be started with, [green-balls](https://plugins.jenkins.io/greenballs). This simply changes the default `SUCCESS` status of Jenkins from Blue to Green. Append the `jenkins-s2i/plugins.txt` file with |
|---|
| | | 5. Let's add a plugin for Jenkins to be started with, [green-balls](https://plugins.jenkins.io/greenballs). This simply changes the default `SUCCESS` status of Jenkins from Blue to Green. Append the `jenkins-s2i/plugins.txt` file with |
|---|
| | | ```txt |
|---|
| | | greenballs:1.15 |
|---|
| | | ``` |
|---|
| | | ``` |
|---|
| | |  |
|---|
| | | Why does Jenkins have Blue Balls? More can be found [on reddit](https://www.reddit.com/r/programming/comments/4lu6q8/why_does_jenkins_have_blue_balls/) or the [jenkins blog](https://jenkins.io/blog/2012/03/13/why-does-jenkins-have-blue-balls/) |
|---|
| | | |
|---|
| | | 5. Before building and deploying the Jenkins s2i; add git credentials to it. These will be used by Jenkins to access the Git Repositories where our apps will be stored. We want Jenkins to be able to push tags to it so write access is required. There are a few ways we can do this; either adding them to the `template/jenkins.yml` as environment Variables and then including them in the `params/jenkins` file. We could also create a token in GitLab and use it as the source secret in the jenkins template. |
|---|
| | | But for simplicity just replace the `<USERNAME>` && `<PASSWORD>` in the `jenkins-s2i/configuration/init.groovy` with your ldap credentials as seen below. This init file gets run when Jenkins launches and will setup the credentials for use in our Jobs in the next exercises |
|---|
| | | 5. Before building and deploying the Jenkins s2i; add git credentials to it. These will be used by Jenkins to access the Git Repositories where our apps will be stored. We want Jenkins to be able to push tags to it so write access is required. There are a few ways we can do this; either adding them to the `template/jenkins.yml` as environment Variables and then including them in the `params/jenkins` file. We could also create a token in GitLab and use it as the source secret in the Jenkins template. |
|---|
| | | But for simplicity just replace the `<USERNAME>` && `<PASSWORD>` in the `jenkins-s2i/configuration/init.groovy` with your LDAP credentials as seen below. This init file gets run when Jenkins launches and will setup the credentials for use in our Jobs in the next exercises |
|---|
| | | ```groovy |
|---|
| | | gitUsername = System.getenv("GIT_USERNAME") ?: "<USERNAME>" |
|---|
| | | gitPassword = System.getenv("GIT_PASSWORD") ?: "<PASSWORD>" |
|---|
| | | ``` |
|---|
| | | <p class="tip"> |
|---|
| | | Note in a residency we would not use your GitCredentials for pushing and pulling from Git, A service user would be created for this. |
|---|
| | | Note in a residency we would not use your GitCredentials for pushing and pulling from Git, a service user would be created for this. |
|---|
| | | </p> |
|---|
| | | |
|---|
| | | 5. Checkout the params and the templates for the `jenkins-s2i` |
|---|
| | |
|---|
| | | git checkout exercise1/jenkins-s2i params/jenkins-s2i templates/jenkins-s2i.yml |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 5. Open `params/jenkins-s2i` and add the following content; replacing variables as appropriate. |
|---|
| | | 5. Open `params/jenkins-s2i` and add the following content; replacing variables as appropriate. |
|---|
| | | ``` |
|---|
| | | SOURCE_REPOSITORY_URL=<GIT_URL> |
|---|
| | | NAME=jenkins |
|---|
| | |
|---|
| | | SOURCE_REPOSITORY_USERNAME=<YOUR_LDAP_USERNAME> |
|---|
| | | SOURCE_REPOSITORY_PASSWORD=<YOUR_LDAP_PASSWORD> |
|---|
| | | ``` |
|---|
| | | where |
|---|
| | | * `<GIT_URL>` is the full path clone path of the repo where this project is stored (including the https && .git) |
|---|
| | | where |
|---|
| | | * `<GIT_URL>` is the full clone path of the repo where this project is stored (including the https && .git) |
|---|
| | | * `<YOUR_NAME>` is the prefix for your `-ci-cd` project. |
|---|
| | | * Explore some of the other parameters in `templates/jenkins-s2i.yml` |
|---|
| | | * `<YOUR_LDAP_USERNAME>` is the username builder pod will use to login and clone the repo with |
|---|
| | |
|---|
| | | Note in a residency we would not use your GitCredentials for pushing and pulling from Git, A service user would be created or a token generated. |
|---|
| | | </p> |
|---|
| | | |
|---|
| | | 5. Create a new object `ci-cd-builds` in the ansible `inventory/host_vars/ci-cd-tooling.yml` to drive the s2i build configuration. |
|---|
| | | 5. Create a new object `ci-cd-builds` in the Ansible `inventory/host_vars/ci-cd-tooling.yml` to drive the s2i build configuration. |
|---|
| | | ```yaml |
|---|
| | | - object: ci-cd-builds |
|---|
| | | content: |
|---|
| | |
|---|
| | | git push |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 5. In order for Jenkins to be able to run `npm` builds and installs we must configure a `jenkins-build-slave` for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. These slaves can take a time to build themselves so to speed up we have placed the slave within openshift and you can use the following commands to be able to use them in your project. |
|---|
| | | |
|---|
| | | 5. In order for Jenkins to be able to run `npm` builds and installs we must configure a `jenkins-build-slave` for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. These slaves can take a time to build themselves so to speed up we have placed the slave within OpenShift and you can use the following commands to be able to use them in your project. |
|---|
| | | ```bash |
|---|
| | | oc project <YOUR_NAME>-ci-cd |
|---|
| | | ``` |
|---|
| | | ```bash |
|---|
| | | oc tag openshift/jenkins-slave-npm:latest jenkins-slave-npm:latest |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | ```bash |
|---|
| | | oc label is jenkins-slave-npm role=jenkins-slave |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | This is pulling the container image into your namespace and then adding a label which will allow Jenkins to take notice of it. |
|---|
| | | This is pulling the container image into your namespace and then adding a label which will allow Jenkins to take notice of it. Don't worry if the label is already there and this last command fails! |
|---|
| | | |
|---|
| | | 5. Now your code is commited, and you have bought in the Jenkins slave; run the OpenShift Applier to add the config to the cluster |
|---|
| | | ```bash |
|---|
| | |
|---|
| | | 5. This will trigger a build of the s2i and when it's complete it will add an imagestream of `<YOUR_NAME>-ci-cd/jenkins:latest` to the project. The Deployment config should kick in and deploy the image once it arrives. You can follow the build of the s2i by going to the OpenShift console's project |
|---|
| | |  |
|---|
| | | |
|---|
| | | 5. When the Jenkins deployment has completed; login (using your openshift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job |
|---|
| | | 5. When the Jenkins deployment has completed; login (using your OpenShift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job |
|---|
| | | |
|---|
| | | ### Part 6 - Jenkins Hello World |
|---|
| | | ### Part 6 - Jenkins Hello World |
|---|
| | | > _To test things are working end-to-end; create a hello world job that doesn't do much but proves we can pull code from git and that our balls are green._ |
|---|
| | | |
|---|
| | | 6. Log in to Jenkins and hit `New Item` . |
|---|
| | |
|---|
| | | |
|---|
| | | 6. On the build tab add an Execute Shell step and fill it with `echo "Hello World"` . |
|---|
| | | |
|---|
| | | 6. Run the build and we should see if pass succesfully and with Green Balls!  |
|---|
| | | 6. Run the build and we should see if pass successfully and with Green Balls!  |
|---|
| | | |
|---|
| | | ### Part 7 - Live, Die, Repeat |
|---|
| | | > _In this section you will proove the infra as code is working by deleting your Cluster Content and recreating it all_ |
|---|
| | | > _In this section you will prove the infra as code is working by deleting your Cluster Content and recreating it all_ |
|---|
| | | |
|---|
| | | 7. Commit your code to the new repo in GitLab |
|---|
| | | ```bash |
|---|
