Sdílet prostřednictvím

Osvědčené postupy pro nasazení

  • Článek

Poznámka:

Od 1. června 2024 budou mít všechny nově vytvořené aplikace App Service možnost vygenerovat jedinečný výchozí název hostitele pomocí zásad <app-name>-<random-hash>.<region>.azurewebsites.netvytváření názvů . Stávající názvy aplikací zůstanou beze změny.

Příklad: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Další podrobnosti najdete v tématu Jedinečný výchozí název hostitele pro prostředek služby App Service.

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 služby 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í

Zdroj nasazení

Zdrojem nasazení je umístění kódu 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.

Kanál buildu

Jakmile se rozhodnete o zdroji nasazení, v dalším kroku zvolíte kanál buildu. Kanál buildu načte zdrojový kód ze zdroje nasazení a provede řadu kroků (například kompilaci kódu, minifikaci kódu 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 zásobníku jazyka. Tyto operace je možné spouštět na buildovém serveru, jako je Azure Pipelines, nebo se spouštět 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 opensourcový vývojářský nástroj pro produktivitu, který běží jako samostatný proces ve službě Windows App Service a jako druhý kontejner v Linux App Service. Kudu zpracovává průběžné nasazování a poskytuje koncové body HTTP pro nasazení, jako je 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í 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žijte sloty nasazení. Pokud používáte úroveň plánu služby App Service Standard nebo lépe, můžete aplikaci nasadit do přípravného prostředí, ověřit změny a provádět orientační testy. Až budete připraveni, můžete prohodit přípravné a produkční sloty. Operace prohození zahřeje potřebné instance pracovního procesu tak, aby odpovídaly vašemu produkčnímu škálování, čímž se eliminuje výpadek.

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

Pokud váš projekt určil větve 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. (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 vydat základní větev, prohodíte ji do produkčního slotu. Prohození do produkčního prostředí ( místo nasazení do produkčního prostředí) zabrání 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é se nasazují

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

Pro vlastní kontejnery z Dockeru nebo jiných registrů kontejnerů nasaďte image do přípravného slotu a prohoďte ji do produkčního prostředí, abyste zabránili výpadkům. Automatizace je složitější než nasazení kódu, protože 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 každé potvrzení do větve následujícím postupem.

  1. Sestavte a označte image. 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í značku "latest". Jinak je obtížné trasovat, jaký kód je aktuálně nasazený, což ztěžuje ladění.
  2. Nasdílí označený obrázek. Jakmile je image sestavená a označená, kanál odešle image 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ů

Pro běžné architektury automatizace jsou uvedené následující příklady.

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 a v části Nasazení vyberte Deployment Center. Podle pokynů vyberte úložiště a větev. Tím nakonfigurujete kanál buildu a verze DevOps, který automaticky sestaví, označí a nasadí kontejner, když se do vybrané větve nasdílí nová potvrzení.

Použití GitHub Actions

Nasazení kontejneru můžete také automatizovat pomocí GitHub Actions. Následující 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ů nasazení pomocí Azure CLI je však potřeba použít nové značky imagí v posledním kroku. Pokud chcete v 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-principala zadejte informace o instančním objektu. Pak 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.

Aspekty specifické pro jazyk

Java

K nasazení aplikací JAR a wardeploy/ pro aplikace WAR použijte zipdeploy Kudu/ API. 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ěť

Aplikace Azure Obsah služby je uložený ve službě Azure Storage a je vystavován trvalým způsobem jako sdílená složka obsahu. 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ěť. Místní mezipaměť se nedoporučuje pro weby pro správu obsahu, jako je WordPress.

Vždy používejte místní mezipaměť ve spojení s sloty nasazení, abyste zabránili výpadkům. 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 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 tomu dojde, dočasně vertikálně navyšte kapacitu počtu instancí, aby se nasazení provedlo. Po dokončení nasazení můžete počet instancí vrátit do předchozí hodnoty.

Další informace oosvědčených materiálech najdete v diagnostice služby App Service .

  • Přejděte na webovou aplikaci na webu Azure Portal.
  • V levém navigačním panelu vyberte Diagnostika diagnostiky služby App Service a vyřešte problémy .
  • Zvolte dlaždici domovské stránky Osvědčené postupy .
  • Vyberte osvědčené postupy pro dostupnost a výkon nebo osvědčené postupy pro optimální konfiguraci , abyste zobrazili 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.

Další materiály

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