Начало работы. Подготовка Windows для контейнеров Get started: Prep Windows for containers

Из этого руководства вы узнаете, как выполнить следующие задачи: This tutorial describes how to:

Предварительные требования Prerequisites

Windows Server Windows Server

Чтобы запустить контейнеры в Windows Server, вам нужен физический сервер или виртуальная машина под управлением Windows Server (Semi-Annual Channel), Windows Server 2019 или Windows Server 2016. To run containers on Windows Server, you need a physical server or virtual machine running Windows Server (Semi-Annual Channel), Windows Server 2019, or Windows Server 2016.

Windows 10 Windows 10

Для запуска контейнеров в Windows 10 необходимо следующее: To run containers on Windows 10, you need the following:

• Одна физическая компьютерная система под управлением Windows 10 Профессиональная или Корпоративная с юбилейным обновлением (версия 1607) или более поздней версии. One physical computer system running Windows 10 Professional or Enterprise with Anniversary Update (version 1607) or later.
• Необходимо включить Hyper-V. Hyper-V should be enabled.

Начиная с Windows 10 с обновлением от октября 2018 г. мы не запрещаем пользователям запускать контейнер Windows в режиме изоляции процессов в Windows 10 Корпоративная или Профессиональная для целей разработки и тестирования. Starting with the Windows 10 October Update 2018, we no longer disallow users from running a Windows container in process-isolation mode on Windows 10 Enterprise or Professional for dev/test purposes. Дополнительные сведения см. в разделе вопросов и ответов. See the FAQ to learn more.

Контейнеры Windows Server по умолчанию используют изоляцию Hyper-V в Windows 10, чтобы разработчики получили ту же версию ядра и ту же конфигурацию, что и в рабочей среде. Windows Server Containers use Hyper-V isolation by default on Windows 10 in order to provide developers with the same kernel version and configuration that will be used in production. Дополнительные сведения об изоляции Hyper-V см. в разделе документации с описанием концепций. Learn more about Hyper-V isolation in the Concepts area of our docs.

Установка Docker Install Docker

Первым шагом станет установка Docker. Это нужно для работы с контейнерами Windows. The first step is to install Docker, which is required for working with Windows containers. Docker предоставляет стандартную среду выполнения для контейнеров, а также основной API и интерфейс командной строки (CLI). Docker provides a standard runtime environment for containers, with a common API and command-line interface (CLI).

Дополнительные сведения о конфигурации см. в статье Подсистема Docker в Windows. For more configuration details, see Docker Engine on Windows.

Чтобы установить Docker в Windows Server, можно использовать модуль PowerShell поставщика OneGet, который опубликован корпорацией Майкрософт, под именем DockerMicrosoftProvider. To install Docker on Windows Server, you can use a OneGet provider PowerShell module published by Microsoft called the DockerMicrosoftProvider. Этот поставщик включает поддержку контейнеров в Windows, а также устанавливает подсистему и клиент Docker. This provider enables the containers feature in Windows and installs the Docker engine and client. Вот как это сделать. Here’s how:

Откройте сеанс PowerShell с повышенными привилегиями и установите поставщик Docker-Microsoft PackageManagement из коллекции PowerShell. Open an elevated PowerShell session and install the Docker-Microsoft PackageManagement Provider from the PowerShell Gallery.

Если будет предложено установить поставщик NuGet, введите Y и установите его. If you’re prompted to install the NuGet provider, type Y to install it as well.

С помощью модуля PackageManagement PowerShell установите последнюю версию Docker. Use the PackageManagement PowerShell module to install the latest version of Docker.

Когда в PowerShell появится запрос, доверять ли источнику пакета DockerDefault, введите A , чтобы продолжить установку. When PowerShell asks you whether to trust the package source ‘DockerDefault’, type A to continue the installation.

После установки перезагрузите компьютер. After the installation completes, restart the computer.

Если позже вам потребуется обновить Docker, выполните следующие действия: If you want to update Docker later:

• Проверьте установленную версию с помощью следующей команды: Check the installed version using:

• Найдите текущую версию с помощью следующей команды: Find the current version using:

