Контейнеры windows server 2016

Содержание:


  • 1.

    Предыстория


  • 2.

    Windows контейнер


  • 3.

    В мире контейнеров Windows


  • 4.

    Связь с Docker


  • 5.

    Мир Windows

Начиная с Windows Server 2016 в операционной системе от Microsoft включена нативная поддержка контейнеров. Это не Linux контейнеры, это контейнеры, которые работают на Windows, и запускают Windows внутри себя.

Данный факт является результатом присоединения Microsoft к Open Container Initiative (OCI). Контейнеры в Windows позволяют запускать приложения, которые изолированы от остальной части системы в переносимых контейнерах. Эти контейнеры включают в себя все, чтобы ваше приложение было полностью функциональным. Так же как это произошло с Linux, Microsoft надеется, что контейнеры изменят характер поставки программного обеспечения для пользователей и в Windows.

Предыстория

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

Тем не менее, Google не был долгое время одинок в своем увлечении контейнерными вычислениями. В какой-то момент из ниоткуда появился Docker, который в отличии от Google стандартизировал процессы доставки контейнеров, а также управления ими. Более того, Docker развивался сообществом энтузиастов в мире открытого исходного кода, что сделало его простым и очень популярным решением. С развитием проекта Docker буквально у каждого желающего появилась возможность получить скорость, гибкость и простоту управления программным обеспечением и инфраструктурой, которую предоставляют контейнеры.

Docker революция стала настолько значительной, что даже Microsoft присоединился к этой инициативе в первую очередь за счет поддержки Docker и Linux в Azure, а теперь и за счет интеграции этой технологии в Windows Server 2016. Самое интересное это то, что контейнеры Windows Server не основаны на Linux, это нечто совершенно новое. Windows контейнеры — это контейнеры, которые работают в Windows и запускают Windows внутри себя.

Причем Microsoft настолько серьезно стала относится к контейнерам, что сейчас активно участвует в Open Container Initiative (OCI), пытаясь перетягивать одеяло на себя так, как будто бы она сама придумала эту технологию.

Windows контейнер

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

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

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

Microsoft планирует предложить два типа контейнеров в Windows Server 2016: контейнер Windows Server и Hyper-V контейнер. Оба типа функционируют одинаковым образом, и могут быть созданы и управляются одинаково. Там, где они различаются — это в уровне изоляции, который каждый из них обеспечивает.

Контейнер Windows Server разделяет ядро с ОС работает на хост-машине, что означает, что все контейнеры, работающие на этой машине, разделяют одно и то же ядро. В то же время, каждый контейнер поддерживает свой собственный вид на операционную систему, реестр, файловую систему, IP-адреса и другие компоненты, сочетая это с изоляцией, предоставляемой каждому контейнеру при помощи процессов, пространства имен и технологий управления ресурсами.

Контейнер Windows Server хорошо подходит для ситуаций, в которых и основная ОС, и приложения в контейнерах лежат в пределах той же зоны доверия, например для приложений, которые охватывают несколько контейнеров или образуют общую службу. Тем не менее, контейнеры Windows Server обсуждаются в связи с их зависимостью от процесса обновления ОС хост-системы, который может осложнить обслуживание и препятствовать процессам. Например, патч примененный к хосту может сломать приложение, работающее в контейнере. Что еще более важно, в таких ситуациях, как многопользовательские среды, модель разделяемого ядра может раскрыть систему для уязвимостей приложений и кросс-контейнерных атак.

docker-windows.png

Hyper-V контейнер решает эти проблемы, предоставляя виртуальную машину, в которой нужно запустить контейнер Windows. При таком подходе контейнер больше не разделяет ядро хост-машины и не имеет зависимости от патчей ОС этой машины. Конечно, такой подход означает некоторую потерю скорости и эффективности упаковки, которые вы получаете с обычным контейнером в Windows Server, но взамен вы получаете более изолированную и безопасную среду.

Вне зависимости от типа контейнера, который вы используете, теперь у вас есть возможность использовать контейнеры с такими технологиями Windows как .NET или PowerShell, что не было возможно раньше. Контейнер для Windows предоставляет все необходимое для обеспечения работы приложения на любом компьютере под управлением Windows Server 2016, давая вам тот уровень переносимости, который был не доступен на протяжении большей части истории Windows. Вы можете создавать свои контейнеры локально, делать их доступными процессов для тестирования и контроля качества, а затем отправить их в команде, занимающейся продуктивом, без необходимости беспокоиться о сложных установках и конфигурациях на каждом шаге этого пути.

В мире контейнеров Windows

