Windows server контейнеры. «Пакуем окна»: изучаем технологию контейнеров от Microsoft

Свершилось! То ли молитвы помогли, то ли жертвоприношения, но теперь можно запускать Docker контейнеры с Windows внутри. Прекрасная новость пришла одновременно с релизом Windows Server 2016. И речь не идёт о какой-нибудь хитро-спрятанной виртуальной машине, или эмуляции Windows на Linux ядре — запускается настоящая Windows в настоящем Docker, с работающими Dockerfile, docker-compose и прочими docker-приблудами.

Ограничения

Но это не значит, что теперь можно запускать любой контейнер где угодно. Из-за того, что Docker контейнеры «отдалживают» ядро операционной системы у своего хоста (а иначе им пришлось бы иметь свою ОС и превращаться в виртуальную машину), Windows контейнеры можно запускать только на свежих Windows 10 Pro Anniversary Update и Windows Server 2016 .

Второй момент, запустить нативно Linux контейнер на Windows всё еще нельзя. В Anniversary Update есть собственная Linux подсистема (с помощью которой можно запустить настоящий Bash, например), но она не дотягивает для полноценного Linux-ядра, так что для того же контейнера с Убунтой на Windows всё еще нужна спрятанная виртуальная машина.

Наконец, одновременно запускать те и другие контейнеры на Windows машине можно, но с танцем. Если выполнить такую команду в Windows Server 2016 с установленным Docker (год назад я бы обозвал такое колдовством), оно сработает:

Но если после этой команды попробовать запустить Ubuntu контейнер, Docker взгрустнёт:

Проблема в том, что Windows и Linux контейнера обслуживаются разными Docker-демонами, которые, тем не менее, используют один и тот же канал для общения с командной строкой. То есть в каждый момент времени только один демон может быть активным. На официальном Докер-сайте есть бета «Docker for Windows «, которая пытается справиться проблемой (пока только на Windows 10 Pro и Enterprise). Но даже с ней, чтобы переключиться с Windows на Linux контейнеры, нужно либо лезть в меню настроек, либо общаться с командной строкой:

PowerShell

& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon

& "C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon

Образы с Windows

Пока есть только два базовых образа с контейнерной Windows:

Сделать свой базовый образ (scratch image) — нельзя.

Образ Windows Server Core весит аж 10 гигов и в целом ведёт себя как полноценная Windows Server 2016. Например, MS SQL и полноценный.NET Framework устанавливаются там без проблем. Если ваше приложение не сильно зависит от UI, то установится и оно.

Nano Server слегка интереснее. Это очень оптимизированная и урезанная Windows Server, которая весит меньше гига. Но и ограничений хватает: нет 32-битных приложений, UI, RDP, порезаный PowerShell, и т.д. Но это не мешает поставить на Nano Server тот же IIS, .NET Core, и даже какой-нибудь MySQL.

И кто-нибудь мог представить пару лет назад, что в Dockerfile можно будет встретить сразу «Microsoft», «Windows» и «PowerShell»?

FROM microsoft/windowsservercore RUN powershell -Command....

FROM microsoft / windowsservercore

RUN powershell - Command . . . .

Это же Windows в Докере! До сих пор звучит абсурдно.

Степени изоляции

Windows контейнера можно запускать в двух режимах изоляции:

  • Windows Server Containers
  • Hyper-V Containers

В первом режиме Windows контейнера ведут себя так же, как и все остальные контейнера в Docker: делят общее ядро с операционной системой, контейнерные процессы изолированы, но всё еще видны в хостовом дереве процессов, и т. п. Это дефолтный и самый быстрый способ запустить контейнер в Windows.

Во втором случае контейнера попадают особую Hyper-V виртуальную машину. Это, конечно, плохо сказывается на скорости запуска, но зато и изоляция полная.

Заключение

Windows в Докере — это просто отличные новости. Даже если не бросаться упаковывать свои продукты по контейнерам, это прекрасный инструмент для того, чтобы изолировать свои юнит-тесты, рабочие машины, сервера для демонстраций, песочницы — всё то, для чего раньше приходилось создавать виртуальную машину. Если Microsoft еще умудрится запустить nanoserver на Linux, то я им прощу недавнее снятие с производства Microsoft Band 2, неосмотрительно купленный за два месяца до этого.

