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


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

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 a legjobb gyakorlatokat és tippeket is tartalmaz konkrét programozási nyelvek környezetére.

Üzembe helyezési összetevők

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

Telepítési forrás

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 kicsinyítése, a tesztek futtatása és az összetevők csomagolása. A build folyamat által futtatott parancsok a nyelvi környezettő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 telepítési foglalatokat. 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 készen áll, cserélje ki az előkészítési és éles helyeket. A felcserélési művelet felkészíti a szükséges munkavállalói példányokat, hogy megfeleljenek a termelési 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. Ez a megközelítés lehetővé teszi az érdekelt felek számára, hogy egyszerűen értékeljék és teszteljék az üzembe helyezett ágat. Az elágaztatási stratégiákról további információt a Trunk Based Development vagy a Git-munkafolyamatok összehasonlítása című témakörben talál.

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

Diagram, amely egy példát mutat be arra, hogyan helyezhetik üzembe az ágakat a pontokon, a véglegesítések az ágakról a megfelelő tárolóhelyekre haladnak, és a fő pont felcserélhető az éles környezetbe.

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 teszthelyen, és váltsa fel a production 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.

Az egyes ágakhoz, amelyeket egy résbe szeretne telepíteni, állítson be automatizálási folyamatot, hogy az ág minden elkövetett változásánál elvégezze ezeket a feladatokat.

  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 a telepítési hely lekéri a címkézett lemezképet a konténerregisztrációból.
  3. Frissítse a behelyezési helyet az új képcímkével. Amikor ez a tulajdonság frissül, a webhely automatikusan újraindul, és lekéri az új konténer ké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 saját alkalmazásához az Azure portálon. 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ás fő azonosítót 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 a az login --service-principal, a fő információkat megadva. 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.

Node

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. Azonban egyes alkalmazásoknak csak egy magas teljesítményű, írásvédett tartalomtárra van szükségük, amely magas rendelkezésre állással képes futni. 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.

Megjegyzé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 a telepítési helyekkel együtt. 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 a helyzetben ideiglenesen skálázza fel a példányok számát az üzembe helyezés végrehajtásához szükséges mennyiségre. 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.

Az alábbi hivatkozás használatával közvetlenül megnyithatja az erőforráshoz tartozó App Service Diagnosztikát: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.