Lab5
Lab5 : Continuous Delivery with Jenkins in Kubernetes Engine
Goal
Learn how to set up a continuous delivery pipeline with Jenkins on Kubernetes engine.
Jenkins is the go-to automation server used by developers who frequently integrate their code in a shared repository.
Provision a Jenkins application into a Kubernetes Engine Cluster
Set up your Jenkins application using Helm Package Manager
Explore the features of a Jenkins application
Create and exercise a Jenkins pipeline
In the Cloud Architecture Center, see Jenkins on Kubernetes Engine to learn more about running Jenkins on Kubernetes.
What is Kubernetes Engine?
Kubernetes Engine is Google Cloud's hosted version of Kubernetes - a powerful cluster manager and orchestration system for containers. Kubernetes is an open source project that can run on many different environmentsโfrom laptops to high-availability multi-node clusters; from virtual machines to bare metal. As mentioned before, Kubernetes apps are built on containers - these are lightweight applications bundled with all the necessary dependencies and libraries to run them. This underlying structure makes Kubernetes applications highly available, secure, and quick to deployโan ideal framework for cloud developers.
What is Jenkins?
Jenkins is an open-source automation server that lets you flexibly orchestrate your build, test, and deployment pipelines. Jenkins allows developers to iterate quickly on projects without worrying about overhead issues that can stem from continuous delivery.
Task 1. Download the source code
set up the your zone
copy the sample code.
Task 2. Provisioning Jenkins
Creating a Kubernetes cluster
Run following command to provision a Kubernetes cluster:
The extra scopes enable Jenkins to access Cloud Source Repositories and Google Container Registry.
2. Confirm that your cluster is running by executing the following command:
3. Get the credentials for your cluster
4. Kubernetes Engine uses these credentials to access your newly provisioned cluster- confirm that you can connect to it by running the following command:
Task 3. Setup Helm
Use Helm to install Jenkins from the Charts repository.
Helm is a package manager that makes it easy to configure and deploy Kubernetes applications. Once you have Jenkins installed, youโll be able to set up your CI/CD pipeline.
Add Helmโs stable chart repo
2. Ensure the repo is up do date
Task 4. Configure and Install Jenkins
When installing Jenkins, a values file can be used as a template to provide values that are necessary for setup.
You will use a custom values file to automatically configure your Kubernetes Cloud and add the following necessary plugins:
Kubernetes:1.29.4
Workflow-multibranch:latest
Git:4.7.1
Configuration-as-code:1.51
Google-oauth-plugin:latest
Google-source-plugin:latest
Google-storage-plugin:latest
This will allow Jenkins to connect to your cluster and your GCP project.
Download the custom values file
2. Use the Helm CLI to deploy the chart with your configuration settings
3. Ensure the Jenkins pod goes to the Running state and the container is in the READY state
4. Configure the Jenkins service account to be able to deploy the cluster
5. Run the following command to setup port forwarding to the Jenkins UI from the Cloud Shell:
6. Now check that the Jenkins Service was created properly:
You are using the Kubernetes Plugin so that our builder nodes will be automatically launched as necessary when the Jenkins master requests them. Upon completion of their work, they will automatically be turned down and their resources added back to the clusters resource pool.
Notice that this service exposes ports 8080 and 50000 for any pods that match the selector. This will expose the Jenkins web UI and builder/agent registration ports within the Kubernetes cluster. Additionally, the jenkins-ui services is exposed using a ClusterIP so that it is not accessible from outside the cluster.
Task 5. Connect to Jenkins
The Jenkins chart will automatically create an admin password for you.
2. Get Jenkins user interface
3. Login with the account.
Jenkins will drvie your automated CI/CD pipelines in the next sections.
Task 6. Understanding the Application
The sample application gceme
In backend mode: gceme listens on port 8080 and returns Compute Engine instance metadata in JSON format.
In frontend mode: gceme queries the backend gceme service and renders the resulting JSON in the user interface.
Task 7. Deploying the Application
Deploy the application into two different enviornments:
Production: The live site that your users access.
Canary: A smaller-capacity site that receives only a percentage of your user traffic. Use this environment to validate your software with live traffic before it's released to all of your users.
Navigate to the sample application directory and create the kubernetes namespace to logically isolate the deployment.
2
Create the production and canary deployments, and the services using the kubectl apply commands
By default, only one replica of the frontend is deployed. Use the kubectl scale command to ensure that there are at least 4 replicas running at all times.
3. Scale up the production environment frontends
4. Confirm that you have 5 pods running for the frontend, 4 for the production traffic and 1 for canary releases (changes to the canary release will only affect 1 out of 5 (20%) of users)
5. Also confirm that you have 2 pods for the backend, 1 for production and 1 for canary:
6. Retrieve the external IP for the production services
Paste External IP into a browser and youโll see this card
7. Store the frontend service load balancer IP in an environment variable for use later
8. Confirm that both services are working by opening the frontend external IP address in your browser.
9. Check the version output of the service by running the following command.
You have successfully deployed the sample application!
Now set up a pipeline for deploying your changes continuously and reliably.
Task 8. Creating the Jenkins Pipeline
Creating a repository to host the sample app source code.
Create a copy of the gceme sample app and push it to a Cloud Source Repository (GCR)
2. Initialize the sample-app directory as its own Git repository
3. add, commit, and push the files to git
Adding your service account credentials
Configure your credentials to allow Jenkins to access the code repository. Jenkins will use your cluster's service account credentials in order to download code from the Cloud Source Repositories.
Jenkins UI โ Manage Jenkins โ Manage Credentials โ Jenkins
Global credentials โ Add Credentials โ Google Service Account from metadata from Kind drop-down
The global credentials has been added.
Create new item
Multibranch Pipeline โ Branch Sources โ git
After you complete these steps, a job named Branch indexing runs. This meta-job identifies the branches in your repository and ensures changes haven't occurred in existing branches. If you click sample-app in the top left, the master job should be seen.
Task 9. Creating the development environment
Development branches are a set of environments your developers use to test their code changes before submitting them for integration into the live site. These environments are scaled-down versions of your application, but need to be deployed using the same mechanisms as the live environment.
Creating a development branch
Modifying the pipeline definition
The Jenkinsfile that defines that pipeline is written using the Jenkins Pipeline Groovy syntax. Using a Jenkinsfile allows an entire build pipeline to be expressed in a single file that lives alongside your source code. Pipelines support powerful features like parallelization and require manual user approval.
In order for the pipeline to work as expected, you need to modify the Jenkinsfile to set your project ID.
Open the Jenkinsfile and edit
Modify the site
To demonstrate changing the application, you wil change the gceme cards from blue to orange.
then change <div class="card blue"> to
open main.go
change the version 1.0.0 into 2.0.0
Task 10. Kick off Deployment
Commit and push your changes
After the change is pushed to the Git repository, navigate to the Jenkins user interface where you can see that your build started for the new-feature branch. It can take up to a minute for the changes to be picked up.
Task 11. Deploying a canary release
You have verified that your app is running the latest code in the development environment, so now deploy that code to the canary environment.
Create a canary branch and push it to the Git server
In Jenkins, you should see the canary pipeline has kicked off. Once complete, you can check the service URL to ensure that some of the traffic is being served by your new version. You should see about 1 in 5 requests (in no particular order) returning version 2.0.0.
Task 12. Deploying to production
Now that our canary release was successful and we haven't heard any customer complaints, deploy to the rest of your production fleet.
Create a canary branch and push it to the Git server
2. Once complete (which may take a few minutes), you can check the service URL to ensure that all of the traffic is being served by your new version, 2.0.0.
3. Once again, if you see instances of 1.0.0 try running the above commands again. You can stop this command by pressing Ctrl + C.
๋!!
Last updated