Partilhar via

Agentes Linux auto-hospedados

Serviços de DevOps do Azure | Azure DevOps Server 2022 | Azure DevOps Server 2020

Este artigo fornece orientação para usar o software de agente 4.x com os Serviços de DevOps do Azure.

Este artigo fornece orientação para usar o software de agente 3.x com o Azure DevOps Server. Para obter uma lista das versões do Servidor de DevOps do Azure que suportam o agente 3.x, consulte O Servidor de DevOps do Azure suporta o agente 3.x.

Importante

Se você estiver usando os Serviços de DevOps do Azure, deverá usar o software de agente 4.x.

Para executar seus trabalhos, você precisa de pelo menos um agente. Um agente 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 Linux suportadas.

Observação

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

Saiba mais sobre os agentes

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

Verificar pré-requisitos

O agente é baseado no .NET 6. Você pode executar este agente em várias distribuições Linux. Suportamos o seguinte subconjunto de distribuições suportadas do .NET 6:

  • Distribuições suportadas
    • 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 24.04, 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
  • Git - Independentemente da sua 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.
  • Subversion - Se você estiver criando a partir de um repositório Subversion, deverá instalar o cliente Subversion na máquina.
  • TFVC - Se você estiver criando a partir de um repositório TFVC, consulte pré-requisitos do TFVC.

Observação

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

Lembre-se de que algumas dessas dependências exigidas pelo .NET são obtidas em sites de terceiros, como packages.efficios.com. Revise o installdependencies.sh script e certifique-se de que todos os sites de terceiros referenciados estejam acessíveis a partir de sua máquina Linux antes de executar o script.

Certifique-se também de que 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 '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 suporte adicional.

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

Preparar permissões

Segurança da informação para agentes hospedados localmente

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 porque 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 alvo para ataques de Execução Remota de Código (RCE).

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, à máquina onde o agente é executado, aos usuários que têm acesso de gravação à definição de Pipeline, os repositórios git onde o yaml está armazenado, ou o grupo de usuários que controlam o acesso ao pool para novos pipelines.

É uma prática recomendada que a identidade que executa o agente seja diferente daquela que possui 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 concedido à própria máquina do agente e às pastas do 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 compilação ou obter arquivos de log para poder relatar falhas do Azure DevOps.

Decida 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 deve concluir essas etapas. O agente não usará as credenciais dessa pessoa na operação diária, mas elas são necessárias para concluir o registo. Saiba mais sobre como os agentes se comunicam.

Confirme se o usuário tem permissão

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

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

