Megosztás a következőn keresztül:


Ajánlott üzembe helyezési eljárások

Feljegyzés

2024. június 1-től az újonnan létrehozott App Service-alkalmazások létrehozhatnak egy egyedi alapértelmezett gazdagépnevet, amely az elnevezési konvenciót <app-name>-<random-hash>.<region>.azurewebsites.nethasználja. A meglévő alkalmazásnevek változatlanok maradnak. Példa:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

További információ: Az App Service-erőforrás egyedi alapértelmezett gazdagépneve.

Minden fejlesztői csapat egyedi követelményekkel rendelkezik, amelyek megnehezíthetik a hatékony üzembe helyezési folyamat megvalósítását bármely felhőszolgáltatásban. Ez a cikk a Azure-alkalmazás szolgáltatásban való üzembe helyezés három fő összetevőjét mutatja be: üzembehelyezési források, buildelési folyamatok és üzembehelyezési mechanizmusok. Ez a cikk néhány ajánlott eljárást és tippeket is tartalmaz adott nyelvi veremekhez.

Üzembe helyezési összetevők

Ez a szakasz az App Service-ben való üzembe helyezés három fő összetevőjét ismerteti.

Központi telepítés forrása

Az üzembehelyezési forrás az alkalmazáskód helye. Éles alkalmazások esetében az üzembehelyezési forrás általában egy verzióvezérlő szoftver, például a GitHub, a Bitbucket vagy az Azure Repos által üzemeltetett adattár. Fejlesztési és tesztelési forgatókönyvek esetén az üzembehelyezési forrás lehet egy projekt a helyi gépen.

Buildelési folyamat

Miután kiválasztotta az üzembehelyezési forrást, a következő lépés egy buildelési folyamat kiválasztása. A buildelési folyamat beolvassa a forráskódot az üzembehelyezési forrásból, és több lépést is futtat az alkalmazás futtatható állapotba helyezéséhez.

A lépések közé tartozhat a kód összeállítása, a HTML és a JavaScript minifying, a futó tesztek és a csomagolási összetevők. A buildelési folyamat által futtatott parancsok a nyelvi veremtől függenek. Ezeket a műveleteket futtathatja egy buildkiszolgálón, például az Azure Pipelineson vagy helyileg.

Üzembe helyezési mechanizmus

Az üzembe helyezési mechanizmus az a művelet, amellyel a beépített alkalmazást a webalkalmazás /home/site/wwwroot könyvtárába helyezheti. A /wwwroot könyvtár a webalkalmazás összes példánya által megosztott csatlakoztatott tárolóhely. Amikor az üzembe helyezési mechanizmus ebbe a könyvtárba helyezi az alkalmazást, a példányok értesítést kapnak az új fájlok szinkronizálásáról.

Az App Service a következő üzembehelyezési mechanizmusokat támogatja:

  • Kudu-végpontok: A Kudu egy nyílt forráskódú fejlesztői hatékonyságnövelő eszköz, amely külön folyamatként fut a Windows App Service-ben. Második tárolóként fut a Linux App Service-ben. A Kudu kezeli a folyamatos üzembe helyezéseket, és HTTP-végpontokat biztosít az üzembe helyezéshez, például zipdeploy/.
  • FTP és WebDeploy: A webhely vagy a felhasználói hitelesítő adatok használatával ftp vagy WebDeploy használatával tölthet fel fájlokat. Ezek a mechanizmusok nem a Kudu-on mennek keresztül.

Az olyan üzembehelyezési eszközök, mint az Azure Pipelines, a Jenkins és a szerkesztő beépülő modul, ezen üzembe helyezési mechanizmusok egyikét használják.

Üzembehelyezési pontok használata

Amikor csak lehetséges, új éles build üzembe helyezésekor használjon üzembehelyezési pontokat. Standard App Service-csomaggal vagy jobb verzióval üzembe helyezheti az alkalmazást átmeneti környezetben, ellenőrizheti a módosításokat, és füstteszteket végezhet. Ha elkészült, cserélje le az előkészítési és éles pontokat. A felcserélési művelet felmelegíti a szükséges feldolgozópéldányokat, hogy megfeleljenek az éles méretnek, ami kiküszöböli az állásidőt.