• Когда все будет готово, запустите обновление с помощью следующей команды: When you’re ready, upgrade using:

• Затем выполните следующую команду: Then, followed with:

Windows Admin Center; Windows Admin Center

Вы можете использовать Windows Admin Center для корректной настройки компьютера Windows Server в качестве узла контейнера. You can use Windows Admin Center to properly set up a Windows Server machine as a container host. Чтобы начать работу, убедитесь, что в вашем экземпляре Windows Admin Center установлена последняя версия расширения «Контейнеры». To get started, ensure you have the latest Containers extension installed on your Windows Admin Center instance. Дополнительные сведения об установке и настройке расширений см. в документации по Windows Admin Center. For more information on how to install and configure extensions, check out the Windows Admin Center documentation. Установив расширение «Контейнеры», выберите компьютер Windows Server, который нужно настроить, и выберите вариант «Контейнеры»: With the Containers extension installed, target the Windows Server machine you want to configure and select the Containers option:

Нажмите кнопку Установить. Click the Install button. Windows Admin Center запустит настройку Windows Server и Docker в фоновом режиме. Windows Admin Center will start the configuration of Windows Server and Docker in the background. После завершения процесса можно обновить страницу и просмотреть другие функции расширения «Контейнеры». After the process is complete, you can refresh the page and see the other functionalities of the Containers extension.

Вы можете установить Docker в Windows 10 Профессиональная и Корпоративная, выполнив описанные ниже действия. You can install Docker on Windows 10 Professional and Enterprise editions by using the following steps.

Скачайте и установите Docker Desktop, создав бесплатную учетную запись Docker, если у вас ее нет. Download and install Docker Desktop, creating a free Docker account if you don’t have one already. Дополнительные сведения см. в документации по Docker. For more details, see the Docker documentation.

Во время установки выберите контейнеры Windows в качестве типа контейнеров по умолчанию. During installation, set the default container type to Windows containers. Чтобы переключиться после установки, можно использовать элемент Docker в области уведомлений Windows (как показано ниже) либо следующую команду в командной строке PowerShell: To switch after installation completes, you can use either the Docker item in the Windows system tray (as shown below), or the following command in a PowerShell prompt:

Дальнейшие действия Next steps

Теперь, когда ваша среда полностью настроена, перейдите по приведенной ниже ссылке, чтобы узнать, как запустить контейнер. Now that your environment has been configured correctly, follow the link to learn how to run a container.

Настройка параметров производительности контейнеров Windows Server Performance tuning Windows Server containers

Введение Introduction

Windows Server 2016 — это первая версия ОС Windows со встроенной поддержкой технологии контейнеров. Windows Server 2016 is the first version of Windows to ship support for container technology built in to the OS. В Windows Server 2016 доступны два типа контейнеров: контейнеры Windows Server и контейнеры Hyper-V. In Server 2016, two types of containers are available: Windows Server Containers and Hyper-V Containers. Каждый тип поддерживает номера SKU Server Core и или Nano Server Windows Server 2016. Each container type supports either the Server Core or Nano Server SKU of Windows Server 2016.

Эти конфигурации по-разному влияют на производительность. Мы подробно рассмотрим их, чтобы вы могли выбрать подходящий вариант для своих сценариев. These configurations have different performance implications which we detail below to help you understand which is right for your scenarios. Кроме того, мы подробно опишем конфигурации, влияющие на производительность, и компромиссные решения с использованием каждого из этих вариантов. In addition, we detail performance impacting configurations, and describe the tradeoffs with each of those options.

Контейнеры Windows Server и контейнеры Hyper-V Windows Server Container and Hyper-V Containers

Контейнер Windows Server и контейнеры Hyper-V предоставляют сходные возможности, предоставляющие сходные возможности переносимости и согласованности. Но они отличаются в контексте гарантий изоляции и показателей производительности. Windows Server Container and Hyper-V containers offer many of the same portability and consistency benefits but differ in terms of their isolation guarantees and performance characteristsics.