Ряд компонентов принимают участие в процессе создании и запуска контейнеров, начиная с хоста, на котором они должны работать. Хост может быть как физическим компьютером, так и ВМ с Windows 2016 Server. Единственное, что важно, чтобы была включена функция контейнеризации для Windows.

Вы можете разместить контейнеры на любой версии Windows: Server Full UI или же Core, которая устанавливается по умолчанию. Microsoft также представляет Nano издание для Windows Server 2016 — минимальную версию ОС, которая не включает в себя локальный графический пользовательский интерфейс или консоль.

Microsoft также добавила вложенную виртуализацию для Windows Server 2016, так что вы можете запустить Hyper-V контейнеры, если хостом является ВМ. Если вы планируете запускать такой тип контейнера, необходимо включить функцию Hyper-V на хост-ОС. Microsoft также добавляет поддержку контейнера для Windows 10, хотя только для Hyper-V контейнеров.

Как и с контейнерами Docker, вы разворачиваете контейнеры для Windows из образов. Каждый образ начинается с образа ОС контейнера — базового образа, включающего в себя операционную систему, которая будет работать внутри контейнера. В настоящее время Microsoft предоставляет два базовых образа: образ Server Core и образ Nano Server. Вы должны загрузить хотя бы один из этих образов ОС от Microsoft, прежде чем сможете развернуть контейнер.

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

Хост-ОС

Контейнер Windows Server

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

Windows Server Full UI

Образ Server Core

Образ Nano Server

Windows Server Core

Образ Server Core

Образ Nano Server

Windows Server Nano

Образ Nano Server

Образ Nano Server

Windows 10

N/A

Образ Nano Server

Как вы можете видеть, Hyper-V контейнеры в настоящее время поддерживают только образ Nano сервера, но ваш выбор контейнеров Windows Server зависит от того, с какой версией Windows Server вы работаете.

Для этого типа контейнера, образ ОС должен также соответствовать хост-системы в отношении сборки и уровня обновления. Несоответствие может привести к непредсказуемому поведению как для контейнера, так и хоста. Это означает, что вы должны обновить образ базового контейнера ОС при обновлении ОС хоста. Это также означает, что вы не будете иметь возможность запускать Linux контейнер на Windows машине, или наоборот, и это также верно для Hyper-V контейнеров.

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

Например, предположим, что вы создаете образ, основанный на Server Core. В новый образ, вы устанавливаете приложение, которое в настоящее время находится в разработке вместе со всеми зависимостями этого приложения. Затем вы можете развернуть один или несколько контейнеров из этого образа. Каждый контейнер функционирует как песочница, которая включает все компоненты, необходимые для полной работоспособности приложения.

Образ может быть развернут так часто, как это необходимо, а также совместно использоваться любым количеством контейнеров. Вы создаете контейнеры по мере необходимости, а затем избавляетесь от них, когда вы с ними закончите. Но лучше всего то, что вы можете обновить и повторно развернуть образ в любое время, а затем создать из него новые контейнеры, которые содержат последние изменения.

Вам не нужно выбирать тип контейнера (Windows Server или Hyper-V) до тех пор, пока вы не будете готовы запустить фактический контейнер. Тип контейнера не имеет никакого отношения к тому, как вы собираете ваши образы. Образы хранятся в репозитории и доступны по запросу для разворачивания контейнеров, где и когда они необходимы, будь то контейнеры Windows Server или Hyper-V.

Связь с Docker

Помимо компании, Docker также является проектом с открытым кодом, которая облегчает процесс развертывания и управления контейнерами. Контейнеры Windows теперь являются частью этого проекта, и сообщество Docker интенсивно работает, чтобы полностью интегрировать контейнеры Windows в экосистему Docker. В рамках этой же инициативы Docker предлагает Docker Engine для Windows, и Docker Client для Windows.

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

Тем не менее, Docker Engine не является частью установки Windows. Вы должны загрузить, установить и настроить его отдельно от Windows. Docker Engine работает как служба Windows. Можно настроить эту службу, используя файл конфигурации или Windows Service Control Manager (SCM). Например, вы можете установить отладку по умолчанию и параметры журнала или настроить, как Docker Engine принимает сетевые запросы. Microsoft рекомендует использовать файл конфигурации, а не SCM, но отмечает, что не каждый параметр конфигурации в файле применим к контейнерам Windows.

