Compartir a través de


Agentes de Linux autohospedados

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

En este artículo se proporcionan instrucciones para usar el software del agente 4.x con Azure DevOps Services y Azure DevOps Server.

En este artículo se proporcionan instrucciones para usar el software del agente 3.x con Azure DevOps Server 2022 y Azure DevOps Server 2020. Para obtener una lista de las versiones de Azure DevOps Server que admiten el agente 3.x, consulte ¿Admite Azure DevOps Server el agente 3.x?

Importante

Si usa Azure DevOps Services o Azure DevOps Server, debe usar el software del agente 4.x.

Para ejecutar los trabajos, necesita al menos un agente. Un agente de Linux puede compilar e implementar diferentes tipos de aplicaciones, incluidas las aplicaciones De Java y Android. Consulte Comprobación de los requisitos previos para obtener una lista de las distribuciones de Linux admitidas.

Nota:

En este artículo se describe cómo configurar un agente autohospedado. Si usa Azure DevOps Services y un agente hospedado por Microsoft satisface sus necesidades, puede omitir la configuración de un agente linux autohospedado .

Más información acerca de los agentes

Si ya sabe qué es un agente y cómo funciona, vaya directamente a las secciones siguientes. Pero si desea más información sobre lo que hacen y cómo funcionan, consulte Agentes de Azure Pipelines.

Comprobación de los requisitos previos

El agente 4.x se basa en .NET 8. Puede ejecutar este agente en varias distribuciones de Linux. Se admite el siguiente subconjunto de distribuciones compatibles con .NET 8:

  • Distribuciones admitidas
    • x64
      • Debian 12
      • Fedora 39 y 40
      • openSUSE 15.5 y 15.6
      • Red Hat Enterprise Linux 8 & 9
      • SUSE Enterprise Linux 15.5
      • Ubuntu 24.04, 22.04, 20.04
      • Azure Linux 2.0
      • Oracle Linux 8 y 9
    • ARM64
      • Debian 11 & 12
      • Ubuntu 24.04, 22.04, 20.04
    • Alpine x64
  • Git : independientemente de la plataforma, debe instalar Git 2.9.0 o posterior. Se recomienda encarecidamente instalar la versión más reciente de Git.
  • .NET : el software del agente se ejecuta en .NET 8, pero instala su propia versión de .NET, por lo que no hay ningún requisito previo de .NET.
  • Subversion : si va a compilar desde un repositorio de Subversion, debe instalar el cliente de Subversion en el equipo.
  • TFVC : si va a compilar desde un repositorio de TFVC, consulte Requisitos previos de TFVC.

Nota:

El instalador del agente sabe cómo comprobar otras dependencias. Puede instalar esas dependencias en plataformas Linux compatibles mediante la ejecución ./bin/installdependencies.sh en el directorio del agente.

Tenga en cuenta que algunas de estas dependencias requeridas por .NET se capturan de sitios de terceros, como packages.efficios.com. Revise el installdependencies.sh script y asegúrese de que los sitios de terceros a los que se hace referencia sean accesibles desde la máquina Linux antes de ejecutar el script.

Asegúrese también de que todos los repositorios necesarios estén conectados al administrador de paquetes correspondiente usado en installdependencies.sh (como apt o zypper).

Para problemas con la instalación de dependencias (como "no se encontró dependencia en el repositorio" o "problema al recuperar el archivo de índice del repositorio") puede ponerse en contacto con el propietario de la distribución para obtener más soporte técnico.

El agente 3.x se basa en .NET 6. Puede ejecutar este agente en varias distribuciones de Linux. Se admite el siguiente subconjunto de distribuciones compatibles con .NET 6:

  • Distribuciones admitidas
    • x64
      • Debian 10+
      • Fedora 36+
      • openSUSE 15+
      • Red Hat Enterprise Linux 7+
        • Ya no requiere un paquete independiente
      • SUSE Enterprise Linux 12 SP2 o posterior
      • Ubuntu 24.04, 22.04, 20.04, 18.04, 16.04
      • Azure Linux 2.0
      • Oracle Linux 7 y versiones posteriores
    • ARM64
      • Debian 10+
      • Ubuntu 22.04, 20.04, 18.04
    • Alpine x64
  • Git : independientemente de la plataforma, debe instalar Git 2.9.0 o posterior. Se recomienda encarecidamente instalar la versión más reciente de Git.
  • .NET : el software del agente se ejecuta en .NET 6, pero instala su propia versión de .NET, por lo que no hay ningún requisito previo de .NET.
  • Subversion : si va a compilar desde un repositorio de Subversion, debe instalar el cliente de Subversion en el equipo.
  • TFVC : si va a compilar desde un repositorio de TFVC, consulte Requisitos previos de TFVC.

