Freigeben über

Isolierte Imagebuilds für Azure VM Image Builder

  • Artikel

Isolierte Imagebuilds sind ein Feature von Azure VM Image Builder (AIB). Es stellt den Kernprozess der VM-Imageanpassung/-validierung von der gemeinsam genutzten Plattforminfrastruktur auf dedizierte ACI-Ressourcen (Azure Container Instances) in Ihrem Abonnement um und bietet Compute- und Netzwerkisolation.

Vorteile isolierter Imagebuilds

Isolierte Imagebuilds ermöglichen eine tiefgehende Verteidigung, indem sie den Netzwerkzugriff Ihrer Build-VM allein auf Ihr Abonnement beschränken. Isolierte Imagebuilds bieten außerdem mehr Transparenz, da Sie Ihnen die Überprüfung der Verarbeitung ermöglichen, die von AIB zur Anpassung/Validierung Ihres VM-Image durchgeführt wurde. Darüber hinaus erleichtern isolierte Imagebuilds die Betrachtung von Livebuildprotokollen. Speziell:

  1. Computeisolation: Bei isolierten Imagebuilds findet der Großteil der Verarbeitung für die Imageerstellung nicht in den gemeinsam genutzten Plattformressourcen von AIB, sondern in ACI-Ressourcen in Ihrem Abonnement statt. ACI bietet Hypervisorisolation für jede Containergruppe, um sicherzustellen, dass Container isoliert ausgeführt werden, ohne einen gemeinsamen Kernel zu verwenden.

  2. Netzwerkisolation: Isolierte Imagebuilds entfernen alle direkten Netzwerk-WinRM/ssh-Kommunikation zwischen Ihrer Build-VM und Back-End-Komponenten des AIB-Diensts.

    • Wenn Sie eine AIB-Vorlage ohne Ihr eigenes Subnetzwerk für Build VM bereitstellen, wird zum Zeitpunkt der Image-Erstellung keine öffentliche IP-Adresse mehr in Ihrer Staging-Ressourcengruppe bereitgestellt.
    • Wenn Sie eine AIB-Vorlage mit einem vorhandenen Subnetz für Build-VM bereitstellen, ist kein privater Link-basierter Kommunikationskanal zwischen den Back-End-Plattformressourcen Ihrer Build-VM und der Back-End-Plattform von AIB eingerichtet. Stattdessen wird der Kommunikationskanal zwischen der ACI und den Build VM-Ressourcen eingerichtet, die sich beide in der Staging-Ressourcengruppe Ihres Abonnements befinden.
    • Ab API Version 2024-02-01 können Sie zusätzlich zum Subnetz für Build-VM ein zweites Subnetz für die Bereitstellung der ACI angeben. Wenn angegeben, stellt AIB ACI in diesem Subnetz bereit und es ist nicht erforderlich, dass AIB den privaten Link-basierten Kommunikationskanal zwischen der ACI und der Build-VM einrichten muss. Weitere Informationen zum zweiten Subnetz finden Sie im Abschnitt hier.

  3. Transparenz: AIB basiert auf HashiCorp Packer. Isolierte Imagebuilds führen Packer in der Azure-Containerinstanz in Ihrem Abonnement aus, sodass Sie die ACI-Ressource und deren Container überprüfen können. Ebenso können Sie alle Netzwerkressourcen sowie ihre Einstellungen und Zertifikate überprüfen, da sich die gesamte Netzwerkkommunikationspipeline in Ihrem Abonnement befindet.

  4. Bessere Anzeige von Liveprotokollen: AIB schreibt Anpassungsprotokolle in ein Speicherkonto in der Stagingressourcengruppe in Ihrem Abonnement. Isolierte Imagebuilds bietet eine weitere Möglichkeit, dieselben Protokolle direkt im Azure-Portal zu verfolgen. Navigieren Sie dazu zum Container des AIB in der ACI-Ressource.

Hinweis

Informationen zum Zugreifen auf die Liveprotokolle während des Imagebuilds oder auf die Anpassungs- und Validierungsprotokolldateien nach Abschluss des Builds finden Sie im Leitfaden zur Problembehandlung.