Docker Engine по существу делает всю рутинную работу по управлению контейнером за вас, расширяя API, необходимый для клиента Docker для взаимодействия Docker Engine. Клиент представляет собой интерфейс командной строки, который предоставляет набор команд для управления образами и контейнерами. Это те же самые команды, которые позволяют создавать и запускать контейнеры Docker в Linux. Хотя вы и не можете запустить контейнер для Windows на Linux или контейнер Linux на Windows, вы можете использовать один и тот же клиент для управления как Linux и Windows контейнерами, будь то контейнеры Windows Server или Hyper-V.

Как и с Docker Engine, вам необходимо загрузить и установить клиент Docker самостоятельно. Клиент может работать как на Windows 10 или Windows Server 2016. Вам нужно только указать клиенту Docker службу, которой необходимо начать управлять.

Мир Windows

Microsoft и Docker осталось сделать еще много работы, прежде чем контейнеры для Windows будут полностью функциональны, но то, что мы видим уже сейчас представляет собой значительный шаг вперед. Пользователям Windows, наконец, получат возможность пользоваться всеми преимуществами гибкости и переносимости, которые контейнеры предлагали миру Linux на протяжении более десяти лет.

Привет, Хабр! Представляю вашему вниманию перевод статьи Deep dive into Windows Server Containers and Docker – Part 2 – Underlying implementation of Windows Server Containers от автора Cornell Knulst.

В данной статье рассказывается об особенностях реализации 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% ошибочно и может сильно запутать. Контейнеры отличаются от виртуальных машин, и поэтому я всегда представляю контейнеры как “что-то, отличное от виртуальных машин” или даже говорю “контейнеры — это НЕ виртуальные машины”. Но в чём же разница? И почему она так важна?

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

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

(Изображение Albund | Dreamstime.com)

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

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

В эпоху развития облачных и мобильных технологий приложения задают ритм для инноваций. Контейнеры и связанная с ними экосистема позволяют создавать сервисы нового поколения. До недавнего времени контейнеры были вещью из мира Linux. Но с выходом Windows Server 2016 ситуация изменилась — технологии контейнеризации стремительно ворвались в мир Windows.

Согласно «Википедии», контейнеризация — это система виртуализации на уровне ОС, позволяющая создавать несколько изолированных экземпляров операционной системы на одном узле. Каждый контейнер, в отличие от виртуальной машины, имеет собственное пространство процессов и сетевой стек, но при этом все контейнеры в рамках хоста используют один и тот же экземпляр ядра операционной системы.

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

Контейнеры как технология существуют еще с 80-х годов, то есть они возникли еще до привычных нам виртуальных машин. В 2000-е появились первые коммерческие продукты для организации контейнеров на Linux и Unix (Virtuozzo, HP-UX Containers), а в 2008 году появилась нативная поддержка контейнеризации в ядре Linux (LXC).

В последние годы контейнеры обрели новую популярность с появлением таких продуктов, как Docker и Apache Mesos, которые сделали работу с контейнерами проще, удобнее, расширили границы масштабируемости систем, а также позволили шире применять контейнеры в Enterprise-системах за счёт мощных возможностей управления.

Год назад компания Microsoft сделала первый серьёзный шаг в мир контейнеров, запустив Azure Container Service — облачный сервис контейнеризации на базе Docker Swarm и DC/OS (Apache Mesos). Этот сервис позволяет тысячам заказчиков по всему миру эффективно развёртывать масштабные решения с использованием контейнеров популярных форматов Docker и Mesos на базе ОС Linux.

Концепция контейнеров долгое время оставалась вещью из мира Linux (ну или Unix). Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux, которые могли эффективно использовать контейнеры для целей Dev/Test, а потом так же быстро и эффективно переносить контейнеры в продуктивную среду. Windows Server 2016 меняет эту парадигму: теперь контейнеры доступны и для мира Windows, причём сразу в двух лицах — в виде контейнеров Windows Server и в виде контейнеров Hyper-V. Причём Windows Server для контейнеризации использует одну из самых популярных систем в индустрии — Docker.

Кстати, Microsoft идёт по пути скрещивания этих двух по сути параллельных продуктов — Azure Container Service и Windows Server Containers (и да, прошу их не путать). В данный момент идёт раннее тестирование Windows Server Containers в Azure Container Service, записаться можно вот здесь. Так что в будущем Azure Container Service сможет работать не только с контейнерами Linux, но и с контейнерами на базе Windows Server.

Типы контейнеров Windows

Контейнеры в Windows Server 2016 создаются из специальных шаблонов в формате Docker. Вы можете создавать свои шаблоны или воспользоваться богатым выбором из библиотеки Docker Hub. Подключение к контейнеру производится через командную строку, так как собственной графической оболочки контейнер не имеет. Контейнер не нужно патчить или обслуживать — вы просто создаёте новый шаблон контейнера и разворачиваете из него новые контейнеры вместо старого за секунды.

