Контейнеры Linux в Windows 10 Linux containers on Windows 10

Контейнеры Linux составляют огромную долю общей экосистемы контейнеров и имеют важное значение для разработки и рабочих сред. Linux containers make up a huge percent of the overall container ecosystem and are fundamental to both developer experiences and production environments. Так как контейнеры и узел контейнеров используют одно ядро, запуск контейнеров Linux непосредственно в Windows — не лучший вариант. Since containers share a kernel with the container host, however, running Linux containers directly on Windows isn’t an option. Как раз в таких случаях и применяется виртуализация. This is where virtualization comes into the picture.

Контейнеры Linux на виртуальной машине Moby Linux containers in a Moby VM

Чтобы запустить контейнеры Linux на виртуальной машине Linux, выполните инструкции из статьи о начале работы с Docker. To run Linux containers in a Linux VM, follow the instructions in Docker’s get-started guide.

Docker поддерживает запуск контейнеров Linux на компьютерах с Windows с момента своего первого запуска в 2016 г. (до того, как стали доступны изоляция Hyper-V или контейнеры Linux в Windows). Для этого используется виртуальная машина на базе LinuxKit, работающая в Hyper-V. Docker has been able to run Linux containers on Windows desktop since it was first released in 2016 (before Hyper-V isolation or Linux containers on Windows were available) using a LinuxKit based virtual machine running on Hyper-V.

В такой модели клиент Docker запускается на компьютере с Windows, но отправляет вызовы в управляющую программу Docker на виртуальной машине Linux. In this model, Docker Client runs on Windows desktop but calls into Docker Daemon on the Linux VM.

В этой модели все контейнеры Linux совместно используют один узел контейнера, а также: In this model, all Linux containers share a single Linux-based container host and all Linux containers:

• используют одно ядро совместно с виртуальной машиной Moby, но не с узлом Windows; Share a kernel with each other and the Moby VM, but not with the Windows host.
• имеют согласованные свойства сети и хранилища между контейнерами Linux, работающими в Linux (так как они работают на виртуальной машине Linux). Have consistent storage and networking properties with Linux containers running on Linux (since they are running on a Linux VM).

Это также означает, что в узле контейнера Linux (виртуальной машине Moby) должна быть запущена управляющая программа Docker и все ее зависимости. It also means the Linux container host (Moby VM) needs to be running Docker Daemon and all of Docker Daemon’s dependencies.

Чтобы узнать, используется ли виртуальная машина Moby, проверьте в диспетчере Hyper-V ее наличие с помощью пользовательского интерфейса или выполните команду Get-VM в окне PowerShell с повышенными привилегиями. To see if you’re running with Moby VM, check Hyper-V Manager for Moby VM using either the Hyper-V Manager UI or by running Get-VM in an elevated PowerShell window.

Docker: можно ли контейнер, созданный из Windows разместить на Linux?

У нас стартап и мы все еще активно пополняемся единомышленниками, но наш продукт уже в скором времени близится к пилотному запуску. ПО наше состоит из следующих модулей:

1. API — проект ASP.NET Core Web API 2
2. MySQL
3. Web-клиент — приложение на Angular 5. Мы не скрестили ASP.NET Core и Angular, а разрабатываем веб-клиент Angular отдельно с Node.js на борту.

Стоит задача, организовать стратегию менее безболезненного развертывания всех трех узлов на инфраструктуре клиента, естественно с учетом того что будет написан туториал по инсталяции и что установкой будет заниматься техническая служба клиента.

Операционная система, которая будет крутиться на сервере клиента неизвестна и хотелось сделать некий универсальный процесс инсталяции который подходил бы как на Windows так и для Linux. Понятное дело, что за универсальность надо платить.

Как писал выше, мы только развивающийся отряд, и мы не имеем пока еще в арсенале хорошего специалиста-администратора с большим опытом решения подобных задач по развертыванию.

Docker. Докер, Docker и еще раз Докер. Естественно в первую очередь программисту приходит в голову это ПО одной из задач (я сказал одной из) которого является избавить программиста от проблем развертывания и дать максимально сфокусироваться на кодинге. Ох если бы это было так.

Прокси-сервер. И как не крути, но плюс к Kestrel/HTTP.sys какой-то из серверов Apache, IIS, nginx и т.д. все же нужен на сколько понял я. Даже если клиент планирует работать с нашим продуктом только внутри корпоративной сети. Дела с HTTP.sys конечно лучше: он не такой голый как Kestrel, но у нас то речь об универсальности, а HTTP.sys только для Windows. Пытался к примеру установить nginx на Windows Server в качестве эксперимента: мама родная, со стороны казалось, что я в первый раз вижу компьютер).

И если можно я задал бы два вопроса:

1) Первый вопрос он более общий, вы наверное догадались: что посоветуете?

2) А теперь, чтобы конкретизироваться: я сейчас работаю на Windows 10 и если я задумал использовать Docker, то я ведь правильно понимаю, что мне надо создать четыре контейнера

1. Контейнер с прокси-сервером (Apache, nginx или IIS)
2. Контейнер с СУБД MySQL
3. Контейнер с Angular-приложением
4. Контейнер с проектом ASP.NET Core 2 Web API

Можно ли это сделать прямо из Windows? То есть будет ли работать контейнер созданный на Windows-машине на Linux?

Preview: Linux Containers on Windows

Microsoft is getting ready for the next big update for Windows Server (check out today’s complimentary Microsoft blog post ) and some of the new features are very exciting for Docker users. One of the most important enhancements is that Docker can now run Linux containers on Windows (LCOW), using Hyper-V technology.

Running Docker Linux containers on Windows requires a minimal Linux kernel and userland to host the container processes. This is exactly what the LinuxKit toolkit was designed for: creating secure, lean and portable Linux subsystems that can provide Linux container functionality as a component of a container platform.

We’ve been busy prototyping LinuxKit support for Docker Linux containers on Windows and have a working preview for you to try. This is still a work in progress, and requires either the recently announced “Windows Server Insider” or Windows 10 Insider builds.

UPDATE: LCOW support is available in Windows 10 Fall Creators Update and in Windows Server 1709. The simplest way to try it out on Windows 10 is to install the edge variant of Docker for Windows (details). On Windows Server 1709, install EE preview.

Running Docker Linux Containers on Windows with LinuxKit

The instructions below have been tested on Windows 10 and Windows Server Insider builds 16278 and 16281.

Be sure to install Docker for Windows (Windows 10) or Docker Enterprise Edition (Windows Server Insider) before starting.

Setup Docker and LinuxKit

A preview build of LinuxKit is available by simply running the following commands in PowerShell (with Administrator rights):

Now get a master branch build of the Docker daemon that contains preview support for Linux containers on Windows:

Start a new Docker daemon listening on a separate pipe and using a separate storage location from the default install:

Try it

Run a Linux container:

Docker just launched a minimal VM running a LinuxKit instance hosting the Linux container!

Since this is an early preview there are some limitations, but basic Docker operations like pull and run work.

Looking ahead

Both Windows Server Insider builds and Docker support for Linux containers on Windows are in early preview mode. When GA, Docker Linux containers on Windows will improve the Docker Linux container experience for both Windows developers and server administrators. Developers will be able to more easily build and test mixed Windows/Linux Docker applications by running containers for both platforms side-by-side on the same system.

And IT-admins that prefer Windows will soon be able to easily run (mostly) Linux-only software like HAProxy and Redis on Windows systems by way of Docker Linux containers on Windows. For example, Docker Linux containers on Windows will make setting up Docker Enterprise Edition and Universal Control Plane (which relies on some Linux-only components) on Windows Server much simpler.

We hope this LinuxKit-based walkthrough will set you up to start experimenting. Feedback is always welcome! For general help and getting started with Insider builds use the Windows Feedback Hub (Windows 10), or the Windows Server Insiders Tech Community . For issues with LinuxKit and Docker support for Linux containers on Windows use the Docker for Windows issue tracker on GitHub . And let us know on Twitter if you build something cool!

Глубокое погружение в контейнеры Windows Server и Docker — Часть 2 — Реализация контейнеров Windows Server (перевод)

В данной статье рассказывается об особенностях реализации Docker в Windows, а также об отличиях в реализации контейнеров между Windows и Linux.

Перед этим даётся общее представление, что такое контейнеры, чем они похожи и чем отличаются от виртуальных машин.

Вступление

Представив 3 августа 2015 года Windows Server 2016 Technical Preview 3, Microsoft внедрила технологию контейнеров в платформу Windows. В то время, как на Linux технология контейнеров появилась в августе 2008 года, подобная функциональность прежде не поддерживалась операционными системами Microsoft. Благодаря успеху Docker на Linux, Microsoft решила почти 3 года назад (оригинальная статья опубликована 6 мая 2017 — прим. перев.) начать работу над реализацией контейнеров для Windows. С сентября 2016 года мы смогли поработать с публично доступной версией этой новой технологии контейнеров в Windows Server 2016 и Windows 10. Но в чём разница между контейнерами и виртуальными машинами? И как внутренне реализованы контейнеры Windows? В этой статье мы погрузимся в реализацию контейнеров на Windows.

Контейнеры и виртуальные машины

Часто с контейнерами начинают знакомить с фразы “Контейнеры — это облегчённые виртуальные машины”. Хотя это может помочь людям дать фундаментальное понимание, что такое контейнеры, важно отметить, что это утверждение на 100% ошибочно и может сильно запутать. Контейнеры отличаются от виртуальных машин, и поэтому я всегда представляю контейнеры как “что-то, отличное от виртуальных машин” или даже говорю “контейнеры — это НЕ виртуальные машины”. Но в чём же разница? И почему она так важна?

Что общего между контейнерами и виртуальными машинами

Хотя контейнеры НЕ виртуальные машины, у них обоих есть три важные характеристики:

Что общего между контейнерами и виртуальными машинами:

• Изолированное окружение: как и виртуальные машины, контейнеры гарантируют изоляцию файловой системы, переменных окружения, реестра и процессов между приложениями. Это значит, что, как и виртуальная машина, каждый контейнер создаёт изолированное окружение для всех приложений внутри себя. При миграции и контейнеры, и виртуальные машины сохраняют не только приложения внутри, но также и контекст этих приложений.
• Миграция между хостами: большое преимущество работы с виртуальными машинами в том, что можно перемещать слепки виртуальных машин между гипервизорами, при этом не нужно изменять их содержимое. Это справедливо и для контейнеров. Там, где виртуальные машины можно “перемещать” между разными гипервизорами, контейнеры можно “перемещать” между разными хостами контейнеров. При “перемещении” обоих видов артефактов между разными хостами содержимое виртуальной машины/контейнера остаётся точно таким же, как и на предыдущих хостах.
• Управление ресурсами: другая общая черта — это то, что доступные ресурсы (ЦП, ОЗУ, пропускная способность сети) как контейнеров, так и виртуальных машин могут быть ограничены до заданных значений. В обоих случаях это управление ресурсами может осуществляться только на стороне хоста контейнера или гипервизора. Управление ресурсами гарантирует, что контейнер получает ограниченные ресурсы, чтобы свести к минимуму риск того, что он повлияет на производительность других контейнеров, запущенных на том же самом хосте. К примеру, контейнеру можно задать ограничение, что он не может использовать больше 10% ЦП.

Разница между контейнерами и виртуальными машинами

Хотя между контейнерами и виртуальными машинами есть общие черты, также между ними есть некоторые важные различия.

Разница между контейнерами и виртуальными машинами:

• Уровень виртуализации: контейнеры — это новый уровень виртуализации. Если взглянуть на историю виртуализации, то она началась с таких понятий, как виртуальная память и виртуальные машины. Контейнеры — это новый уровень этой тенденции виртуализации. Там, где виртуальные машины обеспечивают виртуализацию аппаратного обеспечения, контейнеры обеспечивают виртуализацию ОС. Это значит, что если виртуализация аппаратного обеспечения позволяет виртуальной машине верить, что её аппаратные ресурсы принадлежат только ей, виртуализация ОС позволяет контейнеру верить, что вся ОС принадлежит только ему. Важно отметить эту разницу в виртуализации. У контейнеров, к примеру, нет собственного режима ядра. По этой причине контейнеры не видны как виртуальные машины и они также не распознаются, как виртуальные машины внутри операционной системы (можете попробовать самостоятельно выполнить команду PowerShell Get-VM). Хорошая аналогия для того, чтобы объяснить эту разницу — это дома (виртуальные машины) и квартиры (контейнеры). Дома (виртуальные машины) полностью самодостаточны и предоставляют защиту от непрошенных гостей. У каждого дома также есть собственная инфраструктура — водопровод, отопление, электричество и т. д. Квартиры (контейнеры) тоже предоставляют защиту от непрошенных гостей, но они строятся на основе общей инфраструктуры. В многоквартирном доме (Docker Host) водопровод, отопление, электричество и т. д являются общими. Хотя у них обоих могут быть общие характеристики, это разные сущности.
• Взаимодействие с ОС: другое важное отличие между контейнерами и виртуальными машинами заключается в способе, которым они взаимодействуют с режимом ядра. Тогда как у виртуальных машин есть полноценная ОС (и выделенный режим ядра), контейнеры разделяют “ОС (точнее, режим ядра)” с другими контейнерами и с хостом контейнеров. В результате контейнеры должны ориентироваться на ОС хоста контейнеров, в то время, как виртуальная машина может выбрать любую ОС (версию и тип), какую пожелает. Там, где виртуальные машины могут запускать ОС Linux на гипервизоре Windows, с технологией контейнеров невозможно запустить контейнер Linux на хосте контейнеров Windows, и наоборот. (В Windows 10 можно запускать контейнеры Linux, но они запускаются внутри виртуальной машины Linux — прим. перев.)
• Модель роста: контейнеры разделяют ресурсы хоста контейнера, и создаются на основе образа, который содержит ровно то, что нужно для запуска вашего приложения. Вы начинаете с основ и добавляете то, что необходимо. Виртуальные машины создаются в обратном порядке. Чаще всего мы начинаем с полной операционной системы и, в зависимости от приложения, убираем вещи, которые не нужны.

Контейнеры Windows Server

Теперь, когда мы знаем о различиях между виртуальными машинами и контейнерами, давайте нырнём глубже в архитектуру контейнеров Windows Server. Чтобы объяснить, как контейнеры внутренне реализованы в операционной системе Windows, нужно знать о двух важных понятиях: режиме пользователя и режиме ядра. Это два разных режима, между которыми постоянно переключается процессор, в зависимости от типа кода, который нужно выполнить.

Режим ядра

Режим ядра операционной системы был создан для драйверов, которым нужен неограниченный доступ к аппаратному обеспечению. Обычным программам (режима пользователя) приходится вызывать API операционной системы, чтобы получить доступ к аппаратному обеспечению или памяти. У кода, выполняющегося в режиме ядра, есть прямой доступ к этим ресурсам, и он разделяет те же области памяти/виртуальное адресное пространство, что и операционная система и другие драйверы в ядре. Поэтому выполнять код в режиме ядра очень рискованно, так как данные, принадлежащие операционной системе или другому драйверу могут быть повреждены, если ваш код режима ядра случайно запишет данные по неверному виртуальному адресу. Если драйвер режима ядра падает, то падает вся операционная система. Поэтому в режиме ядра нужно выполнять как можно меньше кода. По этой самой причине был создан режим пользователя.

Режим пользователя

В режиме пользователя код всегда выполняется в отдельном процессе (пользовательском пространстве), у которого есть свой собственный набор областей памяти (собственное виртуальное адресное пространство). Так как виртуальное адресное пространство каждого приложения является собственным, одно приложение не может изменить данные, принадлежащие другому приложению. Каждое приложение выполняется в изоляции, и если приложение падает, то падение ограничено только этим приложением. В дополнение к тому, что виртуальное адресное пространство является собственным, в режиме пользователя оно ограничено. Процессор, работающий в режиме пользователя, не может получить доступ к виртуальным адресам, зарезервированным для операционной системы. Ограничение виртуального адресного пространства приложения в режиме пользователя не позволяет ему изменять, и, возможно, повреждать, критические данные операционной системы.

Техническая реализация контейнеров Windows

Но что всем этим режимам процессора делать с контейнерами? Каждый контейнер — это всего лишь “режим пользователя” процессора с парой дополнительных возможностей, таких, как изоляция пространства имён, управление ресурсами и понятием каскадно-объединённой файловой системы. Это значит, что Microsoft нужно было адаптировать операционную систему Windows, чтобы она позволяла поддерживать множественные режимы пользователя. Что-то, что было очень трудно сделать, принимая во внимание высокий уровень интеграции между обоими режимами в предыдущих версиях Windows.

До выпуска Windows Server 2016 каждая операционная система Windows, которой мы пользовались, состояла из единственного “режима пользователя” и “режима ядра”. С появлением Windows Server 2016 стало возможным иметь несколько режимов пользователя, выполняющихся в одной операционной системе. Следующая диаграмма даёт общее представление об этой новой архитектуре мульти-режимов пользователя.

Взглянув на режимы пользователя в Windows Server 2016, можно выявить два различных типа: режим пользователя хоста и режимы пользователя контейнера (зелёные блоки на диаграмме). Режим пользователя хоста идентичен обычному режиму пользователя, с которым мы знакомы по предыдущим версиям Windows. Цель этого режима пользователя — размещать основные службы Windows и процессы, такие, как Session Manager, Event Manager и сеть. Более того, этот режим пользователя облегчает, в случае реализации Windows Server Core, взаимодействие пользователя с Windows Server 2016 при помощи пользовательского интерфейса.

