Overzicht van Azure Developer CLI-sjablonen

Een sjabloon Azure Developer CLI (azd) is een codeopslagplaats die de conventies volgtazd. Het combineert projectconfiguratie, infrastructuur als code en optionele toepassingsbron, zodat u herhaalbare Azure omgevingen en implementaties kunt maken.

Sjablonen kunnen verschillende projecttypen ondersteunen, waaronder:

  • Een volledige toepassing met een of meer implementeerbare services.
  • Een oplossing voor alleen infrastructuur zonder toepassingscode.
  • Een herbruikbaar startpunt dat een andere ontwikkelaar kan initialiseren en uitbreiden.
  • Een bestaand project dat u met azd voorbereidt op provisioning en implementatie.

In dit artikel wordt de structuur van een sjabloon uitgelegd en hoe azd opdrachten de bestanden gebruiken.

Waarom een sjabloon gebruiken?

Een sjabloon legt de beslissingen vast die nodig zijn om een project uit te voeren op Azure. Afhankelijk van het project kan het volgende worden gedefinieerd:

  • Azure resources en hun configuratie.
  • Implementeerbare toepassingsservices en verpakkingsinstructies.
  • Verbindingen tussen toepassingsservices en Azure resources.
  • Omgevingsspecifieke parameters en uitvoer.
  • Lokale ontwikkeling, continue integratie en continue leveringsconfiguratie.

Omdat de configuratie wordt opgeslagen met het project, kunnen teams wijzigingen in broncodebeheer controleren en consistente ontwikkel-, test- en productieomgevingen maken.

Hoe azd een sjabloon gebruikt

De bestanden in een sjabloon ondersteunen verschillende fasen van de azd werkstroom:

  • azd init initialiseert het project en maakt een azd omgeving. Het kan ook GitHub Copilot gebruiken om een eerste sjabloon te genereren of een bestaande sjabloon te kopiëren.
  • azd provision evalueert de infrastructuurdefinities en maakt Azure-resources of werkt deze bij.
  • azd package bereidt implementeerbare toepassingsservices voor op basis van azure.yaml.
  • azd deploykoppelt elke service aan de Azure host en implementeert het toepassingspakket.
  • azd up voert de fasen voor inrichting, verpakking en uitrol uit in één gecombineerde workflow.

De sjabloonbestanden blijven regelmatig bronbestanden gedurende dit proces. U kunt ze bekijken, bewerken en versien met de rest van het project.

Azure Developer CLI-sjabloonstructuur verkennen

azd sjablonen zijn standaardcodeopslagplaatsen met extra configuratie- en infrastructuurassets. De meeste sjablonen gebruiken de volgende structuur:

  • azure.yaml bestand : definieert het project en wijst implementeerbare bronmappen toe aan Azure resources.
  • infra map - Bevat de infrastructuur-als-codebestanden van Bicep of Terraform waarmee de Azure-hulpbronnen worden gemaakt.
  • src map : bevat meestal de broncode van de toepassing die kan worden geïmplementeerd. Alleen-infrastructuursjablonen kunnen de toepassingsbron weglaten en toepassingssjablonen kunnen andere bronmapnamen gebruiken.
  • .azure map - Bevat lokale omgevingen en instellingen die zijn aangemaakt door azd. Deze map is de lokale projectstatus en wordt normaal gesproken niet gedeeld als onderdeel van een herbruikbare sjabloon.

Een algemene azd sjabloon kan bijvoorbeeld overeenkomen met de volgende mapstructuur:

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 sjablonen bevatten desgewenst ook een of meer van de volgende mappen:

  • .github map : bevat CI/CD-werkstroombestanden voor GitHub Actions.
  • .azdo map: als u besluit Azure-pipelines voor CI/CD te gebruiken, definieert u de configuratiebestanden van de workflow in deze map.
  • .devcontainer map : definieert een ontwikkelcontaineromgeving voor het project.

In het volgende diagram ziet u hoe de primaire sjabloonassets samenwerken:

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

Vereiste en optionele middelen

De exacte structuur verschilt per project, maar de meeste sjablonen gebruiken de volgende assets.

azure.yaml

Het azure.yaml bestand is het primaire projectconfiguratiebestand. Het definieert de projectnaam en kan implementeerbare services, infrastructuurproviders, hooks, werkstromen en ander azd gedrag definiëren.

Voor een applicatieservice identificeert azure.yaml doorgaans:

  • Het pad naar de toepassingsbron.
  • De programmeertaal of verpakkingsstrategie.
  • De Azure-service die als host fungeert voor de toepassing.
  • Build-, implementatie-, container- of Kubernetes-instellingen.

Met alleen-infrastructuursjablonen kunnen toepassingsservices worden weggelaten. Zie het schema voor het azure.yamlvolledige configuratiemodel.

In het volgende voorbeeld worden twee toepassingsservices gedefinieerd. De servicenamen, bronpaden, talen en hostingdoelen vertellen azd wat u moet verpakken en waar u deze wilt implementeren:

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

Infrastructuur als code

