Použití kontejnerů Windows ke kontejnerizaci existujících aplikací
Platí pro: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016
Kontejnery Windows poskytují skvělý mechanismus pro modernizaci tradičních nebo starších aplikací. I když se tento přístup označuje jako "lift and shift to containers", metafora "lift and shift" pochází z přesunu úloh z fyzických na virtuální počítače a používá se při přesunu úloh do cloudu. V současné době je tento termín vhodnější pro migraci virtuálních počítačů. Kontejnery však nejsou virtuální počítače a považovat je za virtuální počítače může vést k nejasnostem ohledně toho, jak je aplikace kontejnerizována, nebo zda ji lze, či zda by měla být kontejnerizována.
Toto téma obsahuje praktické pokyny k přesunu tradičních aplikací do kontejnerů Windows. Cílem je pomoct určit prioritu aplikací, které mají být kontejnerizovány, vysvětlením zvláštních aspektů předem.
Úvod
Co jsou kontejnery Windows a co nejsou
Obecný kontejner termínů odkazuje na technologii, která virtualizuje operační systém (OS). Tato virtualizace poskytuje úroveň izolace od operačního systému samotného serveru nebo hostitele, což zase umožňuje větší flexibilitu pro vývojáře aplikací a provozní týmy.
Kontejnery Windows jsou specifickou implementací technologie kontejnerů. Poskytují instance virtualizovaných operačních systémů, které jsou izolované od operačního systému Windows. Ale celková vzájemná závislost mezi kontejnerem a hostitelem je nemožné: kontejner Windows musí koordinovat svou poptávku po prostředcích a funkcích s operačním systémem Windows. Proč je to důležité? Vzhledem k tomu, že kontejner Windows není celý virtualizovaný server a některé z věcí, které můžete chtít udělat s aplikací, není možné provádět pouze s virtualizovaným operačním systémem.
Další informace o tomto tématu najdete v tématu Containers vs. virtuální počítače. Ale pár dobrých bodů, které vám pomůžou zapamatovat si kontejner a rozdíl mezi virtuálními počítači:
- Kontejnery nejsou řešení ekvivalentní virtualizaci desktopových aplikací. Podporují pouze aplikace na straně serveru, které nevyžadují interaktivní relaci. Protože běží na specializovaných imagích kontejnerů, podporují pouze ty aplikace, které nepotřebují grafický front-end.
- Kontejnery jsou ze své podstaty dočasné. To znamená, že ve výchozím nastavení neexistuje žádný mechanismus pro uložení stavu instance kontejneru. Pokud instance selže, jiná instance zaujme její místo.
Technologie kontejneru začala v Linuxu a Docker se objevil jako standard. Microsoft úzce spolupracoval s Dockerem, aby se zajistilo, že funkce kontejneru budou v systému Windows co nejvíce stejné. Vrozené rozdíly mezi Linuxem a Windows se mohou projevit způsoby, které vypadají jako omezení kontejnerů Windows, když ve skutečnosti jde pouze o rozdíly mezi Linuxem a Windows. Na druhou stranu kontejnery Windows poskytují několik jedinečných implementací, jako je izolace Hyper-V, která se probírá později. Toto téma vám pomůže porozumět těmto rozdílům a tomu, jak je přizpůsobit.
Výhody používání kontejnerů
Podobně jako spouštění několika virtuálních počítačů na jednom fyzickém hostiteli můžete na jednom fyzickém nebo virtuálním hostiteli spustit více kontejnerů. Na rozdíl od virtuálních počítačů ale nemusíte spravovat operační systém pro kontejner, což vám dává flexibilitu soustředit se na vývoj aplikací a základní infrastrukturu. Také to znamená, že můžete izolovat aplikaci tak, aby na ni neměl vliv žádné jiné procesy podporované operačním systémem.
Kontejnery poskytují odlehčenou metodu vytváření a dynamického zastavování prostředků potřebných pro funkční aplikaci. I když je možné vytvářet a nasazovat virtuální počítače s rostoucí poptávkou po aplikacích, je rychlejší používat kontejnery pro horizontální navýšení kapacity. S kontejnery můžete také rychle restartovat v případě chybového ukončení nebo přerušení hardwaru. Kontejnery umožňují vzít jakoukoli aplikaci z vývoje do produkčního prostředí s minimální nebo žádnou změnou kódu, protože obsahují závislosti aplikací tak, aby fungovaly napříč prostředími. Možnost kontejnerizovat existující aplikaci s minimálními změnami kódu, protože integrace Dockeru napříč vývojářskými nástroji Microsoftu je také účinným faktorem při vývoji a údržbě aplikací.
A konečně jednou z nejdůležitějších výhod používání kontejnerů je flexibilita, kterou získáte při vývoji aplikací, protože můžete mít různé verze aplikace spuštěné na stejném hostiteli bez střetu prostředků.
Úplný seznam výhod pro používání kontejnerů pro existující aplikace najdete na stránce dokumentace k Microsoft .NET.
Důležitý koncept úrovně izolace
Kontejnery Windows poskytují izolaci od operačního systému Windows, izolaci, která je výhodná při sestavování, testování a propagaci aplikace do produkčního prostředí. Způsob, jakým se izolace dosahuje, je ale důležité pochopit, když uvažujete o kontejnerizaci aplikace.
Kontejnery Windows nabízejí dva různé režimy izolace modulu runtime: proces a Hyper-V. Kontejnery v obou režimech se vytvářejí a spravují identicky a fungují stejně. Jaké jsou rozdíly a proč byste se měli starat?
V izolaci procesůběží více kontejnerů souběžně na jednom serveru s izolací poskytovanou prostřednictvím jmenných prostorů, řízení prostředků a dalších funkcí. Kontejnery v režimu izolace procesů sdílejí stejné jádro s hostitelem a navzájem. To je zhruba stejné jako způsob, jakým běží kontejnery Linuxu.
V izolaci Hyper-Vna jednom hostiteli běží několik kontejnerů současně, ale kontejnery běží uvnitř vysoce optimalizovaných virtuálních počítačů, přičemž každý z nich efektivně má své vlastní jádro. Přítomnost tohoto virtuálního počítače – v podstatě provozního virtuálního stroje – poskytuje izolaci na úrovni hardwaru mezi jednotlivými kontejnery a hostitelským systémem kontejnerů.
Hyper-V režim izolace je téměř jako hybridní virtuální počítač a kontejner a poskytuje další vrstvu zabezpečení, která je užitečná zejména v případě, že vaše aplikace potřebuje víceklientskou architekturu. Mezi možné kompromisy při používání Hyper-V režimu izolace ale patří:
- Delší doba spuštění kontejneru a pravděpodobně vliv na celkový výkon aplikace.
- Ne všechny nástroje nativně pracují s izolací Hyper-V.
- Azure Kubernetes Service (AKS) ani AKS v Azure Stack HCI v tuto chvíli nepodporují izolaci Hyper-V.
Další informace o tom, jak jsou dva režimy izolace implementovány v tématu Režimy izolace. Při prvním kontejnerizování aplikace si budete muset vybrat mezi těmito dvěma režimy. Naštěstí je velmi snadné změnit z jednoho režimu na jiný později, protože nevyžaduje žádné změny aplikace nebo kontejneru. Mějte ale na paměti, že při kontejnerizaci aplikace je volba mezi těmito dvěma režimy jednou z prvních věcí, kterou budete muset udělat.
Orchestrace kontejnerů
Možnost spouštět více kontejnerů na jednom nebo několika hostitelích bez obav o správu operačního systému poskytuje velkou flexibilitu a pomáhá vám při přechodu k architektuře založené na mikroslužbách. Jedním z kompromisů pro tuto flexibilitu je ale to, že prostředí založené na kontejnerech a mikroslužbách se může rychle rozrůst do mnoha pohyblivých částí – příliš mnoho na to, aby se dalo sledovat. Správa vyrovnávání zatížení, vysoká dostupnost, plánování kontejnerů, správa prostředků a mnoho dalšího je naštěstí rolí orchestrátoru kontejnerů.
Orchestrátory jsou pravděpodobně nesprávně pojmenovány; Jsou spíše jako dirigenti orchestru, kteří koordinují činnost více kontejnerů, aby hudba zůstala hrát. V tom smyslu zpracovávají plánování a přidělování prostředků pro kontejnery podobným způsobem jako fungování operačního systému. Při přechodu na kontejnerizaci aplikací si tedy budete muset vybrat mezi orchestrátory, které podporují kontejnery Windows. Mezi nejběžnější patří Kubernetes a Docker Swarm.
Co nejde přesunout do kontejnerů Windows
Když zvažujete, jestli je možné aplikaci kontejnerizovat nebo ne, je pravděpodobně nejjednodušší začít se seznamem faktorů, které jako možnost zcela vyloučí kontejnery Windows.
Následující tabulka shrnuje typy aplikací, které nejde přesunout do kontejnerů Windows, a proč ne. Důvody jsou podrobněji vysvětleny v pododdílech za tabulkou. Pochopení důvodů těchto omezení vám může poskytnout jasnější představu o tom, jaké kontejnery skutečně jsou, včetně toho, jak se liší od virtuálních počítačů. To vám zase pomůže lépe posoudit možnosti kontejnerů Windows, které můžete využít s existujícími aplikacemi, které můžete kontejnerizovat.
Poznámka: Následující seznam není úplný seznam. Místo toho se jedná o kompilaci aplikací, které Microsoft zaznamenal, že se zákazníci snaží kontejnerizovat.
| Aplikace nebo funkce nejsou podporovány. | Proč se nepodporuje | Můžeš to obejít? |
|---|---|---|
| Aplikace vyžadující desktopovou verzi | Kontejnery nepodporují grafické uživatelské rozhraní (GUI) | Pokud aplikace k instalaci vyžaduje jenom grafické uživatelské rozhraní, může být jeho změna na bezobslužnou instalaci řešením. |
| Aplikace používající protokol RDP (Remote Desktop Protocol) | Protokol RDP je určený pro interaktivní relace, takže zde platí i výše uvedený princip. | Možná budete moct používat Windows Admin Center (WAC) nebo Vzdálený PowerShell jako alternativu pro vzdálenou správu. |
| Stavové aplikace | Kontejnery jsou dočasné | Ano, některé aplikace můžou vyžadovat minimální změnu, takže do kontejneru neukládají data ani stav. |
| Databázové aplikace | Kontejnery jsou dočasné | Ano, některé aplikace můžou vyžadovat minimální změnu, takže do kontejneru neukládají data ani stav. |
| Active Directory | Návrh a účel služby Active Directory brání spuštění v kontejneru. | Ne. Aplikace, které jsou závislé na službě Active Directory, ale můžou používat účty skupinových spravovaných služeb (gMSA). Další informace o gMSA najdete níže. |
| Starší verze Windows Serveru | Podporuje se jenom Windows Server 2016 nebo novější. | Ne. Kompatibilita aplikací ale může být možností – většina Windows Serveru 2008/R2 a starších aplikací běží na novějších verzích Windows Serveru. |
| Aplikace využívající rozhraní .NET Framework verze 2.0 nebo starší | Pro podporu rozhraní .NET Framework se vyžadují konkrétní image kontejneru a podporují se pouze novější verze. | Verze starší než 2.0 nejsou podporované vůbec, ale pro obrazy kontejnerů vyžadované pro novější verze viz níže. |
| Aplikace využívající jiné architektury třetích stran | Společnost Microsoft konkrétně necertifikuje ani nepodporuje použití architektur jiných společností než Microsoft v kontejnerech Windows. | Obraťte se na dodavatele konkrétní architektury nebo aplikace a najděte zásady podpory pro kontejnery Windows. Další informace najdete níže. |
Podívejme se na všechna tato omezení.
Aplikace vyžadující desktopovou verzi
Kontejnery jsou ideální pro dočasné funkce, které se vyvolávají z jiných aplikací, včetně těch, které mají interakce uživatelů. Nemůžete je ale použít pro aplikace, které mají vlastní gui. To platí i v případě, že samotná aplikace nemá grafické uživatelské rozhraní, ale má instalační program, který spoléhá na grafické uživatelské rozhraní. Obecně platí, že Instalační služba systému Windows se dá vyvolat pomocí PowerShellu, ale pokud vaše aplikace vyžaduje instalaci prostřednictvím grafického uživatelského rozhraní, tento požadavek ho eliminuje jako kandidáta na kontejnerizaci.
Nejedná se o problém se způsobem implementace kontejnerů Windows, ale spíše základní koncept fungování kontejnerů.
Jedná se o jinou věc, pokud aplikace potřebuje GUI API. Rozhraní API jsou podporovaná, i když grafické uživatelské rozhraní obsluhované těmito rozhraními API nejsou. To je podrobněji vysvětleno v tématu Nano Server x Server Core x Server – Která základní image je pro vás ta správná?
Aplikace využívající protokol RDP
Vzhledem k tomu, že celým účelem protokolu RDP (Remote Desktop Protocol) je vytvořit interaktivní vizuální relaci, platí také omezení grafického uživatelského rozhraní. Aplikace používající protokol RDP nemůže být kontejnerizována as-is.
Dobrou alternativou je ale nástroj pro vzdálenou správu, jako je Windows Admin Center. Windows Admin Center můžete použít ke správě hostitelů kontejnerů Windows a samotných kontejnerů, aniž byste do nich museli provádět protokol RDP. Ke správě můžete také otevřít vzdálenou relaci PowerShellu pro hostitele nebo kontejnery.
Stavové aplikace
Aplikace, které potřebují zachovat stavová data, je možné kontejnerizovat pouze v případě, že data potřebná z jedné relace do druhé izolujete a uložíte je do trvalého úložiště. To může vyžadovat nějakou "změna architektury", která může nebo nemusí být triviální, ale pokračování v ní odstraní tuto bariéru kontejnerizace.
Příkladem stavu je webová aplikace, která ukládá obrázky nebo hudební soubory do místní složky. V tradičním prostředí Windows se soubor uloží na disk v okamžiku, kdy operace zápisu skončí, takže pokud instance (v tomto případě virtuální počítač) selže, jednoduše ho vrátíte zpět a soubor tam zůstane. Naproti tomu pokud instance kontejneru provádějící operaci zápisu selže, nová instance kontejneru nebude tento soubor obsahovat. Z tohoto důvodu byste měli zvážit použití trvalého úložiště, aby všechny instance kontejnerů mohly ukládat stavová data nebo soubory do centralizovaného, odolného umístění. Tento typ změny architektury nevyžaduje změnu kódu aplikace, pouze typ úložiště používané instancí Systému Windows. Další informace najdete v dokumentaci o úložišti pro kontejnery Windows.
To ale přináší další související téma...
Databázové aplikace
Obecně platí, že databázové aplikace nejsou ideálními kandidáty pro kontejnerizaci. I když můžete databázi spustit uvnitř kontejneru, kontejnerizace existující databáze není obvykle ideální ze dvou důvodů.
Za prvé, výkon potřebný pro databázi může vyžadovat celé hardwarové prostředky dostupné pro hostitele – což snižuje výhodu konsolidace. Za druhé, několik instancí jedné databázové vrstvy potřebuje koordinaci pro své operace zápisu. Orchestrace kontejnerů to může vyřešit, ale u existujících databází může být orchestrace režijní náklady. Většina databází, jako je Microsoft SQL Server, má integrovaný mechanismus vyrovnávání zatížení a vysokou dostupnost.
Role infrastruktury na Windows Serveru
Role infrastruktury Windows Serveru primárně zpracovávají funkce blíže operačnímu systému (například AD, DHCP a Souborový server). Proto nejsou dostupné pro běžící kontejnery. Proto budou aplikace, které tyto role potřebují, vždy obtížné kontejnerizovat.
Existují některé nejasné oblasti. Některé funkce, jako je DNS, můžou například fungovat na kontejnerech Windows, i když ve skutečnosti nejsou určené k použití v kontejnerech. Jiné role infrastruktury se jednoduše odeberou ze základní image kontejneru a nedají se nainstalovat, například Active Directory, DHCP a další.
Active Directory (AD)
Služba Active Directory byla vydána před více než dvaceti lety na Windows 2000 Serveru. Používá mechanismus, ve kterém je každé zařízení nebo uživatel reprezentován objektem uloženým v databázi. Tento vztah je úzce propojený a objekty se uchovávají v databázi, i když se skutečný uživatel nebo zařízení už nepoužívají. Tento přístup pro službu Active Directory je v přímém rozporu s pomíjivou povahou kontejnerů, u kterých se očekává, že mají být krátkodobí nebo odstraněni po vypnutí. Udržování vztahu 1:1 se službou Active Directory není pro tyto scénáře ideální.
Z tohoto důvodu nemohou být kontejnery Windows připojené k doméně. V důsledku toho nemůžete v kontejnerech Windows spouštět službu Active Directory Domain Services jako roli infrastruktury. PowerShell modul pro správu řadičů domény můžete spustit vzdáleně uvnitř kontejneru Windows.
Pro aplikace spuštěné v kontejnerech Windows, které jsou závislé na službě Active Directory, použijte účty spravované služby skupiny (gMSA), které budou podrobněji vysvětleny.
Aplikace využívající rozhraní .NET Framework verze 2.0 nebo starší
Pokud vaše aplikace vyžaduje .NET, vaše schopnost kontejnerizovat zcela závisí na verzi rozhraní .NET Framework, která používá. Všechny verze před rozhraním .NET Framework 2.0 se vůbec nepodporují; vyšší verze vyžadují použití konkrétních obrázků, jak je popsáno později.
Aplikace využívající architektury třetích stran (jiné společnosti než Microsoft)
Obecně řečeno, Společnost Microsoft nemůže certifikovat architektury nebo aplikace třetích stran nebo je podporovat v kontejnerech Windows – nebo fyzických a virtuálních počítačích. Microsoft ale provádí vlastní interní testování použitelnosti několika architektur a nástrojů třetích stran, včetně Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat a mnoha dalších.
V případě jakékoli architektury nebo softwaru třetích stran ověřte jeho možnosti podpory v kontejnerech Windows u dodavatele, který ho dodává.
Ideální kandidáti pro kontejnerizaci
Teď, když jsme zvážili pevná omezení kontejnerizace aplikací, je jednodušší zjistit, jaké typy aplikací se snadněji hodí pro kontejnery Windows. Ideální kandidáti pro kontejnery Windows a všechny zvláštní aspekty pro kontejnerizaci jsou v následující tabulce.
| Typ aplikace | Proč jsou to dobří kandidáti | Zvláštní aspekty |
|---|---|---|
| Konzolové aplikace | Bez omezení grafického uživatelského rozhraní jsou konzolové aplikace ideálními kandidáty pro kontejnery. | V závislosti na potřebách aplikace použijte příslušnou základní image kontejneru. |
| Služby pro Windows | Vzhledem k tomu, že se jedná o procesy na pozadí, které nevyžadují žádnou přímou interakci uživatelů | V závislosti na potřebách aplikace použijte příslušnou základní image kontejneru. Musíte vytvořit proces popředí, aby kontejnerizované procesy na pozadí zůstaly spuštěné. Viz část o službách na pozadí níže. |
| Služby Wcf (Windows Communication Foundation) | Vzhledem k tomu, že se jedná o aplikace orientované na služby, které běží také na pozadí | V závislosti na potřebách aplikace použijte příslušnou základní image kontejneru. Možná budete muset vytvořit proces na popředí, aby běžel kontejnerizovaný proces na pozadí. Viz část o službách na pozadí níže. |
| Webové aplikace | Webové aplikace jsou v podstatě službami na pozadí, které naslouchají určitému portu, a proto jsou skvělými kandidáty na kontejnerizaci, protože využívají škálovatelnost nabízenou kontejnery. | V závislosti na potřebách aplikace použijte příslušnou základní image kontejneru. |
Poznámka: I tyto ideální kandidáty pro kontejnerizaci můžou záviset na základních funkcích a součástech Windows, které je potřeba zpracovat jinak v kontejnerech Windows. Další část, která se zaměřuje na další podrobnosti o těchto praktických aspektech, vás lépe připraví na využití funkcí kontejnerů Windows.
Praktické aspekty aplikací, které je možné kontejnerizovat
Projekty renovace aplikací obvykle berou v úvahu, zda je možné konkrétní aplikaci kontejnerizovat prostřednictvím perspektivy obchodní funkce aplikace. Obchodní funkce ale nejsou faktorem, který určuje, jestli je technicky možné. Důležitá je architektura aplikace, tj. na jakých technických komponentech závisí. Proto neexistuje žádná jednoduchá odpověď na otázku, jako je "Můžu kontejnerizovat svou aplikaci personálního oddělení?", protože to není to, co aplikace dělá, jak (a jaké komponenty a služby Systému Windows používá), což dělá rozdíl.
Je to důležitý rozdíl, protože pokud vaše aplikace není již od začátku postavena s architekturou mikroslužeb, bude pravděpodobně obtížnější ji kontejnerizovat. Když budete pokračovat v kontejnerizaci, některé funkce můžou potřebovat speciální zpracování. Některé můžou být způsobené používáním základních komponent a architektur pro Windows, které nejsou podporovány v kontejnerech Windows. Jiné, jako je protokolování událostí a monitorování, jsou způsobeny zásadními rozdíly mezi Linuxem a Windows, které se zjeví jenom v případě, že aplikaci kontejnerizujete. I další, například naplánované úlohy a služby na pozadí, musí být srozumitelné z pohledu, že kontejner není virtuální počítač, ale dočasný, a proto potřebuje zvláštní zpracování.
V následující tabulce najdete stručný přehled komponent a funkcí aplikací, které při vytváření kontejnerů potřebují zvláštní pozornost. Následující pododdíly poskytují podrobnější informace, včetně příkladů, které ilustrují techniky pro zpracování jednotlivých scénářů. I když následující seznam popisuje scénáře podporované v kontejnerech Windows, tyto scénáře stále musí respektovat pokyny z předchozí kapitoly. Zatímco se podporují například služby na pozadí, nepodporuje se spuštění služby na pozadí v rozhraní .NET Framework 1.1.
| Funkce nebo komponenta Systému Windows vyžadující zvláštní zpracování | Důvod |
|---|---|
| Microsoft Messaging Queueing (MSMQ) | MSMQ pochází dlouho před kontejnery a ne všechny jeho modely nasazení pro fronty zpráv jsou kompatibilní s architekturou kontejnerů. |
| Microsoft Distributed Transaction Coordinator (MSDTC) | Řešení názvů mezi MSDTC a kontejnerem vyžaduje zvláštní pozornost. |
| IIS | Služba IIS je stejná jako ve virtuálním počítači, ale při jejím spuštění v prostředí kontejneru existují důležité aspekty, jako je správa certifikátů, připojovací řetězce databáze a další. |
| Naplánované úkoly | Kontejnery Windows můžou spouštět naplánované úlohy stejně jako všechny instance Windows. Možná ale budete muset spustit úlohu popředí, aby se instance kontejneru udržela v chodu. V závislosti na aplikaci můžete chtít zvážit přístup řízený událostmi. |
| Služby na pozadí | Vzhledem k tomu, že kontejnery běží jako dočasné procesy, budete potřebovat další zpracování, abyste zajistili, že kontejner zůstane v provozu. |
| .NET Framework a .NET (dříve .Net Core) | Nezapomeňte použít správný obrázek, abyste zajistili kompatibilitu, jak je vysvětleno v pododdílu níže. |
Další podpůrné komponenty
| Komponenta vyžadující speciální zpracování | Důvod | Alternativní přístup |
|---|---|---|
| Protokolování a monitorování událostí | Vzhledem k tomu, že způsob, jakým Systém Windows zapisuje události a protokoly, se ze své podstaty liší od linuxového stdoutu | Pomocí nového nástroje Sledování protokolů můžete normalizovat data a kombinovat je z Linuxu i Windows. |
| Zabezpečení kontejnerů Windows | I když mnoho postupů zabezpečení zůstává stejné, kontejnery vyžadují další bezpečnostní opatření. | Použijte účelový nástroj pro kontrolu registrů a obrázků – další podrobnosti najdete později. |
| Zálohování kontejnerů Windows | Kontejnery by v něm neměly mít data ani stav. | Zálohujte všechna trvalá úložiště používaná kontejnery a image kontejnerů. |
Součásti a funkce systému Windows
Teď se podíváme na podrobnosti o aplikacích a komponentách, které je možné kontejnerizovat, ale vyžadují další zpracování.
MSMQ
Pokud je vaše aplikace závislá na MSMQ, jestli ji můžete kontejnerizovat, závisí na scénáři nasazení MSMQ. MSMQ obsahuje několik možností nasazení. Faktory privátních vs. veřejných front, transakčních nebo ne a typ ověřování tvoří matici scénářů, které msMQ původně navrhla pro podporu. Ne všechny tyto můžou být snadno přesunuty do kontejnerů Windows. Následující tabulka uvádí podporované scénáře:
| Rozsah | Transakční? | Umístění fronty | Typ ověřování | Odeslat a přijmout? |
|---|---|---|---|---|
| Soukromý | Ano | Stejný kontejner (jeden kontejner) | Anonymní | Ano |
| Soukromý | Ano | Trvalý svazek | Anonymní | Ano |
| Soukromý | Ano | Řadič domény | Anonymní | Ano |
| Soukromý | Ano | Jeden hostitel (dva kontejnery) | Anonymní | Ano |
| Veřejný | Ne | Dva hostitelé | Anonymní | Ano |
| Veřejný | Ano | Dva hostitelé | Anonymní | Ano |
Několik poznámek k těmto podporovaným scénářům, které byly ověřeny interními vývojářskými týmy Microsoftu:
- Režim izolace: Režim zpracování i režim Hyper-V pro izolaci fungují s výše uvedenými scénáři.
- Minimální image operačního systému a kontejneru: Minimální verze operačního systému doporučená pro použití s MSMQ je Windows Server 2019.
- Trvalé svazky: Výše uvedené scénáře byly ověřeny během provozu MSMQ na Azure Kubernetes Service (AKS) s využitím souborů Azure pro perzistentní úložiště.
Když tyto aspekty spojíte s tabulkou uvedenou výše, uvidíte, že jediný scénář, který není podporovaný, je pro fronty, které vyžadují ověřování pomocí služby Active Directory. Integrace účtů gMSA (skupinových účtů spravované služby) s MSMQ se v současné době nepodporuje, protože MSMQ má závislosti na službě Active Directory, které ještě nejsou zavedené.
Alternativně místo MSMQ použijte Azure Service Bus. Azure Service Bus je plně spravovaný podnikový zprostředkovatel zpráv s frontami zpráv a tématy pro publikování a odběr (v prostoru názvů). Přechod z MSMQ na Azure Service Bus vyžaduje změny kódu a změnu architektury aplikací, ale poskytne vám flexibilitu přechodu na moderní platformu.
MSDTC
Microsoft Distributed Transaction Coordinator (MSDTC) je ve starších aplikacích Windows ve velkých podnicích silně používán. MSDTC lze nainstalovat v kontejnerech Windows, ale existují určité scénáře, které nefungují a nelze je reprodukovat v kontejnerech Windows.
- Při vytváření kontejneru nezapomeňte předat parametr --name do příkazu docker run. Tento parametr názvu umožňuje kontejnerům komunikovat přes síť Dockeru. Pokud používáte gMSA, musí se název shodovat s názvem hostitele, který se musí shodovat s názvem účtu gMSA.
- Tady je příklad příkazu run s gMSA:
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
- Kontejnery musí být schopny se vzájemně rozpoznávat pomocí názvu NETBIOS. Pokud s tímto nastane jakýkoli problém, nejlepším způsobem, jak jej vyřešit, je přidat jméno a IP adresu kontejnerů do hostitelských souborů druhého.
- Identifikátor uuid pro msdtc v obou kontejnerech musí být jedinečný. Identifikátor uuid najdete spuštěním rutiny Get-Dtc v PowerShellu v kontejnerech. Pokud nejsou jedinečné, jedním ze způsobů, jak je vyřešit, je odinstalace a přeinstalace msdtc na jednom z kontejnerů. Tyto příkazy PowerShelll lze použít – uninstall-dtc, install-dtc.
- MsDTC se v současné době ve službách Azure Kubernetes nepodporuje. Pokud máte konkrétní potřebu spustit MSDTC v AKS, dejte týmu kontejnerů Windows vědět otevřením problému v úložišti kontejnerů Windows na GitHubu.
Jak služba IIS funguje v kontejneru a virtuálním počítači
Služba IIS funguje stejně jako v kontejneru Windows jako ve virtuálním počítači. Existují však některé aspekty spuštění instance služby IIS, které by se měly zvážit při spuštění v prostředí kontejneru:
- Trvalé úložiště pro místní data: Složky, na kterých aplikace zapisuje/čte soubory do/z, představují skvělý příklad něčeho, co byste měli na virtuálním počítači pro instanci služby IIS zachovat. U kontejnerů nechcete, aby se do kontejneru zapisují žádná data přímo. Kontejnery používají pro místní úložiště "pomocné místo" a když se nový kontejner objeví pro stejnou aplikaci, nemá k této oblasti přístup z předchozího kontejneru. Z tohoto důvodu používejte trvalé úložiště pro data, která musí být přístupná pro webovou aplikaci, aby každá instance kontejneru měla přístup k danému úložišti.
- Certifikáty: I když můžete mít místní certifikáty v instancích kontejnerů, vyhněte se tomu, protože pokud je potřeba aktualizovat certifikát, musíte znovu sestavit image kontejneru. Alternativně můžete použít orchestrátor kontejneru s řízením vstupu. Ingress kontrolery mohou používat síťové zásady a také spravovat certifikáty pro webové stránky hostované za ním. Nevýhodou je oddělení správy životního cyklu certifikátů od správy webu.
- Připojovací řetězce databáze: Pro tradiční nasazení služby IIS můžete předat připojovací řetězec databáze jako součást nasazení aplikace. I když kontejnery Windows umožňují postupovat podle tohoto modelu, můžete zvážit oddělení připojovacího řetězce databáze od kontejneru na centralizovanou konfiguraci poskytovanou orchestrátorem kontejnerů, ze kterého může aplikace číst. To umožňuje spravovat a aktualizovat připojovací řetězec databáze nezávisle na aplikaci. Pokud se databáze změní (například v případě metody Lift and Shift do cloudu), můžete snadno změnit připojovací řetězec bez opětovného sestavení image kontejneru. Tento přístup také umožňuje uchovávat tajné kódy (například uživatelské jméno a heslo pro připojení k databázi) v úložišti tajných kódů.
- Horizontální automatické škálování: Při nárůstu zatížení mají výpočetní systémy tendenci zpomalit vnímaný výkon při pokusu o zpracování souběžných požadavků. Obecně existují dva způsoby, jak se vyhnout dopadu na výkon – vertikální nebo horizontální škálování. Vertikální škálování zvyšuje prostředky dostupné pro stávající výpočetní instance (více procesoru, paměti atd.). Horizontální škálování zvyšuje počet instancí podporujících požadavky (více fyzických hostitelů nebo virtuálních počítačů nebo kontejnerů). U webových vrstev, jako je služba IIS, je horizontální škálování efektivnější než vertikální, ale místní prostředí můžou narazit na omezení prostředků a problémy s vyrovnáváním zatížení. U cloudových prostředí je horizontální škálování mnohem jednodušší, protože prostředky jsou snadno dostupné (za příplatek) a poskytovatel cloudu obvykle navrhuje svůj mechanismus vyrovnávání zatížení s ohledem na horizontální škálování. Kontejnery Windows můžou využívat horizontální škálování služby IIS, ale dočasný aspekt kontejnerů hraje důležitou roli. Je nezbytné, aby kontejnery měly stejnou konfiguraci a že se neukládá žádný stav nebo data, aby bylo možné vertikálně navýšit nebo snížit počet instancí podporujících vaši webovou aplikaci.
Naplánované úkoly
Naplánované úlohy se používají k volání programu, služby nebo skriptu v libovolném okamžiku v prostředí windows. Tradičně máte instanci Windows spuštěnou nepřetržitě a při splnění spouštěče se úloha spustí. To je možné u kontejnerů Windows a kromě toho, že potřebujete nakonfigurovat a spravovat naplánované úlohy přes Azure PowerShell, fungují úplně stejně.
S přístupem k mikroslužbám ale máte několik možností, jak zabránit tomu, aby kontejner běžel a čekal na trigger:
- K uložení kódu a definování triggeru pro danou aplikaci použijte model PaaS řízený událostmi (platforma jako služba), jako je funkce Azure Functions. Azure Functions dokonce podporuje spouštění i imagí kontejnerů Windows při splnění triggeru.
- Používejte kontejnery Windows ve spojení s orchestrátorem kontejnerů. Kontejner se může spustit pouze při splnění triggeru a zavolání z jiných částí aplikace. V tomto případě orchestrátor kontejneru zpracuje plánování a spuštění aplikace.
- Nakonec ponechte kontejner Windows spuštěný a spusťte naplánovanou úlohu. K zachování spuštěného kontejneru budete potřebovat službu popředí (například Monitorování služeb).
Služby na pozadí
I když jsou kontejnery obecně určené pro dočasné procesy, můžete kontejnerizovat aplikaci běžící na pozadí, pokud vytvoříte hlavní proces, který ji spustí a bude ji udržovat v chodu.
Skvělým příkladem je ServiceMonitor, což je spustitelný soubor systému Windows navržený jako proces vstupního bodu při spouštění služby IIS v kontejnerech. Přestože byl vytvořen pro službu IIS, nástroj ServiceMonitor nabízí model, který lze použít také k monitorování jiných služeb s určitými omezeními.
Další informace o službě ServiceMonitor najdete v dokumentaci na GitHubu.
.NET Framework a .NET
Kontejnery Windows podporují rozhraní .NET Framework i .NET (dříve .NET Core). Tým .NET vytváří své vlastní oficiální obrazy pro oba rámce na základních obrazech kontejneru Windows. Volba vhodné image je důležitá pro zajištění kompatibility. Tým .NET poskytuje image rozhraní .NET Framework na základní image kontejneru Server Core a image .NET na základních image kontejneru Server Core a Nano Server. Jádro serveru má větší sadu rozhraní API než Nano Server, což umožňuje větší kompatibilitu, ale také větší velikost image. Nano Server má výrazně zmenšený rozsah rozhraní API, ale mnohem menší velikost obrazu.
V některých případech možná budete potřebovat vytvořit vlastní obraz rozhraní .NET Framework nebo .NET na základě základních obrazů kontejnerů Windows nebo Server. To může být nezbytné v případě, že vaše aplikace má nejen závislost architektury, ale i závislost operačního systému. Pomocí testování aplikace s konkrétní základní imagí kontejneru budete moct detekovat všechny takové závislosti.
Například image základního kontejneru Serveru Core a Nano Serveru mají k dispozici pouze jedno písmo, aby se zmenšila velikost obrázku. Pokud vaše aplikace vyžaduje jiné písmo, budete muset buď nainstalovat toto písmo, nebo použít image Serveru nebo Windows, které mají větší sadu rozhraní API a zahrnout všechna výchozí písma Windows. Z hlediska kompatibility to umožňuje prakticky jakoukoli aplikaci (pokud respektují povahu kontejnerů, například bez grafického uživatelského rozhraní), kontejnerizovat. Na nevýhodě budou mnohem větší, což může ovlivnit výkon.
Při ověřování, jestli aplikace, která se má kontejnerizovat, funguje v kontejnerech Windows, microsoft doporučuje následující:
| Pro tuto architekturu | Nejprve otestujte s tímto obrazem kontejneru. | Použijte tento obraz kontejneru jako záložní možnost, pokud první nefunguje. | Základní obraz |
|---|---|---|---|
| .NET Framework verze 2.X a 3.X | .NET Framework 4.x | .NET Framework 3.5 | Jádro Windows Serveru |
| Verze rozhraní .NET Framework 4.x | .NET Framework 4.x | Sestavení image kontejneru rozhraní .NET Framework pomocí imagí serveru nebo Windows | Jádro Windows Serveru |
| .NET 6 nebo 7 | .NET 6 nebo 7, respektive | Sestavení image kontejneru .NET pomocí základních imagí Windows nebo Serveru | Windows Nano Server nebo jádro serveru |
Další podpůrné komponenty
Níže uvedené komponenty a témata poskytují další pokyny pro položky, které spolu s kontejnery Windows poskytují lepší přehlednost.
Protokolování událostí
Windows a Linux používají různé metody k ukládání a prezentování protokolů a událostí svým uživatelům. Systém Windows tradičně používal formát EVT, který lze zobrazit strukturovaným způsobem v Prohlížeči událostí. Naproti tomu Linux nabízí zjednodušený přístup se standardním výstupem (stdout), na který spoléhají jiné nástroje, jako je Docker.
Docker měl vždy mechanismus pro extrakci protokolů z linuxových kontejnerů. Pomocí příkazu "docker logs" s výchozí konfigurací stdout přenáší Docker aplikační protokoly z kontejneru bez nutnosti jeho otevření v interaktivním režimu. Dokud ale nespustíte nástroj Sledování protokolů, stejná technika ve Windows nefungovala.
Nástroj Sledování protokolů zobrazí protokoly Windows ve formátu stdout, aby ostatní nástroje, jako je Docker, mohly shromáždit informace potřebné k jeho zobrazení. Mezi další výhody použití Log Monitoru patří:
- Schopnost filtrovat, které typy událostí nebo protokolů chcete zpřístupnit pro stdout. Protokol aplikace můžete například filtrovat na zprávy "chyba" a "upozornění" pouze pokud vás nezajímají události "informace".
- Možnost výběru z protokolů událostí, vlastních souborů protokolů nebo trasování událostí pro Windows (ETW). To je užitečné zejména v případě, že aplikace píše na jiný zdroj protokolu. Příkladem je protokol služby IIS umístěný ve složce C:\inetpub.
- Skutečnost, že Log Monitor způsobuje, že se kontejnery Windows chovají podobně jako kontejnery Linuxu, znamená, že nástroje, které hledají stdout a pracují s funkcemi modulu runtime kontejneru, fungují podle očekávání. Pokud například přejdete z Dockeru na ContainerD jako na runtime kontejneru, logy by měly být stále viditelné na hostiteli kontejneru, například pomocí "crictl logs".
Další informace o nástroji Sledování protokolů najdete v tomto blogovém příspěvku.
Zabezpečení kontejnerů Windows
Kontejnery Windows jsou založené na stejné bázi jako instance Windows běžící na fyzických nebo virtuálních počítačích. Vysvětlení specifik způsobu implementace kontejnerů, zejména jejich povahy sdíleného jádra, pomáhá zabezpečit kontejnerizovanou aplikaci:
- Sdílené komponenty. Kontejnery Windows sdílejí některé součásti hostitele pro účely zabezpečení. Součástí je Windows Firewall, Windows Defender (Antivirová ochrana) a omezení přístupu k dalším prostředkům. Tyto komponenty v kontejneru nemusíte konfigurovat přímo, protože hostitel kontejneru provádí potřebné úpravy na základě úloh kontejneru. Pokud například kontejner vytvoří webový požadavek, hostitel kontejneru přesměruje potřebný provoz přes bránu firewall, aby mohl přistupovat k webu.
- Režim izolace. Jak bylo diskutováno, kontejnery Windows je možné nasadit v režimu zpracování nebo v režimu izolace Hyper-V, přičemž Hyper-V poskytuje nejbezpečnější izolaci. V izolaci procesů kontejner sdílí své jádro, systém souborů a registr s hostitelem, což umožňuje, aby proces se zvýšenými oprávněními (správce) komunikoval s procesy a službami kontejneru. Volba správného režimu izolace pro vaši aplikaci je důležitá k zajištění vhodného modelu zabezpečení.
- Aktualizace Windows. Protože v kontejnerech Windows není zásobník údržby, nedostávají kontejnery Windows aktualizace, jako běžné instance Windows. Místo toho je potřeba znovu sestavit kontejnery Windows pomocí nejnovější dostupné základní image kontejneru. Zákazníci můžou pro tento účel využívat kanály DevOps. Microsoft každý měsíc aktualizuje základní obrazy kontejnerů pro všechny své oficiální obrazy v souladu s harmonogramem Patch Tuesday.
- Uživatelský účet kontejneru. Ve výchozím nastavení běží aplikace uvnitř kontejnerů Windows se zvýšenými oprávněními v uživatelském účtu ContainerAdmin. To je užitečné pro instalaci a konfiguraci nezbytných komponent v imagi kontejneru. Při spuštění aplikace, která nevyžaduje zvýšená oprávnění, byste ale měli zvážit změnu uživatelského účtu na ContainerUser. Pro konkrétní scénáře můžete také vytvořit nový účet s příslušnými oprávněními.
- Kontrola obrazů a běhového prostředí Kontejnery vyžadují, aby obrazy v úložištích a instance kontejnerů byly zabezpečené. Microsoft doporučuje používat Microsoft Defender for Containers ke skenování obrazů a ke skenování za běhu. Defender for Containers podporuje kontejnery Windows pro posouzení zranitelností s využitím kontroly registru a ochranu za běhu s detekcí hrozeb.
Další informace o výše uvedených tématech lze nalézt na stránce dokumentace Windows kontejnerů .
Zálohování kontejnerů Windows
Při používání kontejnerů je potřeba myslet na zálohování odlišně. Jak už jsme si řekli dříve, kontejner by se neměl používat k ukládání stavu ani dat vzhledem k jeho dočasné povaze. Pokud oddělíte stav a data od instance kontejneru, vaše obavy o zálohování nebudou součástí běhového prostředí instance kontejneru, které lze nahradit novou instancí, ke které bude mít stále přístup veškeré potřebné trvalé úložiště.
Za zálohování komponent však stále zodpovídáte; včetně aplikace, image kontejneru a dockerfile, který se používá k sestavení image kontejneru. Většinu těchto operací zpracovává platforma, na které spouštíte produkční a vývojové úlohy. Při přijetí přístupu DevOps zvažte nejběžnější případy:
- Aplikace: Vaše aplikace se pravděpodobně nachází ve zdrojovém úložišti, jako je GitHub nebo Azure DevOps. Tato úložiště poskytují správu verzí, která umožňuje vrátit se zpět ke konkrétní verzi aplikace. Pokud vlastníte zdrojové úložiště, nezapomeňte postupovat podle doporučení pro zálohování a správu.
- Image kontejneru: V produkčních prostředích by se image kontejneru měla nacházet v centralizované úložišti imagí, jako je Azure Container Registry (ACR). Image kontejneru můžete odeslat do služby ACR, aby byly k dispozici pro ostatní hostitele, aby je mohli vyžádat. ACR zpracovává dostupnost imagí kontejnerů a slouží jako možnost zálohování– mějte ale na paměti, že zatímco ACR zpracovává dostupnost image, nezabrání odstranění nebo přepsání image. V případě jakéhokoli jiného místního nebo místního úložiště imagí postupujte podle doporučení dodavatele pro zálohování existujících registrů.
- Dockerfile: Soubory Dockerfile vytvářejí nové image kontejneru a obvykle se ukládají společně se zdrojem aplikace. Vzhledem k tomu, že soubor dockerfile pravděpodobně nebyl vytvořen s aplikací, zejména pokud se jedná o existující aplikaci, která se kontejnerizuje, zodpovídáte za zajištění, že soubor Dockerfile je uložený v zabezpečeném a zálohovaném umístění. Měli byste také zajistit, aby se zálohovaly všechny ostatní prostředky, které vaše aplikace potřebuje pro práci v kontejneru; Například: soubory YAML a JSON pro Kubernetes, Docker Swarm a šablony Azure ARM se řídí stejnými pokyny jako výše.
Plánování procesu "lift and shift"
Po posouzení připravenosti aplikace na kontejnerizaci použijte následující obecné pokyny k plánování procesu:
- Určete základní image operačního systému Windows, kterou potřebujete: Windows Server Core, Nano Server, Windowsnebo Server image.
- Určete typ režimu izolace kontejneru: vyberte mezi režimem izolace procesů nebo režimem izolace Hyper-V. Poznámka: V současné době AKS a AKS ve službě Azure Stack HCI podporují pouze izolované kontejnery procesů. V budoucí verzi budou AKS i AKS v Azure Stack HCI podporovat také izolované kontejnery Hyper-V. Další informace naleznete v tématu režimy izolace.
- Zvolte správnou verzi Windows Serveru pro vaši aplikaci pro účely kompatibility aplikací. Minimální verze Windows Serveru pro kontejnery je Windows Server 2016, ale Windows Server 2019 a Windows Server 2022 jsou jedinými hostitelskými operačními systémy kontejneru podporovanými v AKS a AKS v Azure Stack HCI.
- Ujistěte se, že jsou pro prostředí kontejneru zavedeny zásady zabezpečení vaší společnosti. To zahrnuje přizpůsobení se konkrétním požadavkům na kontejnery, jako je kontrola registru a detekce hrozeb.
- Zvažte potřeby vyrovnávání zatížení. Kontejnery se samy nepřesouvají; Orchestrátor můžete místo toho použít k automatickému spuštění nebo zastavení kontejnerů na uzlech clusteru nebo ke správě změn v zatížení a dostupnosti pomocí automatického horizontálního škálování.
- Zvažte potřeby orchestrace. Po kontejnerizaci vaše aplikace pravděpodobně potřebuje automatizovanou správu dostupnou pomocí nástrojů, jako jsou Kubernetes, AKS nebo AKS ve službě Azure Stack HCI. Viz Přehled orchestrace kontejnerů Windows pro úplnou diskusi a průvodce výběrem mezi nástroji.
- Kontejnerizujte aplikaci.
- Odešlete aplikaci do úložiště imagí. To umožní hostitelům kontejnerů stáhnout image v libovolném prostředí, včetně vývoje, testování a produkce.
Azure Migrate může poskytovat proces s asistencí pro zjišťování, posuzování a migraci stávající aplikace pro Windows do služby Azure Kubernetes Service. Další informace najdete na stránce dokumentace ke službě Azure Migrate.