Erőforrások tesztelése az üzembe helyezés után
A Bicep-telepítés ellenőrzésével és előzetes verziójának megtekintésével magabiztosan üzembe helyezheti a Bicep-fájlokat. De az üzembe helyezés nem az egész történet. Az üzembe helyezés befejezése után azt is érdemes ellenőrizni, hogy az üzembe helyezés a vártnak megfelelően történt-e.
Ebben a leckében megismerheti azokat a teszteket, amelyeket az üzembe helyezés befejezése után futtathat. Megismerheti az üzembe helyezés visszaállítását is, ha a dolgok nem úgy alakulnak, ahogy várta.
Füsttesztek és negatív tesztek futtatása
Amikor erőforrásokat definiál egy Bicep-fájlban, a cél nem csak az Erőforrások létrehozása az Azure-ban. A szervezet igényeinek megfelelő értékeket kell szolgáltatnia a szervezetnek. A Bicep-fájlok ellenőrzésekor és előnézetében magabiztosan ellenőrizheti, hogy az erőforrás-definíciók érvényesek-e. De nem feltétlenül tudja, hogy az erőforrások valóban azt teszik, amit szeretne.
Tegyük fel például, hogy egy új Azure SQL logikai kiszolgálót helyez üzembe egy Bicep üzembehelyezési munkafolyamat használatával. A kiszolgáló Bicep-definíciója érvényes, ezért megfelel a linter és az elővizsgálati ellenőrzési feladatoknak. A what-if parancs azt mutatja, hogy létrejön egy kiszolgáló, ami a várt. Az üzembe helyezés is sikeresen befejeződött. Az üzembe helyezési folyamat végén azonban előfordulhat, hogy még mindig nem rendelkezik használatra kész működő adatbázis-kiszolgálóval. Ennek okai a következők lehetnek:
- Nem úgy konfigurálta a tűzfalszabályokat, hogy a hálózati forgalom elérhesse a kiszolgálót.
- Engedélyezte a Microsoft Entra-hitelesítést a kiszolgálón, ha nem kellett volna, vagy fordítva.
Még ha csak alapszintű Bicep-fájlokat is üzembe helyez, érdemes megfontolni, hogyan ellenőrizheti, hogy a telepített erőforrások valóban működnek-e, és megfelelnek-e a követelményeknek. Az alábbi példákból megtudhatja, hogyan alkalmazhatja ezt az elvet:
- Webhely üzembe helyezésekor próbálja meg elérni a webalkalmazást a munkafolyamatból. Ellenőrizze, hogy a munkafolyamat sikeresen csatlakozik-e a webhelyhez, és megkapja-e az érvényes válaszkódot.
- Tartalomkézbesítési hálózat (CDN) üzembe helyezésekor próbáljon meg csatlakozni egy erőforráshoz a CDN-en keresztül. Ellenőrizze, hogy a munkafolyamat sikeresen csatlakozik-e a CDN-hez, és megkapja-e az érvényes válaszkódot.
Ezeket a teszteket néha infrastruktúra-füstteszteknek is nevezik. A füsttesztelés a tesztelés egy egyszerű formája, amely az üzembe helyezés során felmerülő főbb problémák feltárására szolgál.
Feljegyzés
Egyes Azure-erőforrásokat nem könnyű elérni a GitHub által üzemeltetett futóktól. Előfordulhat, hogy érdemes megfontolnia egy saját üzemeltetésű futó használatát a füsttesztelési feladatok futtatásához, ha privát hálózatokon keresztül kell hozzáférniük az erőforrásokhoz.
Emellett érdemes negatív teszteket végezni. A negatív tesztelés segít meggyőződni arról, hogy az erőforrások nem kívánnak viselkedést. Például egy virtuális gép üzembe helyezésekor célszerű az Azure Bastion használatával biztonságosan csatlakozni a virtuális géphez. Negatív tesztet is hozzáadhat a munkafolyamathoz, így ellenőrizheti, hogy nem tud-e közvetlenül csatlakozni egy virtuális géphez távoli asztali Csatlakozás ion vagy SSH használatával.
Fontos
Ezeknek a teszteknek a célja nem annak ellenőrzése, hogy a Bicep megfelelően telepítette-e az erőforrásokat. A Bicep használatával feltételezi, hogy az üzembe helyezi a Bicep-fájlokban megadott erőforrásokat. Ehelyett a cél annak ellenőrzése, hogy a megadott erőforrások megfelelnek-e a helyzetnek, és megfelelnek-e a követelményeknek.
Tesztek futtatása GitHub-munkafolyamatokból
A munkafolyamatban sokféleképpen futtathat teszteket. Ebben a modulban a Pestert használjuk, amely egy nyílt forráskódú eszköz, amely PowerShell-lel írt teszteket futtat. A Pester előre telepítve van a GitHub által üzemeltetett futókon. Nem kell semmi különlegeset tennie ahhoz, hogy szkriptlépésben használhassa.
Dönthet úgy, hogy egy másik tesztelési keretrendszert használ, vagy akár teszteszköz nélkül is futtatja a teszteket. Egy másik megfontolandó teszteszköz például az Azure-hoz készült PSRule, amely előre összeállított szabályokat és teszteket tartalmaz az Azure-hoz. Futtathat érvényesítést a sablonokon, és teszteket is futtathat az üzembe helyezett Azure-erőforrásokon. Az összegzésben hivatkozunk a PSRule-ra.
Ha egy munkafolyamatból futtat teszteket, a tesztelési hibáknak le kell állítaniuk a munkafolyamat folytatását. A következő gyakorlatban látni fogja, hogyan használhat munkafolyamatokat infrastruktúra-füsttesztekkel.
A teszteredmények a munkafolyamat-naplóba lesznek írva. A GitHub Marketplace nem Microsoft-műveleteket is tartalmaz, amelyek képesek a teszteredmények időbeli megjelenítésére és nyomon követésére.
Adatok továbbítása feladatok között
Ha a munkafolyamatot több feladatra osztja, mindegyik saját felelősségi körébe tartozik, néha adatokat kell átadnia ezek között a feladatok között. Előfordulhat például, hogy egy feladat létrehoz egy Azure-erőforrást, amellyel egy másik feladatnak dolgoznia kell. Az adatok átadásához a második feladatnak ismernie kell a létrehozott erőforrás nevét. A füsttesztelési feladatnak például hozzá kell férnie az üzembe helyezési feladat által üzembe helyezett erőforrásokhoz.
A Bicep-fájl üzembe helyezi az erőforrásokat, így hozzáférhet az erőforrás tulajdonságaihoz, és üzembe helyezési kimenetként közzéteheti őket. Amikor futtatja a Bicep-üzembe helyezést a arm-deploy műveleten keresztül, ez a művelet ezeket a Bicep-telepítési kimeneteket a lépéskimeneteiben tárolja. Ezután a műveletet tartalmazó feladat mostantól közzéteheti ezeket a arm-deploy lépéskimeneteket feladatkimenetként. A feladat a lépés tulajdonságára id hivatkozik, amelyet a következőre deployállítottunk be:
deploy:
runs-on: ubuntu-latest
environment: Website
needs: preview
outputs:
appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy website
with:
deploymentName: ${{ github.run_number }}
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: ./deploy/main.bicep
parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
A feladat kimenetét bármely későbbi feladatban elérheti, feltéve, hogy az a kimenetet előállító feladattól függ:
smoke-test:
runs-on: ubuntu-latest
needs: deploy
steps:
- uses: actions/checkout@v3
- run: |
$container = New-PesterContainer `
-Path 'deploy/Website.Tests.ps1' `
-Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
Invoke-Pester `
-Container $container `
-CI
name: Run smoke tests
shell: pwsh
A munkafolyamat-szkriptek kimeneteit speciális szintaxissal is átadhatja. Az összegzésben további információkra hivatkozunk.
Egyéb teszttípusok
A funkcionális teszteket és az integrációs teszteket gyakran használják annak ellenőrzésére, hogy az üzembe helyezett erőforrások a várt módon működnek-e. Előfordulhat például, hogy egy integrációs teszt csatlakozik a webhelyhez, és elküld egy teszttranzakciót, majd várja meg, hogy a tranzakció sikeresen befejeződjön. Az integrációs tesztek használatával tesztelheti a csapat által készített megoldást, valamint a futó infrastruktúrát. Egy későbbi modulban látni fogja, hogyan vehetők fel ezek a tesztek a munkafolyamatba.
Más típusú teszteket is futtathat az üzembehelyezési munkafolyamatokból, beleértve a teljesítményteszteket és a biztonsági behatolási teszteket. Ezek a tesztek nem tartoznak a modul hatókörébe, de értéket adhatnak egy automatizált üzembehelyezési folyamathoz.
Visszatekerés vagy előregördítés
Tegyük fel, hogy a munkafolyamat sikeresen üzembe helyezi az erőforrásokat, de a tesztek sikertelenek. Akkor mit kell tennie?
A modul korábbi szakaszában megtanulta, hogy a GitHub Actions lehetővé teszi olyan visszaállítási feladatok létrehozását, amelyek egy korábbi feladat meghiúsulásakor futnak. Ezzel a módszerrel visszaállítási feladatot hozhat létre, amikor a tesztfeladat váratlan eredményt jelez. Manuálisan is visszaállíthatja a módosításokat, vagy újrafuttathatja a teljes munkafolyamatot, ha úgy véli, hogy a hiba egy már megoldott ideiglenes probléma miatt történt.
Feljegyzés
Amikor elküld egy üzembe helyezést az Azure Resource Managernek, kérheti, hogy a Resource Manager automatikusan futtassa újra a legutóbbi sikeres üzembe helyezést, ha az meghiúsul. Ehhez használja a --rollback-on-error paramétert, amikor az üzembe helyezést az Azure CLI az deployment group create paranccsal küldi el.
Hozzáadhat például egy visszaállítási feladatot a munkafolyamathoz. A visszaállítási feladat akkor fut, ha a füsttesztelési feladat meghiúsul:
rollback:
runs-on: ubuntu-latest
needs: smoke-test
if: ${{ always() && needs.smoke-test.result == 'failure' }}
steps:
- run: |
echo "Performing rollback steps..."
A feladat a füsttesztelési feladattól függ. Csak akkor fut, ha a füstteszt meghiúsul. Alapértelmezés szerint a GitHub Actions leállítja a munkafolyamatot, amikor egy korábbi feladat meghiúsul. A if feltétel tartalmaz egy always() ellenőrzést a viselkedés felülbírálásához. always() A kifejezés nélkül a visszaállítási feladat kimarad, ha egy korábbi feladat meghiúsul.
A visszaállítási feladat végrehajtásának lépéseit gyakran nehéz elvégezni. A Bicep-telepítések általában összetettek, és nem könnyű a módosítások visszaállítása. Különösen nehéz visszatérni, ha az üzembe helyezés más összetevőket is tartalmaz.
Tegyük fel például, hogy a munkafolyamat üzembe helyez egy Bicep-fájlt, amely meghatároz egy Azure SQL-adatbázist, majd hozzáad néhány adatot az adatbázishoz. Az üzembe helyezés visszaállításakor törölni kell az adatokat? Az adatbázist is el kell távolítani? Nehéz megjósolni, hogy minden hiba és minden visszaállítás milyen hatással lehet a futó környezetre.
Emiatt sok szervezet inkább előrehalad, ami azt jelenti, hogy gyorsan kijavítják a hiba okát, majd újra üzembe helyezik őket. Egy kiváló minőségű automatizált üzembe helyezési folyamat létrehozásával és a képzési tervek során elsajátított ajánlott eljárások követésével gyorsan kijavíthatja a problémákat, és újra üzembe helyezheti a Bicep-fájlokat a magas minőség fenntartása mellett.
Tipp.
A DevOps-gondolkodásmód egyik alapelve, hogy tanuljon a hibákból. Ha vissza kell állítania egy üzembe helyezést, alaposan gondolja át, hogy miért történt a hiba, és adjon hozzá automatizált tesztelést az üzembe helyezés megkezdése előtt, hogy észlelje ugyanazt a problémát, ha a jövőben bekövetkezik.