Agentes Linux auto-hospedados

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

Este artigo fornece diretrizes para usar o software do agente 3.x com o Azure DevOps Services e as versões atuais do Azure DevOps Server. Para obter uma lista das versões do Servidor do Azure DevOps que dão suporte ao agente 3.x, consulte O Servidor do Azure DevOps dá suporte ao agente 3.x.

Para executar seus trabalhos, você precisa de pelo menos um agente. Um agente do Linux pode criar e implantar diferentes tipos de aplicativos, incluindo aplicativos Java e Android. Consulte Verificar pré-requisitos para obter uma lista de distribuições do Linux com suporte.

Observação

Este artigo descreve como configurar um agente auto-hospedado . Se você estiver usando o Azure DevOps Services e um agente hospedado pela Microsoft atender às suas necessidades, poderá ignorar a configuração de um agente Linux auto-hospedado.

Saiba mais sobre agentes

Se você já sabe o que é um agente e como ele funciona, fique à vontade para ir direto para as seções a seguir. Mas se você quiser mais informações sobre o que eles fazem e como eles funcionam, consulte Azure Pipelines agents.

Verificar pré-requisitos

O agente é baseado no .NET 6. Você pode executar esse agente em várias distribuições do Linux. Damos suporte ao seguinte subconjunto de distribuições compatíveis com o .NET 6:

• Distribuições com suporte
  • x64
    • Debian 10+
    • Fedora 36+
    • openSUSE 15+
    • Red Hat Enterprise Linux 7+
      • Não requer mais pacote separado
    • SUSE Enterprise Linux 12 SP2 ou posterior
    • Ubuntu 22.04, 20.04, 18.04, 16.04
    • Azure Linux 2.0
    • Oracle Linux 7 e superior
  • ARM64
    • Debian 10+
    • Ubuntu 22.04, 20.04, 18.04
  • Alpino x64
    • Alpine Linux 3.13 e superior (requer agente 3.227 ou superior)
• Git – Independentemente da plataforma, você precisa instalar o Git 2.9.0 ou superior. É altamente recomendável instalar a versão mais recente do Git.
• .NET – o software do agente é executado no .NET 6, mas instala sua própria versão do .NET para que não haja nenhum pré-requisito do .NET.
• Subversão – Se você estiver criando a partir de um repositório de Subversão, deverá instalar o cliente subversion no computador.
• TFVC – Se você estiver criando a partir de um repositório TFVC, confira Pré-requisitos do TFVC.

Observação

O instalador do agente sabe como verificar se há outras dependências. Você pode instalar essas dependências em plataformas Linux com suporte executando ./bin/installdependencies.sh no diretório do agente.

Lembre-se de que algumas dessas dependências exigidas pelo .NET são buscadas de sites de terceiros, como packages.efficios.com. Examine o installdependencies.sh script e verifique se os sites de terceiros referenciados estão acessíveis no computador Linux antes de executar o script.

Verifique também se todos os repositórios necessários estão conectados ao gerenciador de pacotes relevante usado em installdependencies.sh (como apt ou zypper).

Para problemas com a instalação de dependências (como 'a dependência não foi encontrada no repositório' ou 'problema ao recuperar o arquivo de índice do repositório') – você pode entrar em contato com o proprietário da distribuição para obter mais suporte.

Você deve executar a instalação do agente manualmente na primeira vez. Depois de ter uma ideia de como os agentes funcionam ou se você quiser automatizar a configuração de muitos agentes, considere usar configuração não supervisionada.

Preparar permissões

Segurança da informação para agentes auto-hospedados

O usuário que configura o agente precisa de permissões de administrador do pool, mas o usuário que executa o agente não.

As pastas controladas pelo agente devem ser restritas ao menor número possível de usuários, pois contêm segredos que podem ser descriptografados ou exfiltrados.

O agente do Azure Pipelines é um produto de software projetado para executar o código baixado de fontes externas. Ele inerentemente pode ser um destino para ataques de RCE (Execução remota de código).

