Översikt över CLI-mallar för Azure Developer

En Azure Developer CLI-mall (azd) är en koddatabas som följer konventionerna i azd. Den kombinerar projektkonfiguration, infrastruktur som kod och valfri programkälla så att du kan skapa repeterbara Azure miljöer och distributioner.

Mallar kan ha stöd för olika projekttyper, bland annat:

  • Ett komplett program med en eller flera distributionsbara tjänster.
  • En lösning endast för infrastruktur utan programkod.
  • En återanvändbar startpunkt som en annan utvecklare kan initiera och utöka.
  • Ett befintligt projekt som du förbereder för etablering och distribution med azd.

I den här artikeln beskrivs strukturen för en mall och hur azd kommandon använder dess filer.

Varför ska jag använda en mall?

En mall samlar in de beslut som krävs för att köra ett projekt på Azure. Beroende på projektet kan det definiera:

  • Azure resurser och deras konfiguration.
  • Distributionsbara programtjänster och paketeringsinstruktioner.
  • Anslutningar mellan programtjänster och Azure resurser.
  • Miljöspecifika parametrar och utdata.
  • Lokal utveckling, kontinuerlig integrering och konfiguration av kontinuerlig leverans.

Eftersom konfigurationen lagras med projektet kan team granska ändringar i källkontrollen och skapa konsekventa utvecklings-, test- och produktionsmiljöer.

Hur azd använder en mall

Filerna i en mall stöder olika steg i azd arbetsflödet:

  • azd init initierar projektet och skapar en azd miljö. Den kan också använda GitHub Copilot för att generera en första mall eller kopiera en befintlig mall.
  • azd provisionutvärderar infrastrukturdefinitionerna och skapar eller uppdaterar Azure resurser.
  • azd package förbereder distributionsbara programtjänster enligt azure.yaml.
  • azd deployassocierar varje tjänst med dess Azure värd och distribuerar programpaketet.
  • azd up kör etablerings-, paketerings- och distributionsstegen som ett kombinerat arbetsflöde.

Mallfilerna förblir vanliga källfiler under hela den här processen. Du kan granska, redigera och version dem med resten av projektet.

Utforska CLI-mallstrukturen för Azure Developer

azd mallar är standardkodlagringsplatser med extra konfigurations- och infrastrukturtillgångar. De flesta mallar använder följande struktur:

  • azure.yaml file – Definierar projektet och mappar distributionsbara källkataloger till Azure resurser.
  • infra folder – Innehåller de Bicep- eller Terraform-infrastruktur-som-kod-filer som skapar Azure resurser.
  • src mapp – innehåller ofta distributionsbar källkod för program. Endast infrastrukturmallar kan utelämna programkällan, och programmallar kan använda andra källkatalognamn.
  • .azure folder – Innehåller lokala miljöer och värden som skapats av azd. Den här mappen är lokalt projekttillstånd och delas normalt inte som en del av en återanvändbar mall.

En vanlig azd mall kan till exempel matcha följande mappstruktur:

contoso-project/
├── azure.yaml                 # azd project and service configuration
├── infra/
│   ├── main.bicep            # Infrastructure entry point
│   └── main.parameters.json  # Maps azd values to Bicep parameters
├── src/                      # Optional application source
│   ├── api/
│   └── web/
├── .github/workflows/        # Optional GitHub Actions pipelines
└── .azure/                   # Local environment state; don't distribute

azd mallar kan också innehålla en eller flera av följande mappar:

  • .github mapp – Innehåller CI/CD-arbetsflödesfiler för GitHub Actions.
  • .azdo mapp – Om du väljer att använda Azure-pipelines för CI/CD definierar du arbetsflödeskonfigurationsfilerna i den här mappen.
  • .devcontainer folder – Definierar en utvecklingscontainermiljö för projektet.

Följande diagram visar hur de primära malltillgångarna fungerar tillsammans:

flowchart LR
AZ[azure.yaml] -->|Defines services| SRC[Application source]
AZ -->|Selects provider and path| INFRA[Infrastructure as code]
INFRA -->|Provisions| RES[Azure resources]
INFRA -->|Exports values| ENV[azd environment]
ENV -->|Configures| SRC
AZ -->|Maps services to| RES

Obligatoriska och valfria tillgångar

Den exakta strukturen varierar beroende på projekt, men de flesta mallar använder följande tillgångar.

azure.yaml

Filen azure.yaml är den primära projektkonfigurationsfilen. Den definierar projektnamnet och kan definiera distributionsbara tjänster, infrastrukturleverantörer, krokar, arbetsflöden och annat azd beteende.

För en programtjänst azure.yaml identifierar vanligtvis:

  • Sökvägen till programmets källkod.
  • Programmeringsspråket eller paketeringsstrategin.
  • Den Azure tjänst som är värd för programmet.
  • Inställningar för build, distribution, container eller Kubernetes.

Mallar som endast omfattar infrastruktur kan utelämna applikationstjänster. Se schemat för den fullständiga konfigurationsmodellenazure.yaml.