Контейнеры в Windows Server 2016 делятся на два типа:

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

Контейнеры Hyper-V — открывают более широкие возможности изоляции по сравнению с контейнерами Windows Server, так как каждый контейнер запускается в виртуальной машине со специальной легковесной версией ОС. В этой конфигурации каждый контейнер использует свою копию ядра, изолированную от других контейнеров, но при этом он обладает характеристиками обычного контейнера (быстрое развёртывание, использование библиотеки шаблонов Docker, stateless, мощные возможности по управлению). 

Принципы работы контейнера Windows

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

При создании контейнеров Windows и последующей работе с ними пригодятся перечисленные ниже основные понятия. 

Узел контейнера. Физический или виртуальный компьютер под управлением Windows Server 2016, настроенный для работы с контейнерами Windows. На хосте работают один или несколько контейнеров Windows.

Образ контейнера. По мере того как в файловую систему или реестр контейнера вносятся изменения (например, при установке программного обеспечения), они регистрируются в «песочнице». Во многих случаях может потребоваться зарегистрировать это состояние, чтобы применить внесенные изменения при создании новых контейнеров. В этом и заключается суть образа: после остановки работы контейнера можно либо отключить «песочницу», либо преобразовать ее в новый образ контейнера. Предположим, вы развернули контейнер в образе Windows Server Core. Затем вы устанавливаете в этот контейнер MySQL. Создание нового образа на базе этого контейнера будет происходить аналогично его развертыванию. Этот образ будет содержать только внесенные изменения (MySQL) и при этом работать в виде слоя поверх образа ОС контейнера.

«Песочница». После запуска контейнера все операции записи (изменения файловой системы и реестра либо установка программного обеспечения) регистрируются на уровне «песочницы». 

Образ ОС контейнера. Контейнеры развертываются из образов. Образ ОС контейнера — это первый из возможного множества слоев образа, составляющих контейнер. Этот образ представляет собой среду операционной системы. Образ ОС контейнера постоянный, его невозможно изменить.

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

Использование контейнеров Windows

Образ Docker можно создать где угодно, начиная с компьютера разработчика и заканчивая тестовыми и рабочими компьютерами. К тому же его развертывание в любой среде будет выполнено одинаково и за считанные секунды. Благодаря этому появилась развитая и расширяющаяся экосистема приложений, запакованных в контейнеры Docker. При этом в общедоступных репозиториях Docker Hub открытого реестра контейнерных приложений, который Docker обслуживает, в настоящее время опубликовано более 180 000 приложений. 

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

Так как контейнер содержит все необходимое для запуска приложения, он отличается высокой переносимостью и может запускаться на любом компьютере под управлением Windows Server 2016. Можно создать и протестировать контейнер локально, а затем развернуть его образ на сервере поставщика услуг, а также в частном или общедоступном облаке компании. Адаптивность контейнеров позволяет использовать современные модели разработки приложений в крупномасштабных виртуализированных и облачных средах.

Контейнеры позволяют масштабировать веб-сервисы эффективнее, так как новые экземпляры стартуют в разы быстрее, чем виртуальные машины (плюс виртуальной машине, в отличие от контейнера, еще нужно время на provisioning).

Также контейнеры значительно менее требовательны к оперативной памяти, нежели виртуальные машины.

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

Если вам интересна тема контейнеров в Windows Server 2016, рекомендуем прочитать официальную документацию, статью Марка Руссиновича и посмотреть доклад по теме с конференции Microsoft Ignite.

You can improve the security of your application development infrastructure by reducing the size and scope of application and compute resources. One way to do this is to containerize workloads. Windows Server and Microsoft Hyper-V containers enable you to isolate workloads from each other and the OS. Even if a container is compromised by an attacker, it will be difficult for the attacker to access the host OS. Containers also provide a standardized environment for development, test and production teams.

Containers

Containers provide an isolated and portable operating environment for apps. From the app’s perspective, a container appears to be a complete, isolated Windows OS with its own file system, devices and configuration. Therefore, in many respects, containers are like VMs because they run an OS, they support a file system, and you can access them across a network similar to any other physical machine or VM.

Containers are virtual environments that share the kernel of the host OS but provide user space isolation, so they provides an ideal environment in which an app can run without affecting the rest of the user mode components of the OS and without the other user mode components affecting the app. Using containers, developers can create and test apps quickly in an isolated environment while using only a few OS resources. This means that containers do not need all of the processes and services that an OS on a VM might use.