Nota:

El instalador del agente sabe cómo comprobar otras dependencias. Puede instalar esas dependencias en plataformas Linux compatibles mediante la ejecución ./bin/installdependencies.sh en el directorio del agente.

Tenga en cuenta que algunas de estas dependencias requeridas por .NET se capturan de sitios de terceros, como packages.efficios.com. Revise el installdependencies.sh script y asegúrese de que los sitios de terceros a los que se hace referencia sean accesibles desde la máquina Linux antes de ejecutar el script.

Asegúrese también de que todos los repositorios necesarios estén conectados al administrador de paquetes correspondiente usado en installdependencies.sh (como apt o zypper).

Para problemas con la instalación de dependencias (como "no se encontró dependencia en el repositorio" o "problema al recuperar el archivo de índice del repositorio") puede ponerse en contacto con el propietario de la distribución para obtener más soporte técnico.

La primera vez, debe ejecutar la instalación del agente manualmente. Después de hacerse una idea de cómo funcionan los agentes o si desea automatizar la configuración de muchos agentes, considere la posibilidad de usar la configuración desatendida.

Preparación de los permisos

Seguridad de la información para los agentes autohospedados

Para configurar el agente, el usuario necesita permisos de administrador del grupo, pero no para ejecutarlo.

Las carpetas controladas por el agente deben estar restringidas a los pocos usuarios como sea posible, ya que contienen secretos que se pueden descifrar o filtrar.

El agente de Azure Pipelines es un producto de software diseñado para ejecutar código que descarga de orígenes externos. De forma inherente, podría recibir ataques de ejecución remota de código (RCE).

Por lo tanto, es importante tener en cuenta el modelo de amenazas que rodea a cada uso individual de los agentes de canalizaciones para realizar el trabajo y decidir cuáles son los permisos mínimos que se pueden conceder al usuario que ejecuta el agente, al equipo donde se ejecuta el agente, a los usuarios que tienen acceso de escritura a la definición de canalización, los repositorios de Git donde se almacena el yaml, o el grupo de usuarios que controlan el acceso al grupo para las nuevas canalizaciones.

Es un procedimiento recomendado hacer que la identidad que ejecute el agente sea diferente de la identidad con permisos para conectar el agente al grupo. El usuario que genera las credenciales (y otros archivos relacionados con el agente) es diferente del usuario que necesita leerlas. Por lo tanto, es más seguro considerar cuidadosamente el acceso concedido a la propia máquina del agente y las carpetas del agente que contienen archivos confidenciales, como los registros y los artefactos.

Tiene sentido conceder acceso a la carpeta del agente solo a los administradores de DevOps y la identidad de usuario que ejecuta el proceso del agente. Es posible que los administradores necesiten investigar el sistema de archivos para comprender errores de compilación u obtener archivos de registro para poder notificar errores de Azure DevOps.

Decida el usuario que va a usar

Debe registrar el agente una vez. Alguien con permiso para administrar la cola del agente debe completar estos pasos. El agente no usará las credenciales de esta persona en las operaciones diarias, pero es necesario para completar el registro. Más información sobre cómo se comunican los agentes.

Confirmación de que el usuario tiene permiso

Asegúrese de que la cuenta de usuario que va a usar tiene permiso para registrar el agente.

¿Es el usuario propietario de una organización de Azure DevOps o TFS, o administrador de Azure DevOps Server? Deténgase aquí, tiene permiso.

