Automatisieren von Build- und Wartungsvorgängen für Containerimages mit Azure Container Registry-Tasks
Container bieten neue Virtualisierungsmöglichkeiten durch die Trennung der Anwendungs- und Entwicklerabhängigkeiten von Infrastruktur- und Betriebsanforderungen. Die Auseinandersetzung mit dem Verwalten und Patchen dieser Anwendungsvirtualisierung über den Containerlebenszyklus ist weiterhin erforderlich.
Azure Container Registry-Tasks sind eine Sammlung von Features, die Folgendes ermöglichen:
- Bereitstellen eines cloudbasierten Containerimages für Plattformen wie Linux, Windows und ARM
- Ausdehnen der frühen Phasen eines Anwendungsentwicklungszyklus auf die Cloud mit bedarfsgesteuerten Buildvorgängen für Containerimages
- Aktivieren automatisierter Buildvorgänge, die durch Quellcodeupdates, Updates des Basisimages eines Containers oder Zeitgeber ausgelöst werden
Mit Triggern für Updates eines Basisimages können Sie beispielsweise das Patchen des Betriebssystems und des Frameworks für Ihre Docker-Container automatisieren. Diese Trigger können Sie bei der Wartung sicherer Umgebungen und der gleichzeitigen Einhaltung der Prinzipien unveränderlicher Container unterstützen.
Wichtig
Die Ausführungen der Azure Container Registry-Tasks werden vorübergehend von der kostenlosen Azure-Gutschrift ausgeschlossen. Dieser Ausschluss könnte sich auf vorhandene Taskausführungen auswirken. Wenn Probleme auftreten, öffnen Sie einen Supportfall für unser Team, um zusätzliche Anleitungen bereitzustellen.
Warnung
Beachten Sie, dass alle Informationen, die in der Befehlszeile oder als Teil eines URI bereitgestellt werden, im Rahmen der Azure Container Registry-Diagnoseablaufverfolgung (ACR) protokolliert werden können. Dazu gehören vertrauliche Daten wie Anmeldeinformationen, persönliche GitHub-Zugriffstoken und andere sichere Informationen. Gehen Sie vorsichtig vor, um potenzielle Sicherheitsrisiken zu verhindern. Vertrauliche Details in Befehlszeilen oder URIs, die der Diagnoseprotokollierung unterliegen, sollten unbedingt vermieden werden.
Taskszenarien
Azure Container Registry-Tasks unterstützen mehrere Szenarios zum Erstellen und Verwalten von Containerimages und weiteren Artefakten. In diesem Artikel werden Schnelltasks, automatisch ausgelöste Vorgänge und Tasks mit mehreren Schritten beschrieben.
Jeder Task verfügt über einen zugeordneten Quellcodekontext, bei dem es sich um den Speicherort von Quelldateien handelt, die zum Erstellen eines Containerimages oder eines weiteren Artefakts verwendet werden. Beispielkontexte schließen ein Git-Repository und ein lokales Dateisystem ein.
Tasks können auch Laufzeitvariablen nutzen, sodass Sie Taskdefinitionen wiederverwenden und Tags für Images und Artefakte standardisieren können.
Schnelle Aufgaben
Der Inner-Loop-Entwicklungszyklus ist der iterative Prozess zum Schreiben von Code und zum Erstellen und Testen der Anwendung, bevor Sie diese in die Quellcodeverwaltung committen. Er stellt den Anfang der Lebenszyklusverwaltung von Containern dar.
Das Feature Schnelltasks in den Azure Container Registry-Tasks kann durch das Auslagern Ihrer Buildvorgänge für Containerimages in Azure eine integrierte Entwicklungsumgebung bieten. Sie können ein einzelnes Containerimage bedarfsgesteuert in Azure erstellen und in eine Containerregistrierung pushen, ohne eine lokale Docker Engine-Installation zu benötigen. Kurz: docker build
, docker push
in die Cloud. Mit Schnelltasks können Sie Ihre automatisierten Builddefinitionen überprüfen und potenzielle Probleme abfangen, bevor Sie Ihren Code committen.
Durch die Verwendung des vertrauten docker build
-Formats erhält der Befehl az acr build in der Azure CLI einen Kontext. Der Befehl sendet anschließend den Kontext an Azure Container Registry und pusht das erstellte Image nach Abschluss standardmäßig in seine Registrierung.
Azure Container Registry-Tasks sind als einfacher Containerlebenszyklustyp konzipiert. Beispiel: Sie können Azure Container Registry-Tasks in Ihre CI/CD-Lösung (Continuous Integration und Continuous Delivery) integrieren. Wenn Sie az login mit einem Dienstprinzipal ausführen, kann Ihre CI/CD-Lösung daraufhin az acr build-Befehle ausgeben, um Buildvorgänge für Images zu starten.
Informationen zum Verwenden von Schnelltasks finden Sie im Schnellstart und Tutorial zum Erstellen und Bereitstellen von Containerimages mithilfe von Azure Container Registry-Tasks.
Tipp
Wenn Sie ein Image direkt aus dem Quellcode ohne Dockerfile-Datei erstellen und pushen möchten, nutzen Sie den az acr pack build-Befehl (Vorschau) der Azure Container Registry. Mit diesem Tool wird mithilfe von Cloud Native Buildpacks ein Image aus dem Quellcode der Anwendung erstellt und gepusht.
Automatisch ausgelöste Tasks
Aktivieren Sie einen oder mehrere Trigger, um ein Image zu erstellen.
Auslösen eines Tasks für ein Quellcodeupdate
Sie können einen Buildvorgang von Containerimages oder einen Task mit mehreren Schritten auslösen, wenn Code in ein öffentliches oder privates Git-Repository in GitHub oder Azure DevOps committet oder ein Pull Request erstellt oder aktualisiert wird. Konfigurieren Sie z. B. einen Buildtask mithilfe des Azure CLI-Befehls az acr task create, indem Sie ein Git-Repository und optional einen Branch und eine Dockerfile-Datei angeben. Wenn Ihr Team Code im Repository aktualisiert, löst ein im Azure Container Registry-Task erstellter Webhook einen Buildvorgang des Containerimages aus, das im Repository definiert ist.
Azure Container Registry-Tasks unterstützen die folgenden Trigger, wenn Sie ein Git-Repository als Kontext eines Tasks festlegen:
Trigger | Standardmäßig aktiviert |
---|---|
Commit | Ja |
Pull Request | Nein |
Hinweis
Derzeit unterstützen Azure Container Registry-Tasks keine Trigger für Commits oder Pull Requests in GitHub Enterprise-Repositorys.
Informationen zum Auslösen von Buildvorgängen für Quellcodecommits finden Sie unter Automatisieren von Buildvorgängen für Containerimages mit Azure Container Registry-Tasks.
Persönliches Zugriffstoken
Um einen Trigger für Quellcodeupdates zu konfigurieren, müssen Sie dem Task ein persönliches Zugriffstoken bereitstellen, um den Webhook im öffentlichen oder privaten Repository von GitHub oder Azure DevOps festzulegen. Erforderliche Bereiche für das persönliche Zugriffstoken lauten folgendermaßen:
Repositorytyp | GitHub | Azure DevOps |
---|---|---|
Öffentliches Repository | repo:status public_repo |
Code (Lesen) |
Privates Repository | Repository (Vollzugriff) | Code (Lesen) |
Informationen zum Erstellen eines persönlichen Zugriffstokens finden Sie in der Dokumentation zu GitHub oder Azure DevOps.
Automatisierung von Betriebssystem- und Frameworkpatching
Die Stärke von Azure Container Registry-Tasks zur Verbesserung Ihres Workflows von Buildvorgängen für Container liegt in ihrer Fähigkeit, ein Update an einem Basisimage zu erkennen. Ein Basisimage ist ein Feature der meisten Containerimages. Dabei handelt es sich um ein übergeordnetes Image, auf dem mindestens ein Anwendungsimage basiert. Basisimages enthalten in der Regel das Betriebssystem und gelegentlich Anwendungsframeworks.
Sie können einen Azure Container Registry-Task einrichten, um eine Abhängigkeit von einem Basisimage zu verfolgen, wenn dieses ein Anwendungsimage erstellt. Wenn das aktualisierte Basisimage in Ihre Registrierung gepusht oder ein Basisimage in einem öffentlichen Repository wie in Docker Hub aktualisiert wird, können Azure Container Registry-Tasks automatisch alle darauf basierenden Anwendungsimages erstellen. Durch diese automatische Erkennung und Neuerstellung können Sie mit Azure Container Registry-Tasks Zeit und Aufwand sparen, die normalerweise erforderlich sind, um jedes Anwendungsimage, das auf Ihr aktualisiertes Basisimage verweist, manuell nachzuverfolgen und zu aktualisieren.
Weitere Informationen finden Sie unter Informationen zu Basisimageupdates für Azure Container Registry-Tasks und Tutorial: Automatisieren von Buildvorgängen für Containerimages, wenn ein Basisimage in einer Azure Container Registry-Instanz aktualisiert wird.
Planen eines Tasks
Sie können einen Task planen, indem Sie einen oder mehrere Zeitgebertrigger einrichten, wenn Sie den Task erstellen oder aktualisieren. Das Planen eines Tasks eignet sich zum Ausführen von Containerworkloads nach einem definierten Zeitplan oder zum Ausführen von Wartungsvorgängen oder Tests für Images, die regelmäßig in Ihre Registrierung gepusht werden. Weitere Informationen finden Sie unter Ausführen eines Azure Container Registry-Tasks nach einem definierten Zeitplan.
Mehrstufige Tasks
Erweitern Sie die Build- und Pushfunktion von Azure Container Registry-Tasks durch Workflows mit mehreren Schritten, die auf mehreren Containern basieren.
Mehrstufige Aufgaben bieten schrittbasierte Aufgabendefinition und -ausführung für Erstellen, Testen und Patchen von Containerimages in der Cloud. In einer YAML-Datei definierte Taskschritte legen einzelne Build- und Pushvorgänge für Containerimages oder andere Artefakte fest. Sie können auch die Ausführung eines oder mehrerer Container mit jedem Schritt definieren, wobei der Container als Ausführungsumgebung verwendet wird.
Beispielsweise können Sie einen Task mit mehreren Schritten erstellen, der die folgenden Schritte automatisiert:
- Erstellen eines Webanwendungsimages
- Ausführen des Webanwendungscontainers
- Erstellen eines Testimages für Webanwendungen
- Ausführen des Testcontainers für Webanwendungen, der Tests für den aktuell ausgeführten Anwendungscontainer durchführt
- Wenn die Tests erfolgreich sind: Erstellen eines Archivpakets für Helm-Charts
- Ausführen eines
helm upgrade
-Tasks mithilfe des neuen Archivpakets für Helm-Charts
Durch Tasks mit mehreren Schritten können Sie das Erstellen, Ausführen und Testen eines Images in mehr kompilierbare Schritte mit Abhängigkeitsunterstützung zwischen den Schritten aufteilen. Durch Tasks mit mehreren Schritten in Azure Container Registry-Tasks haben Sie eine genauere Kontrolle über Workflows für die Imageerstellung, Tests und das Patchen des Betriebssystems und des Frameworks.
Kontextspeicherorte
Die folgende Tabelle enthält Beispiele für unterstützte Kontextspeicherorte für Azure Container Registry-Tasks:
Kontextspeicherort | BESCHREIBUNG | Beispiel |
---|---|---|
Ein lokales Dateisystem | Dateien in einem Verzeichnis im lokalen Dateisystem | /home/user/projects/myapp |
GitHub-Mainbranch | Dateien im Mainbranch (oder einem anderen Standardbranch) eines öffentlichen oder privaten GitHub-Repositorys | https://github.com/gituser/myapp-repo.git |
GitHub-Branch | Bestimmter Branch eines öffentlichen oder privaten GitHub-Repositorys | https://github.com/gituser/myapp-repo.git#mybranch |
GitHub-Unterordner | Dateien in einem Unterordner in einem öffentlichen oder privaten GitHub-Repository. Das Beispiel zeigt die Kombination aus einer Branch- und Unterordnerspezifikation. | https://github.com/gituser/myapp-repo.git#mybranch:myfolder |
GitHub-Commit | Spezifischer Commit in ein öffentliches oder privates GitHub-Repository. Das Beispiel zeigt die Kombination aus einem Commit-Hash (SHA) und einer Unterordnerspezifikation. | https://github.com/gituser/myapp-repo.git#git-commit-hash:myfolder |
Azure DevOps-Unterordner | Dateien in einem Unterordner in einem öffentlichen oder privaten Azure-Repository. Das Beispiel zeigt die Kombination aus einer Branch- und Unterordnerspezifikation. | https://dev.azure.com/user/myproject/_git/myapp-repo#mybranch:myfolder |
Remotetarball | Dateien in einem komprimierten Archiv auf einem Remotewebserver | http://remoteserver/myapp.tar.gz |
Artefakt in Containerregistrierung | OCI-Artefaktdateien in einem Repository einer Containerregistrierung. | oci://myregistry.azurecr.io/myartifact:mytag |
Hinweis
Wenn Sie ein Git-Repository als Kontext für einen Task verwenden, der durch ein Quellcodeupdate ausgelöst wird, müssen Sie ein persönliches Zugriffstoken bereitstellen.
Imageplattformen
Standardmäßig erstellen Azure Container Registry-Tasks Images für das Linux-Betriebssystem und die AMD64-Architektur. Geben Sie das Tag --platform
an, um Windows-Images oder Linux-Images für andere Architekturen zu erstellen. Geben Sie das Betriebssystem und optional eine unterstützte Architektur im Format Betriebssystem/Architektur an (z. B. --platform Linux/arm
). Geben Sie für ARM-Architekturen optional eine Variante im Format Betriebssystem/Architektur/Variante an (z. B. --platform Linux/arm64/v8
).
Betriebssystem | Aufbau |
---|---|
Linux | AMD64 ARM ARM64 386 |
Windows | AMD64 |
Taskausgabe
Bei jeder Aufgabenausführung wird eine Protokollausgabe erzeugt, die Sie überprüfen können, um festzustellen, ob die Aufgabenschritte erfolgreich ausgeführt wurden. Wenn Sie einen Task manuell auslösen, wird die Protokollausgabe für die Taskausführung an die Konsole gestreamt und für ein späteres Abrufen gespeichert. Wenn ein Task automatisch beispielsweise durch einen Quellcodecommit oder ein Basisimageupdate ausgelöst wird, werden lediglich die Taskprotokollen gespeichert. Zeigen Sie die Ausführungsprotokolle im Azure-Portal an, oder verwenden Sie den Befehl az acr task logs.
Hier erfahren Sie mehr über das Anzeigen und Verwalten von Taskprotokollen.
Zugehöriger Inhalt
Weitere Informationen zum Automatisieren von Build- und Wartungsvorgänge in der Cloud finde Sie unter Tutorial: Erstellen und Bereitstellen von Containerimages in der Cloud mit Azure Container Registry-Tasks.
Weitere Informationen finden Sie optional für die Docker-Erweiterung und die Azure-Kontoerweiterung für Visual Studio Code. Sie können diese Erweiterungen für Folgendes in Visual Studio Code verwenden: zum Pullen von Images aus einer Containerregistrierung, zum Pushen von Images in eine Containerregistrierung oder zum Ausführen von Azure Container Registry-Tasks.