В *nix-системах изначально реализована многозадачность и предлагаются средства, позволяющие изолировать и контролировать процессы. Такие технологии, как chroot(), обеспечивающая изоляцию на уровне файловой системы, FreeBSD Jail, ограничивающая доступ к структурам ядра, LXC и OpenVZ, давно известны и широко используются. Но импульсом в развитии технологии стал Docker, позволивший удобно распространять приложения. Теперь подобное добралось и до Windows.

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

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

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

Отличие контейнеров от виртуальных машин заключается в том, что контейнеры не загружают собственные копии ОС, библиотеки, системные файлы и прочее. Операционная система как бы делится с контейнером. Единственное, что дополнительно требуется, - это ресурсы, необходимые для запуска приложения в контейнере. В результате контейнер стартует в считаные секунды и меньше нагружает систему, чем в случае применения виртуальных машин. Docker в настоящее время предлагает 180 тысяч приложений в репозитории, а формат унифицирован в Open Container Initiative (OCI). Но зависимость от ядра подразумевает, что в другой ОС контейнеры не будут работать. Контейнеры Linux требуют Linux API, соответственно Windows в Linux работать не станет.

Разработчики Windows до недавнего времени предлагали две технологии виртуализации: виртуальные машины и виртуальные приложения Server App-V. Каждая имеет свою нишу применения, свои плюсы и минусы. Теперь ассортимент стал шире - в Windows Server 2016 анонсированы контейнеры (Windows Server Containers). И хотя на момент TP4 разработка еще не была завершена, уже вполне можно посмотреть новую технологию в действии и сделать выводы. Нужно отметить, что, догоняя и имея на руках готовые технологии, разработчики MS пошли в некоторых вопросах чуть дальше, так что использование контейнеров стало проще и более универсальным. Главное отличие в том, что предложены два вида контейнеров: контейнеры Windows и контейнеры Hyper-V. В TP3 были доступны только первые.

Контейнеры Windows используют одно ядро с ОС, которое динамично разделяют между собой. Процесс распределения (CPU, ОЗУ, сеть) берет на себя ОС. При необходимости можно ограничить максимально доступные ресурсы, выделяемые контейнеру. Файлы ОС и запущенные службы проецируются в пространство имен каждого контейнера. Такой тип контейнера эффективно использует ресурсы, уменьшая накладные расходы, а значит, позволяет более плотно размещать приложения. Этот режим в чем-то напоминает FreeBSD Jail или Linux OpenVZ.

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

Важная особенность контейнеров в Win 2016 состоит в том, что тип выбирается не в момент создания, а в момент деплоя. То есть любой контейнер может быть запущен и как Windows, и как Hyper-V.

В Win 2016 за контейнеры отвечает слой абстракции Contаiner Management stack, реализующий все нужные функции. Для хранения используется формат образа жесткого диска VHDX. Контейнеры, как и в случае с Docker, сохраняются в образы в репозитории. Причем каждый сохраняет не полный набор данных, а только отличия создаваемого образа от базового, и в момент запуска все нужные данные проецируются в память. Для управления сетевым трафиком между контейнером и физической сетью служит Virtual Switch.

В качестве ОС в контейнере может использоваться Server Core или Nano Server. Первый, в общем-то, давно не новинка и обеспечивает высокий уровень совместимости с имеющимися приложениями. Второй - еще более урезанная версия для работы без монитора, позволяющая запускать сервер в минимально возможной конфигурации для использования с Hyper-V, файловым сервером (SOFS) и облачными службами. Графический интерфейс, естественно, отсутствует. Содержит только самые необходимые компоненты (.NET с CoreCLR, Hyper-V, Clustering и так далее). Но в итоге занимает на 93% меньше места, требует меньше критических исправлений.

Еще интересный момент. Для управления контейнерами, кроме традиционного PowerShell, можно использовать и Docker. И чтобы обеспечить возможность запуска неродных утилит на Win, MS заключила партнерское соглашение для расширения API Docker и набора инструментов. Все разработки открыты и доступны в официальном GitHub проекта Docker . Команды управления Docker применимы ко всем контейнерам как Win, так и Linux. Хотя, естественно, контейнер, созданный на Linux, запустить в Windows невозможно (как и наоборот). В настоящий момент PowerShell по функциям ограничен и позволяет работать только с локальным репозиторием.

