Veelgestelde vragen over Azure Developer CLI

Er zijn verschillende opties voor het verwijderen van azd, afhankelijk van hoe u deze oorspronkelijk hebt geïnstalleerd. Ga naar de -installatiepagina voor meer informatie.

Azure Developer CLI (azd) en Azure CLI (az) zijn beide opdrachtregelprogramma's, maar ze helpen u verschillende taken uit te voeren.

azd richt zich op de werkstroom voor ontwikkelaars op hoog niveau. Naast het inrichten/beheren van Azure-resources helpt azd om cloudonderdelen, lokale ontwikkelingsconfiguratie en pijplijnautomatisering samen te voegen in een volledige oplossing.

Azure CLI is een besturingsvlakhulpprogramma voor het maken en beheren van een Azure-infrastructuur, zoals virtuele machines, virtuele netwerken en opslag. De Azure CLI is ontworpen rond gedetailleerde opdrachten voor specifieke beheertaken.

Azure Developer CLI gebruikt een omgevingsnaam om de AZURE_ENV_NAME omgevingsvariabele in te stellen die wordt gebruikt door Azure Developer CLI-sjablonen. AZURE_ENV_NAME wordt ook gebruikt om de naam van de Azure-resourcegroep voor tevoegen. Omdat elke omgeving een eigen set configuraties heeft, slaat Azure Developer CLI alle configuratiebestanden op in omgevingsmappen.

├── .Azure                          [This directory displays after you run add init or azd up]
│   ├── <your environment1>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └── <your environment2>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └──config.json 

Ja. U kunt verschillende omgevingen instellen (bijvoorbeeld dev, test, productie). U kunt azd env gebruiken om deze omgevingen te beheren.

Het pad naar het .env-bestand is <your-project-directory-name>\.azure\<your-environment-name>\.env.

In Azure Developer CLI verwijzen de azd opdrachten naar het .env-bestand voor omgevingsconfiguratie. Opdrachten zoals azd deploy ook het .env-bestand bijwerken met bijvoorbeeld de db-verbindingsreeks en het Azure Key Vault-eindpunt.

Ja. U kunt het ontwikkelwerk lokaal voortzetten.

1. Voer azd init -t <template repo> uit om het sjabloonproject te klonen op uw lokale computer.
2. Voer azd env refreshuit om de bestaande env die met Codespaces is gemaakt, op te halen. Zorg ervoor dat u dezelfde omgevingsnaam, hetzelfde abonnement en dezelfde locatie opgeeft als voorheen.

In het bestand azure.yaml worden de apps en typen Azure-resources beschreven die zijn opgenomen in de sjabloon.

De secretOrRandomPassword-functie haalt een geheim op uit Azure Key Vault als parameters voor de naam en het geheim van de sleutelkluis worden opgegeven. Als deze parameters niet worden opgegeven of als er geen geheim kan worden opgehaald, retourneert de functie een willekeurig gegenereerd wachtwoord dat moet worden gebruikt.

In het volgende voorbeeld ziet u een veelvoorkomend gebruiksvoorbeeld van de secretOrRandomPassword in een main.parameters.json-bestand. De variabelen ${AZURE_KEY_VAULT_NAME} en sqlAdminPassword worden doorgegeven als parameters voor de namen van de Sleutelkluis en het geheim. Als de waarde niet kan worden opgehaald, wordt in plaats daarvan een willekeurig wachtwoord gegenereerd.

  "sqlAdminPassword": {
    "value": "$(secretOrRandomPassword ${AZURE_KEY_VAULT_NAME} sqlAdminPassword)"
  } 

De uitvoer van secretOrRandomPassword moet ook worden opgeslagen in Key Vault met Bicep voor toekomstige uitvoeringen. Het ophalen en hergebruiken van dezelfde geheimen voor implementaties kan fouten of onbedoeld gedrag voorkomen dat optreedt bij het herhaaldelijk genereren van nieuwe waarden. Als u een sleutelkluis wilt maken en het gegenereerde geheim erin wilt opslaan, gebruikt u de Bicep-code hieronder. U kunt de volledige voorbeeldcode voor deze modules bekijken in de Azure Developer CLI GitHub-opslagplaats.

