Agentes do Linux auto-hospedados (2.x)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Importante
Este artigo fornece diretrizes para usar o software do agente versão 2.x com o Azure DevOps Server e o TFS. Se você estiver usando Azure DevOps Services, consulte Agentes do Linux auto-hospedados.
Cuidado
Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planejamento adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.
Para executar seus trabalhos, você precisará de pelo menos um agente. Um agente do Linux pode criar e implantar diferentes tipos de aplicativos, incluindo aplicativos Java e Android. Nós damos suporte ao Ubuntu, Red Hat e CentOS.
Antes de começar:
- Se os pipelines estiverem no Azure Pipelines e um agente hospedado pela Microsoft atender às suas necessidades, você poderá ignorar a configuração de um agente do Linux privado.
- Caso contrário, você chegou ao lugar certo para configurar um agente no Linux. Siga para a próxima seção.
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
O agente é baseado no .NET Core 3.1. 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 Core:
- X64
- CentOS 7, 6 (confira a observação 1)
- Debian 9
- Fedora 30, 29
- Linux Mint 18, 17
- openSUSE 42.3 ou versões posteriores
- Oracle Linux 8, 7
- Red Hat Enterprise Linux 8, 7, 6 (confira a observação 1)
- SUSE Enterprise Linux 12 SP2 ou posterior
- Ubuntu 20.04, 18.04, 16.04
- Azure Linux 1.0 (confira a observação 3)
- ARM32 (confira a observação 2)
- Debian 9
- Ubuntu 18.04
- ARM64
- Debian 9
- Ubuntu 21.04, 20.04, 18.04
Observação
Observação 1: o RHEL 6 e o CentOS 6 exigem a instalação da versão rhel.6-x64
especializada do agente.
Importante
Desde fevereiro de 2023, não há mais versões de agente compatíveis com o RHEL 6. Para obter mais informações, consulte Os clientes que usam o RHEL (Red Hat Enterprise Linux) 6 devem atualizar o sistema operacional em agentes auto-hospedados.
Observação
Observação 2: o conjunto de instruções do ARM ARMv7 ou superior é necessário.
Execute uname -a
para ver o conjunto de instruções da sua distribuição do Linux.
Observação
Atualmente, a distribuição do sistema operacional Linux do Azure tem suporte parcial do Agente do Azure DevOps.
Estamos fornecendo um mecanismo para a detecção dessa distribuição do sistema operacional no script installdependencies.sh
, mas devido à falta de suporte do lado do .Net Core, não pudemos garantir a operabilidade total de todas as funções do agente durante a execução nessa distribuição do sistema operacional.
Independentemente de sua plataforma, você precisará instalar o Git 2.9.0 ou superior. É altamente recomendável instalar a versão mais recente do Git.
Observação
O instalador do agente sabe como verificar se há outras dependências.
Você pode instalar essas dependências em plataformas Linux compatíveis executando ./bin/installdependencies.sh
no diretório do agente.
Lembre-se de que algumas dessas dependências exigidas pelo .NET Core são buscadas de sites de terceiros, como packages.efficios.com
. Examine o script installdependencies.sh
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.
Subversion
Se você estiver criando a partir de um repositório Subversion, precisará instalar o cliente Subversion no computador.
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.
TFVC
Se você usar 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ê precisará aceitar durante a configuração se planeja trabalhar com o TFVC.
Como o plug-in TEE não é mais mantido e contém algumas dependências Java desatualizadas, o agente 2.198.0 e versões posteriores não estão mais incluídos 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 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 firewall, você precisará garantir o acesso ao seguinte site: https://vstsagenttools.blob.core.windows.net/
. O plug-in 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:
- Defina a variável de pipeline ou ambiente
DISABLE_TEE_PLUGIN_REMOVAL
comotrue
. Essa variável impede que o agente remova o plug-in TEE após a verificação do repositório TFVC. - Baixe o TEE-CLC versão 14.135.0 manualmente de Versões do GitHub do Team Explorer Everywhere.
- Extraia o conteúdo da pasta
TEE-CLC-14.135.0
para<agent_directory>/externals/tee
.
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 e contêm segredos que podem 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 relacionada a 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 do 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 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.
Autenticar-se com um PAT (token de acesso pessoal)
- Entre com a conta de usuário que você planeja usar no portal da Web do Azure DevOps Server (
https://{your-server}/DefaultCollection/
).
- Entre com a conta de usuário que você planeja usar em sua organização do Azure DevOps (
https://dev.azure.com/{your_organization}
).
Na home page, abra seu perfil. Acesse os detalhes de segurança.
Crie um token de acesso pessoal.
Observação
Se você estiver configurando um agente de grupo de implantação ou se vir um erro ao registrar um recurso de ambiente de VM, defina o escopo do PAT como Todas as organizações acessíveis.
Na sua home page, abra as configurações do usuário e selecione Tokens de acesso pessoal.
Para o escopo, selecione Pools de Agentes (ler, gerenciar) e verifique se todas as outras caixas estão desmarcadas. Se for um agente de grupo de implantação, para o escopo, selecione Grupo de implantação (ler, gerenciar) e verifique se todas as outras caixas estão desmarcadas.
Selecione Mostrar todos os escopos na parte inferior da janela Criar um token de acesso pessoal para ver a lista completa de escopos.
Copie a o token. Você usará esse token ao configurar o agente.
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:
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:
Entre em sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Entre na sua coleção de projetos (
http://your-server/DefaultCollection
).Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Selecione o pool no lado direito da página e clique em Segurança.
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 a fila do agente.
Baixar e configurar o agente
Azure Pipelines
Faça logon no computador usando a conta para a qual você preparou permissões, conforme explicado acima.
No navegador da Web, entre no Azure Pipelines e navegue até a guia Pools de agentes:
Entre em sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Entre na sua coleção de projetos (
http://your-server/DefaultCollection
).Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Selecione o pool Padrão, selecione a guia Agentes e escolha Novo agente.
Na caixa de diálogo Obter o agente, clique em Linux.
No painel esquerdo, selecione o tipo específico. Oferecemos x64 ou ARM para a maioria das distribuições do Linux.
No painel direito, clique no botão Baixar.
Siga as instruções na página.
Desempacote o agente no diretório de sua escolha.
cd
para esse diretório e execute./config.sh
.
Azure DevOps Server 2019 e Azure DevOps Server 2020
Faça logon no computador usando a conta para a qual você preparou permissões, conforme explicado acima.
No navegador da Web, entre no Azure DevOps Server 2019 e navegue até a guia Pools de agentes:
Entre em sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Entre na sua coleção de projetos (
http://your-server/DefaultCollection
).Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Clique em Baixar agente.
Na caixa de diálogo Obter agente, clique em Linux.
No painel esquerdo, selecione o tipo específico. Oferecemos x64 ou ARM para a maioria das distribuições do Linux.
No painel direito, clique no botão Baixar.
Siga as instruções na página.
Desempacote o agente no diretório de sua escolha.
cd
para esse diretório e execute./config.sh
.
Servidor URL
Azure Pipelines: https://dev.azure.com/{your-organization}
Azure DevOps Server 2019: https://{your_server}/DefaultCollection
Tipo de autenticação
Azure Pipelines
Escolha PAT e cole o token PAT que você criou na janela do prompt de comando.
Observação
Ao usar PAT como o método de autenticação, o token PAT é usado apenas para a configuração inicial do agente. Saiba mais em Comunicação com o Azure Pipelines ou o TFS.
TFS ou Azure DevOps Server
Importante
Verifique se o servidor está configurado para dar suporte ao método de autenticação que você deseja usar.
Ao configurar seu agente para se conectar ao TFS, você tem as seguintes opções:
Alternativo Conecte-se ao TFS ou Azure DevOps Server usando a autenticação Básica. Depois de selecionar Alternativo, você será solicitado a fornecer suas credenciais.
Integrado Incompatível com macOS e Linux.
Negociar (padrão) Conectar-se ao TFS ou ao Azure DevOps Server como um usuário diferente do usuário conectado por meio de um esquema de autenticação do Windows, como NTLM ou Kerberos. Depois de selecionar Negociar, você será solicitado a fornecer credenciais.
PAT Compatível apenas com o Azure Pipelines e o TFS 2017 e mais recente. Escolha PAT e cole o token PAT que você criou na janela do prompt de comando. Use um PAT (token de acesso pessoal) se o Azure DevOps Server ou a instância do TFS e o computador do agente não estiverem em um domínio confiável. A autenticação PAT é tratada pelo Azure DevOps Server ou pela instância do TFS, em vez de pelo controlador de domínio.
Observação
Ao usar o PAT como método de autenticação, o token PAT é usado apenas para a configuração inicial do agente no Azure DevOps Server e nas versões mais recentes do TFS. Saiba mais em Comunicação com o Azure Pipelines ou o TFS.
Executar de maneira interativa
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.
Para executar o agente de maneira interativa:
Se você estiver executando o agente como um serviço, desinstale o serviço.
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 estará 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 um trabalho. Para executar nessa configuração:
./run.sh --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 systemd
Se o agente estiver em execução nestes sistemas operacionais, você poderá executar o agente como um serviço systemd
:
- 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 serviço systemd
.
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
svc.sh
fornecido. Consulte este 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ê instalou na subpasta myagent
do 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 o parâmetro username
não for especificado, o nome de usuário será retirado da variável de ambiente $SUDO_USER, que é definida pelo comando sudo. Essa variável é sempre igual ao nome do usuário que invocou o comando sudo
.
Iniciar
sudo ./svc.sh start
Status
sudo ./svc.sh status
Stop
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 usa uma instantâneo de algumas variáveis de ambiente úteis para o 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 novo software):
./env.sh
sudo ./svc.sh stop
sudo ./svc.sh start
O instantâneo das variáveis de ambiente é armazenado no arquivo .env
(PATH
é armazenado em .path
) no diretório raiz do agente, você também pode alterar esses arquivos diretamente para aplicar alterações de variável de ambiente.
Executar instruções antes do serviço ser iniciado
Você também pode executar suas instruções e comandos a serem executados quando o serviço for iniciado. Por exemplo, você pode configurar o ambiente ou chamar scripts.
Edite
runsvc.sh
.Substitua a seguinte linha por suas instruções:
# insert anything to setup env when running as a service
Arquivos do serviço
Quando você instala o serviço, alguns arquivos de serviço são colocados em prática.
Arquivo de serviço systemd
Um arquivo de serviço systemd é 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 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 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 script ./svc.sh
como uma maneira conveniente de executar e gerenciar seu agente como um serviço systemd. No entanto, você pode usar qualquer tipo de mecanismo de serviço que preferir (por exemplo: initd ou upstart).
Você pode usar o modelo descrito acima como para facilitar a geração de outros tipos de arquivo de serviço.
Usar um cgroup para evitar falha do agente
É importante evitar situações em que o agente falha ou se torna inutilizável porque, caso contrário, o agente não pode transmitir logs de pipeline ou relatar o status do pipeline de volta para o servidor. Você pode atenuar o risco desse tipo de problema ser causado por alta pressão de memória usando grupos 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:
Interrompa e desinstale o serviço, conforme explicado acima.
Remova o agente.
./config.sh remove
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 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) – o PAT é o único esquema que funciona com o Azure DevOps Services.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- O 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 do Windows no formatodomain\userName
ouuserName@domain.com
--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 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 formatodomain\userName
ouuserName@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 comoSERVICE_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.sh --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.sh --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.
Ajuda em 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.
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
Como fazer ter certeza de que tenho a versão mais recente do agente?
Navegue até a guia Pools de agentes:
Entre em sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Entre na sua coleção de projetos (
http://your-server/DefaultCollection
).Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Clique no pool que contém o agente.
Verifique se o agente está habilitado.
Navegue até a guia Funcionalidades:
Na guia Pools de agentes, selecione o pool de agentes desejado.
Selecione Agentes e escolha o agente desejado.
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.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Selecione a guia Funcionalidades.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Selecione a guia Funcionalidades.
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.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.
Posso atualizar meus agentes que fazem parte de um pool do Azure DevOps Server?
Sim. No Azure DevOps Server 2019 e versões posteriores, você pode configurar o servidor para procurar os arquivos de pacote do agente em um disco local. Essa configuração substituirá a versão padrão que veio com o servidor quando ele foi lançado. Esse cenário também se aplica quando o servidor não tem acesso à Internet.
Em um computador com acesso à Internet, baixe a versão mais recente dos arquivos de pacote do agente (no formulário .zip ou .tar.gz) na página Versões do GitHub do Agente do Azure Pipelines.
Transfira os arquivos de pacote baixados para cada Camada de Aplicativo do Azure DevOps Server 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:
- Windows:
%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.
- Tudo pronto! Seu Azure DevOps Server agora usará os arquivos locais sempre que os agentes forem atualizados. Cada agente é atualizado automaticamente quando executa uma tarefa que exige uma versão mais recente do agente. No entanto, se você quiser atualizar manualmente alguns agentes, clique com o botão direito do mouse no pool e selecione Atualizar todos os agentes.
Como fazer para ter certeza de que tenho a versão mais recente do agente v2?
Navegue até a guia Pools de agentes:
Entre em sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Entre na sua coleção de projetos (
http://your-server/DefaultCollection
).Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Escolha Azure DevOps, Configurações de coleção.
Escolha Pools de agentes.
Clique no pool que contém o agente.
Verifique se o agente está habilitado.
Navegue até a guia Funcionalidades:
Na guia Pools de agentes, selecione o pool de agentes desejado.
Selecione Agentes e escolha o agente desejado.
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.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Selecione a guia Funcionalidades.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Selecione a guia Funcionalidades.
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.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.
Posso atualizar meus agentes v2 que fazem parte de um pool do Azure DevOps Server?
Sim. No Azure DevOps Server 2019 e versões posteriores, você pode configurar o servidor para procurar os arquivos de pacote do agente em um disco local. Essa configuração substituirá a versão padrão que veio com o servidor quando ele foi lançado. Esse cenário também se aplica quando o servidor não tem acesso à Internet.
Em um computador com acesso à Internet, baixe a versão mais recente dos arquivos de pacote do agente (no formulário .zip ou .tar.gz) na página Versões do GitHub do Agente do Azure Pipelines.
Transfira os arquivos de pacote baixados para cada Camada de Aplicativo do Azure DevOps Server usando um método de sua escolha (como unidade USB, transferência de rede e assim por diante). Coloque os arquivos do agente na pasta
%ProgramData%\Microsoft\Azure DevOps\Agents
. Crie a pasta Agentes se ela não estiver presente.Tudo pronto! Seu Azure DevOps Server agora usará os arquivos locais sempre que os agentes forem atualizados. Cada agente é atualizado automaticamente quando executa uma tarefa que exige uma versão mais recente do agente. No entanto, 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 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?
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 Iniciar o agente.
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?
Uso o TFS local e não vejo alguns desses recursos. Por que não?
Alguns desses recursos estão disponíveis apenas no Azure Pipelines e ainda não estão disponíveis localmente. Alguns recursos estarão disponíveis localmente se você tiver atualizado para a versão mais recente do TFS.
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de