Новая возможность Windows Server 2016 заключается в том, что как только вы включили компонент “Контейнеры”, этот режим пользователя хоста будет содержать некоторые дополнительные технологии управления контейнерами, которые гарантируют, что контейнеры будут работать в Windows. Основа этой технологии контейнеров — абстракция Compute Services (оранжевый блок), которая даёт доступ через публичный API к низкоуровневым возможностям контейнера, предоставляемым ядром. На самом деле, эти службы содержат лишь функциональность, чтобы запускать контейнеры Windows, отслеживать, запущены ли они, и управлять функциональностью, необходимой для их перезапуска. Остальные функции управления контейнером, такие, как отслеживание всех контейнеров, хранение образов контейнеров, томов и т. д., реализованы в Docker Engine. Этот движок напрямую общается с API контейнеров Compute Services и использует для этого “биндинг языка Go”, предложенный Microsoft.

Разница между контейнерами Windows и Linux

Одинаковые утилиты и команды Docker в контейнерах Windows и Linux

Хотя те же самые клиентские утилиты Docker (Docker Compose, Docker Swarm) могут управлять как контейнерами Windows, так и Linux, существуют некоторые важные отличия между реализациями контейнеров в Windows и в Linux.

Системные процессы

Там, где Linux предоставляет свою функциональность уровня ядра через системные вызовы, Microsoft решила контролировать доступную функциональность ядра при помощи DLL (это также является причиной того, почему Microsoft на самом деле не документировала свои системные вызовы). Хотя этот способ абстракции системных вызовов имеет свои преимущества, он привёл к сильно интегрированной операционной системе Windows со множеством взаимозависимостей между разными DLL Win32 и ожиданию от многих DLL, что будут запущены некоторые системные службы, на которые они (не)явно ссылаются. В результате запускать только процессы приложений, указанных в Dockerfile, внутри контейнера Windows не очень реалистично. Поэтому внутри контейнера Windows вы увидите кучу запущенных дополнительных системных процессов, в то время, как контейнерам Linux нужно запускать только указанные процессы приложений. Чтобы гарантировать, что необходимые системные процессы и службы выполняются внутри контейнера Windows, внутри каждого контейнера запускается так называемый процесс smss. Цель процесса smss — запустить нужные системные процессы и службы.

Процесс SMSS

Архитектура ОС

Не только в способе предоставления функциональности уровня ядра, но также и на уровне архитектуры существует важная разница в том, как обе операционные системы предоставляют функциональность контейнера клиентским утилитам Docker. В текущей реализации контейнеров в Windows Server 2016 представлен слой абстракции, называемый Compute Services, который абстрагирует низкоуровневые возможности контейнера извне. Причина этого в том, что Microsoft может менять низкоуровневый API контейнера без необходимости менять публичный API, вызываемый Docker Engine и другими клиентскими утилитами контейнеров. Кроме этого API Compute Services, вы можете написать свой собственный инструментарий управления контейнерами, используя биндинг языков C# или Go, которые доступны по адресам https://github.com/Microsoft/dotnet-computevirtualization и https://github.com/Microsoft/hcsshim.

Каскадно-объединённая файловая система?

Третье важное отличие между реализациями контейнеров Linux и Windows заключается в способе, которым обе операционные системы используют технологию Docker “копирование-при-записи”. Так как множество приложений Windows полагается на семантику NTFS, для команды Microsoft было сложно создать полноценную реализацию каскадно-объединённой файловой системы в Windows. Для таких функций, как журналы USN и транзакции, это, к примеру, потребовало бы совершенно новой реализации. Поэтому в текущей версии контейнеров в Windows Server 2016 нет настоящей каскадно-объединённой файловой системы. Вместо этого текущая реализация создаёт новый виртуальный диск NTFS для каждого контейнера. Чтобы эти виртуальные диски оставались небольшими, различные объекты файловой системы на этом виртуальном NTFS диске на самом деле являются символическими ссылками на настоящие файлы файловой системы хоста. Как только вы изменяете файлы внутри контейнера, эти файлы сохраняются на виртуальное блочное устройство, а в момент, когда вы хотите зафиксировать этот слой изменений, изменения забираются из виртуального блочного устройства и сохраняются в нужном месте файловой системы хоста контейнера.

Контейнеры Hyper-V

Последнее различие в реализации контейнеров Linux и Windows состоит в понятии контейнеров Hyper-V. Я напишу об этом интересном типе контейнеров в следующей статье этой серии. Оставайтесь с нами…