Введение
В этой лабораторной работе вы научитесь использовать команду docker buildx inspect для просмотра деталей о ваших экземплярах сборщиков Docker. Вы начнёте с проверки текущего экземпляра сборщика, а затем узнаете, как указать сборщик по имени.
Вы также изучите, как убедиться, что сборщик запущен перед проверкой с помощью флага --bootstrap, и как получить более подробную информацию с флагом --debug, что позволит вам получить полное представление о конфигурации и состоянии вашего сборщика.
Проверка текущего экземпляра сборщика
На этом шаге вы узнаете, как проверить текущий экземпляр сборщика Docker. Сборщик Docker отвечает за создание образов Docker. Проверка сборщика позволяет получить информацию о его конфигурации и состоянии.
Сначала воспользуемся командой docker buildx inspect без указания имени сборщика. Это проверит текущий экземпляр сборщика.
docker buildx inspect
Вы должны увидеть вывод, похожий на этот, с деталями о сборщике по умолчанию:
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
В выводе содержится информация, такая как имя сборщика, используемый драйвер (в данном случае docker), а также детали о нодах сборки, включая их статус, версию BuildKitd и поддерживаемые платформы.
Проверка конкретного экземпляра сборщика по имени
На предыдущем шаге вы проверили текущий экземпляр сборщика. В этом шаге вы узнаете, как проверить конкретный экземпляр сборщика по его имени. Хотя изначально у вас может быть только сборщик по умолчанию, умение указывать имя полезно, когда у вас настроено несколько сборщиков.
Для проверки конкретного экземпляра сборщика используйте команду docker buildx inspect, за которой следует имя сборщика. Сборщик по умолчанию обычно называется default.
Давайте явно проверим сборщик default по имени:
docker buildx inspect default
Вы должны увидеть тот же вывод, что и на предыдущем шаге, подтверждающий, что вы проверяете экземпляр сборщика default.
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
Это демонстрирует, как выбрать конкретный экземпляр сборщика для проверки, используя его имя.
Убедитесь, что сборщик запущен перед проверкой с параметром --bootstrap
На этом шаге вы узнаете, как использовать флаг --bootstrap с командой docker buildx inspect. Флаг --bootstrap гарантирует, что экземпляр сборщика запущен перед попыткой его проверки. Если сборщик не работает, этот флаг автоматически его запустит.
Хотя сборщик по умолчанию обычно работает, рекомендуется использовать --bootstrap, когда необходимо убедиться, что сборщик активен перед проверкой или другими операциями сборки.
Давайте снова проверим сборщик по умолчанию, на этот раз с флагом --bootstrap:
docker buildx inspect --bootstrap default
Вы должны увидеть тот же результат проверки, что и ранее. Флаг --bootstrap гарантирует, что сборщик находится в рабочем состоянии перед выполнением проверки. Если бы сборщик был остановлен, эта команда сначала бы его запустила.
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
Использование --bootstrap особенно полезно в скриптах или автоматизированных процессах, где необходимо убедиться, что сборщик готов перед началом сборки.
Просмотр детальной информации с параметром --debug
В этом завершающем шаге вы узнаете, как получить более подробную информацию об экземпляре сборщика, используя флаг --debug с командой docker buildx inspect. Флаг --debug предоставляет дополнительный вывод, который может быть полезен для устранения неполадок или более глубокого понимания конфигурации сборщика.
Давайте снова проверим сборщик по умолчанию, на этот раз с флагом --debug:
docker buildx inspect --debug default
Вы увидите стандартный вывод проверки, но ему будут предшествовать отладочные логи. Эти логи дают представление о внутренних операциях команды buildx inspect и взаимодействии с демоном BuildKit.
Отладочный вывод будет содержать строки, начинающиеся с DEBU[..., за которыми следует подробная информация о процессе. Это может включать вызовы API, загрузку конфигурации и другие внутренние процессы.
DEBU[0000] loading config file /home/labex/.docker/config.json
DEBU[0000] Looking for builder "default"
DEBU[0000] found builder "default"
DEBU[0000] loading builder "default"
DEBU[0000] found 1 node(s) for builder "default"
DEBU[0000] loading node "default"
DEBU[0000] connecting to docker
DEBU[0000] running buildkitd container "buildx_buildkit_default"
DEBU[0000] buildkitd container "buildx_buildkit_default" is running
DEBU[0000] connecting to buildkitd
DEBU[0000] buildkitd connection successful
Name: default
Driver: docker
Nodes:
default:
Status: running
Buildkitd:
Version: v0.10.5
Platforms:
- linux/amd64
- linux/arm64
- linux/riscv64
- linux/ppc64le
- linux/s390x
- linux/386
- linux/arm/v7
- linux/arm/v6
Флаг --debug является мощным инструментом для диагностики проблем или получения более глубокого понимания того, как docker buildx взаимодействует с базовой службой BuildKit.
Резюме
В этой лабораторной работе вы научились использовать команду docker buildx inspect для просмотра информации о сборщиках Docker. Вы начали с проверки текущего сборщика без указания имени, что по умолчанию показывает информацию о стандартном сборщике. Затем вы узнали, как явно проверить конкретный сборщик, указав его имя, и убедились, что для стандартного сборщика выводятся те же данные.
Эти шаги продемонстрировали базовое использование docker buildx inspect для получения информации о вашей среде сборки Docker, включая имя сборщика, драйвер, статус узлов, версию BuildKitd и поддерживаемые платформы.
