Osvědčené postupy pro nasazení

Každý vývojový tým má jedinečné požadavky, které můžou ztížit implementaci efektivního kanálu nasazení v jakékoli cloudové službě. Tento článek představuje tři hlavní komponenty nasazení do Azure App Service: zdroje nasazení, kanály sestavení a mechanismy nasazení. Tento článek se věnuje také některým osvědčeným postupům a tipům pro konkrétní zásobníky jazyků.

Součásti nasazení

Tato část popisuje tři hlavní komponenty pro nasazení do služby App Service.

Zdroj nasazení

Zdroj nasazení je místo, kde se nachází kód vaší aplikace. Pro produkční aplikace je zdrojem nasazení obvykle úložiště hostované softwarem pro správu verzí, jako je GitHub, Bitbucket nebo Azure Repos. Ve scénářích vývoje a testování může být zdrojem nasazení projekt na místním počítači.

Sestavovací řetězec

Po rozhodnutí o zdroji nasazení je dalším krokem volba build pipeline. Sestavovací kanál načte zdrojový kód ze zdroje nasazení a spustí řadu kroků, aby připravil aplikaci do stavu, ve kterém ji lze spustit.

Kroky můžou zahrnovat kompilaci kódu, minifikaci HTML a JavaScriptu, spouštění testů a balení komponent. Konkrétní příkazy spouštěné kanálem buildu závisí na vašem zásobníku jazyka. Tyto operace můžete spustit na buildovém serveru, jako je Azure Pipelines, nebo místně.

Mechanismus nasazení

Mechanismus nasazení je akce použitá k vložení integrované aplikace do adresáře /home/site/wwwroot vaší webové aplikace. Adresář /wwwroot je připojené umístění úložiště sdílené všemi instancemi vaší webové aplikace. Když mechanismus nasazení umístí vaši aplikaci do tohoto adresáře, instance obdrží oznámení o synchronizaci nových souborů.

App Service podporuje následující mechanismy nasazení:

• Koncové body Kudu: Kudu je open-sourcový nástroj pro zvýšení produktivity vývojářů. Běží jako samostatný proces ve službě Windows App Service. Běží jako druhý kontejner ve službě Linux App Service. Kudu spravuje průběžné nasazování a poskytuje koncové body HTTP pro nasazení, například zipdeploy/.
• FTP a WebDeploy: Pomocí přihlašovacích údajů webu nebo uživatele můžete nahrát soubory přes FTP nebo WebDeploy. Tyto mechanismy neprocházejí přes Kudu.

Nástroje pro nasazení, jako jsou Azure Pipelines, Jenkins a moduly plug-in editoru, používají jeden z těchto mechanismů nasazení.

Použijte sloty nasazení

Kdykoli je to možné, použijte při nasazení nového produkčního sestavení sloty pro nasazení. Se standardním nebo vyšším plánem služby App Service můžete aplikaci nasadit do přípravného prostředí, ověřit své změny a provádět základní testy. Až budete připraveni, prohoďte přípravné a produkční prostředí. Operace prohození aktivuje potřebné instance pracovních jednotek tak, aby odpovídaly úrovni produkce, což eliminuje výpadky.

Průběžné nasazování kódu

Pokud má váš projekt větve určené pro testování, kontrolu kvality a přípravu, měly by se všechny tyto větve průběžně nasazovat do přípravného slotu. Tento přístup umožňuje zúčastněným stranám snadno posoudit a otestovat nasazenou větev. Informace o strategiích větvení najdete v tématu Vývoj na základě kmene nebo porovnání pracovních postupů Gitu.

Pro produkční slot by nikdy nemělo být povolené průběžné nasazování. Místo toho by se vaše produkční větev (často hlavní) měla nasadit do neprodukčního slotu. Až budete připraveni vydat základní větev, prohoďte ji do produkčního slotu. Přepnutí do produkčního prostředí místo nasazení do produkčního prostředí zabraňuje výpadkům a umožňuje vrátit změny zpět dalším přepnutím.

Průběžné nasazování kontejnerů

Pro vlastní kontejnery z Dockeru nebo jiných registrů kontejnerů nasaďte image do testovacího slotu a přeneste ji do produkčního prostředí, abyste zabránili výpadkům. Automatizace je složitější než nasazení kódu. Image musíte odeslat do registru kontejneru a aktualizovat značku image ve webové aplikaci.

Pro každou větev, kterou chcete nasadit do slotu, nastavte automatizaci pro provádění těchto úkolů při každém potvrzení do větve.

1. Sestavte a označte obraz. V rámci kanálu buildu označte image pomocí ID potvrzení Gitu, časového razítka nebo jiných identifikovatelných informací. Nejlepší je nepoužívat výchozí nejnovější značku. Jinak je obtížné zjistit, který kód je aktuálně nasazen, což ztěžuje ladění.
2. Nahrajte označený obrázek. Po sestavení a označení obrazu automatizační skript nahraje obraz do registru kontejneru. V dalším kroku nasazovací slot stáhne opatřený štítkem obraz z registru kontejneru.
3. Aktualizujte slot nasazení pomocí nového štítku obrázku. Při aktualizaci této vlastnosti se lokalita automaticky restartuje a načítá novou image kontejneru.

