Folyamatos integráció és teljesítés az Azure Data Factoryben

A KÖVETKEZŐKRE VONATKOZIK: Azure Data Factory Azure Synapse Analytics

A folyamatos integráció az a gyakorlat, amely során a kódbázison végrehajtott minden módosítást automatikusan és a lehető leghamarabb tesztelünk. A folyamatos teljesítés a folyamatos integráció során zajló tesztelést követi, és egy előkészítési vagy éles rendszerbe küldi le a módosításokat.

Az Azure Data Factoryben a folyamatos integráció és teljesítés (CI/CD) a Data Factory-folyamatoknak az egyik (fejlesztési, tesztelési, éles) környezetből egy másikba történő áthelyezését jelenti. Azure Data Factory Azure Resource Manager-sablonokat használ a különböző ADF-entitások (folyamatok, adatkészletek, adatfolyamok stb.) konfigurációjának tárolására. Az adat-előállítók másik környezetbe való előléptetésének két javasolt módja van:

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

Megjegyzés

Ez a cikk az Azure Az PowerShell-modult használja, amely az Azure-ral való interakcióhoz ajánlott PowerShell-modul. Az Az PowerShell-modul használatának megkezdéséhez lásd az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.

CI/CD-életciklus

Megjegyzés

További információ: Folyamatos üzembe helyezés fejlesztései.

Az alábbiakban egy, az Azure Repos Gittel konfigurált Azure Data Factory CI/CD-életciklusát tekintheti át. A Git-adattár konfigurálásáról további információt az Azure Data Factory Verziókövetés című témakörében talál.

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

  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ásaikon. A folyamatfuttatások hibakeresésével kapcsolatos további információkért lásd: Iteratív fejlesztés és hibakeresés Azure Data Factory.

  3. Miután a fejlesztő elégedett a módosításokkal, létrehoz egy lekéréses kérelmet a funkcióágból a fő vagy együttműködési ágba, hogy a módosításokat a társak felülvizsgálhassá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 üzembe helyezésére egy teszt- vagy UAT- (felhasználói elfogadási teszt) gyárban, a csapat az Azure Pipelines-kiadásba lép, és üzembe helyezi a fejlesztői gyár kívánt verzióját az UAT-ben. Ez az üzembe helyezés egy Azure Pipelines-feladat részeként történik, és Resource Manager sablonparaméterek használatával 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 társítva egy Git-adattárral. A teszt- és éles gyárakhoz nem lehet git-adattár társítva, és csak Azure DevOps-folyamaton vagy Resource Management-sablonon keresztül frissíthetők.

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

Diagram of continuous integration with Azure Pipelines

Ajánlott eljárások a CI/CD-hez

