Benutzerdefinierte Betriebssystem-Image-Pipeline mit gcloud oder Terraform erstellen

Sie können eine Image Builder-Pipeline programmatisch mit der Google Cloud CLI oder Terraform konfigurieren und senden. Wenn Sie Ihre Pipeline programmatisch konfigurieren, können Sie Infrastruktureinstellungen, Basisbetriebssystem-Images, Anpassungsaktionen und Validierungstests in deklarativen Konfigurationsdateien definieren.

Hinweis

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen und Einreichen von Pipelines zur Bildanpassung mit der Google Cloud CLI oder Terraform benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Konfigurationsdateien erstellen

Wenn Sie Ihre Pipeline mit der gcloud CLI oder Terraform konfigurieren möchten, erstellen Sie zwei Konfigurationsdateien:

  • imagebuilder.yaml: Definiert das Anpassungsrezept für das Image, einschließlich des Basis-Betriebssystem-Images, der Infrastruktureinstellungen für Worker-VMs, der Ausgabedetails für das Ziel-Image und der sequenziellen Anpassungsschritte wie das Ausführen von Shell-Skripts, das Übertragen von Dateien oder das Ausführen von Neustarts.
  • cloudbuild.yaml: Orchestriert die Schritte des Build-Prozesses in Cloud Build, einschließlich des Parsens, der Validierung, des Erstellens, des Testens und des Veröffentlichens des benutzerdefinierten Betriebssystem-Images.

Bildkonfigurationsdatei erstellen

Erstellen Sie eine Datei mit dem Namen imagebuilder.yaml in Ihrem lokalen Verzeichnis, um die Bildkonfiguration anzugeben. Eine vollständige Liste aller unterstützten Schemafelder und Anpassungsaktionen finden Sie unter Schema für Anpassungsrezepte und Unterstützte Anpassungsaktionen.

Die folgende Beispiel-imagebuilder.yaml-Datei konfiguriert eine Pipeline, die ein benutzerdefiniertes Ubuntu 22.04 LTS-Image mit einer e2-standard-4-Worker-VM in der angegebenen Region und Zone erstellt und ein Systempaket-Update ausführt.

apiVersion: imagebuilder.gcp.com/v1
kind: OSImageCustomization
metadata:
  name: customized-ubuntu-baseline
  description: "Ubuntu 22.04 LTS custom OS baseline image"
infrastructureConfig:
  machineType: e2-standard-4
  zone: ZONE
  debug: false
source:
  imageFamily: projects/ubuntu-os-cloud/global/images/family/ubuntu-2204-lts
destinations:
  - diskImage:
      name: custom-ubuntu-v1
      family: custom-ubuntu-family
      project: PROJECT_ID
      storageLocations:
        - REGION
spec:
  config:
    skipSystemTests: false
  steps:
    -   name: "System Package Update"
      action: Shell
      inputs:
        command: "apt-get update -y && apt-get upgrade -y"

Ersetzen Sie die folgenden Platzhalterwerte:

  • PROJECT_ID: Ihre Projekt-ID.
  • REGION: Der Speicherort des Zielbilds, z. B. us-east1 oder europe-west1. Folgende regionale und zonale Anforderungen müssen erfüllt sein:
    • Image Builder wird nur in Regionen unterstützt, in denen Cloud Build verfügbar ist.
    • Die Worker-VM ZONE muss sich in der von Ihnen angegebenen REGION befinden.
    • Um die Netzwerklatenz zu minimieren und regionsübergreifende Gebühren für ausgehenden Traffic zu vermeiden, müssen sich die Zone der Worker-VM, der Cloud Storage-Staging-Bucket, das Artifact Registry-Repository und der Speicherort des Ziel-Image in derselben Region befinden.
  • ZONE: Eine Zone innerhalb der angegebenen REGION, z. B. us-east1-b oder europe-west1-b.

Orchestrator-Build-Datei erstellen

Erstellen Sie eine Datei mit dem Namen cloudbuild.yaml im selben Verzeichnis. In dieser Datei werden die Container-Schritte von Image Builder aufgerufen, um das benutzerdefinierte Betriebssystem-Image zu erstellen, zu validieren und zu veröffentlichen.

