Übersicht über Image Builder

Image Builder ist ein deklaratives Betriebssystem- Image-Anpassungstool, das in Ihrem Google Cloud Projekt mit Cloud Build ausgeführt wird. Es automatisiert das Erstellen, Anpassen und Validieren von Betriebssystem-Images, um zu prüfen, ob sie korrekt gestartet werden und Ihren Konfigurationsanforderungen entsprechen, bevor Sie sie für Produktionsarbeitslasten veröffentlichen.

Hauptvorteile

Durch die Automatisierung des Lebenszyklus benutzerdefinierter Betriebssystem-Images in Google Cloudhilft Image Builder Ihnen, die Infrastruktur zu verwalten und Konfigurationsanforderungen zu validieren. Image Builder bietet die folgenden Funktionen für Ihre benutzerdefinierten Betriebssystem-Image-Builds:

  • Erstellung von Betriebssystem-Images automatisieren: Erstellen und verwalten Sie benutzerdefinierte Betriebssystem-Images mit deklarativen YAML-Rezepten und automatisierten Cloud Build-Workflows, ohne dass benutzerdefinierte Skripts oder externe Tools erforderlich sind. Da Image Builder in Cloud Build ausgeführt wird, können Sie Cloud Build-Trigger verwenden, um Image-Builds automatisch bei Repository-Ereignissen (z. B. Git-Push oder -Tag) zu starten, wiederkehrende Zeitpläne einzurichten (z. B. wöchentliche Builds für Sicherheitspatches) oder auf Pub/Sub-Nachrichten zu reagieren (um Builds programmgesteuert über externe Workflows oder Webhooks auszulösen).
  • Images vor der Veröffentlichung validieren: Prüfen Sie Images, bevor Sie sie veröffentlichen. Von Google bereitgestellte Prüfungen validieren, dass Zwischen-Images gestartet werden, Secure Boot unterstützen (falls zutreffend), erforderliche Netzwerktreiber laden und einen fehlerfreien Gastagenten ausführen.
  • Skriptausführung nachverfolgen: Verfolgen Sie den Code, der während Ihrer Build-Pipeline ausgeführt wird. Image Builder zeichnet automatisch den kryptografischen SHA-256-Hash Ihrer Inline-Anpassungsskripts in den Build-Logs auf, um einen Prüfpfad zu erstellen.
  • Nur für verwendete Ressourcen bezahlen: Der Image Builder-Dienst ist ohne zusätzliche Kosten verfügbar. Es fallen nur Kosten für die zugrunde liegenden Compute-, Speicher- und Build-Ressourcen an, die während der Ausführung Ihrer Pipelines verbraucht werden.

Funktionsweise von Image Builder