Caso contrário:

  1. Abra um navegador e navegue até ao separador Pools de Agentes da sua organização do Azure Pipelines, Azure DevOps Server ou servidor TFS.

    1. Inicie sessão na sua organização (https://dev.azure.com/{yourorganization}).

    2. SelecioneConfigurações da Organização>.

      Captura de tela que mostra como selecionar Configurações da organização.

    3. Selecione Pools de agentes.

      Captura de tela que mostra como selecionar a guia Pools de agentes.

    1. Inicie sessão na sua coleção de projetos (http://your-server/DefaultCollection).

    2. Selecione Azure DevOps>Configurações da Coleção.

      Captura de tela que mostra como selecionar Configurações de coleção.

    3. Selecione Pools de agentes.

      Selecione Pools de agentes.

    Captura de tela que mostra como aceder e selecionar grupos 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, peça a 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 de grupo de implantação, o administrador pode ser um administrador de grupo de implantação, um proprietário de organização do Azure DevOps ou 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 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 de 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 do Azure)

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

  2. No seu navegador da Web, inicie sessão no Azure Pipelines e navegue até ao separador Pools de Agentes:

    1. Inicie sessão na sua organização (https://dev.azure.com/{yourorganization}).

    2. SelecioneConfigurações da Organização>.

      Captura de tela que mostra como selecionar Configurações da organização.

    3. Selecione Pools de agentes.

      Captura de tela que mostra como selecionar a guia Pools de agentes.

    1. Inicie sessão na sua coleção de projetos (http://your-server/DefaultCollection).

    2. Selecione Configurações da Coleção do Azure DevOps.

      Captura de tela que mostra como selecionar Configurações de coleção.

    3. Selecione Pools de agentes.

      Selecione Pools de agentes.

    Imagem de ecrã que mostra como aceder e selecionar 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 Linux.

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

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

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

Ao registrar um agente, escolha entre os seguintes tipos de autenticação e a configuraçã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.
  • Alternativa: conecte-se ao Servidor de DevOps do Azure usando a autenticação Básica. Ao selecionar Alternativo, suas credenciais serão solicitadas.

Executar de forma interativa

Para obter orientação sobre se o agente deve ser executado no modo interativo ou como um serviço, consulte Agentes: interativo versus serviço.

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 o seu agente, execute uma tarefa usando o pool do agente. Se você não escolheu um pool diferente, seu agente será colocado no pool Padrão .

Executar uma vez

Para agentes configurados para execução interativa, você pode optar por fazer com que o agente aceite apenas um trabalho. Para executar nesta configuração:

./run.sh --once

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

Executar como serviço systemd

Se o agente estiver sendo executado nestes sistemas operacionais, você poderá executar o agente como um systemd serviço:

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

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

Algumas ressalvas importantes:

  • Se executares o agente como um serviço, não poderás executar o serviço do agente como root utilizador.
  • Os usuários que executam o SELinux relataram dificuldades com o script fornecido svc.sh . Refira-se a este problema do agente como um ponto de partida. O SELinux não é uma configuração oficialmente suportada.

Observação

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

Comandos

Mudar para o diretório do agente

Por exemplo, se você instalou na subpasta myagent do seu diretório base:

cd ~/myagent$

Instalar

Comando:

sudo ./svc.sh install [username]

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

Início

sudo ./svc.sh start

Situação

sudo ./svc.sh status

Parar

sudo ./svc.sh stop

Desinstale

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 seu usuário de logon atual, como PATH, LANG, JAVA_HOME, ANT_HOME e MYSQL_PATH. Se você precisar atualizar as variáveis (por exemplo, depois de instalar algum software novo):

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

O instantâneo das variáveis de ambiente é armazenado no .env ficheiro (PATH é armazenado em .path) no diretório raiz do agente, pode também alterar esses ficheiros diretamente para aplicar alterações das variáveis de ambiente.

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

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

  1. Editar runsvc.sh.

  2. Substitua a seguinte linha pelas instruções:

    # insert anything to setup env when running as a service

Arquivos de serviço

Quando se instala o serviço, alguns arquivos de serviço são instalados.

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á: ou

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

  • TFS ou Azure DevOps Server: o nome do seu servidor local. Por exemplo, se você se conectar ao 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 este arquivo a partir deste modelo: ./bin/vsts.agent.service.template

Arquivo .service

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

Mecanismos de serviço alternativos

Disponibilizamos o script ./svc.sh como uma maneira conveniente para que possa executar e gerir o seu agente como um serviço systemd. 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.

Use um cgroup para evitar falha do agente

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

Substituir um agente

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

Quando você configura um agente usando o mesmo nome de um agente que já existe, você é perguntado se deseja substituir o agente existente. Se responderes Y, certifica-te de remover o agente (veja abaixo) que vais substituir. Caso contrário, após alguns minutos de conflitos, um dos agentes será desativado.

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. Introduza as suas credenciais.

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

Configuração sem supervisão

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

Para configurar um agente, ele deve saber a URL da sua organização ou coleção e as 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: colocar o seu nome em maiúsculas e prefixar VSTS_AGENT_INPUT_. Por exemplo, VSTS_AGENT_INPUT_PASSWORD em vez de especificar --password.

Opções necessárias

  • --unattended - A configuraçã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) - A PAT é o único esquema que funciona com os Serviços de DevOps do Azure.
    • alt (autenticação básica)

Opções de autenticação

  • Se você escolheu --auth pat:
    • --token <token> - especifica o seu token de acesso pessoal
    • A PAT é o único esquema que funciona com os Serviços de DevOps do Azure.
  • 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 agentes

  • --pool <pool> - Nome do pool ao qual o agente deve aderir
  • --agent <agent> - nome do agente
  • --replace - Substitua o agente num pool. Se outro agente estiver a ouvir pelo mesmo nome, isso resultará num conflito.

Configuração do agente

  • --work <workDirectory> - diretório de trabalho onde os dados do trabalho são armazenados. Por padrão, é _work 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 - aceite o Contrato de Licença de Usuário Final do Team Explorer Everywhere (somente macOS e Linux)
  • --disableloguploads - Não transmita ou envie a 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 do grupo de implantação
  • --deploymentGroupName <name> - usado com --deploymentGroup para especificar o grupo de implantação ao qual o agente deve aderir
  • --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 as 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 últimas respostas obrigatórias e opcionais.

Diagnóstico

Se estiver a ter problemas com o seu agente autónomo, pode tentar executar diagnósticos. Depois de configurar o agente:

./run.sh --diagnostics

Isto será executado através de uma suíte de diagnósticos que pode ajudá-lo a resolver 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 para recolher logs adicionais que podem ser usados para solucionar problemas de rede de agentes autogeridos. Para obter mais informações, consulte Diagnóstico de rede para agentes autogeridos.

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 não supervisionada.

Capacidades

As capacidades do seu agente são catalogadas e divulgadas no pool, de modo que apenas as compilações e versões que ele pode gerir sejam atribuídas a ele. Consulte Capacidades do agente de compilação 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 que você usa em sua máquina de desenvolvimento.

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

Importante

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

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

FAQ

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

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

Como posso assegurar-me de que tenho a versão mais recente do agente?

  1. Navegue até ao separador Pools de agentes:

    1. Inicie sessão na sua organização (https://dev.azure.com/{yourorganization}).

    2. SelecioneConfigurações da Organização>.

      Captura de tela que mostra como selecionar Configurações da organização.

    3. Selecione Pools de agentes.

      Captura de tela que mostra como selecionar a guia Pools de agentes.

    1. Inicie sessão na sua coleção de projetos (http://your-server/DefaultCollection).

    2. Selecione Configurações da Coleção de DevOps> do Azure.

      Captura de tela que mostra como selecionar Configurações de coleção.

    3. Selecione Pools de agentes.

      Selecione Pools de agentes.

    Captura de ecrã que mostra como aceder e selecionar pools de agentes.

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

  3. Verifique se o agente está habilitado.

  4. Navegue até a guia de recursos:

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

      Em Pools de agentes, selecione o pool de agentes desejado.

    2. Selecione Agentes e escolha o agente desejado.

      Selecione Agentes e escolha o agente.

    3. Escolha o separador Capacidades.

      Escolha a guia Recursos.

      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.

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

      Selecione o pool desejado.

    2. Selecione Agentes e escolha o agente desejado.

      Selecione Agentes e escolha o agente desejado.

    3. Escolha o separador Capacidades.

      Guia de Capacidades do Agente.

  5. Verifique a Agent.Version capacidade. Você pode verificar esse valor em relação à versão do agente mais recente publicada. Consulte Azure Pipelines Agent e verifique na página o número da versão mais alta listado.

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

Posso atualizar meus agentes que fazem parte de um pool do Azure DevOps Server?

Sim. A partir do Azure DevOps Server 2019, você pode configurar seu servidor para procurar os arquivos do pacote do agente em um disco local. Essa configuração substituirá a versão padrão que acompanhava o servidor no momento de seu lançamento. Esse cenário também se aplica quando o servidor não tem acesso à Internet.

  1. A partir de um computador com acesso à Internet, descarregue a versão mais recente dos ficheiros do pacote do agente (no formato .zip ou .tar.gz) a partir da página de Lançamentos do GitHub do Azure Pipelines Agent.

  2. Transfira os arquivos de pacote baixados para cada Camada de Aplicativo do Servidor de DevOps do Azure usando um método de sua escolha (como unidade USB, transferência de rede e assim por diante). Coloque os arquivos do agente na seguinte pasta:

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

Crie a pasta Agentes se ela não estiver presente.

  1. Está tudo pronto! Seu Servidor de DevOps do Azure agora usará os arquivos locais sempre que os agentes forem atualizados. Cada agente se atualiza automaticamente quando executa uma tarefa que requer uma versão mais recente do agente. Mas se você quiser atualizar manualmente alguns agentes, clique com o botão direito do mouse no pool e escolha Atualizar todos os agentes.

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

./svc.sh utiliza systemctl, o que requer 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, certifique-se de que o agente possa iniciar a comunicação com os seguintes URLs e endereços IP.

URL do domínio Descrição
https://{organization_name}.pkgs.visualstudio.com Azure DevOps Packaging API 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 de DevOps do Azure para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com Release Management Services para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com Serviços da Plataforma Azure DevOps para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com Serviços de Gerenciamento de Teste de DevOps do Azure 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 Artefactos do Azure via CDN
https://*.vsblob.visualstudio.com Telemetria de DevOps do Azure para organizações que usam o domínio dev.azure.com
https://*.vssps.visualstudio.com Serviços da Plataforma Azure DevOps para organizações que usam o domínio dev.azure.com
https://*.vstmr.visualstudio.com Serviços de Gerenciamento de Teste de DevOps do Azure 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 Iniciar sessão no Microsoft Entra
https://management.core.windows.net APIs de Gerenciamento do Azure
https://download.agent.dev.azure.com Pacote do agente

Importante

O Edgio CDN para Azure DevOps foi desativado, o que requer que uma nova URL de domínio seja permitida nas regras de firewall para download de software do agente. O novo domínio a incluir na lista de permissões para o download do agente é https://*.dev.azure.com. Se as regras de firewall não permitirem caracteres universais, 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 os Serviços de DevOps do Azure
  • 15 de maio de 2025 para o Azure DevOps Server

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

Para garantir que sua organização funcione com qualquer firewall ou restrições de IP 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 na sua versão de IP. Se, no momento, estiver a autorizar a lista dos endereços IP 13.107.6.183 e 13.107.9.183, mantenha-os, como não precisa de os remover.


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

Observação

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

Como posso executar o agente com certificado autoassinado?

Execute o agente com certificado autoassinado

Como executar o agente através de um proxy da Web?

Executar o agente por intermédio de um proxy web

Como faço para reiniciar o agente

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

Como configuro o agente para ignorar um proxy da Web e me conectar ao Azure Pipelines?

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

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 qualquer firewall ou restrições de IP 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 na sua versão de IP. Se, no momento, estiver a autorizar a lista dos endereços IP 13.107.6.183 e 13.107.9.183, mantenha-os, como não precisa de os remover.


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

Observação

Este procedimento permite que o agente ignore um proxy da Web. O seu conjunto de compilação e scripts ainda devem tratar de contornar o seu proxy da Web para cada tarefa e ferramenta que executa no conjunto de compilação.

Por exemplo, se estiveres a usar uma tarefa NuGet, deves configurar o teu proxy da Web para ignorar a URL do servidor que hospeda o feed do NuGet que estás a usar.

Estou usando o TFS e as URLs nas seções acima não funcionam para mim. Onde posso obter ajuda?

Configurações e segurança do site

Por que não vejo alguns desses recursos no meu Azure DevOps Server local?

Alguns desses recursos estão disponíveis somente nos Serviços de DevOps do Azure e não estão disponíveis para o Servidor de DevOps do Azure local. Alguns recursos estão disponíveis somente na versão mais recente do Azure DevOps Server.

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 plugin TEE é usado para a funcionalidade TFVC. Ele tem um EULA, que você precisa aceitar durante a configuração se você planeja trabalhar com TFVC.

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

Observação

Nota: Você pode notar que sua tarefa de checkout está demorando muito para começar a funcionar devido a esse mecanismo de download.

Se o agente estiver sendo executado atrás de um proxy ou firewall, você precisará garantir o acesso ao seguinte site: https://vstsagenttools.blob.core.windows.net/. O plugin TEE será descarregado a partir deste endereço.

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

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