Добрый день.
Разбирая новый функционал Windows Server 2016 CTP3 невозможно не коснуться темы с контейнерами. Собственно, у меня в лаборатории есть 2-х узловой кластер, который я использую для всяческих экспериментов.
Для ознакомления с темой контейнеризации я бы использовал несколько статей, расположенных по ссылке Windows Containers, для быстрого понимания темы можно внимательно прочитать FAQs. Известные проблемы и ограничения для контейнеров в Windows Server 2016 CTP опубликованы тут.
Для развёртывания демо-среды контейнеров используются два подхода:
При развёртывании "с нуля" используется скрипт New-ContainerHost.ps1 - он позволяет скачать необходимые части для развёртывания из Интернет, подготовить виртуальную машину и т.д.
При установке с помощью скриптов виртуальная машина сервера и её диски размещаются по путям, указанным в Hyper-V по-умолчанию. Если вы хотите, чтобы виртуальная машина попадала на CSV - сделайте настройку в оснастке Hyper-V Manager . Гипотетически можно попытаться изменить строку номер 110 в скрипте - напрямую указав путь к требуемой папке на файловой системе.
Собственно, на скриншоте ниже можно ознакомиться с процессом развёртывания. В данном случае я ещё не модифицировал пути размещения компонентов виртуальных машин.
ПРИМЕЧАНИЕ! После установки вы можете выполнить команду Move средствами оснастки Hyper-V Manager и положить файлы виртуальной машины на нужное хранилище.
Последней командой я присоединил виртуальную машину к виртуальному коммутатору.
Как видите, я и путь поправил.
В процессе работы скрипта, появились дополнительные файлы
Виртуальные коммутатор присутствовал. VLAN на гостевой виртуальной машине был задан верный, разрешались имена и ходили PING. Пришлось опять лезть в скрипт для его анализа. Строка в скриншоте, навела на мысль, что может быть проблема с DHCP.
Однако, после добавления второго интерфейса - IPv4 адрес с настройками был успешно получен.
С другой стороны, проблема возникала на этапе "Creating container switch (DHCP)".... Но, у меня на интерфейсе задана статика... Вероятно на одном и том же интерфейсе не могут фигурировать два MAC без включенного MAC Address Spoofing, что не даёт возможности работать с DHCP.
После этого, я решил включить Mac Address Spoofing, и ещё раз внимательно прочитать раздел Work in Progress - к моему удивлению моя теория подтвердилась см.раздел Networking по ссылке. Это побочный эффект, возникающий при использовании одного ядра и ОС, и контейнерами, без включенного Mac Address Spoofing - всё контейнеры получают один и тот же MAC.
После удаления vSwitсh, чтобы избежать проблем при перезапуске скрипта, процесс пошел.
Сервер стал скачивать дистрибутив, после окончания загрузки он запустил процесс установки.
Обе мои системы успешно были развёрнуты :) можно приступать к тестированию.
Создаём наш первый контейнер из Default image
Разбирая новый функционал Windows Server 2016 CTP3 невозможно не коснуться темы с контейнерами. Собственно, у меня в лаборатории есть 2-х узловой кластер, который я использую для всяческих экспериментов.
Для ознакомления с темой контейнеризации я бы использовал несколько статей, расположенных по ссылке Windows Containers, для быстрого понимания темы можно внимательно прочитать FAQs. Известные проблемы и ограничения для контейнеров в Windows Server 2016 CTP опубликованы тут.
Для развёртывания демо-среды контейнеров используются два подхода:
- Развёртывание "с нуля", включая виртуальную машину;
- На существующей виртуальной машине;
При развёртывании "с нуля" используется скрипт New-ContainerHost.ps1 - он позволяет скачать необходимые части для развёртывания из Интернет, подготовить виртуальную машину и т.д.
При установке с помощью скриптов виртуальная машина сервера и её диски размещаются по путям, указанным в Hyper-V по-умолчанию. Если вы хотите, чтобы виртуальная машина попадала на CSV - сделайте настройку в оснастке Hyper-V Manager . Гипотетически можно попытаться изменить строку номер 110 в скрипте - напрямую указав путь к требуемой папке на файловой системе.
Собственно, на скриншоте ниже можно ознакомиться с процессом развёртывания. В данном случае я ещё не модифицировал пути размещения компонентов виртуальных машин.
ПРИМЕЧАНИЕ! После установки вы можете выполнить команду Move средствами оснастки Hyper-V Manager и положить файлы виртуальной машины на нужное хранилище.
Последней командой я присоединил виртуальную машину к виртуальному коммутатору.
Однако, как видно из скриншота выше, по-умолчанию создаётся виртуальный свитч контейнер в режиме NAT и возможности выбора никто не предложил. Мне это не понравилось, да и излишне усложнило тестовый стенд. Посему я занялся поиском возможностей обхода этого технологического решения.
Как выяснилось, после создания гостевой виртуальной машины, в корне системного диска можно обнаружить файл Install-ContainerHost.ps1. Там же лежали файлы логов, и ответов.
После анализа файла выяснилось, что в нём зашиты настройки виртуального коммутатора и NAT, однако, существует параметр $UseDHCP, которые позволяет создать vSwitch в режиме External, если произвести небольшую модификацию файла
Модифицированный скрипт со второй попытки при развёртывании "с нуля" можно положить следующим образом:
Как видите, я и путь поправил.
Данный файл скрипта идентичен файлу, который используется при установке на существующую виртуальную машину ContainerSetup.ps1. Для второй попытки я подготовил другую виртуальную машину и скачал этот скрипт с помощью команды:
wget -uri
https://aka.ms/setupcontainers -OutFile C:\ContainerSetup.ps1
Далее, сконфигурировал его для использования DHCP, повысил себе привилегий и запустил.
Файл Install-ContainerHost-Bootstrap.ps1 содержит закладку на перезапуск скрипта, после перезагрузки системы.
Казалось установка шла штатно, но как и в первом эксперименте с изменённой версией скрипта Install-ContainerHost.ps1 у меня возникла проблема
Виртуальные коммутатор присутствовал. VLAN на гостевой виртуальной машине был задан верный, разрешались имена и ходили PING. Пришлось опять лезть в скрипт для его анализа. Строка в скриншоте, навела на мысль, что может быть проблема с DHCP.
Однако, после добавления второго интерфейса - IPv4 адрес с настройками был успешно получен.
С другой стороны, проблема возникала на этапе "Creating container switch (DHCP)".... Но, у меня на интерфейсе задана статика... Вероятно на одном и том же интерфейсе не могут фигурировать два MAC без включенного MAC Address Spoofing, что не даёт возможности работать с DHCP.
После этого, я решил включить Mac Address Spoofing, и ещё раз внимательно прочитать раздел Work in Progress - к моему удивлению моя теория подтвердилась см.раздел Networking по ссылке. Это побочный эффект, возникающий при использовании одного ядра и ОС, и контейнерами, без включенного Mac Address Spoofing - всё контейнеры получают один и тот же MAC.
После удаления vSwitсh, чтобы избежать проблем при перезапуске скрипта, процесс пошел.
Сервер стал скачивать дистрибутив, после окончания загрузки он запустил процесс установки.
Обе мои системы успешно были развёрнуты :) можно приступать к тестированию.
Создаём наш первый контейнер из Default image
Комментариев нет:
Отправить комментарий
Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.