Pochopení prostředí
Pracovní postupy nasazení umožňují automatizovat kroky v procesu nasazení. Často je potřeba spustit kroky v několika samostatných prostředích. Ve vaší společnosti toy chcete před nasazením změn do produkčního prostředí zkontrolovat změny kódu.
V této lekci se dozvíte, jak prostředí v GitHub Actions pomáhají podporovat vlastní proces.
Proč máte více prostředí?
Procesy nasazení mění prostředky Azure, včetně prostředků, které se používají. Změna prostředků zahrnuje určité riziko, protože změny, které nasazujete, se nemusí chovat podle očekávání. Můžete dokonce zjistit, že změny přeruší aktuální nastavení.
Pokud chcete minimalizovat riziko problémů, je vhodné vyzkoušet změny bezpečným způsobem, než je nasadíte do produkčního prostředí. Minimalizujete riziko nasazením změn do neprodukčního prostředí.
Řada organizací nastavila několik neprodukčních prostředí, kde postupně nasazují své změny před uvolněním do produkčního prostředí. Každé neprodukční prostředí slouží konkrétnímu účelu a často má specifické brány kvality, které musí být splněny, aby bylo možné pokračovat k dalšímu prostředí. Pokud se něco nepovede, jako je selhání testu, nasazení se zastaví. S tím, jak vaše nasazení prochází jednotlivými prostředími, roste vaše důvěra ve změny.
Mezi běžná prostředí patří:
Vývoj: Vývojové prostředí obvykle používají vývojáři k vyzkoušení svých změn a k rychlé iteraci práce.
Vývojová prostředí mají často minimální ovládací prvky, aby si členové týmu mohli snadno vyzkoušet nápady. Vývojové prostředí můžete použít k otestování určitého nastavení konfigurace prostředku nebo k tomu, abyste zjistili, jak můžete nastavit nový web s back-endovou databází zabezpečeným způsobem. Mnoho z těchto změn a zkušebních verzí nemusí v procesu nasazení pokračovat, protože eliminujete nápady, které neuspějí.
V některých týmech můžete dokonce nastavit samostatné vývojové prostředí pro každého člena týmu, aby se navzájem nedostali do cesty, když pracují na nových funkcích.
Vývojová prostředí se někdy také označují jako sandboxová prostředí.
Test: Testovací prostředí je navržené pro spouštění ručních nebo automatizovaných testů proti vašim změnám.
Testovací prostředí je možné použít v procesu kontinuální integrace. Po nasazení změny do testovacího prostředí je možné spouštět automatizované testy. Pokud všechny automatizované testy projdou, je změna bezpečná pro sloučení do hlavní větve projektu. Automatizované testy obvykle kontrolují základní systémové funkce spolu s porušeními zásad v nově nasazených prostředcích.
Můžete také vytvořit vyhrazená testovací prostředí pro konkrétní typy testování, jako je výkon a testování zabezpečení.
Integrace: Prostředí integrace vám může pomoct otestovat všechny integrační body s jinými systémy.
V prostředí integrace můžete simulovat komplexní transakce. Tyto testy se často spouštějí automaticky, ale mnoho organizací také provádí ruční testování v tomto prostředí.
Integrační prostředí se někdy také označují jako prostředí sit (System Integration Test ).
Uživatelský akceptační test: Prostředí uživatelských akceptačních testů (UAT) se používá k ručnímu ověření, obvykle pro obchodní účastníky, nikoli pro vývojáře. Při ručním ověření někdo projde řešením a ověří, že se chová podle očekávání a že splňuje nezbytné obchodní požadavky. Tato osoba pak schválí změny, aby nasazení bylo možné pokračovat.
Předprodukční prostředí: Předprodukční prostředí je často zrcadlem produkčního prostředí se stejnými skladovými položkami prostředků a konfigurací. Používá se jako konečná kontrola k ověření chování produkčního nasazení během a po použití změny. Dá se také použít k ověření, jestli se během produkčního nasazení očekává jakýkoli výpadek.
Předprodukční prostředí se někdy také označují jako přípravná prostředí.
Produkční prostředí: Vaše produkční prostředí je prostředí, které koncoví uživatelé aplikace používají. Je to vaše živé prostředí, které chcete chránit a udržovat v provozu co nejvíce.
V některých organizacích můžete mít několik produkčních prostředí. Můžete mít například produkční prostředí v různých geografických oblastech nebo obsluhovat různé skupiny zákazníků.
Ukázka: Váš tým může také vytvořit ukázková (ukázková) prostředí, která aplikaci ukážou koncovým uživatelům, aby ji mohli používat při školení nebo prodejní týmy k zobrazení určitých možností potenciálním zákazníkům. Můžete mít dokonce několik ukázkových prostředí, která slouží různým účelům. Ukázkové prostředí je často zmenšená replika produkčního prostředí s falešnými zákaznickými daty.
Prostředí ve vaší organizaci
Může se zobrazit varianta těchto prostředí. Některé organizace používají jenom několik prostředí a některé používají mnohem víc. Počet a typ prostředí, která používáte, závisí na řešení, které nasazujete, velikosti týmu, který řešení vytváří, a na důležitosti úlohy.
V některých případech má jedno prostředí roli několika dříve uvedených prostředí. Jindy můžete mít složitý pracovní postup, který se nasadí do více prostředí, některé paralelně a některé postupně. Některé organizace dokonce automaticky odstraní nebo zruší zřízení prostředí, když se už nepoužívají, a pak je znovu nasadí, až budou v budoucnu potřeba.
Ať už si vaše organizace zvolí svůj seznam prostředí, je cílem zlepšit vaši důvěru v změnu při procházení pracovním postupem nasazení. Pokud změna nesplňuje vaše požadavky na kvalitu, chcete mít možnost zastavit nasazení této změny do všech následných prostředí v řetězci.
Ve vaší toy společnosti se rozhodnete začít se základní sadou prostředí pro váš web. Kromě produkčního prostředí vytvoříte jedno neprodukční prostředí s názvem Test:
Pracovní postup aktualizujete tak, aby nasadil kód Bicep do testovacího prostředí a spustili na něm několik základních testů. Pokud bude toto úsilí úspěšné, můžete ho nasadit do produkčního prostředí.
Prostředí pracovních postupů
GitHub Actions má také koncept prostředí. Vytvoříte prostředí GitHub Actions, které bude představovat prostředí, které máte v Azure. Když pracovní postup definujete v souboru YAML, můžete úlohy propojit s konkrétním prostředím. Pomocí prostředí získáte v pracovním postupu některé další funkce.
Pravidla ochrany
Prostředí v GitHub Actions může mít nakonfigurovaná pravidla ochrany. Pokaždé, když se prostředí používá v úloze pracovního postupu, GitHub Actions zajistí splnění těchto pravidel před spuštěním úlohy.
Můžete například nakonfigurovat ruční kontroly v produkčním prostředí. Před zahájením produkčního nasazení obdrží určený kontrolor oznámení. Tato osoba může ručně ověřit splnění zásad a postupů před zahájením nasazení. Schvalovatel může například před schválením nasazení zkontrolovat, jestli všechno funguje podle očekávání v předprodukčním prostředí.
Kromě toho můžete spustit automatizovanou kontrolu a potvrdit větev, ze které vaše změna pochází. Pokud tato změna není ve vaší hlavní větvi, můžete GitHub nakonfigurovat tak, aby se zabránilo jeho nasazení do produkčního prostředí.
Tajné kódy
GitHub Actions umožňuje ukládat tajné kódy, které se dají používat jenom s konkrétním prostředím. Další informace o správě tajných kódů se dozvíte později v tomto modulu.
Historie nasazení
GitHub Actions sleduje historii nasazení do prostředí. Tato historie poskytuje snadný způsob, jak sledovat, co se v prostředí v průběhu času stane. Dokonce vám umožní trasovat nasazení do potvrzení ve vašem úložišti. Tato funkce může být užitečná, pokud máte problém s nasazením a potřebujete identifikovat změnu, která vedla k problému.
Vytvoření prostředí
Prostředí můžete vytvořit pomocí webového rozhraní GitHubu.
Když pracovní postup odkazuje na prostředí, které neexistuje, GitHub Actions ho automaticky vytvoří za vás. Tato funkce může ovlivnit zabezpečení úložiště GitHub, protože nové prostředí nebude mít nakonfigurovaná žádná pravidla ochrany. Nejlepší je vytvořit prostředí sami prostřednictvím webového rozhraní GitHubu, abyste měli plnou kontrolu nad jeho zabezpečením.
Propojení úlohy nasazení s prostředím
V definici pracovního postupu nasazení můžete odkazovat na prostředí pomocí environment vlastnosti:
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
V tomto příkladu je úloha propojená deploy s prostředím Test .
Prostředí a připojení k Azure
Pokud používáte více prostředí, měli byste každé prostředí nastavit nezávisle na ostatních prostředích. Web vašeho vývojového prostředí by například neměl mít přístup k databázi v produkčním prostředí.
Stejný princip platí i pro pracovní postup nasazení. Pro každé prostředí byste měli vytvořit samostatné identity úloh. Podle tohoto postupu přidáte další vrstvu ochrany, abyste zajistili, že vaše neprodukční nasazení neovlivní vaše produkční prostředí.
Identitám úloh by se měla přiřadit konkrétní oprávnění, která se mají nasadit jenom do předplatného a skupiny prostředků používané v daném prostředí:
Důležité
Pro každé prostředí, do kterého plánujete nasazení, použijte samostatnou identitu úlohy. Udělte identitě úlohy minimální oprávnění, která musí nasadit do svého prostředí, a ne ostatní.
Je také vhodné oddělit prostředí v Azure. Minimálně byste měli vytvořit samostatnou skupinu prostředků pro každé prostředí. V mnoha situacích je lepší vytvořit samostatná předplatná Azure pro každé prostředí. Pak můžete v rámci předplatného každého prostředí vytvořit více skupin prostředků.
Použijte přiřazení rolí Azure, aby uživatelé a identity úloh měli přístup pouze k prostředím, ke kterým potřebují přístup. Dávejte pozor, abyste omezili přístup k produkčnímu prostředí na malou sadu lidí a identitu úlohy nasazení pro dané prostředí.
Federované přihlašovací údaje pro prostředí
Když se vaše identita úloh připojí k Azure z pracovního postupu nasazení, použije federované přihlašovací údaje k bezpečnému ověření bez jakýchkoli tajných kódů nebo klíčů. V předchozíchmodulech modulech v tomto studijním programu udělila přístup k pracovním postupům nasazení při nasazení z hlavní větve úložiště Git.
Když nasadíte do prostředí v rámci pracovního postupu, musíte pro toto prostředí použít federované přihlašovací údaje s vymezeným oborem.
V tomto modulu zahrnuje pracovní postup několik úloh, z nichž mnohé se připojují a nasazují do Azure. Některé úlohy používají prostředí a některé ne. Proto pro každou identitu úloh vytvoříte dvě federované přihlašovací údaje: jednu vymezenou pro prostředí a jednu s vymezeným oborem na hlavní větev.