Előző

Következő

Folyamatos integráció és üzembe helyezés

Befejeződött

A folyamatos integráció az a gyakorlat, hogy a kódbázison végrehajtott minden módosítást automatikusan és a lehető leghamarabb tesztel. Continuous delivery follows the testing that happens during continuous integration and pushes changes to a staging or production system.

In Azure Data Factory, continuous integration and delivery (CI/CD) means moving Data Factory pipelines from one environment (development, test, production) to another. Az Azure Data Factory Azure Resource Manager-sablonokkal tárolja a különböző Azure Data Factory-entitások (folyamatok, adathalmazok, adatfolyamok stb.) konfigurációját. Az adat-előállítók egy másik környezetbe való előléptetéséhez két javasolt módszer létezik:

• Automatizált üzembe helyezés a Data Factory És az Azure Pipelines integrációjával.
• Manuálisan töltsön fel egy Resource Manager-sablont a Data Factory UX-integrációjával az Azure Resource Managerrel.

Folyamatos integráció/Folyamatos kézbesítés életciklusa

Az alábbiakban az Azure Repos Gittel konfigurált Azure Data Factory CI/CD-életciklusának áttekintését tekintjük át.

1. Létrejön és konfigurál egy fejlesztői adat-előállítót az Azure Repos Gittel. Minden fejlesztőnek rendelkeznie kell engedéllyel Data Factory-erőforrások, például folyamatok és adathalmazok létrehozásához.

2. A fejlesztő létrehoz egy funkcióágat a módosításhoz. A legutóbbi módosításokkal hibakeresést hajtanak végre a folyamatfuttatásaikban.

3. Miután a fejlesztő elégedett a módosításokkal, létrehoz egy lekéréses kérelmet a szolgáltatáságból a fő- vagy együttműködési ágba, hogy a módosításokat a társviszonyok felülvizsgálják.

4. A lekéréses kérelem jóváhagyása és a módosítások a főágban való egyesítése után a módosítások közzé lesznek téve a fejlesztői gyárban.

5. Ha a csapat készen áll a módosítások tesztelési vagy felhasználói elfogadási tesztüzemben való üzembe helyezésére, a csapat az Azure Pipelines kiadására lép, és üzembe helyezi a fejlesztői gyár kívánt verzióját a UAT-ben. Ez az üzembe helyezés egy Azure Pipelines-feladat részeként történik, és Resource Manager-sablonparaméterekkel alkalmazza a megfelelő konfigurációt.

6. Miután ellenőrizte a módosításokat a teszt-előállítóban, helyezze üzembe az éles üzemben a folyamatok kiadásának következő feladatával.

Megjegyzés:

Csak a fejlesztői gyár van hozzárendelve egy git-adattárhoz. A teszt- és éles üzemeket nem szabad git-adattárral társítani, és csak Azure DevOps-folyamaton vagy erőforrás-kezelési sablonon keresztül kell frissíteni.

Az alábbi kép az életciklus különböző lépéseit emeli ki.

A folyamatos integráció automatizálása az Azure Pipelines-kiadások használatával

Az alábbi útmutató egy Azure Pipelines-kiadás beállításához nyújt útmutatást, amely automatizálja egy adat-előállító üzembe helyezését több környezetben.

Requirements

• Az Azure Resource Manager szolgáltatásvégpontot használó Visual Studio Team Foundation-kiszolgálóhoz vagy Azure-adattárhoz társított Azure-előfizetés

• Azure Repos Git-integrációval konfigurált adat-előállító.

• Az egyes környezetekhez tartozó titkos kulcsokat tartalmazó Azure-kulcstartó.

Azure Pipelines-kiadás beállítása

1. Az Azure DevOpsban nyissa meg az adat-előállítóval konfigurált projektet.

2. A lap bal oldalán válassza a Folyamatok, majd a Kiadások lehetőséget.

   

3. Válassza az Új folyamat lehetőséget, vagy ha már rendelkezik meglévő folyamatokkal, válassza az Új , majd az Új kiadási folyamatot.

4. Válassza az Üres feladat sablont.

   

5. A Szakasznév mezőbe írja be a környezet nevét.

6. Válassza az Összetevő hozzáadása lehetőséget, majd válassza ki a fejlesztői adat-előállítóval konfigurált Git-adattárat. Válassza ki az alapértelmezett ág adattárának közzétételi ágát. Alapértelmezés szerint ez a közzétételi ág a következő adf_publish: . Az Alapértelmezett verzió esetében válassza az Alapértelmezett ág Legújabb elemét.

   