Kód folyamatos üzembe helyezése

Ha a projektben vannak tesztelésre, minőségbiztosítási és előkészítési célokra kijelölt ágak, az egyes ágakat folyamatosan üzembe kell helyezni egy átmeneti ponton. Ezt a megközelítést Gitflow-kialakításnak nevezzük. Ez a kialakítás lehetővé teszi az érdekelt felek számára, hogy egyszerűen értékeljék és teszteljék az üzembe helyezett ágat.

A folyamatos üzembe helyezést soha nem szabad engedélyezni az éles ponthoz. Ehelyett az éles ágat (gyakran fő) egy nem termelési ponton kell üzembe helyezni. Ha készen áll az alapág felszabadítására, cserélje le az éles pontra. Az éles üzembe helyezés helyett az éles környezetbe való felcserélés megakadályozza az állásidőt, és lehetővé teszi a módosítások visszaállítását újracseréléssel.

A dev, az átmeneti és a fő ágak közötti folyamatot, valamint az üzembe helyezett tárolóhelyeket ábrázoló ábra.

Tárolók folyamatos üzembe helyezése

A Dockerből vagy más tárolóregisztrációs adatbázisokból származó egyéni tárolók esetében helyezze üzembe a lemezképet egy átmeneti tárolóhelyen, és váltsa fel éles környezetbe az állásidő megakadályozása érdekében. Az automatizálás összetettebb, mint a kód üzembe helyezése. Le kell küldenie a lemezképet egy tárolóregisztrációs adatbázisba, és frissítenie kell a képcímkét a webalkalmazásban.

Minden olyan ághoz, amelyet üzembe szeretne helyezni egy ponton, állítsa be az automatizálást, hogy ezeket a feladatokat az ág minden véglegesítésén elvégezze.

  1. Hozza létre és címkézze fel a képet. A buildelési folyamat részeként címkézze fel a képet a git véglegesítési azonosítójával, az időbélyeggel vagy más azonosítható információkkal. A legjobb, ha nem az alapértelmezett legújabb címkét használja. Ellenkező esetben nehéz visszakövetni a jelenleg üzembe helyezett kódot, ami megnehezíti a hibakeresést.
  2. Nyomja le a címkézett képet. A rendszerkép létrehozása és címkézése után a folyamat leküldi a lemezképet a tárolóregisztrációs adatbázisba. A következő lépésben az üzembehelyezési pont lekéri a címkézett lemezképet a tárolóregisztrációs adatbázisból.
  3. Frissítse az üzembehelyezési pontot az új rendszerképcímkével. A tulajdonság frissítésekor a webhely automatikusan újraindul, és lekéri az új tárolórendszerképet.

Az ábrán a webalkalmazásokat, a tárolóregisztrációs adatbázist és az adattárfiókokat ábrázoló ponthasználati vizualizáció látható.

Ez a cikk példákat tartalmaz a gyakori automatizálási keretrendszerekre.

Az Azure DevOps használata

Az App Service beépített folyamatos kézbesítést biztosít a tárolókhoz az Üzembe helyezési központban keresztül. Lépjen az alkalmazáshoz az Azure Portalon. Az Üzembe helyezés területen kattintson az Üzembehelyezési központ elemre. Kövesse az utasításokat az adattár és az ág kiválasztásához. Ez a módszer egy DevOps buildelési és kiadási folyamatot konfigurál a tároló automatikus összeállítására, címkézésére és üzembe helyezésére, amikor az új véglegesítéseket a rendszer leküldi a kiválasztott ágba.

A GitHub Actions használata

A tároló üzembe helyezését a GitHub Actions használatával is automatizálhatja. A munkafolyamat-fájl létrehozza és címkézi a tárolót a véglegesítési azonosítóval, leküldi egy tárolóregisztrációs adatbázisba, és frissíti a megadott webalkalmazást az új rendszerképcímkével.

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 }}'

Más automatizálási szolgáltatók használata

A korábban felsorolt lépések más automatizálási segédprogramokra, például a CircleCI-re vagy a Travis CI-re vonatkoznak. Az üzembehelyezési pontok új képcímkékkel való frissítéséhez azonban az Azure CLI-t kell használnia az utolsó lépésben. Az Azure CLI automatizálási szkriptben való használatához hozzon létre egy szolgáltatásnevet az alábbi paranccsal.

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

A szkriptben jelentkezzen be az login --service-principalaz egyszerű információk megadásával. Ezután az webapp config container set beállíthatja a tároló nevét, címkéjét, a beállításjegyzék URL-címét és a beállításjegyzék jelszavát. További információ: Hogyan jelentkezhet be az Azure CLI-be a Circle CI-n.

Nyelvspecifikus szempontok

Tartsa szem előtt a Következő szempontokat a Java, a Node és a .NET-implementációk esetében.

Java

Jar-alkalmazások üzembe helyezéséhez használja a Kudu zipdeploy API-t. A wardeploy használata WAR-alkalmazásokhoz. Ha Jenkinst használ, ezeket az API-kat közvetlenül az üzembe helyezési fázisban használhatja. További információ: Üzembe helyezés Azure-alkalmazás szolgáltatásban a Jenkins használatával.

Csomópont

Alapértelmezés szerint a Kudu futtatja a csomópontalkalmazás (npm install) buildelési lépéseit. Ha olyan buildelési szolgáltatást használ, mint az Azure DevOps, a Kudu-build szükségtelen. A Kudu-build letiltásához hozzon létre egy alkalmazásbeállítást, SCM_DO_BUILD_DURING_DEPLOYMENTamelynek értéke : false.

.NET

Alapértelmezés szerint a Kudu futtatja a .NET-alkalmazás (dotnet build) buildelési lépéseit. Ha olyan buildelési szolgáltatást használ, mint az Azure DevOps, a Kudu-build szükségtelen. A Kudu-build letiltásához hozzon létre egy alkalmazásbeállítást, SCM_DO_BUILD_DURING_DEPLOYMENTamelynek értéke : false.

Egyéb üzembe helyezési szempontok

Egyéb szempontok közé tartozik a helyi gyorsítótár és a magas processzor- vagy memóriahasználat.

Helyi gyorsítótár

Azure-alkalmazás szolgáltatástartalmak az Azure Storage-ban tárolódnak, és tartalommegosztásként tartósan kerülnek felszínre. Egyes alkalmazásoknak azonban csak nagy teljesítményű, írásvédett tartalomtárra van szükségük, amelyet magas rendelkezésre állással futtathatnak. Ezek az alkalmazások kihasználhatják a helyi gyorsítótár használatát. További információ: Azure-alkalmazás szolgáltatás helyi gyorsítótárának áttekintése.

Feljegyzés

A helyi gyorsítótár nem ajánlott tartalomkezelő webhelyekhez, például a WordPresshez.

Az állásidő elkerülése érdekében mindig használja a helyi gyorsítótárat üzembehelyezési pontok használatával. A funkciók együttes használatáról további információt az ajánlott eljárásokban talál.

Magas processzor- vagy memóriahasználat

Ha az App Service-csomag a rendelkezésre álló processzor vagy memória több mint 90%-át használja, a mögöttes virtuális gépnek problémát jelenthet az üzembe helyezés feldolgozása. Ebben az esetben ideiglenesen skálázza fel a példányok számát az üzembe helyezés végrehajtásához. Az üzembe helyezés befejezése után visszaadhatja a példányok számát az előző értékére.

További információkért látogasson el az App Service Diagnostics webhelyre, ahol megismerheti az erőforrásra vonatkozó ajánlott eljárásokat.

  1. Navigáljon a webalkalmazáshoz az Azure Portalon.

  2. Válassza a Problémák diagnosztizálása és megoldása lehetőséget a bal oldali navigációs sávon, amely megnyitja az App Service Diagnosticst.

  3. Válassza a Rendelkezésre állás és teljesítmény lehetőséget, vagy fedezze fel az egyéb lehetőségeket, például a magas cpu-elemzést.

    Tekintse meg az alkalmazás aktuális állapotát az ajánlott eljárások tekintetében.

Ezen a hivatkozáson közvetlenül megnyithatja az App Service Diagnosticst az erőforráshoz: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.