Image Builder wird in Ihrem Google Cloud Projekt mit einem Cloud Build-Orchestrator-Container ausgeführt. Der Image-Build-Prozess besteht aus den folgenden Phasen:

  1. Validierung und Vorbereitung: Der Orchestrator-Container prüft die YAML-Syntax und verifiziert, dass alle erforderlichen APIs aktiviert sind und die Zielberechtigungen für Identity and Access Management (IAM) aktiv sind.
  2. Vorbereitung von Arbeitsbereich und Laufwerk: Der Orchestrator-Container archiviert das Cloud Build-Arbeitsverzeichnis (/workspace) mit Ihrem Quellcode und Ihren Konfigurationen in einer komprimierten tar-Datei (.tar.gz) und lädt diese tar-Datei in den Cloud Storage-Arbeitsverzeichnis-Bucket hoch, der in Ihrer Build-Konfiguration angegeben ist. Der Orchestrator-Container verwendet dann ein statisch kompiliertes Anpassungsbereitstellungs-Dateisystem, um ein temporäres Compute Engine-Image zu erstellen, das das sekundäre Datenlaufwerk definiert, das an Ihre Worker-VM angehängt ist.
  3. Ausführung der Worker-VM: Der Orchestrator-Container startet eine kurzlebige Worker-VM-Instanz mit dem angegebenen Quell-Image als Bootlaufwerk und hängt das sekundäre Datenlaufwerk mit dem Anpassungsbereitsteller an. Die Hardwareeigenschaften, das VPC-Netzwerk, das Subnetzwerk und die Zuweisung der externen IP-Adresse der Worker-VM – entweder eine kurzlebige öffentliche IP-Adresse oder keine externe IP-Adresse – werden durch die infrastructureConfig-Einstellungen in Ihrer imagebuilder.yaml-Datei bestimmt.
  4. Anpassung: Ein Startskript stellt das Datenlaufwerk bereit und startet den Anpassungsbereitsteller auf der Worker-VM. Der Bereitsteller lädt das Arbeitsbereichsarchiv herunter und wendet Ihre deklarierten Anpassungen an, z. B. durch Ausführen von Shell-Skripts, Kopieren von Dateien oder Kompilieren von Treibern. Außerdem wird eine Sicherheitsbereinigung durchgeführt, um SSH-Schlüssel, eindeutige Maschinen-IDs und Protokollverläufe zu entfernen. Anschließend wird die Instanz heruntergefahren.
  5. Validierung (Test): Der Orchestrator-Container erstellt ein temporäres Testbetriebssystem-Image aus dem angepassten Bootlaufwerk und stellt temporäre Test-VMs mit der Netzwerk- und Infrastrukturkonfiguration in Ihrer imagebuilder.yaml-Datei bereit, um die folgenden vom System definierten Validierungsprüfungen auszuführen:
    • Überprüfung des Intel IDPF-Treibers: Prüft, ob unterstützte Instanzen den Intel Infrastructure Data Path Function (idpf)-Netzwerktreiber anstelle generischer Anzeige- oder Fallback-Treiber laden.
    • Überprüfung des Netzwerks und des Gastagenten: Bestätigt, dass der Gastagentendienst aktiv ist, mindestens eine Nicht-Loopback-Netzwerkschnittstelle aktiv ist und die Namen den Konventionen entsprechen (eth* oder en*).
    • Überprüfung von Secure Boot: Prüft, ob UEFI Secure Boot aktiv ist und das System die Überprüfung des Gastkernels erzwingt.
    • Überprüfung des Anhaltens und Fortsetzens: Hält die Test-VM mit der Compute Engine API an und prüft, ob die Netzwerkverbindung nach dem Fortsetzen ohne Neustart des Systems wiederhergestellt wird.
  6. Release: Wenn alle Validierungsprüfungen bestanden wurden, bereitet der Orchestrator-Container das endgültige Image vor:
    • Wenn Artifact Registry konfiguriert ist: Der Orchestrator-Container exportiert das angepasste Bootlaufwerk als tar-Datei in ein generisches Artifact Registry-Repository und erstellt das endgültige Compute Engine-Image für die Produktion mit der Artifact Registry-URI als Quelle.
    • Wenn Artifact Registry nicht konfiguriert ist: Der Orchestrator-Container erstellt das Compute Engine-Image direkt in Ihrem Projekt mit dem angepassten Bootlaufwerk.

Preise und Kontingente

Der Image Builder-Dienst ist ohne zusätzliche Kosten verfügbar. Es fallen jedoch Google Cloud Gebühren für Standardressourcen an, die während der Build-, Test- und Release-Phasen bereitgestellt werden:

  • Compute Engine: Gebühren für Worker-VMs, Test-VMs und angehängte nichtflüchtige Festplatten.
  • Cloud Build: Gebühren für die Laufzeitminuten des Orchestrator-Containers.
  • Cloud Storage: Gebühren für Arbeitsbereichsarchive, Protokollexporte und Zwischen-Assets.
  • Artifact Registry: Gebühren für das Speichern exportierter Image-Tar-Dateien, falls konfiguriert.
  • Benutzerdefinierte Images: Gebühren für das Speichern von Test-, Debug- und Produktions-Images.

Ausführliche Informationen zu den Ressourcenkosten finden Sie in der Preisdokumentation für Compute Engine, Cloud Build, Cloud Storage, Artifact Registry und benutzerdefinierten Image-Speicher.

Kontingentanforderungen

Prüfen Sie, ob Ihr Projekt in der Zone, in der Sie Ihre Builds ausführen, über ein ausreichendes Compute Engine-CPU- und nichtflüchtiges Festplattenkontingent verfügt. Ein unzureichendes Kontingent in der Zielzone führt dazu, dass die Pipeline während der VM-Bereitstellung fehlschlägt.

Nächste Schritte