7. Azure Resource Manager üzembe helyezési feladat hozzáadása:

   a. A szakasznézetben válassza a Szakaszfeladatok megtekintése lehetőséget.

   

   b. Hozzon létre egy új feladatot. Keresse meg az ARM-sablon üzembe helyezését, majd válassza a Hozzáadás lehetőséget.

   c. Az üzembe helyezési feladatban válassza ki a céladat-előállító előfizetését, erőforráscsoportját és helyét. Szükség esetén adja meg a hitelesítő adatokat.

   d. A Művelet listában válassza az Erőforráscsoport létrehozása vagy frissítése lehetőséget.

   e. Válassza a Három pont gombot (...) a Sablon mező mellett. Keresse meg a konfigurált Git-adattár közzétételi ágában létrehozott Azure Resource Manager-sablont. Keresse meg a fájlt ARMTemplateForFactory.json a <FactoryName> adf_publish ág mappájában.

   f. Válassza a ... lehetőséget a Sablon paraméterei mező mellett a paraméterfájl kiválasztásához. Keresse meg a fájlt ARMTemplateParametersForFactory.json a <FactoryName> adf_publish ág mappájában.

   g. Válassza a ... lehetőséget a Sablonparaméterek felülbírálása mező mellett, és adja meg a céladat-előállító kívánt paraméterértékeit. Az Azure Key Vaultból származó hitelesítő adatok esetében adja meg a titkos kód nevét a kettős idézőjelek között. Ha például a titkos kód neve cred1, adja meg a "$(cred1)" értéket ehhez az értékhez.

   h. Válassza a Növekményes beállítást az üzembe helyezési módhoz.

   Figyelmeztetés

   Teljes üzembe helyezési módban a rendszer törli azokat az erőforrásokat, amelyek az erőforráscsoportban találhatók, de nincsenek megadva az új Resource Manager-sablonban.

   

8. Mentse a kiadási folyamatot.

9. Kiadás aktiválásához válassza a Kiadás létrehozása lehetőséget. Az Azure DevOpsban ez automatizálható.

   

Fontos

CI/CD-forgatókönyvekben a különböző környezetekben az integrációs modul (IR) típusának meg kell egyeznie. Ha például egy saját üzemeltetésű integrációs modult használ a fejlesztési környezetben, akkor ugyanazt az integrációs modult más környezetekben, például a tesztelésben és az éles környezetben is saját üzemeltetésűnek kell lennie. Hasonlóképpen, ha több fázison keresztül oszt meg integrációs futtatókörnyezeteket, akkor az integrációs futtatókörnyezeteket minden környezetben , például fejlesztésben, tesztelésben és éles környezetben, összekapcsoltként kell konfigurálnia.

Titkos kulcsok lekérése az Azure Key Vaultból

Ha titkos kulcsokat szeretne átadni egy Azure Resource Manager-sablonban, javasoljuk, hogy az Azure Key Vaultot használja az Azure Pipelines kiadással.

A titkos kulcsok kétféleképpen kezelhetők:

1. Adja hozzá a titkos kulcsokat a paraméterfájlhoz.

   Hozzon létre egy másolatot a közzétételi ágba feltöltött paraméterfájlról. Állítsa be a Key Vaultból lekérni kívánt paraméterek értékeit a következő formátumban:

   {
       "parameters": {
           "azureSqlReportingDbPassword": {
               "reference": {
                   "keyVault": {
                       "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                   },
                   "secretName": " < secret - name > "
               }
           }
       }
   }
   

   Ha ezt a módszert használja, a rendszer automatikusan lekérte a titkos kulcsot a kulcstartóból.

   A paraméterfájlnak a közzétételi ágban is meg kell lennie.

2. Adjon hozzá egy Azure Key Vault-feladatot az előző szakaszban ismertetett Azure Resource Manager-üzembe helyezési feladat előtt:

   1. A Feladatok lapon hozzon létre egy új feladatot. Keressen rá az Azure Key Vaultra, és adja hozzá.

   2. A Key Vault-feladatban válassza ki azt az előfizetést, amelyben létrehozta a kulcstartót. Szükség esetén adja meg a hitelesítő adatokat, majd válassza ki a kulcstartót.

   

Engedélyek megadása az Azure Pipelines-ügynöknek

Ha a megfelelő engedélyek nincsenek beállítva, előfordulhat, hogy az Azure Key Vault-feladat a hozzáférés megtagadása hibával hiúsul meg. Töltse le a kiadás naplóit, és keresse meg a parancsot tartalmazó .ps1 fájlt, amely engedélyeket ad az Azure Pipelines-ügynöknek. A parancsot közvetlenül is futtathatja. Másolhatja az egyszerű azonosítót a fájlból, és manuálisan is hozzáadhatja a hozzáférési szabályzatot az Azure Portalon. Get és List a minimális engedélyekre van szükség.

Aktív eseményindítók frissítése

Az üzembe helyezés sikertelen lehet, ha aktív eseményindítókat próbál frissíteni. Az aktív eseményindítók frissítéséhez manuálisan le kell állítania őket, majd újra kell indítania őket az üzembe helyezés után. Ezt egy Azure PowerShell-feladattal teheti meg:

1. A kiadás Feladatok lapján adjon hozzá egy Azure PowerShell-feladatot. Válassza ki a 4. feladatverziót.*.

2. Válassza ki azt az előfizetést, amelyben a gyár található.

3. Szkripttípusként válassza a Szkriptfájl elérési útját . Ehhez mentenie kell a PowerShell-szkriptet az adattárba. Az eseményindítók leállításához a következő PowerShell-szkript használható:

   $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName
   
   $triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }
   