Windows Server 2016 supports two types of containers:

  • Windows Server containers. These containers provide app isolation through the process and namespace isolation technology. Windows Server containers share the OS kernel with the container host and with all other containers that run on the host.
  • Hyper-V containers. These containers expand on the isolation that Windows Server containers provide by running each container in a highly optimized VM.

Using containers has multiple benefits. The reduced OS size means that you must maintain fewer operating-system components, which in turn results in fewer potential security risks. The reduced OS size also helps improves scalability.

Docker

To run an application workload in a container, you must use Docker. Docker is a collection of open-source tools and cloud-based services that provide a common model for packaging (containerizing) app code into a standardized unit for software development. This standardized unit, or Docker container, is software that is wrapped in a complete file system that includes everything it needs to run, including code, runtime, system tools, system libraries, and anything else you can install on a server. You must download Docker separately; it is not part of the Windows Server 2016 installation media.

Nano Server

Microsoft Nano Server is a fairly new installation option for Windows Server 2016. It is a lightweight operating system tailored for use with virtualized container instances. There is no UI; you must manage Nano Server remotely using PowerShell, but this PowerShell differs from the standard one. As of Windows Server version 1803, Nano Server is available only as a container-based OS image, and you must run it as a container in a container host, such as Docker. You can troubleshoot these new Nano containers using Docker and run them in IoT Core.

A Nano Server instance cannot function as an Active Directory domain controller. In particular, it does not support the following features:

  • Group Policy
  • Network interface card teaming
  • Virtual host bus adapters
  • Proxy server access to the internet
  • System Center Configuration Manager
  • System Center Data Protection Manager

Nano Server supports the following roles:

  • File Services
  • Hyper-V
  • IIS
  • DNS Server

 Loading …

Product Evangelist at Netwrix Corporation, writer, and presenter. Ryan specializes in evangelizing cybersecurity and promoting the importance of visibility into IT changes and data access. As an author, Ryan focuses on IT security trends, surveys, and industry insights.

Tags:
Windows, Docker, Linux

Когда вы начнете работать с контейнерами, вы увидите много сходства между контейнером и виртуальной машиной; но, по сути, это два совершенно разных понятия. Контейнеры собираются изменить способ разработки Windows-разработок в следующем году, и они уже лежат в основе большой работы по ускорению процесса доставки. Мы объясним, как использовать функцию Windows Containers.

Введение

Контейнеры Windows революционизируют виртуализацию и процесс DevOps.

С Windows Server 2016 Microsoft представляет новую функцию под названием Windows Containers. Организации, которые обновляют свои серверы до этой новой операционной системы, смогут использовать контейнеры прямо из разработки в производственную среду.

Мы не будем углубляться в концепцию контейнеров, но в этой серии расскажем, как создавать, запускать, конвертировать и управлять вашими контейнерами Windows.

Основы Windows Containers

Прежде чем начать практическую сторону Windows Containers, мы должны вкратце осветить основы этой новой функции.

Контейнеры упаковывают программное обеспечение внутри полной файловой системы, которая содержит все, что нужно для запуска: код, среда выполнения, системные инструменты и системные библиотеки. Это гарантирует, что он всегда будет работать одинаково, независимо от среды, в которой он работает. Для достижения этой цели Windows использует изоляцию пространства имен, управление ресурсами и технологические процессы, чтобы ограничить файлы, сетевые порты и запущенные процессы, к которым может обращаться каждый контейнер, чтобы приложения, работающие в контейнерах, не могли взаимодействовать или видеть другие запущенные приложения в ОС хоста или в других контейнерах.

Виртуальные машины против контейнеров

Виртуальная машина является автономной и имеет собственную операционную систему, собственные приложения и собственные ресурсы (память, процессор и т. д.). Следующая схема показывает три виртуальных машины, размещенных на одном и том же физическом узле. Каждая виртуальная машина использует свою собственную ОС, библиотеки и т. Д. В результате они занимают значительное количество памяти.

Архитектура виртуальных машин

Довольно часто разработчикам приходится очень быстро тестировать приложения с разными версиями. Затем они должны попросить команду IT Ops развернуть одну или несколько машин (виртуальных или физических): это трудоемкий процесс. VM также потребляют значительные ресурсы, такие как память и пространство для хранения. Вот почему контейнеры удивительно полезны для процесса DevOps:

Архитектура контейнеров

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

Таким образом, преимущества контейнеров Windows заключаются в следующем:

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

Наконец, философия контейнера — это «одна услуга на контейнер»,

Windows Server Containers против Hyper-V Containers

