Build container images

 Cloud Build provides pre-built images that you can reference in a Cloud Build config file to execute your tasks. These images are supported and maintained by Google Cloud. You can use the supported, pre-built Docker image to execute Docker commands and build Docker images.

The instructions on this page assume that you are familiar with Docker. In addition:

  • Have your application source code along with Dockerfile handy.
  • Have a Docker repository for storing images in Artifact Registry, or create a new repository.
  • If you want to use the gcloud commands in this page, install the Google Cloud CLI.
  • If you want to run the images, install Docker
  • If you want to sign the images with cosign, follow the instructions in Authorize service-to-service access to create a user-specified service account and grant the permissions required to generate ID tokens.

To build your Docker image using a build config file:

  1. In the same directory that contains your application source code, create a file named cloudbuild.yaml or cloudbuild.json.

  2. In the build config file:

    • Add a name field and specify the pre-built Docker image. The pre-built image is stored at gcr.io/cloud-builders/docker. In the example config file below, the name field specifies that the pre-built Docker image is used by Cloud Build to execute the task indicated by the args field.

    • In the args field, add the arguments to build the image.

      YAMLJSON
      steps:
      - name: 'gcr.io/cloud-builders/docker'
        args      : [ 'build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME', '.' ]

      Replace the placeholder values in the above build config with the following:

    • LOCATION: the regional or multi-regional location of your Docker repository in Artifact Registry.

    • PROJECT_ID: your Google Cloud project ID.

    • REPOSITORY: the name of your Docker repository in Artifact Registry.

    • IMAGE_NAME: the name of your container image.

      If your Dockerfile and source code are in different directories, add -f and the path to the Dockerfile to the list of arguments in the args field:

      YAMLJSON
      steps:
      - name: 'gcr.io/cloud-builders/docker'
        args      : [ 'build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME', '-f', 'DOCKERFILE_PATH', '.' ]

      Replace the placeholder values in the above build config with the following:

      • LOCATION: the regional or multi-regional location for your repository.
      • PROJECT_ID: your Google Cloud project ID.
      • REPOSITORY: the name of your Artifact Registry repository.
      • IMAGE_NAME: the name of your container image.
      • DOCKERFILE_PATH: path to your Dockerfile.

  3. Start the build using the build config file:

    gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY

    Replace the placeholder values in the above command with the following:

    • CONFIG_FILE_PATH: the path to the build config file.
    • SOURCE_DIRECTORY: the path or URL to the source code.

    If you don't specify a CONFIG_FILE_PATH and SOURCE_DIRECTORY in the gcloud builds submit command, Cloud Build assumes that the config file and the source code are in the current working directory.

Cloud Build allows you to build a Docker image using just a Dockerfile. You don't require a separate build config file.

To build using a Dockerfile, run the following command from the directory containing your source code and the Dockerfile:

    gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

Replace the placeholder values in the above command with the following:

  • LOCATION: the regional or multi-regional location for your repository.
  • PROJECT_ID: your Google Cloud project ID.
  • REPOSITORY: the name of your Artifact Registry repository.
  • IMAGE_NAME: the name of your container image.

Cloud Build allows you to build an image without a Dockerfile or a build config file. You can do this using Google Cloud's buildpacks.

To build using buildpacks, run the following command from the directory containing your source code:

    gcloud builds submit --pack builder=BUILDPACK_BUILDER, \
        env=ENVIRONMENT_VARIABLE, \
        image=IMAGE_NAME

Replace the placeholder values in the above commands with the following:

  • BUILDPACK_BUILDER: the buildpacks builder to use. If you don't specify a builder, Cloud Build uses gcr.io/buildpacks/builder by default.
  • ENVIRONMENT_VARIABLE: any environment variables for your build.
  • IMAGE: the URL of the image in Artifact Registry. The image URL must be in the format LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME.

