Osvědčené postupy pro nasazení

  • Článek

Každý vývojový tým má jedinečné požadavky, které můžou znesnadnit implementaci efektivního kanálu nasazení v jakékoli cloudové službě. Tento článek představuje tři hlavní součásti nasazení do 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í jazykové zásobníky.

Komponenty nasazení

Zdroj nasazení

Zdroj nasazení je umístění kódu vaší aplikace. U produkčních aplikací je zdrojem nasazení obvykle úložiště hostované softwarem pro správu verzí, jako je GitHub, BitBucket nebo Azure Repos. Pro scénáře vývoje a testování může být zdrojem nasazení projekt na místním počítači. App Service jako zdroje nasazení podporuje také složky OneDrive a Dropbox. I když cloudové složky usnadňují zahájení práce s App Service, pro produkční aplikace na podnikové úrovni se tento zdroj obvykle nedoporučuje používat.

Kanál buildu

Jakmile se rozhodnete pro zdroj nasazení, vaším dalším krokem je volba kanálu buildu. Kanál buildu načte zdrojový kód ze zdroje nasazení a provede řadu kroků (například kompilace kódu, minifikace HTML a JavaScriptu, spouštění testů a balení komponent), aby se aplikace dostala do spustitelného stavu. Konkrétní příkazy spouštěné kanálem buildu závisí na vašem jazykovém zásobníku. Tyto operace se dají spouštět na buildovacím serveru, jako je Azure Pipelines, nebo místně.

Mechanismus nasazení

Mechanismus nasazení je akce, která slouží k umístění 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í 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 opensourcový vývojářský nástroj pro produktivitu, který běží jako samostatný proces ve Windows App Service a jako druhý kontejner v Linuxu App Service. Kudu zpracovává 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 protokol FTP nebo WebDeploy. Tyto mechanismy neprocházejí kudu.

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

Použití slotů nasazení

Kdykoli je to možné, při nasazování nového produkčního sestavení používejte sloty nasazení . Při použití úrovně Standard App Service Plan nebo vyšší můžete aplikaci nasadit do přípravného prostředí, ověřit změny a provést orientační testy. Až budete připraveni, můžete prohodit přípravný a produkční slot. Operace prohození zahřeje potřebné instance pracovních procesů tak, aby odpovídaly vašemu produkčnímu měřítku, a tím eliminuje prostoje.

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

Pokud má váš projekt určené větve pro testování, kontrolu kvality a přípravu, měla by se každá z těchto větví průběžně nasazovat do přípravného slotu. (To se označuje jako návrh Gitflow.) To umožňuje zúčastněným stranám snadno posoudit a otestovat nasazenou větev.

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 základní větev uvolnit, prohodíte ji do produkčního slotu. Prohození 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 opětovným prohozením.

Diagram znázorňující tok mezi větvemi Dev, Staging a Main a sloty, do které jsou nasazené

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

V případě vlastních kontejnerů z Dockeru nebo jiných registrů kontejnerů nasaďte image do přípravného slotu a prohoďte je do produkčního prostředí, aby se zabránilo výpadku. Automatizace je složitější než nasazení kódu, protože musíte odeslat image do registru kontejneru a aktualizovat značku image ve webové aplikaci.

Pro každou větev, kterou chcete nasadit do slotu, nastavte automatizaci, která při každém potvrzení do větve provede následující akce.

  1. Sestavte a označte image. Jako součást 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í značku "latest". Jinak je obtížné zjistit, jaký kód je aktuálně nasazený, což výrazně ztěžuje ladění.
  2. Nasdílení označené image Jakmile je image sestavená a označená, kanál ji odešle do našeho registru kontejneru. V dalším kroku slot nasazení stáhne označenou image z registru kontejneru.
  3. Aktualizujte slot nasazení pomocí nové značky image. Po aktualizaci této vlastnosti se lokalita automaticky restartuje a stáhne novou image kontejneru.

Vizuál využití slotů

Níže najdete příklady běžných architektur automatizace.

Použití Azure DevOps

