Overview

In this exercise, you create a modern serverless continuous integration/continuous delivery (CI/CD) pipeline to automate application delivery to GKE and Anthos clusters.

The pipeline starts with a "hello world" Node.js code stored in Cloud Source Repositories in a private Git repository. Commits that are made to the master branch trigger a Cloud Build workflow, which builds a new container image, pushes it to Artifact Registry, and triggers Google Cloud Deploy as the CD part.

Google Cloud Deploy delivers the application to the dev cluster, which, after testing, allows you to promote it to a staging and production cluster. Additionally, you learn to implement approvals to ensure that code only reaches production when the right stakeholders approve the release.

Objectives

In this lab, you learn how to:

• Create and use a repository in Cloud Source Repositories.
• Set up continuous integration with Cloud Build workflows.
• Configure continuous delivery pipelines with Google Cloud Deploy.

Setup and requirements

In this task, you use Qwiklabs and perform initialization steps for your lab.

For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.

1. Sign in to Qwiklabs using an incognito window.

2. Note the lab's access time (for example, 1:15:00), and make sure you can finish within that time.
   There is no pause feature. You can restart if needed, but you have to start at the beginning.

3. When ready, click Start lab.

4. Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.

5. Click Open Google Console.

6. Click Use another account and copy/paste credentials for this lab into the prompts.
   If you use other credentials, you'll receive errors or incur charges.

7. Accept the terms and skip the recovery resource page.

After you complete the initial sign-in steps, the project dashboard appears.

8. Click Select a project, highlight your GCP Project ID, and click Open to select your project.

Activate Google Cloud Shell

Google Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud.

Google Cloud Shell provides command-line access to your Google Cloud resources.

1. In Cloud console, on the top right toolbar, click the Open Cloud Shell button.

   

2. Click Continue.

It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. For example:

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

• You can list the active account name with this command:

gcloud auth list

Output:

Credentialed accounts: - @.com (active)

Example output:

Credentialed accounts: - google1623327_student@qwiklabs.net

• You can list the project ID with this command:

gcloud config list project

Output:

[core] project =

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: Full documentation of gcloud is available in the gcloud CLI overview guide . Note: The lab environment is partially configured, and the following objects were created:

• A GKE cluster named dev-cluster.
• A GKE cluster named staging-cluster.
• A GKE cluster named prod-cluster.

Task 1. Create a basic Node.js application from the Google Cloud Console

1. Activate Cloud Shell.
2. If the tab under the Cloud Shell header does not list your project ID qwiklabs-gcp-[hex], press the down arrow to create a new Cloud Shell tab associated with the correct project.

3. Enable the required Google Cloud APIs:

   gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com \ artifactregistry.googleapis.com \ clouddeploy.googleapis.com \ cloudresourcemanager.googleapis.com

4. Export the current Qwiklabs project ID into a PROJECT_ID environmental variable:

   export PROJECT_ID=$(gcloud config list --format 'value(core.project)')

5. Set the Zone environment variable:

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

6. Authenticate to the Artifact Registry:

   gcloud auth configure-docker

7. Clone a copy of a hello world example into Cloud Shell, and change into the HelloWorldNodeJs folder that the clone operation creates:

   git clone https://github.com/haggman/HelloWorldNodeJs.git cd HelloWorldNodeJs/

   You can explore the code in the Cloud Shell Editor.

8. Use the Docker CLI to build the code into a container and push it to Artifact Registry:

   docker build -t gcr.io/$PROJECT_ID/helloworld . docker push gcr.io/$PROJECT_ID/helloworld

   The docker build command looks in the specified path (.) for a Dockerfile. If it finds one, it follows the instructions to build a Docker image (in this case adding the specified tag -t). docker push then uploads a copy of the image to Artifact Registry.

9. In the Google Cloud Console, navigate to Artifact Registry and confirm that the image was created and uploaded as expected.

Click Check my progress to verify the objective. Create a basic Node.js application from the Google Cloud Console

Task 2. Configure your CI/CD pipeline with Cloud Build and Google Cloud Deploy

In the previous task, you took code from a Git repository, used Docker to build an image, and pushed it to Artifact Registry. Cloud Build allows you to create workflows of build steps similar to the kind you executed manually. Google and the Cloud Build community have created several builders, each usable by name.

In this task, you create a cloudbuild.yaml file to define the build workflow: build the image, push it to Artifact Registry, and finally push it to Google Cloud Deploy. From there, Google Cloud Deploy manages continuous delivery. You then test for correctness.

1. Create a cloudbuild.yaml file, which executes the same steps you just performed manually:

   cat <<EOF > cloudbuild.yaml steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/$PROJECT_ID/helloworld', '.'] # Push the container image to Artifact Registry - name: 'gcr.io/cloud-builders/docker' args: ['push', 'gcr.io/$PROJECT_ID/helloworld'] # Create release in Google Cloud Deploy - name: gcr.io/google.com/cloudsdktool/cloud-sdk entrypoint: gcloud args: [ "beta", "deploy", "releases", "create", "rel-\${SHORT_SHA}a", "--delivery-pipeline", "helloworld-pipeline", "--region", "us-central1", "--annotations", "commitId=\${REVISION_ID}", "--images", "helloworld=gcr.io/$PROJECT_ID/helloworld" ] options: logging: CLOUD_LOGGING_ONLY EOF

The file name cloudbuild.yaml is the expected default, but you can give it a custom name. At its most basic, the cloudbuild.yaml file lays out the steps the Cloud Build worker should complete. The file can then be manually passed to Cloud Build or automated as part of a trigger.

2. Create a clouddeploy.yaml file to specify the delivery pipeline containing the target platforms where the helloworld file should be delivered; in this case, the three existing GKE clusters: dev-cluster, staging-cluster, and prod-cluster:

   cat <<EOF > clouddeploy.yaml apiVersion: deploy.cloud.google.com/v1beta1 kind: DeliveryPipeline metadata: name: helloworld-pipeline description: helloworld application delivery pipeline serialPipeline: stages: - targetId: dev profiles: [] - targetId: staging profiles: [] - targetId: prod profiles: [] --- apiVersion: deploy.cloud.google.com/v1beta1 kind: Target metadata: name: dev description: dev cluster gke: cluster: projects/$PROJECT_ID/locations/$CLUSTER_ZONE/clusters/dev-cluster --- apiVersion: deploy.cloud.google.com/v1beta1 kind: Target metadata: name: staging description: staging cluster gke: cluster: projects/$PROJECT_ID/locations/$CLUSTER_ZONE/clusters/staging-cluster --- apiVersion: deploy.cloud.google.com/v1beta1 kind: Target metadata: name: prod description: prod cluster requireApproval: true gke: cluster: projects/$PROJECT_ID/locations/$CLUSTER_ZONE/clusters/prod-cluster EOF

Note: Notice that prod-cluster requires an approval before the rollout can occur.

3. Create the skaffold.yaml file to specify the Kubernetes YAML files to be deployed by Google Cloud Deploy:

   cat <<EOF > skaffold.yaml apiVersion: skaffold/v2beta16 kind: Config deploy: kubectl: manifests: - kubernetes-app.yaml EOF

4. Create the Kubernetes files to be deployed to the clusters:

   cat <<EOF > kubernetes-app.yaml apiVersion: apps/v1 kind: Deployment metadata: name: hello-world-demo spec: replicas: 3 selector: matchLabels: app: hello-world-demo template: metadata: labels: app: hello-world-demo spec: containers: - name: hello-world-demo image: gcr.io/${PROJECT_ID}/helloworld ports: - containerPort: 8080 env: - name: PORT value: "8080" --- apiVersion: v1 kind: Service metadata: name: hello-world-demo spec: type: LoadBalancer selector: app: hello-world-demo ports: - port: 80 targetPort: 8080 EOF

5. Deploy the clouddeploy.yaml file to Google Cloud Deploy to configure the release pipeline:

   gcloud beta deploy apply --file clouddeploy.yaml \ --region=us-central1 --project=$PROJECT_ID

6. In the Google Cloud Console, navigate to Cloud Deploy and confirm that the pipeline was created.

7. Click on helloworld-pipeline to open it and view the pipeline.

8. Use Cloud Build to execute the workflow:

   gcloud builds submit --config cloudbuild.yaml

9. In the Google Cloud Console, navigate to Cloud Deploy, open the pipeline you created earlier, and wait for the release to be deployed to dev-cluster.

10. In the Google Cloud Console, navigate to Kubernetes Engine > Gateways, Services & Ingress, click on Services tab and locate the hello-world-demo service, and click on the link with the public IP address to see the deployed application running on dev-cluster.

Click Check my progress to verify the objective. Configure your CI/CD pipeline with Cloud Build and Google Cloud Deploy

Task 3. Automate continuous integration using a Cloud Build trigger

For this task, you use a very simplified development process. You commit changes to the Git repository local to Cloud Shell and push the changes to the remote repository. When changes are pushed to Cloud Source Repositories master branch, a Cloud Build trigger based on the cloudbuild.yaml file created earlier is executed, which builds the image, pushes it to Artifact Registry, and schedules a Google Cloud Deploy release.

1. In Cloud Shell, initialize and configure Git for use:

   git init git config --global user.email "you@example.com" git config --global user.name "Student"

2. Stage the code for commit in the local Cloud Shell Git repository, and make the initial commit:

   git add . git commit -m "Initial commit"

3. Create a new helloworld Git repository in your Cloud repository:

   gcloud source repos create helloworld

   Git allows for the creation of remote team repositories for sharing code between developers.