Контейнеры Windows Server обеспечивают изоляцию приложений используя соответствующую технологию в отношении процессов и пространств имен. Windows Server Containers provide application isolation through process and namespace isolation technology. Контейнер Windows Server использует ядро совместно с узлом контейнера и всеми остальными контейнерами на этом узле. A Windows Server container shares a kernel with the container host and all containers running on the host.

Контейнеры Hyper-V расширяют возможности изоляции, предоставляемые контейнерами Windows Server, ведь каждый контейнер запускается в высокооптимизированной виртуальной машине. Hyper-V Containers expand on the isolation provided by Windows Server Containers by running each container in a highly optimized virtual machine. В этой конфигурации ядро узла контейнера не используется совместно с контейнерами Hyper-V. In this configuration the kernel of the container host is not shared with the Hyper-V Containers.

Дополнительная изоляция, предоставляемая контейнерами Hyper-V, во многом достигается благодаря предоставляемому гипервизором уровню изоляции между контейнером и узлом контейнера. The additional isolation provided by Hyper-V containers is achieved in large part by a hypervisor layer of isolation between the container and the container host. Это влияет на плотность контейнеров (в отличие от контейнеров Windows Server системные и двоичные файлы используются совместно в меньшей степени), увеличивая общий объем хранилища и памяти. This affects container density as, unlike Windows Server Containers, less sharing of system files and binaries can occur, resulting in an overall larger storage and memory footprint. Кроме того, использование некоторых режимов использования сети, операций ввода-вывода для хранилища и ЦП может быть сопряжено с дополнительными издержками. In addition there is the expected additional overhead in some network, storage io, and CPU paths.

Server Core и Nano Server Nano Server and Server Core

Контейнеры Windows Server и контейнеры Hyper-V поддерживают Server Core, а для нового режима установки, доступного в Windows Server 2016, еще и Nano Server. Windows Server Containers and Hyper-V containers offer support for Server Core and for a new installation option available in Windows Server 2016 : Nano Server.

Nano Server: это удаленно управляемая серверная ОС, оптимизированная для частных облаков и центров обработки данных. Nano Server is a remotely administered server operating system optimized for private clouds and datacenters. Этот вариант аналогичен Windows Server в режиме основных серверных компонентов, однако значительно меньше по размеру, не имеет функций локального входа и поддерживает только 64-разрядные приложения, средства и агенты. It is similar to Windows Server in Server Core mode, but significantly smaller, has no local logon capability, and only supports 64-bit applications, tools, and agents. Он занимает гораздо меньше места на диске и запускается быстрее. It takes up far less disk space and starts faster.

Время запуска контейнера Container Start Up Time

Время запуска контейнера является важнейшей метрикой во многих ситуациях, когда использование контейнеров является неоспоримым преимуществом. Container start up time is a key metric in many of the scenarios that containers offer the greatest benefit. Крайне важно понимать, как можно ускорить запуск контейнера, As such, understanding how to best optimize for container start up time is critical. поэтому ниже описаны некоторые компромиссные решения. Below are some tuning trade-offs to understand to achieve improved start up time.

Первый вход в систему First Logon

Корпорация Майкрософт предоставляет базовый образ для Nano Server и Server Core. Microsoft ships a base image for both Nano Server and Server Core. Базовый образ для Server Core оптимизирован путем устранения издержек при запуске, связанных с первым входом в систему (запуск при первом включении компьютера). The base image which ships for Server Core has been optimized by removing the start-up time overhead associated with first logon (OOBE). Для базового образа Nano Server такая оптимизация не применялась. This is not the case with Nano Server base image. Но эти издержки можно устранить и в образах на основе Nano Server, зафиксировав хотя бы один слой в образе контейнера. However, this cost can be removed from Nano Server based images by committing at least one layer to the container image. В этом случае при последующих запусках контейнера из образа не будет использоваться столько ресурсов, как при первом запуске. Subsequent container starts from the image will not incur the first logon cost.

Расположение области для временных файлов Scratch Space Location

