Implementación continua con contenedores personalizados en Azure App Service
En este tutorial, configurará una implementación continua para una imagen de contenedor personalizada desde los repositorios administrados de Azure Container Registry o Docker Hub.
1. Ir al centro de implementación
En Azure Portal, vaya a la página de administración de la aplicación App Service.
En el menú de la izquierda, haga clic en Centro de implementación>Configuración.
2. Elegir origen de la implementación
Elija el origen de implementación en función de su escenario:
- Container Registry configura CI/CD entre el registro de contenedor y App Service.
- La opción Acciones de GitHub se utiliza si se mantiene el código fuente de la imagen de contenedor en GitHub. Desencadenada por nuevas confirmaciones en el repositorio de GitHub, la acción de implementación puede ejecutar
docker build
ydocker push
directamente en el registro de contenedor y, después, actualizar la aplicación App Service para ejecutar la nueva imagen. Para más información, consulte el funcionamiento de CI/CD con Acciones de GitHub. - Para configurar CI/CD con Azure Pipelines, consulte implementación de un contenedor de aplicación web de Azure en Azure Pipelines.
Nota
Para una aplicación de Docker Compose, seleccione Container Registry.
Si elige Acciones de GitHub, haga clic en Autorizar y siga las indicaciones de autorización. Si ya ha autorizado antes con GitHub, puede realizar la implementación desde un repositorio de otro usuario haciendo clic en Cambiar cuenta.
Cuando autorice su cuenta de Azure con GitHub, seleccione la organización, el repositorioy la rama desde donde se va a realizar la implementación.
2. Configurar el registro
3. Configurar el registro
Nota:
Los contenedores sidecar (versión preliminar) se realizarán correctamente en aplicaciones de varios contenedores (Docker Compose) en App Service. Para empezar, consulte Tutorial: Configuración de un contenedor sidecar para un contenedor personalizado en Azure App Service (versión preliminar).
Para implementar una aplicación de varios contenedores (Docker Compose), seleccione Docker Compose en Tipo de contenedor.
Si no ve la lista desplegable Tipo de contenedor, desplácese hacia atrás hasta el origen y seleccione Container Registry.
En el origen del registro, seleccione el lugar en el que se encuentra el registro de contenedor. Si no es Azure Container Registry ni Docker Hub, seleccione Registro privado.
Nota:
Si la aplicación de varios contenedores (Docker Compose) usa más de una imagen privada, asegúrese de que las imágenes privadas se encuentren en el mismo registro privado y estén accesibles con las mismas credenciales de usuario. Si la aplicación de varios contenedores solo usa imágenes públicas, seleccione Docker Hub, aunque algunas imágenes no estén en Docker Hub.
Siga los pasos siguientes. Para ello, seleccione la pestaña que coincida con su elección.
La lista desplegable Registro muestra los registros de la misma suscripción que la aplicación. Seleccione el registro que desee.
Nota:
- Si desea usar identidades administradas para bloquear el acceso a ACR, siga esta guía:
- Para implementar desde un registro en una suscripción diferente, seleccione en cambio Registro privado en el origen del registro.
Seleccione la imagen y la etiqueta que quiere implementar. Si lo desea, escriba el comando de inicio en el archivo de inicio.
Siga este paso según el tipo de contenedor:
- En Docker Compose, seleccione el registro para las imágenes privadas. Haga clic en Elegir archivo para cargar el archivo de Docker Composeo simplemente pegue el contenido del archivo Docker Compose en la configuración.
- Para un solo contenedor, seleccione la imagen y la etiqueta que quiere implementar. Si lo desea, escriba el comando de inicio en el archivo de inicio.
App Service anexa la cadena del archivo de inicio al final del comando docker run
(como el segmento [COMMAND] [ARG...]
) al iniciar el contenedor.
3. Habilitar CI/CD
4. Habilitar CI/CD
App Service admite la integración de CI/CD con Azure Container Registry y Docker Hub. Para habilitarla, seleccione Activado en Implementación continua.
Nota:
Si selecciona Acciones de GitHub en Origen, no se obtendrá esta opción porque Acciones de GitHub controlan CI/CD directamente. En su lugar, verá una sección de configuración de flujo de trabajo, donde puede hacer clic en Vista previa del archivo para inspeccionar el archivo de flujo de trabajo. Azure confirma este archivo en el repositorio de origen de GitHub seleccionado para controlar las tareas de compilación e implementación. Para más información, consulte el funcionamiento de CI/CD con Acciones de GitHub.
Cuando se habilita esta opción, App Service agrega un webhook al repositorio en Azure Container Registry o Docker Hub. El repositorio se envía a este webhook cada vez que se actualiza la imagen seleccionada con docker push
. El webhook hace que la aplicación App Service se reinicie y ejecute docker pull
para obtener la imagen actualizada.
Nota:
Para garantizar el funcionamiento adecuado del webhook, es esencial habilitar la opción Credenciales básicas de publicación de autenticación en la aplicación web. Si no se hace, puede aparecer un error "401 No autorizado" para el webhook. Para comprobar si la opción Credenciales básicas de publicación de autenticación está habilitada, siga estos pasos:
- Vaya a Configuración > Configuración general de su aplicación web.
- Busque la sección Configuración de la plataforma, donde encontrará la opción Credenciales básicas de publicación de autenticación.
Para otros registros privados, puede publicar en el webhook manualmente o como un paso en una canalización de CI/CD. En URL de webhook, haga clic en el botón Copiar para obtener la dirección URL del webhook.
Nota
La compatibilidad con aplicaciones de varios contenedores (Docker Compose) es limitada:
- Para Azure Container Registry, App Service crea un webhook en el registro seleccionado con el registro como ámbito. Un
docker push
a cualquier repositorio del registro (incluidos los a los que no hace referencia el archivo Docker Compose) desencadena un reinicio de la aplicación. Puede que quiera modificar el webhook a un ámbito más restringido. - Docker Hub no admite webhooks en el nivel del registro. Debe agregar los webhooks manualmente a las imágenes especificadas en el archivo de Docker Compose.
4. Guardar la configuración
5. Guardar la configuración
Haga clic en Guardar.
Funcionamiento de CI/CD con Acciones de GitHub
Si elige Acciones de GitHub en Origen (consulte Elección del origen de implementación), App Service configura CI/CD de las siguientes maneras:
- Deposita un archivo de flujo de trabajo de Acciones de GitHub en el repositorio de GitHub para controlar las tareas de compilación e implementación en App Service.
- Agrega las credenciales del registro privado como secretos de GitHub. El archivo de flujo de trabajo generado ejecuta la acción de inicio de sesión de Azure/Docker para iniciar sesión en el registro privado y, a continuación, ejecuta
docker push
para implementarlo. - Agrega el perfil de publicación de la aplicación como secreto de GitHub. El archivo de flujo de trabajo generado usa este secreto para autenticarse con App Service y, a continuación, ejecuta la acción Azure/aplicaciones web-deploy para configurar la imagen actualizada, lo que desencadena un reinicio de la aplicación para extraer la imagen actualizada.
- Captura la información de los registros de ejecución del flujo de trabajo y la muestra en la pestaña Registros del Centro de implementaciónde la aplicación.
Puede personalizar el proveedor de compilación de Acciones de GitHub de las siguientes maneras:
- Personalice el archivo de flujo de trabajo después de que se genere en el repositorio de GitHub. Para más información, consulte Sintaxis de flujo de trabajo para Acciones de GitHub. Solo tiene que asegurarse de que el flujo de trabajo finaliza con la acción Azure/webapps-deploy para desencadenar un reinicio de la aplicación.
- Si la rama seleccionada está protegida, todavía puede obtener una vista previa del archivo de flujo de trabajo sin guardar la configuración, después, agregarla junto con los secretos de GitHub requeridos manualmente al repositorio. Este método no proporciona la integración de registros con Azure Portal.
- En lugar de un perfil de publicación, utilice una entidad de servicio para realizar la implementación en Microsoft Entra ID.
Autenticación con una entidad de servicio
Esta configuración opcional reemplaza la autenticación predeterminada por los perfiles de publicación en el archivo de flujo de trabajo generado.
Genere una entidad de servicio mediante el comando az ad sp create-for-rbac de la CLI de Azure. En el ejemplo siguiente, reemplace <subscription-id>, <group-name> y <app-name> por sus propios valores. Guarde la salida JSON completa para el paso siguiente, incluido {}
de nivel superior.
az ad sp create-for-rbac --name "myAppDeployAuth" --role contributor \
--scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
--json-auth
Importante
Por seguridad, conceda el acceso mínimo necesario a la entidad de servicio. El ámbito del ejemplo anterior se limita a la aplicación específica de App Service y no a todo el grupo de recursos.
En GitHub, examine el repositorio y seleccione Configuración > Secretos > Agregar un nuevo secreto. Pegue la salida JSON completa del comando de la CLI de Azure en el campo de valor del secreto. Asigne un nombre al secreto, como AZURE_CREDENTIALS
.
En el archivo de flujo de trabajo generado por el centro de implementación, revise el paso azure/webapps-deploy
con código como el ejemplo siguiente:
- name: Sign in to Azure
# Use the GitHub secret you added
- uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy to Azure Web App
# Remove publish-profile
- uses: azure/webapps-deploy@v2
with:
app-name: '<app-name>'
slot-name: 'production'
images: '<registry-server>/${{ secrets.AzureAppService_ContainerUsername_... }}/<image>:${{ github.sha }}'
- name: Sign out of Azure
run: |
az logout
Automatización con la interfaz de la línea de comandos
Para configurar el registro de contenedor y la imagen de Docker, ejecute az webapp config container set.
az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name '<image>:<tag>' --docker-registry-server-url 'https://<registry-name>.azurecr.io' --docker-registry-server-user '<username>' --docker-registry-server-password '<password>'
Para configurar una aplicación de varios contenedores (Docker Compose), prepare un archivo de Docker Compose localmente y, después, ejecute az webapp config container set con el parámetro --multicontainer-config-file
. Si el archivo de Docker Compose contiene imágenes privadas, agregue los parámetros --docker-registry-server-*
como se muestra en el ejemplo anterior.
az webapp config container set --resource-group <group-name> --name <app-name> --multicontainer-config-file <docker-compose-file>
Para configurar CI/CD desde el registro de contenedor para la aplicación, ejecute az webapp deployment container config con el parámetro --enable-cd
. El comando genera la dirección URL del webhook, pero debe crear el webhook en el registro manualmente en un paso independiente. En el ejemplo siguiente, se habilita CI/CD en la aplicación y, a continuación, se usa la dirección URL del webhook en la salida para crear el webhook en Azure Container Registry.
ci_cd_url=$(az webapp deployment container config --name <app-name> --resource-group <group-name> --enable-cd true --query CI_CD_URL --output tsv)
az acr webhook create --name <webhook-name> --registry <registry-name> --resource-group <group-name> --actions push --uri $ci_cd_url --scope '<image>:<tag>'
Más recursos
- Azure Container Registry
- Creación de una aplicación web de .NET Core en App Service en Linux
- Inicio rápido: Ejecución de un contenedor personalizado en App Service
- Peguntas más frecuentes sobre App Service en Linux
- Configurar contenedores personalizados
- Flujos de trabajo de acciones para implementar en Azure