De lo contrario:

  1. Abra un explorador y vaya a la pestaña Grupos de agentes de la organización de Azure Pipelines, Azure DevOps Server o el servidor TFS:

    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 DevOpsCollection settings (Configuración de la colección de >).

      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 en el lado derecho de la página y haga clic en Seguridad.

  3. Si no se muestra la cuenta de usuario que va a usar, que un administrador la agregue. El administrador puede ser administrador del grupo de agentes, propietario de la organización de Azure DevOps o administrador de TFS o Azure DevOps Server.

    Si se trata de un agente de grupo de implementación, el administrador puede ser administrador del grupo de implementación, propietario de la organización de Azure DevOps o administrador de TFS o Azure DevOps Server.

    Puede agregar un usuario al rol de administrador del grupo de implementación en la pestaña Seguridad de la página Grupos de implementación de Azure Pipelines.

Nota:

Si ve un mensaje similar al siguiente: Lo lamentamos, no se pudo agregar la identidad. Pruebe con una identidad diferente. Probablemente haya seguido los pasos anteriores para el propietario de la organización o el administrador de TFS o Azure DevOps Server. No necesitas hacer nada; Ya tiene permiso para administrar el grupo de agentes.

Descarga y configuración del agente

Azure Pipelines (Canales de Azure)

  1. Inicie sesión en la máquina con la cuenta para la que ha preparado los permisos, tal como se explica en la sección anterior.

  2. En el explorador web, inicie sesión en Azure Pipelines y 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 DevOpsCollection settings (Configuración de la colección de >).

      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.

  3. Seleccione el grupo Predeterminado y la pestaña Agentes, y elija Nuevo agente.

  4. En el cuadro de diálogo Obtener el agente , haga clic en Linux.

  5. En el panel izquierdo, seleccione el sabor específico. Ofrecemos x64 o ARM para muchas distribuciones de Linux.

  6. En el panel derecho, haga clic en el botón Descargar .

  7. Siga las instrucciones de la página.

  8. Desempaquete el agente en el directorio que prefiera. cd a ese directorio y ejecute ./config.sh.

Dirección URL del servidor

Azure Pipelines: https://dev.azure.com/{your-organization}

Tipo de autenticación

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.

Ejecución de forma interactiva

Para instrucciones sobre la ejecución del agente en modo interactivo o como servicio, consulte Agentes: interactivos o como servicio.

Para ejecutar el agente en modo interactivo:

  1. Si ha ejecutado el agente como servicio, desinstale el servicio.

  2. Ejecute el agente.

    ./run.sh
    

Para reiniciar el agente, presione Ctrl+C y ejecute run.sh para reiniciarlo.

Para usar el agente, ejecute un trabajo mediante el grupo del agente. Si no ha elegido un grupo diferente, el agente se coloca en el grupo predeterminado .

Una ejecución

Para los agentes configurados para que se ejecuten de forma interactiva, puede elegir que el agente acepte solo un trabajo. Para la ejecución en esta configuración:

./run.sh --once

Los agentes en este modo solo aceptarán un trabajo y se retirarán fácilmente (útiles para la ejecución de un Docker en servicios como Azure Container Instances).

Ejecutar como servicio systemd

Si el agente se ejecuta en estos sistemas operativos, puede ejecutar el agente como servicio systemd:

  • Ubuntu 16 LTS o versiones posteriores
  • Red Hat 7.1 o posterior

Proporcionamos un script de ejemplo ./svc.sh para que ejecute y administre el agente como systemd servicio. Este script se generará una vez configurado el agente. Le recomendamos que revise y, si es necesario, actualice el script antes de ejecutarlo.

Algunas advertencias importantes:

  • Si ejecutas tu agente como un servicio, no puedes ejecutar el servicio del agente como usuario root.
  • Los usuarios que ejecutan SELinux han notificado dificultades con el script proporcionado svc.sh . Consulte este problema del agente como punto de partida. SELinux no es una configuración compatible oficialmente.

Nota:

Si tiene una distribución diferente o si prefiere otros enfoques, puede usar cualquier tipo de mecanismo de servicio que prefiera. Consulte Archivos de servicio.

Órdenes

Cambio al directorio del agente

Por ejemplo, si realizó la instalación en la subcarpeta myagent del directorio principal:

cd ~/myagent$

Instalar

Comando:

sudo ./svc.sh install [username]

Este comando crea un archivo de servicio que apunta a ./runsvc.sh. Este script configura el entorno (más detalles a continuación) e inicia el host de agentes. Si username no se especifica el parámetro , el nombre de usuario se toma de la variable de entorno $SUDO_USER establecida por el comando sudo. Esta variable siempre es igual al nombre del usuario que invocó el sudo comando.

