Instellen van voortdurende implementatie naar Azure App Service

Notitie

Vanaf 1 juni 2024 kunnen nieuw gemaakte App Service-apps een unieke standaardhostnaam genereren die gebruikmaakt van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Zie het blogbericht over het maken van een web-app met een unieke standaardhostnaamvoor meer informatie.

Je kunt continue implementatie configureren vanuit GitHub-, Bitbucket- en Azure-repositories door gebruik te maken van Azure App Service, die de nieuwste updates binnenhaalt. Deze gids biedt je alles wat je nodig hebt om te beginnen.

Uw opslagplaats voorbereiden

"Om geautomatiseerde builds van de App Service-buildserver te verkrijgen, moet je ervoor zorgen dat de hoofdmap van je repository de juiste bestanden in je project bevat."

Looptijd	Root directory files
ASP.NET (alleen Windows)	*.sln, *.csproj, or default.aspx.
ASP.NET Core	*.sln or *.csproj.
PHP	index.php.
Ruby (alleen Linux)	Gemfile.
Node.js	server.js, app.js, or package.json with a start script.
Python	*.py, requirements.txt, or runtime.txt.
HTML	default.htm, default.html, default.asp, index.htm, index.html, or iisstart.htm.
Webjobs	<job_name>/run.<extension> onder App_Data/jobs/continuous voor continue webtaken of App_Data/jobs/triggered voor geactiveerde webtaken. Zie Kudu WebJobs documentation (Documentatie over Kudu WebJobs) voor meer informatie.
Functies	See Continuous deployment for Azure Functions.

Om uw implementatie aan te passen, voegt u een .deployment bestand toe in de hoofdmap van de repository. Voor meer informatie, zie Customize deployments (Implementaties aanpassen) en Custom deployment script (Aangepast implementatiescript).

Hint

Visual Studio kan een repository voor u maken. With this method, your project is immediately ready for deployment via Git.

De implementatiebron configureren

1. In de Azure-portal ga je naar het beheerpaneel voor je App Service-app.

2. Selecteer in het linker menu Deployment Center. Selecteer vervolgens Instellingen.

3. In de Source-box, selecteer een van de opties voor Continue Integratie en Levering (CI/CD).

   

Om door te gaan, selecteer de tabblad die overeenkomt met uw buildprovider.

GitHub

1. GitHub Actions is de standaard buildprovider. Als u de provider wilt wijzigen, selecteert u >>

2. Als u voor het eerst vanuit GitHub implementeert, selecteert u Autoriseren en volgt u de autorisatieprompts. Om te implementeren vanuit een andere gebruiker zijn repository, selecteer Account wijzigen.

3. After you authorize your Azure account with GitHub, select the appropriate Organization, Repository, and Branch.

   Als je geen organisatie of repository kunt vinden, moet je mogelijk meer toestemmingen inschakelen op GitHub. Zie Toegang tot de opslagplaatsen van uw organisatie beheren voor meer informatie.

4. Selecteer onder Verificatietype de door de gebruiker toegewezen identiteit voor betere beveiliging. For more information, see Frequently asked questions.

   Notitie

   Als uw Azure-account over de vereiste machtigingen beschikt voor de door de gebruiker toegewezen identiteit, maakt Azure een door de gebruiker toegewezen beheerde identiteit voor u. Als je niet over de vereiste machtigingen beschikt, werk dan samen met je Azure-beheerder om een identiteit met de vereiste rol op je app aan te maken, en selecteer deze vervolgens in de vervolgkeuzelijst.

5. (Optioneel) Als u het bestand wilt zien voordat u de wijzigingen opslaat, selecteert u Voorbeeldbestand. App Service selecteert een workflowtemplate op basis van de taalstackinstelling van uw app en voegt deze toe aan uw geselecteerde GitHub-repository.

6. Selecteer Opslaan.

   Nieuwe commits in de geselecteerde repository en branch worden nu continu gedeployd naar je App Service-app. U kunt de doorvoeringen en implementaties bijhouden op het tabblad Logboeken .

Bitbucket

De Bitbucket-integratie gebruikt de App Service build-service voor geautomatiseerde builds.

1. Als u voor het eerst vanuit Bitbucket implementeert, selecteert u Autoriseren en volgt u de autorisatieprompts. Als je wilt implementeren vanuit de repository van een andere gebruiker, selecteer Account wijzigen.

2. Selecteer het Bitbucket team, de repository en de branch die je continu wilt inzetten.

3. Selecteer Opslaan.

   New commits in the selected repository and branch now deploy continuously into your App Service app. U kunt de doorvoeringen en implementaties bijhouden op het tabblad Logboeken .

Lokale Git

Zie lokale Git-implementatie voor Azure-app Service.

Azure Repos