Az eseményindítók üzembe helyezés utáni újraindításához hasonló lépéseket is végrehajthat (a Start-AzDataFactoryV2Trigger függvénnyel együtt).

Megjegyzés:

Ezek a lépések már szerepelnek az Azure Data Factory csapata által biztosított üzembe helyezés előtti és utáni szkriptekben

Resource Manager-sablon manuális előléptetése minden környezethez

Ha nem tudja használni az Azure DevOpst vagy egy másik kiadáskezelő eszközt, manuálisan előléptethet egy adat-előállítót ARM-sablonnal.

1. Az ARM-sablonlistában válassza az ARM-sablon exportálása lehetőséget az adat-előállító Resource Manager-sablonjának fejlesztési környezetben való exportálásához.

   

2. A teszt- és éles adatgyárakban válassza az ARM-sablon importálása lehetőséget. Ez a művelet az Azure Portalra viszi, ahol importálhatja az exportált sablont. Válassza a Saját sablon létrehozása a szerkesztőben lehetőséget a Resource Manager-sablonszerkesztő megnyitásához.

   

3. Válassza a Fájl betöltése lehetőséget, majd válassza ki a létrehozott Resource Manager-sablont. Ez az 1. lépésben exportált .zip fájlban található arm_template.json fájl.

   

4. A beállítások szakaszban adja meg a konfigurációs értékeket, például a társított szolgáltatás hitelesítő adatait. Ha elkészült, válassza a Vásárlás lehetőséget a Resource Manager-sablon üzembe helyezéséhez.

   

Az Azure Resource Manager-sablon paramétereinek testreszabása

Ha a fejlesztői gyárhoz tartozik git-adattár, felülbírálhatja a Resource Manager-sablon alapértelmezett Resource Manager-sablonparamétereit a sablon közzétételével vagy exportálásával. Az alábbi esetekben érdemes lehet felülbírálni az alapértelmezett paraméterezési sablont:

• Automatizált CI/CD-t használ, és módosítani szeretne néhány tulajdonságot a Resource Manager üzembe helyezése során, de a tulajdonságok alapértelmezés szerint nem paraméterezhetők.
• A gyár olyan nagy, hogy az alapértelmezett Resource Manager-sablon érvénytelen, mert több mint a maximálisan engedélyezett paraméterekkel rendelkezik (256).

Az alapértelmezett paraméterezési sablon felülbírálásához lépjen a felügyeleti központba, és válassza a paraméterezési sablont a forrásvezérlő szakaszban. Válassza a Sablon szerkesztése lehetőséget a paraméterezési sablon kódszerkesztőjének megnyitásához.

Egyéni paraméterezési sablon létrehozása létrehoz egy arm-template-parameters-definition.json nevű fájlt a git-ág gyökérmappájában. Pontosan ezt a fájlnevet kell használnia.

Az együttműködési ágból való közzétételkor a Data Factory beolvassa ezt a fájlt, és annak konfigurációjával hozza létre, hogy mely tulajdonságok lesznek paraméterezve. Ha nem található fájl, a rendszer az alapértelmezett sablont használja.

Resource Manager-sablon exportálásakor a Data Factory azt a fájlt olvassa be, amelyiken éppen dolgozik, nem pedig az együttműködési ágból. A fájlt létrehozhatja vagy szerkesztheti egy privát ágból, ahol tesztelheti a módosításokat az ARM-sablon exportálása lehetőség kiválasztásával a felhasználói felületen. Ezután egyesítheti a fájlt az együttműködési ágba.

Megjegyzés:

Az egyéni paraméterezési sablon nem módosítja az ARM-sablon 256-os paraméterkorlátját. Lehetővé teszi a paraméteres tulajdonságok számának kiválasztását és csökkentését.