4. In Cloud Shell, create a remote link to the Git repository created in the previous step, and name it to-google:

   git remote add to-google https://source.developers.google.com/p/$PROJECT_ID/r/helloworld

5. Push the code from your local Cloud Shell repository to the Google repository helloworld master branch:

   git push to-google master

6. In the Google Cloud Console, navigate to Source Repositories and investigate your new repo.

The code is written locally and stored in a central repository, the build steps are defined in a cloudbuild.yaml file, and the deployment steps are specified in the clouddeploy.yaml file. The last step is to create a trigger to put it all together.

7. In the Google Cloud Console, navigate to Cloud Build > Triggers.

8. Click on the CREATE TRIGGER button.

9. Enter the name HelloWorldJS.

10. Under Source, enter select the repository to be helloworld (Cloud Source Repositories) and the branch to match ^master$.

11. Under Configuration, select Cloud Build configuration file, and enter /cloudbuild.yaml as the Cloud Build configuration file location.

12. Under Service Account, select XXXXXXXXX-compute@developer.gserviceaccount.com. Please note the warning, in a production setting, declare a dedicated service account with limited IAM Permissions.

13. Click on CREATE to create the trigger.

14. When the trigger is ready, to test the trigger's logic, click RUN. If a window pops up to select a branch, enter master and press RUN TRIGGER.

15. Navigate to Cloud Build > History and wait for the build workflow to complete.

16. Navigate to Cloud Deploy and confirm that the new pipeline has been triggered.

Test the process

1. Return to Cloud Shell and edit the services code:

   edit index.js

2. Make a change to the services returned message; for example, change World to World 2.

3. Stage and commit the change to your local developers Git repository, and then push the change to the repository:

   git add . git commit -m "Message updated" git push to-google master

4. Return to the Google Cloud Console and navigate to Cloud Build > History.

5. When the trigger is finished executing, go to Cloud Deploy and wait for the deployment to occur.

6. Re-load the application and confirm that the new message is displayed.

Click Check my progress to verify the objective. Automate continuous integration using a Cloud Build trigger

Task 4. Promote and approve releases

You have been working out of dev-cluster, which is great for developing and testing new features of your application. However, after those features have been developed, you might want to expose them to an internal audience in a staging environment for further testing and eventually deploy them to a production environment.

In this task, you learn how to promote your application to other environments and use approvals for stakeholders to approve a release.

1. In the Google Cloud Console, navigate to Cloud Deploy and open your pipeline.

2. In the pipeline visualization area, click on the 3-dot menu in the dev target box. Notice the following actions:

   • Promote release: Launches your application to the next target; in this case, staging-cluster.
   • Re-deploy release: If an error occurs, you can try to redeploy the current version to dev-cluster to fix any transient issues.
   • Roll back release: Discard the latest release and bring the previous version of your application to the target cluster.

3. To deploy your application to staging, click Promote release. Investigate the options in the pop-up window, and check the Manifest Diff tab to check the differences with the previous version.

4. Click Promote.

5. After the application is deployed, to see the deployed application running on staging-cluster, navigate to Kubernetes Engine > Gateways, Services & Ingress, click on Services tab.

6. Locate the hello-world-demo service and click on the link with the public IP address.

7. To promote the release from staging to production, return to Cloud Deploy, open your pipeline, click Promote in the staging box, and then in the dialog, click Promote again. Notice that this time the promotion has been blocked by a review action that you specified earlier in the clouddeploy.yaml.

8. In the visualization area between staging and production, click Review.

9. After reviewing the changes, click Approve. Usually, approvals would be done by a different person or team.

10. Return to your Cloud Deploy pipeline visualization, and click on the release that is deployed to prod-cluster.

11. Click again on the rollout to open a details window and open the Render logs and Deployment logs. Here you can debug if there are any issues in the deployment. Notice that the actual deployment also runs on a Cloud Build runner.

12. After the rollout has finished, to see the deployed application running on prod-cluster, navigate to Kubernetes Engine > Gateways, Services & Ingress, click on Services tab, locate to the hello-world-demo service, and click on the link with the public IP address.

Click Check my progress to verify the objective. Promote and approve releases

Congratulations!

You have used Cloud Source Repositories, Cloud Build, and Google Cloud Deploy to automate the application delivery to GKE and Anthos clusters. You also learned how to promote and approve releases to staging and production clusters.

End your lab

When you have completed your lab, click End Lab. Google Cloud Skills Boost removes the resources you’ve used and cleans the account for you.

You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.

The number of stars indicates the following:

• 1 star = Very dissatisfied
• 2 stars = Dissatisfied
• 3 stars = Neutral
• 4 stars = Satisfied
• 5 stars = Very satisfied

You can close the dialog box if you don't want to provide feedback.

For feedback, suggestions, or corrections, please use the Support tab.

Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.