App Service má integrované průběžné doručování kontejnerů prostřednictvím deployment center. V Azure Portal přejděte k aplikaci a v části Nasazení vyberte Deployment Center. Podle pokynů vyberte úložiště a větev. Tím nakonfigurujete kanál sestavení a verze DevOps tak, aby automaticky sestavoval, označoval a nasazoval kontejner při odeslání nových potvrzení do vybrané větve.

Použití GitHub Actions

Nasazení kontejneru můžete také automatizovat pomocí GitHub Actions. Následující soubor pracovního postupu sestaví kontejner a označí ho ID potvrzení, nasdílí ho do registru kontejneru a aktualizuje zadaný slot webu novou značkou image.

name: Build and deploy a container image to Azure Web Apps

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

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@main

    -name: Authenticate using a Service Principal
      uses: azure/actions/login@v1
      with:
        creds: ${{ secrets.AZURE_SP }}

    - uses: azure/container-actions/docker-login@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Build and push the image tagged with the git commit hash
      run: |
        docker build . -t contoso/demo:${{ github.sha }}
        docker push contoso/demo:${{ github.sha }}

    - name: Update image tag on the Azure Web App
      uses: azure/webapps-container-deploy@v1
      with:
        app-name: '<your-webapp-name>'
        slot-name: '<your-slot-name>'
        images: 'contoso/demo:${{ github.sha }}'

Použití jiných zprostředkovatelů automatizace

Výše uvedené kroky platí pro jiné nástroje pro automatizaci, jako je Například CircleCI nebo Travis CI. V posledním kroku ale musíte použít Azure CLI k aktualizaci slotů nasazení novými značkami image. Pokud chcete ve svém automatizačním skriptu použít Azure CLI, vygenerujte instanční objekt 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-principalpříkazu a zadejte informace o objektu zabezpečení. Potom můžete použít az webapp config container set k nastavení názvu kontejneru, značky, adresy URL registru a hesla registru. Níže najdete několik užitečných odkazů pro vytvoření procesu CI kontejneru.

Důležité informace o Language-Specific

Java

Pro nasazování aplikací JAR použijte zipdeploy / API Kudu a pro aplikace WAR použijte wardeploy/ . Pokud používáte Jenkinse, můžete tato rozhraní API použít přímo ve fázi nasazení. Další informace najdete v tomto článku.

Uzel

Ve výchozím nastavení Kudu provede 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 nastavení SCM_DO_BUILD_DURING_DEPLOYMENTaplikace s hodnotou false.

.NET

Ve výchozím nastavení Kudu provede 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 nastavení SCM_DO_BUILD_DURING_DEPLOYMENTaplikace s hodnotou false.

Další důležité informace o nasazení

Místní mezipaměť

Azure App Service obsah je uložený ve službě Azure Storage a trvale se zobrazí jako sdílená složka obsahu. Některé aplikace ale potřebují vysoce výkonné úložiště obsahu jen pro čtení, které je možné spouštět s vysokou dostupností. Tyto aplikace můžou těžit z používání místní mezipaměti. Místní mezipaměť se nedoporučuje pro weby pro správu obsahu, jako je WordPress.

Pokud chcete zabránit výpadkům, vždy používejte místní mezipaměť ve spojení se sloty nasazení . Informace o společném používání těchto funkcí najdete v této části .

Vysoké využití procesoru nebo paměti

Pokud váš plán 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í. V takovém případě dočasně vertikálně navyšte kapacitu počtu instancí, aby se nasazení provedlo. Po dokončení nasazení můžete vrátit počet instancí na předchozí hodnotu.

Další informace o osvědčených postupech najdete v tématu diagnostika App Service, kde najdete užitečné osvědčené postupy specifické pro váš prostředek.

  • V Azure Portal přejděte na webovou aplikaci.
  • V levém navigačním panelu vyberte Diagnostikovat a řešit problémy, která se otevře App Service Diagnostika.
  • Zvolte dlaždici domovské stránky Doporučené postupy .
  • Pokud chcete zobrazit aktuální stav aplikace s ohledem na tyto osvědčené postupy, vyberte Osvědčené postupy pro zajištění výkonu dostupnosti & nebo Osvědčené postupy pro optimální konfiguraci.

Pomocí tohoto odkazu můžete také přímo otevřít diagnostiku 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.

Další zdroje informací

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