{"id":15026410,"url":"https://github.com/googlecloudplatform/continuous-deployment-on-kubernetes","last_synced_at":"2025-05-15T04:07:02.731Z","repository":{"id":41467388,"uuid":"45876369","full_name":"GoogleCloudPlatform/continuous-deployment-on-kubernetes","owner":"GoogleCloudPlatform","description":"Get up and running with Jenkins on Google Kubernetes Engine","archived":false,"fork":false,"pushed_at":"2024-05-03T04:55:29.000Z","size":1965,"stargazers_count":1590,"open_issues_count":24,"forks_count":886,"subscribers_count":158,"default_branch":"master","last_synced_at":"2025-05-15T04:06:55.078Z","etag":null,"topics":["continuous-delivery","google-cloud","kubernetes"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/GoogleCloudPlatform.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-11-10T00:25:03.000Z","updated_at":"2025-05-13T12:57:18.000Z","dependencies_parsed_at":"2023-01-21T08:46:42.481Z","dependency_job_id":"88a53543-a78f-4565-a46a-3cdbd909c65d","html_url":"https://github.com/GoogleCloudPlatform/continuous-deployment-on-kubernetes","commit_stats":{"total_commits":142,"total_committers":35,"mean_commits":4.057142857142857,"dds":0.3943661971830986,"last_synced_commit":"59676d84deb623a40adb95b444bd65b231e4643f"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoogleCloudPlatform%2Fcontinuous-deployment-on-kubernetes","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoogleCloudPlatform%2Fcontinuous-deployment-on-kubernetes/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoogleCloudPlatform%2Fcontinuous-deployment-on-kubernetes/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoogleCloudPlatform%2Fcontinuous-deployment-on-kubernetes/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/GoogleCloudPlatform","download_url":"https://codeload.github.com/GoogleCloudPlatform/continuous-deployment-on-kubernetes/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254270646,"owners_count":22042859,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["continuous-delivery","google-cloud","kubernetes"],"created_at":"2024-09-24T20:04:25.781Z","updated_at":"2025-05-15T04:06:57.688Z","avatar_url":"https://github.com/GoogleCloudPlatform.png","language":"Shell","readme":"# Lab: Build a Continuous Deployment Pipeline with Jenkins and Kubernetes\n\nFor a more in depth best practices guide, go to the solution posted [here](https://cloud.google.com/solutions/jenkins-on-container-engine).\n\n## Introduction\n\nThis guide will take you through the steps necessary to continuously deliver\nyour software to end users by leveraging [Google Container Engine](https://cloud.google.com/container-engine/)\nand [Jenkins](https://jenkins.io) to orchestrate the software delivery pipeline.\nIf you are not familiar with basic Kubernetes concepts, have a look at\n[Kubernetes 101](http://kubernetes.io/docs/user-guide/walkthrough/).\n\nIn order to accomplish this goal you will use the following Jenkins plugins:\n  - [Jenkins Kubernetes Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin) - start Jenkins build executor containers in the Kubernetes cluster when builds are requested, terminate those containers when builds complete, freeing resources up for the rest of the cluster\n  - [Jenkins Pipelines](https://jenkins.io/solutions/pipeline/) - define our build pipeline declaratively and keep it checked into source code management alongside our application code\n  - [Google Oauth Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Google+OAuth+Plugin) - allows you to add your google oauth credentials to jenkins\n\nIn order to deploy the application with [Kubernetes](http://kubernetes.io/) you will use the following resources:\n  - [Deployments](http://kubernetes.io/docs/user-guide/deployments/) - replicates our application across our kubernetes nodes and allows us to do a controlled rolling update of our software across the fleet of application instances\n  - [Services](http://kubernetes.io/docs/user-guide/services/) - load balancing and service discovery for our internal services\n  - [Ingress](http://kubernetes.io/docs/user-guide/ingress/) - external load balancing and SSL termination for our external service\n  - [Secrets](http://kubernetes.io/docs/user-guide/secrets/) - secure storage of non public configuration information, SSL certs specifically in our case\n\n## Prerequisites\n\n1. A Google Cloud Platform Account\n1. [Enable the Compute Engine, Container Engine, and Container Builder APIs](https://console.cloud.google.com/flows/enableapi?apiid=compute_component,container,cloudbuild.googleapis.com)\n\n## Do this first\n\nIn this section you will start your [Google Cloud Shell](https://cloud.google.com/cloud-shell/docs/)\nand clone the lab code repository to it.\n\n1. Create a new Google Cloud Platform project: [https://console.developers.google.com/project](https://console.developers.google.com/project)\n\n1. Click the Activate Cloud Shell icon in the top-right and wait for your shell to open.\n\n   ![](docs/img/cloud-shell.png)\n\n   \u003e If you are prompted with a _Learn more_ message, click __Continue__ to\n   \u003e finish opening the Cloud Shell.\n\n1. When the shell is open, use the [gcloud](https://cloud.google.com/sdk/)\n   command line interface tool to set your default compute zone:\n\n   ![](docs/img/cloud-shell-prompt.png)\n\n   ```shell\n   gcloud config set compute/zone us-east1-d\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Updated property [compute/zone].\n   ```\n\n1. Set an environment variable with your project:\n\n   ```shell\n   export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Your active configuration is: [cloudshell-...]\n   ```\n\n1. Clone the lab repository in your cloud shell, then `cd` into that dir:\n\n   ```shell\n   git clone https://github.com/GoogleCloudPlatform/continuous-deployment-on-kubernetes.git\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Cloning into 'continuous-deployment-on-kubernetes'...\n   ...\n   ```\n\n   ```shell\n   cd continuous-deployment-on-kubernetes\n   ```\n\n## Create a Service Account with permissions\n\n1. Create a service account, on Google Cloud Platform (GCP).\n\n   Create a new service account because it's the recommended way to avoid\n   using extra permissions in Jenkins and the cluster.\n\n   ```shell\n   gcloud iam service-accounts create jenkins-sa \\\n       --display-name \"jenkins-sa\"\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Created service account [jenkins-sa].\n   ```\n\n1. Add required permissions, to the service account, using predefined roles.\n\n   Most of these permissions are related to Jenkins use of _Cloud Build_, and\n   storing/retrieving build artifacts in _Cloud Storage_. Also, the\n   service account needs to enable the Jenkins agent to read from a repo\n   you will create in _Cloud Source Repositories (CSR)_.\n\n   ```shell\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/viewer\"\n\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/source.reader\"\n\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/storage.admin\"\n\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/storage.objectAdmin\"\n\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/cloudbuild.builds.editor\"\n\n   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \\\n       --member \"serviceAccount:jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\" \\\n       --role \"roles/container.developer\"\n   ```\n\n   You can check the permissions added using __IAM \u0026 admin__ in Cloud Console.\n\n   ![](docs/img/jenkins_sa_iam.png)\n\n1. Export the service account credentials to a JSON key file in Cloud Shell:\n\n   ```shell\n   gcloud iam service-accounts keys create ~/jenkins-sa-key.json \\\n       --iam-account \"jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\"\n   ```\n\n   Output (do not copy):\n\n   ```output\n   created key [...] of type [json] as [/home/.../jenkins-sa-key.json] for [jenkins-sa@myproject.aiam.gserviceaccount.com]\n   ```\n\n1. Download the JSON key file to your local machine.\n\n   Click __Download File__ from __More__ on the Cloud Shell toolbar:\n\n   ![](docs/img/download_file.png)\n\n1. Enter the __File path__ as `jenkins-sa-key.json` and click __Download__.\n\n   The file will be downloaded to your local machine, for use later.\n\n## Create a Kubernetes Cluster\n\n1. Provision the cluster with `gcloud`:\n\n   Use Google Kubernetes Engine (GKE) to create and manage your Kubernetes\n   cluster, named `jenkins-cd`. Use the _service account_ created earlier.\n\n   ```shell\n   gcloud container clusters create jenkins-cd \\\n     --num-nodes 2 \\\n     --machine-type n1-standard-2 \\\n     --cluster-version 1.15 \\\n     --service-account \"jenkins-sa@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com\"\n   ```\n\n   Output (do not copy):\n\n   ```output\n   NAME        LOCATION    MASTER_VERSION  MASTER_IP     MACHINE_TYPE  NODE_VERSION   NUM_NODES  STATUS\n   jenkins-cd  us-east1-d  1.15.11-gke.15   35.229.29.69  n1-standard-2 1.15.11-gke.15  2          RUNNING\n   ```\n\n1. Once that operation completes, retrieve the credentials for your cluster.\n\n   ```shell\n   gcloud container clusters get-credentials jenkins-cd\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Fetching cluster endpoint and auth data.\n   kubeconfig entry generated for jenkins-cd.\n   ```\n\n1. Confirm that the cluster is running and `kubectl` is working by listing pods:\n\n   ```shell\n   kubectl get pods\n   ```\n\n   Output (do not copy):\n\n   ```output\n   No resources found.\n   ```\n\n   \u003e You would see an error if the cluster was not created, or you did not\n   \u003e have permissions.\n\n1. Add yourself as a cluster administrator in the cluster's RBAC so that you can\n   give Jenkins permissions in the cluster:\n\n    ```shell\n    kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)\n    ```\n\n    Output (do not copy):\n\n    ```output\n    Your active configuration is: [cloudshell-...]\n    clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created\n    ```\n\n## Install Helm\n\nIn this lab, you will use Helm to install Jenkins with a stable _chart_.  Helm\nis a package manager that makes it easy to configure and deploy Kubernetes\napplications.  Once you have Jenkins installed, you'll be able to set up your\nCI/CD pipleline.\n\n1. Download and install the helm binary\n\n    ```shell\n    wget https://get.helm.sh/helm-v3.2.1-linux-amd64.tar.gz\n    ```\n\n1. Unzip the file to your local system:\n\n    ```shell\n    tar zxfv helm-v3.2.1-linux-amd64.tar.gz\n    cp linux-amd64/helm .\n    ```\n\n1. Add the official stable repository.\n\n    ```shell\n    ./helm repo add stable https://kubernetes-charts.storage.googleapis.com\n    ```\n\n1. Ensure Helm is properly installed by running the following command. You\n   should see version `v3.2.1` appear:\n\n    ```shell\n    ./helm version\n    ```\n\n    Output (do not copy):\n\n    ```output\n    version.BuildInfo{Version:\"v3.2.1\", GitCommit:\"fe51cd1e31e6a202cba7dead9552a6d418ded79a\", GitTreeState:\"clean\", GoVersion:\"go1.13.10\"}\n    ```\n\n## Configure and Install Jenkins\n\nYou will use a custom [values file](https://github.com/helm/charts/blob/master/stable/jenkins/values.yaml)\nto add the GCP specific plugin necessary to use service account credentials to reach your Cloud Source Repository.\n\n1. Use the Helm CLI to deploy the chart with your configuration set.\n\n    ```shell\n    ./helm install cd-jenkins -f jenkins/values.yaml stable/jenkins --version 1.7.3 --wait\n    ```\n\n    Output (do not copy):\n\n    ```output\n    ...\n    For more information on running Jenkins on Kubernetes, visit:\n    https://cloud.google.com/solutions/jenkins-on-container-engine\n    ```\n\n1. The Jenkins pod __STATUS__ should change to `Running` when it's ready:\n\n    ```shell\n    kubectl get pods\n    ```\n\n    Output (do not copy):\n\n    ```output\n    NAME                          READY     STATUS    RESTARTS   AGE\n    cd-jenkins-7c786475dd-vbhg4   1/1       Running   0          1m\n    ```\n\n1. Configure the Jenkins service account to be able to deploy to the cluster.\n\n    ```shell\n    kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins\n    ```\n\n    Output (do not copy):\n\n    ```output\n    clusterrolebinding.rbac.authorization.k8s.io/jenkins-deploy created\n    ```\n\n1. Set up port forwarding to the Jenkins UI, from Cloud Shell:\n\n    ```shell\n    export JENKINS_POD_NAME=$(kubectl get pods -l \"app.kubernetes.io/component=jenkins-master\" -o jsonpath=\"{.items[0].metadata.name}\")\n    kubectl port-forward $JENKINS_POD_NAME 8080:8080 \u003e\u003e /dev/null \u0026\n    ```\n\n1. Now, check that the Jenkins Service was created properly:\n\n    ```shell\n    kubectl get svc\n    ```\n\n    Output (do not copy):\n\n    ```output\n    NAME               CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE\n    cd-jenkins         10.35.249.67   \u003cnone\u003e        8080/TCP    3h\n    cd-jenkins-agent   10.35.248.1    \u003cnone\u003e        50000/TCP   3h\n    kubernetes         10.35.240.1    \u003cnone\u003e        443/TCP     9h\n    ```\n\n    This Jenkins configuration is using the [Kubernetes Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin),\n    so that builder nodes will be automatically launched as necessary when the\n    Jenkins master requests them.  Upon completion of the work, the builder nodes\n    will be automatically turned down, and their resources added back to the\n    cluster's resource pool.\n\n    Notice that this service exposes ports `8080` and `50000` for any pods that\n    match the `selector`. This will expose the Jenkins web UI and builder/agent\n    registration ports within the Kubernetes cluster.  Additionally the `jenkins-ui`\n    services is exposed using a ClusterIP so that it is not accessible from outside\n    the cluster.\n\n## Connect to Jenkins\n\n1. The Jenkins chart will automatically create an admin password for you. To\n   retrieve it, run:\n\n    ```shell\n    printf $(kubectl get secret cd-jenkins -o jsonpath=\"{.data.jenkins-admin-password}\" | base64 --decode);echo\n    ```\n\n2. To get to the Jenkins user interface, click on the Web Preview\n   button![](../docs/img/web-preview.png) in cloud shell, then click\n   **Preview on port 8080**:\n\n![](docs/img/preview-8080.png)\n\nYou should now be able to log in with username `admin` and your auto generated\npassword.\n\n![](docs/img/jenkins-login.png)\n\n### Your progress, and what's next\n\nYou've got a Kubernetes cluster managed by GKE. You've deployed:\n\n* a Jenkins Deployment\n* a (non-public) service that exposes Jenkins to its agent containers\n\nYou have the tools to build a continuous deployment pipeline. Now you need a\nsample app to deploy continuously.\n\n## The sample app\n\nYou'll use a very simple sample application - `gceme` - as the basis for your CD\npipeline. `gceme` is written in Go and is located in the `sample-app` directory\nin this repo. When you run the `gceme` binary on a GCE instance, it displays the\ninstance's metadata in a pretty card:\n\n![](docs/img/info_card.png)\n\nThe binary supports two modes of operation, designed to mimic a microservice. In\nbackend mode, `gceme` will listen on a port (8080 by default) and return GCE\ninstance metadata as JSON, with content-type=application/json. In frontend mode,\n`gceme` will query a backend `gceme` service and render that JSON in the UI you\nsaw above. It looks roughly like this:\n\n```\n-----------      ------------      ~~~~~~~~~~~~        -----------\n|         |      |          |      |          |        |         |\n|  user   | ---\u003e |   gceme  | ---\u003e | lb/proxy | -----\u003e |  gceme  |\n|(browser)|      |(frontend)|      |(optional)|   |    |(backend)|\n|         |      |          |      |          |   |    |         |\n-----------      ------------      ~~~~~~~~~~~~   |    -----------\n                                                  |    -----------\n                                                  |    |         |\n                                                  |--\u003e |  gceme  |\n                                                       |(backend)|\n                                                       |         |\n                                                       -----------\n```\nBoth the frontend and backend modes of the application support two additional URLs:\n\n1. `/version` prints the version of the binary (declared as a const in\n   `main.go`)\n1. `/healthz` reports the health of the application. In frontend mode, health\n   will be OK if the backend is reachable.\n\n### Deploy the sample app to Kubernetes\n\nIn this section you will deploy the `gceme` frontend and backend to Kubernetes\nusing Kubernetes manifest files (included in this repo) that describe the\nenvironment that the `gceme` binary/Docker image will be deployed to. They use a\ndefault `gceme` Docker image that you will be updating with your own in a later\nsection.\n\nYou'll have two primary environments -\n[canary](http://martinfowler.com/bliki/CanaryRelease.html) and production - and\nuse Kubernetes to manage them.\n\n\u003e **Note**: The manifest files for this section of the tutorial are in\n\u003e `sample-app/k8s`. You are encouraged to open and read each one before creating\n\u003e it per the instructions.\n\n1. First change directories to the sample-app, back in __Cloud Shell__:\n\n   ```shell\n   cd sample-app\n   ```\n\n1. Create the namespace for production:\n\n   ```shell\n   kubectl create ns production\n   ```\n\n   Output (do not copy):\n\n   ```output\n   namespace/production created\n   ```\n\n1. Create the production Deployments for frontend and backend:\n\n    ```shell\n    kubectl --namespace=production apply -f k8s/production\n    ```\n\n    Output (do not copy):\n\n    ```output\n    deployment.extensions/gceme-backend-production created\n    deployment.extensions/gceme-frontend-production created\n    ```\n\n1. Create the canary Deployments for frontend and backend:\n\n    ```shell\n    kubectl --namespace=production apply -f k8s/canary\n    ```\n\n    Output (do not copy):\n\n    ```output\n    deployment.extensions/gceme-backend-canary created\n    deployment.extensions/gceme-frontend-canary created\n    ```\n\n1. Create the Services for frontend and backend:\n\n    ```shell\n    kubectl --namespace=production apply -f k8s/services\n    ```\n\n    Output (do not copy):\n\n    ```output\n    service/gceme-backend created\n    service/gceme-frontend created\n    ```\n\n1. Scale the production, frontend service:\n\n    ```shell\n    kubectl --namespace=production scale deployment gceme-frontend-production --replicas=4\n    ```\n\n    Output (do not copy):\n\n    ```output\n    deployment.extensions/gceme-frontend-production scaled\n    ```\n\n1. Retrieve the External IP for the production services:\n\n   **This field may take a few minutes to appear as the load balancer is being\n   provisioned**\n\n   ```shell\n   kubectl --namespace=production get service gceme-frontend\n   ```\n\n   Output (do not copy):\n\n   ```output\n   NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE\n   gceme-frontend   LoadBalancer   10.35.254.91   35.196.48.78   80:31088/TCP   1m\n   ```\n\n1. Confirm that both services are working by opening the frontend `EXTERNAL-IP`\n   in your browser\n\n   ![](docs/img/blue_gceme.png)\n\n1. Poll the production endpoint's `/version` URL.\n\n   Open a new **Cloud Shell** terminal by clicking the `+` button to the right\n   of the current terminal's tab.\n\n   ```shell\n   export FRONTEND_SERVICE_IP=$(kubectl get -o jsonpath=\"{.status.loadBalancer.ingress[0].ip}\"  --namespace=production services gceme-frontend)\n   while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 3;  done\n   ```\n\n   Output (do not copy):\n\n   ```output\n   1.0.0\n   1.0.0\n   1.0.0\n   ```\n\n   You should see that all requests are serviced by v1.0.0 of the application.\n\n   Leave this running in the second terminal so you can easily observe rolling\n   updates in the next section.\n\n1. Return to the first terminal/tab in Cloud Shell.\n\n### Create a repository for the sample app source\n\nHere you'll create your own copy of the `gceme` sample app in\n[Cloud Source Repository](https://cloud.google.com/source-repositories/docs/).\n\n1. Initialize the git repository.\n\n   Make sure to work from the `sample-app` directory of the repo you cloned previously.\n\n    ```shell\n    git init\n    git config credential.helper gcloud.sh\n    gcloud source repos create gceme\n    ```\n\n1. Add a _git remote_ for the new repo in Cloud Source Repositories.\n\n    ```shell\n    git remote add origin https://source.developers.google.com/p/$GOOGLE_CLOUD_PROJECT/r/gceme\n    ```\n\n1. Ensure git is able to identify you:\n\n    ```shell\n    git config --global user.email \"YOUR-EMAIL-ADDRESS\"\n    git config --global user.name \"YOUR-NAME\"\n    ```\n\n1. Add, commit, and push all the files:\n\n   ```shell\n   git add .\n   git commit -m \"Initial commit\"\n   git push origin master\n   ```\n\n   Output (do not copy):\n\n   ```output\n   To https://source.developers.google.com/p/myproject/r/gceme\n    * [new branch]      master -\u003e master\n   ```\n\n## Create a pipeline\n\nYou'll now use __Jenkins__ to define and run a pipeline that will test, build,\nand deploy your copy of `gceme` to your Kubernetes cluster. You'll approach this\nin phases. Let's get started with the first.\n\n### Phase 1: Add your service account credentials\n\nFirst, you will need to configure GCP credentials in order for Jenkins to be\nable to access the code repository:\n\n1. In the **Jenkins UI**, Click **Credentials** on the left\n1. Click the **(global)** link\n1. Click **Add Credentials** on the left\n1. From the **Kind** dropdown, select `Google Service Account from private key`\n1. Enter the **Project Name** from your project\n1. Leave **JSON key** selected, and click **Choose File**.\n1. Select the `jenkins-sa-key.json` file downloaded earlier, then click\n   **Open**.\n\n   ![](docs/img/jenkins_creds_safromkey.png)\n\n1. Click **OK**\n\nYou should now see 1 global credential. Make a note of the name of the\ncredential, as you will reference this in Phase 2.\n\n![](docs/img/jenkins-credentials.png)\n\n### Phase 2: Create a job\n\nThis lab uses [Jenkins Pipeline](https://jenkins.io/solutions/pipeline/) to\ndefine builds as _groovy_ scripts.\n\nNavigate to your Jenkins UI and follow these steps to configure a Pipeline job\n(hot tip: you can find the IP address of your Jenkins install with `kubectl get\ningress --namespace jenkins`):\n\n1. Click the **Jenkins** link in the top left toolbar, of the ui\n\n1. Click the **New Item** link in the left nav\n\n1. For **item name** use `sample-app`, choose the **Multibranch Pipeline**\n   option, then click **OK**\n\n   ![](docs/img/sample-app.png)\n\n1. Click **Add source** and choose **git**\n\n1. Paste the **HTTPS clone URL** of your `gceme` repo on Cloud Source\n   Repositories into the **Project Repository** field.\n   It will look like:\n   https://source.developers.google.com/p/[REPLACE_WITH_YOUR_PROJECT_ID]/r/gceme\n\n1. From the **Credentials** dropdown, select the name of the credential from\n   Phase 1. It should have the format `PROJECT_ID service account`.\n\n1. Under **Scan Multibranch Pipeline Triggers** section, check the\n   **Periodically if not otherwise run** box, then set the **Interval** value to\n   `1 minute`.\n\n   ![](docs/img/git-credentials.png)\n\n1. Click **Save**, leaving all other options with default values.\n\n   A _Branch indexing_ job was kicked off to identify any branches in your\n   repository.\n\n1. Click **Jenkins** \u003e **sample-app**, in the top menu.\n\n   You should see the `master` branch now has a job created for it.\n\n   The first run of the job will fail, until the _project name_ is set properly\n   in the `Jenkinsfile` next step.\n\n  ![](docs/img/first-build.png)\n\n### Phase 3:  Modify Jenkinsfile, then build and test the app\n\n1. Create a branch for the canary environment called `canary`\n\n   ```shell\n   git checkout -b canary\n   ```\n\n   Output (do not copy):\n\n   ```output\n   Switched to a new branch 'canary'\n   ```\n\n   The [`Jenkinsfile`](https://jenkins.io/doc/book/pipeline/jenkinsfile/) is\n   written using the Jenkins Workflow DSL, which is Groovy-based. It allows an\n   entire build pipeline to be expressed in a single script that lives alongside\n   your source code and supports powerful features like parallelization, stages,\n   and user input.\n\n1. Update your `Jenkinsfile` script with the correct **PROJECT** environment value.\n\n   **Be sure to replace `REPLACE_WITH_YOUR_PROJECT_ID` with your project name.**\n\n   Save your changes, but don't commit the new `Jenkinsfile` change just yet.\n   You'll make one more change in the next section, then commit and push them\n   together.\n\n### Phase 4: Deploy a [canary release](http://martinfowler.com/bliki/CanaryRelease.html) to canary\n\nNow that your pipeline is working, it's time to make a change to the `gceme` app\nand let your pipeline test, package, and deploy it.\n\nThe canary environment is rolled out as a percentage of the pods behind the\nproduction load balancer.  In this case we have 1 out of 5 of our frontends\nrunning the canary code and the other 4 running the production code. This allows\nyou to ensure that the canary code is not negatively affecting users before\nrolling out to your full fleet.  You can use the\n[labels](http://kubernetes.io/docs/user-guide/labels/) `env: production` and\n`env: canary` in Google Cloud Monitoring in order to monitor the performance of\neach version individually.\n\n1. In the `sample-app` repository on your workstation open `html.go` and replace\n   the word `blue` with `orange` (there should be exactly two occurrences):\n\n  ```html\n  //snip\n  \u003cdiv class=\"card orange\"\u003e\n  \u003cdiv class=\"card-content white-text\"\u003e\n  \u003cdiv class=\"card-title\"\u003eBackend that serviced this request\u003c/div\u003e\n  //snip\n  ```\n\n1. In the same repository, open `main.go` and change the version number from\n   `1.0.0` to `2.0.0`:\n\n   ```go\n   //snip\n   const version string = \"2.0.0\"\n   //snip\n   ```\n\n1. Push the _version 2_ changes to the repo:\n\n   ```shell\n   git add Jenkinsfile html.go main.go\n   ```\n\n   ```shell\n   git commit -m \"Version 2\"\n   ```\n\n   ```shell\n   git push origin canary\n   ```\n\n1. Revisit your sample-app in the Jenkins UI.\n\n   Navigate back to your Jenkins `sample-app` job. Notice a canary pipeline\n   job has been created.\n\n   ![](docs/img/sample_app_master_canary.png)\n\n1. Follow the canary build output.\n\n   * Click the **Canary** link.\n   * Click the **#1** link the **Build History** box, on the lower left.\n   * Click **Console Output** from the left-side menu.\n   * Scroll down to follow.\n\n1. Track the output for a few minutes.\n\n   When you see `Finished: SUCCESS`, open the Cloud Shell terminal that you\n   left polling `/version` of _canary_. Observe that some requests are now\n   handled by the _canary_ `2.0.0` version.\n\n   ```\n   1.0.0\n   1.0.0\n   1.0.0\n   1.0.0\n   2.0.0\n   2.0.0\n   1.0.0\n   1.0.0\n   1.0.0\n   1.0.0\n   ```\n\n   You have now rolled out that change, version 2.0.0, to a **subset** of users.\n\n1. Continue the rollout, to the rest of your users.\n\n   Back in the other Cloud Shell terminal, create a branch called\n   `production`, then push it to the Git server.\n\n   ```shell\n    git checkout master\n    git merge canary\n    git push origin master\n   ```\n\n1. Watch the pipelines in the Jenkins UI handle the change.\n\n   Within a minute or so, you should see a new job in the **Build Queue** and **Build Executor**.\n\n    ![](docs/img/master_build_executor.png)\n\n1. Clicking on the `master` link will show you the stages of your pipeline as\n   well as pass/fail and timing characteristics.\n\n   You can see the failed master job #1, and the successful master job #2.\n\n   ![](docs/img/master_two_pipeline.png)\n\n1. Check the Cloud Shell terminal responses again.\n\n   In Cloud Shell, open the terminal polling canary's `/version` URL and observe\n   that the new version, `2.0.0`, has been rolled out and is serving all\n   requests.\n\n   ```\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   2.0.0\n   ```\n\nIf you want to understand the pipeline stages in greater detail, you can\nlook through the `Jenkinsfile` in the `sample-app` project directory.\n\n### Phase 5: Deploy a development branch\n\nOftentimes changes will not be so trivial that they can be pushed directly to\nthe **canary** environment. In order to create a **development** environment,\nfrom a long lived feature branch, all you need to do is push it up to the Git\nserver. Jenkins will automatically deploy your **development** environment.\n\nIn this case you will not use a loadbalancer, so you'll have to access your\napplication using `kubectl proxy`. This proxy authenticates itself with the\nKubernetes API and proxies requests from your local machine to the service in\nthe cluster without exposing your service to the internet.\n\n#### Deploy the development branch\n\n1. Create another branch and push it up to the Git server\n\n   ```shell\n   git checkout -b new-feature\n   git push origin new-feature\n   ```\n\n1. Open Jenkins in your web browser and navigate back to sample-app.\n\n   You should see that a new job called `new-feature` has been created,\n   and this job is creating your new environment.\n\n   ![](docs/img/new_feature_job.png)\n\n1. Navigate to the console output of the first build of this new job by:\n\n   * Click the **new-feature** link in the job list.\n   * Click the **#1** link in the Build History list on the left of the page.\n   * Finally click the **Console Output** link in the left menu.\n\n1. Scroll to the bottom of the console output of the job to see\n   instructions for accessing your environment:\n\n   ```\n   Successfully verified extensions/v1beta1/Deployment: gceme-frontend-dev\n   AvailableReplicas = 1, MinimumReplicas = 1\n\n   [Pipeline] echo\n   To access your environment run `kubectl proxy`\n   [Pipeline] echo\n   Then access your service via\n   http://localhost:8001/api/v1/proxy/namespaces/new-feature/services/gceme-frontend:80/\n   [Pipeline] }\n   ```\n\n#### Access the development branch\n\n1. Set up port forwarding to the dev frontend, from Cloud Shell:\n\n   ```shell\n   export DEV_POD_NAME=$(kubectl get pods -n new-feature -l \"app=gceme,env=dev,role=frontend\" -o jsonpath=\"{.items[0].metadata.name}\")\n   kubectl port-forward -n new-feature $DEV_POD_NAME 8001:80 \u003e\u003e /dev/null \u0026\n   ```\n\n1. Access your application via localhost:\n\n   ```shell\n   curl http://localhost:8001/api/v1/proxy/namespaces/new-feature/services/gceme-frontend:80/\n   ```\n\n   Output (do not copy):\n\n   ```output\n   \u003c!doctype html\u003e\n   \u003chtml\u003e\n   ...\n   \u003c/div\u003e\n   \u003cdiv class=\"col s2\"\u003e\u0026nbsp;\u003c/div\u003e\n   \u003c/div\u003e\n   \u003c/div\u003e\n   \u003c/html\u003e\n   ```\n\n   Look through the response output for `\"card orange\"` that was changed earlier.\n\n1. You can now push code changes to the `new-feature` branch in order to update\n   your development environment.\n\n1. Once you are done, merge your `new-feature ` branch back into the  `canary`\n   branch to deploy that code to the canary environment:\n\n   ```shell\n   git checkout canary\n   git merge new-feature\n   git push origin canary\n   ```\n\n1. When you are confident that your code won't wreak havoc in production, merge\n   from the `canary` branch to the `master` branch. Your code will be\n   automatically rolled out in the production environment:\n\n   ```shell\n   git checkout master\n   git merge canary\n   git push origin master\n   ```\n\n1. When you are done with your development branch, delete it from Cloud\n   Source Repositories, then delete the environment in Kubernetes:\n\n   ```shell\n   git push origin :new-feature\n   kubectl delete ns new-feature\n   ```\n\n## Extra credit: deploy a breaking change, then roll back\n\nMake a breaking change to the `gceme` source, push it, and deploy it through the\npipeline to production. Then pretend latency spiked after the deployment and you\nwant to roll back. Do it! Faster!\n\nThings to consider:\n\n* What is the Docker image you want to deploy for roll back?\n* How can you interact directly with the Kubernetes to trigger the deployment?\n* Is SRE really what you want to do with your life?\n\n## Clean up\n\nClean up is really easy, but also super important: if you don't follow these\ninstructions, you will continue to be billed for the GKE cluster you created.\n\nTo clean up, navigate to the\n[Google Developers Console Project List](https://console.developers.google.com/project),\nchoose the project you created for this lab, and delete it. That's it.\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgooglecloudplatform%2Fcontinuous-deployment-on-kubernetes","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgooglecloudplatform%2Fcontinuous-deployment-on-kubernetes","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgooglecloudplatform%2Fcontinuous-deployment-on-kubernetes/lists"}