Установка Containers

В Azure есть необходимый образ Windows Server 2016 Core with Containers Tech Preview 4, который можно развернуть и использовать для изучения контейнеров. Иначе необходимо все настроить самому. Для локальной установки нужен Win 2016, причем, так как Hyper-V в Win 2016 поддерживает вложенную виртуализацию (Nested virtualization), это может быть как физический, так и виртуальный сервер. Сам процесс установки компонента стандартен. Выбираем соответствующий пункт в мастере добавления ролей и компонентов или, используя PowerShell, даем команду

PS> Install-WindowsFeature Containers

В процессе установится и сетевой контроллер Virtual Switch, его сразу необходимо настроить, иначе дальнейшие действия будут выдавать ошибку. Смотрим названия сетевых адаптеров:

PS> Get-NetAdapter

Для работы нам нужен контроллер с типом External. У командлета New-VMSwitch много параметров, но для примера обойдемся минимальными установками:

PS> New-VMSwitch -Name External -NetAdapterName Ethernet0

Проверяем:

PS> Get-VMSwitch | where {$_.SwitchType –eq "External"}

Файрвол Windows будет блокировать соединения к контейнеру. Поэтому необходимо создать разрешающее правило, как минимум для возможности подключаться удаленно при помощи PowerShell remoting, для этого разрешим TCP/80 и создадим правило NAT:

PS> New-NetFirewallRule -Name "TCP80" -DisplayName "HTTP on TCP/80" -Protocol tcp -LocalPort 80 -Action Allow -Enabled True PS> Add-NetNatStaticMapping -NatName "ContainerNat" -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.1.2 -InternalPort 80 -ExternalPort 80

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

PS> https://aka.ms/tp4/Install-ContainerHost -OutFile C:\Install-ContainerHost.ps1 PS> C:\Install-ContainerHost.ps1

Есть еще один вариант - развернуть готовую виртуальную машину с поддержкой контейнера. Для этого на том же ресурсе есть скрипт, автоматически производящий все нужные операции. Подробная инструкция приведена на MSDN . Скачиваем и запускаем скрипт:

PS> wget -uri https://aka.ms/tp4/New-ContainerHost -OutFile c:\New-ContainerHost.ps1 PS> C:\New-ContainerHost.ps1 –VmName WinContainer -WindowsImage ServerDatacenterCore

Имя задаем произвольное, а -WindowsImage говорит о типе собираемого образа. Вариантами могут быть NanoServer, ServerDatacenter. Сразу ставится и Docker, за его отсутствие или наличие отвечает параметр SkipDocker и IncludeDocker. После запуска начнется загрузка и преобразование образа, в процессе нужно будет указать пароль для входа в VM. Сам ISO-файл достаточно большой, почти 5 Гбайт. Если канал медленный, файл можно скачать на другом компьютере, после чего переименовать в WindowsServerTP4 и скопировать в С:\Users\Public\Documents\Hyper-V\Virtual Hard Disks . Можем залогиниться в установленную виртуальную машину, указав пароль, заданный при сборке, и работать.

Теперь можно переходить непосредственно к использованию контейнеров.

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

Модуль Containers содержит 32 командлета PowerShell, документация по некоторым еще неполная, хотя, в общем, чтобы заставить все работать, достаточная. Перечень вывести просто:

PS> Get-Command -module Containers

Получить список доступных образов можно при помощи командлета Get-ContainerImage, контейнеров - Get-Container. В случае с контейнером в колонке Status будет показан его текущий статус: остановлен или запущен. Но пока технология находится в стадии разработки, MS не представила репозиторий, да и, как говорилось, пока PowerShell работает с локальным репозиторием, поэтому для экспериментов его придется создать самому.

Итак, сервер с поддержкой у нас есть, теперь нужны сами контейнеры. Для этого ставим провайдер пакетов ContainerProvider.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

В марте 2013 года Соломан Хайкс объявил о старте открытого проекта, впоследствии ставшего известным как Docker. В последующие месяцы его активно поддержало сообщество Linux, а осенью 2014 года Microsoft объявила о планах реализации контейнеров в Windows Server 2016. Компания WinDocks, соучредителем которой я являюсь, выпустила независимую версию открытого кода Docker для Windows в начале 2016 года с акцентом на первоклассную поддержку контейнера в SQL Server. Контейнеры быстро становятся центром внимания в отрасли. В этой статье мы рассмотрим контейнеры и их использование разработчиками и администраторами баз данных SQL Server