Comenzar

sudo ./svc.sh start

Estado

sudo ./svc.sh status

Parar

sudo ./svc.sh stop

Desinstalar

Deberías detenerte antes de desinstalar.

sudo ./svc.sh uninstall

Actualización de las variables de entorno

Al configurar el servicio, se toma una instantánea de algunas variables de entorno útiles para el usuario con sesión iniciada, como PATH, LANG, JAVA_HOME, ANT_HOME y MYSQL_PATH. Si necesita actualizar las variables (por ejemplo, después de instalar algún software nuevo):

./env.sh
sudo ./svc.sh stop
sudo ./svc.sh start

La instantánea de las variables de entorno se almacena en el archivo .env (PATH se almacena en .path) en el directorio raíz del agente; también puede cambiar estos archivos directamente para aplicar cambios en las variables de entorno.

Ejecución de instrucciones antes de que se inicie el servicio

También puede usar sus propias instrucciones y comandos para que ejecuten al inicio del servicio. Por ejemplo, podría configurar el entorno o los scripts de llamada.

  1. Edite runsvc.sh.

  2. Reemplace la siguiente línea por sus instrucciones:

    # insert anything to setup env when running as a service
    

Archivos de servicio

Al instalar el servicio, se colocan algunos archivos de servicio.

archivo de servicio systemd

Se crea un systemd archivo de servicio:

/etc/systemd/system/vsts.agent.{tfs-name}.{agent-name}.service

Por ejemplo, ha configurado un agente (consulte más arriba) con el nombre our-linux-agent. El archivo de servicio será uno de los siguientes:

  • Azure Pipelines: el nombre de la organización. Por ejemplo, si se conecta a https://dev.azure.com/fabrikam, el nombre del servicio sería /etc/systemd/system/vsts.agent.fabrikam.our-linux-agent.service.

  • TFS o Azure DevOps Server: el nombre del servidor local. Por ejemplo, si se conecta a http://our-server:8080/tfs, el nombre del servicio sería /etc/systemd/system/vsts.agent.our-server.our-linux-agent.service.

sudo ./svc.sh install genera el archivo a partir de esta plantilla: ./bin/vsts.agent.service.template

Archivo .service

sudo ./svc.sh start busca el servicio leyendo el .service archivo, que contiene el nombre del archivo de servicio systemd descrito anteriormente.

Mecanismos de servicio alternativos

Proporcionamos el ./svc.sh script como una manera cómoda de ejecutar y administrar tu agente como un servicio de systemd. Pero puede usar cualquier tipo de mecanismo de servicio que prefiera (por ejemplo: initd o upstart).

Puede usar la plantilla descrita anteriormente para facilitar la generación de otros tipos de archivo de servicio.

Uso de un cgroup para evitar errores del agente

Es importante evitar situaciones en las que el agente produce un error o deja de ser utilizable porque, de lo contrario, el agente no puede transmitir los registros de canalización ni informar del estado de la canalización al servidor. Puede mitigar el riesgo de que este tipo de problema se deba a una presión de memoria alta mediante cgroups y un menor oom_score_adj. Una vez hecho esto, Linux reclama la memoria del sistema de los procesos del trabajo de canalización antes de reclamar memoria del proceso del agente. Obtenga información sobre cómo configurar cgroups y la puntuación de OOM.

Reemplazo de un agente

Para reemplazar un agente, siga los pasos de Descarga y configuración del agente de nuevo.

Al configurar un agente con el mismo nombre que un agente que ya existe, se le pregunta si desea reemplazar el agente existente. Si responde Y, asegúrese de quitar el agente (consulte a continuación) que va a reemplazar. De lo contrario, después de unos minutos de conflictos, uno de los agentes se apagará.

Quitar y volver a configurar un agente

Para eliminar el agente:

  1. Detenga y desinstale el servicio como se explica en la sección anterior.

  2. Elimine el agente.

    ./config.sh remove
    
  3. Escriba sus credenciales.

Después de quitar el agente, puede volver a configurarlo.

Configuración desatendida

El agente se puede configurar desde un script sin intervención humana. Debe pasar --unattended y las respuestas a todas las preguntas.

