Deploying to Google Kubernetes Engine

You can deploy to Google Kubernetes Engine as part of your continuous deployment (CD) workflows.

Dans cet article

Introduction

This guide explains how to use GitHub Actions to build a containerized application, push it to Google Container Registry (GCR), and deploy it to Google Kubernetes Engine (GKE) when there is a push to the main branch.

GKE is a managed Kubernetes cluster service from Google Cloud that can host your containerized workloads in the cloud or in your own datacenter. For more information, see Google Kubernetes Engine.

Remarque

Si vos workflows GitHub Actions doivent accéder aux ressources d’un fournisseur de cloud qui prend en charge OpenID Connecter (OIDC), vous pouvez configurer vos workflows pour qu’ils s’authentifient directement auprès du fournisseur de cloud. Cela vous permet d’arrêter de stocker ces informations d’identification en tant que secrets de longue durée, et de fournir d’autres avantages en matière de sécurité. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Prerequisites

Before you proceed with creating the workflow, you will need to complete the following steps for your Kubernetes project. This guide assumes the root of your project already has a Dockerfile and a Kubernetes Deployment configuration file.

Creating a GKE cluster

To create the GKE cluster, you will first need to authenticate using the gcloud CLI. For more information on this step, see the following articles:

For example:

Shell
$ gcloud container clusters create $GKE_CLUSTER \
	--project=$GKE_PROJECT \
	--zone=$GKE_ZONE

Enabling the APIs

Enable the Kubernetes Engine and Container Registry APIs. For example:

Shell
$ gcloud services enable \
	containerregistry.googleapis.com \
	container.googleapis.com

Configuring a service account and storing its credentials

This procedure demonstrates how to create the service account for your GKE integration. It explains how to create the account, add roles to it, retrieve its keys, and store them as a base64-encoded encrypted repository secret named GKE_SA_KEY.

  1. Create a new service account:

    Shell
    gcloud iam service-accounts create $SA_NAME

  2. Retrieve the email address of the service account you just created:

    Shell
    gcloud iam service-accounts list

  3. Add roles to the service account.

    Remarque

    Apply more restrictive roles to suit your requirements.

    Shell
    gcloud projects add-iam-policy-binding $GKE_PROJECT \
  --member=serviceAccount:$SA_EMAIL \
  --role=roles/container.admin
gcloud projects add-iam-policy-binding $GKE_PROJECT \
  --member=serviceAccount:$SA_EMAIL \
  --role=roles/storage.admin
gcloud projects add-iam-policy-binding $GKE_PROJECT \
  --member=serviceAccount:$SA_EMAIL \
  --role=roles/container.clusterViewer

  4. Download the JSON keyfile for the service account:

    Shell
    gcloud iam service-accounts keys create key.json --iam-account=$SA_EMAIL

  5. Store the service account key as a secret named GKE_SA_KEY:

    Shell
    export GKE_SA_KEY=$(cat key.json | base64)

    For more information about how to store a secret, see Using secrets in GitHub Actions.

Storing your project name

Store the name of your project as a secret named GKE_PROJECT. For more information about how to store a secret, see Using secrets in GitHub Actions.

(Optional) Configuring kustomize

Kustomize is an optional tool used for managing YAML specs. After creating a kustomization file, the workflow below can be used to dynamically set fields of the image and pipe in the result to kubectl. For more information, see kustomize usage.

(Optional) Configure a deployment environment

Les environnements sont utilisés pour décrire une cible de déploiement général comme production, staging ou development. Quand un workflow GitHub Actions est déployé dans un environnement, l’environnement s’affiche dans la page principale du dépôt. Vous pouvez utiliser les environnements pour exiger l’approbation d’un travail, restreindre les branches pouvant déclencher un flux de travail, contrôler les déploiements avec des règles personnalisées de protection des déploiements ou limiter l’accès aux secrets. Pour plus d’informations sur la création d’environnements, consultez Managing environments for deployment.

Creating the workflow

Once you've completed the prerequisites, you can proceed with creating the workflow.

The following example workflow demonstrates how to build a container image and push it to GCR. It then uses the Kubernetes tools (such as kubectl and kustomize) to pull the image into the cluster deployment.

Under the env key, change the value of GKE_CLUSTER to the name of your cluster, GKE_ZONE to your cluster zone, DEPLOYMENT_NAME to the name of your deployment, and IMAGE to the name of your image.

Si vous avez configuré un environnement de déploiement, remplacez la valeur environment par le nom de votre environnement. Si vous n’avez pas configuré d’environnement ou si votre workflow se trouve dans un référentiel privé et que vous n’utilisez pas GitHub Enterprise Cloud, supprimez la clé environment.

YAML
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.

# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.

name: Build and Deploy to GKE

on:
  push:
    branches:
      - main

env:
  PROJECT_ID: ${{ secrets.GKE_PROJECT }}
  GKE_CLUSTER: cluster-1    # Add your cluster name here.
  GKE_ZONE: us-central1-c   # Add your cluster zone here.
  DEPLOYMENT_NAME: gke-test # Add your deployment name here.
  IMAGE: static-site

jobs:
  setup-build-publish-deploy:
    name: Setup, Build, Publish, and Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    # Setup gcloud CLI
    - uses: google-github-actions/setup-gcloud@1bee7de035d65ec5da40a31f8589e240eba8fde5
      with:
        service_account_key: ${{ secrets.GKE_SA_KEY }}
        project_id: ${{ secrets.GKE_PROJECT }}

    # Configure Docker to use the gcloud command-line tool as a credential
    # helper for authentication
    - run: |-
        gcloud --quiet auth configure-docker

    # Get the GKE credentials so we can deploy to the cluster
    - uses: google-github-actions/get-gke-credentials@db150f2cc60d1716e61922b832eae71d2a45938f
      with:
        cluster_name: ${{ env.GKE_CLUSTER }}
        location: ${{ env.GKE_ZONE }}
        credentials: ${{ secrets.GKE_SA_KEY }}

    # Build the Docker image
    - name: Build
      run: |-
        docker build \
          --tag "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA" \
          --build-arg GITHUB_SHA="$GITHUB_SHA" \
          --build-arg GITHUB_REF="$GITHUB_REF" \
          .

    # Push the Docker image to Google Container Registry
    - name: Publish
      run: |-
        docker push "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA"

    # Set up kustomize
    - name: Set up Kustomize
      run: |-
        curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
        chmod u+x ./kustomize

    # Deploy the Docker image to the GKE cluster
    - name: Deploy
      run: |-
        ./kustomize edit set image gcr.io/PROJECT_ID/IMAGE:TAG=gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA
        ./kustomize build . | kubectl apply -f -
        kubectl rollout status deployment/$DEPLOYMENT_NAME
        kubectl get services -o wide

Additional resources

For more information on the tools used in these examples, see the following documentation: