Использование контейнеров Windows для "Контейнеризации" существующих приложений

Область применения: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Контейнеры Windows предоставляют отличный механизм модернизации традиционных или устаревших приложений. Хотя этот подход иногда называется "перенос в контейнеры", метафора "лифт и шифт" берет начало от перемещения рабочих нагрузок с физических на виртуальные машины и используется при переносе рабочих нагрузок в облако. Сегодня этот термин более уместно применять к перемещению виртуальных машин (VMs). Но контейнеры не являются виртуальными машинами, и думать о них как о виртуальных машинах может привести к путанице по поводу того, как приложение контейнеризировано, или может ли оно, или должно быть контейнеризовано.

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

Знакомство

Что такое контейнеры Windows и что они не являются

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

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

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

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

Технология контейнеров началась в Linux с Docker, который становится стандартным. Корпорация Майкрософт тесно сотрудничала с Docker, чтобы гарантировать, что функциональные возможности контейнера совпадают с Windows, как это возможно. Внутренние различия между Linux и Windows могут проявляться таким образом, что они могут показаться ограничениями контейнеров Windows, когда на самом деле это просто различия между Linux и Windows. С другой стороны, контейнеры Windows предоставляют некоторые уникальные реализации, такие как изоляция Hyper-V, которая будет описана позже. Этот раздел помогает понять различия и как к ним адаптироваться.

Преимущества использования контейнеров

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

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

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

Полный список преимуществ использования контейнеров для существующих приложений можно найти на странице документации по Microsoft .NET.

Важная концепция уровня изоляции

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

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

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

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

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

• Более длительное время запуска контейнера и вероятное влияние на общую производительность приложения.
• Не все инструменты нативно работают с изоляцией Hyper-V.
• На данный момент ни служба Azure Kubernetes (AKS), ни AKS в Azure Stack HCI не поддерживают изоляцию Hyper-V.

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

Оркестрация контейнеров

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

Оркестраторы, возможно, неправильно названные; они больше похожи на дирижеров оркестра в том, что они координируют деятельность нескольких контейнеров, чтобы музыка продолжала играть. В некотором смысле они обрабатывают планирование и выделение ресурсов для контейнеров таким образом, как функционирование ОС. Таким образом, при переходе к контейнеризации приложений необходимо выбрать один из оркестраторов, поддерживающих контейнеры Windows. Некоторые из наиболее распространенных являются Kubernetes и Docker Swarm.

Что нельзя переместить в контейнеры Windows

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

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

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

Приложения и функции не поддерживаются	Почему не поддерживается	Можете ли вы обойти это?
Приложения, требующие рабочего стола	Контейнеры не поддерживают графический пользовательский интерфейс (GUI)	Если приложению требуется установить только графический интерфейс, изменение его на автоматическую установку может быть решением.
Приложения с помощью протокола удаленного рабочего стола (RDP)	RDP предназначен для интерактивных сеансов, поэтому приведенный выше принцип применяется здесь, а также	Вы можете использовать Windows Admin Center (WAC) или Remote PowerShell в качестве альтернативы удаленному управлению.
Состоянные приложения	Контейнеры являются временными	Да, для некоторых приложений может потребоваться минимальное изменение, поэтому они не хранят данные или состояние в контейнере.
Приложения базы данных	Контейнеры являются временными	Да, для некоторых приложений может потребоваться минимальное изменение, поэтому они не хранят данные или состояние в контейнере.
Active Directory	Проектирование и назначение Active Directory исключает выполнение в контейнере	Нет. Однако приложения, зависящие от Active Directory, могут использовать групповые управляемые учетные записи служб (gMSA). Дополнительные сведения о gMSA приведены ниже
Старые версии Windows Server	Поддерживается только Windows Server 2016 или более поздней версии	Нет. Однако совместимость приложений может быть вариантом: большинство приложений Windows Server 2008/R2 и более старые приложения работают в более новых версиях Windows Server
Приложения с помощью .NET Framework версии 2.0 или более ранних версий	Для поддержки .NET Framework требуются определенные образы контейнеров, и поддерживаются только последние версии.	Более ранние версии 2.0 не поддерживаются вообще, но см. ниже сведения о образах контейнеров, необходимых для более поздних версий.
Приложения, использующие другие сторонние платформы	Корпорация Майкрософт не сертифицирует или не поддерживает использование платформ, отличных от Майкрософт, в контейнерах Windows	Ознакомьтесь с поставщиком конкретной платформы или приложения политикой поддержки контейнеров Windows. Дополнительные сведения см. ниже

Рассмотрим все эти ограничения в свою очередь.

Приложения, требующие рабочего стола

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

Это не проблема, связанная с тем, как были реализованы контейнеры Windows, а основное понятие о том, как работают контейнеры.

Это другой вопрос, если приложению нужны API ГРАФИЧЕСКОго интерфейса. API поддерживаются, даже если графический интерфейс, обслуживаемый этими API, не поддерживается. Это более подробно описано в разделе Nano Server x Server Core x Server — какой базовый образ подходит для вас?

Приложения с помощью RDP

Поскольку вся цель протокола удаленного рабочего стола (RDP) заключается в создании интерактивного визуального сеанса, это ограничение графического интерфейса также применимо. Приложение, использующее RDP, не может быть контейнеризовано as-is.

Однако хорошим вариантом является средство удаленного управления, например Windows Admin Center. Вы можете использовать Центр администрирования Windows для управления узлами контейнеров Windows и самими контейнерами без необходимости использовать RDP в них. Вы также можете открыть удаленный сеанс PowerShell для узла и (или) контейнеров для управления ими.

Приложения с отслеживанием состояния

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

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

Тем не менее, это приводит к другой связанной теме...

Приложения базы данных

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

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

Роли инфраструктуры в Windows Server

Роли инфраструктуры Windows Server в основном обрабатывают функции ближе к операционной системе (например, AD, DHCP и файлового сервера). Таким образом, они недоступны для запуска контейнеров. Поэтому приложениям, нуждающимся в этих ролях, всегда будет трудно контейнеризировать.

Есть некоторые серые области. Например, некоторые функции, такие как DNS, могут работать в контейнерах Windows, даже если они не предназначены для использования в контейнерах. Другие роли инфраструктуры просто удаляются из базового образа контейнера и не могут быть установлены, такие как Active Directory, DHCP и другие.

Active Directory (AD)

Active Directory был выпущен более двадцати лет назад на сервере Windows 2000. Он использует механизм, в котором каждое устройство или пользователь представлен объектом, хранящимся в базе данных. Эта связь тесно связана, и объекты хранятся в базе данных, даже если фактический пользователь или устройство больше не играет. Этот подход для Active Directory напрямую противоречит эфемерной природе контейнеров, которые, как ожидается, будут кратковременными или удаленными при отключении. Поддержание этой связи "один к одному" с Active Directory не идеально подходит для этих сценариев.

По этой причине контейнеры Windows не могут быть присоединены к домену. В результате этого нельзя запускать службы доменов Active Directory на инфраструктурном уровне в контейнерах на Windows. Модуль PowerShell можно запустить для удаленного управления контроллерами домена в контейнере Windows.

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

Приложения с помощью .NET Framework версии 2.0 или более ранних версий

Если приложению требуется .NET, возможность контейнеризации полностью зависит от используемой версии .NET Framework. Любая версия до .NET Framework 2.0 не поддерживается вообще; Для более высоких версий требуется использование определенных образов, как описано далее.

Приложения, использующие сторонние платформы (не майкрософт)

Как правило, корпорация Майкрософт не может сертифицировать сторонние платформы или приложения или поддерживать их работу в контейнерах Windows или физических и виртуальных машинах в этом случае. Однако корпорация Майкрософт выполняет собственное внутреннее тестирование для удобства использования нескольких сторонних платформ и инструментов, включая Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat и многие другие.

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

Идеальные кандидаты для контейнеризации

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

Тип приложения	Почему это хорошие кандидаты	Особые соображения
Консольные приложения	Без ограничений графического интерфейса консольные приложения идеально подходят для контейнеров.	Используйте соответствующий базовый образ контейнера в зависимости от потребностей приложения.
Службы Windows	Так как это фоновые процессы, не требующие прямого взаимодействия с пользователем	Используйте соответствующий базовый образ контейнера в зависимости от потребностей приложения. Необходимо создать процесс переднего плана, чтобы обеспечить выполнение любого контейнерного фонового процесса. См. раздел фоновых служб ниже.
Службы Windows Communication Foundation (WCF)	Поскольку они являются сервисно-ориентированными приложениями, которые также работают в фоновом режиме	Используйте соответствующий базовый образ контейнера в зависимости от потребностей приложения. Возможно, потребуется создать процесс переднего плана, чтобы поддерживать работу любого фонового процесса в контейнере. См. раздел фоновых служб ниже.
Веб-приложения	Веб-приложения в сущности являются фоновыми службами, которые прослушивают определенный порт и поэтому являются отличными кандидатами для контейнеризации, поскольку они пользуются масштабируемостью, предлагаемой контейнерами.	Используйте соответствующий базовый образ контейнера в зависимости от потребностей приложения.

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

Практические рекомендации для приложений, которые можно контейнеризировать

Проекты по восстановлению приложений обычно учитывают, можно ли контейнеризировать конкретное приложение с точки зрения бизнес-функции приложения. Но бизнес-функциональные возможности не являются фактором, который определяет, возможно ли это технически. Что важно, так это архитектура приложения, а именно на какие технические компоненты она опирается. Таким образом, нет простого ответа на такой вопрос, как "Можно ли контейнеризировать приложение отдела кадров?", потому что это не то, что делает приложение, это как (и какие компоненты и службы Windows он использует) что делает разницу.

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

В следующей таблице представлена краткая сводка по компонентам и функциям приложений, которым требуется особое внимание при рассмотрении вопроса о контейнеризации. Приведенные ниже подразделы содержат дополнительные сведения, включая примеры, иллюстрирующие методы обработки каждого сценария. Хотя в приведенном ниже списке рассматриваются сценарии, поддерживаемые в контейнерах Windows, эти сценарии по-прежнему должны соблюдать рекомендации из предыдущей главы. Например, в то время как фоновые службы поддерживаются, запуск фоновой службы в .NET Framework 1.1 не поддерживается.

Функция или компонент Windows, требующий специальной обработки	Причина
Очередь сообщений Майкрософт (MSMQ)	MSMQ возникла долго до того, как контейнеры и не все его модели развертывания для очередей сообщений совместимы с архитектурой контейнера.
Координатор распределенных транзакций Майкрософт (MSDTC)	Для разрешения имен между MSDTC и контейнером требуется особое внимание.
ИИС	IIS работает так же, как и в виртуальной машине, но при запуске ее в среде контейнеров важно учитывать такие аспекты, как управление сертификатами, строки подключения к базе данных и многое другое.
Запланированные задачи	Контейнеры Windows могут выполнять запланированные задачи, как и любой экземпляр Windows. Однако может потребоваться запустить задачу в переднем плане, чтобы экземпляр контейнера продолжал работать. В зависимости от приложения может потребоваться рассмотреть подход на основе событий.
Фоновые службы	Так как контейнеры выполняются как временные процессы, вам потребуются дополнительные механизмы, чтобы контейнер продолжал работать.
.NET Framework и .NET (прежнее название — .NET Core)	Обязательно используйте правильный образ для обеспечения совместимости, как описано в подразделе ниже.

Другие вспомогательные компоненты

Компонент, требующий специальной обработки	Причина	Альтернативный подход
Ведение журнала событий и мониторинг	Поскольку способ записи событий и журналов в Windows по своей сути отличается от вывода в стандартный поток (stdout) в Linux.	Используйте новое средство мониторинга журналов для нормализации данных и объединения данных из Linux и Windows.
Безопасность контейнеров Windows	Хотя многие методики безопасности остаются неизменными, контейнеры требуют дополнительных мер безопасности.	Используйте специально созданное средство для сканирования изображений и реестра. Дополнительные сведения см. далее.
Резервное копирование контейнеров Windows	Контейнеры не должны содержать данные или состояние	Выполняйте резервное копирование любого постоянного хранилища, используемого контейнерами, а также образов контейнеров.

Компоненты/функции Windows

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

MSMQ

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

Размах	Транзакционный?	Расположение очереди	Тип проверки подлинности	Отправка и получение?
Частный	Да	Тот же контейнер (один контейнер)	Анонимный	Да
Частный	Да	Постоянный объем	Анонимный	Да
Частный	Да	Контроллер домена	Анонимный	Да
Частный	Да	Один узел (два контейнера)	Анонимный	Да
Публичный	Нет	Два ведущих	Анонимный	Да
Публика	Да	Два хоста	Анонимный	Да

Несколько заметок об этих поддерживаемых сценариях, которые были проверены внутренними командами разработчиков Майкрософт:

• Режим изоляции: режим обработки и режим Hyper-V для изоляции работает с приведенными выше сценариями.
• Минимальный образ ОС и контейнера: минимальная версия ОС, рекомендуемая для использования с MSMQ, — Windows Server 2019.
• Постоянные тома: описанные выше сценарии были проверены с использованием MSMQ в службе Azure Kubernetes (AKS) с помощью файлов Azure для постоянного хранения.

При добавлении этих рекомендаций вместе с приведенной выше таблицей можно увидеть, что единственный сценарий, который не поддерживается, предназначен для очередей, требующих проверки подлинности с помощью Active Directory. Интеграция gMSAs (групповые управляемые учетные записи служб) с MSMQ в настоящее время не поддерживается, так как MSMQ имеет зависимости от Active Directory, которые еще не установлены.

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

MSDTC

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

• При создании контейнера обязательно передайте параметр --name в команду docker run. Этот параметр имени позволяет контейнерам обмениваться данными по сети Docker. При использовании gMSA имя должно соответствовать имени узла, которое должно соответствовать имени учетной записи gMSA.
  • Ниже приведен пример команды выполнения с gMSA:

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• Контейнеры должны иметь возможность разрешать друг друга с помощью имени NETBIOS. Если возникают трудности, лучший способ решения - это добавить имя и IP-адрес контейнеров в файлы хостов друг друга.
• Идентификатор uuid для msdtc в обоих контейнерах должен быть уникальным. UUID можно найти, выполнив команду Get-Dtc в PowerShell в контейнерах. Если они не уникальны, один из способов разрешения — удаление и переустановка msdtc на одном из контейнеров. Эти команды PowerShell можно использовать — "uninstall-dtc", "install-dtc".
• В настоящее время MSDTC не поддерживается в службах Azure Kubernetes. Если вам необходимо запустить MSDTC в AKS, пожалуйста, сообщите об этом команде контейнеров Windows, создав запрос в репозитории контейнеров Windows на GitHub.

Как службы IIS работают в контейнере и виртуальной машине

Службы IIS работают так же в контейнере Windows, что и в виртуальной машине. Однако существуют некоторые аспекты запуска экземпляра IIS, которые следует учитывать при запуске в среде контейнера:

• Постоянное хранилище локальных данных: папки, в которые приложение записывает и из которых считывает файлы, являются отличным примером того, что вы будете хранить в виртуальной машине для экземпляра IIS. При использовании контейнеров не требуется записывать данные непосредственно в контейнер. Контейнеры используют "временное пространство" для локального хранилища, и когда новый контейнер запускается для этого же приложения, он не имеет доступа к этой области от предыдущего контейнера. Поэтому используйте постоянное хранилище для данных, которые должны быть доступны веб-приложению, чтобы любой экземпляр контейнера может иметь доступ к этому хранилищу.
• Сертификаты. Хотя локальные сертификаты можно использовать в экземплярах контейнеров, избегайте этого, так как если сертификат необходимо обновить, необходимо перестроить образ контейнера. В качестве альтернативы, можно использовать оркестратор контейнеров с Ingress-контроллером. Контроллеры входящего трафика могут применять сетевые политики, а также управлять сертификатами для веб-сайта, размещенного за ним. Вы отделяете управление жизненным циклом сертификатов от управления веб-сайтами.
• Строки подключения к базе данных: для традиционного развертывания IIS можно передать строку подключения базы данных в рамках развертывания приложения. Хотя контейнеры Windows позволяют следовать этой модели, вы можете рассмотреть возможность отделения строки подключения базы данных от контейнера и передачи ее в централизованную конфигурацию, предоставляемую оркестратором контейнеров, из которой приложение может считывать данные. Это позволяет управлять и обновлять строку подключения базы данных независимо от приложения. Если база данных изменяется (например, в случае переноса из локальной среды в облако), можно легко изменить строку подключения без необходимости перестраивать образ контейнера. Этот подход также позволяет хранить секреты (например, имя пользователя и пароль для подключения к базе данных) в хранилище секретов.
• Горизонтальное автоматическое масштабирование: при увеличении нагрузки вычислительные системы, как правило, замедляют воспринимаемую производительность при попытке обработать одновременные запросы. Как правило, существует два способа избежать влияния на производительность — вертикальное или горизонтальное масштабирование. Вертикальное масштабирование увеличивает ресурсы, доступные для существующих вычислительных экземпляров (больше ЦП, памяти и т. д.). Горизонтальное масштабирование увеличивает количество экземпляров, поддерживающих запросы (больше физических узлов, виртуальных машин или контейнеров). Для веб-уровней, таких как IIS, горизонтальное масштабирование, как правило, более эффективно, чем по вертикали, но локальные среды могут столкнуться с ограничениями ресурсов и проблемами балансировки нагрузки. В облачных средах горизонтальное масштабирование гораздо проще, так как ресурсы легко доступны (для дополнительных затрат) и поставщик облачных служб обычно разрабатывает механизм балансировки нагрузки с учетом горизонтального масштабирования. Контейнеры Windows могут использовать горизонтальное масштабирование для IIS, но временный аспект контейнеров играет важную роль. Очень важно, чтобы контейнеры имели ту же конфигурацию, и что состояние или данные не хранятся, чтобы обеспечить увеличение или уменьшение числа экземпляров, поддерживающих веб-приложение.

Запланированные задачи

Запланированные задачи используются для вызова программы, службы или скрипта в любое время в среде Windows. Традиционно экземпляр Windows всегда запущен, и при срабатывании триггера выполняется задача. Это возможно с контейнерами Windows и , помимо того, что необходимо настроить запланированные задачи и управлять ими с помощью Azure PowerShell, они работают точно так же.

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

• Используйте управляемое событием PaaS (платформа как услуга), например функцию Azure, для хранения кода и определения триггера для этого приложения. Функции Azure даже поддерживают запуск образов контейнеров Windows при выполнении триггера.
• Используйте контейнеры Windows в сочетании с оркестратором контейнеров. Контейнер может выполняться только в том случае, если триггер срабатывает и вызывается из других частей приложения. В этом случае оркестратор контейнеров будет обрабатывать планирование и запуск приложения.
• Наконец, оставьте контейнер Windows запущенным для выполнения запланированной задачи. Для того чтобы контейнер продолжал работать, потребуется служба переднего плана, такая как Service Monitor.

Фоновые службы

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

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

Дополнительные сведения о ServiceMonitor см. в документации по на сайте Github.

.NET Framework и .NET

Контейнеры Windows поддерживают .NET Framework и .NET (ранее .NET Core). Команда .NET создает собственные официальные образы для обеих платформ на основе базовых образов контейнеров Windows. Выбор подходящего образа имеет решающее значение для обеспечения совместимости. Команда .NET предоставляет образы .NET Framework поверх базового образа контейнера Server Core и образы .NET поверх базовых образов контейнеров Server Core и Nano Server. Server Core имеет больший набор API, чем Nano Server, что обеспечивает более высокую совместимость, но и больший размер образа. Nano Server имеет сильно сокращённый интерфейс API, но значительно меньший размер образа.

В некоторых случаях может потребоваться создать ваш собственный образ .NET Framework или .NET на основе базовых образов контейнеров Windows или Server. Это может потребоваться, если приложение имеет не только зависимость платформы, но и зависимость ОС. Вы сможете обнаружить любые такие зависимости, проверив приложение с определенным базовым образом контейнера.

Например, базовые образы контейнеров server Core и Nano Server имеют только один шрифт, чтобы уменьшить размер изображения. Если вашему приложению требуется другой шрифт, вам необходимо либо установить этот шрифт, либо использовать образы системы Сервера или Windows, которые имеют более обширный набор API и включают все шрифты Windows по умолчанию. С точки зрения совместимости это позволяет практически любому приложению (при соблюдении свойств контейнеров, таких как отсутствие графического интерфейса) быть контейнеризированы. Недостатком является то, что они будут гораздо большего размера, что может повлиять на производительность.

При проверке того, работает ли приложение в контейнерах Windows, корпорация Майкрософт рекомендует следующее:

Для этого фреймворка	Сначала протестируйте этот образ контейнера	Возврат к этому образу контейнера, если первый не работает	Базовый образ
.NET Framework версии 2.X и 3.X	.NET Framework 4.x	.NET Framework 3.5	Windows Server Core
Версии .NET Framework 4.x	.NET Framework 4.x	Создание образа контейнера .NET Framework с помощью серверов или образов Windows	Windows Server Core
.NET 6 или 7	.NET 6 или 7 соответственно	Создание образа контейнера .NET с помощью базовых образов Windows или Server	Windows Nano Server или Server Core

Другие вспомогательные компоненты

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

Ведение журнала событий

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

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

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

• Возможность выбрать и фильтровать типы событий или журналов, которые вы хотите вывести на stdout. Например, журнал приложений можно отфильтровать для сообщений об ошибках и предупреждениях, только если вы не заинтересованы в информационных событиях.
• Возможность выбрать журналы событий, пользовательские файлы журналов или трассировку событий для Windows (ETW). Это особенно полезно, если ваше приложение записывает в другом источнике лога. Примером этого является журналы IIS, расположенные в папке C:\inetpub.
• Тот факт, что Log Monitor заставляет контейнеры Windows вести себя так же, как контейнеры Linux, означает, что инструменты, которые ищут stdout и взаимодействуют с функциями среды выполнения контейнера, работают, как и предполагалось. Например, если вы переходите с Docker на ContainerD как среда выполнения контейнера, то журналы по-прежнему должны отображаться с узла контейнера, например, через "crictl logs".

Дополнительные сведения об инструменте мониторинга журналов можно найти в этой записи блога .

Безопасность контейнеров Windows

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

• Общие компоненты. Контейнеры Windows разделяют некоторые компоненты хоста в целях безопасности. К ним относятся брандмауэр Windows, Защитник Windows (антивирусная программа) и другие ограничения доступа к ресурсам. Вам не нужно конфигурировать эти компоненты в вашем контейнере напрямую, поскольку узел контейнера самостоятельно вносит необходимые изменения на основе рабочей нагрузки вашего контейнера. Например, если контейнер выполняет веб-запрос, узел контейнера перенаправит необходимый трафик через его брандмауэр, чтобы контейнер смог получить доступ к Интернету.
• Режим изоляции. Как упоминалось, контейнеры Windows можно развертывать в режиме изоляции процесса или Hyper-V, при этом Hyper-V обеспечивает наиболее безопасную изоляцию. В методе изоляции процесса контейнер делится своим ядром, файловой системой и реестром с хостом, что позволяет повышенному администраторскому процессу взаимодействовать с процессами и службами контейнера. Выбор правильного режима изоляции для приложения важен для обеспечения соответствующей модели безопасности.
• Обновления Windows. Так как стек обслуживания отсутствует в контейнерах Windows, контейнеры Windows не получают обновления, такие как общие экземпляры Windows. Вместо этого необходимо перестроить контейнеры Windows с помощью последнего доступного базового образа контейнера. Клиенты могут использовать конвейеры DevOps для этой цели. Корпорация Майкрософт обновляет базовые образы контейнеров для всех своих официальных образов каждый месяц в соответствии с графиком "вторника обновлений".
• Учетная запись пользователя контейнера. По умолчанию приложения в контейнерах Windows выполняются с повышенными привилегиями в учетной записи пользователя ContainerAdmin. Это полезно для установки и настройки необходимых компонентов в образе контейнера. Однако при запуске приложения, не требующего повышенных привилегий, следует изменить учетную запись пользователя на ContainerUser. Для определенных сценариев можно также создать новую учетную запись с соответствующими привилегиями.
• Сканирование изображений и среды выполнения. Контейнеры требуют, чтобы образы в репозиториях и экземплярах контейнеров были защищены. Корпорация Майкрософт рекомендует использовать Microsoft Defender для контейнеров для сканирования изображений и сканирования среды выполнения. Defender для контейнеров поддерживает контейнеры Windows для оценки уязвимостей с помощью проверки реестра и защиты среды выполнения с обнаружением угроз.

