В * nix-системах спочатку реалізована багатозадачність і пропонуються засоби, що дозволяють ізолювати і контролювати процеси. Такі технології, як chroot (), що забезпечує ізоляцію на рівні файлової системи, FreeBSD Jail, що обмежує доступ до структур ядра, LXC і OpenVZ, давно відомі і широко використовуються. Але імпульсом в розвитку технології став Docker, що дозволив зручно передавати програми. Тепер подібне добралася і до Windows.
Контейнери в Windows
Сучасні сервери мають надлишкову продуктивністю, і додатки часом не використовують навіть їх частини. В результаті системи якийсь час «простоюють», нагріваючи повітря. Виходом стала віртуалізація, що дозволяє запускати кілька ОС на одному сервері, гарантовано розділяючи їх між собою і виділяючи кожній потрібну кількість ресурсів. Але прогрес не стоїть на місці. Наступний етап - мікросервіси, коли кожна частина програми розгортається окремо, як самодостатній компонент, який легко масштабується під потрібну навантаження і оновлюється. Ізоляція запобігає втручання в роботу мікросервіса з боку інших додатків. З появою проекту Docker. спростити процес упаковки і доставки додатків разом з оточенням, архітектура мікросервісов отримала додатковий поштовх у розвитку.
Контейнери - це інший тип віртуалізації, що надає відокремлену середу для виконання додатків, звану OS Virtualization. Реалізуються контейнери за рахунок використання ізольованого простору імен, що включає всі необхідні для роботи ресурси (віртуалізовані імена), з якими можна взаємодіяти (файли, мережеві порти, процеси та інше) і вийти за які не можна. Тобто ОС показує контейнеру тільки те, що виділено. Додаток всередині контейнера вважає, що воно єдине, і працює в повноцінної ОС без будь-яких обмежень. Якщо необхідно змінити існуючий файл або створити новий, контейнер отримує копії з основною ОС хоста, зберігаючи тільки змінені ділянки. Тому розгортання кількох контейнерів на одному хості дуже ефективно.
Відмінність контейнерів від віртуальних машин полягає в тому, що контейнери не завантажують власні копії ОС, бібліотеки, системні файли та інше. Операційна система як би ділиться з контейнером. Єдине, що додатково потрібно, - це ресурси, необхідні для запуску програми в контейнері. В результаті контейнер стартує в лічені секунди і менше навантажує систему, ніж в разі застосування віртуальних машин. Docker в даний час пропонує 180 тисяч додатків в репозиторії, а формат уніфікований в Open Container Initiative (OCI). Але залежність від ядра має на увазі, що в інший ОС контейнери не будуть працювати. Контейнери Linux вимагають Linux API, відповідно Windows в Linux працювати не стане.
Контейнери Windows використовують одне ядро з ОС, яке динамічно поділяють між собою. Процес розподілу (CPU, ОЗУ, мережа) бере на себе ОС. При необхідності можна обмежити максимально доступні ресурси, що виділяються контейнеру. Файли ОС і запущені служби проектуються в простір імен кожного контейнера. Такий тип контейнера ефективно використовує ресурси, зменшуючи накладні витрати, а значить, дозволяє більш щільно розміщувати додатки. Цей режим в чомусь нагадує FreeBSD Jail або Linux OpenVZ.
Контейнери Hyper-V забезпечують додатковий рівень ізоляції за допомогою Hyper-V. Кожному контейнеру виділяється своє ядро і пам'ять, ізоляцію здійснює не ядро ОС, а гипервизор Hyper-V. В результаті досягається такий же рівень ізоляції, як і в віртуальних машинах, при менших накладних витратах в порівнянні з VM, але більший, якщо порівняти з контейнерами Windows. Для використання такого виду контейнерів потрібно встановити на хості роль Hyper-V. Контейнери Windows більше підходять для використання в довіреної середовищі, наприклад коли на сервері запускаються додатки однієї організації. Коли ж сервером користуються безліч компаній і необхідно забезпечити більший рівень ізоляції, контейнери Hyper-V, ймовірно, будуть більш раціональними.
В якості ОС в контейнері може використовуватися Server Core або Nano Server. Перший, в общем-то, давно не новинка і забезпечує високий рівень сумісності з наявними додатками. Другий - ще більш урізана версія для роботи без монітора, що дозволяє запускати сервер в мінімально можливої конфігурації для використання з Hyper-V, файловим сервером (SOFS) і хмарними службами. Графічний інтерфейс, природно, відсутня. Містить тільки найнеобхідніші компоненти (.NET з CoreCLR, Hyper-V, Clustering і так далі). Але в підсумку займає на 93% менше місця, вимагає менше критичних виправлень.
Ще цікавий момент. Для управління контейнерами, крім традиційного PowerShell, можна використовувати і Docker. І щоб забезпечити можливість запуску нерідних утиліт на Win, MS уклала партнерську угоду для розширення API Docker і набору інструментів. Всі розробки відкриті і доступні в офіційному GitHub проекту Docker. Команди управління Docker пишуться для всіх контейнерів як Win, так і Linux. Хоча, природно, контейнер, створений на Linux, запустити в Windows неможливо (як і навпаки). На даний момент PowerShell за функціями обмежений і дозволяє працювати тільки з локальним репозиторієм.
установка Containers
В процесі встановиться і мережевий контролер Virtual Switch, його відразу необхідно налаштувати, інакше подальші дії будуть видавати помилку. Дивимося назви мережевих адаптерів:
Для роботи нам потрібен контролер з типом External. У командлет New-VMSwitch багато параметрів, але для прикладу обійдемося мінімальними установками:
Файрвол Windows блокуватиме з'єднання до контейнера. Тому необхідно створити дозволяє правило, як мінімум для можливості підключатися віддалено за допомогою PowerShell remoting, для цього дозволимо TCP / 80 і створимо правило NAT:
Є ще один варіант простого розгортання. Розробники приготували скрипт, що дозволяє встановити всі залежності автоматично і налаштувати хост. При бажанні можна скористатися ним. Параметри всередині скрипта допоможуть зрозуміти всі механізми:
Є ще один варіант - розгорнути готову віртуальну машину з підтримкою контейнера. Для цього на тому ж ресурсі є скрипт, автоматично робить усе потрібні операції. Детальна інструкція наведена на MSDN. Завантажуємо і запускаємо скрипт:
Ім'я задаємо довільне, а -WindowsImage говорить про тип зібраного образу. Варіантами можуть бути NanoServer, ServerDatacenter. Відразу ставиться і Docker, за його відсутність або наявність відповідає параметр SkipDocker і IncludeDocker. Після запуску почнеться завантаження і перетворення образу, в процесі потрібно буде вказати пароль для входу в VM. Сам ISO-файл достатньо великий, майже 5 Гбайт. Якщо канал повільний, файл можна завантажити на іншому комп'ютері, після чого перейменувати в WindowsServerTP4 і скопіювати в С: \ Users \ Public \ Documents \ Hyper-V \ Virtual Hard Disks. Можемо залогінитися в встановлену віртуальну машину, вказавши пароль, заданий при складанні, і працювати.
Тепер можна переходити безпосередньо до використання контейнерів.
Використання контейнерів з PowerShell
Модуль Containers містить 32 командлет PowerShell, документація по деяким ще неповна, хоча, загалом, щоб змусити всі працювати, достатня. Перелік вивести просто:
Отримати список доступних образів можна за допомогою командлета Get-ContainerImage, контейнерів - Get-Container. У випадку з контейнером в колонці Status буде показаний його поточний статус: зупинений або запущений. Але поки технологія знаходиться в стадії розробки, MS не надала репозиторій, та й, як говорилося, поки PowerShell працює з локальним репозиторієм, тому для експериментів його доведеться створити самому.
Отже, сервер з підтримкою у нас є, тепер потрібні самі контейнери. Для цього ставимо провайдер пакетів ContainerProvider.