A környezetek megértése

Befejeződött

Az üzembehelyezési munkafolyamatok lehetővé teszik az üzembe helyezési folyamat lépéseinek automatizálását. A lépéseket gyakran több külön környezetben kell futtatnia. A toy cégnél érdemes áttekinteni a kód módosításait, mielőtt üzembe helyezené a módosításokat az éles környezetben.

Ebben a leckében megtudhatja, hogyan segíthetnek a GitHub Actions környezetei a saját folyamatának támogatásában.

Miért van több környezete?

Az üzembehelyezési folyamatok módosításokat hajtanak végre az Azure-erőforrásokon, beleértve a használatban lévő erőforrásokat is. Az erőforrások módosítása bizonyos kockázattal jár, mert előfordulhat, hogy az üzembe helyezhető módosítások nem a várt módon működnek. Azt is felfedezheti, hogy a módosítások megtörik az aktuális beállítást.

A problémák kockázatának minimalizálása érdekében célszerű biztonságosan kipróbálni a módosításokat, mielőtt üzembe helyezené őket az éles környezetben. A kockázat minimalizálásához helyezze üzembe a módosításokat egy nem éles környezetben.

Számos szervezet több nem éles környezetet állít be, ahol fokozatosan telepítik a módosításokat, mielőtt éles környezetbe bocsátanák őket. Minden nem éles környezet egy adott célt szolgál, és gyakran rendelkezik meghatározott minőségi kapukkal, amelyeket teljesíteni kell a következő környezethez való továbblépéshez. Ha valami nem sikerül, például egy teszt meghiúsul, az üzembe helyezés leáll. Ahogy az üzembe helyezés halad az egyes környezetekben, növekszik a változások iránti bizalma.

Gyakori környezetek a következők:

  • Fejlesztés: A fejlesztői környezeteket általában a fejlesztők használják a módosítások kipróbálására és a munkájuk gyors iterálására.

    A fejlesztői környezetek gyakran minimális vezérlőkkel rendelkeznek, hogy a csapattagok egyszerűen kipróbálhassák ötleteiket. Fejlesztési környezettel tesztelhet egy adott konfigurációs beállítást egy erőforráson, vagy megnézheti, hogyan állíthat be egy új webhelyet egy háttéradatbázissal biztonságos módon. Előfordulhat, hogy a módosítások és próbaverziók nagy része nem halad előre az üzembe helyezési folyamat során, mert kiküszöböli a nem sikeres ötleteket.

    Egyes csapatokban akár külön fejlesztői környezetet is beállíthat az egyes csapattagok számára, hogy ne legyenek egymás módján, miközben új funkciókon dolgoznak.

    A fejlesztési környezeteket tesztkörnyezetnek is nevezik.

  • Teszt: A tesztkörnyezetek úgy lettek kialakítva, hogy manuális vagy automatizált teszteket futtasson a módosításokon.

    A tesztkörnyezetek egy folyamatos integrációs folyamat során használhatók. Miután üzembe helyez egy módosítást egy tesztkörnyezetben, automatizált tesztek futtathatók rajta. Ha az összes automatizált teszt sikeres, akkor a módosítás biztonságosan egyesíthető a projekt fő ágával. Az automatizált tesztek általában ellenőrzik a rendszer alapvető funkcióit, valamint az újonnan üzembe helyezett erőforrások szabályzatainak megsértését.

    Emellett dedikált tesztkörnyezeteket is létrehozhat bizonyos tesztelési típusokhoz, például a teljesítmény- és biztonsági teszteléshez.

  • Integráció: Az integrációs környezetek segíthetnek az integrációs pontok más rendszerekkel való tesztelésében.

    Egy integrációs környezetben a végpontok közötti tranzakciókat szimulálhatja. Ezek a tesztek gyakran automatikusan futnak, de számos szervezet manuális tesztelést is végez ezen a környezetben.

    Az integrációs környezeteket néha rendszerintegrációs tesztkörnyezetnek (SIT) is nevezik.

  • Felhasználói elfogadási teszt: A felhasználói elfogadási teszt (UAT) környezetét a manuális ellenőrzéshez használják, általában az üzleti szereplők és nem a fejlesztők. A manuális ellenőrzés során valaki végighalad a megoldáson, és ellenőrzi, hogy a várt módon viselkedik-e, és hogy megfelel-e a szükséges üzleti követelményeknek. Ez a személy ezután jóváhagyja a módosításokat, hogy az üzembe helyezés folytatható legyen.

  • Éles üzem előtti környezet: Az éles környezet gyakran az éles környezet tükörképe, ugyanazokkal az erőforrás-termékváltozatokkal és konfigurációval. A rendszer végső ellenőrzésként használja annak ellenőrzésére, hogy az éles üzembe helyezés hogyan fog viselkedni a módosítás alkalmazása során és után. Emellett annak ellenőrzésére is használható, hogy várható-e állásidő az éles üzembe helyezés során.

    Az éles üzem előtti környezeteket átmeneti környezeteknek is nevezik.

  • Éles környezet: Az éles környezet az, amelyet az alkalmazás végfelhasználói használnak. Az élő környezetét szeretné a lehető legnagyobb mértékben védeni, fenntartani és működtetni.

    Egyes szervezetekben előfordulhat, hogy több éles környezettel rendelkezik. Előfordulhat például, hogy különböző földrajzi régiókban vannak éles környezetek, vagy különböző ügyfélcsoportok kiszolgálására szolgálnak.

  • Bemutató: A csapat bemutató (demó) környezeteket is létrehozhat, hogy megjelenítse az alkalmazást a végfelhasználóknak, a betanításban való használatra vagy az értékesítési csapatok számára bizonyos képességeket jelenítsen meg a potenciális ügyfelek számára. Előfordulhat, hogy több bemutatókörnyezete is van, amelyek különböző célokat szolgálnak. A bemutató környezet gyakran az éles környezet karcsúsított replikája, hamis ügyféladatokkal.