I följande exempel definieras två programtjänster. Tjänstnamnen, källsökvägarna, språken och värdmålen anger azd vad de ska paketera och var de ska distribueras:

name: store
services:
  api:
    project: ./src/api
    language: js
    host: containerapp
  web:
    project: ./src/web
    language: js
    host: staticwebapp

Infrastruktur som kod

De flesta mallar innehåller en infra katalog med Bicep- eller Terraform-filer. Dessa filer definierar Azure resurser, rolltilldelningar, nätverk, programinställningar och distributionsutdata som krävs av projektet.

För standardprovidern azd Bicep används infra/main.bicep vanligtvis som distributionsstartpunkt och infra/main.parameters.json för att mappa azd miljövärden till Bicep parametrar. Terraform-mallar använder infra/main.tf ofta och relaterade Terraform-filer.

Till exempel kan en Bicep parameterfil skicka värden som valts av azd till infrastrukturdistributionen:

{
  "parameters": {
    "environmentName": { "value": "${AZURE_ENV_NAME}" },
    "location": { "value": "${AZURE_LOCATION}" }
  }
}

När etableringen med Bicep är klar lagrar azd utdata från startpunkten som miljövärden. Programtjänster och krokar kan använda dessa värden för resursslutpunkter, namn och annan körningskonfiguration.

output API_ENDPOINT string = api.outputs.uri

Programkälla

Programkällan är valfri. När en mall innehåller distributionsbara tjänster pekar varje tjänstdefinition i azure.yaml på källkatalogen. En mall kan ordna tjänster under src, använda kataloger någon annanstans på lagringsplatsen eller peka en tjänst på lagringsplatsens rot.

Själva mappnamnet är inte betydande. Värdet project i azure.yaml avgör var azd varje tjänst hittas.

Miljökonfiguration

Katalogen .azure innehåller lokala miljötillstånd och värden som skapats av azd. Den kan innehålla utdatavärden för prenumeration, plats, resursnamn, slutpunkt och distribution för flera miljöer.

Behandla den här katalogen som lokalt tillstånd i stället för en återanvändbar malltillgång. Checka inte in miljöfiler som innehåller hemligheter eller miljöspecifika värden.

Stödtillgångar

Mallar kan också innehålla:

  • definitioner för GitHub Actions eller Azure-pipelines
  • Dockerfiles och containerkonfiguration.
  • Konfiguration av utvecklingscontainer.
  • Kommando- och servicehookar.
  • Tester, skript och projektdokumentation.

Dessa tillgångar är valfria och bör endast inkluderas när de stöder den avsedda mallupplevelsen.

Tjänst- och resursassociation

Om du vill distribuera en programtjänst azd måste du associera dess definition med azure.yaml en etablerad Azure resurs. Som standard hittar azd en resurs vars azd-service-name-tagg matchar tjänstens namn.

Till exempel mappar en tjänst med namnet api till en resurs taggad med azd-service-name: api. Du kan i stället använda tjänstegenskapen resourceName för att uttryckligen identifiera distributionsmålet.

Följande Bicep-uttryck lägger till identifieringstaggen i de befintliga taggarna för en resurs:

tags: union(tags, {
  'azd-service-name': 'api'
})

Behåll tjänstnamn, inställningar för resursidentifiering, infrastrukturutdata och programmiljövariabler justerade när du redigerar en mall.

Skapa eller anpassa en mall

Den rekommenderade redigeringsupplevelsen är att köra azd init och välja Konfigurera med GitHub Copilot (förhandsgranskning). Den dedikerade Copilot-agent-sessionen kan analysera befintliga filer, planera ett nytt projekt, generera malltillgångar och verifiera resultatet. Det här arbetsflödet och andra redigeringsmetoder finns i Börja med en ny mall.

De genererade filerna är inte kopplade till Copilot. Du kan utforska och redigera mallfilerna direkt efter initieringen. Du kan också skapa samma filer manuellt eller med en annan AI-kodningsagent.

Om en mall från Microsoft, din organisation eller utvecklarcommunityn redan har en användbar arkitektur kan du börja från den befintliga mallen och anpassa den för ditt projekt. Bläddra bland tillgängliga mallar i mallgallerierna.

Riktlinjer för mallanvändning

Varje mall licensieras av ägaren enligt det avtal som medföljer mallen. Ta reda på vilken licens som gäller innan du använder eller distribuerar en mall.

Microsoft ansvarar inte för icke-Microsoft mallar och kontrollerar dem inte för säkerhets-, sekretess-, kompatibilitets- eller prestandaproblem. Mallar, inklusive mallar som tillhandahålls av Microsoft, stöds inte av ett Microsoft supportprogram eller tjänst och tillhandahålls som de är utan garanti.

Granska alla mallfiler innan du driftsätter. I synnerhet utvärdera rolltilldelningar, nätverksexponering, autentiseringsmetoder, tjänstnivåer, resursplatser och förväntade kostnader.

Nästa steg

Översikt över mallutveckling

  • Last updated on