De meeste sjablonen bevatten een infra map met Bicep- of Terraform-bestanden. Deze bestanden definiëren de Azure resources, roltoewijzingen, netwerken, toepassingsinstellingen en implementatie-uitvoer die vereist is voor het project.

Voor de standaard-Bicep-provider gebruikt azd doorgaans infra/main.bicep als startpunt voor de implementatie en infra/main.parameters.json om omgevingswaarden van azd toe te wijzen aan Bicep-parameters. Terraform-sjablonen gebruiken infra/main.tf vaak en gerelateerde Terraform-bestanden.

Een Bicep-parameterbestand kan bijvoorbeeld waarden doorgeven die door azd zijn geselecteerd naar de infrastructuurimplementatie:

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

Wanneer het inrichten met Bicep is voltooid, slaat azd de uitvoer van het ingangspunt op als omgevingswaarden. Toepassingsservices en hooks kunnen deze waarden gebruiken voor resource-eindpunten, namen en andere runtimeconfiguraties.

output API_ENDPOINT string = api.outputs.uri

Bron van de toepassing

De toepassingsbron is optioneel. Wanneer een sjabloon implementeerbare services bevat, verwijst elke servicedefinitie naar azure.yaml de bronmap. Een sjabloon kan services organiseren onder src, mappen ergens anders in de opslagplaats gebruiken of een service aanwijzen in de hoofdmap van de opslagplaats.

De mapnaam zelf is niet belangrijk. De project waarde in azure.yaml bepaalt waar azd elke service wordt gevonden.

Omgevingsconfiguratie

De .azure map bevat de lokale omgevingsstatus en -waarden die zijn gemaakt door azd. Het kan waarden voor abonnement, locatie, resourcenaam, eindpunt en implementatie voor meerdere omgevingen bevatten.

Deze map behandelen als lokale status in plaats van een herbruikbare sjabloonasset. Voer geen omgevingsbestanden door die geheimen of omgevingsspecifieke waarden bevatten.

Ondersteunende middelen

Sjablonen kunnen ook het volgende bevatten:

  • Definities van GitHub Actions of Azure-pipelines.
  • Dockerfiles en containerconfiguratie.
  • Configuratie van ontwikkelcontainers.
  • Opdrachten en servicehooks.
  • Testen, scripts en projectdocumentatie.

Deze assets zijn optioneel en moeten alleen worden opgenomen wanneer ze de beoogde sjabloonervaring ondersteunen.

Koppeling van service en resource

Als u een toepassingsservice wilt implementeren, azd moet u de definitie azure.yaml koppelen aan een ingerichte Azure resource. azd Standaard wordt een resource gevonden waarvan azd-service-name de tag overeenkomt met de servicenaam.

Een service met de naam api wordt bijvoorbeeld toegewezen aan een resource die is getagd met azd-service-name: api. U kunt in plaats daarvan de resourceName service-eigenschap gebruiken om het implementatiedoel expliciet te identificeren.

Met de volgende Bicep-expressie wordt de detectietag toegevoegd aan de bestaande tags van een resource:

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

Houd servicenamen, instellingen voor resourcedetectie, infrastructuuruitvoer en omgevingsvariabelen van toepassingen uitgelijnd wanneer u een sjabloon bewerkt.

Een sjabloon maken of aanpassen

De aanbevolen methode is om azd init uit te voeren en Set up with GitHub Copilot (voorbeeld) te selecteren. De toegewezen Copilot-agent sessie kan bestaande bestanden analyseren, helpen bij het plannen van een nieuw project, het genereren van sjabloonassets en het resultaat valideren. Zie Beginnen met een nieuwe sjabloon voor deze werkstroom en andere ontwerpmethoden.

De gegenereerde bestanden zijn niet gekoppeld aan Copilot. U kunt de sjabloonbestanden direct na de initialisatie verkennen en bewerken . U kunt dezelfde bestanden ook handmatig of met een andere AI-coderingsagent maken.

Als een sjabloon uit Microsoft, uw organisatie of de ontwikkelaarscommunity al een nuttige architectuur biedt, begint u met de bestaande sjabloon en past u deze aan voor uw project. Blader door beschikbare sjablonen in de sjabloongalerieën.

Richtlijnen voor sjabloongebruik

Elke sjabloon wordt gelicentieerd door de eigenaar onder de overeenkomst die bij de sjabloon hoort. Bepaal welke licentie van toepassing is voordat u een sjabloon gebruikt of distribueert.

Microsoft niet verantwoordelijk is voor niet-Microsoft sjablonen en deze niet screent op beveiligings-, privacy-, compatibiliteits- of prestatieproblemen. Sjablonen, waaronder Microsoft geleverde sjablonen, worden niet ondersteund door een Microsoft-ondersteuningsprogramma of -service en worden geleverd zoals is zonder garantie.

Bekijk alle sjabloonbestanden voordat u het inricht. Evalueer met name roltoewijzingen, netwerkblootstelling, verificatiemethoden, servicelagen, resourcelocaties en verwachte kosten.

Volgende stappen

Overzicht van sjabloonontwikkeling

  • Last updated on