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.
First we will need to configure our GCP credentials in order for Jenkins to be able to access our code repository
- In the Jenkins UI, Click “Credentials” on the left
- Click either of the “(global)” links (they both route to the same URL)
- Click “Add Credentials” on the left
- From the “Kind” dropdown, select “Google Service Account from metadata”
- 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:
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
):
-
Click the “Jenkins” link in the top left of the interface
-
Click the New Item link in the left nav
-
Name the project sample-app, choose the Multibranch Pipeline option, then click
OK
-
Click
Add Source
and choosegit
-
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 -
From the Credentials dropdown select the name of new created credentials from the Phase 1.
-
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.
-
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.
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
- When your change has been pushed to the Git repository, navigate to Jenkins. Your build should start shortly.
- 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.