Para configurar un agente, debe conocer la dirección URL de la organización o la colección, y las credenciales de alguien autorizado para configurar agentes. Todas las demás respuestas son opcionales. En su lugar, se puede especificar cualquier parámetro de línea de comandos mediante una variable de entorno: coloque su nombre en mayúsculas y anteponga VSTS_AGENT_INPUT_. Por ejemplo, VSTS_AGENT_INPUT_PASSWORD en lugar de especificar --password.

Opciones necesarias

  • --unattended: el programa de instalación del agente no solicitará información y todas las configuraciones se deben proporcionar en la línea de comandos.
  • --url <url>: dirección URL del servidor. Por ejemplo, https://dev.azure.com/myorganization o http://my-azure-devops-server:8080/tfs.
  • --auth <type>: tipo de autenticación. Los valores válidos son:
    • pat (Token de acceso personal): PAT es el único esquema que funciona con Azure DevOps Services.
    • alt (Autenticación básica)

Opciones de autenticación

  • Si ha elegido --auth pat:
    • --token <token>: especifica su token de acceso personal.
    • PAT es el único esquema que funciona con Azure DevOps Services.
  • Si ha elegido --auth negotiate o --auth alt:
    • --userName <userName> : especifica un nombre de usuario.
    • --password <password>: especifica una contraseña.

Nombres de grupo y agente

  • --pool <pool>: nombre del grupo al que se unirá el agente.
  • --agent <agent>: nombre del agente.
  • --replace - Reemplace el agente en un grupo. Si otro agente está escuchando por el mismo nombre, comenzará a generar un error de conflicto.

Instalación del agente

  • --work <workDirectory>: directorio de trabajo donde se almacenan los datos del trabajo. El valor predeterminado es _work en la raíz del directorio del agente. El directorio de trabajo es propiedad de un agente determinado y no debe compartirse entre varios agentes.
  • --acceptTeeEula: acepta el contrato de licencia de usuario final Team Explorer Everywhere (solo macOS y Linux).
  • --disableloguploads - no envíes ni transmitas la salida de los logs de la consola al servidor. En su lugar, puede recuperarlos del sistema de archivos del host del agente una vez completado el trabajo.

Solo el grupo de implementación

  • --deploymentGroup: configura el agente como agente del grupo de implementación.
  • --deploymentGroupName <name>: se usa con --deploymentGroup para especificar el grupo de implementación para que el agente se una.
  • --projectName <name>: se usa con --deploymentGroup para establecer el nombre del proyecto.
  • --addDeploymentGroupTags: se usa con --deploymentGroup para indicar que se deben agregar etiquetas de grupo de implementación.
  • --deploymentGroupTags <tags>: se usa con --addDeploymentGroupTags para especificar la lista de etiquetas separadas por comas para el agente del grupo de implementación; por ejemplo, "web, db".

Solo entornos

  • --addvirtualmachineresourcetags: se usa para indicar que se deben agregar etiquetas de recurso del entorno.
  • --virtualmachineresourcetags <tags>: se usa con --addvirtualmachineresourcetags para especificar la lista de etiquetas separadas por comas para el agente del recurso de entorno; por ejemplo, "web, db".

./config.sh --help siempre enumera las respuestas obligatorias y opcionales más recientes.

Diagnósticos

Si tiene problemas con el agente autohospedado, puede intentar ejecutar diagnósticos. Después de configurar el agente:

./run.sh --diagnostics

Esto se ejecutará a través de un conjunto de diagnósticos que puede ayudarle a solucionar el problema. La característica de diagnóstico está disponible a partir de la versión 2.165.0 del agente.

Diagnósticos de red para agentes autohospedados

Cambie el valor de Agent.Diagnostic a true para recopilar registros adicionales que se pueden usar para solucionar problemas de red para agentes autohospedados. Para obtener más información, consulte Diagnósticos de red para agentes autohospedados.

Ayuda sobre otras opciones

Para información sobre otras opciones:

./config.sh --help

La ayuda proporciona información sobre las opciones de autenticación y la configuración desatendida.

Capacidades

Las funcionalidades del agente se catalogan y anuncian en el grupo para que solo se asignen las compilaciones y versiones que pueda controlar. Consulte Funcionalidades del agente de compilación y versión.

En muchos casos, después de implementar un agente, se debe instalar software o utilidades. Por lo general, deberías instalar en tus agentes las mismas herramientas y software que utilices en tu máquina de desarrollo.

Por ejemplo, si la compilación incluye la tarea npm, la compilación no se ejecutará a menos que haya un agente de compilación en el grupo que tenga npm instalado.

Importante

Las funcionalidades incluyen todas las variables de entorno y los valores que se establecen cuando se ejecuta el agente. Si alguno de estos valores cambia durante la ejecución del agente, este último debe reiniciarse para recoger los nuevos valores. Después de instalar nuevo software en un agente, debe reiniciarlo para que la nueva funcionalidad se muestre en el grupo y que la compilación de pueda ejecutar.

Si desea excluir variables de entorno como funcionalidades, puede designarlas estableciendo una variable de entorno VSO_AGENT_IGNORE con una lista de las variables que deben omitir delimitadas por comas.

Preguntas más frecuentes

¿Dónde puedo obtener más información sobre el nuevo software de agente v3?

Para obtener información y preguntas más frecuentes sobre el software del agente v3, consulte Software del agente versión 3.

¿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 DevOpsCollection settings (Configuración de la colección de >).

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

  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 siguiente carpeta:

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

Cree la carpeta Agentes, en caso de que no exista.

  1. ¡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.

¿Por qué se necesita sudo para ejecutar los comandos de servicio?

./svc.sh usa systemctl, que requiere sudo.

Código fuente: systemd.svc.sh.template en GitHub

Estoy ejecutando un firewall y mi código está en Azure Repos. ¿Con qué direcciones URL necesita comunicarse el agente?

Si ejecuta un agente en una red segura detrás de un firewall, asegúrese de que el agente puede iniciar la comunicación con las siguientes direcciones URL e IP.

URL de dominio Descripción
https://{organization_name}.pkgs.visualstudio.com API de empaquetado de Azure DevOps para organizaciones que usan el dominio {organization_name}.visualstudio.com
https://{organization_name}.visualstudio.com Para las organizaciones que usan el dominio {organization_name}.visualstudio.com
https://{organization_name}.vsblob.visualstudio.com Telemetría de Azure DevOps para organizaciones que usan el dominio {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com Servicios de Release Management para las organizaciones que usan el dominio {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com Servicios de plataforma de Azure DevOps para las organizaciones que usan el dominio {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com Servicios de administración de pruebas de Azure DevOps para las organizaciones que usan el dominio {organization_name}.visualstudio.com
https://*.blob.core.windows.net Azure Artifacts
https://*.dev.azure.com Para las organizaciones que usan el dominio dev.azure.com
https://*.vsassets.io Azure Artifacts a través de CDN
https://*.vsblob.visualstudio.com Telemetría de Azure DevOps para organizaciones que usan el dominio dev.azure.com
https://*.vssps.visualstudio.com Servicios de plataforma de Azure DevOps para las organizaciones que usan el dominio dev.azure.com
https://*.vstmr.visualstudio.com Servicios de administración de pruebas de Azure DevOps para las organizaciones que usan el dominio dev.azure.com
https://app.vssps.visualstudio.com Para las organizaciones que usan el dominio {organization_name}.visualstudio.com
https://dev.azure.com Para las organizaciones que usan el dominio dev.azure.com
https://login.microsoftonline.com inicio de sesión de Microsoft Entra
https://management.core.windows.net API de administración de Azure
https://download.agent.dev.azure.com Paquete del agente

Importante

La CDN de Edgio para Azure DevOps ha sido retirada, lo que requiere que una nueva URL de dominio sea incluida en la lista de permitidos en las reglas del firewall para la descarga del software del agente. El nuevo dominio para la lista de permitidos para la descarga de agente es https://*.dev.azure.com. Si las reglas de firewall no permiten caracteres comodín, use https://download.agent.dev.azure.com.

El equipo de Azure DevOps recomienda realizar este cambio en la fecha siguiente:

  • 1 de mayo de 2025 para Azure DevOps Services
  • 15 de mayo de 2025 para Azure DevOps Server

Para obtener más información, consulte Cambio de dirección URL de dominio de CDN para agentes en canalizaciones.

Para asegurarse de que su organización funcione con cualquier firewall o restricciones de IP existentes, asegúrese de que dev.azure.com y *dev.azure.com estén abiertos y actualice las direcciones IP permitidas para incluir las siguientes direcciones IP, según su versión de IP. Si actualmente permite enumerar las direcciones IP 13.107.6.183 y 13.107.9.183, déjelas en su lugar, ya que no es necesario quitarlas.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Nota:

Para más información sobre las direcciones permitidas, consulte Listas de direcciones y conexiones de red permitidas.

¿Cómo se ejecuta el agente con certificado autofirmado?

Ejecución del agente con certificado autofirmado

¿Cómo se ejecuta el agente detrás de un proxy web?

Ejecutar el agente detrás de un proxy web

¿Cómo se reinicia el agente?

Si ejecuta el agente de forma interactiva, consulte las instrucciones de reinicio en Ejecución interactiva. Si ejecuta el agente como un servicio de sistema, siga los pasos descritos en Detener y, a continuación, Inicie el agente.

¿Cómo se configura el agente para omitir un proxy web y conectarse a Azure Pipelines?

Si desea que el agente omita el proxy y se conecte directamente a Azure Pipelines, debe configurar el proxy web para permitir que el agente acceda a las siguientes direcciones URL.

Para las organizaciones que usan el dominio *.visualstudio.com:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

Para las organizaciones que usan el dominio dev.azure.com:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://download.agent.dev.azure.com
https://vssps.dev.azure.com

Para asegurarse de que su organización funcione con cualquier firewall o restricciones de IP existentes, asegúrese de que dev.azure.com y *dev.azure.com estén abiertos y actualice las direcciones IP permitidas para incluir las siguientes direcciones IP, según su versión de IP. Si actualmente permite enumerar las direcciones IP 13.107.6.183 y 13.107.9.183, déjelas en su lugar, ya que no es necesario quitarlas.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Nota:

Este procedimiento permite al agente omitir un proxy web. La canalización de compilación y los scripts deben seguir controlando el proxy web para cada tarea y herramienta que se ejecute en la compilación.

Por ejemplo, si usa una tarea de NuGet, debe configurar el proxy web para admitir la omisión de la dirección URL del servidor que hospeda la fuente de NuGet que está usando.

Estoy usando TFS y las direcciones URL de las secciones anteriores no me funcionan. ¿Dónde puedo obtener ayuda?

Configuración y seguridad del sitio web

¿Por qué no veo algunas de estas características en mi instancia local de Azure DevOps Server?

Algunas de estas características solo están disponibles en Azure DevOps Services y no están disponibles para Azure DevOps Server local. Algunas características solo están disponibles en la versión más reciente de Azure DevOps Server.

Requisitos previos para TFVC

Si va a usar TFVC, también necesitará Oracle Java JDK 1.6 o una versión posterior. (Oracle JRE y OpenJDK no son suficientes para este propósito).

El complemento TEE se usa para la funcionalidad de TFVC. Tiene un CLUF, que debes aceptar durante la configuración si piensas trabajar con TFVC.

Puesto que el complemento TEE ya no se mantiene y contiene algunas dependencias de Java obsoletas, a partir del Agente 2.198.0 ya no se incluye en la distribución del agente. Sin embargo, el complemento TEE se descargará durante la ejecución de la tarea de restauración si está restaurando un repositorio TFVC. El complemento TEE se quitará después de la ejecución del trabajo.

Nota:

Nota: Es posible que observe que la tarea de pago tarda mucho tiempo en comenzar a ejecutarse debido a este mecanismo de descarga.

Si el agente se ejecuta detrás de un proxy o un firewall, debe garantizar el acceso al siguiente sitio: https://vstsagenttools.blob.core.windows.net/. El complemento TEE se descargará desde esta dirección.

Si usa un agente autohospedado y tiene problemas con la descarga de TEE, puede instalar TEE manualmente:

  1. Establezca el entorno DISABLE_TEE_PLUGIN_REMOVAL o la variable de canalización en true. Esta variable impide que el agente quite el complemento TEE después de la finalización de la restauración de TFVC.
  2. Descargue manualmente la versión 14.135.0 de TEE-CLC desde las versiones en GitHub de Team Explorer Everywhere.
  3. Extraiga el contenido de la carpeta TEE-CLC-14.135.0 en <agent_directory>/externals/tee.