Управление кроссплатформенными изображениями Docker для совместимости с Windows и Linux

Файловая система и разрешения

Изображения Linux используют разрешения POSIX (пользователь, группа, другие) и чувствительные к регистру пути файлов. Изображения Windows полагаются на ACL (списки контроля доступа) и чувствительные к регистру пути. Запуск изображения Linux с кодом, который ожидает обработку чувствительных к регистру файлов на хосте Windows (даже в контейнере) может привести к тонким ошибкам. И наоборот, пути с обратными слэшами или буквами диска (например, [FLT: 5]] не будут разрешаться в контейнере Linux. Любой кроссплатформенный дизайн должен гарантировать, что ваш код приложения и конфигурационные файлы используют конструкции платформенно-агностических путей или что вы вводите правильную конвенцию пути для целевой ОС.

Мультиархитектурные изображения с Docker Buildx

Как работает Buildx

Docker Buildx - это рекомендуемый способ создания изображений, которые могут работать на нескольких платформах с одного вызова сборки. Он использует эмуляцию на основе QEMU (для кросс-компиляции Linux-on-Linux) или нативные конструкторы на отдельных узлах для компиляции изображения для каждой целевой архитектуры. Для сборок кросс-платформ Windows и Linux обычно требуются нативные узлы сборки Windows и Linux, потому что QEMU не может эмулировать ядро Windows.

Buildx создает многоархитектурный манифест (также называемый списком манифестов или ), который ссылается на одно или несколько изображений, каждое из которых помечено своей платформой. Когда пользователь запускает на машине Windows, Docker автоматически выбирает вариант Windows из манифеста. На машине Linux выбирается вариант Linux. Не требуется ручное переключение тегов.

Настройка Buildx Builder для кросс-платформы

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

После того, как конструктор настроен, вы можете построить и нажать манифест в один шаг:

Флаг автоматически подталкивает как отдельные изображения, так и список манифестов к реестру. Никаких дополнительных команд создания манифестов не требуется.

Ограничения и погони

• Перекрестная компиляция Windows-on-Linux невозможна, потому что вы не можете использовать QEMU для эмуляции ядра Windows.
• Поддержка реестров должна включать в себя списки манифестов. Большинство основных реестров (Docker Hub, AWS ECR, Azure ACR, GitHub Container Registry) поддерживают их. Некоторые частные реестры могут потребовать от вас проверки совместимости.
• Кэширование уровня является пер-платформенным.Кэширование, построенное на узле Linux, не применяется к сборке Windows. Планируйте отдельные шаги CI или используйте совместно используемое местоположение кэша, которое уважает платформу.
• Тэг неизменности: Как только вы нажимаете список манифестов, вы не можете изменить его, не отбрасывая все ссылки на изображения. Всегда используйте новый тег или схему неизменной версии, если вам нужно откатиться назад.

Разработка Dockerfiles для кросс-платформы

Условные шаги с многоступенчатыми конструкциями

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

ARG BASE_IMAGE
FROM ${BASE_IMAGE} AS base

FROM base AS install-linux
RUN apt-get update && apt-get install -y libfoo

FROM base AS install-windows
RUN powershell -Command Install-Package -Name Foo

FROM install-${TARGETOS} AS final
COPY app /app
CMD ["/app/start"]

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

Переменные среды и конфигурационная инъекция

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

ARG TARGETOS
ENV CONFIG_DIR=/etc/myapp
ENV CONFIG_DIR=C:\\ProgramData\\MyApp

Однако будьте осторожны: приведенный выше пример является иллюстративным, но не может работать как есть, потому что директива оценивается во время сборки, но arg доступна во время сборки на платформу. Вы можете использовать «оболочку» с условным скриптом платформы или шаблоном времени сборки. Более надежный подход заключается в введении каталогов конфигурации для конкретной платформы через или Kubernetes ConfigMap для типа узла, а не в выпечке его в изображение.

Обработка линейных концовок и исполняемых битов

Linux ожидает окончания строки LF в скриптах оболочки и конфигурационных файлах; Windows использует CRLF. Когда вы проверяете файлы в репозиторий Git, установите для хранения скриптов в качестве LF и конвертации на кассе только для хостов Windows. В Dockerfile явно помечайте сценарии начальной точки как исполняемые с (только для Linux) или используйте директиву , которая работает одинаково на обеих платформах (требуется Docker BuildKit).

CI/CD интеграция трубопроводов

Matrix строит для каждой платформы

В GitHub Actions, GitLab CI, или Azure Pipelines, используют матричную стратегию для создания и тестирования изображения в пулах бегунов Linux и Windows отдельно. После каждой сборки, подтолкните изображение, специфичное для платформы, к реестру с тегом, который включает суффикс платформы (например, , ).

Пример рабочего процесса GitHub Actions (упрощенный)

jobs:
 build:
 strategy:
 matrix:
 os: [ubuntu-latest, windows-latest]
 include:
 - os: ubuntu-latest
 platform: linux/amd64
 - os: windows-latest
 platform: windows/amd64
 runs-on: ${{ matrix.os }}
 steps:
 - uses: actions/checkout@v4
 - name: Build and push
 uses: docker/build-push-action@v5
 with:
 platforms: ${{ matrix.platform }}
 tags: myapp:${{ matrix.platform }}-${{ github.sha }}
 push: true

 manifest:
 needs: build
 runs-on: ubuntu-latest
 steps:
 - uses: docker/setup-buildx-action@v3
 - name: Create manifest list
 run: |
 docker buildx imagetools create \
 -t myregistry.io/myapp:latest \
 myregistry.io/myapp:linux-amd64-${{ github.sha }} \
 myregistry.io/myapp:windows-amd64-${{ github.sha }}

Тестирование на обеих платформах

Интегрируйте интеграционные тесты для конкретной платформы в одни и те же сборки матриц. Например, после создания образа Windows на бегуне Windows, запустите дымовой тест, который проверяет запуск приложения и отвечает на ожидаемый порт. Для Linux делайте то же самое. Только если оба набора тестов пройдут, должно произойти явное создание. Это предотвращает объединение сломанного образа Windows в тег «многоуровневый», который пользователи Linux ожидают работать.

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

Отладка кросс-платформенных проблем

Общие режимы неудач

• Базовое несоответствие изображения : версия Windows Server Core (например, ltsc2022 vs. ltsc2019) не соответствует версии хост-ОС. Всегда прикрепляйте к определенному тегу выпуска Windows и координируйте с вашей командой по инфраструктуре.
• Ограничения памяти и параметры ядра: Контейнеры Windows могут требовать изоляции Hyper-V для обеспечения ограничений памяти, в то время как контейнеры Linux могут использовать CFS (Completely Fair Scheduler).
• Различия в работе сети : Контейнеры Windows по умолчанию используют коммутатор на основе NAT, а связывание портов ведет себя по-разному. не поддерживается в Windows. Убедитесь, что ваше приложение не зависит от хост-сетей, если вы не используете Linux.
• Запирание и сигналы файлов : Windows не поддерживает сигналы POSIX так же, как это делает Linux. Отправка SIGTERM в процесс внутри контейнера Windows может не вызвать изящное отключение. Создайте приложение для обработки (Windows) в качестве обработчика сигналов.

Инструменты для регистрации и интроспекции

При отладке кроссплатформенной проблемы используйте для проверки ОС и архитектуры изображения. Посмотрите на поля и под :

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

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

Реальные модели и подводные камни

Паттерн: использование Docker Desktop для локального развития

Docker Desktop на Windows может переключаться между режимами Linux и Windows-контейнеров, но не может работать одновременно. Для кроссплатформенной разработки используйте отдельные удаленные конструкторы или виртуальные машины. Возможность Docker Desktop запускать контейнеры Linux нативно (через WSL 2) уменьшила потребность в контейнерах Windows на рабочих станциях разработчиков, но вам все равно нужны контейнеры Windows для интеграционного тестирования функций изображения только для Windows.

Паттерн: LTS Alignment для Windows Images

Microsoft выпускает новую версию Windows Server с поддержкой канала долгосрочного обслуживания (LTSC) примерно каждые два-три года. Каждая версия LTSC имеет соответствующее изображение базы контейнеров. Если ваше изображение контейнера Windows нацелено на ltsc2022, вы должны построить его на хосте ltsc2022 и запустить его на хостах ltsc2022. Нет гарантии обратной совместимости. Планируйте свой каденция обновления, чтобы соответствовать циклу выпуска Microsoft. Для Linux это ограничение намного слабее, но все же стоит отметить: изображение, построенное на очень старом ядре (]), может работать на более новых ядрах, но изображение, построенное с более новыми зависимыми от ядра сискалами (например, ]), выйдет из строя на старых хостах.

Недостаток: игнорирование ARM64

В то время как статья посвящена Windows и Linux, будущее вычислений неоднородно: кластеры AWS Graviton, Azure Ampere, Apple Silicon и Raspberry Pi работают под управлением ARM64 Linux. Если вы создаете многоархитектурное изображение для Windows и Linux, рассмотрите также включение в свой манифест. Многие бегуны CI теперь предлагают собственные узлы ARM64 Linux, а экосистема Docker Buildx легко обрабатывает кросс-компиляцию. Исключение ARM64 сегодня может привести к дорогостоящим усилиям по реинжинирингу за 12-18 месяцев.

Pitfall: просмотр разрешений файловой системы в COPY

При использовании в Dockerfile Docker уважает метаданные файловой системы хоста-источника. Если вы КСОПИруете скрипт с хоста Linux, он сохраняет свои исполняемые биты и окончания строки LF. Если вы КСОПИ с хоста Windows, файл приземляется без исполняемого бита и с окончаниями CRLF. Чтобы гарантировать последовательное поведение, используйте и убедитесь, что ваши исходные файлы проверены в Git с окончаниями строки LF. Альтернативно, добавьте шаг , который нормализует разрешения на платформу после COPY.

Заключение

Управление кроссплатформенными изображениями Docker для совместимости с Windows и Linux больше не является экзотическим вариантом использования. Это практическое требование для любого флота, который охватывает гетерогенную инфраструктуру, от локальных кластеров Windows Server до облачных Linux Kubernetes. Приняв Docker Buildx для многоархитектурных манифестов, поддерживая платформенные условные Dockerfiles, интегрируя матрицу на основе CI / CD конвейера и строго тестируя оба семейства ОС, вы можете предоставить один тег изображения, который работает беспрепятственно на всем вашем флоте.

Ключевые выводы просты:

• Используйте с нативными узлами Windows и Linux для создания списков манифестов.
• Создайте свои Dockerfiles с помощью и , чтобы избежать дублирования кода.
• Автоматизация сборок и тестов для конкретной платформы в CI; только слияние проявляется после прохождения обоих.
• Оставайтесь в курсе циклов выпуска LTSC от Microsoft, чтобы избежать несоответствия базовой версии изображения.

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