Übersicht über Image Builder

Image Builder ist ein deklaratives Tool zur Anpassung von Betriebssystem-Images, das in Ihrem Google Cloud-Projekt mit Cloud Build ausgeführt wird. Der Image Builder automatisiert das Erstellen, Anpassen und Validieren von Betriebssystem-Images, um sicherzustellen, dass sie korrekt gebootet werden und Ihren Konfigurationsanforderungen entsprechen, bevor Sie sie für Produktionsarbeitslasten veröffentlichen.

Hauptvorteile

Durch die Automatisierung des Lebenszyklus benutzerdefinierter Betriebssystem-Images inGoogle Cloudhilft Ihnen Image Builder, 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. einem 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 programmatisch über externe Workflows oder Webhooks auszulösen).
  • Bilder vor der Veröffentlichung prüfen: Prüfen Sie Bilder, bevor Sie sie veröffentlichen. Von Google bereitgestellte Prüfungen bestätigen, dass Zwischenbilder gebootet werden, Secure Boot (falls zutreffend) unterstützen, erforderliche Netzwerktreiber geladen werden und ein funktionierender Gast-Agent ausgeführt wird.
  • Skriptausführung verfolgen: 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. Kosten fallen nur für die zugrunde liegenden Compute-, Speicher- und Build-Ressourcen an, die während der Ausführung Ihrer Pipelines genutzt werden.

Funktionsweise von Image Builder

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

  1. Validierung und Vorbereitung: Der Orchestrator-Container prüft die YAML-Syntax und stellt sicher, dass alle erforderlichen APIs aktiviert sind und die IAM-Sicherheitsberechtigungen (Identity and Access Management) für das Ziel aktiv sind.
  2. Arbeitsbereich und Datenträger vorbereiten: Der Orchestrator-Container archiviert das Cloud Build-Arbeitsbereichsverzeichnis (/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 Anpassungs-Bereitsteller-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 temporäre Worker-VM-Instanz mit dem angegebenen Quell-Image als Bootlaufwerk und hängt das sekundäre Datenlaufwerk mit dem Anpassungs-Bereitsteller an. Die Hardwareeigenschaften, das VPC-Netzwerk, das Subnetzwerk und die Zuweisung der externen IP-Adresse der Worker-VM – entweder eine temporäre öffentliche IP-Adresse oder keine externe IP-Adresse – werden durch die infrastructureConfig-Einstellungen in Ihrer imagebuilder.yaml-Datei bestimmt.
  4. Anpassung: Ein Startskript hängt die Datenfestplatte ein und startet den Anpassungsbereitsteller auf der Worker-VM. Der Provisioner lädt das Arbeitsbereichsarchiv herunter und wendet die von Ihnen deklarierten Anpassungen an, z. B. das Ausführen von Shell-Skripts, das Kopieren von Dateien oder das 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 von der angepassten Bootdisk und stellt temporäre Test-VMs mit der Netzwerk- und Infrastrukturkonfiguration in Ihrer imagebuilder.yaml-Datei bereit, um die folgenden systemdefinierten Validierungsprüfungen auszuführen:
    • Intel IDPF-Treiberüberprüfung: Prüft, ob auf unterstützten Instanzen der idpf-Netzwerktreiber (Intel Infrastructure Data Path Function) anstelle von generischen Display- oder Fallbacktreibern geladen wird.
    • Netzwerk- und Gast-Agent-Überprüfung: Bestätigt, dass der Gast-Agent-Dienst aktiv ist, mindestens eine Nicht-Loopback-Netzwerkschnittstelle aktiv ist und Namen den Konventionen (eth* oder en*) entsprechen.
    • Secure Boot-Verifizierung: Stellt sicher, dass UEFI Secure Boot aktiv ist und dass das System die Verifizierung des Gastkernel erzwingt.
    • Überprüfung anhalten oder fortsetzen: Die Test-VM wird mit der Compute Engine API angehalten und es wird geprüft, ob die Netzwerkverbindung nach dem Fortsetzen ohne Systemneustart wiederhergestellt wird.
  6. Release: Wenn alle Validierungsprüfungen bestanden sind, 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-Produktionsimage mit dem 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 benutzerdefinierten Bootlaufwerk.

Überlegungen zu Preisen und Kontingenten

Der Image Builder-Dienst ist ohne Aufpreis verfügbar. Google Cloud Gebühren für Standardressourcen, die während der Phasen „Erstellen“, „Testen“ und „Veröffentlichen“ bereitgestellt werden:

  • Compute Engine: Gebühren für Worker-VMs, Test-VMs und angehängte nichtflüchtige Speicher.
  • Cloud Build: Gebühren für Orchestrator-Containerlaufzeitminuten.
  • Cloud Storage: Gebühren für Workspace-Archive, Log-Exporte und Zwischen-Assets.
  • Artifact Registry: Gebühren für das Speichern exportierter Bild-Tar-Dateien, sofern konfiguriert.
  • Benutzerdefinierte Bilder: Gebühren für das Speichern von Zwischenbildern für Tests, Debugging und Produktion.

Detaillierte Informationen zu den Ressourcenkosten finden Sie in der Preisdokumentation für Compute Engine, Cloud Build, Cloud Storage, Artifact Registry und Speicher für benutzerdefinierte Images.

Kontingentanforderungen

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

Nächste Schritte