Compartir a través de

Agentes de Azure Pipelines.

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Para compilar el código o implementar el software mediante Azure Pipelines, necesita al menos un agente. A medida que crece el código base y el equipo, necesita más agentes.

Cuando la canalización se ejecuta, el sistema inicia uno o varios trabajos. Un agente es una infraestructura informática con software de agente instalado que ejecuta un trabajo de uno en uno.

Azure Pipelines proporciona varios tipos diferentes de agentes.

Tipo de agente Descripción Disponibilidad
Agentes hospedado por Microsoft Agentes hospedados y administrados por Microsoft Azure DevOps Services
Agentes autohospedados Agentes que configure y administre, hospedados en las máquinas virtuales Azure DevOps Services, Azure DevOps Server
Agentes de grupos de DevOps administrados Los grupos de DevOps administrados son un servicio totalmente administrado en el que las máquinas virtuales o los contenedores que alimentan a los agentes residen en una suscripción de Microsoft Azure y no en su propia suscripción de Azure Azure DevOps Services
Agentes de conjunto de escalado de máquinas virtuales de Azure Una forma de agentes autohospedados, mediante Azure Virtual Machine Scale Sets, que se puede escalar automáticamente para satisfacer las demandas.

Si está pensando en usar grupos de agentes autoescalables autohospedados, recomendamos considerar grupos de DevOps administrados. Para más información, consulte Comparación de grupos de DevOps administrados con agentes de conjuntos de escalado de máquinas virtuales de Azure y información general de grupos de DevOps administrados.		 Azure DevOps Services

Los trabajos se pueden ejecutar directamente en la máquina host del agente o en un contenedor.

Agentes hospedado por Microsoft

Si las canalizaciones están en Azure Pipelines, dispone de una práctica opción para ejecutar los trabajos mediante un agente hospedado por Microsoft. Si se usan agentes hospedados por Microsoft, las actualizaciones y el mantenimiento se realizarán automáticamente. Siempre obtendrá la versión más reciente de la imagen de máquina virtual que especifique en la canalización. Cada vez que ejecute una canalización, obtendrá una máquina virtual nueva para cada trabajo de la canalización. La máquina virtual se descarta después de un trabajo (lo que significa que cualquier cambio que realice un trabajo en el sistema de archivos de la máquina virtual, como la extracción de código del repositorio, no estará disponible para el siguiente trabajo). Los agentes hospedados por Microsoft pueden ejecutar trabajos directamente en la máquina virtual o en un contenedor.

Azure Pipelines proporciona un grupo de agentes predefinido llamado Azure Pipelines con agentes hospedados por Microsoft.

Para muchos equipos, esta es la manera más sencilla de ejecutar sus trabajos. Puede probarlo en primer lugar y ver si funciona para la compilación o la implementación. Si no es así, puede usar agentes de conjunto de escalado o un agente autohospedado.

Sugerencia

Puede probar un agente hospedado por Microsoft sin cargo alguno.

Obtenga más información sobre los agentes hospedados por Microsoft.

Agentes autohospedados

Un agente autohospedado es un tipo de agente que se configura y administra por su cuenta para ejecutar trabajos. Puede usar agentes autohospedados en Azure Pipelines o Azure DevOps Server. Los agentes autohospedados proporcionan mayor control para instalar el software dependiente necesario para las compilaciones e implementaciones. Además, las memorias caché de nivel de máquina y la configuración se conservan de una ejecución a otra, lo que puede aumentar la velocidad.

Nota:

Aunque se pueden instalar varios agentes por máquina, se recomienda instalar solo un agente por máquina. La instalación de dos o más agentes puede afectar negativamente al rendimiento y al resultado de las canalizaciones.

Sugerencia

Antes de instalar un agente autohospedado, podría considerar comprobar si un grupo de agentes hospedados por Microsoft le funciona. En muchos casos, un grupo de agentes hospedados por Microsoft es la manera más sencilla de empezar. Pruébelo.

Puede instalar el agente en máquinas Linux, macOS o Windows. También puede instalar un agente en un contenedor de Docker. Para más información acerca de la instalación de un agente autohospedado, consulte:

Nota:

En macOS, debe borrar el atributo especial en el archivo de descarga para evitar que la protección de Gatekeeper se muestre para cada ensamblado del archivo tar cuando se ejecute ./config.sh. El siguiente comando borra el atributo extendido en el archivo:

xattr -c vsts-agent-osx-x64-V.v.v.tar.gz  ## replace V.v.v with the version in the filename downloaded.

# then unpack the gzip tar file normally:

tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz

Después de instalar el agente en una máquina, puede instalar cualquier otro software en esa máquina, según la necesidad que tengan los trabajos.

Nota:

Los agentes son ampliamente compatibles con versiones anteriores. Cualquier versión del agente debe ser compatible con cualquier versión de Azure DevOps siempre que Azure DevOps no exija una versión superior del agente.

Solo se admite la versión más reciente del agente, ya que es la única versión garantizada para tener todas las revisiones actualizadas y correcciones de errores.

Versiones del ejecutor de Node

El agente se incluye con varias versiones de las bibliotecas NodeJS para admitir tareas de destino que usan diferentes controladores de Node.

Sin embargo, todas las tareas oficiales de Azure DevOps usan Node 20 como controlador universal. En cualquier caso, los clientes pueden seguir usando tareas personalizadas que usan las bibliotecas de Node 6, Node 10 o Node 16 que hayan alcanzado el final del ciclo de vida Para admitir la compatibilidad retroactiva con Node que ha alcanzado su fin de vida útil, proporcionamos los siguientes métodos de autoservicio para instalar manualmente el ejecutor de Node designado.

  • Instale manualmente el ejecutor de Node 6. Para obtener más información, consulte Compatibilidad con Node 6.

  • Use la tarea NodeTaskRunnerInstaller@0 en las canalizaciones que requieren la biblioteca de Node 6 obsoleta.

  • Instale un paquete de agente que incluya Node 6.

    Azure Pipelines proporciona dos versiones de paquetes de agente.

    • Los paquetes vsts-agent-* admiten Node 6.
    • Los paquetes pipelines-agent-* no admiten Node 6. Esta versión del paquete se convertirá en el paquete de agente predeterminado en el futuro.

    Si sabe que no usa ninguna tarea dependiente de Node 6 y no quiere tener Node 6 instalado en el equipo del agente, puede instalar el agente desde la sección Descargas alternativas del agente de https://github.com/microsoft/azure-pipelines-agent/releases.

Agentes de conjunto de escalado de máquinas virtuales de Azure

Los agentes de Azure Virtual Machine Scale Set son un tipo de agentes autohospedados que se pueden escalar automáticamente para satisfacer sus necesidades. Esta elasticidad reduce la necesidad de ejecutar agentes dedicados de forma continua. A diferencia de los agentes hospedados por Microsoft, el tamaño y la imagen de las máquinas en las que se ejecutan los agentes tienen flexibilidad.

Especifique un Virtual Machine Scale Set, una serie de agentes que se mantendrán en espera, un número máximo de máquinas virtuales en el conjunto de escalado y Azure Pipelines administra el escalado de los agentes en su nombre.

Para obtener más información, consulte Agentes del conjunto de escalado de máquinas virtuales de Azure.

Sugerencia

Los grupos de DevOps administrados son un nuevo servicio que es una evolución de los grupos de agentes del conjunto de escalado de máquinas virtuales de Azure DevOps, lo que simplifica aún más la creación de grupos personalizados, ya que mejora la escalabilidad y la confiabilidad de los grupos personalizados. Los grupos de DevOps administrados son un servicio totalmente administrado en el que las máquinas virtuales o los contenedores que alimentan a los agentes residen en una suscripción de Microsoft Azure y no en su propia suscripción de Azure, como cuando se usan grupos de agentes de Azure DevOps Virtual Machine Scale Set.

Si está considerando usar grupos de agentes autohospedados y autoescalables, le recomendamos que busque Managed DevOps Pools. Para más información, consulte Comparación de grupos de DevOps administrados con agentes de conjuntos de escalado de máquinas virtuales de Azure y información general de grupos de DevOps administrados.

Agentes de grupos de DevOps administrados

Los grupos de DevOps administrados permiten a los equipos de desarrollo poner en marcha de forma rápida y sencilla grupos de agentes de Azure DevOps adaptados a las necesidades específicas de un equipo.

Grupos de DevOps administrados:

  • implementa los procedimientos recomendados de seguridad
  • proporciona botones para equilibrar el costo y el rendimiento
  • proporciona rutas de acceso para los escenarios más comunes.
  • reduce significativamente el tiempo invertido en crear y mantener grupos personalizados.

Los grupos de DevOps administrados son una evolución de los grupos de agentes del conjunto de escalado de máquinas virtuales de Azure DevOps. Simplifican aún más la creación de grupos personalizados mediante la mejora de la escalabilidad y confiabilidad de los grupos personalizados. Los grupos de DevOps administrados son un servicio totalmente administrado en el que las máquinas virtuales o los contenedores que alimentan a los agentes residen en una suscripción de Microsoft Azure y no en su propia suscripción de Azure, como cuando se usan grupos de agentes de Azure DevOps Virtual Machine Scale Set. Para obtener más información, consulte la documentación sobre Managed DevOps Pools.

Trabajos paralelos

Los trabajos paralelos representan el número de trabajos que puede ejecutar al mismo tiempo en su organización. Si su organización tiene un único trabajo paralelo, puede ejecutar un único trabajo a la vez en su organización, con cualquier otro trabajo simultáneo que se pone en cola hasta que se complete el primer trabajo. Para ejecutar dos trabajos al mismo tiempo, necesita dos trabajos paralelos. En Azure Pipelines, puede ejecutar trabajos paralelos en la infraestructura hospedada por Microsoft o en su propia infraestructura (autohospedada).

Microsoft proporciona un nivel de servicio gratuito de forma predeterminada en cada organización que incluye al menos un trabajo paralelo. Según el número de canalizaciones simultáneas que necesite ejecutar, es posible que necesite más trabajos paralelos para usar varios agentes hospedados por Microsoft o autohospedados al mismo tiempo. Para más información sobre trabajos paralelos y diferentes niveles de servicio gratuitos, consulte Trabajos paralelos en Azure Pipelines.

Es posible que necesite más trabajos paralelos para usar varios agentes al mismo tiempo:

Importante

A partir de Azure DevOps Server 2019, no es necesario pagar por trabajos simultáneos autohospedados en versiones. Estás limitado únicamente por el número de agentes que tienes.

Funcionalidades

Cada agente autohospedado tiene un conjunto de funcionalidades que indican lo que puede hacer. Las funcionalidades son pares nombre-valor que el software del agente detecta automáticamente, en cuyo caso se denominan funcionalidades del sistema o las que se definen, en cuyo caso se denominan funcionalidades de usuario.

El software del agente determina automáticamente diversas funcionalidades del sistema, como el nombre de la máquina, el tipo de sistema operativo y las versiones de cierto software instalado en la máquina. Además, las variables de entorno definidas en la máquina aparecen automáticamente en la lista de funcionalidades del sistema.

Nota:

Almacenar variables de entorno como funcionalidades significa que cuando se ejecuta un agente, los valores de funcionalidad almacenados se usan para establecer las variables de entorno. Además, los cambios realizados en las variables de entorno que se efectúan mientras se ejecuta el agente no se recogen ni se utilizan en ninguna tarea. Si tiene variables de entorno confidenciales que cambian y no quiere que se almacenen como funcionalidades, puede hacer que se omitan estableciendo la variable de entorno VSO_AGENT_IGNORE, con una lista delimitada por comas de variables que se omitirán. Por ejemplo, PATH es una variable crítica que puede omitir si va a instalar software.

Al crear una canalización, se especifican determinadas demandas del agente. El sistema envía el trabajo solo a los agentes que tienen funcionalidades que coinciden con las demandas especificadas en la canalización. Como resultado, las funcionalidades del agente permiten dirigir trabajos a agentes específicos.

Nota:

Las demandas y funcionalidades están diseñadas para su uso con agentes autohospedados para que los trabajos puedan coincidir con un agente que cumpla los requisitos del trabajo. Al usar agentes hospedados por Microsoft, seleccione una imagen para el agente que coincida con los requisitos del trabajo. Aunque es posible agregar funcionalidades a un agente hospedado por Microsoft, no es necesario usar funcionalidades con agentes hospedados por Microsoft.

Configuración de demandas

Para agregar una demanda a la canalización de compilación de YAML, agregue la línea demands: a la sección pool.

pool:
  name: Default
  demands: SpecialSoftware # exists check for SpecialSoftware

Puede comprobar la existencia de una funcionalidad o realizar una comparación con el valor de una funcionalidad. Para obtener más información, consulte Esquema YAML: demandas.

Configuración de las funcionalidades del agente

Puede ver los detalles de un agente, incluida su versión y sus funcionalidades del sistema, y administrar sus funcionalidades de usuario; para ello, vaya a Grupos de agentes y seleccione la pestaña Funcionalidades del agente deseado.

  1. En el explorador web, vaya a Grupos de agentes:

    1. Inicie sesión en su organización (https://dev.azure.com/{yourorganization}).

    2. Elija Azure DevOps, Configuración de la organización.

      Seleccione Configuración de organización.

    3. Seleccione Grupos de agentes.

      Seleccione la pestaña Grupos de agentes.

    1. Inicie sesión en la colección de proyectos (http://your-server/DefaultCollection).

    2. Seleccione Azure DevOps, Configuración de colección.

      Seleccione Configuración de colección.

    3. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes.

    1. Seleccione Azure DevOps, Configuración de colección.

      Configuración de colección, 2019.

    2. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes, 2019.

  2. Vaya a la pestaña Funcionalidades:

    1. En la pestaña Grupos de agentes, seleccione el grupo de agentes deseado.

      En Grupos de agentes, seleccione el grupo de agentes deseado.

    2. Seleccione Agentes y elija el agente deseado.

      Seleccione Agentes y elija el agente.

    3. Selecciona la pestaña Funcionalidades.

      Seleccione la pestaña Capacidades.

      Nota:

      Los agentes hospedados por Microsoft no muestran las funcionalidades del sistema. Para una lista de software instalado en agentes hospedados por Microsoft, consulte Uso de un agente hospedado por Microsoft.

    1. En la pestaña Grupos de agentes, seleccione el grupo deseado.

      Seleccione el grupo deseado.

    2. Seleccione Agentes y elija el agente deseado.

      Seleccione Agentes y elija el agente deseado.

    3. Selecciona la pestaña Funcionalidades.

      Pestaña Funcionalidades del agente.

    1. En la pestaña Grupos de agentes, seleccione el grupo deseado.

      Seleccione la pestaña deseada, 2019.

    2. Seleccione Agentes y elija el agente deseado.

      Elija el agente deseado, 2019.

    3. Selecciona la pestaña Funcionalidades.

      Seleccione la pestaña Capacidades, 2019.

  3. Para registrar una nueva funcionalidad con el agente, elija Agregar una nueva funcionalidad.

Sugerencia

Después de instalar nuevo software en un agente autohospedado, debe reiniciar el agente para que aparezca la nueva funcionalidad. Para más información, consulte Reiniciar agente de Windows, Reiniciar agente de Linux y Reiniciar agente de Mac.

Comunicación

Comunicación con Azure Pipelines

Comunicación con Azure DevOps Server

El agente se comunica con Azure Pipelines o Azure DevOps Server para determinar qué trabajo debe ejecutar y para informar de los registros y el estado del trabajo. El agente siempre inicia esta comunicación. Todos los mensajes del agente a Azure Pipelines o Azure DevOps Server suceden en HTTP o HTTPS, dependiendo de cómo configure el agente. Este modelo de extracción permite configurar el agente en topologías diferentes tal y como se muestra en los ejemplos siguientes.

Topologías del agente en instalaciones locales.

Enlaces de servicio en Azure DevOps Services

Este es un patrón de comunicación común entre el agente y Azure Pipelines o Azure DevOps Server.

  1. El usuario registra un agente con Azure Pipelines o Azure DevOps Server agregándolo a un grupo de agentes. Debe ser administrador del grupo de agentes para registrar un agente en ese grupo de agentes. La identidad del administrador del grupo de agentes solo es necesaria en el momento del registro y no se conserva en el agente. No se usa en ninguna comunicación adicional entre el agente y Azure Pipelines o Azure DevOps Server. Una vez completado el registro, el agente descarga un token de OAuth del cliente de escucha y lo usa para escuchar la cola de trabajos.

  2. El agente escucha si se ha publicado una nueva solicitud de trabajo en la cola de trabajos de Azure Pipelines o Azure DevOps Server mediante un sondeo largo HTTP. Cuando hay un trabajo disponible, el agente descarga el trabajo y un token de OAuth específico del trabajo. Azure Pipelines o Azure DevOps Server genera un token de corta duración para la identidad con ámbito especificada en la canalización. El agente usa el token para acceder o modificar recursos en Azure Pipelines o Azure DevOps Server dentro de ese trabajo. Por ejemplo, para acceder al código fuente o cargar los resultados de las pruebas.

  3. Después de completar el trabajo, el agente descarta el token de OAuth específico del trabajo y vuelve a comprobar si hay una nueva solicitud de trabajo mediante el token de OAuth del agente de escucha.

La carga de los mensajes intercambiados entre el agente y Azure Pipelines o Azure DevOps Server se protege mediante cifrado asimétrico. Cada agente tiene un par de claves pública y privada y la clave pública se intercambia con el servidor durante el registro. El servidor usa la clave pública para cifrar la carga del trabajo antes de enviarla al agente. El agente descifra el contenido del trabajo mediante su clave privada. Este método protege los secretos almacenados en canalizaciones o grupos de variables cuando se intercambian con el agente.

Nota:

El agente proporciona compatibilidad con la salida de codificación de cliente UTF-8. Sin embargo, si el sistema tiene una codificación diferente de UTF-8, es posible que encuentre algunos problemas con la salida de los registros. Por ejemplo, los registros pueden contener caracteres que la codificación del sistema no reconoce, por lo que pueden aparecer como símbolos ensangrados o que faltan.

Comunicación para implementar en servidores de destino

Cuando se usa el agente para implementar artefactos en un conjunto de servidores, debe tener conectividad de "línea de visión" con esos servidores. De forma predeterminada, los grupos de agentes hospedados por Microsoft tienen conectividad con los sitios web y servidores de Azure que se ejecutan en Azure.

Nota:

Si los recursos de Azure se ejecutan en una instancia de Azure Virtual Network, puede obtener los intervalos IP del agente en los que se implementan los agentes hospedados por Microsoft para que pueda configurar las reglas de firewall para que la red virtual de Azure permita el acceso por parte del agente.

Si los entornos locales no tienen conectividad con un grupo de agentes hospedados por Microsoft (que es lo habitual debido a firewalls intermedios), deberá configurar manualmente agentes autohospedados en equipos locales. Los agentes deben tener conectividad a los entornos locales de destino y acceso a Internet para conectarse a Azure Pipelines o Team Foundation Server, como se muestra en el siguiente esquema.

Conectividad del agente para entornos locales

Authentication

Para registrar un agente, debe ser miembro del rol de administrador en el grupo de agentes. La identidad del administrador del grupo de agentes solo es necesaria en el momento del registro y no se conserva en el agente. No se usa en ninguna comunicación posterior entre el agente y Azure Pipelines o Azure DevOps Server. Además, debe ser un administrador local en el servidor para poder configurar el agente.

Cuando registre un agente, elija entre los siguientes tipos de autenticación, y la configuración del agente le pedirá la información adicional específica necesaria para cada tipo de autenticación. Para obtener más información, consulte Opciones de autenticación del agente autohospedado.

  • Token de acceso personal
  • Alternativa Conéctese a Azure DevOps Server o a TFS mediante la autenticación básica. Al seleccionar Alternativa se le pedirán sus credenciales.

Además, los agentes de Windows tienen las dos opciones de autenticación siguientes en Azure DevOps Server.

  • Negotiate Conéctese a Azure DevOps Server como usuario que no sea el usuario que ha iniciado sesión a través de un esquema de autenticación de Windows, como New Technology LAN Manager (NTLM) o Kerberos. Después de seleccionar Negotiate, se le pedirán credenciales.
  • Integrado (valor predeterminado) Conecte un agente de Windows a Azure DevOps Server con las credenciales del usuario que ha iniciado sesión a través de un esquema de autenticación de Windows, como NTLM o Kerberos. No se le pedirán credenciales después de elegir este método.

Importante

El servidor debe configurarse de tal forma que admita el método de autenticación para usar la autenticación Alternativa, Negociada o Integrada.

El método de autenticación para el registro del agente se usa solo durante dicho registro. Para obtener más información sobre la forma en que los agentes se comunican con Azure Pipelines después del registro, consulte Comunicación con Azure Pipelines o Azure DevOps Server.

Interactivo frente al servicio

Puede ejecutar el agente autohospedado como un servicio o un proceso interactivo.

Después de configurar el agente, le recomendamos probarlo primero en modo interactivo para asegurarse de que funciona. A continuación, para el uso de producción, se recomienda que ejecute el agente en uno de los siguientes modos para que siga ejecutándose de forma confiable. Estos modos también garantizan que el agente se inicie automáticamente si se reinicia la máquina.

  1. Como servicio. Puede usar el administrador de servicios del sistema operativo para administrar el ciclo de vida del agente. Además, la experiencia de actualización automática del agente es mejor cuando se ejecuta como un servicio.

  2. Como un proceso interactivo con el inicio de sesión automático habilitado. En algunos casos, es posible que tenga que ejecutar el agente de forma interactiva para su uso en producción, como para ejecutar pruebas de IU. Cuando el agente está configurado para ejecutarse en este modo, también se deshabilita el protector de pantalla. Algunas directivas de dominio pueden impedir que habilite el registro automático o deshabilite el protector de pantalla. En tales casos, es posible que tenga que buscar una exención de la directiva de dominio o ejecutar el agente en un equipo de grupo de trabajo en el que no se aplican las directivas de dominio.

    Nota:

    Hay riesgos de seguridad al habilitar el inicio de sesión automático o deshabilitar el protector de pantalla porque permite que otros usuarios pasen al equipo y usen la cuenta que inicia sesión automáticamente. Si configura el agente para que se ejecute de esta manera, debe asegurarse de que el equipo está protegido físicamente; por ejemplo, ubicado en una instalación segura. Si usa Escritorio remoto para acceder al equipo en el que se ejecuta un agente con el registro automático, cerrar simplemente el Escritorio remoto hace que el equipo esté bloqueado y las pruebas de UI que se ejecuten en este agente podrían producir un error. Para evitar este problema, use el comando tscon para desconectar de Escritorio remoto. Por ejemplo:

    %windir%\System32\tscon.exe 1 /dest:console

Nombre de la cuenta del agente.

Tanto si ejecuta un agente como un servicio como de forma interactiva, puede elegir qué cuenta del equipo usa para ejecutar el agente. La elección de la cuenta de agente depende únicamente de las necesidades de las tareas que se ejecutan en los trabajos de compilación e implementación.

Por ejemplo, para ejecutar tareas que usan autenticación de Windows para acceder a un servicio externo, debe ejecutar el agente con una cuenta con acceso a ese servicio. Sin embargo, si está ejecutando pruebas de IU como Selenium o pruebas de IU codificadas que requieren un explorador, el explorador se inicia en el contexto de la cuenta del agente.

En Windows, debe considerar el uso de una cuenta de servicio como Servicio de red o Servicio local. Estos permisos de cuentas son restringidos y sus contraseñas no expiran, lo que significa que el agente requiere menos administración con el tiempo.

Estas credenciales son diferentes de las credenciales que se usan al registrar el agente con Azure Pipelines o Azure DevOps Server.

Versiones y actualizaciones del agente

Actualizamos el software del agente cada pocas semanas en Azure Pipelines. Indicamos la versión del agente con el formato {major}.{minor}. Por ejemplo, si la versión del agente es 2.1, la versión principal es 2 y la versión secundaria es 1.

Los agentes hospedados por Microsoft siempre se mantienen actualizados. Si la versión más reciente del agente solo es diferente en la versión secundaria, Azure Pipelines puede actualizar automáticamente los agentes autohospedados. Puede configurar esta opción en Grupos de agentes, seleccionar el agente, Configuración: el valor predeterminado está habilitado. Se solicita una actualización cuando una característica de plataforma o una de las tareas usadas en la canalización requiere una versión más reciente del agente.

Si ejecuta un agente autohospedado de forma interactiva o si hay una versión principal más reciente del agente disponible, es posible que tenga que actualizar manualmente los agentes. Puede actualizar los agentes fácilmente desde la pestaña Grupos de agentes de la organización. Las canalizaciones no se pueden ejecutar sin un agente compatible

Para actualizar agentes autohospedados

  1. Vaya a Configuración del proyecto, Grupos de agentes.

    Configuración del proyecto, grupos de agentes

  2. Seleccione el grupo de agentes y elija Actualizar todos los agentes.

    Actualizar todos los agentes

    También puede actualizar los agentes individualmente si elige Actualizar agente en el menú ....

    Actualizar agente

  3. Seleccione Actualizar para confirmar la actualización.

    Actualizar la confirmación de todos los agentes

  4. Se pone en cola una solicitud de actualización para cada agente del grupo y se ejecuta cuando se completan los trabajos en ejecución. La actualización normalmente solo tarda unos instantes, el tiempo suficiente como para descargar la versión más reciente del software del agente (aproximadamente 200 MB), descomprimirlo y reiniciar el agente con la nueva versión. Puede supervisar el estado de los agentes en la pestaña Agentes.

Actualizamos el software del agente con cada actualización en Azure DevOps Server. Indicamos la versión del agente con el formato {major}.{minor}. Por ejemplo, si la versión del agente es 2.1, la versión principal es 2 y la versión secundaria es 1.

Cuando el servidor Azure DevOps Server tiene una versión más reciente del agente y ese agente más reciente solo es diferente en la versión secundaria, normalmente se puede actualizar automáticamente. Se solicita una actualización cuando una característica de plataforma o una de las tareas usadas en la canalización requiere una versión más reciente del agente. A partir de Azure DevOps Server 2019, no es necesario esperar a una nueva versión del servidor. Puede cargar una nueva versión del agente en el nivel de aplicación y esa versión se ofrece como una actualización.

Si ejecuta el agente de forma interactiva o hay disponible una versión principal más reciente del agente, debe actualizarlo manualmente. Puede actualizar el agente desde la pestaña Grupos de agentes en la colección de proyectos. Las canalizaciones no se pueden ejecutar sin un agente compatible.

Para ver la versión de un agente, vaya a Grupos de agentes y seleccione la pestaña Funcionalidades del agente deseado, tal como se describe en Configuración de las funcionalidades del agente.

Para desencadenar la actualización del agente mediante programación, puede usar la API de actualización del agente como se describe en la sección ¿Cómo puedo desencadenar actualizaciones del agente mediante programación para un grupo de agentes específico?

Nota:

Para los servidores sin acceso a Internet, copie manualmente el archivo ZIP del agente en la carpeta siguiente para usarlo como archivo local. Cree la carpeta Agentes si no está presente.

  • Windows: %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux: usr/share/Microsoft/Azure DevOps/Agents
  • macOS: usr/share/Microsoft/Azure DevOps/Agents

Cree la carpeta Agentes si no está presente.

Estructura del directorio del agente

Cuando se ejecutan trabajos de canalización en agentes, se crea una estructura de directorios para almacenar el código fuente, los archivos binarios y los artefactos.

El directorio principal del agente es el directorio donde está instalado el agente. El directorio se encuentra normalmente:

  • agentes hospedados por Microsoft:C:\agents\<agent version> en Windows, /Users/runner/runners/<agent version> en macOS y /home/vsts/agents/<agent version> en Linux.
  • agentes autohospedados:C:\agent en Windows, Users/<username>/agent (~/agent) en macOS y /home/vsts/agent en Linux.

El directorio de trabajo del agente contiene el espacio de trabajo donde se almacena el origen y la salida de los trabajos. El directorio de trabajo se encuentra normalmente:

  • agente hospedado por Microsoft:C:\a en Windows, /Users/runner/work en macOS y/home/vsts/work en Linux.
  • agente autohospedado:C:\agent\_work en Windows, ~/agent/work en macOS y /home/agent/_work en Linux.

La estructura del directorio de trabajo es la siguiente:


    - /work directory
        - /1 build directory/pipeline workspace
            - /s source/working directory
            - /b binaries directory
            - /a artifacts staging directory
            - /TestResults Test results directory
Directorio Descripción Ejemplos Variables predefinidas
Directorio principal del agente Dónde está instalado el agente agente hospedado por Microsoft:
   Windows: C:\agents\3.248.0
   Linux: /home/vsts/agents/3.248.0
   macOS: /Users/runner/runners/3.248.0
Agente autohospedado:
   Windows: C:\agent
   Linux: home/agent
   macOS: ~/agent		 Agent.HomeDirectory
Directorio de trabajo Donde el agente almacena el código fuente, los archivos binarios y los artefactos agente hospedado por Microsoft:
   Windows: C:\a
   Linux: /home/vsts/work
   macOS: /Users/runner/work
Agente autohospedado:
   Windows: C:\agent\_work
   Linux: /home/agent/_work
   macOS: ~/agent/work		 Agent.WorkFolder
Agent.RootDirectory
System.WorkFolder
Crear directorio o área de trabajo Dónde se ejecuta el trabajo de canalización agente hospedado por Microsoft:
   Windows: C:\a\1
   Linux: /home/vsts/work/1
   macOS: /Users/runner/work/1
Agente autohospedado:
   Windows: C:\agent\_work\1
   Linux: /home/agent/_work/1
   macOS: ~/agent/work/1		 Agent.BuildDirectory
Pipeline.Workspace
s: directorio de origen y trabajo Contiene el código fuente que se extrajo del repositorio. Si tiene varios pasos checkout en el trabajo, el código fuente se extrae en directorios con el nombre de los repositorios como una subcarpeta de s. agente hospedado por Microsoft:
   Windows: C:\a\1\s
   Linux: /home/vsts/work/1/s
   macOS: /Users/runner/work/1/s
Agente autohospedado:
   Windows: C:\agent\_work\1\s
   Linux: /home/agent/_work/1/s
   macOS: ~/agent/work/1/s		 Build.SourcesDirectory
Build.RepositoryLocalPath
System.DefaultWorkingDirectory
b: directorio binarios Contiene las salidas de compilación. agente hospedado por Microsoft:
   Windows: C:\a\1\b
   Linux: /home/vsts/work/1/b
   macOS: /Users/runner/work/1/b
Agente autohospedado:
   Windows: C:\agent\_work\1\b
   Linux: /home/agent/_work/1/b
   macOS: ~/agent/work/1/b		 Build.BinariesDirectory
a: directorio de almacenamiento provisional de artefactos Contiene los artefactos de compilación. La limpieza se realiza entre ejecuciones en los agentes autohospedados. agente hospedado por Microsoft:
   Windows: C:\a\1\a
   Linux: /home/vsts/work/1/a
   macOS: /Users/runner/work/1/a
Agente autohospedado:
   Windows: C:\agent\_work\1\a
   Linux: /home/agent/_work/1/a
   macOS: ~/agent/work/1/a		 Build.StagingDirectory
Build.ArtifactStagingDirectory
System.ArtifactsDirectory
Directorio TestResults Contiene los resultados de la prueba. La limpieza se realiza entre ejecuciones en los agentes autohospedados. agente hospedado por Microsoft:
   Windows: C:\a\1\TestResults
   Linux: /home/vsts/work/1/TestResults
   macOS: /Users/runner/work/1/TestResults
Agente autohospedado:
   Windows: C:\agent\_work\1\TestResults
   Linux: /home/agent/_work/1/TestResults
   macOS: ~/agent/work/1/TestResults		 Common.TestResultsDirectory

En los agentes hospedados por Microsoft, se usa un agente diferente en cada ejecución, por lo que el directorio de trabajo no se conserva entre ejecuciones. En los agentes autohospedados, solo los directorios de ensayo de artefactos y los directorios de resultados de pruebas se limpian de forma predeterminada entre ejecuciones. Para obtener más información sobre la opción de limpieza del área de trabajo, consulte Área de trabajo.

Para obtener más información sobre las variables predefinidas, vea Variables predefinidas.

Preguntas más frecuentes

¿Cómo se garantiza la versión más reciente del agente?

  1. Vaya a la pestaña Grupos de agentes:

    1. Inicie sesión en su organización (https://dev.azure.com/{yourorganization}).

    2. Elija Azure DevOps, Configuración de la organización.

      Seleccione Configuración de organización.

    3. Seleccione Grupos de agentes.

      Seleccione la pestaña Grupos de agentes.

    1. Inicie sesión en la colección de proyectos (http://your-server/DefaultCollection).

    2. Seleccione Azure DevOps, Configuración de colección.

      Seleccione Configuración de colección.

    3. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes.

    1. Seleccione Azure DevOps, Configuración de colección.

      Configuración de colección, 2019.

    2. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes, 2019.

  2. Haga clic en el grupo que contiene el agente.

  3. Asegúrese de que el agente está habilitado.

  4. Vaya a la pestaña Funcionalidades:

    1. En la pestaña Grupos de agentes, seleccione el grupo de agentes deseado.

      En Grupos de agentes, seleccione el grupo de agentes deseado.

    2. Seleccione Agentes y elija el agente deseado.

      Seleccione Agentes y elija el agente.

    3. Selecciona la pestaña Funcionalidades.

      Seleccione la pestaña Capacidades.

      Nota:

      Los agentes hospedados por Microsoft no muestran las funcionalidades del sistema. Para una lista de software instalado en agentes hospedados por Microsoft, consulte Uso de un agente hospedado por Microsoft.

    1. En la pestaña Grupos de agentes, seleccione el grupo deseado.

      Seleccione el grupo deseado.

    2. Seleccione Agentes y elija el agente deseado.

      Seleccione Agentes y elija el agente deseado.

    3. Selecciona la pestaña Funcionalidades.

      Pestaña Funcionalidades del agente.

    1. En la pestaña Grupos de agentes, seleccione el grupo deseado.

      Seleccione la pestaña deseada, 2019.

    2. Seleccione Agentes y elija el agente deseado.

      Elija el agente deseado, 2019.

    3. Selecciona la pestaña Funcionalidades.

      Seleccione la pestaña Capacidades, 2019.

  5. Busque la funcionalidad Agent.Version. Puede comprobar este valor en la versión más reciente del agente publicado. Consulte Agente de Azure Pipelines y compruebe en la página el máximo número de versión enumerado.

  6. Los agentes se actualizan automáticamente cuando ejecutan una tarea que requiere una versión más reciente. Si desea actualizar manualmente algunos agentes, haga clic con el botón derecho en el grupo y seleccione Actualizar todos los agentes.

¿Puedo actualizar los agentes que forman parte de un grupo de Azure DevOps Server?

Sí. A partir de Azure DevOps Server 2019, puede configurar el servidor para buscar los archivos de paquete del agente en un disco local. Esta configuración invalidará la versión predeterminada incluida con el servidor en el momento de la publicación. Este escenario también se aplica cuando el servidor no tiene acceso a Internet.

  1. Desde un equipo con acceso a Internet, descargue la versión más reciente de los archivos de paquete del agente (en formato .zip o .tar.gz) desde la página Versiones de GitHub del agente de Azure Pipelines.

  2. Transfiera los archivos de paquete descargados a cada nivel de aplicación de Azure DevOps Server mediante el método que prefiera (USB, transferencia por la red, etc.). Coloque los archivos del agente en la carpeta %ProgramData%\Microsoft\Azure DevOps\Agents. Cree la carpeta Agentes si no está presente.

  3. ¡Ya está a punto! Azure DevOps Server ahora usará los archivos locales cada vez que se actualicen los agentes. Los agentes se actualizan automáticamente cuando ejecutan una tarea que requiere una versión más reciente. Pero si desea actualizar manualmente algunos agentes, haga clic con el botón derecho en el grupo y elija Actualizar todos los agentes.

¿Los agentes autohospedados tienen alguna ventaja de rendimiento con respecto a los agentes hospedados por Microsoft?

En muchos casos, sí. Concretamente:

  • Si usa un agente autohospedado, puede ejecutar compilaciones incrementales. Por ejemplo, si define una canalización que no limpia el repositorio y no realiza una compilación limpia, las compilaciones normalmente se ejecutarán más rápido. No se obtienen estas ventajas con un agente hospedado por Microsoft a menos que use características como almacenamiento en caché porque el agente se destruye después de que se complete la canalización.

  • Un agente hospedado por Microsoft puede tardar más tiempo en iniciar la compilación. Aunque a menudo el trabajo tarda unos segundos en asignarse a un agente hospedado por Microsoft, a veces puede tardar varios minutos en asignarse un agente, en función de la carga en nuestro sistema.

¿Puedo instalar varios agentes autohospedados en la misma máquina?

Sí. Este enfoque puede funcionar bien para los agentes que ejecutan trabajos que no consumen muchos recursos compartidos. Por ejemplo, podría probarlo para los agentes que ejecutan versiones que organizan principalmente las implementaciones y no hacen mucho trabajo en el propio agente.

En otros casos, es posible que no obtenga mucha eficacia mediante la ejecución de varios agentes en la misma máquina. Por ejemplo, puede que no valga la pena para los agentes que ejecutan compilaciones que consumen muchos recursos de disco y de E/S.

También podría tener problemas si los trabajos de compilación paralelos usan la misma implementación de herramienta singleton, como los paquetes npm. Por ejemplo, una compilación podría actualizar una dependencia mientras que otra compilación está en pleno uso de ella, lo que podría provocar resultados y errores de baja fiabilidad.

¿Cuál es el comportamiento de los agentes cuando se cancelan los trabajos de canalización?

En el caso de los agentes hospedados por Microsoft, el agente se descompone y se devuelve al grupo de Azure Pipelines.

Para agentes autohospedados:

Cuando se cancela una canalización, el agente envía una secuencia de comandos al proceso que ejecuta el paso actual.

  • El primer comando se envía con un tiempo de espera de 7,5 segundos.
  • Si el proceso no finaliza, se envía un segundo comando con un tiempo de espera de 2,5 segundos.
  • Si el proceso no termina, el agente ordena eliminarlo.
  • Si el proceso ignora las dos solicitudes de finalización iniciales, se eliminará.

Desde la solicitud inicial hasta la finalización tarda aproximadamente 10 segundos.

Los comandos emitidos al proceso para cancelar la canalización difieren en función del sistema operativo del agente.

  • macOS y Linux: los comandos enviados son SIGINT, seguidos de SIGTERM, seguidos de SIGKILL.
  • Windows: los comandos enviados al proceso son Ctrl+C, seguido de Ctrl+Interrumpir, seguido de Process.Kill.

¿Cómo puedo desencadenar actualizaciones de agente mediante programación para un grupo de agentes específico?

Puede desencadenar actualizaciones del agente para el grupo mediante la siguiente API:

POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

POST https://{server url}/tfs/{collection}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

Nota:

Para obtener más información sobre la asignación de versiones de API y Azure DevOps Server, consulte Asignación de versiones de API y Azure DevOps Server

Parámetros de identificador URI

Nombre En Obligatorio Type Descripción
agentId Query False string Agente que se va a actualizar. Si no se especifica, se desencadena la actualización para todos los agentes.
organization path True string El nombre de la organización de Azure DevOps.
poolId path True integer int32 Grupo de agentes que se va a usar
api-version Query False string Versión de la API que se va a usar. El valor debe establecerse en "6.0" para usar esta versión de la API.

Para desencadenar la actualización del agente: el cuerpo de la solicitud debe estar vacío.

Nota:

El agente de Azure Pipelines es de código abierto en GitHub.

Más información

Para más información sobre los agentes, consulte los siguientes módulos de la ruta de aprendizaje Compilación de aplicaciones con Azure DevOps.