По умолчанию контейнеры используют область на системном диске узла контейнера для хранения временных файлов во время существования запущенного контейнера. Containers, by default, use a temporary scratch space on the container host’s system drive media for storage during the lifetime of the running container. Эта область выполняет роль системного диска контейнера, поэтому к ней обращаются очень многие операции записи и чтения в контейнере. This serves as the container’s system drive, and as such many of the writes and reads done in container operation follow this path. Если система узла использует системный диск на вращающемся магнитом носителе (HDD), но располагает и более быстрым носителем для хранения данных (быстрый HDD или любой SSD), вы можете переместить область для временных файлов на другой диск. For host systems where the system drive exists on spinning disk magnetic media (HDDs) but faster storage media is available (faster HDDs or SSDs), it is possible to move the container scratch space to a different drive. Для этого примените команду dockerd –g. This is achieved by using the dockerd –g command. Эта команда имеет глобальный охват, влияя на все запущенные в системе контейнеры. This command is global, and will affect all containers running on the system.

Вложенные контейнеры Hyper-V Nested Hyper-V Containers

В Hyper-V для Windows Server 2016 добавлена поддержка вложенных гипервизоров. Hyper-V for Windows Server 2016 introduces nested hypervisor support. Теперь вы можете запустить виртуальную машину внутри другой виртуальной машины. That is, it is now possible to run a virtual machine from within a virtual machine. Это позволяет реализовать множество полезных сценариев, но одновременно и усиливает влияние гипервизоров на производительность, ведь на физическом узле работает сразу два уровня гипервизоров. This opens up many useful scenarios but also exaggerates some performance impact that the hypervisor incurs, as there are two level of hypervisors running above the physical host.

Для контейнеров это важно, когда контейнер Hyper-V работает внутри виртуальной машины. For containers, this has an impact when running a Hyper-V container inside a virtual machine. Контейнер Hyper-V обеспечивает изоляцию на уровне гипервизора между собой и узлом контейнера, а узел контейнера представляет собой виртуальную машину на основе Hyper-V. Поэтому наблюдается снижение производительности, связанное с временем запуска контейнера, операциями ввода-вывода хранилища и сети, пропускной способностью сети и производительностью ЦП. Since a Hyper-V Container offers isolation through a hypervisor layer between itself and the container host, when the container host is a Hyper-V based virtual machine, there is performance overhead associated in terms of container start-up time, storage io, network io and throughput, and CPU.

Хранение Storage

Подключенные тома данных Mounted Data Volumes

Контейнеры позволяют использовать системный диск узла контейнера для размещения области временных файлов контейнера. Containers offer the ability to use the container host system drive for the container scratch space. Но срок жизни файлов в этой области совпадает со сроком жизни контейнера. However, the container scratch space has a life span equal to that of the container. Это означает, что область временных файлов и все данные в ней очищаются при остановке контейнера. That is, when the container is stopped, the scratch space and all associated data goes away.

Но во многих сценариях требуется сохранять данные независимо от времени существования контейнера. However, there are many scenarios in which having data persist independent of container lifetime is desired. Для таких ситуаций мы реализовали возможность подключения к контейнеру томов данных из узла контейнера. In these cases, we support mounting data volumes from the container host into the container. Для контейнеров Windows Server использование подключенных томов данных незначительно влияет на операции ввода-вывода (производительность соответствует внутренним показателям). For Windows Server Containers, there is negligible IO path overhead associated with mounted data volumes (near native performance). Но при подключении томов данных к контейнерам Hyper-V в этом режиме наблюдается некоторое снижение производительности. However, when mounting data volumes into Hyper-V containers, there is some IO performance degradation in that path. Более того, это влияние усиливается при работе контейнеров Hyper-V внутри виртуальных машин. In addition, this impact is exaggerated when running Hyper-V containers inside of virtual machines.

Область временных файлов Scratch Space

