Zásady správného řízení infrastruktury Azure DevTest Labs

Tento článek se zabývá sladěním a správou prostředků pro DevTest Labs ve vaší organizaci.

Zdroje informací

Sladění prostředků DevTest Labs v rámci předplatného Azure

Než organizace začne používat Azure pro obecný vývoj aplikací, měli by it plánovači nejprve zkontrolovat, jak tuto funkci zavést jako součást svého celkového portfolia služeb. Oblasti ke kontrole by se měly zabývat následujícími aspekty:

• Jak měřit náklady spojené s životním cyklem vývoje aplikací?
• Jak organizace srovná navrženou nabídku služeb se zásadami podnikového zabezpečení?
• Vyžaduje se segmentace k oddělení vývojových a produkčních prostředí?
• Jaké kontroly se zavádějí pro dlouhodobou jednoduchost správy, stability a růstu?

Prvním doporučeným postupem je zkontrolovat taxonomii Azure v organizacích, ve kterých jsou popsány rozdělení mezi produkčním a vývojovým předplatným. V následujícím diagramu navrhovaná taxonomie umožňuje logické oddělení vývojových/testovacích a produkčních prostředí. Díky tomuto přístupu může organizace zavést fakturační kódy ke sledování nákladů spojených s každým prostředím samostatně. Další informace najdete v tématu Zásady správného řízení prescriptivního předplatného. Značky Azure můžete také použít k uspořádání prostředků pro účely sledování a fakturace.

Druhým doporučeným postupem je povolení předplatného DevTest na portálu Azure Enterprise Portal. Umožňuje organizaci spouštět klientské operační systémy, které nejsou obvykle dostupné v předplatném Azure Enterprise. Pak použijte podnikový software, ve kterém platíte jenom za výpočetní prostředky a nemusíte se starat o licencování. Zajišťuje, že fakturace určených služeb, včetně imagí galerie v IaaS, jako je Microsoft SQL Server, je založená pouze na spotřebě. Podrobnosti o předplatném Azure DevTest najdete tady pro zákazníky smlouva Enterprise (EA) a tady pro zákazníky s průběžnou platbou.

Tento model poskytuje organizaci flexibilitu nasazení služby Azure DevTest Labs ve velkém měřítku. Organizace může podporovat stovky testovacích prostředí pro různé organizační jednotky s 100 až 1000 virtuálními počítači běžícími paralelně. Podporuje koncept centralizovaného podnikového testovacího řešení, které může sdílet stejné principy správy konfigurace a kontrolních mechanismů zabezpečení.

Tento model také zajišťuje, že organizace nevyčerpá limity prostředků spojené s předplatným Azure. Podrobnosti o omezeních předplatného a služeb najdete v tématu Limity, kvóty a omezení předplatného a služeb Azure. Proces zřizování DevTest Labs může využívat velký počet skupin prostředků. Můžete požádat o navýšení limitů prostřednictvím žádosti o podporu v předplatném Azure DevTest. Prostředky v produkčním předplatném nejsou ovlivněné, protože se bude používat vývojové předplatné. Další informace o škálování DevTest Labs najdete v tématu Kvóty a omezení škálování v DevTest Labs.

Běžným limitem na úrovni předplatného, který je potřeba zohlednit, je způsob přidělování přiřazení rozsahu IP adres sítě pro podporu produkčního i vývojového předplatného. Tato přiřazení by měla zohledňovat růst v průběhu času (za předpokladu místního připojení nebo jiné síťové topologie, která vyžaduje, aby podnik spravil svůj síťový zásobník místo výchozí implementace Azure). Doporučeným postupem je mít několik virtuálních sítí, které mají přiřazenou velkou předponu IP adresy a rozdělují se s mnoha velkými podsítěmi, a nikoli s několika virtuálními sítěmi s malými podsítěmi. Například s 10 předplatnými můžete definovat 10 virtuálních sítí (jednu pro každé předplatné). Všechna testovací prostředí, která nevyžadují izolaci, můžou sdílet stejnou podsíť ve virtuální síti předplatného.

