Written by 
- Praktický úvod do Docker a kontejnerů (1) – od instalace po první kontejnery
- Praktický úvod do Docker a kontejnerů (2) – propojování
- Praktický úvod do Docker a kontejnerů (3) – víc najednou aneb něco užitečného s Docker Compose
- Praktický úvod do Docker a kontejnerů (4) – jak z nich získat maximum
- Praktický úvod do Docker a kontejnerů (5) – Docker Machine
- Praktický úvod do Docker a kontejnerů (6) – cluster hostitelů s Docker Swarm
- Praktický úvod do Docker a kontejnerů (7) – scheduler v Docker Swarm
- Praktický úvod do Docker a kontejnerů (8) – váš vlastní registr obrazů
- Praktický úvod do Docker a kontejnerů (9) – multi-host networking
- Praktický úvod do Docker a kontejnerů (10) – Windows kontejnery s Docker API
- Praktický úvod do Docker a kontejnerů (11) – Windows kontejnery s PowerShell
- Praktický úvod do Docker a kontejnerů (12) – Windows Hyper-V kontejner
- Praktický úvod do Docker a kontejnerů (13) – Swarm mode, service, balancing, scaling (v1.12)
Po minulých dvou dílech už si umíme vytvořit Windows kontejner – z Docker CLI i PowerShellu. Dnes se krátce podíváme na specialitu – Hyper-V kontejner.
Kontejnery ve VM
Jsou kontejnery dostatečná izolace? To je velmi obtížná otázka. Faktem je, že kontejner nevidí procesy ostatních, má svoje síťové prostředí (nemůže poslouchat pakety ostatních), nevidí souborový systém ostatních a nemůže neomezeně spotřebovávat CPU a paměť hostitele. Pro řadu z nás bude takové oddělení dostatečné. Nicméně pro úředníka, který jde kontrolovat vaší PCI-DSS nebo HIPPA certifikaci to stačit nemusí. Tam kde pracujete s opravdu citlivými daty možná není prostor přemýšlet o něčem, co je zatím relativně mladé a názory na bezpečnost izolace ještě nejsou plně dospělé. Vzdát se kvůli tomů kontejnerové technologie je ale zbytečné.
Co s tím? Možná nám kompromisně bude stačit kontejnerové oddělení v rámci jedné organizace nebo třídy aplikací. Budeme ale chtít oddělit testovací a produkční prostředí, aplikace pro vnitřní a vnější použití, aplikace s přísně tajnými údaji a ty ostatní, aplikace jednotlivých BU firmy. Můžeme to samozřejmě udělat na úrovni hardwaru, ale proč nevyužít už osvědčené a uznávané izolace na úrovni hypervisoru. Typicky bych situaci řešil použitím OpenStack IaaS a vytvořením tenantů, uvnitř kterých pak poběží cluster Cloud Foundry PaaS (pokud chcete vyvíjet a provozvat cloud native aplikace opravdu jednoduše) nebo cluster Container as a Server řešení (typu Docker Swarm, Kubernetes, Mesos).
Hyper-V kontejner
Microsoft se rozhodl jít kombinaci VM a kontejnerů naproti a zavedl “Hyper-V kontejner”, což je ve skutečnosti jen extrémně jednoduché vytvoření VM a kontejneru současně (a trocha automatické síťařiny). Stačí drobná úprava Docker příkazu…
docker run -it --isolation=hyperv mujimage
nebo PowerShellu…
New-Container -Name kontik -ContainerImageName mujimage -SwitchName "Virtual Switch" -RuntimeType HyperV
… a je to.
Co se přesně stane? Tento příkaz automaticky vytvoří VM, která se stane novým virtuálním hostitelem a teprve uvnitř této VM spustí náš kontejner. Pokud je hlavní hostitel bare metal, tak to ani nebude mít nějaké zásadní dopady na výkon (pokud je ale hostitel třeba virtuální, půjde o nested virtualizaci, což má výrazně negativní dopad na výkon a v tuto chvíli není například u kontejnerů v Azure podporováno).