Дополнительные сведения о приведенных выше разделах см. на странице документации по контейнерам Windows .

Резервное копирование контейнеров Windows

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

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

• Приложение: приложение, вероятно, находится в исходном репозитории, например GitHub или Azure DevOps. Эти репозитории предоставляют управление версиями, что позволяет вернуться к определенной версии приложения. Если вы владеете исходным репозиторием, обязательно следуйте рекомендациям по резервному копированию и управлению.
• Образ контейнера. Для рабочих сред образ контейнера должен находиться в централизованном репозитории образов, например в реестре контейнеров Azure (ACR). Вы можете отправить образы контейнеров в ACR, чтобы сделать его доступным для других узлов для извлечения. ACR обрабатывает доступность образов контейнеров и служит вариантом резервного копирования. Однако помните, что при обработке ACR доступности образа он не препятствует удалению или перезаписи образа. Для любого другого локального или корпоративного репозитория образов следуйте рекомендациям поставщика по резервному копированию существующих реестров.
• Dockerfile: Dockerfiles создает новые образы контейнеров и обычно хранится вместе с источником приложения. Так как dockerfile, возможно, не был создан с приложением, особенно если это существующее приложение, которое контейнеризовано, вы несете ответственность за обеспечение хранения dockerfile в безопасном и резервном расположении. Кроме того, необходимо убедиться, что все другие ресурсы, необходимые для работы приложения в контейнере, созданы резервные копии; например: YAML и JSON-файлы для Kubernetes, Docker Swarm и шаблонов Azure ARM следуют тем же рекомендациям, что и выше.

Планирование процесса переноса и трансформации

После оценки готовности приложения к контейнеризации используйте следующие общие рекомендации по планированию процесса:

1. Определите базовый образ операционной системы Windows, который вам нужен: Windows Server Core, Nano Server, Windowsили Server.
2. Определите тип режима изоляции для контейнера: выберите между процессным и Hyper-V режимами изоляции. Примечание. В настоящее время AKS и AKS в Azure Stack HCI поддерживают только изолированные от процесса контейнеры. В будущем выпуске AKS и AKS в Azure Stack HCI также поддерживают изолированные контейнеры Hyper-V. Дополнительные сведения см. о режимах изоляции.
3. Выберите подходящую версию Windows Server для обеспечения совместимости приложений. Минимальная версия Windows Server для контейнеров — Windows Server 2016, но Windows Server 2019 и Windows Server 2022 являются единственными операционными системами узла контейнеров, поддерживаемыми в AKS и AKS в Azure Stack HCI.
4. Убедитесь, что политики безопасности вашей компании существуют для среды контейнера. Это включает в себя адаптацию к конкретным требованиям контейнера, например сканирование реестра и обнаружение угроз.
5. Рассмотрите потребности балансировки нагрузки. Контейнеры сами не перемещаются; вместо этого можно использовать оркестратор для автоматического запуска или остановки контейнеров на узлах кластера или управления изменениями нагрузки и доступности с помощью автоматического горизонтального масштабирования.
6. Учитывайте нужды оркестрации. После контейнеризации приложение, скорее всего, требует автоматического управления с такими инструментами, как Kubernetes, AKS или AKS в Azure Stack HCI. См. раздел об оркестрации контейнеров Windows для подробного обсуждения и руководства по выбору инструментов.
7. Контейнеризация приложения.
8. Отправьте приложение в репозиторий образов. Это позволит узлам контейнеров скачать образ в любой среде, включая разработку, тестирование и рабочую среду.

Azure Migrate может предоставить руководимый процесс выявления, оценки и переноса вашего существующего приложения Windows в Azure Kubernetes Service. Дополнительные сведения см. на странице документации по миграции Azure.