Agentes de Azure Pipelines.

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

Necesita al menos un agente para compilar el código o implementar el software mediante Azure Pipelines. A medida que crece el código base y el equipo, necesita varios 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 que se hospedan en las máquinas virtuales (VM). Azure DevOps Services, Azure DevOps Server
Agentes de grupos de DevOps administrados Los grupos de DevOps administrados son un servicio totalmente administrado. Las máquinas virtuales o los contenedores que impulsan los agentes están en una suscripción de Microsoft Azure y no en su propia suscripción de Azure. Azure DevOps Services
Agentes de los conjuntos de escalado de máquinas virtuales de Azure Una forma de agentes autohospedados que usa conjuntos de escalado de máquinas virtuales de Azure y se puede escalar automáticamente para satisfacer las demandas.

Si está pensando en usar grupos de agentes autoscalables y autohospedados, recomendamos considerar grupos de DevOps administrados. Para más información, consulte Comparación de grupos de DevOps administrados con agentes de Azure Virtual Machine Scale Sets y Grupos de DevOps administrados.		 Azure DevOps Services

Puede ejecutar trabajos directamente en la máquina host del agente o en un contenedor.

Agentes hospedado por Microsoft

Si las canalizaciones están en Azure Pipelines, puede ejecutar convenientemente los trabajos mediante un agente hospedado por Microsoft. Con los agentes hospedados por Microsoft, el mantenimiento y las actualizaciones se producen automáticamente.

Siempre dispone de la versión más reciente de la imagen de máquina virtual que especifique en su pipeline. 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 único trabajo. Cualquier cambio que realice un trabajo en el sistema de archivos de la máquina virtual, como la extracción de código, no estará disponible en 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, este proceso es la manera más sencilla de ejecutar los trabajos. Puede probarlo primero para ver si funciona para la compilación o la implementación. Si no es así, puede usar agentes de conjuntos de escalado de máquinas virtuales 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 agente que configura para ejecutar trabajos y que usted mismo administra. Puede usar agentes autohospedados en Azure Pipelines o Azure DevOps Server. Los agentes autohospedados proporcionan más control para instalar software dependiente que necesita 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.

Aunque se pueden instalar varios agentes por máquina, se recomienda encarecidamente instalar solo un agente por máquina. Al instalar dos o más agentes, podría 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 y Windows. También puede instalar el agente en un contenedor de Docker. Para más información acerca de la instalación de un agente autohospedado, consulte:

En macOS, debe borrar el atributo especial en el archivo de descarga para evitar que la protección de macOS Gatekeeper se muestre para cada ensamblado en el archivo TAR cuando ./config.sh se ejecute. 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 ese equipo que requieran 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 y cuando 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 up-to-date y correcciones de errores.

versiones del ejecutor de Node.js

El agente se incluye con varias versiones de bibliotecas de Node.js para admitir tareas objetivo que usan diferentes manejadores de Node.js.

Todas las tareas oficiales de Azure DevOps usan Node.js biblioteca 20 como controlador universal. Sin embargo, es posible que los clientes sigan usando tareas personalizadas que usen las versiones de Node.js de fin de soporte técnico. Los autores de tareas personalizadas o de extensión deben actualizar o probar sus tareas con las versiones de Node.js actuales.

Para más información sobre el ciclo de vida del ejecutor de Node.js en Azure Pipelines, consulte Node.js ejecutores en el agente de Azure Pipelines.

Agentes de Azure de los Conjuntos de Escala de Máquinas Virtuales

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

Azure Pipelines se encarga del escalado de tus agentes automáticamente. Especifique los siguientes factores:

  • Un conjunto escalable de máquinas virtuales
  • Número de agentes que se van a mantener en espera
  • El número máximo de máquinas virtuales en un conjunto de escala

Para más información, consulte Agentes de Azure Virtual Machine Scale Sets.

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 maneras de equilibrar el costo y el rendimiento.
  • Proporciona rutas de acceso para los escenarios más comunes.
  • Reduce significativamente el tiempo necesario para crear y mantener grupos personalizados.

Los grupos de DevOps administrados son una evolución de los grupos de agentes de Azure Virtual Machine Scale Sets. Simplifica 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. Las máquinas virtuales o contenedores que impulsan a los agentes residen en una suscripción de Microsoft Azure y no en su propia suscripción de Azure, de forma similar a los grupos de agentes de Azure Virtual Machine Scale Sets. Para obtener más información, consulte la documentación sobre Managed DevOps Pools.

Trabajos paralelos

El concepto de trabajos paralelos representa 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 solo trabajo a la vez en su organización. Cualquier otro trabajo simultáneo se pone en cola hasta que finalice 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 se cobran trabajos simultáneos autohospedados en despliegues. 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 capacidades son pares de nombre y valor que son:

  • Funcionalidades que detecta el software del agente, denominadas funcionalidades del sistema.
  • Funcionalidades que defina, denominadas funcionalidades de usuario.

El software del agente determina automáticamente varias funcionalidades del sistema. Estas funcionalidades incluyen 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.

Al almacenar variables de entorno como funcionalidades, los valores de funcionalidad almacenados se usan para establecer las variables de entorno cuando se ejecuta un agente. Además, cuando se realizan cambios en las variables de entorno mientras se ejecuta el agente, no se seleccionan ni usan en ninguna tarea. Si no desea que las variables de entorno confidenciales que cambien se almacenen como funcionalidades, puede dirigir al agente para omitirlas. Establezca la VSO_AGENT_IGNORE variable de entorno, 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.

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 del agente, incluidas las funcionalidades del sistema y la versión, y administrar sus funcionalidades de usuario. 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. SeleccioneConfiguración de organización de >.

      Captura de pantalla que muestra cómo seleccionar Configuración de la organización.

    3. Seleccione Grupos de agentes.

      Captura de pantalla que muestra cómo seleccionar 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 la colección.

      Captura de pantalla que muestra cómo seleccionar Configuración de recopilación.

    3. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes.

    Captura de pantalla que muestra cómo ir a y seleccionar Grupos de agentes.

  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.

  3. Para registrar una nueva funcionalidad con el agente, seleccione 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. Determina qué trabajo necesita ejecutar e informa 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, como se muestra en los ejemplos siguientes.

Gráfico que muestra las topologías de agente en instalaciones locales.

Gráfico que muestra las topologías de agente 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. Para registrar un agente en ese grupo de agentes, debe tener el rol de administrador del grupo de agentes . El rol de administrador del grupo de agentes solo es necesario 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 listener OAuth token y lo utiliza para monitorear la cola de trabajos.

  2. El agente escucha si se publica una nueva solicitud de trabajo en la cola de trabajos en Azure Pipelines o Azure DevOps Server mediante un sondeo largo HTTP. Cuando hay un trabajo disponible, el agente descarga el trabajo y un job-specific OAuth token. 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, usa el token para acceder al código fuente o cargar los resultados de la prueba.

  3. El agente descarta el token específico OAuth del proceso una vez que este ha concluido, y luego verifica si hay una nueva solicitud de trabajo utilizando el token de OAuth del oyente.

La carga de los mensajes intercambiados entre el agente y Azure Pipelines o Azure DevOps Server se protege mediante el 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 enviarlo 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 no usa la codificación UTF-8, es posible que encuentre algunos problemas con la salida del registro. Por ejemplo, los registros pueden contener caracteres que la codificación del sistema no reconoce, por lo que es posible que parezcan estar ensargblados o que falten símbolos.

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. Los grupos de agentes hospedados por Microsoft, de forma predeterminada, tienen conectividad con sitios web y servidores de Azure que se ejecutan en Azure.

Si los recursos de Azure se ejecutan en una red virtual de Azure, puede obtener los intervalos IP del agente donde se implementan los agentes hospedados por Microsoft. A continuación, puede configurar las reglas de firewall de la red virtual de Azure para permitir 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 con los entornos locales de destino y el acceso a Internet para conectarse a Azure Pipelines o Azure DevOps Server. Este proceso se muestra en el esquema siguiente:

Gráfico que muestra la 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. Para configurar el agente, también debe ser administrador local en el servidor.

Al registrar un agente, seleccione entre los siguientes tipos de autenticación. El proceso de configuración del agente le solicita 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.

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

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

Importante

Debe configurar el servidor para que admita el método de autenticación para usar la autenticación alternativa, negociación o integrada.

El método de autenticación que se usa para registrar el agente solo se usa durante el registro del agente. 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, se recomienda probarlo primero en modo interactivo para asegurarse de que funciona. A continuación, para su uso en producción, se recomienda ejecutar el agente en uno de los modos siguientes para que permanezca de forma confiable en un estado en ejecución. Estos modos también garantizan que el agente se inicie automáticamente si se reinicia la máquina.

  • Como servicio: puede usar el administrador de servicios del sistema operativo para administrar el ciclo de vida del agente. La experiencia de actualización automática del agente es mejor cuando se ejecuta el agente como un servicio.

  • Como 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 (por ejemplo, para ejecutar pruebas de IU). Al configurar un agente para que se ejecute en este modo, el protector de pantalla está deshabilitado. Algunas directivas de dominio pueden impedir que habilite el inicio de sesión 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. Es posible que otros usuarios puedan acceder al equipo y usar 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 un escritorio remoto para acceder a un equipo en el que se ejecuta un agente con inicio de sesión automático, al cerrar el escritorio remoto, el equipo se bloquea. Es posible que se produzcan errores en las pruebas de iu que se ejecutan en este agente. Para evitar este problema, use el tscon comando para desconectar del 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 del 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 mediante la autenticación de Windows para acceder a un servicio externo, el agente debe ejecutarse mediante una cuenta con acceso a ese servicio. Sin embargo, si está ejecutando pruebas de IU como Selenium o pruebas automatizadas de IU que requieren un explorador, el explorador se abre en el contexto de la cuenta del agente.

En Windows, se recomienda usar una cuenta de servicio como Servicio de red o Servicio local. Estos permisos de cuentas están restringidos y sus contraseñas no expiran, por lo que el agente requiere menos administración a lo largo del 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.

Mantenemos actualizados los agentes hospedados por Microsoft. 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. La configuración predeterminada está habilitada. Para configurar esta opción en grupos de agentes , seleccione el agente y, a continuación, seleccione Configuración. Se solicita una actualización cuando una característica de plataforma o una de las tareas de 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 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.

    Captura de pantalla que muestra cómo buscar y seleccionar grupos de agentes.

  2. Seleccione el grupo de agentes y, a continuación, seleccione Actualizar todos los agentes.

    Captura de pantalla que muestra cómo seleccionar Actualizar todos los agentes.

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

    Captura de pantalla que muestra cómo seleccionar Actualizar agente.

  3. Seleccione Actualizar para confirmar.

    Captura de pantalla que muestra cómo seleccionar Actualizar para confirmar.

  4. Se pone en cola una solicitud de actualización para cada agente del grupo y se ejecuta cuando finalizan los trabajos en ejecución. Normalmente, una actualización tarda unos instantes. Esta cantidad de tiempo es lo suficientemente larga como para descargar la versión más reciente del software del agente (aproximadamente 200 MB), descomprimirla 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 de 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 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 que se usan 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 si hay disponible una versión principal más reciente del agente, es posible que tenga que actualizar manualmente los agentes. 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.

Puede ver la versión de un agente. Vaya a Grupos de agentes y seleccione la pestaña Funcionalidades del agente deseado, como se describe en Configuración de 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 las actualizaciones del agente mediante programación para un grupo de agentes específico?.

En el caso de 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

Estructura del directorio del agente

Cuando los trabajos de canalización se ejecutan 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:


    - /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 Donde 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 Donde 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 - Origen o directorio de trabajo Contiene el código fuente extraído del repositorio. Si hay varios checkout pasos en tu trabajo, el código fuente se ha extraído en directorios nombrados según 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
TestResults directorio 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 entre ejecuciones de forma predeterminada. 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. SeleccioneConfiguración de organización de >.

      Captura de pantalla que muestra cómo seleccionar Configuración de la organización.

    3. Seleccione Grupos de agentes.

      Captura de pantalla que muestra cómo seleccionar 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 la colección.

      Captura de pantalla que muestra cómo seleccionar Configuración de recopilación.

    3. Seleccione Grupos de agentes.

      Seleccione Grupos de agentes.

    Captura de pantalla que muestra cómo ir a y seleccionar Grupos de agentes.

  2. Seleccione 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.

  5. Busque la funcionalidad Agent.Version. Puede comparar este valor con la versión más reciente del agente publicado en la página Agente de Azure Pipelines .

  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 archivos de paquete del agente en un disco local. Esta configuración invalida la versión predeterminada que se incluye con el servidor en el momento de su lanzamiento. 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 .zip o formulario de .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 del servidor de Azure DevOps mediante un método de su elección (por ejemplo, unidad USB, transferencia de red, etc.). Coloque los archivos del agente en la carpeta %ProgramData%\Microsoft\Azure DevOps\Agents. Si no hay ninguna carpeta con la etiqueta Agentes, cree una.

  3. ¡Ya está a punto! Azure DevOps Server ahora usa los archivos locales cada vez que se actualizan 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í. 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 obtiene estas ventajas con un agente hospedado por Microsoft a menos que use características como el almacenamiento en caché, ya que el agente se destruye una vez completada la canalización.

Un agente hospedado por Microsoft puede tardar más tiempo en iniciar la compilación. Aunque a menudo tarda unos segundos en asignarse el trabajo 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 una gran cantidad de espacio en disco y recursos de entrada y salida.

También pueden surgir problemas si los trabajos de compilación paralelos utilizan el mismo despliegue de herramientas en modo único (por ejemplo, paquetes npm). Una compilación podría actualizar una dependencia mientras otra compilación la usa, lo que podría provocar resultados y errores poco confiables.

¿Qué hacen 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á.

El tiempo desde la solicitud inicial hasta la finalización es de 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, seguidos de Ctrl+Break, seguidos 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 más información, consulte API y asignación de versiones de Azure DevOps Server.

Parámetros de URI

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

Para desencadenar una actualización del agente, el cuerpo de la petición HTTP debe estar vacío.

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

Contenido relacionado

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 :

  • Last updated on