Ha Git-integrációt használ az adat-előállítóval, és olyan CI-/CD-folyamattal rendelkezik, amely a módosításokat a fejlesztésről a tesztelésre, majd az éles környezetbe helyezi át, 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ési és éles 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 karbantartást. Javasoljuk, hogy az üzembe helyezési feladat előtt és után használjon PowerShell-szkripteket. További információ: Aktív eseményindítók frissítése. Az adat-előállító csapata egy, a lap alján található szkriptet adott meg.

  • Integrációs futtatókörnyezetek és megosztás. Az integrációs futtatókörnyezetek nem változnak gyakran, és hasonlóak a CI/CD minden szakaszában. A Data Factory tehát azt várja, hogy a CI/CD minden szakaszában ugyanazzal a névvel és típusú integrációs modullal rendelkezzen. Ha minden fázisban meg szeretné osztani az integrációs modulokat, fontolja meg egy ternáris gyár használatát, amely csak a megosztott integrációs futtatókörnyezeteket tartalmazza. 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 egy azonos nevű, de módosított tulajdonságokkal rendelkező privát végpontot tartalmaz, az üzembe helyezés sikertelen lesz. Más szóval sikeresen üzembe helyezhet egy privát végpontot, feltéve, hogy ugyanazokkal a tulajdonságokkal rendelkezik, mint a gyárban. Ha bármelyik tulajdonság különbözik a környezetek között, felülbírálhatja a tulajdonság paraméterezésével és a megfelelő érték megadásával az üzembe helyezés során.

  • 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 jogosultsági szinteket is konfigurálhat. Előfordulhat például, hogy nem szeretné, hogy a csapattagok engedélyekkel rendelkezzenek az éles titkos kódokhoz. Ha ezt a megközelítést alkalmazza, javasoljuk, hogy tartsa meg ugyanazokat a titkos neveket az összes fázisban. Ha megtartja ugyanazokat a titkos kódneveket, nem kell minden kapcsolati sztring paramétereznie a CI/CD-környezetekben, mert az egyetlen dolog, ami megváltozik, az a Key Vault neve, amely egy külön paraméter.

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

  • Expozíció-vezérlés és funkciójelzők. Amikor csapaton dolgozik, vannak olyan példányok, ahol egyesítheti a módosításokat, de nem szeretné, hogy emelt szintű környezetekben, például prod és minőségbiztosítási környezetben fussanak. A forgatókönyv kezeléséhez az ADF csapata a DevOps funkciójelölők használatát javasolja. Az ADF-ben kombinálhatja a globális paramétereket és az if condition tevékenységet , hogy elrejtse a logikai készleteket ezen környezeti jelzők alapján.

    A funkciójelölők beállításáról az alábbi oktatóvideóból tájékozódhat:

Nem támogatott szolgáltatások

  • A Data Factory nem teszi lehetővé a véglegesítések kiválasztását és az erőforrások szelektív közzétételét. A közzététel tartalmazza az adat-előállítóban végzett összes módosítást.

    • Az adat-előállító entitásai egymástól függenek. Az eseményindítók például a folyamatoktól, a folyamatok pedig az adathalmazoktól és más folyamatoktól függenek. Az erőforrások egy részhalmazának szelektív közzététele váratlan viselkedéshez és hibákhoz vezethet.
    • Olyan ritka esetekben, amikor szelektív közzétételre van szükség, érdemes lehet gyorsjavítást használni. További információ: Gyorsjavítások éles környezete.
  • A Azure Data Factory csapata nem javasolja, hogy Azure RBAC-vezérlőket rendeljen az adat-előállítók egyes entitásaihoz (folyamatokhoz, adatkészletekhez stb.). Ha például egy fejlesztő hozzáfér egy folyamathoz vagy adathalmazhoz, akkor hozzá kell férnie az adat-előállítóban lévő összes folyamathoz vagy adathalmazhoz. Ha úgy érzi, hogy számos Azure-szerepkört kell implementálnia egy adat-előállítóban, tekintse meg egy második adat-előállító üzembe helyezését.

  • Privát ágakból nem végezhető közzététel.

  • A Bitbucketen jelenleg nem lehet projekteket üzemeltetni.

  • Jelenleg nem exportálhat és importálhat riasztásokat és mátrixokat paraméterekként.

  • A adf_publish ág alatti kódtárban jelenleg a "PartialArmTemplates" nevű mappa van hozzáadva a "linkedTemplates" mappa, az "ARMTemplateForFactory.json" és az "ARMTemplateParametersForFactory.json" fájlok mellett a verziókövetéssel történő közzététel részeként.

    Diagram of 'PartialArmTemplates' folder.

    2021. november 1-től kezdve nem tesszük közzé a "PartialArmTemplates" parancsot a adf_publish ágban.

    Csak akkor kell műveletet végeznie, ha a PartialArmTemplates parancsot használja. Ellenkező esetben váltson az üzembe helyezés bármely támogatott mechanizmusára az "ARMTemplateForFactory.json" vagy a "linkedTemplates" fájlok használatával.

Következő lépések