Контейнери Microsoft Windows Server 2016 стали розширенням можливостей технології для клієнтів. Microsoft планує розробки клієнтів, розгортання і тепер хостинг додатків у контейнерах як частину їхніх процесів розвитку.
У міру того, як темпи розгортання додатків продовжують збільшуватися і клієнти використовують розгортання версій додатків щодня або навіть щогодини, можливість швидкого розгортання додатків валідацію з розроблювача клавіатури для виробництва визначає вирішальне значення для успіху бізнесу. Цей процес пришвидшується контейнерами.
У той час як віртуальні машини мають функцію перенесення додатків у центрах обробки даних та у хмару та за її межі, ресурси віртуалізації додатково розблоковані контейнерами за допомогою віртуалізації ОС (Системний Софт). Це рішеннязавдяки віртуалізації, дозволить здійснити швидку доставку додатків.
Технологія Windows Контейнер включає два різних типуконтейнерів, Windows Server Контейнер та Hyper-V Контейнери. Обидва типи контейнерів створюються, керуються та функціонують однаково. Вони навіть виробляють та споживають той самий образ контейнера. Відрізняються вони між собою рівнем ізоляції, створеного між контейнером, операційною системою хоста та іншими контейнерами, запущеними на хості.
Windows Server Контейнери: Декілька екземплярів контейнерів можуть працювати одночасно на хості з ізоляцією, що надається через простір імен, управління ресурсами та ізоляції процесів технологій. Windows Server Контейнери мають те саме ядро, розташоване на хості.
Hyper-V Контейнери: Декілька екземплярів контейнерів можуть працювати одночасно на хості. Тим не менш, кожен контейнер реалізований усередині спеціальної віртуальної машини. Це забезпечує ізоляцію рівня ядра між кожним Hyper-V контейнером та контейнером хоста.
Microsoft включив у функцію контейнера набір інструментів Docker з управління не лише контейнерами Linux, а й контейнерами Windows Server та Hyper-V. У рамках співпраці в спільнотах Linux і Windows, було розширено досвід Docker шляхом створення модуля PowerShell для Docker, який представлений тепер з відкритим вихідним кодом для. Модуль PowerShell може керувати Linux і Windows Sever контейнерами локально або віддалено за допомогою технології REST API Docker. Розробники задоволені впровадженням інновацій для клієнтів за допомогою відкритого вихідного коду для розвитку нашої платформи. Надалі планується принести технології для наших клієнтів, поряд з інноваціями, як Hyper-V.
Придбати Windows Server 2016
Пропонуємо Вам купити Windows Server 2016 зі знижкою у офіційного Партнера Microsoft у Росії – Компанії ДАТАСИСТЕМ. Ви матимете можливість отримати консультацію, а також безкоштовно скачати Windows Server 2016 для тестування, звернувшись до наших фахівців техпідтримки. Ціна Windows Server 2016 на запит. Комерційна пропозиціядля участі у закупівлі Windows Server 2016 ви зможете отримати за запитом на e-mail:Вивчаємо технологію контейнерів
Windows Server 2016
Однією з чудових новинок, що з'явилися в Windows Server 2016, є підтримка контейнерів. Познайомимося з нею ближче
Сучасні системи давно відійшли від принципу одна ОС – один сервер. Технології віртуалізації дозволяють раціональніше використовувати ресурси сервера, дозволяючи запускати кілька ОС, розділяючи їх між собою та спрощуючи адміністрування. Потім з'явилися мікросервіси, що дозволяють розгортати ізольовані програми як окремий легко керований і масштабований компонент. Docker змінив усі. Процес доставки програми разом з гуртуванням став настільки простим, що не міг не зацікавити кінцевого споживача. Додаток усередині контейнера працює так, ніби використовує повноцінну ОС. Але, на відміну від віртуальних машин, вони не завантажують власні копії ОС, бібліотеки, системні файли і т.д. Контейнери отримують ізольований простір імен, у якому додатку доступні всі необхідні ресурси, але вийти за які не можна. Якщо потрібно змінити установки, зберігаються лише відмінності з основною ОС. Тому контейнер на відміну віртуальних машин дуже швидко запускається і менше навантажують систему. Контейнери ефективніше використовують ресурси сервера.
Контейнери у Windows
У Windows Server 2016 на додаток до існуючих технологій віртуалізації – Hyper-V та віртуальні програми Server App-V, додалася підтримка контейнерів Windows Server Containers реалізована через шар абстракції Contаiner Management stack, що реалізує всі потрібні функції. Анонсовано технологію ще в Technical Preview 4, але з того часу багато що змінилося у бік спрощення та інструкції написані раніше можна навіть не читати. При цьому було запропоновано два види «своїх» контейнерів – контейнери Windows та контейнери Hyper-V. І напевно ще однією головною можливістю, є використання для управління контейнерів крім командлет PowerShell ще і інструментів Docker.
Контейнери Windows нагадують за принципом FreeBSD Jail або Linux OpenVZ, використовують із ОС одне ядро, яке разом із іншими ресурсами (ОЗУ, мережа) поділяють між собою. Файли ОС та служби проектуються у простір імен кожного контейнера. Такий тип контейнера ефективно використовує ресурси, зменшуючи накладні витрати, а отже дозволяє щільніше розміщувати додатки. Так як базові образи контейнера мають одне ядро з вузлом, їх версії повинні збігатися, інакше робота не гарантується.
У контейнерах Hyper-V використовується додатковий рівень ізоляції і кожному контейнеру виділяється своє ядро та пам'ять. Ізоляцію на відміну попереднього типу здійснює не ядро ОС, а гіпервізор Hyper-V (потрібна роль Hyper-V). В результаті досягається менша накладна витрата в порівнянні з віртуальними машинами, але більший рівень ізоляції в порівнянні з контейнерами Windows. В цьому випадку для запуску контейнера мати таке ж ядро вОС. Також ці контейнери можна розгортати і в Windows 10 Pro/Корпоративна. Особливо варто відзначити, що тип контейнера вибирається не під час створення, а під час розгортання. Тобто будь-який контейнер може бути запущений як Windows і як Hyper-V варіанті.
Як ОС у контейнері використовуються обрізані Server Core або Nano Server. Перший, з'явився ще в Windows Sever 2008 і забезпечує велику сумісність з програмами. Другий ще більш урізаний порівнянням з Server Core і призначений для роботи без монітора, дозволяючи запускати сервер у мінімально можливій конфігурації для використання з Hyper-V, файловим сервером (SOFS) та «хмарними» службами, вимагаючи на 93% менше місця. Містить лише необхідні компоненти (.Net з CoreCLR, Hyper-V, Clustering і т.д.).
Для зберігання використовується формат зображення жорсткого диска VHDX. Контейнери, як і у випадку з Docker, зберігаються в образах в репозиторії. При чому кожен зберігається не повний набір даних, а лише відмінності створюваного образувідбазового. А в момент запуску всі необхідні дані проектуються на згадку. Для керування мережним трафіком між контейнером та фізичною мережею використовується Virtual Switch.
Як запакувати додаток у контейнер Docker?У мене є програма, написана на NodeJS. Як я можу запакувати його в образ Docker, щоб запускати як контейнер?
Docker - система управління контейнерами в POSIX-сумісних операційних системах (зараз підтримується Linux). Особливістю Docker є можливість запакувати додаток з усім необхідним оточенням таким чином, щоб запускати його на іншій системі без довгих та складних процедур встановлення залежностей або збирання з вихідних джерел. Запакований додаток, готовий до розгортання, називається "образом". Образи Docker ґрунтуються на "шаблонах" - попередньо налаштованих робочих оточеннях. Можна розглядати це як дистрибутиви операційної системи, хоч це й не зовсім так. Крім того, вивчивши документацію на Docker, ви зможете створити власний шаблон. Перевагою такого підходу є те, що образ вашої програми буде містити тільки сам додаток, а необхідне для нього оточення буде скачуватися автоматично з шаблону репозиторію. Docker трохи нагадує chroot або bsd jail, але працює інакше.
Важливо розрізняти собі поняття "контейнер" та "образ". Контейнер - це копія вашої програми, а образ - це файл, в якому зберігається програма, і з якого і створюється контейнер.
Припустимо, що у вас є програма на NodeJS, яку ви хочете запакувати в контейнер. Припустимо, що файл, який запускає вашу програму називається server.js, а для роботи програма слухає порт 8000. Як шаблон ми будемо використовувати "node:carbon". Для контейнеризації програми потрібно створити в каталозі, де розташовані файли вашої програми, файл "Dockerfile", в якому будуть описані параметри підготовки образу:
$ touch Dockerfile
Вміст файлу може бути приблизно таким:
# Вказуємо шаблон FROM node:carbon # Створюємо робочий каталог програми всередині контейнера WORKDIR /usr/src/app # Встановлюємо залежності програми за допомогою npm # Копіюються обидва файли package.json І package-lock.json, якщо вони присутні COPY package*. json./RUN npm install # Копіюємо в образ файли вашої програми COPY. . # Відкриваємо порт 8000 щоб він був доступний зовні контейнера EXPOSE 8000 # Виконуємо команду для запуску програми всередині контейнера CMD [ "npm", "start" ]
Щоб виключити непотрібні файли з образу, можна перерахувати їх імена у файлі ".dockerignore". Дозволяється використання маски (*.log).
Складання образу здійснюється наступною командою:
$ docker build -t username/node-web-app .
$ docker images # Example REPOSITORY TAG ID CREATED node carbon 1934b0b038d1 5 днів тому username/node-web-app останній d64d3505b0d2 1 хв
Запуск контейнера з образу здійснюється наступною командою:
$ docker run -p 49160:8000 -d username/node-web-app
У цьому прикладі створюється контейнер з образу "username/node-web-app" і одразу запускається. Порт програми 8000 доступний на локальній машині (localhost) і для того, щоб він був доступний "зовні", він "прокидається" на порт 49160. Можна вибрати будь-який вільний порт, крім того можна прокинути порт програми "як є", вказавши опцію " -p 8000: 8000 ".
Ви можете побачити, що ваш контейнер виконується, ввівши команду:
$ docker ps # Example ID IMAGE COMMAND ... PORTS ecce33b30ebf username/node-web-app:latest npm start...
Керування контейнером можна здійснювати різними командами, вказуючи ID цього контейнера:
$ docker pause ecce33b30ebf - призупинити роботу контейнера з ID ecce33b30ebf
$ docker resume ecce33b30ebf - відновити роботу контейнера з ID ecce33b30ebf
$ docker stop ecce33b30ebf - зупинити контейнер з ID ecce33b30ebf
$ docker rm ecce33b30ebf - видалити контейнер (при цьому видаляються всі дані, створені додатком усередині контейнера)
Здійснилося! Чи то молитви допомогли, чи жертвопринесення, але тепер можна запускати Docker контейнери з Windows усередині. Прекрасна новина прийшла одночасно з релізом Windows Server 2016. І мова не йде про якусь хитро-заховану віртуальну машину, або емуляцію Windows на Linux ядрі — запускається справжня Windows у справжньому Docker, з працюючими Dockerfile, docker-compose та іншими docker-приблудами .
Обмеження
Але це не означає, що тепер можна запускати будь-який контейнер будь-де. Через те, що Docker контейнери «віддаляють» ядро операційної системи у свого хоста (а інакше їм довелося б мати свою ОС і перетворюватися на віртуальну машину), контейнери Windows можна запускати тільки на свіжих Windows 10 Pro Anniversary Update і Windows Server 2016 .
Другий момент, запустити на Linux контейнер на Windows все ще не можна. В Anniversary Update є власна Linux підсистема (за допомогою якої можна запустити справжній Bash, наприклад), але вона не дотягує для повноцінного Linux-ядра, тому для того ж контейнера з Убунтою на Windows все ще потрібна захована віртуальна машина.
Зрештою, одночасно запускати ті та інші контейнери на Windows машині можна, але з танцем. Якщо виконати таку команду в Windows Server 2016 із встановленим Docker (рік тому я б обізвав таке чаклунство), воно спрацює:
Але якщо після цієї команди спробувати запустити Ubuntu контейнер, Docker зануриться:
Проблема в тому, що Windows та Linux контейнери обслуговуються різними Docker-демонами, які, тим не менш, використовують один і той же канал для спілкування з командним рядком. Тобто в кожний момент часу лише один демон може бути активним. На офіційному Докер-сайті є бета Docker for Windows, яка намагається впоратися проблемою (поки що тільки на Windows 10 Pro і Enterprise). Але навіть з нею, щоб перейти з Windows на Linux контейнери, потрібно або лізти в меню налаштувань, або спілкуватися з командним рядком:
PowerShell
& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon
& "C:\Program Files\Docker\Docker\DockerCli.exe"-SwitchDaemon |
Образи з Windows
Поки є лише два базові образи з контейнерною Windows:
Зробити свій базовий образ (scratch image) – не можна.
Образ Windows Server Core важить аж 10 гігів і загалом поводиться як повноцінна Windows Server 2016. Наприклад, MS SQL та повноцінний .NET Framework встановлюються там без проблем. Якщо ваша програма не сильно залежить від UI, то встановиться і вона.
Nano Server трохи цікавіше. Це дуже оптимізована та урізана Windows Server, яка важить менше за гігу. Але й обмежень вистачає: немає 32-бітових програм, UI, RDP, порізаний PowerShell, і т.д. Але це не заважає поставити на Nano Server той же IIS, .NET Core, і навіть якийсь MySQL.
І хтось міг уявити пару років тому, що в Dockerfile можна буде зустріти відразу Microsoft, Windows і PowerShell?
FROM microsoft/windowsservercore RUN powershell -Command.
FROM microsoft / windowsservercore RUN PowerShell - Command . . . . |
Це ж Windows у Докері! Досі звучить абсурдно.
Ступені ізоляції
Windows контейнера можна запускати у двох режимах ізоляції:
- Windows Server Containers
- Hyper-V Containers
У першому режимі Windows контейнера поводяться так само, як і всі інші контейнери в Docker: ділять загальне ядро з операційною системою, контейнерні процеси ізольовані, але все ще видно в хостівому дереві процесів, і т. п. Це дефолтний і самий швидкий спосібзапустити контейнер у Windows.
У другому випадку контейнера потрапляють спеціальну Hyper-V віртуальну машину. Це, звичайно, погано позначається на швидкості запуску, зате й ізоляція повна.
Висновок
Windows у Докері – це просто чудові новини. Навіть якщо не кидатися упаковувати свої продукти по контейнерах, це чудовий інструмент для того, щоб ізолювати свої юніт-тести, робочі машини, сервери для демонстрацій, пісочниці — все те, для чого доводилося раніше створювати віртуальну машину. Якщо Microsoft ще примудриться запустити nanoserver на Linux, то я їм пробачу недавнє зняття з виробництва Microsoft Band 2, куплений необачно за два місяці до цього.
У *nix-системах спочатку реалізована багатозадачність та пропонуються засоби, що дозволяють ізолювати та контролювати процеси. Такі технології, як chroot(), що забезпечує ізоляцію на рівні файлової системи, FreeBSD Jail, що обмежує доступ до структур ядра, LXC та OpenVZ, давно відомі та широко використовуються. Але імпульсом у розвитку технології став Docker, який дозволив зручно розповсюджувати програми. Тепер таке дісталося і до Windows.
Контейнери у Windows
Сучасні сервери мають надмірну продуктивність, і програми часом не використовують навіть їх частини. Через війну системи якийсь час «простаюють», нагріваючи повітря. Виходом стала віртуалізація, що дозволяє запускати декілька ОС на одному сервері, гарантовано розділяючи їх між собою та виділяючи кожній потрібну кількість ресурсів. Але прогрес не стоїть на місці. Наступний етап - мікросервіси, коли кожна частина програми розгортається окремо як самодостатній компонент, який легко масштабується під потрібне навантаження і оновлюється. Ізоляція запобігає втручанню в роботу мікросервісу з боку інших програм. З появою проекту Docker, який спростив процес упаковки та доставки програм разом з оточенням, архітектура мікросервісів отримала додатковий поштовх у розвитку.
Контейнери - це інший тип віртуалізації, що надає відокремлене середовище для виконання програм, що називається OS Virtualization. Реалізуються контейнери за рахунок використання ізольованого простору імен, що включає всі необхідні для роботи ресурси (віртуалізовані імена), з якими можна взаємодіяти (файли, мережні порти, процеси та інше) та вийти за які не можна. Тобто ОС показує контейнер тільки те, що виділено. Додаток усередині контейнера вважає, що він єдиний, і працює у повноцінній ОС без будь-яких обмежень. Якщо потрібно змінити існуючий файл або створити новий, контейнер отримує копії з основної ОС хоста, зберігаючи лише змінені ділянки. Тому розгортання кількох контейнерів однією хості дуже ефективно.
Відмінність контейнерів від віртуальних машин полягає в тому, що контейнери не завантажують власні копії ОС, бібліотеки, системні файли та інше. Операційна системаяк би ділиться із контейнером. Єдине, що додатково потрібно - це ресурси, необхідні для запуску програми в контейнері. В результаті контейнер стартує за лічені секунди і менше навантажує систему, ніж у разі застосування віртуальних машин. Docker зараз пропонує 180 тисяч додатків у репозиторії, а формат уніфікований в Open Container Initiative (OCI). Але залежність від ядра має на увазі, що в іншій ОС контейнери не працюватимуть. Контейнери Linux вимагають Linux API, відповідно Windows у Linux працювати не стане.
Розробники Windows донедавна пропонували дві технології віртуалізації: віртуальні машини та віртуальні програми Server App-V. Кожна має свою нішу застосування, свої плюси та мінуси. Тепер асортимент став ширшим – у Windows Server 2016 анонсовані контейнери (Windows Server Containers). І хоча на момент TP4 розробка ще не була завершена, вже можна подивитися нову технологію в дії і зробити висновки. Потрібно відзначити, що, наздоганяючи та маючи на руках готові технології, розробники MS пішли в деяких питаннях трохи далі, так що використання контейнерів стало простіше та універсальнішим. Головна відмінність у тому, що запропоновано два види контейнерів: контейнери Windows та контейнери Hyper-V. У TP3 були доступні лише перші.
Контейнери Windows використовують одне ядро з ОС, яке динамічно поділяють між собою. Процес розподілу (CPU, ОЗУ, мережа) перебирає ОС. При необхідності можна обмежити максимально доступні ресурси, які виділяються контейнеру. Файли ОС та запущені служби проектуються у простір імен кожного контейнера. Такий тип контейнера ефективно використовує ресурси, зменшуючи накладні витрати, отже, дозволяє щільніше розміщувати додатки. Цей режим чимось нагадує FreeBSD Jail або Linux OpenVZ.
Контейнери Hyper-V забезпечують додатковий рівень ізоляції за допомогою Hyper-V. Кожному контейнеру виділяється своє ядро та пам'ять, ізоляцію здійснює не ядро ОС, а гіпервізор Hyper-V. В результаті досягається такий же рівень ізоляції, як і у віртуальних машинах, при менших накладних витратах у порівнянні з VM, але більший, якщо порівняти з контейнерами Windows. Для використання такого виду контейнерів необхідно встановити на хості роль Hyper-V. Контейнери Windows більше підходять для використання в довіреному середовищі, наприклад, коли на сервері запускаються програми однієї організації. Коли ж сервер користується безліч компаній і необхідно забезпечити більший рівень ізоляції, контейнери Hyper-V, ймовірно, будуть раціональнішими.
Важлива особливість контейнерів Win 2016 полягає в тому, що тип вибирається не в момент створення, а в момент деплою. Тобто будь-який контейнер може бути запущений як і Windows, і як Hyper-V.
У Win 2016 за контейнери відповідає шар абстракції Contаiner Management stack, що реалізує всі необхідні функції. Для зберігання використовується формат зображення жорсткого диска VHDX. Контейнери, як і у випадку з Docker, зберігаються в образах репозиторії. Причому кожен зберігає не повний набір даних, лише відмінності створюваного образу від базового, й у момент запуску всі необхідні дані проектуються на згадку. Для управління мережним трафіком між контейнером та фізичною мережею служить Virtual Switch.
Як ОС у контейнері може використовуватися 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
В Azure є необхідний образ Windows Server 2016 Core with Containers Tech Preview 4, який можна розгорнути та використовувати для вивчення контейнерів. Інакше потрібно все налаштувати самому. Для локальної установки потрібен Win 2016, причому, оскільки Hyper-V Win 2016 підтримує вкладену віртуалізацію (Nested virtualization), це може бути як фізичний, так і віртуальний сервер. Сам процес встановлення компонента стандартний. Вибираємо відповідний пункт у майстрі додавання ролей та компонентів або, використовуючи PowerShell, даємо команду
PS> Install-WindowsFeature Containers
У процесі встановиться і мережевий контролер Virtual Switch, його одразу необхідно налаштувати, інакше подальші дії будуть видавати помилку. Дивимося назви мережевих адаптерів:
PS> Get-NetAdapter
Для роботи нам потрібний контролер із типом External. У командлета New-VMSwitch багато параметрів, але для обійдемося мінімальними установками:
PS> New-VMSwitch -Name External -NetAdapterName Ethernet0
Перевіряємо:
PS> Get-VMSwitch | where ($_.SwitchType –eq "External") 
Файрвол Windows блокуватиме з'єднання до контейнера. Тому необхідно створити роздільну здатність, як мінімум для можливості підключатися віддалено за допомогою PowerShell remoting, для цього дозволимо TCP/80 і створимо правило NAT:
PS> New-NetFirewallRule -Name "TCP80" -DisplayName "HTTP on TCP/80" -Protocol tcp -LocalPort 80 -Action Allow -Enabled True PS> Add-NetNatStaticMapping -NatName "ContainerNat" -Protocol TCP -ExternalIPAdds. InternalIPAddress 192.168.1.2 -InternalPort 80 -ExternalPort 80
Є ще один варіант простого розгортання. Розробники приготували скрипт, що дозволяє встановити всі залежності автоматично та налаштувати хост. За бажання можна скористатися ним. Параметри всередині скрипту допоможуть зрозуміти всі механізми:
PS> https://aka.ms/tp4/Install-ContainerHost -OutFile C:\Install-ContainerHost.ps1 PS> C:\Install-ContainerHost.ps1
Є ще один варіант – розгорнути готову віртуальну машину за допомогою контейнера. Для цього на тому ж ресурсі є скрипт, який автоматично виготовляє все потрібні операції. докладна інструкціянаведено на MSDN. Скачуємо та запускаємо скрипт:
PS> wget -uri https://aka.ms/tp4/New-ContainerHost -OutFile c:\New-ContainerHost.ps1 PS> C:\New-ContainerHost.ps1 -VmName WinContainer -WindowsImage ServerDatacenterCore 
Ім'я задаємо довільне, а WindowsImage говорить про тип збираного образу. Варіантами може бути NanoServer, ServerDatacenter. Відразу ставиться і Docker, за його відсутність чи наявність відповідає параметри SkipDocker та IncludeDocker. Після запуску розпочнеться завантаження та перетворення образу, у процесі потрібно буде вказати пароль для входу до VM. Сам ISO файл досить великий, майже 5 Гбайт. Якщо канал повільний, файл можна завантажити на іншому комп'ютері, після чого перейменувати в Windows ServerTP4 і скопіювати в С:\Users\Public\Documents\Hyper-V\Virtual Hard Disks . Можемо залогінитись у встановлену віртуальну машину, вказавши пароль, заданий під час збирання, та працювати.
Тепер можна переходити безпосередньо до використання контейнерів.
Використання контейнерів з PowerShell
Модуль Containers містить 32 командлети PowerShell, документація за деякими ще неповна, хоча загалом, щоб змусити все працювати, достатня. Список вивести просто:
PS> Get-Command -модулі Containers 
Отримати список доступних образів можна з допомогою командлета Get-ContainerImage, контейнерів - Get-Container. У випадку з контейнером у колонці Status буде показано його поточний статус: зупинено або запущено. Але поки технологія перебуває на стадії розробки, MS не представила репозиторій, та й, як говорилося, поки PowerShell працює з локальним репозиторієм, тому для експериментів його доведеться створити самому.
Отже, сервер із підтримкою у нас є, тепер потрібні самі контейнери. Для цього ставимо провайдер пакетів ContainerProvider.
Продовження доступне лише учасникам
Варіант 1. Приєднайтесь до спільноти «сайт», щоб читати всі матеріали на сайті
Членство у спільноті протягом зазначеного терміну відкриє тобі доступ до ВСІХ матеріалів «Хакера», збільшить особисту накопичувальну знижку та дозволить накопичувати професійний рейтинг Xakep Score!
