Übersicht über Image Builder

Image Builder ist ein deklaratives Tool zur Anpassung von Betriebssystem-Images, das in Ihrem Cloud de Confiance-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 inCloud de Confiancehilft 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. 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: Überprü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 laden und einen funktionierenden Gast-Agent ausführen.
  • Skriptausführung nachverfolgen: Verfolgen Sie den Code, der während der 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 Cloud de Confiance -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 des Ziels aktiv sind.
  2. Vorbereitung von Arbeitsbereich und Laufwerk: 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 kurzlebige Worker-VM-Instanz mit dem angegebenen Quell-Image als Bootlaufwerk und hängt das sekundäre Datenlaufwerk mit dem Anpassungs-Provisioner an. Die Hardwareeigenschaften, das VPC-Netzwerk, das Subnetzwerk und die Zuweisung der externen IP-Adresse (entweder eine temporäre öffentliche IP-Adresse oder keine externe IP-Adresse) der Worker-VM werden durch die infrastructureConfig-Einstellungen in Ihrer imagebuilder.yaml-Datei bestimmt.
  4. Anpassung: Ein Startskript hängt das Datenlaufwerk ein und startet den Anpassungsbereitsteller auf der Worker-VM. Der Provisioner lädt das Arbeitsbereicharchiv 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 Test-Betriebssystem-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 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 Gastagent-Überprüfung: Bestätigt, dass der Gastagent-Dienst aktiv ist, mindestens eine Nicht-Loopback-Netzwerkschnittstelle aktiv ist und Namen den Konventionen entsprechen (eth* oder en*).
    • Secure Boot-Überprüfung: Stellt sicher, dass UEFI Secure Boot aktiv ist und dass das System die Überprüfung des Gast-Kernels 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 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-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 zusätzliche Kosten verfügbar. Allerdings Cloud de Confiance by S3NS 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: Abrechnung von 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 Images: Gebühren für das Speichern von Zwischen-, Test-, Debug- und Produktions-Images.

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 Kontingent für Compute Engine-CPUs und nichtflüchtige Speicher verfügt. Ein unzureichendes Kontingent in der Zielzone führt dazu, dass die Pipeline während der VM-Bereitstellung fehlschlägt.

Nächste Schritte