Принципы организации контейнеров

Контейнеры определяют новый метод упаковывания приложений, в сочетании с изоляцией пользователей и процессов, для мультиабонентских приложений. Различные реализации контейнеров для Linux и Windows существуют уже много лет, но с выходом Windows Server 2016 мы получили фактический стандарт Docker. Сегодня API-интерфейс и формат контейнера Docker поддерживаются в общедоступных службах AWS, Azure, Google Cloud, всех дистрибутивах Linux и Windows. У элегантной структуры Docker есть важные преимущества.

  • Переносимость. Контейнеры содержат программные зависимости приложений и выполняются неизменными на ноутбуке разработчика, общем тестовом сервере и в любой общедоступной службе.
  • Экосистема контейнеров. API-интерфейс Docker является средоточием отраслевых новинок с решениями для мониторинга, ведения журнала, хранения данных, оркестровки кластеров и управления.
  • Совместимость с общедоступными службами. Контейнеры спроектированы для архитектуры микрослужб, горизонтального масштабирования и временных рабочих нагрузок. Контейнеры проектируются таким образом, чтобы их можно было при желании удалить и заменить, а не исправлять или обновлять.
  • Скорость и экономия. Для создания контейнеров требуется несколько секунд; обеспечена эффективная поддержка мультиабонентности. У большинства пользователей количество виртуальных машин сокращается в три-пять раз (рисунок 1).

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

SQL Server поддерживает мультиабонентность с применением именованных экземпляров в течение десяти лет, так в чем же ценность контейнеров SQL Server?

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

Благодаря быстродействию и автоматизации контейнеры SQL Server идеальны для организации производственной среды разработки и контроля качества. Каждый член группы работает с изолированными контейнерами в общей виртуальной машине, с трех-пяти-кратным сокращением числа виртуальных машин. В результате мы получаем существенную экономию на обслуживании виртуальных машин и стоимости лицензий Microsoft. Контейнеры легко интегрировать в массивы сети хранения данных (SAN) с использованием реплик хранилища и клонов баз данных (рисунок 2).

Подключенная база данных объемом 1 Тбайт формируется в экземпляре контейнера менее чем за одну минуту. Это значительное улучшение по сравнению с серверами с выделенными именованными экземплярами или предоставлением виртуальных машин для каждого разработчика. Одна компания использует восьмиядерный сервер для обслуживания до 20 контейнеров SQL Server по 400 Гбайт. В прошлом для подготовки каждой виртуальной машины требовалось более часа, а экземпляры контейнеров выдаются за две минуты. Таким образом, удалось в 20 раз сократить число виртуальных машин, уменьшить число ядер процессора в 5 раз и резко сократить расходы на оплату лицензий Microsoft. Кроме того, повысились гибкость и быстрота реагирования в бизнесе.

Применение контейнеров SQL Server

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

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

Каждый контейнер содержит частную файловую систему, изолированную от ресурсов хоста. В приведенном на экране 2 примере контейнер строится с использованием MSSQL-2014 и venture.mdf. Формируются уникальный идентификатор ContainerID и порт контейнера.


Экран 2. Контейнер на базе SQL Server 2014 и venture.mdf

Контейнеры SQL Server обеспечивают новый уровень быстродействия и автоматизации, но их поведение точно такое же, как у обычных именованных пространств. Управление ресурсами можно реализовать с помощью инструментария SQL Server или через пределы ресурсов контейнера (экран 3).

Другие случаи применения

Контейнеры - самое распространенное средство организации среды для разработки и контроля качества, но появляются и другие области применения. Тестирование аварийного восстановления - простой, но многообещающий сценарий использования. Среди прочих - контейнеризация внутренней среды SQL Server для унаследованных приложений, таких как SAP или Microsoft Dynamics. Контейнеризованный внутренний компонент используется для предоставления рабочей среды для поддержки и текущего обслуживания. Применяются также оценочные контейнеры для поддержки рабочих сред с постоянными хранилищами данных. В одной из следующих статей я подробно расскажу о постоянных данных.

