Skip to content

Latest commit

 

History

History
155 lines (104 loc) · 5.87 KB

create-jenkins-pipeline.md

File metadata and controls

155 lines (104 loc) · 5.87 KB
Raw

Create a pipeline

You'll now use Jenkins to define and run a pipeline that will test, build, and deploy your copy of gceme to your Kubernetes cluster. You'll approach this in phases. Let's get started with the first.

Phase 1: Add your service account credentials

First we will need to configure our GCP credentials in order for Jenkins to be able to access our code repository

  1. In the Jenkins UI, Click “Credentials” on the left
  2. Click either of the “(global)” links (they both route to the same URL)
  3. Click “Add Credentials” on the left
  4. From the “Kind” dropdown, select “Google Service Account from metadata”
  5. Click “OK”

You should now see 2 Global Credentials. Make a note of the name of second credentials as you will reference this in Phase 2:

Phase 2: Create a job

This lab uses Jenkins Pipeline to define builds as groovy scripts.

Navigate to your Jenkins UI and follow these steps to configure a Pipeline job (hot tip: you can find the IP address of your Jenkins install with kubectl get ingress --namespace jenkins):

  1. Click the “Jenkins” link in the top left of the interface

  2. Click the New Item link in the left nav

  3. Name the project sample-app, choose the Multibranch Pipeline option, then click OK

  4. Click Add Source and choose git

  5. Paste the HTTPS clone URL of your sample-app repo on Cloud Source Repositories into the Project Repository field. It will look like: https://source.developers.google.com/p/REPLACE_WITH_YOUR_PROJECT_ID/r/default

  6. From the Credentials dropdown select the name of new created credentials from the Phase 1.

  7. Under "Build Triggers", check "Build Periodically" and enter "* * * * *" in to the "Schedule" field, this will ensure that Jenkins will check our repository for changes every minute.

  8. Click Save, leaving all other options with their defaults

A job entitled "Branch indexing" was kicked off to see identify the branches in your repository. If you refresh Jenkins you should see the master branch now has a job created for it.

The first run of the job will fail until the project name is set properly in the next step.

Phase 3: Modify Jenkinsfile, then build and test the app

Create a branch for the staging environment called staging

 $ git checkout -b staging

The Jenkinsfile is written using the Jenkins Workflow DSL (Groovy-based). It allows an entire build pipeline to be expressed in a single script that lives alongside your source code and supports powerful features like parallelization, stages, and user input.

Modify line 2 of your Jenkinsfile script so it contains the output of the following command.

$ echo $(gcloud info --format='value(config.project)')

Don't commit the new Jenkinsfile just yet. You'll make one more change in the next section, then commit and push them together.

Phase 4: Deploy a canary release to staging

Now that your pipeline is working, it's time to make a change to the gceme app and let your pipeline test, package, and deploy it.

The staging environment is rolled out as a percentage of the pods behind the production load balancer. In this case we have 1 out of 5 of our frontends running the staging code and the other 4 running the production code. This allows you to ensure that the staging code is not negatively affecting users before rolling out to your full fleet. You can use the labels env: production and env: staging in Google Cloud Monitoring in order to monitor the performance of each version individually.

In the sample-app repository on your workstation open html.go and replace the word blue with orange (there should be exactly two occurrences):

  //snip
  <div class="card orange">
  <div class="card-content white-text">
  <div class="card-title">Backend that serviced this request</div>
  //snip

In the same repository, open main.go and change the version number from 1.0.0 to 2.0.0:

   //snip
   const version string = "2.0.0"
   //snip

Back in the console

$ git add Jenkinsfile html.go main.go
$ git commit -m "Version 2"
$ git push origin staging
  1. When your change has been pushed to the Git repository, navigate to Jenkins. Your build should start shortly.

  1. Once the build is running, click the down arrow next to the build in the left column and choose Console Output:

Track the output for a few minutes and watch for the kubectl --namespace=production apply... to begin. When it starts, open the terminal that's polling staging's /version URL and observe it start to change in some of the requests:

  1.0.0
  1.0.0
  1.0.0
  1.0.0
  2.0.0
  2.0.0
  1.0.0
  1.0.0
  1.0.0
  1.0.0

You have now rolled out that change to a subset of users.

Once the change is deployed to staging, you can continue to roll it out to the rest of your users by creating a branch called production and pushing it to the Git server:

$ git checkout master
$ git merge staging
$ git push origin master

In a minute or so you should see that the master job in the sample-app folder has been kicked off:

Clicking on the master link will show you the stages of your pipeline as well as pass/fail and timing characteristics.

Open the terminal that's polling staging's /version URL and observe that the new version (2.0.0) has been rolled out and is serving all requests.

2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0
2.0.0

Look at the Jenkinsfile in the project to see how the workflow is written.