Compartir a través de

Azure Pipelines: actualización de Sprint 240

Características

Acceso a Azure Service Bus desde canalizaciones mediante la autenticación de Microsoft Entra ID

Ahora puede usar la autenticación de Id. de Entra de Microsoft para acceder a Azure Service Bus desde Azure Pipelines. Esto le permite aprovechar la federación de identidades de carga de trabajo para quitar la administración de secretos y RBAC de Azure para el control de acceso específico.

Las identidades que acceden a Azure Service Bus deben concederse uno de los roles integrados de Azure para Azure Service Bus en el service Bus al que se accede.

tarea de PublishToAzureServiceBus@2

Las nuevas tareas de PublishToAzureServiceBus@2 se pueden configurar mediante una conexión de servicio de Azure. Cree una conexión de servicio de Azure y rellene las serviceBusQueueName propiedades y serviceBusNamespace de la nueva tarea:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }
Tareas del servidor

Las tareas de servidor personalizado (sin agente) que usan ServiceBus la ejecución pueden especificar una conexión de servicio de Azure como EndpointId y omitir ConnectionString. Consulte Creación de tareas de servidor.

Canalizaciones y tareas rellenan variables para personalizar la autenticación de federación de identidad de carga de trabajo

El punto de conexión de la API REST para solicitar tokens OIDC ahora está disponible en la variable de System.OidcRequestUri canalización. Los desarrolladores de tareas pueden aprovechar esta variable para generar un idToken para la autenticación con Entra ID.

Si usa tareas de Marketplace o tareas personalizadas para implementar en Azure, tenga en cuenta que es posible que estas tareas aún no admitan la federación de identidades de carga de trabajo. Se recomienda a los desarrolladores de tareas habilitar la federación de identidades de carga de trabajo para mejorar las medidas de seguridad.

Captura de pantalla de la colaboración oidc.

Las tareas que toman una connectedService:AzureRM entrada en task.json se pueden actualizar para admitir la federación de identidades de carga de trabajo siguiendo estos pasos:

  • Use la API REST de Oidctoken para solicitar un idToken (flecha 1 en el diagrama anterior).
  • Intercambiar idToken para un token de acceso mediante el flujo de credenciales federadas de la API de OAuth, especificando idToken como client_assertion (flechas 2 y 4 en el diagrama anterior);
    O bien
  • En el caso de las tareas que actúan como contenedor alrededor de una herramienta que realiza la autenticación propiamente dicha, use el método de autenticación de las herramientas para especificar el token federado.

Las tareas de nodo pueden usar el paquete npm azure-pipelines-tasks-artifacts-common para obtener el idToken. Consulte el ejemplo de código para obtener detalles de implementación.

Solicitud de un idToken nuevo

La System.OidcRequestUri variable de canalización y AZURESUBSCRIPTION_SERVICE_CONNECTION_ID la variable de entorno expuestas en las tareas y AzureCLI@2 permiten a los AzurePowerShell@5 autores de canalizaciones autenticarse desde su propio script:

Az de PowerShell
- task: AzurePowerShell@5
  inputs:
    azureSubscription: 'my-azure-subscription'
    scriptType: inlineScript
    inline: |        
      # Request fresh idToken
      Invoke-RestMethod -Headers @{
                        Authorization  = "Bearer $(System.AccessToken)"
                        'Content-Type' = 'application/json'
                      } `
                      -Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
                      -Method Post `
                      | Select-Object -ExpandProperty oidcToken
                      | Set-Variable idToken

    # Fetch current context
    $azContext = Get-AzContext

    # Start new Az session
    Connect-AzAccount -ApplicationId $azContext.Account.Id `
                      -TenantId $azContext.Tenant.Id `
                      -SubscriptionId $azContext.Subscription.Id `
                      -FederatedToken $idToken
CLI de Azure
- task: AzureCLI@2
  inputs:
    addSpnToEnvironment: true
    azureSubscription: 'my-azure-subscription'
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      # Request fresh idToken
      OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
      ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')

      # Save subscription context
      ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)

      # New az-cli session
      az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
      az account set --subscription $ARM_SUBSCRIPTION_ID

Reintentos para tareas de servidor

Las tareas de servidor que llaman a sistemas externos, como AzureFunction o InvokeRESTAPI, pueden producir errores ocasionales debido a errores transitorios, como el agotamiento de recursos de proceso. Anteriormente, estos errores provocarían un error en todo el trabajo y, posiblemente, en la canalización.

Para mejorar la resistencia frente a errores transitorios, hemos introducido compatibilidad con la propiedad en las tareas del retryCountOnTaskFailure servidor. Supongamos que tiene el siguiente código YAML en la canalización:

- stage: deploy
  jobs:
  - job:
    pool: server
    steps:
    - task: AzureFunction@1
      retryCountOnTaskFailure: 2
      inputs:
        function: 'https://api.fabrikamfiber.com'
        key: $(functionKey)
        method: 'POST'
        waitForCompletion: 'false'

Si https://api.fabrikamfiber.com experimenta un error transitorio, Azure Pipelines reintentará la solicitud hasta tres veces (el intento inicial más dos reintentos especificados por retryCountOnTaskFailure). Cada reintento incluye un período de espera creciente. El número máximo de reintentos permitidos es 10.

retryCountOnTaskFailure no está disponible para la ManualValidation tarea y otras tareas que no implican llamadas al sistema externo.

Tareas que usan una versión final del ejecutor de Node para ejecutar advertencias

Las tareas de canalización que dependen de una versión de Node ya no se mantienen comenzarán a recibir advertencias:

La versión TaskName de la tarea <version> depende de una versión de Nodo (10) que sea de fin de ciclo de vida. Póngase en contacto con el propietario de la extensión para obtener una versión actualizada de la tarea. Los mantenedores de tareas deben revisar la guía de actualización del nodo: https://aka.ms/node-runner-guidance

Para suprimir estas advertencias, puede establecer un entorno o una variable de canalización en el nivel de canalización (trabajo) o tarea. Por ejemplo:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 usa Docker Compose v2 en modo de compatibilidad v1

Docker Compose v1 llegará a su fin de ciclo de vida y se quitará de los agentes hospedados de julio de 24 de 2024. Hemos actualizado la tarea de DockerCompose@0 para usar Docker Compose v2 en modo de compatibilidad v1 si Docker Compose v1 no está disponible en el agente.

Sin embargo, el modo de compatibilidad no aborda todos los problemas de compatibilidad. Algunos usuarios necesitarán más tiempo para actualizar sus proyectos de Docker Compose para la compatibilidad con Docker Compose v2. En esos casos, siga estas instrucciones para usar la tarea DockerComposeV0 con docker-compose v1.

NOTA: Esta guía se basa en la documentación independiente de Install Compose

Uso de docker-compose v1 en Windows

Agregue el paso de PowerShell a la canalización para descargar docker-Compose v1.29.2 y úselo con la tarea DockerComposeV0 en Windows:

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe

Uso de docker-compose v1 en Linux

Agregue el paso bash a la canalización para descargar Docker-Compose v1.29.2 y úselo con la tarea DockerComposeV0 en Linux:

variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

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.

Vaya a Azure DevOps.

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.

Hacer una sugerencia

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

  • Last updated on