Компания WinDocks стремится еще более упростить использование контейнеров через веб-интерфейс. Другой проект сосредоточен на переносе контейнеров SQL Server в процессе DevOps или Continuous Integration с конвейерами CI/CD на основе Jenkins или Team City. Сегодня вы можете познакомиться с использованием контейнеров на всех редакциях Windows 8 и Windows 10, Windows Server 2012 или Windows Server 2016 с поддержкой всех выпусков, начиная с SQL Server 2008. с помощью вашей копии WinDocks Community Edition (https://www.windocks.com/community-docker-windows).

Изучаем технологию контейнеров
Windows Server 2016

Одной из примечательных новинок, появившихся в Windows Server 2016, является поддержка контейнеров. Познакомимся с ней поближе

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

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

В Windows Server 2016 в дополнение к существующим технологиям виртуализации – Hyper-V и виртуальные приложения Server App-V, добавилась поддержка контейнеров Windows Server Containers реализованная через слой абстракции Contаiner Management stack реализующий все нужные функции. Анонсирована технология еще в Technical Preview 4, но с тех пор много что изменилось в сторону упрощения и инструкции написанные раньше можно даже не читать. Приэтом было предложено два вида «своих» контейнеров – контейнеры Windows и контейнеры Hyper-V. И наверное еще одной главной возможностью, является использование для управления контейнеров помимо командлетов PowerShell еще иинструментов Docker.

Контейнеры Windows напоминают по принципу FreeBSD Jail или Linux OpenVZ, используют с ОС одно ядро, которое вместе с остальными ресурсами (ОЗУ, сеть) разделяют между собой. Файлы ОС и службы проецируются в пространство имен каждого контейнера. Такой тип контейнера эффективно использует ресурсы, уменьшая накладные расходы, а значит позволяет более плотно размещать приложения. Так как базовые образы контейнера «имеют» одно ядро c узлом, ихверсии должны совпадать, иначе работа не гарантируется.

В контейнерах Hyper-V используется дополнительный уровень изоляции и каждому контейнеру выделяется свое ядро и память. Изоляцию в отличие от предыдущего типа осуществляет не ядро ОС, а гипервизор Hyper-V (требуется роль Hyper-V). В результате достигается меньшие накладные расходы по сравнению с виртуальными машинами, но больший уровень изоляции по сравнению с контейнерами Windows. В этом случае для запуска контейнера иметь такое же ядро вОС. Также эти контейнеры можно разворачивать и в Windows 10 Pro/Корпоративная . Особо стоит отметить, что тип контейнер выбирается не во время создания, а во время развертывания. То есть любой контейнер может быть запущен икак Windows и как Hyper-V варианте.

В качестве ОС в контейнере используются обрезанные Server Core или Nano Server. Первый, появился еще в Windows Sever 2008 и обеспечивает большую совместимость с имеющимися приложениями. Второй еще более урезан посравнениею с Server Core и предназначен для работы без монитора, позволяя запускать сервер в минимально возможной конфигурации для использования с Hyper-V, файловым сервером (SOFS) и «облачными» службами, требуя на 93% меньше места. Содержит только самые необходимые компоненты (.Net с CoreCLR, Hyper-V, Clustering и т.д.).

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

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

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

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

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

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

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

Microsoft включил в функцию контейнера набор инструментов Docker по управлению не только контейнерами Linux, но и контейнерами Windows Server и Hyper-V. В рамках сотрудничества в сообществах Linux и Windows , был расширен опыт Docker путем создания модуля PowerShell для Docker , который представлен теперь с открытым исходным кодом для. Модуль PowerShell может управлять Linux и Windows Sever контейнерами локально или удаленно с помощью REST API Docker технологии. Разработчики удовлетворены внедрением инноваций для клиентов с помощью открытого исходного кода для развитием нашей платформы. В дальнейшем планируется принести технологии для наших клиентов наряду с инновациями, как Hyper-V.

Купить Windows Server 2016

Предлагаем Вам купить Windows Server 2016 со скидкой у официального Партнера Microsoft в России – Компании ДАТАСИСТЕМ. У вас будет возможность получить консультацию, а также бесплатно скачать Windows Server 2016 для тестирования, обратившись к нашим специалистам техподдержки. Цена Windows Server 2016 по запросу. Коммерческое предложение для участия в закупке Windows Server 2016 вы сможете получить по запросу на e-mail:
Поделиться