Tento článek obsahuje příklady běžných architektur automatizace.

Použití Azure DevOps

Služba App Service má integrované průběžné doručování kontejnerů prostřednictvím Centra nasazení. Přejděte do aplikace na webu Azure Portal. V části Nasazení vyberte Deployment Center. Podle pokynů vyberte úložiště a větev. Tento přístup konfiguruje kanál sestavení a vydávání v rámci DevOps tak, aby automaticky sestavoval, označoval a nasazoval kontejner, když jsou nové commity pushovány do vybrané větve.

Použijte GitHub Actions

Nasazení kontejneru můžete také automatizovat pomocí GitHub Actions. Soubor pracovního postupu sestaví a označí kontejner pomocí ID potvrzení, odešle ho do registru kontejneru a aktualizuje zadanou webovou aplikaci novou značkou image.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Použití jiných poskytovatelů automatizace

Výše uvedené kroky platí pro další nástroje automatizace, jako je CircleCI nebo Travis CI. K aktualizaci slotů pro nasazení v posledním kroku je však potřeba použít Azure CLI s novými značkami obrázku. Pokud chcete v automatizačním skriptu použít Azure CLI, vygenerujte Service Principal pomocí následujícího příkazu.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

Ve skriptu se přihlaste pomocí az login --service-principal a poskytněte základní informace. Pak můžete použít az webapp config container set k nastavení názvu kontejneru, značky, adresy URL registru a hesla registru. Další informace najdete v tématu Jak se přihlásit k Azure CLI v Circle CI.

Aspekty specifické pro jazyk

Mějte na paměti následující aspekty implementace Java, Node a .NET.

Java

K nasazení aplikací JAR použijte rozhraní API zipdeploy Kudu. Používejte wardeploy pro aplikace WAR. Pokud používáte Jenkinse, můžete tato rozhraní API použít přímo ve fázi nasazení. Další informace najdete v tématu Nasazení do služby Aplikace Azure Pomocí Jenkinse.

Node

Ve výchozím nastavení Kudu spustí kroky sestavení pro vaši aplikaci Node (npm install). Pokud používáte službu sestavení, jako je Azure DevOps, je sestavení Kudu zbytečné. Pokud chcete zakázat sestavení Kudu, vytvořte nové nastavení aplikace SCM_DO_BUILD_DURING_DEPLOYMENT s hodnotou false.

platforma .NET

Ve výchozím nastavení Kudu spustí kroky sestavení pro vaši aplikaci .NET (dotnet build). Pokud používáte službu sestavení, jako je Azure DevOps, je sestavení Kudu zbytečné. Pokud chcete zakázat sestavení Kudu, vytvořte nové nastavení aplikace SCM_DO_BUILD_DURING_DEPLOYMENT s hodnotou false.

Další aspekty nasazení

Mezi další aspekty patří místní mezipaměť a vysoké využití procesoru nebo paměti.

Místní mezipaměť

Obsah služby Azure App Service je uložený ve službě Azure Storage a je vystavován trvale jako sdílený obsah. Některé aplikace ale potřebují vysoce výkonné úložiště obsahu jen pro čtení, které můžou běžet s vysokou dostupností. Tyto aplikace můžou využívat místní mezipaměť. Další informace najdete v tématu Přehled místní mezipaměti služby Azure App Service.

Poznámka:

Místní mezipaměť se nedoporučuje pro weby pro správu obsahu, jako je WordPress.

Abyste zabránili výpadkům, vždy používejte místní mezipaměť s nasazovacími sloty. Informace o společném používání těchto funkcí najdete v tématu Osvědčené postupy.

Vysoké využití procesoru nebo paměti

Pokud váš plán služby App Service využívá více než 90 % dostupného procesoru nebo paměti, může mít základní virtuální počítač potíže se zpracováním vašeho nasazení. Pokud k této situaci dojde, dočasně zvyšte počet instancí, aby se nasazení provedlo. Po dokončení nasazení můžete počet instancí vrátit do předchozí hodnoty.

Další informace najdete v diagnostice služby App Service a zjistěte vhodné osvědčené postupy specifické pro váš prostředek.

1. Přejděte na webovou aplikaci na webu Azure Portal.

2. V levém navigačním panelu vyberte Diagnostikovat a řešit problémy, což otevře diagnostiku služby App Service.

3. Zvolte Dostupnost a výkon nebo prozkoumejte další možnosti, jako analýza vysokého využití procesoru.

   Podívejte se na aktuální stav vaší aplikace, pokud jde o tyto osvědčené postupy.

Pomocí tohoto odkazu můžete také přímo otevřít diagnostiku služby App Service pro váš prostředek: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Související obsah

• Referenční informace k proměnným prostředí a nastavením aplikace