Počet uživatelů na testovací prostředí a testovací prostředí v organizaci

Obchodní jednotky a vývojové skupiny, které jsou přidružené ke stejnému vývojovému projektu, by se měly přidružit ke stejnému testovacímu prostředí. Umožňuje použití stejných typů zásad, imagí a zásad vypnutí pro obě skupiny.

Možná budete muset zvážit také geografické hranice. Například vývojáři v oblasti usa – východ USA (USA) můžou používat testovací prostředí zřízené v oblasti USA – východ 2. A vývojáři v Dallasu, Texasu a Denveru, Colorado mohou být přesměrováni na použití prostředku v oblasti USA – středojiž. Pokud se jedná o spolupráci s externí třetí stranou, může se jim přiřadit testovací prostředí, které interní vývojáři nepoužívají.

Testovací prostředí můžete použít také pro konkrétní projekt v rámci azure DevOps Projects. Potom použijete zabezpečení prostřednictvím zadané skupiny Microsoft Entra, která umožňuje přístup k oběma skupinám prostředků. Virtuální síť přiřazená k testovacímu prostředí může být další hranicí pro konsolidaciuživatelůch

Zabránění odstranění prostředků

Nastavte oprávnění na úrovni testovacího prostředí, aby mohli odstraňovat prostředky nebo měnit zásady testovacího prostředí jenom oprávnění uživatelé. Vývojáři by měli být umístěni ve skupině DevTest Labs Users . Vedoucí vývojář nebo vedoucí infrastruktury by měli být vlastníkem DevTest Labs. Doporučujeme, abyste měli jenom dva vlastníky testovacího prostředí. Tato zásada se vztahuje k úložišti kódu, aby se zabránilo poškození. Testovací prostředí používá práva k používání prostředků, ale nemůže aktualizovat zásady testovacího prostředí. Podívejte se na následující článek, který uvádí role a práva, která má každá integrovaná skupina v testovacím prostředí: Přidání vlastníků a uživatelů v Azure DevTest Labs.

Správa nákladů a vlastnictví

Náklady a vlastnictví jsou hlavními obavami, když uvažujete o vytváření vývojových a testovacích prostředí. V této části najdete informace, které vám pomůžou optimalizovat náklady a sladit vlastnictví ve vašem prostředí.

Optimalizace nákladů

Několik integrovaných funkcí DevTest Labs vám pomůže optimalizovat náklady. Informace o omezení aktivit uživatelů najdete v článcích o správě nákladů, prahových hodnotách a zásadách .

Pokud používáte DevTest Labs pro vývojové a testovací úlohy, zvažte použití výhody předplatného Enterprise pro vývoj/testování, které je součástí vašeho smlouva Enterprise. Nebo pokud jste zákazníkem s průběžnou platbou, zvažte nabídku DevTest s průběžným platbou.

Tento přístup nabízí několik výhod:

• Speciální nižší sazby za vývoj/testování na virtuálních počítačích s Windows, cloudových službách, HDInsight, App Service a Logic Apps
• Skvělé smlouva Enterprise (EA) sazby za ostatní služby Azure
• Přístup k exkluzivním imagím pro vývoj/testování v Galerii, včetně Windows 8.1 a Windows 10

Prostředky Azure spuštěné v rámci podnikového předplatného pro vývoj/testování můžou používat jenom aktivní předplatitelé sady Visual Studio (standardní předplatná, roční cloudová předplatná a měsíční cloudová předplatná). Koncoví uživatelé ale můžou k aplikaci získat přístup, aby mohli poskytnout zpětnou vazbu nebo provést testování přijetí. Prostředky v rámci tohoto předplatného můžete používat jenom pro vývoj a testování aplikací. Neexistuje žádná záruka provozuschopnosti.

Pokud se rozhodnete použít nabídku DevTest, využijte tuto výhodu výhradně pro vývoj a testování aplikací. Využití v rámci předplatného neslouží finančně zálohovanou smlouvu SLA, s výjimkou použití Azure DevOps a HockeyAppu.