Netzwerktopologien

Isolierte Imagebuilds stellen die ACI und die Build-VM sowohl in der Stagingressourcengruppe in Ihrem Abonnement bereit. Damit AIB Ihr Image anpassen/überprüfen kann, müssen Containerinstanzen, die in der ACI ausgeführt werden, über einen Netzwerkpfad zur Build-VM verfügen. Basierend auf Ihren benutzerdefinierten Netzwerkanforderungen und Richtlinien können Sie AIB so konfigurieren, dass unterschiedliche Netzwerktopologien für diesen Zweck verwendet werden:

Stellen Sie kein eigenes Build-VM-Subnetz zur Verfügung

  • Sie können diese Topologie auswählen, indem Sie das vnetConfig Feld in der Bildvorlage nicht angeben oder durch Angeben des Felds ohne subnetId und containerInstanceSubnetId Unterfelder.
  • In diesem Fall stellt AIB ein virtuelles Netzwerk in der Stagingressourcengruppe zusammen mit zwei Subnetzen und Netzwerksicherheitsgruppen (Network Security Groups, NSGs) bereit. Eines der Subnetze wird verwendet, um die ACI bereitzustellen, während das andere Subnetz zum Bereitstellen der Build-VM verwendet wird. NSGs sind so eingerichtet, dass die Kommunikation zwischen den beiden Subnetzen zugelassen wird.
  • AIB stellt in diesem Fall keine öffentliche IP-Ressource oder eine private Link-basierte Kommunikationspipeline bereit.

Stellen Sie Ihr eigenes Build-VM-Subnetz zur Verfügung, aber nicht Ihr eigenes ACI-Subnetz

  • Sie können diese Topologie auswählen, indem Sie das vnetConfig Feld zusammen mit dem subnetId Unterfeld, aber nicht das containerInstanceSubnetId Unterfeld in der Bildvorlage angeben.
  • In diesem Fall stellt AIB ein temporäres virtuelles Netzwerk in der Stagingressourcengruppe zusammen mit zwei Subnetzen und Netzwerksicherheitsgruppen (NSGs) bereit. Eines der Subnetze wird verwendet, um die ACI bereitzustellen, während das andere Subnetz verwendet wird, um die private Endpoint-Ressource bereitzustellen. Die Build-VM wird in Ihrem angegebenen Subnetz bereitgestellt. Eine private Link-basierte Kommunikationspipeline, bestehend aus einem privaten Endpunkt, privatem Linkdienst, Azure Load Balancer und virtuellen Proxycomputern wird auch in der Stagingressourcengruppe bereitgestellt, um die Kommunikation zwischen dem ACI-Subnetz und Ihrem Build-VM-Subnetz zu erleichtern.

Stellen Sie Ihr eigenes Build-VM-Subnetz und Ihr eigenes ACI-Subnetz zur Vefügung

  • Sie können diese Topologie auswählen, indem Sie das vnetConfig Feld zusammen mit den Unterfeldern subnetId und containerInstanceSubnetId in der Bildvorlage angeben. Diese Option (und das Unterfeld containerInstanceSubnetId) steht ab API-Version 2024-02-01 zur Verfügung. Sie können ihre vorhandenen Vorlagen auch aktualisieren, um diese Topologie zu verwenden.
  • In diesem Fall stellt AIB Build-VM im angegebenen Build-VM-Subnetz und ACI im angegebenen ACI-Subnetz bereit.
  • AIB stellt keine der Netzwerkressourcen in der Staging-Ressourcengruppe bereit, einschließlich öffentlicher IP, virtuellem Netzwerk, Subnetzen, Netzwerksicherheitsgruppen, privatem Endpunkt, Private Link-Dienst, Azure Load Balancer und virtueller Proxymaschine. Diese Topologie kann verwendet werden, wenn Sie Kontingentbeschränkungen oder Richtlinien haben, die die Bereitstellung dieser Ressourcen aufheben.
  • Das ACI-Subnetz muss bestimmte Bedingungen erfüllen, um die Verwendung mit isolierten Imagebuilds zu ermöglichen.