Here are some example commands:

  • Running a build using the default gcr.io/buildpacks/builder to create the image us-docker.pkg.dev/gcb-docs-project/containers/gke/hello-app:

      gcloud builds submit --pack image=us-docker.pkg.dev/gcb-docs-project/containers/gke/hello-app

  • Passing multiple environment variables to your build using ^--^ as a separator. For more information about escaping arguments, see gcloud topic escaping.

      gcloud builds submit --pack \
              ^--^image=gcr.io/my-project/myimage--env=GOOGLE_ENTRYPOINT='java -jar target/myjar.jar',GOOGLE_RUNTIME_VERSION='3.1.301'

Configuring triggers to use buildpacks: In addition to building using the command line, you can configure triggers to use buildpacks to build your image automatically. To learn more, see Creating and managing build triggers.

You can configure Cloud Build to store your built image in one of the following ways:

  • using the images field, which stores the image in Artifact Registry after your build completes.
  • using the docker push command, which stores the image in Artifact Registry as part of your build flow.

The difference between using the images field and the Docker push command is that if you use the images field, the stored image will be displayed in the build results. This includes the Build description page for a build in the Google Cloud console, the results of Build.get(), and the results of gcloud builds list. However, if you use the Docker push command to store the built image, the image will not be displayed in the build results.

If you want to store the image as part of your build flow and want to display the image in the build results, use both the Docker push command and the images field in your build config file.

To store a container image in Artifact Registry after your build completes:

  1. If the target repository does not exist, create a new repository.
  2. In the same directory that contains your application source code and Dockerfile, create a file named cloudbuild.yaml or cloudbuild.json.

  3. In your build config file, add a build step to build an image and then add an images field specifying the built image. This stores the image in Artifact Registry. The following snippet shows a build config to build an image and store it in Artifact Registry:

    YAMLJSON
    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args    : [ 'build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME', '.' ]
    images    : ['LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME']

    Where:

    • LOCATION: the regional or multi-regional location for your repository.
    • PROJECT_ID: your Google Cloud project ID.
    • REPOSITORY: the name of your Artifact Registry repository.
    • IMAGE_NAME: the name of your container image.

  4. Start the build using the build config file:

    gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY

    Where:

    • CONFIG_FILE_PATH is the path to the build config file.
    • SOURCE_DIRECTORY is the path or URL to the source code.

