Поделиться через

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

  • Статья

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

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

В этом разделе приводятся практические рекомендации по перемещению традиционных приложений в контейнеры 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.
  • В настоящее время ни Служба Azure Kubernetes (AKS), ни AKS в Azure Stack HCI не поддерживают изоляцию Hyper-V.

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

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

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

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

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

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

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

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

Неподдерживаемые приложения и функции Почему не поддерживается Существует ли обходное решение?
Приложения, для которых нужны возможности рабочего стола Контейнеры не поддерживают графический пользовательский интерфейс (GUI) Если приложению требуется установить только графический интерфейс пользователя, решением может быть выбор автоматической установки
Приложения, использующие протокол удаленного рабочего стола (RDP) RDP предназначен для интерактивных сеансов, поэтому приведенный выше принцип также применяется здесь Вы можете использовать Windows Admin Center (WAC) или удаленный сеанс 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, Server Core или Server).

Приложения, использующие протокол RDP

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

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

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

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

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

В связи с этим возникает еще один вопрос.

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

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

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

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

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

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

Active Directory

Служба Active Directory была выпущена более двадцати лет назад вместе с Windows 2000 Server. Она использует механизм, в котором каждое устройство или пользователь представлено объектом, хранящимся в базе данных. Это очень тесная связь, и объекты хранятся в базе данных даже в тех случаях, когда фактический пользователь или устройство больше не участвуют в обмене данными. Такой подход к 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 существует намного дольше контейнеров, и не все ее модели развертывания для очередей сообщений совместимы с архитектурой контейнеров.
Координатор распределенных транзакций (Майкрософт) Разрешение имен между MSDTC и контейнером требует особого внимания.
IIS Службы IIS работают так же, как и на виртуальных машинах, но при запуске в среде контейнера следует учитывать важные факторы, такие как управление сертификатами, строки подключения к базам данных и многое другое.
Запланированные задачи Контейнеры Windows могут выполнять запланированные задачи так же, как и любой экземпляр Windows. Но вам может потребоваться выполнить задачу переднего плана, чтобы не прекращать работу экземпляра контейнера. В зависимости от приложения может потребоваться использовать подход на основе событий.
Фоновые службы Так как контейнеры выполняются в качестве временных процессов, для поддержания работы контейнера потребуется дополнительное управление
.NET Framework и .NET (ранее .NET Core) Обязательно используйте правильный образ для обеспечения совместимости, как описано в подразделе ниже

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

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

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

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

MSMQ

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

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

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

  • Режим изоляции. Режимы изоляции процесса и изоляции 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 в одном из контейнеров. Можно использовать следующие команды PowerShelll: uninstall-dtc, install-dtc.
  • В настоящее время MSDTC не поддерживается в Службах Azure Kubernetes. Если у вас есть конкретная необходимость в запуске MSDTC в AKS, сообщите группе разработчиков контейнеров Windows, открыв проблему am в репозитории контейнеров Windows на GitHub.

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

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

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

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

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

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

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

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

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

Примером этого является 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 имеют только один шрифт, для уменьшения размера образа. Если приложению требуется другой шрифт, вам придется установить этот шрифт или использовать образы Server или Windows, которые имеют более широкий набор API и включают все шрифты Windows по умолчанию. С точки зрения совместимости это позволяет контейнеризировать практически любое приложение (при условии, что оно учитывает особенности контейнеров, например отсутствие графического пользовательского интерфейса). Но недостатком является то, что они будут намного крупнее, что может повлиять на производительность.

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

Для этой платформы Сначала попробуйте этот образ контейнера Выполните откат к этому образу контейнера, если первый не работает Base image
.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 с помощью образов Server или 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 выводит журналы приложений из контейнера без интерактивного его открытия. Но до добавления средства Log Monitor этот же метод не работал в Windows.

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

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

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

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

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

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

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

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

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

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

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

Планирование процесса lift-and-shift

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

  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" предоставляет интерактивный процесс обнаружения, оценки и переноса существующего приложения Windows в Служба Azure Kubernetes. Дополнительные сведения проверка на странице документации по миграции Azure.