module keyVault './core/security/keyvault.bicep' = {
  name: 'keyvault'
  scope: resourceGroup
  params: {
    name: '${take(prefix, 17)}-vault'
    location: location
    tags: tags
    principalId: principalId
  }
}

module keyVaultSecrets './core/security/keyvault-secret.bicep' = {
  name: 'keyvault-secret-sqlAdminPassword'
  scope: resourceGroup
  params: {
    keyVaultName: keyVault.outputs.name
    name: 'sqlAdminPassword'
    secretValue: sqlAdminPassword
  }
}]

Met deze Bicep-installatie kan de volgende werkstroom worden gebruikt voor het beheren van uw geheimen:

1. Als het opgegeven geheim bestaat, wordt het opgehaald uit Key Vault met behulp van de functie secretOrRandomPassword.
2. Als het geheim niet bestaat, wordt er een sleutelkluis gemaakt en wordt het willekeurig gegenereerde geheim erin opgeslagen.
3. Bij toekomstige implementaties haalt de secretOrRandomPassword methode het opgeslagen geheim op nu het in Key Vault bestaat. De Sleutelkluis wordt niet opnieuw gemaakt als deze al bestaat, maar dezelfde geheime waarde wordt opnieuw opgeslagen voor de volgende uitvoering.

Ja, maar elke Azure-locatie kan slechts één implementatie hebben. Als u de geselecteerde Azure-locatie al hebt gebruikt, ziet u de implementatiefout:

InvalidTemplateDeployment: The template deployment '<env_name>' isn't valid according to the validation procedure. The tracking ID is '<tracking_id>'. See inner errors for details.

U kunt een andere Azure-locatie selecteren om het probleem op te lossen.

Dit kan gebeuren vanwege onze methode voor het benoemen van resources.

Met onze door Azure Dev geschreven sjablonen kunt u de naam van de resource configureren. Hiervoor kunt u een vermelding toevoegen aan de main.parameters.json in de map infra. Bijvoorbeeld:

  "webServiceName": {
  "value": "my-unique-name"
}

Met deze vermelding maakt u een nieuwe resource met de naam 'my-unique-name' in plaats van een gerandomiseerde waarde, zoals 'app-web-aj84u2adj' wanneer u de toepassing de volgende keer inricht. U kunt de oude resourcegroep handmatig verwijderen met behulp van Azure Portal of azd down uitvoeren om alle vorige implementaties te verwijderen. Nadat u de resources hebt verwijderd, voert u azd provision uit om ze opnieuw te maken met de nieuwe naam.

Deze naam moet globaal uniek zijn, anders krijgt u een ARM-fout tijdens azd provision wanneer de resource wordt gemaakt.

De opdracht maakt gebruik van Bicep-sjablonen, die worden gevonden onder <your-project-directory-name>/infra voor het inrichten van Azure-resources.

Ga naar https://portal.azure.com en zoek vervolgens naar uw resourcegroep, die rg-<your-environment-name>is.

We gebruiken Bicep-sjablonen, die worden gevonden onder <your-project-directory-name>/infra, om Azure-resources in te richten. Als er problemen zijn, nemen we het foutbericht op in de CLI-uitvoer.

U kunt ook naar https://portal.azure.com gaan en vervolgens naar uw resourcegroep zoeken. Dit is rg-<your-environment-name>. Als een van de implementaties mislukt, selecteert u de foutkoppeling voor meer informatie.

Zie Veelvoorkomende Azure-implementatiefouten oplossen - Azure Resource Manager-voor andere resources.

Binnenkort beschikbaar. Deze functie is gepland voor een toekomstige release.

Ja.