Egyéni paraméterszintaxis

Az alábbiakban néhány útmutatást követünk az egyéni paraméterfájl, az arm-template-parameters-definition.json létrehozásakor. A fájl minden entitástípushoz tartalmaz egy szakaszt: eseményindító, folyamat, társított szolgáltatás, adatkészlet, integrációs modul és adatfolyam.

• Adja meg a tulajdonság elérési útját a megfelelő entitástípus alatt.
• A tulajdonságnév * beállítása azt jelzi, hogy az alatta lévő összes tulajdonságot paraméterezni szeretné (csak az első szintig, nem rekurzívan). Kivételeket is megadhat ehhez a konfigurációhoz.
• Egy tulajdonság értékének sztringként való beállítása azt jelzi, hogy paraméterezni szeretné a tulajdonságot. Használja a következő formátumot: <action>:<name>:<stype>.
  • <action> a következő karakterek egyike lehet:
    • = azt jelenti, hogy a paraméter alapértelmezett értékeként megtartja az aktuális értéket.
    • - azt jelenti, hogy ne tartsa meg a paraméter alapértelmezett értékét.
    • |Az Azure Key Vault titkos kulcsainak különleges esete kapcsolati sztring vagy kulcsokhoz.
  • <name> a paraméter neve. Ha üres, akkor a tulajdonság nevét veszi fel. Ha az érték egy - karakterrel kezdődik, a név rövidül. A rövidítés például AzureStorage1_properties_typeProperties_connectionString a következőre rövidül AzureStorage1_connectionString: .
  • <stype> a paraméter típusa. Ha <stype> üres, az alapértelmezett típus a következő string: . Támogatott értékek: string, bool, number, objectés securestring.
• Ha megad egy tömböt a definíciós fájlban, az azt jelzi, hogy a sablon egyező tulajdonsága tömb. A Data Factory a tömb összes objektumán végigfut a tömb integrációs modul objektumában megadott definícióval. A második objektum, egy sztring lesz a tulajdonság neve, amelyet a rendszer az egyes iterációk paraméterének neveként használ.
• A definíciók nem lehetnek erőforráspéldányokra jellemzőek. A definíciók az adott típusú összes erőforrásra vonatkoznak.
• Alapértelmezés szerint minden biztonságos sztring, például a Key Vault titkos kulcsai és a biztonságos sztringek, például kapcsolati sztring, kulcsok és jogkivonatok paraméterezve vannak.

Hivatkozott sablonok

Ha beállította a CI/CD-t az adat-előállítókhoz, előfordulhat, hogy a gyár növekedésével túllépi az Azure Resource Manager-sablon korlátait. Az egyik korlát például a Resource Manager-sablonban lévő erőforrások maximális száma. Ha nagy gyárakat szeretne befogadni egy gyár teljes Resource Manager-sablonjának létrehozásakor, a Data Factory összekapcsolt Resource Manager-sablonokat hoz létre. Ezzel a funkcióval a teljes gyári hasznos adat több fájlra van lebontva, hogy ne korlátozzák a korlátok.

Ha konfigurálta a Gitet, a csatolt sablonok a adf_publish ágban lévő teljes Resource Manager-sablonok mellett jönnek létre és mentve lesznek egy új, linkedTemplates nevű mappában. A csatolt Resource Manager-sablonok általában egy fősablonból és a főkiszolgálóhoz csatolt gyermeksablonokból állnak. A szülősablon neve ArmTemplate_master.json, a gyermeksablonok neve pedig ArmTemplate_0.json, ArmTemplate_1.json stb.

Ha a teljes Resource Manager-sablon helyett csatolt sablonokat szeretne használni, frissítse a CI-/CD-feladatot, hogy az ArmTemplateForFactory.json (a teljes Resource Manager-sablon) helyett ArmTemplate_master.jsonra mutasson. A Resource Manager azt is megköveteli, hogy feltöltse a csatolt sablonokat egy tárfiókba, hogy az Azure hozzáférhessen az üzembe helyezés során.

Gyorsjavítás éles környezete

Ha üzembe helyez egy gyárat az éles környezetben, és rájön, hogy egy hibát azonnal javítani kell, de az aktuális együttműködési ágat nem tudja üzembe helyezni, előfordulhat, hogy gyorsjavítást kell üzembe helyeznie. Ezt a megközelítést gyorsjavítási mérnöki vagy QFE-nek nevezzük.

1. Az Azure DevOpsban nyissa meg az éles környezetben üzembe helyezett kiadást. Keresse meg az utolsó üzembe helyezett véglegesítést.