Definování přístupu na základě rolí v celé organizaci

Centrální IT by mělo vlastnit jenom to, co je potřeba, a umožnit týmům projektu a aplikací mít potřebnou úroveň kontroly. Obvykle to znamená, že centrální IT vlastní předplatné a zpracovává základní IT funkce, jako jsou konfigurace sítí. Sada vlastníků předplatného by měla být malá. Tito vlastníci můžou jmenovat jiné vlastníky, pokud je potřeba, nebo použít zásady na úrovni předplatného, například Bez veřejné IP adresy.

Může existovat podmnožina uživatelů, kteří vyžadují přístup napříč předplatným, jako je podpora vrstvy 1 nebo vrstvy 2. V takovém případě doporučujeme těmto uživatelům udělit přístup přispěvatele , aby mohli spravovat prostředky, ale neposkytovali přístup uživatelů ani neupravovali zásady.

Vlastníci prostředků DevTest Labs by měli být blízko projektu nebo aplikačnímu týmu. Tito vlastníci rozumí požadavkům na počítač a software. Ve většině organizací je vlastníkem prostředku DevTest Labs vedoucí projekt nebo vývoj. Tento vlastník může spravovat uživatele a zásady v testovacím prostředí a může spravovat všechny virtuální počítače v prostředí DevTest Labs.

Přidejte členy projektového a aplikačního týmu do role DevTest Labs Users. Tito uživatelé můžou vytvářet virtuální počítače v souladu se zásadami testovacího prostředí a na úrovni předplatného. Uživatelé můžou také spravovat vlastní virtuální počítače, ale nemůžou spravovat virtuální počítače, které patří jiným uživatelům.

Další informace najdete v tématu Generování uživatelského rozhraní Azure Enterprise – zásady správného řízení předplatných.

Zásady společnosti a dodržování předpisů

Tato část obsahuje pokyny k řízení zásad společnosti a dodržování předpisů pro infrastrukturu Azure DevTest Labs.

Veřejné a privátní úložiště artefaktů

Veřejné úložiště artefaktů poskytuje počáteční sadu softwarových balíčků, které se nejčastěji používají. Pomáhá s rychlým nasazením, aniž byste museli investovat čas na reprodukci běžných vývojářských nástrojů a doplňků. Můžete se rozhodnout nasadit vlastní privátní úložiště. Veřejné a privátní úložiště můžete používat paralelně. Můžete se také rozhodnout zakázat veřejné úložiště. Kritéria nasazení privátního úložiště by měla být řízena následujícími otázkami a aspekty:

• Má organizace v rámci nabídky DevTest Labs požadavek na podnikový licencovaný software? Pokud je odpověď ano, mělo by se vytvořit privátní úložiště.
• Vyvíjí organizace vlastní software, který poskytuje konkrétní operaci, která se vyžaduje jako součást celkového procesu zřizování? Pokud je odpověď ano, mělo by se nasadit privátní úložiště.
• Pokud zásady správného řízení organizace vyžadují izolaci a externí úložiště nejsou pod přímou správou konfigurace organizace, měli byste nasadit privátní úložiště artefaktů. V rámci tohoto procesu lze počáteční kopii veřejného úložiště zkopírovat a integrovat s privátním úložištěm. Veřejné úložiště je pak možné zakázat, aby k němu nikdo v organizaci už neměl přístup. Tento přístup vynutí, aby všichni uživatelé v organizaci měli jenom jedno úložiště schválené organizací a minimalizovali posun konfigurace.

Jedno úložiště nebo více úložišť

Jako součást celkové strategie správy zásad správného řízení a konfigurace vaší organizace doporučujeme používat centralizované úložiště. Když používáte více úložišť, mohou se stát silami nespravovaného softwaru v průběhu času. S centrálním úložištěm může více týmů využívat artefakty z tohoto úložiště pro své projekty. Vynucuje standardizaci, zabezpečení, snadnou správu a eliminuje duplicitu úsilí. V rámci centralizace se doporučují následující akce pro dlouhodobou správu a udržitelnost:

• Přidružte Azure Repos ke stejnému tenantovi Microsoft Entra, který předplatné Azure používá k ověřování a autorizaci.
• Vytvořte skupinu s názvem Všichni vývojáři DevTest Labs v ID Microsoft Entra, která se centrálně spravuje. Každý vývojář, který přispívá k vývoji artefaktů, by měl být umístěn v této skupině.
• Stejnou skupinu Microsoft Entra můžete použít k zajištění přístupu k úložišti Azure Repos a k testovacímu prostředí.
• V Azure Repos by se větvení nebo fork měly použít k oddělení úložiště v rámci vývoje od primárního produkčního úložiště. Obsah se přidá jenom do hlavní větve s žádostí o přijetí změn po správné kontrole kódu. Jakmile kontrolor kódu změnu schválí, vedoucí vývojář, který je zodpovědný za údržbu hlavní větve, sloučí aktualizovaný kód.

Podnikové zásady zabezpečení

Organizace může použít firemní zásady zabezpečení pomocí:

• Vývoj a publikování komplexních zásad zabezpečení Tato zásada vyjadřuje pravidla přijatelného použití spojeného s používáním softwaru, cloudových prostředků. Definuje také, co jasně porušuje zásady.
• Vývoj vlastní image, vlastníchartefaktch Tento přístup vynucuje podnikovou hranici a nastavuje společnou sadu kontrol prostředí. Tyto ovládací prvky v prostředí, které vývojář může zvážit při vývoji a sledování životního cyklu zabezpečeného vývoje v rámci celého procesu. Cílem je také poskytnout prostředí, které není příliš omezující, které by mohlo bránit vývoji, ale přiměřenou sadu kontrol. Zásady skupiny v organizační jednotce,která obsahuje virtuální počítače testovacího prostředí, můžou být podmnožinou celkových zásad skupiny, které se nacházejí v produkčním prostředí. Alternativně se můžou jednat o jinou sadu, která správně zmírní všechna zjištěná rizika.

Integrita dat

Organizace může zajistit integritu dat, aby vývojáři vzdálené komunikace nemohli odebrat kód nebo zavést malware nebo neschválené software. Existuje několik vrstev řízení, které zmírnit hrozbu od externích konzultantů, dodavatelů nebo zaměstnanců, aby mohli spolupracovat v DevTest Labs.

Jak už jsme uvedli dříve, musí mít první krok přijatelnou zásadu použití, která je načrtnuta a jasně vystihoduje důsledky, když někdo zásadu porušuje.

První vrstva ovládacích prvků pro vzdálený přístup spočívá v použití zásad vzdáleného přístupu prostřednictvím připojení VPN, které není přímo připojené k testovacímu prostředí.

Druhou vrstvou ovládacích prvků je použití sady objektů zásad skupiny, které brání kopírování a vkládání přes vzdálenou plochu. Zásady sítě je možné implementovat tak, aby nepovolily odchozí služby z prostředí, jako jsou služby FTP a RDP, mimo prostředí. Směrování definované uživatelem může vynutit veškerý síťový provoz Azure zpět do místního prostředí, ale směrování nemohlo zohlednit všechny adresy URL, které by mohly umožnit nahrávání dat, pokud není řízen proxy serverem pro prohledávání obsahu a relací. Veřejné IP adresy je možné omezit ve virtuální síti podporující DevTest Labs, aby nepovolovaly přemostění externího síťového prostředku.

V konečném důsledku je potřeba použít stejný typ omezení v celé organizaci, což by také muselo zohlednit všechny možné metody vyměnitelných médií nebo externích adres URL, které by mohly přijmout příspěvek obsahu. Pokud chcete zkontrolovat a implementovat zásady zabezpečení, obraťte se na svého odborníka na zabezpečení. Další doporučení najdete v tématu Microsoft Cyber Security.

Migrace a integrace aplikací

Po vytvoření vývojového/testovacího prostředí je potřeba zvážit následující otázky:

• Jak používáte prostředí v rámci projektového týmu?
• Jak zajistíte, že dodržujete požadované zásady organizace a udržujete flexibilitu pro přidání hodnoty aplikace?

