Привет, Хабр! Представляю вашему вниманию перевод статьи Глубокое погружение в контейнеры Windows Server и Docker. Часть 2. Базовая реализация контейнеров Windows Server. Корнелл Кнульст. В этой статье рассказывается об особенностях реализации Docker в Windows, а также о различиях реализации контейнеров между Windows и Linux. Перед этим дается общее представление о том, что такое контейнеры, чем они похожи и чем отличаются от виртуальных машин.
Введение Выпустив Windows Server 2016 Техническая предварительная версия 3 3 августа 2015 года, Microsoft привнесла контейнерную технологию на платформу Windows. Хотя технология контейнеров появилась в Linux в августе 2008 года, ранее такая функциональность не поддерживалась операционными системами Microsoft. Благодаря успеху Docker в Linux компания Microsoft приняла решение почти 3 года назад (оригинальная статья опубликована 6 мая 2017 г.
— ок.
перевод ) начать работу над реализацией контейнеров для Windows. С сентября 2016 года мы можем работать с общедоступной версией этой новой контейнерной технологии в Windows Server 2016 и Windows 10. Но в чем разница между контейнерами и виртуальными машинами? А как контейнеры Windows реализованы внутри? В этой статье мы углубимся в реализацию контейнеров в Windows. Контейнеры и виртуальные машины Знакомство с контейнерами часто начинают с фразы «Контейнеры — это легкие виртуальные машины».
Хотя это может помочь людям получить фундаментальное представление о том, что такое контейнеры, важно отметить, что это утверждение на 100% неверно и может сбить с толку.
Контейнеры отличаются от виртуальных машин, поэтому я всегда представляю контейнеры как «нечто иное, чем виртуальные машины» или даже говорю: «контейнеры НЕ являются виртуальными машинами».
Но какая разница? И почему это так важно?
Что общего между контейнерами и виртуальными машинами?
Хотя контейнеры НЕ являются виртуальными машинами, они оба имеют три важные характеристики:
(Изображение Альбунд | Dreamstime.com ) Что общего между контейнерами и виртуальными машинами:
- Изолированная среда : Как и виртуальные машины, контейнеры обеспечивают изоляцию файловой системы, переменных среды, реестра и процессов между приложениями.
Это означает, что, как и виртуальная машина, каждый контейнер создает изолированную среду для всех приложений внутри него.
Во время миграции и контейнеры, и виртуальные машины сохраняют не только приложения внутри них, но и контекст этих приложений.
- Миграция между хостами : Большим преимуществом работы с виртуальными машинами является то, что вы можете перемещать снимки виртуальных машин между гипервизорами без необходимости изменения их содержимого.
Это справедливо и для контейнеров.
Там, где виртуальные машины можно «перемещать» между разными гипервизорами, контейнеры можно «перемещать» между разными хостами контейнеров.
Когда оба типа артефактов «перемещаются» между разными хостами, содержимое виртуальной машины/контейнера остается точно таким же, как и на предыдущих хостах.
- Управление ресурсами : Еще одной общей особенностью является то, что доступные ресурсы (ЦП, ОЗУ, пропускная способность сети) как контейнеров, так и виртуальных машин могут быть ограничены заданными значениями.
В обоих случаях такое управление ресурсами может осуществляться только на стороне хоста контейнера или гипервизора.
Управление ресурсами гарантирует, что контейнер получает ограниченные ресурсы, чтобы свести к минимуму риск влияния на производительность других контейнеров, работающих на том же хосте.
Например, контейнер можно настроить таким образом, чтобы он не мог использовать более 10 % ресурсов ЦП.
Разница между контейнерами и виртуальными машинами
Несмотря на сходство между контейнерами и виртуальными машинами, между ними есть и некоторые важные различия.
Разница между контейнерами и виртуальными машинами:
- Уровень виртуализации : Контейнеры — это следующий уровень виртуализации.
Если вы посмотрите на историю виртуализации, то увидите, что она началась с таких понятий, как виртуальная память и виртуальные машины.
Контейнеры — это следующий уровень этой тенденции виртуализации.
Если виртуальные машины обеспечивают аппаратную виртуализацию, то контейнеры обеспечивают виртуализацию ОС.
Это означает, что виртуализация оборудования позволяет виртуальной машине полагать, что ее аппаратные ресурсы принадлежат только ей, а виртуализация ОС позволяет контейнеру полагать, что вся ОС принадлежит только ему.
Важно отметить эту разницу в виртуализации.
Контейнеры, например, не имеют собственного режима ядра.
По этой причине контейнеры не видны как виртуальные машины, а также не распознаются как виртуальные машины внутри операционной системы (вы можете попробовать запустить команду PowerShell Get-VM самостоятельно).
Хорошей аналогией, объясняющей эту разницу, являются дома (виртуальные машины) и квартиры (контейнеры).
Дома (виртуальные машины) полностью самодостаточны и обеспечивают защиту от незваных гостей.
В каждом доме также имеется своя инфраструктура – водопровод, отопление, электричество и т. д. Квартиры (контейнеры) также обеспечивают защиту от незваных гостей, но построены на основе общей инфраструктуры.
В многоквартирном доме (Docker Host) сантехника, отопление, электричество и т.д. общие.
Хотя они оба могут иметь общие характеристики, это разные сущности.
- Взаимодействие с ОС : Еще одно важное различие между контейнерами и виртуальными машинами — это способ их взаимодействия с режимом ядра.
Хотя виртуальные машины имеют полную ОС (и выделенный режим ядра), контейнеры используют «ОС (или, скорее, режим ядра)» с другими контейнерами и с хостом контейнера.
В результате контейнеры должны ориентироваться на операционную систему хоста контейнера, а виртуальная машина может выбрать любую операционную систему (версию и тип), которую пожелает. В то время как виртуальные машины могут запускать ОС Linux на гипервизоре Windows, с помощью контейнерной технологии невозможно запустить контейнер Linux на узле контейнера Windows, и наоборот. (В Windows 10 вы можете запускать контейнеры Linux, но они работают внутри виртуальной машины Linux — ок.
перевод )
- Модель роста : Контейнеры используют ресурсы хоста контейнера и создаются на основе образа, содержащего именно то, что вам нужно для запуска вашего приложения.
Вы начинаете с основ и добавляете то, что необходимо.
Виртуальные машины создаются в обратном порядке.
Чаще всего мы начинаем с полной операционной системы и в зависимости от приложения удаляем ненужное.
Это два разных режима, между которыми процессор постоянно переключается в зависимости от типа кода, который необходимо выполнить.
Режим ядра
Режим ядра операционной системы создан для водителей, которым необходим неограниченный доступ к оборудованию.Обычные программы (пользовательского режима) должны вызывать API операционной системы для доступа к оборудованию или памяти.
Код, работающий в режиме ядра, имеет прямой доступ к этим ресурсам и использует те же области памяти/виртуальное адресное пространство, что и операционная система и другие драйверы в ядре.
Поэтому запуск кода в режиме ядра очень рискован, поскольку данные, принадлежащие операционной системе или другому драйверу, могут быть повреждены, если ваш код режима ядра случайно запишет данные по неправильному виртуальному адресу.
Если происходит сбой драйвера режима ядра, происходит сбой всей операционной системы.
Поэтому вам нужно выполнять как можно меньше кода в режиме ядра.
Именно по этой причине был создан Пользовательский режим.
Пользовательский режим
В пользовательском режиме код всегда выполняется в отдельном процессе (пользовательском пространстве), который имеет собственный набор областей памяти (собственное виртуальное адресное пространство).Поскольку виртуальное адресное пространство каждого приложения является собственным, одно приложение не может изменять данные, принадлежащие другому приложению.
Каждое приложение работает изолированно, и в случае сбоя приложения сбой ограничивается только этим приложением.
Помимо того, что виртуальное адресное пространство является частным, оно ограничено в пользовательском режиме.
Процессор, работающий в пользовательском режиме, не может получить доступ к виртуальным адресам, зарезервированным для операционной системы.
Ограничение виртуального адресного пространства приложения пользовательского режима предотвращает изменение и, возможно, повреждение критически важных данных операционной системы.
Техническая реализация контейнеров Windows
Но что все эти режимы процессора делают с контейнерами? Каждый контейнер — это просто «пользовательский режим» процессора с парой дополнительных функций, таких как изоляция пространства имен, управление ресурсами и концепция каскадной файловой системы.Это означало, что Microsoft необходимо было адаптировать операционную систему Windows для поддержки нескольких пользовательских режимов.
Это было очень сложно сделать, учитывая высокий уровень интеграции обоих режимов в предыдущих версиях Windows. До выпуска Windows Server 2016 каждая используемая нами операционная система Windows состояла из одного «пользовательского режима» и «режима ядра».
С появлением Windows Server 2016 теперь можно использовать несколько пользовательских режимов в одной операционной системе.
На следующей диаграмме представлен обзор этой новой архитектуры многопользовательского режима.
Если посмотреть на пользовательские режимы в Windows Server 2016, то можно выделить два разных типа: пользовательский режим хоста и пользовательский режим контейнера (зеленые прямоугольники на схеме).
Режим хост-пользователя идентичен обычному пользовательскому режиму, с которым мы знакомы по предыдущим версиям Windows. Целью этого пользовательского режима является размещение основных служб и процессов Windows, таких как диспетчер сеансов, диспетчер событий и сеть.
Более того, в случае реализации Windows Server Core этот пользовательский режим упрощает взаимодействие пользователя с Windows Server 2016 с помощью пользовательского интерфейса.
Новой функцией Windows Server 2016 является то, что после включения функции «Контейнеры» этот пользовательский режим хоста будет содержать некоторые дополнительные технологии управления контейнерами, которые гарантируют, что контейнеры будут работать в Windows. Ядром этой контейнерной технологии является абстракция вычислительных служб (оранжевый блок), которая обеспечивает доступ через общедоступный 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 со множеством взаимозависимостей между различными библиотеками Win32 DLL и ожиданием, что многие библиотеки DLL будут запускать некоторые системные службы, на которые они (неявно) ссылаются.
В результате запускать внутри контейнера Windows только процессы приложения, указанные в Dockerfile, не очень реалистично.
Таким образом, внутри контейнера Windows вы увидите множество дополнительных системных процессов, в то время как контейнерам Linux достаточно запускать только определенные процессы приложений.
Чтобы обеспечить работу необходимых системных процессов и служб внутри контейнера Windows, внутри каждого контейнера запускается так называемый sms-процесс.
Целью sms-процесса является запуск необходимых системных процессов и сервисов.
SMS-процесс
Архитектура ОС
Не только в том, как они обеспечивают функциональность на уровне ядра, но и на архитектурном уровне, существует важная разница в том, как обе операционные системы предоставляют функциональность контейнера клиентским утилитам Docker. Текущая реализация контейнеров в Windows Server 2016 представляет уровень абстракции, называемый Compute Services, который абстрагирует низкоуровневые возможности контейнера извне.Причина этого в том, что Microsoft может изменить низкоуровневый API-интерфейс контейнера без необходимости изменять общедоступный API, вызываемый Docker Engine и другими клиентскими утилитами контейнера.
В дополнение к этому API вычислительных служб вы можете написать свои собственные инструменты управления контейнерами, используя языки привязки 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. Об этом интересном типе контейнеров я напишу в следующей статье этой серии.Оставайтесь с нами… Теги: #Виртуализация #Windows #docker #Windows Server 2016
-
Как Копировать Игры Без Мод-Чипа
19 Oct, 24 -
Так Что Же Такое Pagerank?
19 Oct, 24 -
Разработка Для Google Appengine
19 Oct, 24 -
Москва Alt.net: 2-Я Встреча
19 Oct, 24 -
Программист Графофилия
19 Oct, 24