substitutions:
  _GCS_WORKDIR: 'gs://STAGING_BUCKET_NAME/workdir/'
  _IMAGE_BUILDER_CONFIG_PATH: 'imagebuilder.yaml'
  _SERVICE_ACCOUNT: 'projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_EMAIL'
  _IMAGE_OUTPUT_PATH: 'image-builder/binaryOut'
  _ARTIFACT_REGISTRY_RESOURCE_URI: 'projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/v${BUILD_ID}'

steps:
  #  Step 1: Parse configs and run OS customization on worker VM
  - name: 'REGION-docker.pkg.dev/image-builder-official/release/builder:stable'
    script: |
      #!/usr/bin/env bash
      /build
    id: 'imagebuilder-customize'
    results:
      - name: image_builder_telemetry_metrics
      - name: base_image
        attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        attestationContent: base_image

  # Step 2: Validate by running system boot checks on a test VM
  - name: 'REGION-docker.pkg.dev/image-builder-official/release/validator:stable'
    script: |
      #!/usr/bin/env bash
      /validate
    id: 'imagebuilder-validate'
    results:
      - name: image_builder_telemetry_metrics

  # Step 3: Register image in Compute Engine and upload tar files to Artifact Registry
  - name: 'REGION-docker.pkg.dev/image-builder-official/release/builder:stable'
    script: |
      #!/usr/bin/env bash
      /publish
    id: 'imagebuilder-publish'
    results:
      - name: image_builder_telemetry_metrics

options:
  automapSubstitutions: true
  requestedVerifyOption: VERIFIED
  substitutionOption: ALLOW_LOOSE
  dynamicSubstitutions: true
  logging: CLOUD_LOGGING_ONLY

artifacts:
  generic_artifacts:
    - folder: '${_IMAGE_OUTPUT_PATH}'
      registry_path: '${_ARTIFACT_REGISTRY_RESOURCE_URI}'

timeout: '3600s'

Ersetzen Sie die folgenden Platzhalterwerte:

  • STAGING_BUCKET_NAME: Ein vorhandener Cloud Storage-Bucket in Ihrem Projekt, der als temporärer Staging-Arbeitsbereich verwendet werden soll. Wenn Sie keinen Bucket haben, können Sie einen erstellen, indem Sie gcloud storage buckets create gs://STAGING_BUCKET_NAME ausführen. Wenn Sie Ihre Pipeline mit Terraform bereitstellen, wird dieser Bucket automatisch erstellt.
  • PROJECT_ID: Projekt-ID in Cloud de Confiance .
  • REGION: die Cloud de Confiance Region für Ihr Artifact Registry-Repository, z. B. us-east1 oder europe-west1.
  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos, das Sie mit den erforderlichen IAM-Berechtigungen konfiguriert haben.
  • REPOSITORY und PACKAGE: das Ziel-Repository und der Paketname, die in Artifact Registry erstellt wurden. Informationen zum Einrichten der Artifact Registry-Registry finden Sie unter Artifact Registry konfigurieren.

Build-Pipeline erstellen und einreichen

Wenn Sie Ihre Pipeline zur Bildanpassung ausführen möchten, senden Sie einen Build mit der gcloud CLI oder stellen Sie Ihre Pipeline mit Terraform bereit. Wählen Sie einen der folgenden Tabs aus:

gcloud

Um Ihre Pipeline zur Bildanpassung bereitzustellen und auszuführen, führen Sie in Ihrem lokalen Terminal im Verzeichnis, das beide Konfigurationsdateien enthält, den gcloud builds submit-Befehl aus:

gcloud builds submit . \
    --config=cloudbuild.yaml \
    --project=PROJECT_ID \
    --service-account="projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_EMAIL" \
    --region=REGION

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID in Cloud de Confiance .
  • REGION: die Cloud de Confiance Region, in der Ihr Job für die Bildanpassungspipeline ausgeführt werden soll.
  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos, das mit den erforderlichen IAM-Berechtigungen konfiguriert ist.

Mit diesem Befehl wird Ihr Anpassungsarbeitsbereich hochgeladen, die Cloud Build-Ausführung registriert und die Orchestrierungscontainer werden gestartet.

Terraform

Mit Terraform können Sie die Infrastruktur bereitstellen, die zum automatischen Erstellen und Validieren benutzerdefinierter Betriebssystem-Images erforderlich ist. Diese Terraform-Konfiguration führt die folgenden Aufgaben aus:

  • Aktiviert die erforderlichen Cloud de Confiance APIs.
  • Erstellt einen dedizierten Cloud Storage-Bucket (workdir_bucket) zum Speichern temporärer Logs und Build-Artefakte.
  • Konfiguriert einen Cloud Build-Trigger (image_builder_trigger), der mit Ihrer Developer Connect-GitHub-Repository-Verbindung verknüpft ist.

Terraform-Konfigurationsdateien erstellen

Führen Sie die folgenden Schritte aus, um Ihre Pipelineinfrastruktur mit Terraform zu organisieren und bereitzustellen:

  1. Erstellen Sie auf Ihrer lokalen Workstation oder in Ihrer CI/CD-Umgebung ein separates Verzeichnis, das sich von Ihrem Anwendungs-Repository unterscheidet, und wechseln Sie in dieses Verzeichnis:

    mkdir terraform-image-builder && cd terraform-image-builder
    
  2. Erstellen Sie in diesem Verzeichnis die folgenden fünf Terraform-Konfigurationsdateien:

    • terraform.tfvars: Legt Werte für projektspezifische Variablen fest.
    • main.tf: Stellt Ressourcen in Ihrem Cloud de Confiance Projekt bereit, einschließlich der Aktivierung erforderlicher APIs, der Erstellung des Cloud Storage-Staging-Buckets (workdir_bucket) und der Bereitstellung des Cloud Build-Triggers (image_builder_trigger).
    • outputs.tf: Definiert Ausgabewerte, die nach der Bereitstellung in Ihrem Terminal angezeigt werden, z. B. die Trigger-ID und den Namen des Staging-Buckets.
    • providers.tf: Gibt die erforderliche Terraform-Version (>= 1.3) an und konfiguriert den Cloud de Confiance by S3NS Provider (hashicorp/google).
    • variables.tf: Definiert Eingabevariablen, Standardwerte und Validierungsregeln für die Bereitstellung.

    Wählen Sie einen der folgenden Tabs aus, um die Konfiguration der einzelnen Dateien aufzurufen und in Ihr lokales Verzeichnis zu kopieren:

    terraform.tfvars

    In dieser Datei werden Parameterwerte für Ihre Umgebung für die deklarierten Variablen angegeben:

    project_id                = "PROJECT_ID"
    builder_service_account   = "SERVICE_ACCOUNT_EMAIL"
    github_repo_name          = "projects/PROJECT_ID/locations/LOCATION/connections/CONNECTION/repositories/REPO_NAME"
    region                    = "REGION"
    trigger_name              = "TRIGGER_NAME"
    cloudbuild_yaml_path      = "CLOUDBUILD_YAML_PATH"
    image_builder_config_path = "RECIPE_PATH"
    gcs_lifecycle_age_days    = LIFECYCLE_DAYS
    ar_repository_id          = "REPOSITORY_NAME"
    ar_package_name           = "PACKAGE_NAME"
    

    Ersetzen Sie die folgenden Platzhalter für Ihre vorhandenen Ressourcen:

    • PROJECT_ID: Ihre vorhandeneCloud de Confiance by S3NS Projekt-ID.
    • SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse Ihres Build-Dienstkontos, das in Dienstkonto für Image Builder konfigurieren konfiguriert ist.
    • LOCATION, CONNECTION und REPO_NAME: Ihre Developer Connect-Hostregion, der Verbindungsname und der Repository-Link, die in Repository verbinden konfiguriert sind.
    • CLOUDBUILD_YAML_PATH: der relative Pfad zu Ihrer cloudbuild.yaml-Datei in Ihrem lokalen Verzeichnis. Sie müssen cloudbuild.yaml nicht in Ihr Git-Repository einchecken.
    • RECIPE_PATH: der relative Pfad zu Ihrer imagebuilder.yaml-Anpassungsrezeptdatei, die in Ihr Git-Repository eingecheckt wurde.
    • REPOSITORY_NAME: das vorhandene generische Artifact Registry-Repository, das in Artifact Registry konfigurieren erstellt wurde.

    Ersetzen Sie die folgenden Platzhalter für die Ressourcen, die von Terraform erstellt werden:

    • REGION: Die Zielregion Cloud de Confiance, in der Terraform den Cloud Storage-Staging-Bucket und den Cloud Build-Trigger bereitstellt, z. B. us-central1.
    • TRIGGER_NAME: Der Name des neuen Cloud Build-Repository-Triggers, der von Terraform erstellt wurde, z. B. git-push-os-builder.
    • LIFECYCLE_DAYS: Der Aufbewahrungszeitraum in Tagen, bevor von Terraform erstellte Zwischenartefakte im Cloud Storage-Staging-Bucket automatisch gelöscht werden, z. B. 30.
    • PACKAGE_NAME: Der Name, den Terraform für das im Artifact Registry-Repository erstellte Paket verwenden soll. In diesem Paket werden veröffentlichte Betriebssystem-Image-Versionen gespeichert, z. B. ubuntu-custom.

    main.tf

    In dieser Datei werden die wichtigsten Infrastrukturressourcen und Datenquellen für die Bereitstellung deklariert:

    # Main resource configurations for Image Builder.
    # 1. Enable Required APIs
    resource "google_project_service" "apis" {
      for_each = toset([
        "compute.googleapis.com",
        "cloudbuild.googleapis.com",
        "artifactregistry.googleapis.com",
        "serviceusage.googleapis.com",
        "cloudresourcemanager.googleapis.com",
        "iam.googleapis.com",
        "storage.googleapis.com"
      ])
      project = var.project_id
      service = each.key
      disable_on_destroy = false
    }
    
    # 2. Project data source to retrieve Project Number
    data "google_project" "project" {
      project_id = var.project_id
      depends_on = [google_project_service.apis]
    }
    
    locals {
      builder_sa = var.builder_service_account
    }
    
    # 3. Storage Bucket for Image Builder Workdir
    resource "google_storage_bucket" "workdir_bucket" {
      name                        = var.gcs_bucket_name != "" ? var.gcs_bucket_name : "${var.project_id}-vm-builder-workdir"
      project                     = var.project_id
      location                    = var.region
      force_destroy               = true
      uniform_bucket_level_access = true
      lifecycle_rule {
        action {
          type = "Delete"
        }
        condition {
          age = var.gcs_lifecycle_age_days
        }
      }
      depends_on = [google_project_service.apis]
    }
    
    # 4. Cloud Build Trigger
    resource "google_cloudbuild_trigger" "image_builder_trigger" {
      name        = var.trigger_name
      location    = var.region
      project     = var.project_id
      description = "Trigger that runs Image Builder customization"
    
      service_account = var.builder_service_account != "" ? "projects/${var.project_id}/serviceAccounts/${var.builder_service_account}" : null
    
      repository_event_config {
        repository = replace(var.github_repo_name, "gitRepositoryLinks", "repositories")
        push {
          branch = "^main$"
        }
      }
      filename = var.cloudbuild_yaml_path
    
      substitutions = {
        _GCS_WORKDIR                    = "gs://${google_storage_bucket.workdir_bucket.name}/workdir/"
        _SERVICE_ACCOUNT                = "projects/${var.project_id}/serviceAccounts/${local.builder_sa}"
        _IMAGE_OUTPUT_PATH              = "image-builder/binaryOut"
        _PROJECT_ID                     = var.project_id
        _LOCATION                       = var.region
        _REPOSITORY_NAME                = var.ar_repository_id
        _PACKAGE_NAME                   = var.ar_package_name
        _IMAGE_BUILDER_CONFIG_PATH      = var.image_builder_config_path
        _ARTIFACT_REGISTRY_RESOURCE_URI = "projects/${var.project_id}/locations/${var.region}/repositories/${var.ar_repository_id}/packages/${var.ar_package_name}/versions/v$${BUILD_ID}"
      }
      depends_on = [
        google_project_service.apis
      ]
    }
    

    outputs.tf

    In dieser Datei werden die Ausgabeargumente definiert, die nach der Bereitstellung in Ihrem Terminal zurückgegeben werden:

    output "builder_service_account" {
      value       = local.builder_sa
      description = "The email representation of the resolved Image Builder service account."
    }
    
    output "workdir_bucket" {
      value       = google_storage_bucket.workdir_bucket.name
      description = "The name of the storage workdir bucket."
    }
    
    output "artifact_registry_repository" {
      value       = "projects/${var.project_id}/locations/${var.region}/repositories/${var.ar_repository_id}"
      description = "The fully qualified resource path of the Artifact Registry repository."
    }
    
    output "cloud_build_trigger_id" {
      value       = google_cloudbuild_trigger.image_builder_trigger.trigger_id
      description = "The unique ID for the created Cloud Build Trigger."
    }
    

    providers.tf

    In dieser Datei werden die erforderliche Terraform-Version und die Regionseinstellungen konfiguriert:

    terraform {
      required_version = ">= 1.3"
      required_providers {
        google = {
          source  = "hashicorp/google"
          version = ">= 5.0, < 7.0"
        }
      }
    }
    
    provider "google" {
      project = var.project_id
      region  = var.region
    }
    

    variables.tf

    In dieser Datei werden alle erforderlichen und optionalen Eingabevariablen und Validierungsregeln deklariert:

    variable "project_id" {
      type        = string
      description = "The target Project ID where resources will be created."
      validation {
        condition     = can(regex("^[a-z0-9-]{6,30}$", var.project_id))
        error_message = "The project_id must consist of lowercase letters, numbers, and hyphens, and be between 6 and 30 characters."
      }
    }
    
    variable "region" {
      type        = string
      default     = "us-central1"
      description = "Location used for cloud build triggers, storage buckets, and artifact registry."
    }
    
    variable "github_repo_name" {
      type        = string
      default     = ""
      description = "Developer Connect github repository details, format: projects/PROJECT_ID/locations/LOCATION/connections/CONNECTION/repositories/REPO_LINK"
      validation {
        condition     = can(regex("^projects/[^/]+/locations/[^/]+/connections/[^/]+/(gitRepositoryLinks|repositories)/[^/]+$", var.github_repo_name))
        error_message = "The github_repo_name must follow either the Cloud Build v2 repository link format (using '/repositories/') or the Developer Connect resource format (using '/gitRepositoryLinks/')."
      }
    }
    
    variable "builder_service_account" {
      type        = string
      default     = ""
      description = "The email representation of the pre-existing Image Builder service account. If omitted, the default Cloud Build service account will be used."
    }
    
    variable "gcs_bucket_name" {
      type        = string
      default     = ""
      description = "Custom name for the workdir storage bucket. If left empty, a default name using the project ID will be constructed."
    }
    
    variable "gcs_lifecycle_age_days" {
      type        = number
      default     = 30
      description = "The number of days after which temporary logs and artifacts in the storage workdir bucket are deleted."
    }
    
    variable "ar_repository_id" {
      type        = string
      default     = "vm-images"
      description = "The repository ID for the generic Artifact Registry hosting the final OS image tarballs."
    }
    
    variable "ar_package_name" {
      type        = string
      default     = "image-builder"
      description = "The package name under which the generic OS image artifact will be registered in Artifact Registry."
    }
    
    variable "trigger_name" {
      type        = string
      default     = "custom-os-image-builder"
      description = "The name of the Cloud Build trigger."
    }
    
    variable "cloudbuild_yaml_path" {
      type        = string
      default     = "cloudbuild.yaml"
      description = "The path to the cloudbuild.yaml configuration file relative to the repository root."
    }
    
    variable "image_builder_config_path" {
      type        = string
      default     = "imagebuilder.yaml"
      description = "The path to the imagebuilder.yaml configuration file relative to the repository root."
    }
    
  3. Führen Sie die folgenden Befehle im Verzeichnis mit Ihren Terraform-Dateien aus, um die Konfigurationen bereitzustellen:

    1. Initialisieren Sie das Verzeichnis:
      terraform init
    2. Syntax validieren:
      terraform validate
    3. Vorschau der Bereitstellung ansehen:
      terraform plan
    4. Wenden Sie die Konfiguration an:
      terraform apply

Build überprüfen und überwachen

So verfolgen Sie den Fortschritt Ihrer Build-Pipeline:

  1. Rufen Sie in der Cloud de Confiance Console die Seite Cloud Build auf.

    Zu Cloud Build

  2. Klicken Sie im Navigationsmenü auf Verlauf, um aktive oder abgeschlossene Jobs aufzurufen.

  3. Klicken Sie in der Liste Builds auf die Build-ID Ihres Builds, um die Container-Ausführungsprotokolle zu prüfen. In den Logs werden die Schritte angezeigt, die in der Worker-VM ausgeführt werden, z. B. Systempaket-Updates oder benutzerdefinierte Shell-Befehle, gefolgt von Validierungstestergebnissen der Test-VM und der Registrierung der endgültigen Ausgabe.

Nächste Schritte