To store the image in Artifact Registry as part of your build flow:

  1. In the same directory that contains your application source code and Dockerfile, create a file named cloudbuild.yaml or cloudbuild.json.

  2. In your build config file, add a docker build step to build an image and then add another docker build step and pass arguments to invoke the push command:

    YAMLJSON
    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args    : ['build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME', '.']
    - name: 'gcr.io/cloud-builders/docker'
      args    : ['push', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME']

    Where:

    • LOCATION: the regional or multi-regional location for your repository.
    • PROJECT_ID: your Google Cloud project ID.
    • REPOSITORY: the name of your Artifact Registry repository.
    • IMAGE_NAME: the name of your container image.

  3. Start the build using the build config file:

    gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY

    Where:

    • CONFIG_FILE_PATH is the path to the build config file.
    • SOURCE_DIRECTORY is the path or URL to the source code.

To store an image as part of your build flow and to display the image in the build results:

  1. In the same directory that contains your application source code and Dockerfile, create a file named cloudbuild.yaml or cloudbuild.json.

  2. In your build config file, after the step that builds the image, add a step to invoke the Docker push command and then add the images field:

    YAMLJSON
    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args    : ['build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME', '.']
    - name: 'gcr.io/cloud-builders/docker'
      args    : ['push', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME']
    images    : ['LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME']

    Where:

    • LOCATION: the regional or multi-regional location for your repository.
    • PROJECT_ID: your Google Cloud project ID.
    • REPOSITORY: the name of your Artifact Registry repository.
    • IMAGE_NAME: the name of your container image.

  3. Start the build using the build config file:

    gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY

    Where:

    • CONFIG_FILE_PATH is the path to the build config file.
    • SOURCE_DIRECTORY is the path or URL to the source code.

If you're storing images in Artifact Registry, you can add another layer of security by using the cosign tool to create a record of which service account is used to initiate a build. Backed by the OpenID Connect (OIDC) standard, auditors can use that record to verify that an image was built by a trusted service account.

The following steps demonstrate how to use your cloudbuild.yaml config file to get an identity token and sign your container image.

YAMLJSON
  steps:
  - name: 'gcr.io/cloud-builders/docker'
    id: 'tag-and-push'
    script: |
      #!/bin/sh
      set -e
      docker build -t $_IMAGE .
      docker push "$_IMAGE"
      docker inspect $_IMAGE --format "$_IMAGE@{{.Id}}" >image_with_digest
  - name: 'gcr.io/cloud-builders/gcloud'
    id: 'generate-token'
    script: |
      #!/bin/sh
      set -e
      gcloud auth print-identity-token --audiences=sigstore > token
  - name: 'gcr.io/cloud-builders/docker'
    id: 'sign-image'
    script: |
      #!/bin/sh
      set -e
      docker run \
      --network=cloudbuild \
      --mount source=home-volume,target=/builder/home \
      --rm \
      -e SIGSTORE_NO_CACHE=true \
      -e HOME=/builder/home \
      gcr.io/projectsigstore/cosign \
      sign --identity-token=$(cat token) $(cat image_with_digest) -y
  service_account: '$_SERVICE_ACCOUNT'
  artifacts:
    images:
    - $_IMAGE
  substitutions:
    _IMAGE: 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME'
    _SERVICE_ACCOUNT_ID: 'SERVICE_ACCOUNT_ID'
    _SERVICE_ACCOUNT: projects/${PROJECT_ID}/serviceAccounts/${_SERVICE_ACCOUNT_ID}
  options:
    env:
    - '_IMAGE=$_IMAGE'
    dynamic_substitutions: true
    logging: CLOUD_LOGGING_ONLY

  • LOCATION is the regional or multi-regional location of the repository where the image is stored, for example us-east1 or us.

  • PROJECT_ID: your Google Cloud project ID.

  • REPOSITORY is the name of the repository where the image is stored.

  • IMAGE_NAME is the image's name.

  • SERVICE_ACCOUNT_ID is the email address of the user-specified service account you want to run your build. For example, a service account email address looks like: service-account-name@project-id.iam.gserviceaccount.com.

To verify the signature, install cosign on your local machine, then run the cosign verify command:

cosign verify \
--certificate-identity=SERVICE_ACCOUNT_ID \
--certificate-oidc-issuer=https://accounts.google.com \
IMAGE

Where:

  • SERVICE_ACCOUNT_ID is the email address of the trusted service account that you expect to have been used to build the container image.
  • IMAGE is the full image name including the sha256 image digest.

To verify that the image you built works as expected, you can run it using Docker.

  1. Configure Docker to use your Artifact Registry credentials when interacting with Artifact Registry. (You are only required to do this once.) Use the following command to authenticate using the gcloud credential helper.

    gcloud auth configure-docker HOSTNAME-LIST

    Where HOSTNAME-LIST is a comma-separated list of repository hostnames to add to the credential helper configuration.

    For example, to add the regions us-central1 and asia-northeast1, run the command:

    gcloud auth configure-docker us-central1-docker.pkg.dev,asia-northeast1-docker.pkg.dev

  2. Run the Docker image that you built before:

    docker run LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME

    Where:

    • LOCATION: the regional or multi-regional location for your repository.
    • PROJECT_ID: your Google Cloud project ID.
    • REPOSITORY: the name of your Artifact Registry repository.
    • IMAGE_NAME: the name of your container image.

    You will see an output similar to the following:

    Hello, world! The time is Fri Feb  2 16:09:54 UTC 2018.

Comments

Post a Comment

Popular posts from this blog

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more