1. De buildservice in App Service is de standaard build provider.

   Notitie

   Als u Azure Pipelines wilt gebruiken als de buildprovider voor uw App Service-app, configureert u deze rechtstreeks vanuit Azure Pipelines. Configureer deze niet in App Service. Met de optie Azure Pipelines wordt u in de juiste richting verwezen.

2. Selecteer de Azure DevOps-organisatie, het project, de opslagplaats en de vertakking die u continu wilt implementeren.

   Als uw DevOps-organisatie niet wordt vermeld, is deze niet gekoppeld aan uw Azure-abonnement. Zie Een Azure-serviceverbinding maken voor meer informatie.

Andere opslagplaatsen

Voor Windows-apps kunt u handmatig continue implementatie configureren vanuit een Git- of Mercurial-opslagplaats in de cloud die niet rechtstreeks door de portal wordt ondersteund, zoals GitLab. U doet dit door Externe Git te selecteren in de vervolgkeuzelijst Bron. Zie Continue implementatie instellen met behulp van handmatige stappen voor meer informatie.

Continue implementatie uitschakelen

1. Ga in Azure Portal naar de beheerpagina voor uw App Service-app.

2. In het linkermenu selecteert u Deployment Center. Then select Settings>Disconnect.

   

3. Het GitHub Actions workflowbestand wordt standaard in je repository bewaard, maar het blijft de deployment naar je app activeren. Als u het bestand uit uw opslagplaats wilt verwijderen, selecteert u Werkstroombestand verwijderen.

4. Select OK.

Wat zijn de buildproviders?

Afhankelijk van uw implementatiebron in Deployment Center, ziet u mogelijk enkele opties voor buildproviders. Bouwproviders helpen je een oplossing voor continue integratie en continue levering (CI/CD) te bouwen met Azure App Service door het automatiseren van de bouw, test en implementatie.

Je bent niet beperkt tot de buildprovider-opties die te vinden zijn in het Deployment Center, maar door gebruik te maken van App Service, kun je ze snel instellen en krijg je een geïntegreerde ervaring met het vastleggen van implementatielogs.

GitHub Actions

De Build-provider van GitHub Actions is alleen beschikbaar voor gitHub-implementatie. Wanneer geconfigureerd vanuit het implementatiecentrum van de app, stelt de buildprovider CI/CD in door een GitHub Actions-workflowbestand in uw GitHub-repository te plaatsen, dat verantwoordelijk is voor het afhandelen van bouw- en implementatietaken naar App Service.

Voor basisverificatie voegt het het publicatieprofiel voor uw app toe als een GitHub-geheim. In het werkstroombestand wordt dit geheim gebruikt om te verifiëren met App Service. Zie Wat doet de optie voor door de gebruiker toegewezen identiteit in GitHub Actions?

Het verzamelt informatie uit de workflow uitvoeringslogboeken en toont deze op het Logboek-tabblad in het Deployment Center.

U kunt de GitHub Actions buildprovider op de volgende manieren aanpassen:

• You can customize the workflow file after it generates in your GitHub repository. Zie Werkstroomsyntaxis voor GitHub Actions voor meer informatie. Just make sure that the workflow deploys to App Service with the azure/webapps-deploy action.
• Als de geselecteerde branch beschermd is, kunt u het workflowbestand nog steeds bekijken zonder de configuratie op te slaan en het vervolgens handmatig aan uw repository toevoegen. Deze methode biedt u geen logboekintegratie met Azure Portal.
• In plaats van basisverificatie of een door de gebruiker toegewezen identiteit te gebruiken, kunt u ook implementeren met behulp van een service-principal in Microsoft Entra-id. Deze methode kan niet in het portaal worden geconfigureerd.

Opbouwdienst voor appservice

Notitie

De App Service-bouwservice vereist dat SCM basic authentication is ingeschakeld om de webhook te laten werken. Voor meer informatie, zie Deploy without basic authentication.

The App Service build service is the deployment and build engine native to App Service. Wanneer deze optie is geselecteerd, voegt App Service een webhook toe aan de opslagplaats die u hebt geautoriseerd. Elke code die naar de opslagplaats wordt gepusht, activeert de webhook en App Service haalt de wijzigingen in de opslagplaats op en voert eventuele implementatietaken uit. Zie Implementeren vanuit GitHub (Kudu) voor meer informatie.

Weg:

• Veelvoorkomende problemen met continue implementatie onderzoeken
• Project Kudu

Azure Pipelines

Azure Pipelines maakt deel uit van Azure DevOps. U kunt een pijplijn configureren voor het bouwen, testen en implementeren van uw app in App Service vanuit elke ondersteunde bronopslagplaats.

Om Azure Pipelines als de build-provider te gebruiken, configureer deze dan niet in App Service. Go to Azure DevOps directly. In Deployment Center, the Azure Pipelines option just points you in the right direction.

Zie Implementeren in App Service met behulp van Azure Pipelines voor meer informatie.

Wat gebeurt er met mijn app tijdens de implementatie?

