http://localhost:8080/gitops_intro/a1.workers/index.html In this lab we’re going to deploy a new runner and configure our project to use that runner. Runners can be hosted on bare metal, inside of VMs, or on kubernetes. In this case we’re going to use a kubernetes operator to manage the deployment and configuration of our runner. Key Terms Runner - executes jobs in a CI/CD pipeline Operator - a convenient way to deploy and manage resources on kubernetes Hugo en-us Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/gitops_intro/a1.workers/openshift/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/gitops_intro/a1.workers/openshift/index.html We use Redhat Openshift as our kubernetes environment. This provides a nice user interface in addition to a suite of enterprise security and application development features. That said the runner deployment we are going to perform in this portion of the workshop can be done on any kubernetes environment. Browse to https://console-openshift-console.apps.paas.fdlabs.dev/ and log in with “fdlabs” Then click on the integrated web terminal button to open up a new terminal. You can keep all the defaults and click the start button to initialize the terminal. http://localhost:8080/gitops_intro/a1.workers/authentication/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/gitops_intro/a1.workers/authentication/index.html Runners reach out to Gitlab and periodically check in to see if they have any jobs assigned to them. In order to communicate with Gitlab they need to have a valid authentication token - a shared secret between the runner and the Gitlab server that ensures the runner is trusted. Sensitive information like authentication tokens are managed in kubernetes with the use of secrets. We are going to generate a new runner token and save this token in a kubernetes secret. http://localhost:8080/gitops_intro/a1.workers/deploy/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/gitops_intro/a1.workers/deploy/index.html First we’ll create a configuration file with information about our runner cat > gitlab-runner.yml << EOF apiVersion: apps.gitlab.com/v1beta2 kind: Runner metadata: name: gitlab-runner spec: gitlabUrl: https://gitlab.fdlabs.dev token: gitlab-runner-token ca: fdlabs-ca #required to support non-public certificate authorities tags: "workshop" EOF Then we’ll run the following command to create the runner based on that configuration kubectl apply -f gitlab-runner.yml Now if we refresh our gitlab page and expand runners again we should see our new runner listed