Рабочие процессы публикации CLI для разработчиков Azure

Эта azd publish команда позволяет создавать и отправлять образы контейнеров в реестр контейнеров, например Реестр контейнеров Azure или Docker Hub без немедленного развертывания в ресурсе Azure.

Разделив этапы сборки и отправки на шаг развертывания, можно реализовать более сложные рабочие процессы развертывания, такие как шаблон "сборка один раз, развертывание везде". Этот подход полезен для контейнерных приложений, предназначенных для приложений контейнеров Azure или Службы Azure Kubernetes (AKS).

Зачем использовать azd publish?

В стандартном azd рабочем процессе azd deploy команда выполняет три действия в последовательности:

  1. Сборка: Преобразует код вашего приложения в образ контейнера.
  2. Отправка: отправляет этот образ в реестр.
  3. Развертывание. Обновляет службу размещения Azure (например, контейнерные приложения) для запуска нового образа.

Хотя это удобно для циклической разработки, этот подход предполагает, что для каждого развертывания требуется новая сборка. В рабочих сценариях часто требуется:

  • Постройте один раз, разверните везде: создайте один артефакт (образ), протестируйте его в среде разработки, а затем перенесите тот же самый артефакт в рабочую среду, не перестраивая его.
  • Централизация артефактов. Используйте единый общий реестр контейнеров Azure (ACR) для хранения образов для всех сред.
  • Повышение безопасности: Убедитесь, что в рабочей среде развертываются только проверенные и протестированные образы.

azd publish включает эти сценарии, обрабатывая только шаги 1 и 2 (сборка и отправка). Затем можно использовать azd deploy с определенными флагами для обработки шага 3 (развертывание) с помощью предварительно опубликованного образа.

Ключевые особенности

  • Независимая публикация: публикация образов в реестре без активации развертывания.
  • Пользовательские целевые объекты: используйте --to флаг, чтобы указать, куда следует отправлять изображение ([registry/]repository[:tag]), переопределяя соглашения об именовании по умолчанию.
  • Поддержка сторонних реестров: отправка в внешние реестры (например, Docker Hub) в дополнение к реестру контейнеров Azure.
  • Поддержка хуков: поддерживает prepublish и postpublish хуки для пользовательской автоматизации.
  • Назначение службы: в настоящее время поддерживает службы, размещенные в приложениях контейнеров Azure и AKS.

Usage

Чтобы создать и опубликовать образ для конкретной службы, указанной в azure.yaml:

azd publish <service-name>

Чтобы создать и опубликовать все службы, выполните приведенные ниже действия.

azd publish --all

Параметры

Flag Description
--all Публикует все службы, определенные в azure.yaml.
--from-package <image> Использует существующий локальный образ или пакет вместо сборки из источника.
--to <image-ref> Указывает ссылку на целевое изображение (например, <your-registry>.azurecr.io/my-app:v1). Переопределяет стандартное именование в azure.yaml.

Замечание

Для сервисов, настроенных с помощью services.<name>.docker.imagePassthrough: true, azd publish не собирает и не отправляет образ. Вместо этого он использует настроенный удалённый образ повторно и отклоняет флаги --from-package и --to для этой службы.

Примеры

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

azd publish api-service --to <your-registry>.azurecr.io/api-service:v1.0.0

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

Если вы уже создали образ локально (например, local-api:dev), вы можете пометить и отправить его с помощью azd:

azd publish api-service --from-package local-api:dev --to <your-registry>.azurecr.io/api-service:v1.0.0

Сценарий: сборка один раз, развертывание везде

Распространенный рабочий процесс включает создание образа один раз и его продвижение через несколько сред, как Dev —> Test —> Prod. Это можно достичь с помощью сочетания azd publish и azd deploy.

Этот сценарий не относится к службам, настроенным с использованием services.<name>.docker.imagePassthrough: true, поскольку azd publish не собирает и не отправляет образ для этих служб.

  1. Опубликуйте изображение:

    Создайте код и отправьте его в общий реестр.

    azd publish api-service --to <your-registry>.azurecr.io/my-app:v1.0.0

  2. Развертывание в разработке:

    Разверните конкретную версию образа в среде разработки. Флаг --from-package сообщает azd deploy пропустить шаги сборки и отправки и просто обновить конфигурацию службы.

    azd env select dev
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0

  3. Выпустить в продуктивную среду:

    После тестирования в Dev разверните тот же образ в рабочем окружении.

    azd env select prod
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0

Сравнение с другими командами

Command Выполненные действия Лучше всего для
azd publish Создать - Отправить> Конвейеры CI/CD, создание артефактов, потоки "Собираем один раз".
azd publish --from-package Только принудительная отправка отправляет предварительно созданные артефакты в среды.
azd deploy Сборка —> отправка —> развертывание Итерация стандартной разработки (внутренний цикл).
azd deploy --from-package Развертывание только развертывание предварительно созданных или предварительно опубликованных артефактов в средах.
azd up Подготовка —> сборка —> push-отправка —> развертывание Начало работы, инициализация новых сред с нуля.

Замечание

Поведение azd up по умолчанию остается неизменным. Он по-прежнему управляет полным комплексным процессом. Однако при необходимости можно настроить рабочие процессы в azure.yaml, чтобы использовать azd publish.

Для служб, настроенных с services.<name>.docker.imagePassthrough: true, azd publish и azd publish --from-package не применяются. azd повторно использует настроенный удаленный образ вместо сборки или отправки.

Конфигурация в azure.yaml

Настройте параметры Docker по умолчанию для ваших служб в azure.yaml. Команда azd publish учитывает эти параметры, если не переопределяется флагами, такими как --to.

name: my-app
services:
  api:
    project: ./src/api
    host: containerapp
    docker:
      registry: 'docker.io/myusername' # Default registry
      image: 'my-api'                  # Default image name
      tag: 'latest'                    # Default tag

При этой конфигурации выполнение azd publish api отправит данные в docker.io/myusername/my-api:latest.

Повторно использовать удалённый образ с помощью imagePassthrough

Если у вашего сервиса уже есть опубликованный образ, который azd не должен собирать, публиковать или иным образом обслуживать, задайте services.<name>.docker.imagePassthrough: true. Если этот параметр включен, выполните следующие действия.

  • Задайте services.<name>.image как конечную полную ссылку на удалённый образ, включая явно указанный реестр.
  • Вы не можете сочетать docker.imagePassthrough с docker.remoteBuild.
  • azd publish не собирает и не отправляет образ для этого сервиса, а также не принимает флаги --from-package и --to для этого сервиса.
name: my-app
services:
  api:
    host: containerapp
    docker:
      imagePassthrough: true
    image: docker.io/myusername/my-api:v1.0.0

Дальнейшие шаги

  • Последнее обновление: