Een werkstroom voor het bouwen en implementeren van containers kiezen

Azure Developer CLI (azd) kan containerinstallatiekopieën bouwen, publiceren en implementeren in verschillende Azure hostingservices. Een containerwerkstroom combineert een hostingdoel met een buildlocatie en een publicatiebenadering. De beste combinatie is afhankelijk van uw toepassing, de hulpmiddelen die uw team beschikbaar heeft en hoe u afbeeldingen tussen omgevingen promoveert.

Gebruik dit artikel om deze keuzes aan uw behoeften te koppelen. De volgende beslissingen worden vergeleken:

  • Welke Azure-service fungeert als host voor uw container.
  • Of azd de installatiekopie lokaal bouwt, deze op afstand bouwt in Azure Container Registry (ACR) of een bestaande installatiekopie gebruikt.
  • Of azd de installatiekopie samen of in afzonderlijke stappen publiceert en implementeert.

In het artikel worden deze hostingservices voor algemeen gebruik vergeleken:

Begin met het vergelijken van de hostingdoelen en opties voor het bouwen van images. Nadat u deze keuzes hebt begrepen, gebruikt u deze om een kandidaatwerkstroom te identificeren in de sectie Werkstromen voor containerimplementatie vergelijken .

Hostingdoelen voor containers vergelijken

De host eigenschap in het bestand azure.yaml identificeert de Azure-service waarop azd uw container wordt geïmplementeerd. Kies de host los van de buildlocatie van de installatiekopie.

Hostwaarde Azure-hostingdoel Werkstroom voor containers Overwegingen
containerapp taken voor Azure Container Apps en Container Apps Bouw vanuit een project en een Dockerfile, of implementeer een vooraf gebouwde image. Ondersteunt omgevingsvariabelen op serviceniveau en Container Apps-specifieke implementatiestrategieën. Gebruik dezelfde hostwaarde voor Container Apps-taken.
appservice Linux-web-app voor containers op Azure App Service Bouw op basis van een project en Dockerfile, of rol een vooraf gebouwde image uit. Uw infrastructuur moet een site inrichten die gereed is voor Linux-containers en beheerde identiteittoegang tot ACR configureren. azd deploy werkt alleen de imageverwijzing bij.
aks Azure Kubernetes Service Bouw een image en implementeer Kubernetes-manifesten, Helm-charts of Kustomize-configuraties. Biedt de meeste controle, maar vereist dat u het cluster en de Kubernetes-configuratie beheert. Voor het gebruik van Helm of Kustomize met azd moeten alphafeatureflags worden ingeschakeld.

De ai.endpoint en azure.ai.agent hosts ondersteunen ook Docker-configuratie voor gespecialiseerde Microsoft Foundry-scenario's. Zie Implementeren naar Microsoft Online-eindpunten van Foundry en de Microsoft Foundry-agentextensie voor deze workloads.

Buildopties voor images vergelijken

De servicedefinitie bepaalt of azd een image bouwt of start met een bestaande image.

Build-optie Vereiste configuratie Waar de build wordt uitgevoerd Lokale containerengine Meest geschikt voor
Lokale build project en, optioneel, docker Uw ontwikkelomgeving of CI-runner Required Snelle ontwikkeliteraties en buildomgevingen die al Docker of Podman ondersteunen.
ACR remote build project en docker.remoteBuild: true Azure Container Registratiedienst Niet nodig tenzij azd terugvalt na een mislukte externe build Consistente cloud-builds en -omgevingen zonder een lokale containerengine. De gedocumenteerde werkstroom voor externe builds is gericht op Azure Container Apps.
Bestaande image beheerd door azd image Geen bronbuild Mogelijk vereist voor bewerkingen in de levenscyclus van images Images die al lokaal bestaan of in een registry staan en die azd kan ophalen, taggen en pushen.
Passthrough voor externe installatiekopieën image en docker.imagePassthrough: true Geen build Niet vereist Volledig gespecificeerde externe images die de hostingresource ongewijzigd moet gebruiken.

Houd rekening met deze conceptuele verschillen wanneer u de configuratieartikelen per optie leest:

  • Een vooraf gebouwde image gebruikt de image-eigenschap in plaats van project, en azd kan deze nog steeds ophalen, taggen en uploaden.
  • Een externe ACR-build valt terug op een lokale Docker- of Podman-build wanneer de externe build mislukt en er een ondersteunde container-engine beschikbaar is.
  • Image passthrough vereist een volledig gekwalificeerde verwijzing naar een externe image die een registry bevat, kan niet worden gecombineerd met remoteBuild, en ondersteunt de opties azd publish --from-package en azd publish --to niet, omdat azd de image niet beheert.

Zie ondersteuning voor externe builds met Azure Container Registry, containerregisters van derden gebruiken, App Service-containerimplementaties met Azure Developer CLI en het docker-schema voor de volledige configuratie van elke optie.

Werkstromen voor containerimplementatie vergelijken

Nadat u de hostingdoelen in Containerhostingdoelen vergelijken en de buildopties in Opties voor het bouwen van images vergelijken hebt vergeleken, gebruikt u de volgende tabel om de meest geschikte workflows voor uw behoeften te bepalen.

Als dat nodig is Beginnen met Waarom
Een containertoepassing implementeren op een serverloos platform Azure Container Apps met een lokale build Met deze werkstroom wordt een op Dockerfile gebaseerd project gebouwd en geïmplementeerd in één ontwikkelwerkstroom.
Lokaal bouwen zonder Docker of Podman te installeren Azure Container Apps met een externe ACR-build ACR bouwt de installatiekopieën van uw project en Dockerfile in Azure.
Een image uitrollen dat door een ander buildsysteem wordt geproduceerd Azure Container Apps of App Service met een vooraf gebouwde installatiekopie De eigenschap image verwijst naar de bestaande image in plaats van naar de broncode om te bouwen.
Een externe image hergebruiken zonder die op te halen, te taggen of te uploaden Azure Container Apps met afbeeldingspassthrough azd geeft de volledig gekwalificeerde afbeeldingsreferentie rechtstreeks door aan de hostingresource.
Een traditionele webtoepassing hosten als een Linux-container web-app voor containers op Azure App Service App Service biedt een geïntegreerd webhostingplatform terwijl uw infrastructuur de siteconfiguratie die gereed is voor containers beheert.
Kubernetes-manifesten en clusterconfiguratie beheren Azure Kubernetes Service (AKS) azd kan de images bouwen en publiceren en vervolgens Kubernetes-manifesten, Helm-charts of Kustomize-configuraties implementeren.
Bouw één keer en promoot dezelfde image door verschillende omgevingen heen azd publish, gevolgd door azd deploy --from-package Publiceren en uitrollen staan los van elkaar, dus elke omgeving ontvangt dezelfde image.

Elke rij combineert de hostingkeuzes uit Containerhostingdoelen vergelijken en de buildkeuzes uit Buildopties voor images vergelijken tot een uitgangspunt. Configureer uw keuze in azure.yamlen laat uw Bicep- of Terraform-bestanden de bijbehorende hosting- en registerbronnen inrichten.

Met een minimale servicedefinitie worden de host, de buildbron en de Dockerfile ingesteld:

services:
  api:
    project: ./src/api
    language: docker
    host: containerapp
    docker:
      path: ./Dockerfile

Als u deze definitie wilt aanpassen aan een andere host, wijzigt u de host waarde en volgt u het configuratiecontract per host:

Publicatie- en implementatieopdrachten vergelijken

Nadat u een host- en buildoptie hebt gekozen, selecteert u of u het publiceren en implementeren van installatiekopieën wilt combineren of scheiden.

Command Afbeeldingsacties actie voor Azure-resource Wanneer gebruiken
azd up Bouwen en uploaden Inrichten en uitrollen U wilt de volledige omgeving maken of bijwerken en de toepassing in één werkstroom implementeren.
azd deploy Bouwen en pushen Deploy De infrastructuur bestaat al en u wilt toepassingswijzigingen implementeren.
azd publish Bouwen en uploaden Geen U wilt een registerartefact maken zonder het te implementeren. azd publish biedt ondersteuning voor Container Apps- en AKS-services.
azd publish --from-package <image> Push een bestaande lokale image Geen Een ander proces heeft de image gebouwd en u wilt dat azd publiceren.
azd deploy --from-package <image> Geen Deploy U wilt een specifieke image implementeren zonder die opnieuw te bouwen.

Publiceer bijvoorbeeld een image met versienummer en implementeer diezelfde image in een andere omgeving:

azd publish api --to myregistry.azurecr.io/my-api:v1.0.0
azd env select production
azd deploy api --from-package myregistry.azurecr.io/my-api:v1.0.0

Deze workflow voorkomt verschillen die kunnen optreden wanneer u voor elke omgeving een image opnieuw opbouwt. Zie Azure Developer CLI-publicatiewerkstromen voor een volledige promotiewerkstroom.

Verwante onderwerpen

  • Laatst bijgewerkt om