Portanto, é importante considerar o modelo de ameaça em torno de cada uso individual de Agentes de Pipelines para executar o trabalho e decidir quais são as permissões mínimas que podem ser concedidas ao usuário que executa o agente, para o computador em que o agente é executado, para os usuários que têm acesso de gravação à definição de Pipeline, os repositórios git em que o yaml está armazenado, ou o grupo de usuários que controlam o acesso ao pool para novos pipelines.

É uma prática recomendada fazer com que a identidade que executa o agente seja diferente da identidade que tem permissões para conectar o agente ao pool. O usuário que gera as credenciais (e outros arquivos relacionados ao agente) é diferente do usuário que precisa lê-las. Portanto, é mais seguro considerar cuidadosamente o acesso permitido ao computador do agente propriamente dito, e às pastas de agente que contêm arquivos confidenciais, como logs e artefatos.

Faz sentido conceder acesso à pasta do agente somente para administradores de DevOps e a identidade do usuário que executa o processo do agente. Os administradores podem precisar investigar o sistema de arquivos para entender as falhas de build ou obter arquivos de log para poder relatar falhas do Azure DevOps.

Decidir qual usuário você usará

Como uma etapa única, você deve registrar o agente. Alguém com permissão para administrar a fila de agentes precisa concluir essas etapas. O agente não usará as credenciais dessa pessoa na operação diária, mas será necessário concluir o registro. Saiba mais sobre como os agentes se comunicam.

Confirmar se o usuário tem permissão

Verifique se a conta de usuário que você usará tem permissão para registrar o agente.

O usuário é um proprietário da organização do Azure DevOps ou administrador do TFS ou do Azure DevOps Server? Parar aqui, você tem permissão.

Caso contrário:

1. Abra um navegador e navegue até a guia Pools de agentes para sua organização do Azure Pipelines ou Azure DevOps Server ou servidor TFS:

   1. Entre em sua organização (https://dev.azure.com/{yourorganization}).

   2. Escolha Azure DevOps, Configurações da organização.

      

   3. Escolha Pools de agentes.

      

2. Selecione o pool no lado direito da página e clique em Segurança.

3. Se a conta de usuário que você vai usar não for mostrada, obtenha um administrador para adicioná-la. O administrador pode ser um administrador do pool de agentes, um proprietário da organização do Azure DevOps ou um administrador do TFS ou do Azure DevOps Server .

   Se for um agente do grupo de implantação , o administrador poderá ser um administrador do grupo de implantação, um proprietário da organização do Azure DevOpsou um administrador do TFS ou do Azure DevOps Server.

   Você pode adicionar um usuário à função de administrador do grupo de implantação na guia Segurança na página Grupos de Implantação no Azure Pipelines.

Observação

Se você vir uma mensagem como esta: Desculpe, não foi possível adicionar a identidade. Tente uma identidade diferente., você provavelmente seguiu as etapas acima para um proprietário da organização ou administrador do TFS ou do Azure DevOps Server. Você não precisa fazer nada; você já tem permissão para administrar o pool de agentes.

Baixar e configurar o agente

Azure Pipelines (Pipelines de Distribuição do Azure)

1. Faça logon no computador usando a conta para a qual você preparou permissões, conforme explicado na seção anterior.

2. No navegador da Web, entre no Azure Pipelines e navegue até a guia Pools de agentes:

   1. Entre em sua organização (https://dev.azure.com/{yourorganization}).

   2. Escolha Azure DevOps, Configurações da organização.

      

   3. Escolha Pools de agentes.

      

3. Selecione o pool Padrão, selecione a guia Agentes e escolha Novo agente.

4. Na caixa de diálogo Obter o agente , clique em Linux.

5. No painel esquerdo, selecione o sabor específico. Oferecemos x64 ou ARM para muitas distribuições do Linux.

6. No painel direito, clique no botão Baixar .

7. Siga as instruções na página.
   

8. Desempacote o agente no diretório de sua escolha. cd para esse diretório e execute ./config.sh.

URL do servidor

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

Tipo de autenticação

Quando você registrar um agente, escolha entre os seguintes tipos de autenticação e a instalação do agente solicitará as informações adicionais específicas necessárias para cada tipo de autenticação. Para obter mais informações, consulte Opções de autenticação de agente auto-hospedado.

• Token de acesso pessoal
• Fluxo de código do dispositivo
• Entidade de serviço

Executar de maneira interativa

Para obter orientação sobre se o agente deve ser executado no modo interativo ou como um serviço, consulte Agents: Interactive vs. service.

Para executar o agente interativamente:

1. Se você estiver executando o agente como um serviço, desinstale o serviço.

2. Execute o agente.

   ./run.sh
   

Para reiniciar o agente, pressione Ctrl+C e execute run.sh para reiniciá-lo.

Para usar seu agente, execute um trabalho usando o pool do agente. Se você não escolheu um pool diferente, seu agente é colocado no pool Padrão.

Executar uma vez

Para agentes configurados para serem executados interativamente, você pode optar por fazer com que o agente aceite apenas uma tarefa. Para executar nesta configuração:

./run.sh --once

Os agentes nesse modo aceitam apenas um trabalho e, em seguida, giram normalmente (útil para execução no Docker em um serviço como Instâncias de Contêiner do Azure).

Executar como um serviço systemd

Se o agente estiver em execução nesses sistemas operacionais, você poderá executar o agente como um systemd serviço:

• Ubuntu 16 LTS ou mais recente
• Red Hat 7.1 ou mais recente

Fornecemos um script de exemplo ./svc.sh para que você execute e gerencie seu agente como um systemd serviço. Esse script será gerado depois que você configurar o agente. Recomendamos que você examine e, se necessário, atualize o script antes de executá-lo.

Algumas advertências importantes:

• Se você executar o agente como um serviço, não poderá executar o serviço do agente como usuário root.
• Os usuários que executam o SELinux relataram dificuldades com o script fornecido svc.sh . Considere esse problema do agente como um ponto de partida. O SELinux não é uma configuração com suporte oficial.

Observação

Se você tiver uma distribuição diferente ou preferir outras abordagens, poderá usar qualquer tipo de mecanismo de serviço que preferir. Confira Arquivos do serviço.

Comandos

Alterar para o diretório do agente

Por exemplo, se você tiver instalado na subpasta myagent do diretório base:

cd ~/myagent$

Instalar

Comando:

sudo ./svc.sh install [username]

Esse comando cria um arquivo de serviço que aponta para ./runsvc.sh. Esse script configura o ambiente (mais detalhes abaixo) e inicia o host dos agentes. Se username o parâmetro não for especificado, o nome de usuário será retirado da variável de ambiente $SUDO_USER definida pelo comando sudo. Essa variável é sempre igual ao nome do usuário que invocou o sudo comando.

Começar

sudo ./svc.sh start

Situação

sudo ./svc.sh status

Parar

sudo ./svc.sh stop

Desinstalar

Você deve parar antes de desinstalar.

sudo ./svc.sh uninstall

Atualizar variáveis de ambiente

Quando você configura o serviço, ele tira um instantâneo de algumas variáveis de ambiente úteis para o usuário atualmente logado, como PATH, LANG, JAVA_HOME, ANT_HOME e MYSQL_PATH. Se você precisar atualizar as variáveis (por exemplo, depois de instalar algum novo software):

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

O snapshot das variáveis de ambiente é armazenado no arquivo .env (PATH é armazenado em .path) no diretório raiz do agente. Além disso, você pode alterar esses arquivos diretamente para aplicar mudanças nas variáveis de ambiente.

Executar instruções antes do início do serviço

Você também pode definir suas próprias instruções e comandos a serem executados quando o serviço for iniciado. Por exemplo, você pode configurar o ambiente ou chamar scripts.

1. Edite runsvc.sh.

2. Substitua a seguinte linha por suas instruções:

   # insert anything to setup env when running as a service
   

Arquivos de serviço

Quando você instala o serviço, alguns arquivos de serviço são colocados.

arquivo de serviço systemd

Um systemd arquivo de serviço é criado:

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

Por exemplo, você configurou um agente (veja acima) com o nome our-linux-agent. O arquivo de serviço será um dos seguintes:

• Azure Pipelines: o nome da sua organização. Por exemplo, se você se conectar a https://dev.azure.com/fabrikam, o nome do serviço será /etc/systemd/system/vsts.agent.fabrikam.our-linux-agent.service

• TFS ou Servidor do Azure DevOps: o nome do servidor local. Por exemplo, se você se conectar a http://our-server:8080/tfs, o nome do serviço será /etc/systemd/system/vsts.agent.our-server.our-linux-agent.service

sudo ./svc.sh install gera esse arquivo a partir deste modelo: ./bin/vsts.agent.service.template

Arquivo .service

sudo ./svc.sh start localiza o serviço lendo o arquivo .service, que contém o nome do arquivo de serviço systemd descrito acima.

Mecanismos de serviço alternativos

Fornecemos o ./svc.sh script como uma maneira conveniente de executar e gerenciar seu agente como um serviço sistemado. Mas você pode usar qualquer tipo de mecanismo de serviço que preferir (por exemplo: initd ou upstart).

Você pode usar o modelo descrito acima para facilitar a geração de outros tipos de arquivos de serviço.

Usar um cgroup para evitar falha do agente

É importante evitar situações em que o agente falhe ou se torne inutilizável porque, caso contrário, o agente não poderá transmitir os logs do pipeline ou relatar o status do pipeline ao servidor. Você pode reduzir o risco de que este tipo de problema seja causado por alta pressão de memória, utilizando cgroups e um oom_score_adj menor. Depois de fazer isso, o Linux recupera a memória do sistema de processos de trabalho de pipeline antes de recuperar a memória do processo do agente. Saiba como configurar cgroups e a pontuação OOM.

Substituir um agente

Para substituir um agente, siga novamente as etapas de Baixar e configurar o agente.

Ao configurar um agente usando o mesmo nome de um agente que já existe, você será perguntado se deseja substituir o agente existente. Se você responder Y, remova o agente (veja abaixo) que você está substituindo. Caso contrário, após alguns minutos de conflitos, um dos agentes será desligado.

Remover e reconfigurar um agente

Para remover o agente:

1. Pare e desinstale o serviço, conforme explicado na seção anterior.

2. Remova o agente.

   ./config.sh remove
   

3. Insira suas credenciais.

Depois de remover o agente, você pode configurá-lo novamente.

Configuração autônoma

O agente pode ser configurado a partir de um script sem intervenção humana. Você deve passar --unattended e as respostas para todas as perguntas.

Para configurar um agente, ele deve saber a URL para sua organização ou coleção e credenciais de alguém autorizado a configurar agentes. Todas as outras respostas são opcionais. Qualquer parâmetro de linha de comando pode ser especificado usando uma variável de ambiente: coloque seu nome em maiúsculas e adicione VSTS_AGENT_INPUT_como prefixo. Por exemplo, VSTS_AGENT_INPUT_PASSWORD em vez de especificar --password.

Opções necessárias

• --unattended - a instalação do agente não solicitará informações e todas as configurações devem ser fornecidas na linha de comando
• --url <url> – URL do servidor. Por exemplo: https://dev.azure.com/myorganization ou http://my-azure-devops-server:8080/tfs
• --auth <type> - tipo de autenticação. Os valores válidos são:
  • pat (token de acesso pessoal) – PAT é o único esquema que funciona com o Azure DevOps Services.
  • alt (autenticação básica)

Opções de autenticação

• Se você escolheu --auth pat:
  • --token <token> – especifica seu token de acesso pessoal
  • PAT é o único esquema que funciona com o Azure DevOps Services.
• Se você escolheu --auth negotiate ou --auth alt:
  • --userName <userName> – especifica um nome de usuário
  • --password <password> – especifica uma senha

Nomes de pool e de agente

• --pool <pool> – nome do pool para o agente ingressar
• --agent <agent> - nome do agente
• --replace – substituir o agente em um pool. Se outro agente estiver escutando com o mesmo nome, ele começará a falhar com um conflito

Configuração do agente

• --work <workDirectory> – diretório de trabalho em que os dados do trabalho são armazenados. Usa _work por padrão, na raiz do diretório do agente. O diretório de trabalho pertence a um determinado agente e não deve ser compartilhado entre vários agentes.
• --acceptTeeEula – aceitar o Contrato de Licença do Usuário Final do Team Explorer Everywhere (somente para macOS e Linux)
• --disableloguploads - não transmita nem envie saída de log do console para o servidor. Em vez disso, você pode recuperá-los do sistema de arquivos do host do agente após a conclusão do trabalho.

Somente grupo de implantação

• --deploymentGroup – configurar o agente como um agente de grupo de implantação
• --deploymentGroupName <name> - usado com --deploymentGroup para especificar o grupo de implantação ao qual o agente deve se juntar
• --projectName <name> - usado com --deploymentGroup para definir o nome do projeto
• --addDeploymentGroupTags – usado com --deploymentGroup para indicar que as tags de grupo de implantação devem ser adicionadas
• --deploymentGroupTags <tags> - usado com --addDeploymentGroupTags para especificar a lista separada por vírgulas de tags para o agente do grupo de implantação - por exemplo "web, db"

Somente ambientes

• --addvirtualmachineresourcetags - usado para indicar que tags de recursos do ambiente devem ser adicionadas
• --virtualmachineresourcetags <tags> - usado com --addvirtualmachineresourcetags para especificar a lista separada por vírgulas de tags para o agente de recursos de ambiente - por exemplo "web, db"

./config.sh --help sempre lista as respostas mais recentes necessárias e opcionais.

Diagnósticos

Se você estiver tendo problemas com seu agente auto-hospedado, tente executar o diagnóstico. Depois de configurar o agente:

./run.sh --diagnostics

Isso será executado por meio de um pacote de diagnóstico que pode ajudá-lo a solucionar o problema. O recurso de diagnóstico está disponível a partir da versão 2.165.0 do agente.

Diagnóstico de rede para agentes auto-hospedados

Defina o valor de Agent.Diagnostic para true coletar logs adicionais que podem ser usados para solucionar problemas de rede para agentes auto-hospedados. Para obter mais informações,confira Diagnóstico de rede para agentes auto-hospedados.

Ajuda sobre outras opções

Para saber mais sobre outras opções:

./config.sh --help

A ajuda fornece informações sobre alternativas de autenticação e configuração autônoma.

Capacidades

Os recursos do agente são catalogados e anunciados no pool para que apenas os builds e lançamentos que ele possa manipular sejam atribuídos a ele. Confira Funcionalidades do agente de build e lançamento.

Em muitos casos, depois de implantar um agente, você precisará instalar software ou utilitários. Geralmente, você deve instalar em seus agentes qualquer software e ferramentas usadas em seu computador de desenvolvimento.

Por exemplo, se o build incluir a tarefa npm, o build não será executado, a menos que haja um agente de build no pool que tenha o npm instalado.

Importante

As capacidades incluem todas as variáveis de ambiente e os valores definidos quando o agente é executado. Se qualquer um desses valores for alterado enquanto o agente estiver em execução, o agente deverá ser reiniciado para selecionar os novos valores. Depois de instalar um novo software em um agente, você deve reiniciar o agente para que o novo recurso apareça no pool, para que o build possa ser executado.

Se você quiser excluir variáveis de ambiente como funcionalidades, poderá designá-las definindo uma variável de ambiente VSO_AGENT_IGNORE com uma lista delimitada por vírgulas de variáveis a serem ignoradas.

Perguntas Freqüentes

Onde posso saber mais sobre o novo software do agente v3?

Para obter informações e perguntas frequentes sobre o software do agente v3, consulte o software agent versão 3.

Como fazer ter certeza de que tenho a versão mais recente do agente?

1. Navegue até a guia Pools de agentes:

   1. Entre em sua organização (https://dev.azure.com/{yourorganization}).

   2. Escolha Azure DevOps, Configurações da organização.

      

   3. Escolha Pools de agentes.

      

2. Clique no pool que contém o agente.

3. Verifique se o agente está habilitado.

4. Navegue até a guia funcionalidades:

   1. Na guia Pools de agentes, selecione o pool de agentes desejado.

      

   2. Selecione Agentes e escolha o agente desejado.

      

   3. Selecione a guia Funcionalidades.

      

      Observação

      Os agentes hospedados pela Microsoft não exibem recursos do sistema. Para obter uma lista de software instalado em agentes hospedados pela Microsoft, consulte Usar um agente hospedado pela Microsoft.

5. Procure a funcionalidade Agent.Version. Você pode verificar esse valor em relação à versão publicada mais recente do agente. Confira Agente do Azure Pipelines e confira a página para ver o número de versão mais alto listado.

6. Cada agente se atualiza automaticamente quando executa uma tarefa que requer uma versão mais recente do agente. Se você quiser atualizar manualmente alguns agentes, clique com o botão direito do mouse no pool e selecione Atualizar todos os agentes.

Por que o sudo é necessário para executar os comandos de serviço?

O ./svc.sh usa systemctl, que exige sudo.

Código-fonte: systemd.svc.sh.template no GitHub

Estou executando um firewall e meu código está no Azure Repos. Com quais URLs o agente precisa se comunicar?

Se você estiver executando um agente em uma rede segura atrás de um firewall, verifique se o agente pode iniciar a comunicação com as SEGUINTEs URLs e endereços IP.

URL do Domínio	Descrição
https://{organization_name}.pkgs.visualstudio.com	API de Empacotamento do Azure DevOps para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.visualstudio.com	Para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vsblob.visualstudio.com	Telemetria do Azure DevOps para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com	Serviços de Gerenciamento de Versão para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com	Azure DevOps Platform Services para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com	Serviços de Gerenciamento de Teste do Azure DevOps para organizações que usam o domínio {organization_name}.visualstudio.com
https://*.blob.core.windows.net	Artefatos do Azure
https://*.dev.azure.com	Para organizações que usam o domínio dev.azure.com
https://*.vsassets.io	Azure Artifacts por meio de CDN
https://*.vsblob.visualstudio.com	Telemetria do Azure DevOps para organizações que usam o domínio dev.azure.com
https://*.vssps.visualstudio.com	Azure DevOps Platform Services para organizações que usam o domínio dev.azure.com
https://*.vstmr.visualstudio.com	Serviços de Gerenciamento de Teste do Azure DevOps para organizações que usam o domínio dev.azure.com
https://app.vssps.visualstudio.com	Para organizações que usam o domínio {organization_name}.visualstudio.com
https://dev.azure.com	Para organizações que usam o domínio dev.azure.com
https://login.microsoftonline.com	Login do Microsoft Entra
https://management.core.windows.net	APIs de Gerenciamento do Azure
https://download.agent.dev.azure.com	Pacote do agente

Importante

A CDN do Edgio para Azure DevOps foi desativada, o que exige que uma nova URL de domínio seja listada em regras de firewall para download de software do agente. O novo domínio para permitir a lista de download do agente é https://*.dev.azure.com. Se as regras de firewall não permitirem curingas, use https://download.agent.dev.azure.com.

A equipe do Azure DevOps recomenda fazer essa alteração até a seguinte data:

• 1º de maio de 2025 para o Azure DevOps Services
• 15 de maio de 2025 para o Azure DevOps Server

Para obter mais informações, consulte Alteração da URL do domínio CDN para agentes em pipelines.

Para garantir que sua organização funcione com quaisquer restrições de IP ou firewall existentes, certifique-se de que dev.azure.com e *dev.azure.com estejam abertos e atualize seus IPs permitidos para incluir os seguintes endereços IP, com base em sua versão de IP. Se você estiver atualmente permitindo a listagem dos endereços IP 13.107.6.183 e 13.107.9.183, deixe-os no local, pois você não precisa removê-los.

Faixas de IP V4

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

Intervalos de IP V6

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Observação

Para obter mais informações sobre endereços permitidos, consulte Listas de endereços permitidas e conexões de rede.

Como fazer para executar o agente com um certificado autoassinado?

Executar o agente com um certificado autoassinado

Como fazer para executar o agente por trás de um proxy Web?

Executar o agente por trás de um proxy Web

Como reiniciar o agente

Se você estiver executando o agente interativamente, consulte as instruções de reinicialização em Executar interativamente. Se você estiver executando o agente como um serviço systemd, siga as etapas para Parar e em seguida, Iniciar o agente.

Como configurar o agente para ignorar um proxy Web e conectar-se ao Azure Pipelines?

Se você quiser que o agente ignore seu proxy e se conecte diretamente ao Azure Pipelines, configure seu proxy Web para permitir que o agente acesse as URLs a seguir.

Para organizações que usam o domínio *.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 organizações que usam o domínio 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 garantir que sua organização funcione com quaisquer restrições de IP ou firewall existentes, certifique-se de que dev.azure.com e *dev.azure.com estejam abertos e atualize seus IPs permitidos para incluir os seguintes endereços IP, com base em sua versão de IP. Se você estiver atualmente permitindo a listagem dos endereços IP 13.107.6.183 e 13.107.9.183, deixe-os no local, pois você não precisa removê-los.

Faixas de IP V4

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

Intervalos de IP V6

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Observação

Esse procedimento permite que o agente ignore um proxy Web. O pipeline de build e os scripts ainda precisam lidar com o bypass do proxy Web para cada tarefa e ferramenta executada em seu build.

Por exemplo, se você estiver usando uma tarefa NuGet, deverá configurar seu proxy Web para dar suporte a ignorar a URL do servidor que hospeda o feed NuGet que você está usando.

Pré-requisitos do TFVC

Se você estiver usando o TFVC, também precisará do Oracle Java JDK 1.6 ou superior. (O Oracle JRE e o OpenJDK não são suficientes para essa finalidade.)

O plug-in TEE é usado para a funcionalidade do TFVC. Ele tem um EULA, que você precisa aceitar durante a configuração se planeja trabalhar com o TFVC.

Como o plug-in do TEE não é mais mantido e contém algumas dependências java desatualizadas, a partir do Agente 2.198.0, ele não está mais incluído na distribuição do agente. No entanto, o plug-in TEE será baixado durante a execução da tarefa de check-out se você estiver fazendo check-out de um repositório TFVC. O plug-in do TEE será removido após a execução do trabalho.

Observação

Observação: você pode observar que sua tarefa de check-out está demorando muito para começar a funcionar devido a esse mecanismo de download.

Se o agente estiver em execução atrás de um proxy ou um firewall, você precisará garantir o acesso ao seguinte site: https://vstsagenttools.blob.core.windows.net/. O plug-in do TEE será baixado desse endereço.

Se você estiver usando um agente auto-hospedado e enfrentando problemas com o download do TEE, poderá instalar o TEE manualmente:

1. Defina a variável de pipeline ou ambiente DISABLE_TEE_PLUGIN_REMOVAL como true. Essa variável impede que o agente remova o plug-in do TEE após o check-out do repositório TFVC.
2. Baixe o TEE-CLC versão 14.135.0 manualmente de Versões do GitHub do Team Explorer Everywhere.
3. Extraia o conteúdo da pasta TEE-CLC-14.135.0 para <agent_directory>/externals/tee.