Microsoft включает два разных типа контейнера. Первый тип основан на образовании Windows Server Core и называется контейнером Windows Server. Второй называется контейнером Hyper-V и основана на образовании Windows Nano Server. Контейнеры Hyper-V расширяют изоляцию, предоставляемую контейнерами Windows Server, запустив каждый контейнер в высоко оптимизированной виртуальной машине, чтобы обеспечить полную безопасную изоляцию. Ядро хоста контейнера не используется совместно с другими контейнерами Hyper-V. Если весь код, запущенный на хосте, надежен, то изоляция, предоставляемая контейнерами Windows, скорее всего, будет адекватной. Но если мы не доверяем коду, то контейнеры Hyper-V обеспечивают тот же уровень изоляции, что и виртуальные машины, но со многими преимуществами стандартных контейнеров.

Обратите внимание, что контейнеры Hyper-V управляются только Docker, а виртуальные машины Hyper-V управляются традиционными инструментами, такими как Hyper-V Manager. На практике загрузка Hyper-V контейнеров занимает больше времени, чем контейнеры Windows Server, но они намного быстрее, чем виртуальная машина с полной ОС (даже на Nano Server).

Docker

В октябре 2014 года Microsoft Corp и Docker объявили о стратегическом партнерстве, которое обеспечит гибкость, переносимость и безопасность платформы Docker для Windows Server.

Контейнеры Windows Server 2016, работающие от Docker Engine

Необходимо понимать, что Windows Server 2016 не может запускать контейнеры Linux в формате Docker, а только контейнеры Windows. Зачем? Поскольку для Linux-контейнеров требуются API-интерфейсы Linux из ядра-хозяина, а для контейнеров Windows Server требуются API-интерфейсы Windows для ядра Windows-хоста.

Однако процесс управления контейнерами Linux и Windows строго идентичен. Следующая схема описывает платформу Docker:

Платформа Docker

Ниже приведен краткий обзор жаргонов Windows Containers с их значением:

  • Container Host: физическая или виртуальная компьютерная система, настроенная с использованием функции Windows Containers
  • Container Image: Изображение контейнера содержит базовую операционную систему, приложение и все зависимости приложения, которые необходимы для быстрого развертывания контейнера.
  • Container OS Image: Изображение операционной системы контейнера — это среда операционной системы.
  • Container Registry: изображения контейнеров хранятся в реестре контейнеров и могут быть загружены по требованию. Это место, где публикуются изображения контейнеров. Реестр может быть удаленным или локальным.
  • Docker Engine: Это ядро ​​платформы Docker. Облегченное время выполнения контейнера, которое создает и запускает ваш контейнер.
  • Docker file: файлы Docker используются разработчиками для создания и автоматизации создания изображений контейнеров. С файлом Docker демон Docker может автоматически создавать образ контейнера.

Docker предоставляет центральный репозиторий, называемый Docker Hub (https://hub.docker.com/), общедоступный реестр контейнерных приложений, поддерживаемый Docker. Контейнерные изображения могут быть опубликованы непосредственно в этом репозитории для совместного использования с сообществом Docker. На Docker Hub уже много изображений. Например:

  • SQL 
  •  WordPress 
  • IIS 
  •  …

Вы можете запустить частный репозиторий локально. Посредством этого URL-адреса Microsoft имеет собственный публичный и официальный репозиторий: https://hub.docker.com/u/microsoft/

Контейнеры Windows на практике

Перед развертыванием контейнеров Windows вы должны подготовить свою среду с некоторыми предварительными условиями. Для этого вы можете использовать физическую или виртуальную машину, это зависит от вас. В нашем случае мы будем использовать виртуальную машину со следующими характеристиками:

  • Система под управлением Windows Server 2016 (или Windows 10). Это самая важная предпосылка. Советуем вам работать с версией Datacenter из-за лицензирования (больше информации в конце статьи). Вы можете использовать Windows Server Core для своего контейнера, а не версию Windows, которая включает полный пользовательский интерфейс. 
  • Разрешения администратора на хосте контейнера 
  • Минимальное свободное пространство для хранения изображений и сценариев развертывания 
  • Ваш сервер должен быть современным

Хорошо, давайте начнем с установки функции Windows Containers на хосте контейнера. Для выполнения этой задачи запустите следующую команду PowerShell:

PS C:\Users\Administrator> Install-WindowsFeature Containers

Success Restart Needed Exit Code      Feature Result

      

True    Yes            SuccessRest... {Containers}

WARNING: You must restart this server to finish the installation process.

Чтобы применить изменения с помощью командлета Restart-Computer, необходимо перезапустить: 

PS C:\Users\Administrator> Restart-Computer

Затем проверьте, что новая функция включена:

PS C:\Users\Administrator> Get-WindowsFeature containers

Display Name       Name                       Install State

                             

[X] Containers     Containers                     Installed

Контейнеры Windows тесно связаны с Docker; вы должны установить Docker Engine на хост контейнера. Для достижения этой цели у вас есть две возможности: 

Первым из них является развертывание Docker из репозитория PSGallery: 

PS C:\Users\Administrator> Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

NuGet provider is required to continue

PowerShellGet requires NuGet provider version ‘2.8.5.201’ or newer to interact with NuGet-based repositories. The NuGet

provider must be available in ‘C:\Program Files\PackageManagement\ProviderAssemblies’ or

‘C:\Users\Administrator\AppData\Local\PackageManagement\ProviderAssemblies’. You can also install the NuGet provider by

running ‘Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force’. Do you want PowerShellGet to install

and import the NuGet provider now?

[Y] Yes  [N] No  [S] Suspend  [?] Help (default is «Y»):

PS C:\Users\Administrator> Install-Package -Name docker -ProviderName DockerMsftProvider

The package(s) come(s) from a package source that is not marked as trusted.

Are you sure you want to install software from ‘DockerDefault’?

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is «N»): Y

