Как использовать команду docker buildx create для управления сборщиками

DockerDockerBeginner
Практиковаться сейчас

💡 Этот учебник переведен с английского с помощью ИИ. Чтобы просмотреть оригинал, вы можете перейти на английский оригинал

Введение

В этой лабораторной работе вы научитесь эффективно управлять сборщиками (builders) Docker с помощью команды docker buildx create. Мы рассмотрим ключевые шаги: создание нового экземпляра сборщика, добавление новых узлов к существующему сборщику, назначение пользовательских имён для сборщиков и узлов, настройку поддерживаемых платформ для узла сборки, а также автоматическое переключение на вновь созданный сборщик для операций сборки. К концу этой лабораторной работы у вас будет чёткое понимание того, как настраивать и использовать различные конфигурации сборщиков для мультиархитектурных и распределённых сборок.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL docker(("Docker")) -.-> docker/ContainerOperationsGroup(["Container Operations"]) docker/ContainerOperationsGroup -.-> docker/ls("List Containers") docker/ContainerOperationsGroup -.-> docker/rm("Remove Container") docker/ContainerOperationsGroup -.-> docker/inspect("Inspect Container") docker/ContainerOperationsGroup -.-> docker/create("Create Container") subgraph Lab Skills docker/ls -.-> lab-555046{{"Как использовать команду docker buildx create для управления сборщиками"}} docker/rm -.-> lab-555046{{"Как использовать команду docker buildx create для управления сборщиками"}} docker/inspect -.-> lab-555046{{"Как использовать команду docker buildx create для управления сборщиками"}} docker/create -.-> lab-555046{{"Как использовать команду docker buildx create для управления сборщиками"}} end

Создание нового экземпляра сборщика

На этом шаге мы научимся создавать новый экземпляр сборщика с помощью команды docker buildx create. Экземпляр сборщика (builder instance) — это объект Docker, который управляет несколькими узлами сборки (build nodes). Каждый узел может представлять отдельную архитектуру или окружение для сборки образов.

Перед созданием нового сборщика давайте проверим существующие сборщики в вашей системе. Это можно сделать с помощью команды docker buildx ls.

docker buildx ls

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

Теперь создадим новый экземпляр сборщика. Назовём его mybuilder.

docker buildx create --name mybuilder

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

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

docker buildx ls

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

Добавление нового узла к существующему сборщику

На предыдущем шаге мы создали новый экземпляр сборщика с именем mybuilder. В данный момент этот сборщик не содержит узлов сборки. В этом шаге мы добавим новый узел к существующему сборщику.

Узел сборки (build node) — это по сути Docker-эндпоинт, в котором будет выполняться процесс сборки. По умолчанию при создании нового сборщика без указания узла он создаётся без активных узлов.

Чтобы добавить новый узел к сборщику mybuilder, мы снова воспользуемся командой docker buildx create, но на этот раз укажем сборщик, к которому нужно добавить узел, с помощью флага --append. Мы добавим узел к сборщику mybuilder.

docker buildx create --name mybuilder --append

Эта команда добавляет новый узел к сборщику mybuilder. По умолчанию, если имя узла не указано, Docker Buildx автоматически генерирует его.

Давайте снова выведем список сборщиков, чтобы увидеть обновлённый экземпляр mybuilder с новым узлом.

docker buildx ls

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

Указание имен для сборщика и узла

На предыдущих шагах мы создали сборщик с именем mybuilder и добавили к нему узел с автоматически сгенерированным именем. В этом шаге мы научимся явно указывать имена как для сборщика, так и для узла при их создании.

Сначала удалим сборщик mybuilder, созданный ранее, чтобы начать с чистого листа.

docker buildx rm mybuilder

Теперь создадим новый экземпляр сборщика с именем custombuilder и укажем имя для его начального узла как node1. Для этого используем флаг --name для сборщика и флаг --node для узла.

docker buildx create --name custombuilder --node node1

Эта команда создает новый экземпляр сборщика custombuilder с начальным узлом node1.

Проверим список сборщиков для подтверждения имен.

docker buildx ls

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

Настройка поддерживаемых платформ для узла

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

Сначала проверим сборщик custombuilder, созданный на предыдущем шаге, чтобы увидеть поддерживаемые его узлом платформы.

docker buildx inspect custombuilder

В выводе найдите поле "Platforms". Оно должно показывать нативную архитектуру вашей LabEx VM (например, linux/amd64).

Теперь обновим узел node1 в custombuilder, добавив поддержку дополнительных платформ. Используем команду docker buildx create с флагами --append и --platform. Добавим поддержку linux/arm64 и linux/riscv64.

docker buildx create --name custombuilder --append --node node1 --platform linux/arm64,linux/riscv64

Обратите внимание, что мы используем --append с существующими именами сборщика и узла. Эта команда обновляет существующий узел node1 в custombuilder, добавляя указанные платформы.

Проверим сборщик снова, чтобы увидеть обновлённый список платформ для node1.

docker buildx inspect custombuilder

Теперь в поле "Platforms" для node1 должны отображаться linux/amd64, linux/arm64 и linux/riscv64. Это означает, что узел теперь может собирать образы для этих архитектур.

Автоматическое переключение на новый сборщик

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

По умолчанию Docker Buildx использует сборщик default. Текущий активный сборщик можно определить по выводу команды docker buildx ls - его имя будет помечено звёздочкой (*).

docker buildx ls

Для переключения на созданный нами custombuilder используйте команду docker buildx use с указанием имени сборщика.

docker buildx use custombuilder

Эта команда устанавливает custombuilder в качестве текущего активного сборщика. Все последующие команды docker buildx build будут использовать узлы, настроенные в custombuilder.

Проверим, что custombuilder стал активным сборщиком, повторно выведя список сборщиков.

docker buildx ls

Теперь рядом с custombuilder должна отображаться звёздочка (*), что подтверждает его активный статус.

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

Итоги

В этой лабораторной работе мы изучили управление сборщиками Docker с помощью команды docker buildx create. Мы начали с создания нового экземпляра сборщика с именем mybuilder, продемонстрировав инициализацию отдельной среды сборки. Затем мы рассмотрели, как добавить новый узел сборки к существующему сборщику, эффективно расширяя возможности нашего экземпляра mybuilder.

Кроме того, мы рассмотрели:

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

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