Flujos de trabajo de publicación de la CLI para desarrolladores de Azure

El azd publish comando permite compilar e insertar imágenes de contenedor en un registro de contenedor como Azure Container Registry o Docker Hub sin implementarlas inmediatamente en un recurso de Azure.

Al separar los pasos de compilación e inserción del paso de implementación, puede implementar flujos de trabajo de implementación más avanzados, como el patrón "compilar una vez, implementar en todas partes". Este enfoque es útil para las aplicaciones en contenedores destinadas a Azure Container Apps o Azure Kubernetes Service (AKS).

¿Por qué usar azd publish?

En un flujo de trabajo estándar azd , el azd deploy comando realiza tres acciones en secuencia:

1. Compilación: compila el código de la aplicación en una imagen de contenedor.
2. Inserción: inserta esa imagen en un registro.
3. Implementación: actualiza el servicio de hospedaje de Azure (como Container Apps) para ejecutar la nueva imagen.

Aunque resulta conveniente para el desarrollo de bucles internos, este enfoque supone que cada implementación requiere una nueva compilación. En escenarios de producción, a menudo se quiere:

• Compilar una vez, implementar en todas partes: cree un único artefacto (imagen), pruébelo en un entorno de desarrollo y, a continuación, promueva ese mismo artefacto exacto a producción sin volver a generarlo.
• Centralizar artefactos: use una sola instancia compartida de Azure Container Registry (ACR) para almacenar imágenes para todos los entornos.
• Mejorar la seguridad: asegúrese de que solo se implementan imágenes comprobadas y probadas en producción.

azd publish habilita estos escenarios controlando solo los pasos 1 y 2 (compilación y empuje). A continuación, puede usar azd deploy con marcas específicas para controlar el paso 3 (Implementar) mediante la imagen publicada previamente.

Características clave

• Publicación independiente: publique imágenes en un registro sin desencadenar una implementación.
• Destinos personalizados: use la --to marca para especificar exactamente dónde se debe insertar la imagen ([registry/]repository[:tag]), invalidando las convenciones de nomenclatura predeterminadas.
• Compatibilidad con el Registro de terceros: inserción en registros externos (como Docker Hub) además de Azure Container Registry.
• Soporte de ganchos: admite prepublish y postpublish ganchos para la automatización personalizada.
• Destino del servicio: actualmente admite servicios hospedados en Azure Container Apps y AKS.

Usage

Para compilar y publicar la imagen para un servicio específico definido en azure.yaml:

azd publish <service-name>

Para compilar y publicar todos los servicios:

azd publish --all

Parámetros

Examples

Publique un servicio específico en una etiqueta personalizada:

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

Publicar una imagen local en un registro remoto:

Si ya ha creado una imagen localmente (por ejemplo: local-api:dev), puede etiquetarla e insertarla mediante azd:

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

Escenario: Compilación una vez, implementación en todas partes

Un flujo de trabajo de producción común implica crear una imagen una vez y promocionarla a través de varios entornos, como Dev -> Test -> Prod. Consigue esto mediante una combinación de azd publish y azd deploy.

Este escenario no se aplica a los servicios configurados con services.<name>.docker.imagePassthrough: true, porque azd publish no compila ni inserta una imagen para esos servicios.

1. Publique la imagen:

   Compile el código e insértelo en el registro compartido.

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

2. Implementación en desarrollo:

   Implemente la versión de imagen específica en el entorno de desarrollo. La --from-package bandera indica a azd deploy que omita los pasos de compilar y empujar y solo actualice la configuración del servicio.

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

3. Promocionar a producción:

   Después de realizar pruebas en Dev, implemente la misma referencia de imagen al entorno de producción.

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

Comparación con otros comandos

Configuración en azure.yaml

Configure los valores predeterminados de Docker para los servicios en azure.yaml. El azd publish comando respeta esta configuración a menos que se invalide mediante marcas como --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

Con esta configuración, ejecutar azd publish api empujaría a docker.io/myusername/my-api:latest.

Reutilización de una imagen remota con imagePassthrough

Si el servicio ya tiene una imagen publicada que azd no debe compilar, insertar o administrar, establezca services.<name>.docker.imagePassthrough: true. Al habilitar esta opción:

• Establezca services.<name>.image como la referencia final completa de la imagen remota, incluyendo un registro explícito.
• No se puede combinar docker.imagePassthrough con docker.remoteBuild.
• azd publish no compila ni publica una imagen para el servicio, y rechaza las opciones --from-package y --to para ese servicio.

name: my-app
services:
  api:
    host: containerapp
    docker:
      imagePassthrough: true
    image: docker.io/myusername/my-api:v1.0.0

Pasos siguientes

• Referencia del comando azd deploy
• Uso de registros de contenedor externos
• Configuración de canalizaciones de Acciones de GitHub