Wanneer je officieel ondersteunde implementatiemethoden gebruikt, worden er wijzigingen aangebracht in de bestanden in de /home/site/wwwroot map van je app. Deze bestanden worden gebruikt om uw app uit te voeren. The deployment can fail because of locked files. De app kan zich ook onvoorspelbaar gedragen tijdens de implementatie, omdat de bestanden niet allemaal tegelijk worden bijgewerkt. Dit gedrag is ongewenst voor een klantgerichte app.

Er zijn een paar manieren om deze problemen te vermijden:

• Voer uw app rechtstreeks uit vanuit het ZIP-pakket, zonder deze uit te pakken.
• Stop uw app of schakel de offline modus in tijdens de implementatie. Zie Omgaan met vergrendelde bestanden tijdens de implementatie voor meer informatie.
• Deploy to a staging slot with auto swap turned on.

Veelgestelde vragen

• Werkt de GitHub Actions-buildprovider met basisverificatie als basisverificatie is uitgeschakeld?
• Wat doet de door de gebruiker toegewezen identiteitsoptie voor GitHub Actions?
• Waarom zie ik de foutmelding "Deze identiteit heeft geen schrijfbevoegdheden voor deze app." Selecteer een andere identiteit of werk samen met uw beheerder om de rol Inzender voor de website aan uw identiteit in deze app te verlenen"?
• Why do I see the error "This identity does not have write permissions on this app. Selecteer een andere identiteit of werk samen met uw beheerder om de rol Inzender voor de website aan uw identiteit in deze app te verlenen"?

Werkt de GitHub Actions-buildprovider met basisverificatie als basisverificatie is uitgeschakeld?

Nee Gebruik GitHub Actions met de door de gebruiker toegewezen identiteitsoptie .

Voor meer informatie, zie Implementeren zonder basisverificatie.

Wat doet de door de gebruiker toegewezen identiteitsoptie voor GitHub Actions?

Wanneer u door de gebruiker toegewezen identiteit selecteert onder de bron GitHub Actions, configureert App Service alle noodzakelijke resources in Azure en GitHub. App Service stelt de aanbevolen Microsoft OpenID Connect-authenticatie met GitHub Actions in staat.

App Service voert de volgende bewerkingen uit:

• Hiermee maakt u een federatieve referentie tussen een door de gebruiker toegewezen beheerde identiteit in Azure en uw geselecteerde opslagplaats en vertakking in GitHub.
• Creates the secrets AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID from the federated credential in your selected GitHub repository.
• Hiermee wijst u de identiteit toe aan uw app.

In een GitHub Actions-werkstroom in je GitHub-repository kun je vervolgens de Azure/login-actie gebruiken om je aan te melden bij je app met OpenID Connect. Zie Het werkstroombestand toevoegen aan uw GitHub-opslagplaats voor voorbeelden.

Als uw Azure-account over de vereiste machtigingen beschikt, maakt App Service een door de gebruiker toegewezen beheerde identiteit en configureert het voor u. Deze identiteit wordt niet weergegeven op de pagina Identiteiten van uw app. Als uw Azure-account niet over de vereiste machtigingen beschikt, moet u een bestaande identiteit met de vereiste rol selecteren.

Why do I see the error "You do not have sufficient permissions on this app to assign role-based access to a managed identity and configure federated credentials"?

Het bericht geeft aan dat je Azure-account niet over de vereiste machtigingen beschikt om een door de gebruiker toegewezen beheerde identiteit voor GitHub-acties te creëren. De vereiste machtigingen (gericht op uw app) zijn:

• Microsoft.Authorization/roleAssignments/write
• Microsoft.ManagedIdentity/userAssignedIdentities/write

Standaard hebben de rollen User Access Administrator en Owner deze machtigingen al, maar de rol Contributor niet. Als je niet de vereiste machtigingen hebt, werk dan samen met je Azure-beheerder om een door de gebruiker toegewezen beheerde identiteit met de rol Websites Contributor te maken. In Deployment Center kunt u vervolgens de identiteit selecteren in de GitHub>Identity keuzelijst.

Voor meer informatie over het gebruik van alternatieve stappen, zie Deploy to App Service using GitHub Actions.

Why do I see the error "This identity does not have write permissions on this app. Selecteer een andere identiteit of werk samen met uw beheerder om de rol Inzender voor de website aan uw identiteit in deze app te verlenen"?

Het bericht geeft aan dat de geselecteerde door de gebruiker toegewezen beheerde identiteit niet over de vereiste rol beschikt om OpenID Connect in te schakelen tussen de GitHub-opslagplaats en de App Service-app. The identity must have one of the following roles on the app: Owner, Contributor, or Websites Contributor. De minst bevoorrechte rol die de identiteit nodig heeft, is Inzender voor websites.

Verwante inhoud

• Azure PowerShell gebruiken