Docker windows настройка сети
Обновлено: 04.07.2024
Есть такие сетевые приложения, которым необходимо иметь выход во внешний мир не одним портом, а сразу большой группой. Примерами таких приложений могут являться различные программы работающие с потоковыми видео/аудио каналами. Например различные PBX решения, такие как Asterisk или FreeSWITCH.
Собственно, с попыток контейнеризировать Asterisk всё и началось. Есть готовые образы на Docker HUB, хорошим примером является dougbtv/asterisk.
Дальнейший текст можно считать вольным переводом документации по настройке сети в docker .
Не использовать контейнеризацию сетевой подсистемы
Это один из очень простых способов предоставить доступ к контейнеру. Если создать контейнер с опцией --net=host , то контейнер будет запущен с сетевой подсистемой хост-системы. Это крайне просто в реализации, но могут возникнуть другие проблемы. Например, придется создавать алиасы на необходимый внешний интерфейс с другими IP-адресами, а в приложения в контейнерах запускать с привязкой именно на этот адрес, а не на 0.0.0.0 . Все проблемы можно решить с помощью создания простого скрипта, который будет “разруливать” эти проблемы:
- создавать алиас на интерфейс
- передавать адрес в контейнер в какой-нибудь переменной
- контейнер будет использовать эту переменную для запуска приложения
Но есть и положительная сторона - нет необходимости узнавать адрес назначаемый контейнеру.
И как дополнение - контейнер имеет доступ к хостовой подсистеме, может управлять ею, может иметь доступ к своему внешнему API. Это сомнительная необходимость, в частности со стороны безопасности.
Проброс одного порта
Проброс одного порта в docker существовал изначально и делался крайне просто с помощью ключа -p или опции EXPOSE в Dockerfile . Например для запуска контейнера с mysql достаточно было указать порт внутри контейнера и порт для хост машины -p <host port>:<container port> (ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort):
Подробне про это можно прочитать в официальной документации тут.
Просмотреть проброшенные порты можно с помощью docker port :
Проброс группы портов
Проброс группы портов был востребован очень давно, но был добавлен в исходный код только 1 ноября 2014. Этот функционал уже доступен в docker версии 1.4.1 .
Пример совсем не похож на реальность, но на то он и пример. Необходимо пробросить 5 портов, 2000-2005 или 3000-3005. Сделаем это опцией --expose , но в одном случае ключ -P (публиковать проброшенные порты на хост-систему) будет установлен в состояние по умолчанию - false , а в другом изменим его состояние на true .
После этого в iptables в цепочках FORWARD и DOCKER увидим следующее:
Как видно из вывода iptables - сервис docker создает правила для проброса портов с хост-системы в контейнер и обратно. Но, стоит учесть то, что при использовании автоматической публикации портов в хост-систему он использует свободные порты из диапазона 49153-65535.
Теперь сделаем тоже самое, но с диапазоном портов 3000-3005 и без публикации портов в хост-систему:
После этого мы не уивидим никаких дополнительных правил для проброса портов, лишь правила для bridge-интерфейса docker0 :
Теперь docker не создал правил для проброса портов. Сделаем это сами и всего лишь одной строкой для каждой цепочки:
Маршрутизация в контейнер
Можно сделать всё на много проще. На сетевом интерфейсе хост-системы уже включен ip_forward (это требуется при первичной настройке docker ) и этого достаточно.
Допустим на хост-системе есть 2 сетевых интерфейса с ip-адресами: 10.10.10.10 и 172.172.172.172. Для доступа к контейнерам из внешней сети достаточно на роутерах во внешней сети указать маршрут на сеть docker через один из ip адресов хост-системы. Но тут встает другая проблема - закрепить IP-адрес за контейнером.
Для назначения статическиого адреса контейнеру создадим контейнер со своей сетевой подсистемой, но никак не связанной с хостовой. Для этого используется ключ --net=none :
Далее, следуя инструкциям из документации назначим IP-адрес контейнеру:
Теперь внутри контейнера ubuntu_none установлен IP-адрес 192.168.10.2. Таким образом был назначен необходимый IP-адрес.
Скрипт для запуска контейнеров со постоянным IP-адресом
Эта часть не совсем относится к настройке сети в контейнерах docker , а скорее к автоматизации описанного ранее.
Почитать подробнее про ностройку сети в docker можно тут - Network Configuration.
Надеюсь весь описанный материал покрывает все стандартные варианты запуска приложений, понятен и не вызывает вопросов. Если вопросы есть, то задавайте их в комментариях.
Подсистема и клиент Docker не входят в состав Windows, потому их нужно устанавливать и настраивать отдельно. Кроме того, подсистема Docker может принимать множество пользовательских конфигураций. Например, можно настроить то, как управляющая программа принимает входящие запросы, сетевые параметры по умолчанию и параметры ведения журнала и отладки. В ОС Windows эти конфигурации можно указать в файле конфигурации или с помощью диспетчера служб Windows. В этом документе объясняется установка и настройка подсистемы Docker; также представлены примеры некоторых часто используемых конфигураций.
Установка Docker
Для работы с контейнерами Windows требуется Docker. Docker состоит из подсистемы Docker (dockerd.exe) и клиента Docker (docker.exe). Самый простой способ установить все необходимые компоненты изложен в кратком руководстве, которое поможет настроить и запустить первый контейнер.
Сведения об установке с помощью сценария см. в разделе Использование сценария для установки Docker EE.
Прежде чем использовать Docker, необходимо установить образы контейнеров. Дополнительные сведения см. в документации по образам контейнеров.
Настройка Docker с помощью файла конфигурации
Предпочтительным способом настройки подсистемы Docker в Windows является использование файла конфигурации. Путь к файлу конфигурации — C:\ProgramData\Docker\config\daemon.json. Если этот файл еще не существует, его можно создать.
Не все доступные параметры конфигурации Docker применяются к Docker в Windows. В примере ниже показаны параметры конфигурации, которые применяются. Дополнительные сведения о конфигурации подсистемы Docker см. в статье Docker daemon configuration file (Файл конфигурации управляющей программы Docker).
Достаточно только внести необходимые изменения в файл конфигурации. Например, в этом случае подсистема Docker настраивается на прием входящих подключений через порт 2375. В других параметрах конфигурации будут использоваться значения по умолчанию.
Аналогично в примере ниже настраивается хранение образов и контейнеров по альтернативному пути в управляющей программе Docker. Если оно не указано, по умолчанию используется значение c:\programdata\docker .
В примере ниже управляющая программа Docker настраивается на прием только защищенных подключений через порт 2376.
Настройка Docker в службе Docker
Подсистему Docker можно также настроить, изменив службу Docker командой sc config . При использовании этого способа флаги подсистемы Docker задаются непосредственно в службе Docker. Выполните указанную ниже команду в командной строке (cmd.exe, не PowerShell).
Не нужно выполнять эту команду в том случае, если файл daemon.json уже содержит запись "hosts": ["tcp://0.0.0.0:2375"] .
Распространенные конфигурации
В следующих примерах файла конфигурации представлены распространенные конфигурации Docker. Их можно объединить в один файл конфигурации.
Создание сети по умолчанию
Чтобы настроить подсистему Docker таким образом, чтобы не была создана сеть NAT по умолчанию, используйте следующую конфигурацию.
Дополнительные сведения см. в статье Управление сетями Docker.
Задание группы безопасности для Docker
После входа в систему на узле Docker и запуска команд Docker эти команды выполняются через именованный канал. По умолчанию только члены группы "Администраторы" могут получить доступ к подсистеме Docker через именованный канал. Чтобы указать группу безопасности, имеющую такой доступ, используйте флаг group .
Конфигурация прокси-сервера
После задания переменной перезапустите службу Docker.
Удаление Docker
В этом разделе описывается, как удалить Docker и выполнить полную очистку компонентов системы Docker в Windows 10 или Windows Server 2016.
Все команды в этих инструкциях необходимо выполнять из сеанса PowerShell с повышенными привилегиями.
Подготовка системы к удалению Docker
Перед удалением Docker убедитесь, что в системе не запущены контейнеры.
Выполните следующие командлеты, чтобы найти работающие контейнеры:
Кроме того, перед удалением Docker рекомендуется удалить все контейнеры, образы контейнеров, сети и тома из системы. Это можно сделать, выполнив следующий командлет:
Удаление Docker
Затем необходимо начать собственно удаление Docker.
Удаление Docker в Windows 10
- На компьютере с Windows 10 перейдите в раздел Параметры > Приложения.
- В разделе Приложения и компоненты найдите пункт Docker для Windows
- Последовательно выберите Docker для Windows > Удалить.
Удаление Docker в Windows Server 2016
В сеансе PowerShell с повышенными привилегиями используйте командлеты Uninstall-Package и Uninstall-Module, чтобы удалить модуль Docker и соответствующий ему поставщик Управление пакетами из системы, как показано в следующем примере:
Вы можете найти поставщик пакетов, который использовался для установки Docker с помощью команды PS C:\> Get-PackageProvider -Name *Docker*
Очистка данных и системных компонентов Docker
После удаления Docker необходимо удалить сети Docker по умолчанию, чтобы их конфигурация не оставалась в системе после того, как Docker будет удален. Это можно сделать, выполнив следующий командлет:
Удалите сети по умолчанию Docker в Windows Server 2016.
Выполните следующий командлет, чтобы удалить программные данные Docker из системы:
Можно также удалить необязательные компоненты Windows, связанные с Docker и контейнерами в Windows.
К ним относится компонент "Контейнеры", который автоматически включается в любом экземпляре Windows 10 или Windows Server 2016 при установке Docker. Это также может быть компонент «Hyper-V», который автоматически включается в Windows 10 при установке Docker, однако в Windows Server 2016 он включается вручную.
Компонент Hyper-V является общим компонентом виртуализации, который обеспечивает гораздо большую функциональность, чем при использовании одних только контейнеров. Прежде чем отключить Hyper-V, убедитесь, что в системе нет других виртуальных компонентов, которые зависят от Hyper-V.
Удаление компонентов Windows 10
Удаление компонентов Windows Server 2016
В сеансе PowerShell с повышенными привилегиями выполните следующие командлеты, чтобы отключить компоненты Контейнеры и (необязательно) Hyper-V.
Перезагрузка системы
Чтобы завершить удаление компонентов и очистить систему, выполните следующий командлет из сеанса PowerShell с повышенными привилегиями для перезагрузки системы:
Ряд параметров сетевых драйверов позволяет воспользоваться преимуществами особых возможностей Windows.
Объединение внедренных коммутаторов с сетями Docker
Применимо ко всем сетевым драйверам
При создании сетей узлов контейнера для использования в DOCKER можно воспользоваться преимуществами объединения коммутаторов , указав несколько сетевых адаптеров (разделенных запятыми) с параметром.
Установка идентификатора виртуальной сети для сети
Применимо к сетевым драйверам "transparent" и "l2bridge"
Когда вы настраиваете идентификатор VLAN для сети, вы настраиваете изоляцию VLAN для любых конечных точек контейнера, которые будут присоединены к этой сети.
Убедитесь, что сетевой адаптер узла (физический) находится в магистральном режиме, чтобы весь помеченный трафик обрабатывался виртуальным коммутатором с портом vNIC (конечной точки контейнера) в режиме доступа в нужной сети VLAN.
Указание политики Аутбаунднат для сети
Если существует набор назначений (например, требуется подключение контейнера к контейнеру), в котором мы не хотим Нат'инг, необходимо также указать список исключений:
Указание имени сети для службы HNS
Применимо ко всем сетевым драйверам
Привязка сети к определенному сетевому интерфейсу
Применимо ко всем сетевым драйверам, за исключением "nat"
Указание суффикса DNS и DNS-серверов сети
Применимо ко всем сетевым драйверам
Дополнительные сведения см. в этой статье.
Советы & Аналитика
Ниже приведен список полезных советов и рекомендаций, составленный на основе стандартных вопросов о сетевых подключениях контейнеров Windows, которые задают участники сообщества.
Для работы службы HNS требуется включить IPv6 на хост-машинах контейнеров
В рамках обновления KB4015217 для работы службы HNS требуется включить IPv6 на узлах контейнеров Windows. При возникновении описанной ниже ошибки есть вероятность, что протокол IPv6 отключен на хост-компьютере.
Мы вносим соответствующие изменения в платформу, чтобы эту проблему можно было автоматически обнаружить/предотвратить. В настоящее время, чтобы убедиться, что на хост-компьютере включен протокол IPv6, можно воспользоваться представленным ниже способом.
Контейнеры Linux в Windows
НОВОЕ. Мы работаем над возможностью параллельного запуска контейнеров Linux и Windows без помощи виртуальной машины Linux Moby. Подробные сведения см. в этой записи блога о контейнерах Linux в Windows (LCOW). Вот как приступить к работе.
ПРИМЕЧАНИЕ. Решение LCOW приходит на замену виртуальной машине Linux Moby и будет использовать внутренний виртуальный коммутатор "nat" службы HNS по умолчанию.
Виртуальные машины Moby Linux используют коммутатор DockerNAT с Docker для Windows (продукт Docker CE)
Docker для Windows (драйвер Windows для подсистемы Docker CE) в Windows 10 использует внутренний виртуальный коммутатор под названием DockerNAT для подключения виртуальных машин Linux Moby к узлу контейнера. Разработчикам, использующим виртуальные машины Linux Moby в Windows, следует иметь в виду, что их узлы будут использовать виртуальный коммутатор DockerNAT вместо виртуального коммутатора "nat", созданного с помощью службы HNS (который является коммутатором по умолчанию, используемым для контейнеров Windows).
Чтобы для присвоения IP-адресов на виртуальном узле контейнеров можно было использовать протокол DHCP, необходимо активировать MACAddressSpoofing
Если узел контейнера виртуализирован и вы хотите использовать DHCP для назначения IP-адресов, необходимо включить MACAddressSpoofing на сетевом адаптере виртуальных машин. В противном случае узел Hyper-V будет блокировать сетевой трафик от контейнеров к виртуальной машине с несколькими MAC-адресами. Активировать MACAddressSpoofing в PowerShell можно с помощью следующей команды.
Если вы используете VMware в качестве гипервизора, вам необходимо включить неизбирательный режим. Подробнее см. здесь.
Создание нескольких прозрачных сетей на одном узле контейнера
Чтобы создать несколько прозрачных сетей, необходимо указать, к какому сетевому адаптеру (виртуальному) должен быть привязан внешний виртуальный коммутатор Hyper-V. Чтобы задать интерфейс для сети, используйте следующий синтаксис.
При выполнении статического назначения IP-адресов не забудьте задать параметры --subnet и --gateway
При статическом назначении IP-адресов необходимо сначала убедиться, что при создании сети указаны параметры --subnet и --gateway. IP-адрес подсети и шлюза должен совпадать с IP-адресом, указанным в параметрах сети для контейнера узла, т. е. физической сети. Ниже показано, как можно создать прозрачную сеть, а затем запустить в этой сети конечную точку, используя статическое назначение IP-адресов.
Назначение IP-адресов по протоколу DHCP не поддерживается для сетей L2Bridge
Для сетей контейнеров, созданных с помощью драйвера "l2bridge", поддерживается только статичное назначение IP-адресов. Как упоминалось выше, не забудьте задать параметры --subnet и --gateway для создания сети, которая подходит для статического назначения IP-адресов.
У сетей, в которых используется внешний виртуальный коммутатор, должен быть собственный сетевой адаптер
Обратите внимание, что если создание нескольких сетей, использующих внешний виртуальный коммутатор для подключения (например сетей Transparent, L2 Bridge, L2 Transparent) выполняется на одном узле контейнера, для каждой из них потребуется собственный сетевой адаптер.
Назначение IP-адресов: остановленные и запущенные контейнеры
Назначение статических IP-адресов выполняется непосредственно на сетевом адаптере контейнера и должно осуществляться, только когда контейнер находится в ОСТАНОВЛЕННОМ состоянии. "Горячее добавление" сетевых адаптеров контейнера или внесение изменений в сетевой стек не поддерживаются (в Windows Server 2016) во время выполнения контейнера.
Уже имеющийся виртуальный коммутатор (подсистема Docker его не видит) может блокировать создание прозрачный сети
Если при создании прозрачной сети возникнет ошибка, возможно, в системе есть внешний виртуальный коммутатор, который не был автоматически обнаружен Docker и не позволяет привязать прозрачную сеть к внешнему сетевому адаптеру узла контейнера.
При создании прозрачной сети Docker создает внешний виртуальный коммутатор для сети, а затем пытается привязать коммутатор к (внешнему) сетевому адаптеру. Адаптер может быть сетевым адаптером VM или физическим сетевым адаптером. Если виртуальный коммутатор уже создан на узле контейнера и видим Docker, подсистема Windows Docker будет использовать этот коммутатор, а не создавать новый. Но если виртуальный коммутатор создан внешними средствами (например, создан на узле контейнера при помощи диспетчера Hyper-V или PowerShell) и еще не виден Docker, подсистема Windows Docker попытается создать виртуальный коммутатор, после чего она не сможет подключить новый коммутатор к внешнему адаптеру сети узла контейнера (так как сетевой адаптер уже будет подключен к коммутатору, созданному внешними средствами).
Например, эта проблема может возникнуть, если вы сначала создали виртуальный коммутатор на узле, когда служба Docker была запущена, после чего попытались создать прозрачную сеть. В этом случае Docker не распознает созданный коммутатор и создаст новый виртуальный коммутатор для прозрачной сети.
Существует три подхода к решению этой проблемы.
- Вы можете удалить виртуальный коммутатор, созданный внешними средствами, что позволит Docker создать новый виртуальный коммутатор и подключить его к сетевому адаптеру узла без проблем. Перед тем как выбрать этот подход убедитесь, что виртуальный коммутатор, созданный внешними средствами, не используется другими службами (например, Hyper-V).
- Кроме того, если вы захотите использовать внешний виртуальный коммутатор, созданный внешними средствами, перезапустите службы Docker и HNS, чтобы коммутатор стал видим Docker.
- Другой вариант — использовать "-o com.docker.network.windowsshim.interface1", чтобы привязать внешний виртуальный коммутатор прозрачной сети к определенному сетевому адаптеру, который еще не используется в узле контейнера (например, сетевой адаптер, отличный от используемого виртуальным коммутатором, созданным внешними средствами). Параметр "-o" описан далее в разделе Создание нескольких прозрачных сетей в одном узле контейнера этого документа.
Обходные пути известных проблем в Windows Server 2016
Несмотря на то что мы продолжаем разрабатывать и добавлять новые функции, некоторые из них не будут перенесены на платформы предыдущих версий. Поэтому в этом случае пользователям лучше всего получить последние обновления для Windows 10 и Windows Server. В разделе ниже перечислены некоторые способы обхода известных проблем и оговорки, применимые к Windows Server 2016 и более ранним версиям Windows 10 (т. е. к версиям до обновления Creators Update 1704)
Несколько сетей NAT на узле контейнера WS2016
Разделы для новых сетей NAT должны быть созданы в префиксе более крупной внутренней сети NAT. Чтобы найти префикс, запустите следующую команду из PowerShell со ссылкой на поле InternalIPInterfaceAddressPrefix.
Например, внутренний префикс сети NAT узла может быть 172.16.0.0/16. В этом случае DOCKER можно использовать для создания дополнительных сетей NAT, если они являются подмножеством префикса 172.16.0.0/16. Например, можно создать две сети NAT с префиксами IP 172.16.1.0/24 (шлюз, 172.16.1.1) и 172.16.2.0/24 (шлюз, 172.16.2.1).
Созданные сети можно перечислить при помощи следующих элементов.
Docker Compose
Docker Compose можно использовать для определения и настройки сетей контейнера вместе с контейнерами и службами, которые будут использовать эти сети. Ключ "networks" Compose используется как ключ верхнего уровня при определении сетей, к которым будут подключены контейнеры. Например, в синтаксисе ниже определена существующая сеть NAT, создаваемая Docker в качестве сети по умолчанию для всех контейнеров и служб, определенных в указанном файле Compose.
Аналогично можно использовать следующий синтаксис для определения пользовательской сети NAT.
Примечание. Пользовательская сеть NAT, указанная в примере ниже, определена как раздел внутреннего префикса существующей сети NAT узла контейнера. Дополнительные сведения см. в разделе выше, "Несколько сетей NAT".
Более подробная информация об определении и настройке сетей контейнера при помощи Docker Compose см. в справочнике по файлам Compose.
Данная публикация является разбором особенностей контейнерной виртуализации Docker под системой Windows.
Она не претендует на роль исчерпывающей и по мере необходимости будет обновляться и дополняться.
За практическим руководством с нуля советую обратиться к этой публикации.
Содержание
Предварительные настройки
Контейнерная виртуализация или виртуализация на уровне операционной системы Docker нативно работает только на дистрибутивах Linux и FreeBSD (экспериментально).
На Windows вам понадобится гостевая Linux система либо специальная минималистичная виртуальная машина с ядром Linux от разработчиков Docker, которая и ставится из коробки.
Само собой разумеется, что вы включили виртуализацию у себя в BIOS/UEFI
Пункт настройки может называться по-разному: VT-x, VT-d, Intel VT, AMD-V, Virtualization Technology.
Еще одним минимальным системным требованием будет разрядность системы x64 и версия не ниже Windows 7 Pro.
Выбор между Docker Toolbox on Windows или Docker for Windows
Сборка включается в себя сам docker, утилиту docker-compose, утилиту для работы с виртуальной машиной docker-machine и клиент Kitematic.
Используется виртуальная машина (по умолчанию на VirtualBox) с минималистичным Linux окружением.
Позже для новых операционных систем выпустили Docker for Windows и Docker for Mac, которая на текущий момент является актуальной версией и продолжает развиваться.
Выбор между версиями не сложный:
— Если у вас Windows 10 x64 Pro, Enterprise или Education то включаем службу Hyper-V и ставим Docker for Windows.
Заметьте, что после включения службы Hyper-V пропадет возможность запускать и создавать x64 виртуальные машины на VirtualBox.
— Если же у вас другая версия Windows(7 Pro, 8, 8.1, 10 Home) то ставим VirtualBox и Docker Toolbox on Windows.
Несмотря на то, что Docker Toolbox разработчиками признан устаревшим работа с ним слабо отличается от Docker for Windows.
Вместе с установкой Docker Toolbox будет создана виртуальная машина.
В самом VirtualBox можно будет добавить оперативной памяти и ядер процессора на ваше усмотрение.
Windows контейнеры и Linux контейнеры
Docker for Windows предоставляет возможность переключать контейнеризацию между Linux и Windows версией.
В режиме Windows контейнеризации вы можете запускать только Windows приложения.
Замечу, что на май 2018 года в официальном Docker Hub существует всего 13 образов для Windows.
После включения Windows контейнеризации не забудьте добавить внешнюю сеть.
В конфигурационном файле docker-compose.yml это выглядит так:
Особенности монтирования папок
На примонтированных volume-ах не кидаются события файловой системы, поэтому inotify-tools не работает.
Спасибо пользователю eee
Если вы разрабатываете свой проект и пользуетесь docker-compose вне домашней папки то вам нужно будет проделать некоторые манипуляции.
Используя Docker for Windows для монтирования нового диска у вашего локального пользователя обязательно должен стоять пароль, который будет использоваться для доступа к shared папки.
Особенность заключается в том, что монтируемые внутрь контейнера диск будет монтироваться как от удаленной машины //10.0.75.1/DISK_DRIVE по протоколу SMB.
Для Docker Toolbox диски монтируются в самом VirtualBox на вкладке «Общие папки»
Пример для диска «D»:
Права доступа к монтируемым файлам и папкам
Как бы вам не хотелось, но для всех примонтированных из хост-машины файлов и папок будут стоять права 755 (rwx r-x r-x) и поменять их вы не сможете.
Остро встает вопрос при монтировании внутрь файла закрытого SSH ключа, права на который должны быть только у владельца(например 600).
В данном случае либо генерируют ключ при создании образа, либо прокидывают сокет ssh-agent с хост-машины.
Монтирование с хост-машины или volume
Монтирование внутрь контейнера происходит с использованием сети и протокола SMB, следовательно, внутри контейнера диск «D:\» будет примонтирован из источника //10.0.75.1/D
Использование volume внутри контейнера отображается как монтирование локального диска /dev/sda1, что влияет на скорость работы.
Простым тестом копирование файла на обычном HDD скорость работы получилась следующая:
Такая разница в скорости скорее всего связана с тем, что в volume данные сбрасываются на диск постепенно, задействуя кеш в ОЗУ.
Особенности разметки диска GPT и MBR
Данный пункт не является истинной так как опровергающей или подтверждающей информации в интернете найти не смог.
Если на хост-машине таблица разделов MBR, то контейнер с MySQL/MariaDB может упасть с ошибкой:
InnoDB: File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation
По умолчанию в базе данных включеён параметр innodb_use_native_aio, отвечающий за асинхронный ввод/вывод и его надо будет выключить.
Данная проблема также встречается на некоторых версиях MacOS.
Docker Toobox to Windows
Главное правило: начинать работу с запуска ярлыка на рабочем столе «Docker Quickstart Terminal», это решает 80% проблем.
— Бывает возникают проблемы с отсутствия переменных окружения, решается командой:
— Если все же возникают проблемы из разряда «docker: error during connect», необходимо выполнить:
Название Docker Machine по умолчанию default.
Docker Swarm
Ни в Docker for Mac, ни в Docker for Windows — нет возможности использовать запущенные демоны в качестве клиентов кластера (swarm members).
Спасибо пользователю stychos
Проблемы с кодировкой
Используя Docker Toolbox(на Docker for Windows не удалось воспроизвести) нашлась проблема с тем, что русские комментарии в docker-compose.yml файле приводили к ошибке:
Полезные ссылки
Заключение
Особенности работы с Docker контейнеризацией на системе Windows не отличается от работы на Linux за исключение разобранных выше.
В статье я умышленно не упомянул заметно низкую скорость работы контейнеров и overhead используя систему Windows как само собой разумеющееся.
Буду рад услышать ваши отзывы. Не стесняйтесь предлагать улучшения или указывать на мои ошибки.
Читайте также: