Implementación de una aplicación en Azure mediante flujos de trabajo de Acciones de GitHub creados por Visual Studio
A partir de la versión 16.11 de Visual Studio 2019, puede crear flujos de trabajo de Acciones de GitHub para proyectos de .NET hospedados en GitHub.com.
Requisitos previos
- Debe iniciar sesión en la Cuenta de GitHub en Visual Studio.
- Una cuenta de Azure. Si no tiene una cuenta de Azure, active las Ventajas de Azure para suscriptores de Visual Studio o regístrese para obtener una evaluación gratuita.
Implementación de un único proyecto en Azure mediante Acciones de GitHub
En el Explorador de soluciones, haga clic con el botón derecho en su proyecto hospedado en GitHub.com y seleccione Publicar.
En la pantalla siguiente, seleccione Azure y, a continuación, elija Siguiente.
En función del tipo de proyecto, obtendrá una lista diferente de servicios de Azure entre los que elegir. Elija uno de los servicios de Azure admitidos que se adapten a sus necesidades.
En el paso final del asistente, seleccione CI/CD con flujos de trabajo de Acciones de GitHub (genera un archivo yml) y, a continuación, Finalizar.
Visual Studio genera un nuevo flujo de trabajo de Acciones de GitHub, y le pide que lo confirme y lo inserte en GitHub.com.
Si completa este paso mediante las herramientas de Git integradas, Visual Studio detectará la ejecución del flujo de trabajo.
Configuración de los secretos de GitHub
Para que el flujo de trabajo generado se implemente correctamente en Azure, se podría necesitar acceso a un perfil de publicación.
Una implementación correcta también podría necesitar acceder a una entidad de servicio.
En todos los casos, Visual Studio intenta establecer automáticamente el secreto de GitHub con el valor correcto. Si se produce un error, le informará y le dará la oportunidad de volver a intentarlo.
Si no puede volver a establecer el secreto, Visual Studio le ofrece la oportunidad de obtener acceso a él manualmente, por lo que puede completar el proceso a través de la página del repositorio en GitHub.com.
Implementación de varios proyectos en Azure Container Apps mediante Acciones de GitHub
Estos pasos son adecuados si tiene más de un proyecto que usa contenedores de Docker y quiere implementarlos como una aplicación multiproyecto. Puede implementar aplicaciones multiproyecto, como las que implementan microservicios en Azure Container Apps o Azure Kubernetes Service. En este artículo se da información sobre Azure Container Apps.
Haga clic con el botón derecho en el nodo Acciones de GitHub en el Explorador de soluciones y elija Nuevo flujo de trabajo. Aparece el Asistente para flujos de trabajo de Acciones de GitHub.
En la pantalla destino del flujo de trabajo de Acciones de GitHub, elija Azure.
Para el destino específico, elija Azure Container Apps. El asistente avanza a la pantalla Aplicación contenedora.
Elija una aplicación de contenedor de Azure existente o elija Crear nueva.
Al crear uno nuevo, verá esta pantalla. Al probar o aprender, normalmente es mejor crear un nuevo grupo de recursos para que sea más fácil eliminarlo más adelante. Un entorno de Container Apps es un límite seguro en torno a grupos de aplicaciones de contenedor que comparten la misma red virtual y escriben registros en el mismo destino de registro. Consulte Entorno de Azure Container Apps. Si no sabe lo que es o no ha creado uno antes, cree uno nuevo para esta instancia.
Una vez creada, se muestra la nueva instancia de Azure Container Apps.
Elija Siguiente para avanzar a la pantalla Registro. Elija una instancia de Azure Container Registry existente o cree una nueva.
Si decide crear uno nuevo, verá esta pantalla. Proporcione el grupo de recursos, la SKU y elija la misma región, si es posible, como antes. Para obtener información sobre las SKU para Azure Container Registry, consulte niveles de servicio de Azure Container Registry.
Una vez creado, el nuevo registro se muestra en la pantalla.
Se muestran los proyectos implementables de la solución; elija los proyectos que desea implementar juntos en la misma instancia de Azure Container Apps.
Elija Finalizar. Puede ver los comandos que se emiten para crear los recursos en Azure y configurar la autenticación. Si se produce algún error, anote la línea de comandos usada, ya que puede intentarlo de nuevo desde la CLI. No se preocupe demasiado si recibe un error de autorización en esta fase. También puede configurar la autenticación más adelante en Visual Studio.
Cuando termine, aparecerá la pantalla de resumen. En la pantalla de resumen se muestran las credenciales, que coinciden con las entradas que Visual Studio crea en el repositorio de GitHub en los secretos de Acciones de GitHub. Compruebe si hay signos de advertencia amarillos. Si se produjo un error en alguno de los pasos de autenticación durante el proceso de creación, tendrá la oportunidad de corregirlo aquí haciendo clic en el vínculo mediante el signo de advertencia y siguiendo algunos pasos.
Abra el archivo de flujo de trabajo para comprobar qué generó Visual Studio. Aunque Visual Studio hace lo mejor para generar un flujo de trabajo para su situación, cada aplicación y repositorio es único, por lo que a menudo tiene que editar manualmente el archivo YML de flujo de trabajo generado por Visual Studio antes de que se ejecute correctamente. Para abrirlo, expanda el nodo Acciones de GitHub en el Explorador de soluciones, haga clic con el botón derecho en el flujo de trabajo que acaba de crear y elija Editar.
A continuación se muestra un ejemplo de un archivo de flujo de trabajo creado por Visual Studio para una solución con dos proyectos implementables, WebAPI y WebFrontEnd.
on:
push:
branches:
- main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
runs-on: ubuntu-latest
steps:
- name: Checkout source code
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker registry
uses: docker/login-action@v2
with:
registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
file: WebApi\Dockerfile
- name: Azure login
uses: azure/login@v1
with:
creds: ${{ secrets.containerapp20230810121017_SPN }}
- name: Deploy to Azure container app
uses: azure/CLI@v1
with:
inlineScript: >-
az config set extension.use_dynamic_install=yes_without_prompt
az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
- name: Azure logout
run: az logout
WebFrontEnd_buildImageAndDeploy:
runs-on: ubuntu-latest
needs: WebApi_buildImageAndDeploy
steps:
- name: Checkout source code
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker registry
uses: docker/login-action@v2
with:
registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
file: WebFrontEnd\Dockerfile
- name: Azure login
uses: azure/login@v1
with:
creds: ${{ secrets.containerapp20230810121017_SPN }}
- name: Deploy to Azure container app
uses: azure/CLI@v1
with:
inlineScript: >-
az config set extension.use_dynamic_install=yes_without_prompt
az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
- name: Azure logout
run: az logout
La función principal del flujo de trabajo es iniciar sesión en los servicios de Azure con la autenticación correcta y ejecutar los comandos para compilar e implementar la aplicación.
Edición y prueba del flujo de trabajo
El procedimiento anterior genera un archivo YML de flujo de trabajo, pero normalmente necesita revisarlo y personalizarlo para poder usarlo para una implementación. Es posible que tenga que consultar las instrucciones de GitHub sobre cómo escribir acciones de flujo de trabajo; consulte Acerca de las acciones personalizadas. El archivo de flujo de trabajo contiene muchos elementos configurables, como la configuración de las variables de entorno y los nombres de los secretos. Puede ver referencias a las ubicaciones de los Dockerfiles, el nombre de la aplicación contenedora de Azure, la rama del repositorio que usará para desencadenar las ejecuciones de flujo de trabajo y las referencias a los secretos de GitHub. Se hace referencia a los secretos mediante la sintaxis ${{ secrets.SECRET_NAME }}. Consulte Secretos de Acciones de GitHub.
Si los proyectos no se encuentran en la raíz del repositorio, debe cambiar el flujo de trabajo para especificar la ruta de acceso para buscar los Dockerfiles. Agregue variables de entorno para las rutas de acceso relativas al Dockerfile en ambos proyectos.
DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile
Use los valores de estas variables de entorno para el parámetro de la file siguiente manera:
- name: Build and push Docker image to Azure container registry
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}
Si necesita realizar cambios en el Dockerfile, realice y guarde los cambios, confirme e inserte en el repositorio remoto. El flujo de trabajo que Genera Visual Studio contiene un desencadenador que hace que se ejecute si se actualiza en una rama especificada. Si va a insertar en la working rama, debe ser similar al código siguiente:
on:
push:
branches:
- working
Para probar los cambios, confírmelos e insértelos en la rama del repositorio especificado en el código de desencadenador. No tiene que crear una solicitud de cambios (PR). El flujo de trabajo se ejecuta siempre que el push desencadenador se establezca en la rama derecha.
En la pestaña Acciones del repositorio en GitHub.com, busque la ejecución del flujo de trabajo. Puede llegar directamente mediante un vínculo en la pestaña Resumen de acciones de GitHub en Visual Studio. En GitHub, puede abrir la ejecución del flujo de trabajo para ver los registros.
Solucionar problemas
Las siguientes sugerencias de solución de problemas pueden resultar útiles si el flujo de trabajo no se ejecuta correctamente.
Problema: La fase de compilación no se compila
Un problema que podría surgir en el Dockerfile es que la fase de compilación no funcionará igual que en Visual Studio. El Dockerfile predeterminado que Visual Studio genera para un proyecto muestra este problema. Tenga en cuenta las siguientes modificaciones en la fase de compilación si tiene un Dockerfile de este tipo. Este es un ejemplo en el que un proyecto se encuentra en docker/ComposeSample/WebApi un repositorio. Se proporciona la ruta de acceso completa porque el contexto dockerfile del contenedor de compilación de flujo de trabajo se establece en la raíz del repositorio, pero en Visual Studio, se establece en la carpeta situada encima de la carpeta del proyecto. El sufijo _build se anexa aquí para crear la carpeta de compilación y, en lugar de simplemente copiar el archivo del proyecto, se copia toda la carpeta. En comparación con el Dockerfile predeterminado generado por Visual Studio, la parte del archivo de la ruta de acceso en el primer argumento del comando COPY se quitó para que se copie toda la carpeta en lugar de solo el archivo del proyecto. Sin estos cambios, esta fase genera un error de MSBuild.
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build
Problema: Credenciales de autenticación
El flujo de trabajo requiere que se configuren los secretos de nombre de usuario y contraseña adecuados para el acceso a Azure. Visual Studio intenta hacerlo automáticamente al crear los recursos de Azure o en la pantalla Acciones de GitHub en el IDE de Microsoft Visual Studio. Puede comprobar los secretos en GitHub y asegurarse de que están allí o volver a generarlos y agregarlos de nuevo a GitHub si es necesario mediante la sección Configuración del repositorio. Compruebe el identificador de secretos con lo que se hace referencia en cada sección del flujo de trabajo. Si es necesario, puede ir al registro de contenedor en Azure Portal y obtener el nombre de usuario y la contraseña del registro de contenedor y usar esos valores para actualizar los secretos en GitHub.
Si ejecutó el az ad sp create-for-rbac comando para configurar una entidad de servicio y obtener un identificador de cliente, un secreto de cliente y un identificador de inquilino, agregue el identificador de cliente y el secreto de cliente como secretos en la sección Secretos de acciones de GitHub para el repositorio de GitHub. Puede proporcionar credenciales de inicio de sesión de Azure en forma de nombre de usuario (identificador de cliente para la aplicación) y contraseña (secreto de cliente) para la autenticación de Azure Container App. Para ello, reemplace el paso Azure login por el código siguiente. Use sus propios nombres de secreto de GitHub que creó para el identificador de cliente y el secreto de cliente, y use el identificador de inquilino de la salida del mismo comando.
- name: Azure login
uses: azure/CLI@v1
with:
inlineScript: |
az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
az account list
Si dockerfile funciona correctamente y la autenticación es correcta y sigue viendo problemas con el flujo de trabajo, tenga en cuenta los siguientes recursos:
¿Qué tipos de proyecto se admiten?
- ASP.NET Core
- ASP.NET 5 y versiones posteriores
- Azure Functions
¿Qué servicios de Azure se admiten?
- Azure Web Apps
- Azure Functions
- Azure API Management
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de