Skip to content

Latest commit

 

History

History
138 lines (98 loc) · 5.82 KB

tutorial.md

File metadata and controls

138 lines (98 loc) · 5.82 KB
Raw

Google Cloud End to End CI/CD tutorial

This tutorial will help you get up and running with Google Cloud CI/CD, including Cloud Build, Google Cloud Deploy, and Artifact Registry

Select a project

Once you've selected a project, click "Start".

Set the PROJECT_ID environment variable

Set the PROJECT_ID environment variable. This variable will be used in forthcoming steps.

export PROJECT_ID=<walkthrough-project-id/>

Enable needed APIs and Create Google Cloud Deploy pipeline

The bootstrap/init.sh script enables your APIs, customizes your clouddeploy.yaml and creates a Cloud Deploy pipeline for you. You'll still need to do some steps manually after these scripts run, though.

Run the initialization script:

. ./bootstrap/init.sh

Check out your Google Cloud Deploy Pipeline

Verify that the Google Cloud Deploy pipeline was created in the Google Cloud Deploy UI

(Optional) Turn on automated container vulnerability analysis

Google Cloud Container Analysis can be set to automatically scan for vulnerabilities on push (see pricing).

Enable Container Analysis API for automated scanning:

Configure your Github.com repo

If you have not fork this repo yet, please do so now:

Fork this repo on Github

To keep file changes you make in Cloud Shell in sync with your repo, you can check these file changes into your new Github repo by following these docs. Note that the Github CLI is available in Cloud Shell.

Setup a Cloud Build trigger for your repo

Now that your Github repo is setup, configure Cloud Build to run each time a change is pushed to the main branch. To do this, add a Trigger in Cloud Build:

Create GKE clusters

You'll need GKE clusters to deploy to. The Google Cloud Deploy pipeline in this example refers to three clusters:

  • testcluster
  • stagingcluster
  • productcluster

If you have/want different cluster names update cluster definitions in:

  • bootstrap/gke-cluster-init.sh
  • clouddeploy.yaml
  • bootstrap/gke-cluster-delete.sh

Create the three GKE Autopilot clusters

. ./bootstrap/gke-cluster-init.sh

Note that these clusters are created asynchronously, so check on the GKE UI periodically to ensure that the clusters are up before submitting your first release to Google Cloud Deploy.

IAM and service account setup

You must give Cloud Build explicit permission to trigger a Google Cloud Deploy release.

  1. Read the docs
  2. Navigate to IAM and locate your Cloud Build service account
  3. Add these two roles
  • Cloud Deploy Releaser
  • Service Account User

Demo Overview

Demo flow

The demo flow outlines a typical developer pathway, submitting a change to a Git repo which then triggers a CI/CD process:

  1. Push a change the main branch of your forked repo. You can make any change such as a trivial change to the README.md file.
  2. A Cloud Build job is automatically triggered, using the cloudbuild.yaml configuration file, which:
  • builds and pushes impages to Artifact Registry
  • creates a Google Cloud Deploy release in the pipeline
  1. You can then navigate to Google Cloud Deploy UI and shows promotion events:
  • test cluster to staging clusters
  • staging cluster to product cluster, with approval gate

Tear down

To remove the three running GKE clusters, run:

. ./bootstrap/gke-cluster-delete.sh

Local dev (optional)

To run this app locally, start minikube:

minikube start

From the pop-kustomize directory, run:

skaffold dev

The default skaffold settings use the "dev" Kustomize overlay. Once running, you can make file changes and observe the rebuilding of the container and redeployment. Use Ctrl-C to stop the Skaffold process.

To test the staging overlays/profile run:

skaffold dev --profile staging

To test the staging overlays/profile locally, run:

skaffold dev --profile prod