2. A véglegesítési üzenetből kérje le az együttműködési ág véglegesítési azonosítóját.

3. Hozzon létre egy új gyorsjavítási ágat a véglegesítésből.

4. Nyissa meg az Azure Data Factory UX-t, és váltson a gyorsjavítási ágra.

5. Az Azure Data Factory UX használatával javítsa ki a hibát. Tesztelje a módosításokat.

6. A javítás ellenőrzése után válassza az ARM-sablon exportálása lehetőséget a Resource Manager-sablon gyorsjavításának lekéréséhez.

7. Manuálisan ellenőrizze a buildet a közzétételi ágban.

8. Ha úgy konfigurálta a kiadási folyamatot, hogy adf_publish bejelentkezések alapján automatikusan aktiváljon, automatikusan elindul egy új kiadás. Ellenkező esetben manuálisan várjon egy kiadást.

9. Telepítse a gyorsjavítás kiadását a teszt- és gyártógyárakban. Ez a kiadás tartalmazza az előző éles hasznos adatokat, valamint az 5. lépésben elvégzett javítást.

10. Adja hozzá a gyorsjavítás módosításait a fejlesztési ághoz, hogy a későbbi kiadások ne tartalmazzák ugyanazt a hibát.

Ajánlott eljárások a folyamatos integrációhoz/folyamatos kézbesítéshez

Ha Git-integrációt használ az adat-előállítóval, és rendelkezik egy CI/CD-folyamattal, amely a fejlesztésről a tesztelésre, majd az éles környezetbe helyezi át a módosításokat, az alábbi ajánlott eljárásokat javasoljuk:

• Git-integráció. Csak a fejlesztői adat-előállítót konfigurálja Git-integrációval. A teszteléshez és az éles környezethez szükséges módosítások CI/CD-n keresztül lesznek üzembe helyezve, és nincs szükség Git-integrációra.

• Üzembe helyezés előtti és utáni szkript. A Ci/CD Resource Manager üzembe helyezési lépése előtt el kell végeznie bizonyos feladatokat, például az eseményindítók leállítását és újraindítását, valamint a törlést. Javasoljuk, hogy az üzembe helyezési feladat előtt és után használjon PowerShell-szkripteket. A data factory csapata egy szkriptet adott meg az Azure Data Factory CI/CD dokumentációs oldalán.

• Integrációs futtatókörnyezetek és megosztás. Az integrációs futtatókörnyezetek nem változnak gyakran, és a CI/CD minden szakaszában hasonlóak. A Data Factory tehát elvárja, hogy a CI/CD minden szakaszában ugyanazzal a névvel és típusú integrációs futtatókörnyezetkel rendelkezzen. Ha minden fázisban meg szeretné osztani az integrációs futtatókörnyezeteket, fontolja meg, hogy csak a megosztott integrációs futtatókörnyezeteket tartalmazza egy ternáris gyár használatával. Ezt a megosztott gyárat az összes környezetben használhatja csatolt integrációs modultípusként.

• Felügyelt privát végpont üzembe helyezése. Ha egy privát végpont már létezik egy gyárban, és olyan ARM-sablont próbál üzembe helyezni, amely azonos nevű, de módosított tulajdonságokkal rendelkező privát végpontot tartalmaz, az üzembe helyezés sikertelen lesz. In other words, you can successfully deploy a private endpoint as long as it has the same properties as the one that already exists in the factory. If any property is different between environments, you can override it by parameterizing that property and providing the respective value during deployment.

• Key Vault. Ha olyan társított szolgáltatásokat használ, amelyek kapcsolati adatait az Azure Key Vault tárolja, ajánlott külön kulcstartókat tartani a különböző környezetekhez. Az egyes kulcstartókhoz külön engedélyszinteket is konfigurálhat. Előfordulhat például, hogy nem szeretné, hogy a csapattagok rendelkezzenek engedélyekkel az éles titkos kulcsokhoz. Ha ezt a megközelítést követi, javasoljuk, hogy minden fázisban tartsa meg ugyanazokat a titkos neveket. Ha megtartja ugyanazokat a titkos kódneveket, nem kell minden kapcsolati sztring paramétereznie a CI/CD-környezetekben, mert csak a kulcstartó neve változik, amely egy külön paraméter.

• Az erőforrások elnevezése AZ ARM-sablon korlátai miatt az üzembe helyezés során problémák léphetnek fel, ha az erőforrások szóközöket tartalmaznak a névben. Az Azure Data Factory csapata "_" vagy "-" karakterek használatát javasolja az erőforrások szóközei helyett. A "Pipeline_1" például előnyösebb név lenne az 1. folyamatnál.

Folytatás