Install-Package : KB3176936 or later is required for docker to work

At line:1 char:1

+ Install-Package -Name docker -ProviderName DockerMsftProvider

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],

   Exception

    + FullyQualifiedErrorId : RequiredWindowsUpdateNotInstalled,Install-Package,Microsoft.PowerShell.PackageManagement

   .Cmdlets.InstallPackage

Докер для Windows Server 2016 требует обновления «KB3176936». Его можно загрузить с веб-сайта Центра обновления Windows, а затем установить вручную: 

http://www.catalog.update.microsoft.com/search.aspx?q.. 

Или вы можете выполнить эту задачу с помощью утилиты sconfig. Затем выберите число 6: 

===============================================================================

                         Server Configuration

===============================================================================

1) Domain/Workgroup:                    Domain:  get-cmd.Local

2) Computer Name:                       SRV1

3) Add Local Administrator

4) Configure Remote Management          Enabled

5) Windows Update Settings:             DownloadOnly

6) Download and Install Updates

7) Remote Desktop:                      Enabled (more secure clients only)

8) Network Settings

9) Date and Time

10) Telemetry settings                  Basic

11) Windows Activation

12) Log Off User

13) Restart Server

14) Shut Down Server

15) Exit to Command Line

Windows загрузит и установит обновления: 

Microsoft (R) Windows Script Host Version 5.812

Copyright (C) Microsoft Corporation. All rights reserved.

Search for for (A)ll updates or (R)ecommended updates only? a

Searching for all applicable updates...

Downloading updates...

Второй способ — установить версию Docker для разработки, чтобы иметь новейшие функции. Вы должны скачать Docker прямо с официального сайта. Используйте командлет Invoke-WebRequest: 

PS > Invoke-WebRequest «https://master.dockerproject.org/windows/amd64/docker-1.14.0-dev.zip» -OutFile «$env:TEMP\docker.zip» UseBasicParsing

Затем извлеките архив с помощью командлета Expand-Archive: 

PS > Expand-Archive -Path «$env:TEMP\docker.zip» -DestinationPath $env:ProgramFiles

Теперь вы можете создать переменную окружения: 

PS > $env:path += «;$env:ProgramFiles\Docker»

PS > $existingMachinePath = [Environment]::GetEnvironmentVariable(«Path»,[System.EnvironmentVariableTarget]::Machine)

PS > [Environment]::SetEnvironmentVariable(«Path», $existingMachinePath + «;$env:ProgramFiles\Docker», [EnvironmentVariableTarget]::Machine)

Чтобы закончить, установите Docker в качестве службы Windows. Итак, запустите следующую команду для регистрации файла dockerd.exe:

PS > dockerd register-service

После установки сервис может быть запущен: 

PS > Start-Service Docker

WARNING: Waiting for service ‘Docker Engine (Docker)’ to start...

PS > Get-Service -name «docker*»

Status   Name               DisplayName

                 

Running  docker             Docker Engine

Чтобы отобразить информацию о докере, выполните следующие действия:

PS C:\> docker info

Containers: 0

Running: 0

Paused: 0

Stopped: 0

Images: 0

Server Version: 1.14.0-dev

Storage Driver: windowsfilter

Windows:

Logging Driver: json-file

Plugins:

Volume: local

Network: l2bridge l2tunnel nat null overlay transparent

