Можно ли запустить контейнер Docker для Linux в Windows
Обновлено: 21.11.2024
Microsoft готовится к следующему большому обновлению для Windows Server (ознакомьтесь с сегодняшней бесплатной записью в блоге Microsoft), и некоторые из новых функций очень интересны пользователям Docker. Одним из наиболее важных улучшений является то, что Docker теперь может запускать контейнеры Linux в Windows (LCOW) с использованием технологии Hyper-V.
Для запуска контейнеров Docker Linux в Windows требуется минимальное ядро Linux и пространство пользователя для размещения процессов контейнера. Это именно то, для чего был разработан набор инструментов LinuxKit: создание безопасных, экономичных и переносимых подсистем Linux, которые могут обеспечивать функциональность контейнера Linux в качестве компонента контейнерной платформы.
Мы были заняты созданием прототипа поддержки LinuxKit для контейнеров Docker Linux в Windows и подготовили предварительную версию, которую вы можете попробовать. Эта работа еще не завершена, и для нее требуется либо недавно анонсированная сборка Windows Server Insider, либо сборка Windows 10 Insider.
ОБНОВЛЕНИЕ: поддержка LCOW доступна в Windows 10 Fall Creators Update и в Windows Server 1709. Самый простой способ опробовать ее в Windows 10 — установить граничный вариант Docker для Windows (подробности). В Windows Server 1709 установите предварительную версию EE.
Запуск контейнеров Docker Linux в Windows с помощью LinuxKit
Приведенные ниже инструкции были протестированы на Windows 10 и сборках Windows Server Insider 16278 и 16281.
Перед запуском обязательно установите Docker для Windows (Windows 10) или Docker Enterprise Edition (Windows Server Insider).
Настройка Docker и LinuxKit
Предварительную сборку LinuxKit можно получить, просто выполнив следующие команды в PowerShell (с правами администратора):
Теперь получите основную сборку ветки демона Docker, которая содержит предварительную поддержку контейнеров Linux в Windows:
Запустите новый демон Docker, прослушивающий отдельный канал и использующий отдельное место хранения из установки по умолчанию:
Попробуйте
Запустите контейнер Linux:
Docker только что запустил минимальную виртуальную машину с экземпляром LinuxKit, на котором размещен контейнер Linux!
Поскольку это предварительная версия, в ней есть некоторые ограничения, но базовые операции Docker, такие как получение и запуск, работают.
Впереди
И сборки Windows Server Insider, и поддержка Docker для контейнеров Linux в Windows находятся в режиме раннего предварительного просмотра. Когда GA контейнеры Docker Linux в Windows улучшат работу с контейнерами Docker Linux как для разработчиков Windows, так и для администраторов серверов. Разработчикам будет проще создавать и тестировать смешанные приложения Windows/Linux Docker, запуская контейнеры для обеих платформ параллельно в одной системе.
А ИТ-администраторы, которые предпочитают Windows, скоро смогут легко запускать (в основном) ПО только для Linux, такое как HAProxy и Redis, в системах Windows с помощью контейнеров Docker Linux в Windows. Например, контейнеры Docker Linux в Windows значительно упростят настройку Docker Enterprise Edition и Universal Control Plane (которая зависит от некоторых компонентов только для Linux) в Windows Server.
Мы надеемся, что это пошаговое руководство на основе LinuxKit настроит вас на эксперименты. Обратная связь всегда приветствуется! Для получения общей справки и начала работы со сборками программы предварительной оценки используйте центр обратной связи Windows (Windows 10) или техническое сообщество участников программы предварительной оценки Windows Server. Для решения проблем с поддержкой LinuxKit и Docker для контейнеров Linux в Windows используйте средство отслеживания проблем Docker для Windows на GitHub. И дайте нам знать в Твиттере, если вы создадите что-то классное!
Пошаговое руководство по контейнеризации виртуальной машины Windows — с RDP-доступом — на платформе Linux Docker с гипервизором KVM
Каждый из компьютеров Windows и Linux имеет свои собственные требования к контейнеризации, которые будут обсуждаться в следующем разделе. Изначально нельзя запускать контейнеры Linux и Windows одновременно на одном и том же демоне Docker. После некоторых исследований решение, которое оказалось наиболее жизнеспособным, состояло в том, чтобы установить каждую машину Windows как виртуальную машину внутри одного контейнера Linux. С точки зрения демона Docker все контейнеры основаны на Linux. Однако некоторые из этих контейнеров работают под управлением гипервизора, а поверх него находится виртуальная машина Windows. Несмотря на то, что контейнер с ВМ в нем занимает больше места на диске, чем другие контейнеры, эффективность экономии места на диске при наличии большого количества ВМ в контейнерах по-прежнему высока по сравнению с запуском ВМ без контейнеров.
В конечном счете, я хотел получить доступ к машине с Windows в контейнере с помощью RDP и получить полный удаленный доступ к рабочему столу этой машины. К сожалению, нет удовлетворительных подробных руководств и полных пошаговых руководств, которые легко и ясно объясняют всю процедуру. И мне пришлось столкнуться с множеством мелких проблем на этом пути.Во время моего исследования я также видел, как многие люди — на различных технических форумах — боролись с такой реализацией и выражали свое разочарование! Я надеюсь, что этот документ послужит полным руководством по решению этой проблемы.
Вы можете спросить себя, зачем кому-то устанавливать виртуальную машину внутри контейнера? Поначалу это выглядит странно, так как уровень контейнера кажется ненужным, и можно просто установить виртуальную машину прямо на базовую ОС. Однако существуют разные причины, по которым это может быть решением и необходимым требованием.
Наш конкретный вариант использования включает развертывание нескольких идентичных виртуальных машин Windows для использования разными пользователями. Если бы нам нужна была только одна виртуальная машина, тогда не было бы необходимости ее контейнеризировать. Но поскольку мы хотим создать много одинаковых ВМ, мы сэкономим огромные ресурсы (жесткий диск, ОЗУ и ЦП), поместив эти ВМ в контейнеры.
Если мы сравним сценарий, в котором мы запускаем одну виртуальную машину непосредственно в нашей базовой ОС, со сценарием контейнеризации этой виртуальной машины, мы обнаружим, что оба они будут потреблять одинаковое дисковое пространство и другие ресурсы. На самом деле, каждый раз, когда мы хотим запустить виртуальную машину в контейнере, мы делаем два шага: запускаем контейнер и затем включаем виртуальную машину. На следующей диаграмме показаны эти два сценария; прямая виртуальная машина занимает 30 ГБ на жестком диске, а образ Docker — 35 ГБ. Здесь не так уж много пользы — с точки зрения экономии системных ресурсов.
Но что произойдет, если мы захотим запустить 6 копий предполагаемых виртуальных машин? Нам нужно будет создать 6 копий этой виртуальной машины, каждая из которых будет занимать то же место на диске, что и исходная. Таким образом, если исходная ВМ имеет размер 30 ГБ, 6 копий займут 180 ГБ на жестком диске.
Это резко меняется, когда мы помещаем в контейнеры каждую из этих идентичных ВМ. Это дополнительное преимущество технологии контейнеризации Docker. И он обязан своей ценностью тому, как Docker различает два основных понятия: образы и контейнеры. Изображения доступны только для чтения и составляют основу контейнеров. Контейнеры, созданные из одного и того же образа, используют одно и то же ядро только для чтения (то есть образ), в то время как каждый контейнер добавляет свой собственный слой для чтения и записи, который взаимодействует с образом только для чтения. Дополнительные сведения о разнице между изображениями и контейнерами см. в этом документе:
Если в нашем примере мы возьмем образ Docker объемом 35 ГБ и создадим из него 6 контейнеров, каждый контейнер создаст свой собственный слой для чтения и записи, через который будет осуществляться доступ к образу, доступному только для чтения. Во время создания этот слой R/W имеет размер 0; однако по мере того, как пользователь начинает взаимодействовать с контейнером — например, включать виртуальную машину, — размер этого уровня начинает увеличиваться. И если мы предположим, что все динамические изменения в одном слое накопили размер 10 ГБ, это означает, что все 6 контейнеров добавили в общей сложности 60 ГБ поверх исходных 35 ГБ образа.
Challenge 1 Контейнеры Windows на платформе Windows и контейнеры Linux на платформе Linux
Одно из самых больших препятствий, с которыми вы сталкиваетесь при использовании Docker и контейнеризации в целом, заключается в том, что вы не можете одновременно запускать контейнеры Linux и Windows на одной платформе (т. е. на одном и том же демоне Docker). Причина этого в том, что Docker — это виртуализация на уровне ОС; это означает, что его основная функция состоит в том, чтобы содержать и изолировать приложения, когда они работают в операционной системе. Демон Docker предоставляет каждому контейнеру все необходимые свойства уровня ядра, чтобы контейнерное приложение могло работать. По этой причине контейнеры, в которых запущены службы/приложения Linux, должны работать на платформе Linux, а контейнеры, в которых запущены службы/приложения Windows, должны работать на платформе Windows.
Рабочий стол Windows Docker имеет функцию предоставления подсистемы Linux; и в этом случае запущенный контейнер Linux может в конечном итоге работать в Windows. Однако следует отметить, что если эта функция включена, могут работать только контейнеры Linux, а контейнеры Windows — нет. Для запуска контейнеров Windows необходимо отключить эту функцию; и в этом случае контейнеры Linux не могут работать. По-прежнему невозможно одновременно запускать контейнеры Linux и Windows на одной платформе.
Если нужно, чтобы контейнеры Linux и Windows работали одновременно и взаимодействовали друг с другом, возможное решение — запустить каждую группу на соответствующей платформе, а затем настроить сетевую маршрутизацию, NAT и правила переадресации портов.
Контейнеры Windows Docker Challenge 2 недоступны через RDP или VNC, т. е. без графического рабочего стола
Даже если мы решили иметь две отдельные платформы — платформу Windows для контейнеров Windows и платформу Linux для контейнеров Linux — с соответствующей конфигурацией сети мы столкнемся с проблемой, что контейнеры Windows не могут иметь среду рабочего стола. Это факт для всех контейнеров Windows. Они разработаны и созданы для запуска служб и приложений; и к ним можно получить доступ с помощью интерфейса командной строки PowerShell/CMD.
В отличие от системы Linux, где среда рабочего стола является устанавливаемой службой, рабочий стол Windows поставляется непосредственно в комплекте с ОС, поставляемой корпорацией Майкрософт. Что касается контейнеров на базе Windows, Microsoft опубликовала определенные образы (известные как базовые образы), которые составляют основу любого контейнера Windows. Эти базовые образы не подходят для службы рабочего стола; и нельзя позволить себе роскошь установить его позже как надстройку.
Для получения дополнительной информации о контейнерах/образах Windows
Наша конечная цель — получить полностью работающую ОС Windows, доступную через RDP, контейнеризированную и управляемую демоном Docker. И для этого у нас будет следующее:
Первое, что нам нужно сделать, это установить Docker в нашу основную операционную систему. Для этого руководства нашей основной системой является Ubuntu 20.04 (Linux Kernel 5.4.0–40-generic) с жестким диском 70 ГБ, 4 ГБ ОЗУ и 2 ядрами ЦП.
Чтобы установить Docker, выполните следующие действия:
[2] Добавьте официальный ключ GPG Docker:
[3] Настройте стабильный репозиторий Docker:
[4] Обновите индекс пакета apt:
Примечание. Это важный шаг после добавления нового репозитория на шаге 3.
[5] Установите последнюю версию Docker Engine:
Примечание. Вам не нужно устанавливать пакеты docker-ce-cli или containerd.io, поскольку они устанавливаются непосредственно вместе с пакетом docker-ce.
[6] Запустите Docker сейчас и настройте его на автоматический запуск после перезагрузки:
Теперь, когда Docker установлен, мы можем приступить к созданию образа, который станет основой для нашего контейнера, на котором будет установлена виртуальная машина. В первом разделе ниже объясняется, как создать этот образ вручную без использования Dockerfile. Затем, во втором разделе, я объясню, как автоматизировать сборку образа с помощью Dockerfile.
Однако перед созданием образа нам нужно проверить, поддерживает ли наша система виртуализацию. Поскольку наш Контейнер будет работать с гипервизором, он не будет работать, если основная платформа не поддерживает виртуализацию. В противном случае мы столкнемся с ошибкой позже при попытке установить виртуальную машину. Мы можем запустить следующую команду:
Если на выходе число больше 0, значит, можно двигаться дальше. В противном случае нужно убедиться, что виртуализация (VT-x) включена в настройках BIOS. Если ваша основная платформа сама является виртуальной машиной, убедитесь, что VT-x включен в программном обеспечении для виртуализации.
- Включить VT-x на рабочей станции VMWare
- Включить VT-x в Virtualbox
Сборка образа без Dockerfile
[1] Извлечь основной образ Docker ubuntu:18.04:
Примечание: чтобы убедиться, что образ успешно добавлен, введите следующую команду:
sudo docker image ls
[2] Запустите контейнер (с именем ubuntukvm) из образа ubuntu:18:04 с некоторыми привилегированными параметрами:
Поскольку мы будем устанавливать гипервизор (QEMU-KVM) в этот контейнер, нам необходимо запустить его с определенными параметрами следующим образом:
— device=/dev/kvm будет отображать устройство /dev/ kvm в основной ОС внутри Контейнера.
— device=/dev/net/tun сопоставит устройство /dev/net/tun в основной ОС внутри Контейнера.
-v /sys/fs /cgroup:/sys/fs/cgroup:rw отобразит каталог /sys/fs/cgroup в основной ОС внутри Контейнера, и Контейнер будет иметь права на чтение и запись в этом каталоге.
— cap-add =NET_ADMIN добавит в контейнер возможности сетевого администратора.
— cap-add=SYS_ADMIN добавит в контейнер возможности системного администратора.
После успешного выполнения команды вы должны оказаться внутри контейнера с приглашением оболочки:
[3] Внутри контейнера обновите индекс пакета apt:
[4] Внутри контейнера установите пакет гипервизора QEMU-KVM и Libvirt:
Вам не нужно устанавливать libvirt-clients и bridge-utils, так как они уже установлены вместе с libvirt-daemon-sys.
libvirt-dev — особенно важный пакет для запуска Vagrant Boxes.
[5] Изменение группового владельца /dev/kvm:
Примечание: устройство /dev/kvm должно принадлежать группе kvm, и любой пользователь, которому нужно запускать виртуальные машины, должен быть частью группы kvm.
[6] Запустите службы Libvirt:
[7] Установите пакет образа Linux, который содержит все необходимые модули ядра:
Примечание: это важный шаг. Существуют определенные модули (например, ip_tables и ip6_tables), которые потребуются на более позднем этапе; и если они отсутствуют, будет создано сообщение об ошибке.
[8] Установите пакет curl (используется для загрузки приложения Vagrant):
[9] Установите пакет net-tools (он содержит утилиту ipconfig):
[10] Загрузите и запустите последнюю версию приложения Vagrant:
Примечание 1. Приведенные выше команды выполняют следующие действия:
- Установите инструмент парсера запросов JSON, jq, который будет использоваться в следующей команде.
- Получите последнюю версию Vagrant. значение и сохраните его в переменной окружения vagrant_latest_version.
– Загрузите последнюю версию пакета Vagrant.
– Установите загруженный пакет Vagrant.Примечание 2. Это очень важно и важно. что вы загружаете и устанавливаете Vagrant этим методом. НЕ устанавливайте его из репозитория Ubuntu (или любых других репозиториев Linux, таких как Red Hat) с помощью команды apt-get install vagrant. Причина этого в том, что библиотека WinRM не поставляется с пакетами Vagrant, предоставляемыми дистрибутивом Linux, а изначально поставляется с официальным пакетом. Библиотека WinRM необходима для запуска ящиков Windows Vagrant.
[11] Установите подключаемый модуль Vagrant Libvirt:
[12] Загрузите и установите Windows10 Vagrant box:
команда vagrant init загрузит Vagrantfile, содержащий инструкции по сборке блока Vagrant.
команда vagrant up создаст блок. Обратите внимание, что эта команда занимает некоторое время. Конкретный блок Vagrant, который мы загружаем здесь (peru/windows-10-enterprise-x64-eval), имеет размер 5,62 ГБ.
После того, как приведенная выше команда завершит выполнение, введите следующую команду, которая попытается получить доступ к ящику через RDP. Даже если это не удастся (поскольку в Контейнере не установлен RDP-клиент), мы получим IP-адрес ящика Vagrant:
[13] Настройте правила переадресации портов iptables:
Это важный шаг, если вы хотите получить доступ к порту RDP на коробке Vagrant из контейнера. По умолчанию приложение Vagrant настраивает правила брандмауэра, чтобы разрешить доступ только из контейнера к ящику Vagrant и наоборот. Машины за пределами контейнера не имеют доступа к коробке Vagrant. Мы хотели бы настроить правила таким образом, чтобы разрешить нашей основной ОС (Ubuntu) доступ к ящику Vagrant по RDP. Следующая диаграмма логически иллюстрирует это:
Добавьте следующие правила для подключений NAT/Port Forward от основной ОС к контейнеру через порт 3389 для переадресации на Vagrant Box через порт 3389:
После этого мы должны удалить правила, запрещающие весь трафик к/от интерфейса virb1; эти правила имеют приоритет над нашими вновь вставленными правилами:
Если вы напортачите с iptables или позже возникнут проблемы со связью, вы можете очистить все таблицы, а затем добавить правила (упомянутые выше) с чистого листа. Чтобы очистить iptables, введите следующее:
[14] Зафиксировать все изменения для создания нового образа:
На данный момент у нас есть полностью работающий контейнер с нужной виртуальной машиной Windows. Однако мы не можем передавать или хранить этот Контейнер. Кроме того, мы не можем создать несколько копий этого контейнера, не выполнив все шаги, которые мы сделали до сих пор. По этой причине нам нужно зафиксировать изменения в новом образе Docker. Изображение может быть передано или сохранено. Можно создать несколько контейнеров — создать экземпляр — практически сразу.
Чтобы зафиксировать изменения в новом изображении, нам нужно сначала выйти из контейнера:
Запишите идентификатор контейнера; а затем введите следующую команду:
Примечание 1. Вы можете заменить имя «ubuntukvm» на любое имя, которое вам нравится. Это будет имя нового изображения.
Создание образа с помощью Dockerfile
Вместо создания образа вручную, как показано в предыдущем разделе, мы можем автоматизировать весь процесс с помощью Dockerfile.
[1] Подготовьте Dockerfile:
В новом каталоге создайте Dockerfile (с именем Dockerfile) и напишите в нем следующие команды. В основном это те же самые команды, которые мы выполняли по отдельности в предыдущем разделе:
[2] Подготовьте сценарий запуска запуска (startup.sh):
Этот файл будет скопирован в образ и будет запускаться автоматически каждый раз, когда вы создаете экземпляр контейнера из этого образа. Скрипт назначит определенные разрешения и запустит необходимые службы. Кроме того, будут созданы правила iptables, которые будут перенаправлять трафик RDP.
[3] Создайте контейнер из файла Docker:
[4] Создайте экземпляр контейнера и запустите его:
К настоящему моменту мы должны иметь доступ к службе RDP в окне Windows Vagrant, подключившись к IP-адресу контейнера Docker. Чтобы проверить, доступен ли порт 3389/tcp (RDP) из основной ОС, мы воспользуемся простой командой Nmap.
Во-первых, если вы находитесь внутри контейнера Docker, нажмите Ctrl+p+q, чтобы перевести контейнер в фоновый режим во время работы; это должно вернуть вас к главному приглашению терминала ОС:
Далее нам нужно установить RDP-клиент для Linux. Популярным является RDesktop:
Наконец-то мы можем получить доступ к виртуальной машине Windows:
В установленном нами окне Windows Vagrant есть две встроенные учетные записи:
Я надеюсь, что этот пост был исчерпывающим руководством по контейнеризации виртуальной машины. Существуют различные преимущества запуска виртуальной машины в контейнере; один из них запускает несколько контейнеров одновременно. Вы можете автоматически создать нужный образ с помощью Dockerfile или вручную, выполнив каждую команду по отдельности. В этом посте мы рассмотрели оба способа.
Я использую бета-версию Docker Desktop для Windows.
Если нет, то почему Windows может запускать контейнеры Linux, а не наоборот?
Невозможно. Для создания и запуска контейнеров Windows требуется система Windows с поддержкой контейнеров.
@Sebastian506563, потому что докер запускает виртуализацию VirtualBox за кулисами, чтобы контейнеры Linux могли работать в Windows. Думаю, теоретически можно и наоборот, просто докер этого не реализовал.
9 ответов 9
В. Могут ли контейнеры Windows работать в Linux?
О: Нет. Не могут.
Контейнеры используют базовые ресурсы и драйверы операционной системы, поэтому контейнеры Windows могут работать только в Windows, а контейнеры Linux могут работать только в Linux.
В: А как насчет Docker для Windows? Или другие решения на основе виртуальных машин?
О: Docker для Windows позволяет имитировать запуск контейнеров Linux в Windows, но внутри создается виртуальная машина Linux, поэтому контейнеры Linux все еще работают в Linux. , а контейнеры Windows работают в Windows.
Бонус: прочитайте эту очень интересную статью о запуске док-контейнеров Linux в Windows.
О: Это зависит. Примите во внимание следующие рекомендации:
Также оставляем старые обновления для истории
Обновление 2: 08.2018
Если вы используете Docker-for-Windows, теперь вы можете одновременно запускать контейнеры Windows и Linux: Одновременный запуск контейнеров Docker для Windows и Linux
Бонус: не имеет прямого отношения к вопросу, но теперь вы можете запускать не только сам контейнер Linux, но и оркестратор, такой как Kubernetes: Kubernetes теперь доступен в стабильном канале Docker Desktop
Обновлено в 2018 году:
Первоначальный ответ в целом правильный, НО несколько месяцев назад Docker добавил экспериментальную функцию LCOW (официальный репозиторий GitHub).
Разве Docker для Windows уже не запускает контейнеры Linux? Вот так. Docker для Windows может запускать контейнеры Linux или Windows с поддержкой контейнеров Linux через виртуальную машину Hyper-V Moby Linux (начиная с Docker для Windows 17.10, эта виртуальная машина основана на LinuxKit).
Настройка для запуска Linux контейнеров с LCOW намного проще, чем предыдущая архитектура, в которой виртуальная машина Hyper-V Linux запускает демон Linux Docker вместе со всеми вашими контейнерами. С LCOW демон Docker запускается как процесс Windows (так же, как при запуске контейнеров Docker Windows), и каждый раз, когда вы запускаете контейнер Linux, Docker запускает минимальный гипервизор Hyper-V, на котором работает виртуальная машина с ядром Linux, runc и процессы контейнера. работает поверх.
Поскольку существует только один демон Docker, и поскольку этот демон теперь работает в Windows, скоро можно будет запускать контейнеры Windows и Linux Docker бок о бок в одном и том же сетевом пространстве имен. . Это откроет множество захватывающих сценариев разработки и производства для пользователей Docker в Windows.
Оригинал:
Как упоминалось в комментариях @PanagiotisKanavos, контейнеры не предназначены для виртуализации и используют ресурсы хост-компьютера. В результате на данный момент контейнер Windows не может работать "как есть" на компьютере с Linux.
Но вы можете сделать это с помощью виртуальной машины, поскольку она работает в Windows. Вы можете установить виртуальную машину Windows на свой хост Linux, что позволит запускать контейнеры Windows.
С учетом этого, ИМХО, запускать его таким образом в производственной среде будет не лучшей идеей.
Подсистема Windows для Linux (WSL) 2 представляет собой существенное архитектурное изменение, поскольку это полное ядро Linux, созданное Microsoft, что позволяет запускать контейнеры Linux без эмуляции. С WSL2 Docker может работать в полной мере в Windows, и вы можете использовать образы Docker, созданные для Linux. Публичный релиз WSL 2 должен появиться к концу мая. При первом запуске только что установленного дистрибутива Linux откроется окно консоли, и вам будет предложено распаковать файлы и сохранить их на вашем компьютере в течение минуты или двух.
Благодаря Docker Desktop, работающему на WSL 2, пользователи могут использовать рабочие области Linux и избежать необходимости поддерживать сценарии сборки как для Linux, так и для Windows.
Чем это отличается?
Приложения, работающие в Docker, ограничены приложениями, изначально поддерживаемыми основной операционной системой.
Другими словами, Docker для Windows может размещать приложения Windows только внутри контейнеров Docker, а Docker для Linux поддерживает только приложения Linux.
Docker в Windows: проблемы
Docker для Windows всегда был проблемой, раньше, когда я впервые использовал Docker в 2017 году, у него были следующие ограничения:
У него были строгие требования к поддерживаемым версиям Windows, некоторые контейнеры были недоступны для платформы Windows. Поддержка систем оркестровки, таких как Kubernates и Mesos, не была полной.
Большая часть этого была связана с тем, что Docker изначально был написан и построен для Linux.
Было несколько обходных путей, чтобы заставить его работать на WSL (подсистема Windows для Linux), но они были сложными и неполными.
Подсистема Windows для Linux (WSL) 2 вносит значительные изменения в архитектуру, поскольку представляет собой полное ядро Linux, созданное Microsoft, что позволяет запускать контейнеры Linux без эмуляции.
Начиная с WSL2, Docker может полноценно работать в Windows, и вы можете использовать образы, созданные для Linux.
Приведенное ниже руководство поможет вам установить Docker на ваш WSL в Windows.
Предпосылки
Перед установкой серверной части Docker Desktop WSL 2 необходимо выполнить следующие шаги:
Установите Windows 10 версии 2004 или выше (сборка 19041 или выше).
На момент написания этой статьи для обновления до Windows 10 версии 2004 (сборка 19041) вам необходимо будет присоединиться к программе Windows Insider и выбрать кольцо «Release Preview». Публичный релиз должен появиться к концу мая.
Включить функцию WSL 2 в Windows.
Откройте PowerShell от имени администратора и выполните:
Включить дополнительный компонент «Платформа виртуальной машины»
Откройте PowerShell от имени администратора и выполните:
На этом этапе перезагрузите компьютер, чтобы завершить установку WSL и обновление до WSL 2.
Установите пакет ядра Linux, необходимый для обновления версии WSL до WSL 2.
Подробная информация о ядре находится по ссылке ниже,
Установщик находится на месте,
Установите WSL 2 в качестве версии по умолчанию
Откройте PowerShell от имени администратора и выполните:
Установите выбранный вами дистрибутив Linux
Откройте Microsoft Store и выберите свой любимый дистрибутив Linux.
Некоторые из популярных приведены ниже:
При первом запуске только что установленного дистрибутива Linux откроется окно консоли, и вам будет предложено подождать минуту или две, пока файлы будут распакованы и сохранены на вашем ПК. Все будущие запуски должны занимать менее секунды.
Затем вам потребуется создать учетную запись пользователя и пароль для вашего нового дистрибутива Linux.
Проверьте список дистрибутивов Linux,
Настройте дистрибутив на использование WSL 2
Установка рабочего стола Docker
Обязательно выберите ниже во время установки,
Запустите Docker Desktop.
Теперь вы установили Docker на WSL 2.
Проверьте его, запустив в терминале Ubuntu/Linux.
Настройка ограничений контейнера Docker в WSL2
WSL 2 также позволяет нам настраивать память и процессоры в приведенной ниже конфигурации. Этим можно управлять, если вы хотите ограничить ресурсы, используемые вашими док-контейнерами.
Добавить файл для настройки параметров WSL2
Тестирование Docker: начало работы
Из официальной документации Docker давайте попробуем руководство по началу работы.
Выполните приведенные ниже команды, чтобы создать образ Docker,
Вы должны увидеть руководство по началу работы.
Вот и все, мы успешно установили и протестировали Docker на WSL2.
Я протестирую дополнительные функции Docker на WSL2 и обновлю статью, но приведенные выше шаги должны дать вам преимущество в использовании образов Linux в Docker для Windows.
Читайте также: