Azure Pipelines: actualización de Sprint 246
Características
- Ubuntu 24.04 en agentes hospedados de Azure Pipelines
- Uso de la federación de identidades de carga de trabajo en pruebas de integración de Azure
- Nueva experiencia de creación de conexiones de servicio de Azure con compatibilidad mejorada con identidad administrada mejorada
- Ejecución de fases secundarias cuando se produce un error en la fase primaria
Ubuntu 24.04 en agentes hospedados de Azure Pipelines
La imagen de Ubuntu 24.04 ya está disponible para los agentes hospedados de Azure Pipelines. Para usar esta imagen, actualice el archivo YAML para incluir vmImage:'ubuntu-24.04':
- job: ubuntu2404
pool:
vmImage: 'ubuntu-24.04'
steps:
- bash: |
echo Hello from Ubuntu 24.04
lsb_release -d
Nota:
La ubuntu-latest etiqueta de imagen seguirá apuntando a ubuntu-22.04 hasta más tarde este año.
Consulte el archivo Léame de imagen de Ubuntu 24.04 para software instalado.
Uso de la federación de identidades de carga de trabajo en pruebas de integración de Azure
En junio, las bibliotecas de Identidad de Azure for.NET, C++, Go, Java, JavaScript y Python agregaron compatibilidad con la federación de identidades de carga de trabajo. Esto agregó la capacidad de código ejecutado desde el AzureCLI@2 y AzurePowerShell@5 tareas para autenticarse con Microsoft Entra (por ejemplo, para acceder a Azure) con la AzurePipelinesCredential clase .
Muchos clientes usan las bibliotecas de Identidad de Azure en las pruebas de integración invocadas desde otras tareas. Ahora se ha agregado compatibilidad con AzurePipelinesCredential las tareas de DotNetCoreCLI@2, Maven@4 y VSTest@3 .
Puede establecer la connectedService propiedad en una conexión de servicio de Azure configurada con la federación de identidades de carga de trabajo. Es AzurePipelinesCredential necesario SYSTEM_ACCESSTOKEN establecer .
- task: DotNetCoreCLI@2
inputs:
command: 'run'
connectedService: <Azure service connection configured with workload identity federation>
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
Para obtener más información sobre AzurePipelinesCredential, consulte esta entrada de blog.
Nueva experiencia de creación de conexiones de servicio de Azure con compatibilidad mejorada con identidad administrada mejorada
La nueva experiencia de creación de conexiones de servicio de Azure proporciona mayor flexibilidad y valores predeterminados seguros. También alinea la terminología con Microsoft Entra ID, de modo que los usuarios que crean objetos de Microsoft Entra ID manualmente tengan una mejor comprensión al navegar por diferentes portales.
Al crear una nueva conexión de servicio de Azure Resource Manager, las distintas opciones para configurar la identidad ahora están disponibles en un único cuadro de diálogo unificado que reemplaza los distintos elementos de nivel superior usados anteriormente:
El tipo de identidad enumera todos los esquemas de autenticación que admite la conexión de servicio de Azure:
En el caso de los registros de aplicaciones, puede seleccionar de forma independiente Credencial para ser federación de identidades de carga de trabajo o un secreto.
Compatibilidad con identidad administrada de conexión de servicio de Azure
Ahora puede seleccionar una identidad administrada preexistente y usarla para configurar una conexión de servicio que use la federación de identidades de carga de trabajo. En primer lugar, cree una identidad administrada asignada por el usuario.
A continuación, cree una conexión de servicio de Azure y seleccione el tipo de identidad administrada. Esto configura las credenciales de identidad federada en la identidad administrada.
La opción para usar una identidad administrada asignada a un agente (grupo) se ha cambiado el nombre de identidad administrada (asignada por el agente). Para evitar el uso compartido de identidades administradas con privilegios elevados, se recomienda usar una identidad administrada con federación de identidades de carga de trabajo en lugar de identidades administradas asignadas a grupos de agentes.
La identidad administrada también es la opción recomendada para los usuarios que no pueden crear un registro de aplicaciones si está deshabilitado en el identificador de Entra de Microsoft.
Para usar una identidad administrada con federación de identidad de carga de trabajo, seleccione primero la suscripción y el grupo de recursos que contiene la identidad administrada. Esto puede ser diferente de la suscripción a la que accede la conexión de servicio en los trabajos de canalización. Elija la identidad administrada configurada para la federación de identidades de carga de trabajo. El usuario necesita el rol Colaborador de identidad administrada o permisos equivalentes en la identidad administrada para crear credenciales de identidad federada en ella.
Continúe seleccionando la suscripción que se usará como ámbito de implementación para la conexión de servicio.
Campo Referencia de administración de servicios
Algunas organizaciones requieren que la referencia de administración de servicios de un registro de aplicaciones se rellene con información de contexto relevante de una base de datos ITSM. Si es necesario para ello, los usuarios pueden especificar esta referencia en el momento de creación de la conexión de servicio.
Más información
La nueva experiencia de creación de conexiones de servicio de Azure se está implementando durante el mes siguiente. Para más información, vea:
- Documentación de conexión de servicio de Azure
- Federación de identidades de carga de trabajo
- Solución de problemas
Ejecución de fases secundarias cuando se produce un error en la fase primaria
Hemos facilitado la continuación de las implementaciones mediante Azure Pipelines. Esto resulta útil, por ejemplo, cuando se usan canalizaciones para implementar nuevas versiones de la aplicación en varias regiones de Azure.
Supongamos que necesita implementar en cinco regiones consecutivas de Azure. Supongamos que la canalización tiene una fase para cada región y cada fase tiene un trabajo que ejecuta una AzureResourceManagerTemplateDeployment tarea y, a continuación, registra algunos datos de telemetría. Esto último es bueno tener, pero no crítico. Imagine que hay un problema al registrar la telemetría. Ahora, se produce un error en la fase y la implementación se detiene.
A partir de este sprint, cuando se produce un error en una fase, puede reanudar la ejecución de sus fases secundarias.
Pasos siguientes
Nota:
Estas características se implementarán en las próximas dos a tres semanas.
Vaya a Azure DevOps y eche un vistazo.
Cómo enviar sus comentarios
Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.
También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.