Agentes do Windows auto-hospedados

Azure DevOps Services

Para criar e implantar o Windows, o Azure e outras soluções do Visual Studio, você precisará de pelo menos um agente do Windows. Os agentes do Windows também podem criar aplicativos Java e Android.

Este artigo fornece orientações para usar o software de agente 3.x com os Azure DevOps Services e as versões atuais do Azure DevOps Server. Para obter uma lista de versões do Azure DevOps Server que dão suporte ao agente 3.x, consulte O Azure DevOps Server oferece suporte ao agente 3.x.

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, você poderá ignorar a configuração de um agente auto-hospedado do Windows.

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 saber mais sobre o que eles fazem e como eles funcionam, confira Agentes do Azure Pipelines.

Verificar pré-requisitos

Verifique se o computador tem estes pré-requisitos:

• Versão do sistema operacional
  • Sistema Operacional do cliente
    • Windows 7 SP1 ESU
    • Windows 8.1
    • Windows 10
    • Windows 11
  • Sistema Operacional do servidor
    • Windows Server 2012 ou posterior
• O software do agente instala sua própria versão do .NET para que não haja pré-requisitos do .NET.
• PowerShell 3.0 ou posterior
• Subversion – Se você estiver criando a partir de um repositório Subversion, precisará instalar o cliente Subversion no computador.
• Recomendado – Ferramentas de build do Visual Studio (2015 ou superior)

Você deve executar a configuraçã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 a configuração autônoma.

Especificações de hardware

As especificações de hardware para seus agentes variam de acordo com suas necessidades, tamanho da equipe etc. Não é possível fazer uma recomendação geral que se aplicará a todos. Como ponto de referência, a equipe do Azure DevOps cria o código de agentes hospedados usando pipelines que utilizam agentes hospedados. Por outro lado, a maior parte do código do Azure DevOps é criada por computadores de classe de servidor de 24 núcleos que executam quatro agentes auto-hospedados cada um.

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 poderão ser descriptografados ou exfiltrados.

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

Portanto, é importante considerar o modelo de ameaça que envolve 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 em que o agente é executado, aos usuários que têm acesso de gravação à definição de Pipeline, aos 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 permitir 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 falhas de build ou obter arquivos de log para poder relatar falhas do Azure DevOps.

Decidir qual usuário você usará

Como uma etapa a ser realizada apenas uma vez, você precisa 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 elas são necessárias para conclusão do 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ê vai usar tem permissão para registrar o agente.

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

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, solicite a um administrador que a adicione. 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 Azure DevOps Server.

   Se esse se tratar de um agente de grupo de implantação, o administrador poderá ser um administrador de grupo de implantação, um proprietário da organização do Azure DevOps ou um administrador do TFS ou 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 semelhante a 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 Azure DevOps Server. Você não precisará fazer nada, pois já terá permissão para administrar o pool de agentes.

Baixar e configurar o agente

Azure Pipelines

1. Faça logon no computador usando a conta para a qual você preparou permissões, conforme explicado acima.

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, escolha Windows.

5. No painel esquerdo, selecione a arquitetura do processador da versão instalada do sistema operacional Windows em seu computador. A versão do agente x64 destina-se ao Windows de 64 bits, enquanto a versão x86 destina-se ao Windows de 32 bits. Se você não tiver certeza de qual versão do Windows está instalada, siga estas instruções para descobrir.

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

7. Siga as instruções na página para baixar o agente.

8. Desempacote o agente no diretório de sua escolha. Verifique se o caminho para o diretório não contém espaços, porque as ferramentas e os scripts nem sempre realizam corretamente o escape dos espaços. Uma pasta recomendada é C:\agents. Extrair na pasta de download ou em outras pastas de usuário pode causar problemas de permissão.

Importante

É altamente recomendável configurar o agente de uma janela do PowerShell com privilégios elevados. Se você quiser configurar como um serviço, isso será necessário.

Você não pode usar o ISE do Windows PowerShell para configurar o agente.

Importante

Por motivos de segurança, é altamente recomendável garantir que a pasta de agentes (C:\agents) só seja editável por administradores.

Observação

Evite usar shells baseados em mintty, como git-bash, para configuração do agente. Mintty não é totalmente compatível com a API nativa de Entrada/Saída do Windows (aqui estão algumas informações sobre isso) e não podemos garantir que o script de instalação funcionará corretamente neste caso.

Instalar o agente

1. Inicie uma janela elevada (PowerShell) e defina o local para onde você descompactou o agente.

   cd C:\agents 
   
   

2. Execute config.cmd. Isso fará uma série de perguntas para configurar o agente.

   .\config.cmd
   
   

Servidor URL

Quando a instalação solicitar a URL do servidor, para Azure DevOps Services, responda https://dev.azure.com/{your-organization}.

Tipo de autenticação de instalação do agente

Ao registrar um agente, escolha entre os tipos de autenticação a seguir e a configuração 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

O método de autenticação usado para registrar o agente é usado somente durante o registro do agente. Para saber mais sobre como os agentes se comunicam com o Azure Pipelines após o registro, consulte Comunicação com o Azure Pipelines ou o TFS.

Escolher modo interativo ou de serviço

Para obter diretrizes sobre se o agente deve ser executado no modo interativo ou como um serviço, confira Agentes: interativo vs. de serviço.

Se você optar por executar como um serviço (o que recomendamos), o nome de usuário como o qual você executar deverá ter 20 caracteres ou menos.

Executar o agente

Executar de maneira interativa

Se você configurou o agente para ser executado interativamente, execute o comando a seguir para iniciar o agente.

.\run.cmd

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

Observação

Se você estiver executando o agente do PowerShell Core para executar tarefas do Windows PowerShell, seu pipeline poderá falhar com um erro como Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present. Isso ocorre porque o Windows PowerShell herda a variável de ambiente PSModulePath, que inclui locais de módulo do PowerShell Core, do processo pai.

Como solução alternativa, você pode definir o botão do agente AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL como true no pipeline. Isso permitirá que o agente redefina PSModulePath antes de executar tarefas.

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

Se essa solução alternativa não resolver o problema ou se você precisar usar locais de módulo personalizados, poderá definir a variável $Env:PSModulePath conforme necessário na janela do PowerShell Core antes de executar o agente.

Executar uma vez

Você também pode optar por fazer com que o agente aceite apenas um trabalho e, em seguida, saia. Para executar nessa configuração, use o comando a seguir.

.\run.cmd --once

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

Executar como um serviço

Se você configurou o agente para ser executado como um serviço, ele será iniciado automaticamente. Você pode exibir e controlar o status de execução do agente do snap-in de serviços. Execute services.msc e procure um dos seguintes:

• "Agente do Azure Pipelines (nome do agente)"
• "Agente do VSTS (nome do agente)"
• "vstsagent.(nome da organização).(nome do agente)"

Observação

Para permitir mais flexibilidade com o controle de acesso de um agente em execução como um serviço, é possível configurar o tipo SID de serviço do agente como [SERVICE_SID_TYPE_UNRESTRICTED] via sinalizador ou prompt durante o fluxo de configuração interativo. Por padrão, o serviço do agente é configurado com SERVICE_SID_TYPE_NONE.

Para obter mais informações sobre tipos de SID, consulte esta documentação.

Para reiniciar o agente, clique com o botão direito do mouse na entrada e escolha Reiniciar.

Observação

Se você precisar alterar a conta de logon do agente, não faça isso no snap-in Serviços. Em vez disso, consulte as informações abaixo para reconfigurar o agente.

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

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:

.\config remove

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 precisa saber a URL para sua organização ou a 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: coloque o nome dele em letras maiúsculas e acrescente VSTS_AGENT_INPUT_. Por exemplo, VSTS_AGENT_INPUT_PASSWORD em vez de especificar --password.

Opções obrigatórias

• --unattended – a instalação do agente não solicitará informações, e todas as configurações precisam ser fornecidas na linha de comando
• --url <url> – a URL do servidor. Por exemplo: https://dev.azure.com/myorganization ou http://my-azure-devops-server:8080/tfs
• --auth <type> – o tipo de autenticação. Os valores válidos são:
  • pat (Token de acesso pessoal)
  • SP (Entidade de serviço) (Requer a versão 3.227.1 ou mais recente do agente)
  • negotiate (Kerberos ou NTLM)
  • alt (Autenticação básica)
  • integrated (credenciais padrão do Windows)

Opções de autenticação

• Se você escolheu --auth pat:
  • --token <token> – especifica seu token de acesso pessoal
  • Você também pode transmitir um token OAuth 2.0 como o parâmetro --token.
• Se você escolheu --auth negotiate ou --auth alt:
  • --userName <userName> – especifica um nome de usuário do Windows no formato domain\userName ou userName@domain.com
  • --password <password> – especifica uma senha
• Se você escolheu --auth SP:
  • --clientID <clientID> - especifica o ID do cliente da entidade de serviço com acesso aos agentes de registro
  • --tenantId <tenantID> - especifica o ID do locatário no qual a entidade de serviço está registrada
  • --clientSecret <clientSecret> - especifica o segredo do cliente da entidade de serviço
  • Confira Registrar um agente usando uma entidade de serviço para obter mais informações

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 de Usuário Final do Team Explorer Everywhere (somente macOS e Linux)
• --disableloguploads – não transmitir nem enviar 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.

Inicialização somente para Windows

• --runAsService – configurar o agente para ser executado como um serviço Windows (exige permissão de administrador)
• --runAsAutoLogon – configurar o logon automático e executar o agente na inicialização (exige permissão de administrador)
• --windowsLogonAccount <account> – usado com --runAsService ou --runAsAutoLogon para especificar o nome de usuário do Windows no formato domain\userName ou userName@domain.com
• --windowsLogonPassword <password> – usado com --runAsService ou --runAsAutoLogon para especificar a senha de logon do Windows (não necessário para Contas de Serviço Gerenciado do Grupo e contas internas do Windows, como 'NT AUTHORITY\NETWORK SERVICE')
• --enableservicesidtypeunrestricted - usado com --runAsService para configurar o agente com o tipo de SID de serviço como SERVICE_SID_TYPE_UNRESTRICTED (requer permissão do administrador)
• --overwriteAutoLogon – usado com --runAsAutoLogon para substituir o logon automático existente no computador
• --noRestart – usado com --runAsAutoLogon para impedir que o host seja reiniciado após a conclusão da configuração do agente

Solução de problemas de configuração do agente com a opção runAsAutoLogon

Configurar o agente com a opção runAsAutoLogon executa o agente sempre após reiniciar o computador. Execute as próximas etapas se o agente não for executado após reiniciar o computador.

Se o agente já estava configurado no computador

Antes de reconfigurar o agente, é necessário remover a configuração antiga do agente, portanto, tente executar este comando na pasta do agente:

.\config.cmd remove --auth 'PAT' --token '<token>'

Verifique se o agente foi removido do pool de agentes depois de executar o comando:

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

Remova o agente do pool de agentes manualmente se ele não tiver sido removido pela execução do comando.

Em seguida, tente reconfigurar o agente executando este comando na pasta do agente:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

Especifique o nome do agente (qualquer nome exclusivo específico) e marcar se esse agente apareceu no pool de agentes após a reconfiguração.

Será muito melhor desempacotar um arquivo morto do agente (que pode ser baixado aqui) e executar esse comando na nova pasta de agente descompactada.

Verifique se a chave do Registro do Windows está registrada e salva corretamente

Execute o comando whoami /user para obter o <sid>. Abra Registry Editor e siga o caminho:

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Verifique se a chave VSTSAgent está presente. Exclua essa chave se ela existir, feche Registry Editor e configure o agente executando o comando .\config.cmd (sem argumentos) da pasta do agente. Antes de responder à pergunta Enter Restart the machine at a later time?, abra Registry Editor novamente e verifique se a chave VSTSAgent apareceu. Pressione Enter para responder à pergunta e verifique se a tecla VSTSAgent permanece no lugar depois de reiniciar o computador.

Verifique se as chaves do Registro do Windows funcionam bem em seu computador

Crie um arquivo chamado autorun.cmd que contém a seguinte linha: echo "Hello from AutoRun!". Abra Registry Editor e crie no caminho acima de um novo par chave-valor com a chave AutoRun e o valor

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

Reinicie o computador. Você terá um problema com as chaves do Registro do Windows se não vir uma janela do console com a mensagem Hello from AutoRun!.

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 para o agente ingressar
• --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 recurso de ambiente devem ser adicionadas
• --virtualmachineresourcetags <tags> – usado com --addvirtualmachineresourcetags para especificar a lista separada por vírgulas de tags para o agente do recurso de ambiente, por exemplo , "web, db"

.\config --help sempre lista as respostas obrigatórias e opcionais mais recentes.

Diagnósticos

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

.\run --diagnostics

Isso será executado por meio de um pacote de diagnóstico que pode ajudar você a solucionar o problema. O recurso 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, consulte Diagnóstico de rede para agentes auto-hospedados

Ajuda em outras opções

Para saber mais sobre outras opções:

.\config --help

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

Funcionalidades

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. Em geral, você deve instalar em seus agentes qualquer software e ferramentas usados 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

Os recursos 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 a nova funcionalidade 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 frequentes

Qual versão do Git é executada pelo meu agente?

Por padrão, o agente do Windows usa a versão do Git que é agrupada com o software do agente. A Microsoft recomenda usar a versão do Git que é agrupada com o agente, mas você tem várias opções para substituir esse comportamento padrão e usar a versão do Git que o computador do agente instalou no caminho.

• Defina uma variável de pipeline chamada System.PreferGitFromPath como true nos seus pipelines.
• Nos agentes auto-hospedados, você pode criar um arquivo chamado .env no diretório raiz do agente e adicionar uma linha System.PreferGitFromPath=true ao arquivo. Para obter mais informações, confira Como definir variáveis de ambiente diferentes para cada agente individual?

Para ver a versão do Git usada por um pipeline, você pode examinar os logs para obter uma etapa checkout no seu pipeline, conforme mostrado no exemplo a seguir.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

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 funcionalidades do sistema. Para obter uma lista de softwares instalados em agentes hospedados pela Microsoft, confira 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 é atualizado automaticamente quando executa uma tarefa que exige 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.

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 por trás de um firewall, certifique-se de que o agente possa iniciar a comunicação com as URLs e endereços IP a seguir.

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 Release Management para organizações que usam o domínio {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com	Serviços de Plataforma do 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 Testes do Azure DevOps para organizações que usam o domínio {organization_name}.visualstudio.com
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	Para organizações que usam o domínio dev.azure.com
https://*.vsassets.io	Azure Artifacts via CDN
https://*.vsblob.visualstudio.com	Telemetria do Azure DevOps para organizações que usam o domínio dev.azure.com
https://*.vssps.visualstudio.com	Serviços de Plataforma do Azure DevOps para organizações que usam o domínio dev.azure.com
https://*.vstmr.visualstudio.com	Serviços de Gerenciamento de Testes 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	Entrada no Microsoft Entra
https://management.core.windows.net	APIs de Gerenciamento do Azure
https://vstsagentpackage.azureedge.net	Pacote do agente

Para garantir que sua organização funcione com quaisquer restrições de IP ou firewall existentes, verifique se dev.azure.com e *dev.azure.com estão abertos e atualize sua lista de IPs permitidos para incluir os endereços IP a seguir com base em sua versão de IP. Se você estiver listando atualmente os endereços IP 13.107.6.183 e 13.107.9.183, deixe-os onde estão, pois não é preciso removê-los.

Intervalos IPv4

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

Intervalos IPv6

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Observação

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

Como fazer para executar o agente com um certificado autoassinado?

Observação

Executar o agente com um certificado autoassinado só se aplica ao Servidor do Azure DevOps.

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, reinicie o agente seguindo as etapas em Executar como um serviço.

Como fazer para definir variáveis de ambiente diferentes para cada agente individual?

Crie um arquivo .env no diretório raiz do agente e coloque as variáveis de ambiente que você deseja definir no arquivo no formato a seguir e reinicie o agente.

MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4

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

Se você quiser que o agente ignore o 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://vstsagentpackage.azureedge.net
https://vssps.dev.azure.com

Para garantir que sua organização funcione com quaisquer restrições de IP ou firewall existentes, verifique se dev.azure.com e *dev.azure.com estão abertos e atualize sua lista de IPs permitidos para incluir os endereços IP a seguir com base em sua versão de IP. Se você estiver listando atualmente os endereços IP 13.107.6.183 e 13.107.9.183, deixe-os onde estão, pois não é preciso removê-los.

Intervalos IPv4

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

Intervalos IPv6

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/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 do NuGet, precisará configurar seu proxy Web para dar suporte ao bypass da URL do servidor que hospeda o feed do NuGet que você está usando.

Estou usando o TFS, e as URLs nas seções acima não funcionam para mim. Onde é possível obter ajuda?

Configurações e segurança do site

O que é habilitar SERVICE_SID_TYPE_UNRESTRICTED para o serviço de agente?

Ao configurar o software do agente no Windows Server, você pode especificar o identificador de segurança do serviço no prompt a seguir.

Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)

As versões anteriores do software do agente definem o tipo de identificador de segurança do serviço como SERVICE_SID_TYPE_NONE, que é o valor padrão para as versões atuais do agente. Para configurar o tipo de identificador de serviço de segurança para SERVICE_SID_TYPE_UNRESTRICTED, pressione Y.

Para obter mais informações, confira estrutura de SERVICE_SID_INFO e Identificadores de segurança.