RedHatTraining/rht-labs-docs.git

			@@ -4,9 +4,9 @@
			![automation-xkcd](https://imgs.xkcd.com/comics/automation.png)

			## 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?
			* Assurance - Prevents unwanted config changes from people making arbitrary changes to environments. No more Snowflake servers!
			@@ -30,11 +30,10 @@
			* [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 cluster we populate it with projects and some ci/cd tooling.

			![ds-messing-around.gif](../images/exercise1/ds-messing-around.gif)
			![big-picture](../images/big-picture/big-picture-1.jpg)

			_____

			@@ -43,20 +42,20 @@

			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)

			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.
			@@ -171,7 +170,7 @@
			```
			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): ![playbook-success](../images/exercise1/play-book-success.png)
			3. Once successful you should see an output similar to this (Cows not included): ![playbook-success](../images/exercise1/play-book-success.png)

			3. You can check to see the projects have been created successfully by running
			```bash
			@@ -227,77 +226,15 @@

			### 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 e.g. "Name LDAP Login"
			* `<GITLAB_ROOT_USER_PASSWORD>` is the root user for GOD access on the GitLab instance e.g. 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 its 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. ![gitlab-up-and-running](../images/exercise1/gitlab-up-and-running.png)

			#### 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
			![gitlab-ui](../images/exercise1/gitlab-ui.png)
			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.
			![gitlab-new-project](../images/exercise1/gitlab-new-project.png)
			<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"
			```
			@@ -444,7 +381,7 @@
			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)
			* `<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