Swarm: inactive

Default Isolation: process

Kernel Version: 10.0 14393 (14393.0.amd64fre.rs1_release.160715-1616)

Operating System: Windows Server 2016 Datacenter

OSType: windows

Architecture: x86_64

CPUs: 1

Total Memory: 1.933 GiB

Name: SRV1

ID: VB3B:IGYN:GEFL:6ML7:OQJM:GMCJ:HDNU:Z57W:SWYI:Z2I3:WZKG:O2L4

Docker Root Dir: C:\ProgramData\docker

Debug Mode (client): false

Debug Mode (server): false

Registry: https://index.docker.io/v1/

Experimental: false

Insecure Registries:

127.0.0.0/8

Live Restore Enabled: false

Итак, хост контейнера запущен и работает, поэтому мы можем развернуть наш первый Windows Container! В первом примере мы будем развертывать контейнер IIS, запускаем следующую команду: 

PS > Docker run -d -p 8080:80 name iis microsoft/iis

Unable to find image ‘microsoft/iis:latest’ locally

latest: Pulling from microsoft/iis

c480435b7cba: Downloading [==>                                                ] 220.1 MB/4.175 GB

2acd7c473906: Downloading [=============>                                     ] 240.1 MB/922.1 MB

a837699b27ea: Download complete

e4e8167eafc5: Download complete

0344b06e0e62: Download complete

Ниже приведен синтаксис команды Docker: 

PS > docker run PUBLIC_PORT:PRIVATE_CONTAINER_PORT CONTAINER_NAME IMAGE

Контейнеры используют концепцию PAT (Port Address Translation). Это означает, что вы должны открывать порты контейнера через хост контейнера. В нашем примере Docker свяжет контейнер порта номер 80 с номером 8080 контейнера порта. Затем, когда мы попытаемся открыть веб-сайт IIS, расположенный внутри контейнера, я буду использовать открытый порт 8080. 

Параметр «Name» добавляет дружественное имя в контейнер. Это не обязательно, но может быть полезно для последующего управления вашими контейнерами. 

Наконец, вы должны указать имя образа контейнера. Здесь мы выбираем образ IIS, предоставленный Microsoft. 

Когда я запускаю команду, Windows проверяет, доступно ли изображение локально (на хосте контейнера). Если нет, то Docker извлекает изображение из концентратора Docker.

PS > Docker run -d -p 8080:80 name iis microsoft/iis

Unable to find image ‘microsoft/iis:latest’ locally

Когда это будет сделано, ваш Windows Container будет запущен. Наш хост контейнера имеет следующий IP-адрес: 192.168.0.132, поэтому мой веб-сайт IIS доступен с 192.168.0.132:8080 

Контейнер IIS 

Дальнейшая работа

Image2Docker 

Допустим, у вас есть сервер, который был любовно собран вручную и который вы хотите контейнеризировать? Ну, вы можете использовать модуль PowerShell «Image2Docker», доступный в GitHub: https://github.com/docker/communitytools-image2docker.., который передает рабочие нагрузки приложений Windows из виртуальных машин на изображения Docker. Таким образом, вы можете легко конвертировать службы Windows в контейнеры Windows, такие как: сайты IIS, DNS, DHCP, … 

Лицензирование 

Официальный сайт содержит относительно небольшую информацию о лицензировании, но в соответствии с Техническим паспортом лицензирования Windows Server 2016 Standard Edition предоставляет права на до 2 контейнеров Hyper-V, когда все физические ядра на сервере лицензированы и контейнеры Windows Server неограничены для обоих выпусков.

Заключение

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

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

В этой статье мы видели, как развернуть наш первый контейнер Windows. Вы скоро заметите, что контейнеры замечательны для разработчиков и администраторов, поскольку контейнеризация обеспечивает большую гибкость в использовании и упрощает развертывание. Есть еще много вещей, которые нужно сказать о контейнерах, поэтому в следующих статьях мы объясним: 

  • Какие нужны команды Docker для начала работы с Docker, 
  • Как найти и загрузить изображения контейнеров, 
  • Как использовать контейнеры Hyper-V, 
  • Как создать собственное изображение Контейнера, 
  • Как конвертировать службы Windows для работы в контейнере Windows

Надеюсь, что эта статья поможет вам расширить свои знания о контейнерах Windows.

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Nikon d3200 драйвера для windows 10
  • Как воспроизвести mp4 на windows 10
  • Встроенный инструмент проверки системных файлов windows
  • Журнал syslog используется для windows
  • Dynamic smart array b140i controller driver for windows 2016