Контейнеры Windows Server и контейнеры Hyper-V предоставляют динамический виртуальный жесткий диск объемом 20 ГБ в качестве области временных файлов контейнера по умолчанию. Both Windows Server Containers and Hyper-V containers provide a 20GB dynamic VHD for the container scratch space by default. В контейнерах обоих типов часть этой области занимает ОС контейнера, и это справедливо для каждого запущенного контейнера. For both container types, the container OS takes up a portion of that space, and this is true for every container started. Поэтому важно помнить, что каждый запущенный контейнер занимает часть физического хранилища и в зависимости от рабочей нагрузки может использовать для записи до 20 ГБ. Thus it is important to remember that every container started has some storage impact, and depending on the workload can write up to 20GB of the backing storage media. Это следует учитывать при планировании конфигураций хранилища для сервера. Server storage configurations should be designed with this in mind. (Можно ли настроить размер области временных файлов?) (can we configure scratch size)

сеть; Networking

Контейнеры Windows Server и контейнеры Hyper-V предоставляют несколько разных сетевых режимов, позволяя выбрать наиболее подходящий для разных сетевых конфигураций. Windows Server Containers and Hyper-V containers offer a variety of networking modes to best suit the needs of differing networking configurations. Каждый из этих режимов оказывает определенное влияние на производительность. Each of these options present their own performance characteristics.

Преобразование сетевых адресов Windows (WinNAT) Windows Network Address Translation (WinNAT)

Каждый контейнер получает IP-адрес из внутреннего частного пространства IP-адресов (например, 172.16.0.0/12). Each container will receive an IP address from an internal, private IP prefix (e.g. 172.16.0.0/12). Перенаправление и сопоставление портов из узла контейнера в конечные точки контейнера поддерживается. Port forwarding / mapping from the container host to container endpoints is supported. При первом запуске dockerd подсистема Docker создает сеть NAT. Docker creates a NAT network by default when the dockerd first runs.

Из этих трех режимов конфигурация NAT больше других влияет на операции сетевого ввода-вывода, но требует меньшего объема настроек. Of these three modes, the NAT configuration is the most expensive network IO path, but has the least amount of configuration needed.

Для подключения к виртуальному коммутатору контейнеры Windows Server используют виртуальный сетевой адаптер узла. Windows Server containers use a Host vNIC to attach to the virtual switch. Для подключения к виртуальному коммутатору контейнеры Hyper-V используют сетевой адаптер синтетической виртуальной машины (не предоставляется служебной виртуальной машине). Hyper-V Containers use a Synthetic VM NIC (not exposed to the Utility VM) to attach to the virtual switch. Когда контейнеры обмениваются данными с внешней сетью, пакеты направляются через WinNAT с применением преобразования адресов, что влечет за собой дополнительные издержки. When containers are communicating with the external network, packets are routed through WinNAT with address translations applied, which incurs some overhead.

Прозрачный режим Transparent

Каждая конечная точка контейнера подключена напрямую к физической сети. Each container endpoint is directly connected to the physical network. IP-адреса из физической сети могут назначаться статически или динамически с помощью внешнего DHCP-сервера. IP addresses from the physical network can be assigned statically or dynamically using an external DHCP server.

Прозрачный режим наиболее экономичен с точки зрения сетевого ввода-вывода, так как внешние пакеты передаются напрямую на виртуальный сетевой адаптер контейнера, предоставляя прямой доступ к внешней сети. Transparent mode is the least expensive in terms of the network IO path, and external packets are directly passed through to the container virtual NIC giving direct access to the external network.

Мост второго уровня L2 Bridge

Каждая конечная точка контейнера будет находиться в той же IP-подсети, что и узел контейнера. Each container endpoint will be in the same IP subnet as the container host. IP-адреса должны назначаться статически из того же префикса, что и узел контейнера. The IP addresses must be assigned statically from the same prefix as the container host. Все конечные точки контейнера на узле будут иметь одинаковый MAC-адрес из-за преобразования адресов второго уровня. All container endpoints on the host will have the same MAC address due to Layer-2 address translation.

Режим моста второго уровня обеспечивает более высокую производительность, чем режим WinNAT, так как он предоставляет прямой доступ к внешней сети. При этом его производительность ниже по сравнению с прозрачным режимом, так как выполняется преобразование MAC-адресов. L2 Bridge Mode is more performant than WinNAT mode as it provides direct access to the external network, but less performant than Transparent mode as it also introduces MAC address translation.