Image z Azure Marketplace vs. vlastní image

Azure Marketplace by se mělo používat ve výchozím nastavení, pokud nemáte konkrétní obavy nebo požadavky organizace. Mezi běžné příklady patří;

• Složitá instalace softwaru, která vyžaduje, aby byla aplikace zahrnuta jako součást základní image.
• Instalace a nastavení aplikace může trvat mnoho hodin, což není efektivní využití výpočetního času, který se má přidat na image Azure Marketplace.
• Vývojáři a testeři vyžadují rychlý přístup k virtuálnímu počítači a chtějí minimalizovat dobu nastavení nového virtuálního počítače.
• Dodržování předpisů nebo zákonné podmínky (například zásady zabezpečení), které musí být zavedeny pro všechny počítače.

Pečlivě zvažte použití vlastních imagí. Vlastní image představují větší složitost, protože teď musíte spravovat soubory VHD pro tyto základní základní image. Tyto základní image je také potřeba pravidelně opravovat pomocí aktualizací softwaru. Tyto aktualizace zahrnují nové aktualizace operačního systému (OS) a všechny aktualizace nebo změny konfigurace potřebné pro samotný softwarový balíček.

Vzorec vs. vlastní obrázek

Rozhodovacím faktorem v tomto scénáři jsou obvykle náklady a opakované použití.

Náklady můžete snížit vytvořením vlastní image v následujících případech:

• Obrázek vyžaduje mnoho uživatelů nebo testovacích prostředí.
• Požadovaná image má nad základní imagí hodně softwaru.

Toto řešení znamená, že image vytvoříte jednou. Vlastní image zkracuje dobu instalace virtuálního počítače. Během instalace neúčtují náklady na provoz virtuálního počítače.

Dalším faktorem je frekvence změn softwarového balíčku. Pokud spouštíte denní buildy a vyžadujete, aby byl software na virtuálních počítačích uživatelů, zvažte použití vzorce místo vlastní image.

Vzory pro nastavení konfigurace sítě

Pokud zajistíte, aby virtuální počítače pro vývoj a testování nemohly získat přístup k veřejnému internetu, je potřeba vzít v úvahu dva aspekty – příchozí a odchozí provoz.

Příchozí provoz – Pokud virtuální počítač nemá veřejnou IP adresu, nemůže se k němu připojit internet. Běžným přístupem je nastavení zásad na úrovni předplatného, které žádný uživatel nemůže vytvořit veřejnou IP adresu.

Odchozí provoz – Pokud chcete virtuálním počítačům zabránit v přímém přechodu na veřejný internet a vynutit provoz přes podnikovou bránu firewall, můžete provoz směrovat místně přes Azure ExpressRoute nebo VPN pomocí vynuceného směrování.

Poznámka:

Pokud máte proxy server, který blokuje provoz bez nastavení proxy serveru, nezapomeňte přidat výjimky do účtu úložiště artefaktů testovacího prostředí.

Můžete také použít skupiny zabezpečení sítě pro virtuální počítače nebo podsítě. Tento krok přidá další vrstvu ochrany, která povolí nebo zablokuje provoz.

Nová a stávající virtuální síť

Pokud vaše virtuální počítače potřebují pracovat s existující infrastrukturou, měli byste zvážit použití existující virtuální sítě v prostředí DevTest Labs. Pokud používáte ExpressRoute, minimalizujte počet virtuálních sítí a podsítí, abyste nemuseli fragmentovat adresní prostor IP adres přiřazený vašim předplatným. Zvažte také použití vzoru partnerského vztahu virtuálních sítí zde (model hvězdicové architektury). Tento přístup umožňuje komunikaci virtuální sítě a podsítě mezi předplatnými v dané oblasti.

Každé prostředí DevTest Labs může mít vlastní virtuální síť, ale existuje omezení počtu virtuálních sítí na předplatné. Výchozí částka je 50, i když tento limit lze zvýšit na 100.

Sdílená, veřejná nebo privátní IP adresa