Tijdens de implementatie detecteert azd eerst alle resourcegroepen waaruit uw toepassing bestaat door te zoeken naar groepen die zijn getagd met azd-env-name en met een waarde die overeenkomt met de naam van uw omgeving. Vervolgens worden alle resources in elk van deze resourcegroepen opgesomd, op zoek naar een resource die is getagd met azd-service-name met een waarde die overeenkomt met de naam van uw service uit azure.yaml.

Hoewel u wordt aangeraden tags te gebruiken voor resources, kunt u ook de eigenschap resourceName in azure.yaml gebruiken om een expliciete resourcenaam op te geven. In dat geval wordt de bovenstaande logica niet uitgevoerd.

Wanneer u uw project implementeert, kunt u ervoor kiezen om specifieke services te implementeren door de servicenaam op te geven in de opdracht (bijvoorbeeld azd deploy api) of door te navigeren naar een submap die alleen de service(s) bevat die u wilt implementeren. Als u dit doet, worden alle andere services vermeld als - Skipped.

Als u geen services wilt overslaan, moet u de opdracht uitvoeren vanuit de hoofdmap of de vlag --all toevoegen aan uw opdracht.

Ja. We gebruiken de incrementele implementatiemodus.

Binnenkort beschikbaar. Deze functie is gepland voor een toekomstige release.

Een Azure-service-principal is een identiteit die wordt gemaakt voor gebruik met apps, gehoste services en geautomatiseerde hulpprogramma's voor toegang tot Azure-resources. Deze toegang wordt beperkt door de rollen die zijn toegewezen aan de service-principal, waarmee u kunt bepalen welke resources kunnen worden geopend en op welk niveau. Zie voor meer informatie over verificatie van Azure naar GitHub Connect GitHub en Azure | Microsoft Docs.

Nee. De opdracht azd pipeline config zorgt voor het maken van de Azure-service-principal en het uitvoeren van de benodigde stappen voor het opslaan van de geheimen in uw GitHub-opslagplaats.

Met de opdracht worden vier geheimen opgeslagen in GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION en AZURE_SUBSCRIPTION_ID. U kunt de waarde van elk geheim overschrijven door naar https://github.com/<your-GH-account>/<your-repo>/secrets/actionste gaan.

Met OpenID Connectkunnen uw werkstromen rechtstreeks vanuit Azure tokens met korte levensduur uitwisselen.

Hoewel OIDC wordt ondersteund als de standaardinstelling voor GitHub Actions en Azure Pipeline (ingesteld als federatieve), wordt deze niet ondersteund voor Azure DevOps of Terraform.

• Voor Azure DevOps leidt het expliciet aanroepen van --auth-type als federated tot een fout.
• Voor Terraform:
  • Als --auth-type niet is gedefinieerd, valt deze terug op clientcredentials en resulteert dit in een waarschuwing.
  • Als --auth-type expliciet is ingesteld op federated, resulteert dit in een fout.

Ga naar https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsen werk AZURE_CREDENTIALS vervolgens bij door het hele JSON-object voor de nieuwe service-principal te kopiëren en te plakken. Bijvoorbeeld:

{
  "clientId": "<GUID>",
  "clientSecret": "<GUID>",
  "subscriptionId": "<GUID>",
  "tenantId": "<GUID>",
  (...)
}

Het bestandspad van GitHub Actions is <your-project-directory-name>\.github\workflows\azure-dev.yml.

Ja. Vervang run: azd up --no-prompt door run: azd deploy --no-prompt.

Ga naar https://github.com/<your-GH-account>/<your-repo>/actionsen raadpleeg het logboekbestand in de werkstroomuitvoering.

Wanneer u containertoepassingen lokaal bouwt, moet u azd auth login uitvoeren in de container zodat de toepassing kan werken met de AzureDeveloperCliCredential. U kunt uw toepassing ook configureren voor het gebruik van een service-principal in plaats van de AzureDeveloperCliCredential.