Testování prostředků po nasazení

  • 6 min

Ověřením a náhledem nasazení Bicep jste byli schopni vytvořit jistotu, že se vaše soubory Bicep úspěšně nasadí. Nasazení ale není celý příběh. Po dokončení nasazení je také užitečné zkontrolovat, jestli vaše nasazení dělalo to, co jste očekávali.

V této lekci se dozvíte o testech, které můžete spustit po dokončení nasazení. Dozvíte se také o vrácení nasazení zpět, pokud se věci nevyzná podle očekávání.

Spuštění orientačních testů a negativních testů

Když definujete prostředky v souboru Bicep, vaším cílem není jen vytvářet prostředky v Azure. Při splnění požadavků vaší organizace doručuje vaší organizaci hodnotu. Při ověřování a zobrazení náhledu souborů Bicep získáte jistotu, že definice prostředků jsou platné, ale nemusíte nutně vědět, že prostředky budou ve skutečnosti dělat to, co chcete.

Představte si například, že nasadíte nový logický server Azure SQL pomocí kanálu nasazení Bicep. Vaše definice Bicep pro server je platná, takže předává fáze linteru a předběžného ověření. Příkaz what-if ukazuje, že se vytvoří server, což je to, co očekáváte. Nasazení se také úspěšně dokončí. Na konci procesu nasazení ale stále nemusíte mít funkční databázový server, který je připravený k použití. Mezi důvody můžou patřit:

  • Nenakonfigurovali jste pravidla brány firewall tak, aby umožňovala síťové přenosy do vašeho serveru.
  • Ověřování Microsoft Entra jste na serveru povolili, pokud byste neměli nebo naopak.

I když právě nasazujete základní soubory Bicep, je vhodné zvážit, jak můžete ověřit, že prostředky, které nasazujete, skutečně fungují a splňují vaše požadavky. Tady jsou příklady použití tohoto principu:

  • Když nasadíte web, zkuste se z kanálu spojit s webovou aplikací. Ověřte, že se váš kanál úspěšně připojí k webu a obdrží platný kód odpovědi.
  • Když nasadíte síť pro doručování obsahu (CDN), zkuste se připojit k prostředku prostřednictvím sítě CDN. Ověřte, že se kanál úspěšně připojí k CDN a obdrží platný kód odpovědi.

Tyto testy se někdy označují jako orientační testy infrastruktury. Orientační testování je jednoduchá forma testování navržená tak, aby odhalila velké problémy ve vašem nasazení.

Poznámka:

Některé prostředky Azure se nesnadně dostanou z agenta kanálu hostovaného Microsoftem. Pokud vyžadují přístup k prostředkům prostřednictvím privátních sítí, možná budete muset zvážit použití agenta v místním prostředí ke spouštění fází orientačního testu.

Je také vhodné provést negativní testování. Negativní testování vám pomůže ověřit, že vaše prostředky nemají nežádoucí chování. Když například nasadíte virtuální počítač, je vhodné použít Azure Bastion k bezpečnému připojení k virtuálnímu počítači. Do kanálu můžete přidat negativní test, abyste ověřili, že se nemůžete připojit k virtuálnímu počítači přímo pomocí připojení ke vzdálené ploše nebo SSH.

Důležité

Cílem těchto testů není ověřit, že bicep správně nasadil vaše prostředky. Pomocí Bicep předpokládáte, že nasadí prostředky, které zadáte v souborech Bicep. Cílem je místo toho ověřit, že vámi definované prostředky budou fungovat pro vaši situaci a splňovat vaše požadavky.

Spouštění testů z Azure Pipelines

V kanálu můžete spouštět testy mnoha způsoby. V tomto modulu použijeme Pester, což je opensourcový nástroj, který spouští testy napsané prostřednictvím PowerShellu. Můžete se rozhodnout použít jinou testovací architekturu nebo dokonce zvolit spuštění testů bez testovacího nástroje. Například dalším testovacím nástrojem, který je potřeba zvážit, je psRule pro Azure, který zahrnuje předem připravená pravidla a testy pro Azure. Může spouštět ověřování na šablonách a také spouštět testy na nasazených prostředcích Azure. V souhrnu budeme odkazovat na psRule.

Když používáte podporovanou testovací architekturu, Azure Pipelines rozumí výsledkům každého testu. Zobrazí výsledky testu společně s informacemi o spuštění kanálu a sleduje historii každého testu v průběhu času. V dalším cvičení se dozvíte, jak můžete azure Pipelines používat s orientačními testy infrastruktury.

Předávání dat mezi kroky a fázemi

Když kanál rozdělíte do několika fází, každá z nich má vlastní zodpovědnost, někdy potřebujete předávat data mezi těmito fázemi. Jedna fáze může například vytvořit prostředek Azure, se kterým musí pracovat jiná fáze. Aby bylo možné předávat data, musí druhá fáze znát název vytvořeného prostředku. Naše fáze orientačního testu například potřebuje přístup k prostředkům, které fáze nasazení nasadila.

Váš soubor Bicep nasadí prostředky, aby mohl přistupovat k vlastnostem prostředku a publikovat je jako výstup nasazení. Ve svém kanálu můžete získat přístup k výstupu nasazení. Ve službě Azure Pipelines existuje speciální syntaxe pro publikování proměnných, která je zpřístupní napříč fázemi.

Nejprve musíte publikovat výstupní proměnnou pro fázi kanálu. K výstupu proměnné napíšete speciálně naformátovaný řetězec do protokolu kanálu, který Azure Pipelines ví, jak porozumět. V následujícím příkladu je proměnná s názvem myVariable nastavena na hodnotu myValue:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines čte a interpretuje řetězec z protokolu kanálu a zpřístupňuje hodnotu proměnné jako výstup. Tuto hodnotu můžete zkombinovat s dalšími skripty, které publikují hodnotu výstupu nasazení Bicep jako výstupní proměnnou pro fázi kanálu. V dalším cvičení se dozvíte, jak toto skriptování provést.

Za druhé musíte proměnnou zpřístupnit pro úlohu fáze orientačního testu. Definujete proměnnou pro úlohu a použijete další speciálně formátovaný řetězec YAML:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Všechny kroky v rámci úlohy orientačního testu teď můžou přistupovat k myVariable hodnotě jako jakékoli jiné proměnné pomocí syntaxe $(myVariable). Proměnnou použijete v dalším cvičení.

Další typy testů

Funkční testy a integrační testy se často používají k ověření, že nasazené prostředky se chovají podle očekávání. Například integrační test se může připojit k webu a odeslat testovací transakci a pak počkat na potvrzení úspěšného dokončení transakce. Pomocí integračních testů můžete otestovat řešení, které váš tým sestaví, spolu s infrastrukturou, na které běží. V dalším modulu se dozvíte, jak se tyto typy testů dají přidat do kanálu.

Je také možné spouštět další typy testů z kanálu nasazení, včetně testů výkonnosti a penetračních testů zabezpečení. Tyto testy jsou mimo rozsah tohoto modulu, ale můžou do automatizovaného procesu nasazení přidat hodnotu.

Vrácení zpět nebo vrácení vpřed

Předpokládejme, že váš kanál úspěšně nasadí vaše prostředky, ale vaše testy selžou. Co byste pak měli udělat?

Dříve v tomto modulu jste se dozvěděli, že Azure Pipelines umožňuje vytvářet fáze vrácení zpět, které se spustí v případě selhání předchozí fáze. Tento přístup můžete použít k vytvoření fáze vrácení zpět, když testovací fáze hlásí neočekávaný výsledek. Pokud se domníváte, že příčinou selhání byl dočasný problém, který byl od té doby vyřešen, můžete změny vrátit ručně nebo znovu spustit celý kanál.

Poznámka:

Když odešlete nasazení do Azure Resource Manageru, můžete požádat o automatické opětovné spuštění posledního úspěšného nasazení, pokud selže. K tomu je potřeba použít krok Azure CLI k nasazení souboru a přidat --rollback-on-error parametr při odeslání nasazení pomocí az deployment group create příkazu.

Často je obtížné provést kroky, které by měla provést fáze vrácení zpět. Obecně platí, že nasazení Bicep jsou složitá a změny se nedají snadno vrátit zpět. Vrácení zpět je obzvláště obtížné, když nasazení zahrnuje další komponenty.

Představte si například, že váš kanál nasadí soubor Bicep, který definuje databázi Azure SQL, a pak do databáze přidá nějaká data. Po vrácení nasazení by se data měla odstranit? Má být databáze také odebrána? Je těžké předpovědět, jak může každé selhání a každé vrácení zpět ovlivnit vaše spuštěné prostředí.

Z tohoto důvodu mnoho organizací dává přednost zavedení, což znamená, že rychle opraví důvod selhání a pak znovu nasadí. Vytvořením vysoce kvalitního automatizovaného procesu nasazení a dodržováním všech osvědčených postupů, které jste se naučili v rámci těchto studijních programů, budete schopni rychle opravit problémy a znovu nasadit soubory Bicep a současně zachovat vysokou kvalitu.

Tip

Jedním z principů myšlení DevOps je naučit se z chyb. Pokud potřebujete vrátit nasazení zpět, pečlivě zvažte, proč k chybě došlo, a před zahájením nasazení přidejte automatizované testování, abyste zjistili stejný problém, pokud k tomu dojde v budoucnu.