Pokud používáte síť VPN typu site-to-site nebo ExpressRoute, zvažte použití privátních IP adres, aby vaše počítače byly přístupné přes vaši interní síť a nepřístupné přes veřejný internet.

Poznámka:

Vlastníci testovacího prostředí můžou tuto zásadu podsítě změnit, aby nikdo nechtěně vytvářel veřejné IP adresy pro své virtuální počítače. Vlastník předplatného by měl vytvořit zásadu předplatného, která brání vytvoření veřejných IP adres.

Při použití sdílených veřejných IP adres sdílejí virtuální počítače v testovacím prostředí veřejnou IP adresu. Tento přístup může být užitečný v případě, že potřebujete zabránit porušení limitů pro veřejné IP adresy pro dané předplatné.

Limity testovacího prostředí

Existuje několik omezení testovacího prostředí, o které byste měli vědět. Tato omezení jsou popsaná v následujících částech.

Omezení testovacích prostředí na předplatné

Počet testovacích prostředí, která je možné vytvořit pro každé předplatné, neexistuje konkrétní limit. Množství prostředků použitých v rámci předplatného je však omezené. Můžete si přečíst o limitech a kvótách pro předplatná Azure a o tom, jak tyto limity zvýšit.

Omezení virtuálních počítačů na testovací prostředí

Počet virtuálních počítačů, které je možné vytvořit pro každé testovací prostředí, neexistuje žádný konkrétní limit. Použité prostředky (jádra virtuálních počítačů, veřejné IP adresy atd.), které se používají, jsou ale omezené na předplatné. Můžete si přečíst o limitech a kvótách pro předplatná Azure a o tom, jak tyto limity zvýšit.

Omezení počtu virtuálních počítačů na uživatele nebo testovací prostředí

Při zvažování počtu virtuálních počítačů na uživatele nebo testovací prostředí existují tři hlavní aspekty:

• Celkové náklady , které tým může utratit za prostředky v testovacím prostředí Je snadné vytočit mnoho strojů. Pokud chcete řídit náklady, jedním mechanismem je omezení počtu virtuálních počítačů na uživatele nebo testovací prostředí.
• Celkový počet virtuálních počítačů v testovacím prostředí má vliv na dostupné kvóty na úrovni předplatného. Jedním z horních limitů je 800 skupin prostředků na předplatné. DevTest Labs v současné době vytvoří novou skupinu prostředků pro každý virtuální počítač (pokud se nepoužívají sdílené veřejné IP adresy). Pokud v předplatném existuje 10 testovacích prostředí, testovací prostředí by mohla do každého testovacího prostředí umístit přibližně 79 virtuálních počítačů (800 horní limit – 10 skupin prostředků pro samotné 10 testovacích prostředí) = 79 virtuálních počítačů na testovací prostředí.
• Pokud je testovací prostředí připojené k místnímu prostředí přes ExpressRoute (například), jsou pro virtuální síť nebo podsíť k dispozici definované adresní prostory IP adres. Aby se zajistilo, že se virtuální počítače v testovacím prostředí nevytvořily (chyba: nejde získat IP adresu), můžou vlastníci testovacího prostředí zadat maximální počet virtuálních počítačů na testovací prostředí v souladu s dostupným adresními prostory IP adres.

Použití šablon Resource Manageru

Nasaďte šablony Resource Manageru pomocí kroků v azure DevTest Labs pro testovací prostředí. V podstatě zkontrolujete šablony Resource Manageru do úložiště Azure Repos nebo GitHubu a do testovacího prostředí přidáte privátní úložiště.

Tento scénář nemusí být užitečný, pokud k hostování vývojových počítačů používáte DevTest Labs. Tento scénář použijte k vytvoření přípravného prostředí, které je reprezentativní pro produkční prostředí.

Počet virtuálních počítačů na testovací prostředí nebo možnost uživatele omezuje pouze počet počítačů vytvořených v samotném testovacím prostředí. Tato možnost neomezuje vytváření v žádném prostředí pomocí šablon Resource Manageru.