Környezetek a szervezetben

Ezeknek a környezeteknek vannak változatai. Egyes szervezetek csak néhány környezetet használnak, mások pedig sok mást. A használt környezetek száma és típusa függ az üzembe helyezhető megoldástól, a megoldást létrehozó csapat méretétől és a számítási feladat fontosságától.

Előfordulhat, hogy egyetlen környezet több korábban felsorolt környezet szerepét is betölti. Máskor előfordulhat, hogy egy összetett munkafolyamat több környezetben, néhány párhuzamosan és néhány sorrendben van üzembe helyezve. Egyes szervezetek még akkor is automatikusan törölnek vagy bontanak ki környezeteket, ha már nincsenek használatban, majd újra üzembe helyezik őket, amikor a jövőben szükség lesz rájuk.

Bármit is választ a szervezet a környezetek listájaként, a cél az, hogy növelje a változásba vetett bizalmát az üzembe helyezési munkafolyamat során. Ha egy módosítás nem felel meg a minőségi követelményeknek, le szeretné állítani a módosítás üzembe helyezését a lánc későbbi környezeteiben.

A toy cégnél úgy dönt, hogy egy alapszintű környezettel kezdi a webhelyét. Az éles környezet mellett egy teszt nevű, nem éles környezetet is létre fog hozni:

Két környezetet bemutató diagram: tesztelés és éles környezet.

Frissíti a munkafolyamatot, hogy a Bicep-kódot üzembe helyezze a tesztkörnyezetben, és futtasson rajta néhány alapszintű tesztet. Ha ez az erőfeszítés sikeres, üzembe helyezheti az éles környezetben.

Munkafolyamat-környezetek

A GitHub Actions a környezet fogalmával is rendelkezik. Létrehoz egy GitHub Actions-környezetet, amely az Azure-ban található környezetet képviseli. Amikor egy YAML-fájlban definiálja a munkafolyamatot, a feladatokat egy adott környezethez csatolhatja. A környezetek használatával további funkciókat kaphat a munkafolyamatban.

Védelmi szabályok

A GitHub Actions-környezetek védelmi szabályai konfigurálhatók. A GitHub Actions minden alkalommal, amikor a környezetet a munkafolyamatban egy feladatban használják, a GitHub Actions ellenőrzi, hogy ezek a szabályok teljesülnek-e a feladat futtatása előtt.

Konfigurálhat például manuális felülvizsgálatokat az éles környezetben. Az éles üzembe helyezés megkezdése előtt a kijelölt felülvizsgáló értesítést kap. Ez a személy manuálisan ellenőrizheti, hogy a házirendek és eljárások teljesülnek-e az üzembe helyezés megkezdése előtt. Előfordulhat például, hogy a jóváhagyó ellenőrzi, hogy minden a várt módon működik-e az éles üzem előtti környezetben, mielőtt jóváhagyják az üzembe helyezést.

Emellett egy automatikus ellenőrzést is futtathat annak ellenőrzéséhez, hogy az ágról származik-e a módosítás. Ha a módosítás nem a fő ágon van, konfigurálhatja a GitHubot, hogy megakadályozza az éles környezetben való üzembe helyezést.