Details zu diesen Feldern finden Sie in der Vorlagenreferenz. Netzwerkoptionen werden hier ausführlich erläutert.

Abwärtskompatibilität

Isolierte Imagebuilds ist eine Änderung auf Plattformebene und wirkt sich nicht auf die Schnittstellen von AIB aus. Ihre vorhandenen Bildvorlagen- und Triggerressourcen funktionieren also weiterhin, und die Art und Weise, wie Sie neue Ressourcen dieser Typen bereitstellen, ändert sich nicht. Sie müssen neue Vorlagen erstellen oder vorhandene Vorlagen aktualisieren, wenn Sie die Netzwerktopologie verwenden möchten, die die Einbeziehung Ihres eigenen ACI-Subnetzes ermöglicht.

Ihre Imagebuilds werden automatisch zu isolierten Imagebuilds migriert und Sie müssen nichts unternehmen, um dies zu aktivieren. Entsprechend stehen Anpassungsprotokolle weiterhin im Speicherkonto zur Verfügung.

Abhängig von der in der Bildvorlage angegebenen Netzwerktopologie können Sie feststellen, dass einige neue Ressourcen vorübergehend in der Stagingressourcengruppe angezeigt werden (z. B. ACI, Virtuelles Netzwerk, Netzwerksicherheitsgruppe und privater Endpunkt), während einige andere Ressourcen nicht mehr angezeigt werden (z. B. öffentliche IP-Adresse). Wie bereits zuvor existieren diese temporären Ressourcen nur während des Builds, und AIB löscht sie danach.

Wichtig

Stellen Sie sicher, dass Ihr Abonnement für Microsoft.ContainerInstance provider registriert ist:

  • Azure-Befehlszeilenschnittstelle: az provider register -n Microsoft.ContainerInstance
  • PowerShell: Register-AzResourceProvider -ProviderNamespace Microsoft.ContainerInstance

Stellen Sie nach der erfolgreichen Registrierung Ihres Abonnements sicher, dass es keine Azure-Richtlinien in Ihrem Abonnement gibt, die die Bereitstellung von ACI Ressourcen verweigern. Richtlinien, die nur einen eingeschränkten Satz von Ressourcentypen zulassen, die keine ACI enthalten, führen dazu, dass isolierte Imagebuilds fehlschlagen.

Stellen Sie sicher, dass Ihr Abonnement auch über ein ausreichendes Kontingent an Ressourcen verfügt, für die Bereitstellung von ACI-Ressourcen erforderlich sind.

Wichtig

Je nach der in der Imagevorlage angegebenen Netzwerktopologie muss AIB möglicherweise temporäre netzwerkbezogene Ressourcen in der Stagingressourcengruppe in Ihrem Abonnement bereitstellen. Stellen Sie sicher, dass keine Azure-Richtlinien die Bereitstellung solcher Ressourcen (virtuelles Netzwerk mit Subnetzen, Netzwerksicherheitsgruppe, privater Endpunkt) in der Ressourcengruppe verweigern.

Wenn Sie Azure-Richtlinien haben, die DDoS-Schutzpläne auf ein neu erstelltes virtuelles Netzwerk anwenden, lockern Sie entweder die Richtlinie für die Ressourcengruppe, oder stellen Sie sicher, dass die verwaltete Vorlage über Berechtigungen zum Beitritt zum Plan verfügt. Alternativ können Sie die Netzwerktopologie verwenden, für die keine Bereitstellung eines neuen virtuellen Netzwerks durch AIB erforderlich ist.

Wichtig

Stellen Sie sicher, dass Sie alle bewährten Methoden bei der Verwendung von AIB befolgen.

Hinweis

Diese Änderung wird derzeit von AIB für alle Standorte und Kunden eingeführt. Einige dieser Details (insbesondere bei der Bereitstellung neuer netzwerkbezogener Ressourcen) können sich ändern, da der Prozess basierend auf Diensttelemetrie und Feedback optimiert wird. Informationen zu Fehlern finden Sie im Handbuch zur Problembehandlung.

Nächste Schritte