Titkos kódok

A GitHub Actions lehetővé teszi olyan titkos kódok tárolását, amelyek csak egy adott környezettel használhatók. A modul későbbi részében többet is megtudhat a titkos kódok kezeléséről.

Üzembe helyezési előzmények

A GitHub Actions nyomon követi az üzemelő példányok előzményeit egy környezetben. Ez az előzmények segítségével könnyen nyomon követheti, hogy mi történik a környezetben az idő múlásával. Lehetővé teszi az üzembe helyezés nyomon követését is egy véglegesítéshez az adattárban. Ez a funkció akkor lehet hasznos, ha egy üzembe helyezéssel kapcsolatos probléma merül fel, és azonosítania kell a problémát okozó módosítást.

Környezetek létrehozása

Általában a GitHub webes felületével hoz létre környezetet.

Ha a munkafolyamat nem létező környezetre hivatkozik, a GitHub Actions automatikusan létrehozza Önnek. Ez a funkció befolyásolhatja a GitHub-adattár biztonságát, mert az új környezetben nincsenek konfigurálva védelmi szabályok. A legjobb, ha saját maga hoz létre egy környezetet a GitHub webes felületén, hogy teljes mértékben szabályozhassa annak biztonságát.

Az üzembehelyezési munkafolyamat definíciójában a következő tulajdonság használatával hivatkozhat egy környezetre environment :

jobs:
  deploy:
    environment: Test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

Ebben a példában a nevesített deploy feladat a Test környezethez van csatolva.

Környezetek és kapcsolatok az Azure-hoz

Ha több környezetet használ, minden környezetet függetlensé kell tennie a többitől. A fejlesztői környezet webhelyének például nem szabad hozzáférnie egy adatbázishoz az éles környezetben.

Ugyanez az elv vonatkozik az üzembehelyezési munkafolyamatra is. Minden környezethez külön számítási feladat-identitásokat kell létrehoznia. Ezt a gyakorlatot követve egy újabb védelmi réteget ad hozzá annak érdekében, hogy a nem éles üzemelő példányok ne legyenek hatással az éles környezetre.

A számítási feladatok identitásait külön engedélyekkel kell hozzárendelni, hogy csak az adott környezet által használt előfizetésben és erőforráscsoportban legyenek üzembe helyezve:

Diagram, amely egy számítási feladat identitását és az Azure-erőforráscsoportot jeleníti meg nem éles környezetben, és egy másik készletet az éles környezetben.

Fontos

Használjon külön számítási feladat-identitást minden olyan környezethez, amelybe üzembe kíván helyezni. Adja meg a számítási feladat identitásának a környezetében üzembe helyezéshez szükséges minimális engedélyeket, és ne adjon meg másokat.

Érdemes különválasztani a környezeteket az Azure-ban. Legalább minden környezethez külön erőforráscsoportot kell létrehoznia. Sok esetben jobb, ha külön Azure-előfizetéseket hoz létre az egyes környezetekhez. Ezután több erőforráscsoportot is létrehozhat az egyes környezetek előfizetésében.

Azure-szerepkör-hozzárendelések alkalmazása, hogy a felhasználók és a számítási feladatok identitásai csak azokhoz a környezetekhez férhessenek hozzá, amelyekhez hozzáférésre van szükségük. Ügyeljen arra, hogy az éles környezethez való hozzáférést egy kis csoportra és a környezet üzembehelyezési számítási feladatainak identitására korlátozza.

Összevont hitelesítő adatok környezetekhez

Amikor a számítási feladatok identitása az üzembehelyezési munkafolyamatból csatlakozik az Azure-hoz, az összevont hitelesítő adatokkal biztonságosan hitelesítheti magát titkos kulcsok és kulcsok nélkül. A képzési terv korábbi moduljaiban az összevont hitelesítő adatok hozzáférést adtak az üzembehelyezési munkafolyamatokhoz, amikor azok a Git-adattár fő ágából lettek üzembe helyezve.

Amikor a munkafolyamat egy környezetében helyezi üzembe az üzembe helyezést, az adott környezethez tartozó összevont hitelesítőadat-hatókört kell használnia.

Ebben a modulban a munkafolyamat számos feladatot tartalmaz, amelyek közül sok az Azure-hoz csatlakozik és üzembe helyezhető. Egyes feladatok környezeteket használnak, mások pedig nem. Tehát két összevont hitelesítő adatot hoz létre minden számítási feladat-identitáshoz: egy hatókört a környezetre, egyet pedig a főágra .