Agentes Linux auto-hospedados (2.x)
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
Importante
Este artigo fornece orientação para usar o software agente de versão 2.x com o Azure DevOps Server e o TFS. Se você estiver usando os Serviços de DevOps do Azure, consulte Agentes Linux auto-hospedados.
Atenção
Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planejamento de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.
Para executar seus trabalhos, você precisará de pelo menos um agente. Um agente Linux pode criar e implantar diferentes tipos de aplicativos, incluindo aplicativos Java e Android. Suportamos Ubuntu, Red Hat e CentOS.
Antes de começar:
- Se seus pipelines estiverem no Azure Pipelines e um agente hospedado pela Microsoft atender às suas necessidades, você poderá ignorar a configuração de um agente Linux privado.
- Caso contrário, você veio ao lugar certo para configurar um agente no Linux. Continue para a próxima seção.
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 Core 3.1. Você pode executar este agente em várias distribuições Linux. Suportamos o seguinte subconjunto de distribuições suportadas pelo .NET Core:
- x64
- CentOS 7, 6 (ver nota 1)
- Debian 9
- Fedora 30, 29
- Linux Mint 18, 17
- openSUSE 42.3 ou posterior
- Oracle Linux 8, 7
- Red Hat Enterprise Linux 8, 7, 6 (consulte a nota 1)
- SUSE Enterprise Linux 12 SP2 ou posterior
- Ubuntu 20.04, 18.04, 16.04
- Azure Linux 1.0 (consulte a nota 3)
- ARM32 (ver nota 2)
- Debian 9
- Ubuntu 18.04
- ARM64
- Debian 9
- Ubuntu 21.04, 20.04, 18.04
Nota
Nota 1: RHEL 6 e CentOS 6 requerem a instalação da versão especializada rhel.6-x64
do agente.
Importante
A partir de fevereiro de 2023, não haverá mais versões de agentes compatíveis com o RHEL 6. Para obter mais informações, consulte Os clientes que usam o Red Hat Enterprise Linux (RHEL) 6 devem atualizar o sistema operacional em agentes auto-hospedados.
Nota
Nota 2: É necessário o conjunto de instruções ARM ARMv7 ou superior.
Execute uname -a
para ver o conjunto de instruções da sua distro Linux.
Nota
Atualmente, a distribuição do sistema operacional Linux do Azure tem suporte parcial do Agente de DevOps do Azure.
Estamos fornecendo um mecanismo para a deteção dessa distribuição do sistema operacional em installdependencies.sh
script, mas devido à falta de suporte do lado do .Net Core, não pudemos garantir a operacionalidade total de todas as funções do agente ao executar nesta distribuição do sistema operacional.
Independentemente da sua plataforma, você precisará instalar o Git 2.9.0 ou superior. É altamente recomendável instalar a versão mais recente do Git.
Nota
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 Core são buscadas em sites de terceiros, como packages.efficios.com
o . 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.
Subversion
Se você estiver criando a partir de um repositório Subversion, deverá instalar o cliente Subversion na máquina.
Você deve executar a configuração do agente manualmente na primeira vez. Depois de ter uma ideia de como os agentes trabalham, ou se quiser automatizar a configuração de muitos agentes, considere usar a configuração autônoma.
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ê precisará aceitar durante a configuração se 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.
Nota
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:
- Defina
DISABLE_TEE_PLUGIN_REMOVAL
a variável de ambiente ou pipeline comotrue
. Essa variável impede que o agente remova o plug-in TEE após o check-out do repositório TFVC. - Baixe o TEE-CLC versão 14.135.0 manualmente das versões do Team Explorer Everywhere GitHub.
- Extraia o conteúdo da
TEE-CLC-14.135.0
pasta 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 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 Pipelines Agents 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 fazer com que a identidade que executa o agente seja diferente da identidade com 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 ela é obrigada a concluir o registro. Saiba mais sobre como os agentes se comunicam.
Autenticar com um token de acesso pessoal (PAT)
- 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 sua página inicial, abra o seu perfil. Aceda aos seus dados de segurança.
Crie um token de acesso pessoal.
Nota
Se você estiver configurando um agente de grupo de implantação ou se vir um erro ao registrar um recurso de ambiente VM, deverá definir o escopo da PAT como Todas as organizações acessíveis.
Na página inicial, abra as configurações de usuário e selecione Tokens de acesso pessoal.
Crie um token 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 novo token de acesso pessoal para ver a lista completa de escopos.
Copie o token. Você usará esse token quando configurar o agente.
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 por aqui, você tem permissão.
Otherwise:
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:
Inicie sessão na sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Inicie sessão 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, 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.
Nota
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 a fila de agentes.
Baixar e configurar o agente
Pipelines do Azure
Faça logon na máquina 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:
Inicie sessão na sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Inicie sessão 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 sabor específico. Oferecemos x64 ou ARM para a maioria das distribuições Linux.
No painel direito, clique no botão Download .
Siga as instruções na página.
Descompacte 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 na máquina 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:
Inicie sessão na sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Inicie sessão 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 sabor específico. Oferecemos x64 ou ARM para a maioria das distribuições Linux.
No painel direito, clique no botão Download .
Siga as instruções na página.
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}
Azure DevOps Server 2019: https://{your_server}/DefaultCollection
Authentication type
Pipelines do Azure
Escolha PAT, e cole o token PAT que você criou na janela do prompt de comando.
Nota
Ao utilizar a PAT como método de autenticação, o token PAT é utilizado apenas para a configuração inicial do agente. Saiba mais em Comunicação com o Azure Pipelines ou TFS.
TFS ou Azure DevOps Server
Importante
Certifique-se de que o servidor está configurado para suportar o método de autenticação que pretende utilizar.
Ao configurar seu agente para se conectar ao TFS, você tem as seguintes opções:
Alterne Conectar-se ao TFS ou ao Servidor de DevOps do Azure usando a autenticação Básica. Depois de selecionar Alternativa, você será solicitado a fornecer suas credenciais.
Integrado Não suportado em macOS ou 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 Suportado apenas no Azure Pipelines e TFS 2017 e mais recentes. Depois de escolher PAT, cole o token PAT criado na janela do prompt de comando. Use um token de acesso pessoal (PAT) se sua instância do Azure DevOps Server ou do TFS e a máquina 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 do controlador de domínio.
Nota
Ao usar a PAT como método de autenticação, o token PAT é usado apenas para a configuração inicial do agente no Servidor de DevOps do Azure e nas versões mais recentes do TFS. Saiba mais em Comunicação com o Azure Pipelines ou TFS.
Executar interativamente
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:
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 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 aceitarão apenas um trabalho e, em seguida, desativarã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 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 você executar o agente como um serviço, não poderá executar o serviço do agente como
root
usuário. - Os usuários que executam o SELinux relataram dificuldades com o script fornecido
svc.sh
. Consulte este problema do agente como um ponto de partida. O SELinux não é uma configuração oficialmente suportada.
Nota
Se você tiver uma distribuição diferente, ou se preferir outras abordagens, poderá usar qualquer tipo de mecanismo de serviço que preferir. Consulte Arquivos de serviço.
Comandos
Alterar para o diretório do agente
Por exemplo, se você instalou na myagent
subpasta 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 que é definida pelo comando sudo. Essa variável é sempre igual ao nome do usuário que invocou o sudo
comando.
Iniciar
sudo ./svc.sh start
Status
sudo ./svc.sh status
Parar
sudo ./svc.sh stop
Desinstale o .
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
arquivo (PATH
é armazenado em ) no diretório raiz do agente, você também pode alterar esses arquivos diretamente para aplicar alterações de .path
variáveis de ambiente.
Execute instruções antes do início do serviço
Você também pode executar suas próprias instruções e comandos para executar quando o serviço for iniciado. Por exemplo, você pode configurar o ambiente ou chamar scripts.
Editar
runsvc.sh
.Substitua a seguinte linha pelas instruções:
# insert anything to setup env when running as a service
Arquivos de serviço
Quando você instala o serviço, alguns arquivos de serviço são colocados no lugar.
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á:
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 ficheiro 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
Nós fornecemos o ./svc.sh
script como uma maneira conveniente para você executar e gerenciar 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 reduzir o risco desse tipo de problema ser causado por alta pressão de memória usando cgroups e um arquivo .oom_score_adj
Depois de fazer isso, o Linux recupera a memória do sistema dos processos de trabalho de pipeline antes de recuperar a memória do processo do agente. Saiba como configurar cgroups e pontuação 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 você responder Y
, certifique-se de remover o agente (veja abaixo) que 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:
Pare e desinstale o serviço como explicado acima.
Remova o agente.
./config.sh remove
Introduza as suas credenciais.
Depois de remover o agente, você pode configurá-lo novamente.
Configuração autônoma
O agente pode ser configurado a partir de um script sem intervenção humana.
Você deve passar --unattended
e as respostas para todas as perguntas.
Para configurar um agente, ele deve saber a URL 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: coloque seu nome em maiúsculas e prepend 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.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 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 utilizador do Windows no formatodomain\userName
ouuserName@domain.com
--password <password>
- especifica uma palavra-passe
Nomes de pool e agentes
--pool <pool>
- Nome do pool para o agente participar--agent <agent>
- nome do agente--replace
- Substitua o agente em um pool. Se outro agente estiver ouvindo pelo mesmo nome, ele começará a falhar com um conflito
Configuração do agente
--work <workDirectory>
- diretório de trabalho onde os dados do trabalho são armazenados. O padrão é sob_work
a 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 Acordo 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.
Inicialização somente do Windows
--runAsService
- configurar o agente para ser executado como um serviço do Windows (requer permissão de administrador)--runAsAutoLogon
- configurar o logon automático e executar o agente na inicialização (requer permissão de administrador)--windowsLogonAccount <account>
- utilizado com--runAsService
ou--runAsAutoLogon
para especificar o nome de utilizador 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 de Grupo e contas integradas do Windows, como 'NT AUTHORITY\NETWORK SERVICE')--enableservicesidtypeunrestricted
- usado com--runAsService
para configurar o agente com o tipo SID de serviço comoSERVICE_SID_TYPE_UNRESTRICTED
(requer permissão de administrador)--overwriteAutoLogon
- usado com--runAsAutoLogon
para substituir o logon automático existente na máquina--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 runAsAutoLogon
opção
Configurar o agente com a runAsAutoLogon
opção executa o agente cada vez depois de reiniciar a máquina.
Execute as próximas etapas se o agente não for executado após reiniciar a máquina.
Se o agente já estava configurado na máquina
Antes de reconfigurar o agente, é necessário remover a configuração antiga do agente, portanto, tente executar este comando a partir da 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 executando o 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 verifique se esse agente apareceu no pool de agentes após a reconfiguração.
Será muito melhor descompactar um arquivo do agente (que pode ser baixado aqui) e executar esse comando a partir da nova pasta do agente descompactado.
Verifique se a chave de registo do Windows está registada e guardada corretamente
Execute o whoami /user
comando para obter o <sid>
arquivo . Abra Registry Editor
e siga o caminho:
Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Verifique se existe a VSTSAgent
chave. Exclua essa chave se ela existir, feche Registry Editor
e configure o agente executando o .\config.cmd
comando (sem args) da pasta do agente. Antes de responder à pergunta Enter Restart the machine at a later time?
, abra Registry Editor
novamente e verifique se a VSTSAgent
chave apareceu. Pressione Enter
para responder à pergunta e verifique se a VSTSAgent
chave permanece em seu lugar depois de reiniciar a máquina.
Verifique se as chaves de registo do Windows funcionam bem na sua máquina
Crie um autorun.cmd
arquivo que contenha a seguinte linha: echo "Hello from AutoRun!"
.
Abra Registry Editor
e crie no caminho acima 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 seu computador. Você tem um problema com as chaves do Registro do Windows se não vir uma janela do console com a Hello from AutoRun!
mensagem.
Apenas 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 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"
Apenas 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 ambientais - por exemplo, "web, db"
./config.sh --help
sempre lista as últimas respostas obrigatórias e opcionais.
Diagnóstico
Se você estiver tendo problemas com seu agente auto-hospedado, você pode tentar executar o diagnóstico. Depois de configurar o agente:
./run.sh --diagnostics
Isso será executado através de um conjunto de diagnóstico que pode ajudá-lo a solucionar o problema. A funcionalidade de diagnóstico está disponível a partir da versão 2.165.0 do agente.
Ajuda sobre outras opções
Para saber mais sobre outras opções:
./config.sh --help
A ajuda fornece informações sobre alternativas de autenticação e configuração autônoma.
Capacidades
Os recursos do seu agente são catalogados e anunciados no pool para que apenas as compilações e versões que ele pode manipular sejam atribuídas a ele. Consulte Recursos do agente de compilação e liberação.
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 pegar 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 VSO_AGENT_IGNORE
de ambiente com uma lista delimitada por vírgulas de variáveis a serem ignoradas.
FAQ
Como posso certificar-me de que tenho a versão mais recente do agente?
Navegue até a guia Pools de agentes:
Inicie sessão na sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Inicie sessão 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 de recursos:
Na guia Pools de agentes, selecione o pool de agentes desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Nota
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.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Procure a
Agent.Version
capacidade. Você pode verificar esse valor em relação à versão mais recente do agente publicada. Consulte Azure Pipelines Agent e verifique na página o número de versão mais alto listado.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.
Em um computador com acesso à Internet, baixe a versão mais recente dos arquivos do pacote do agente (no formato .zip ou .tar.gz) na página Versões do GitHub do Agente de Pipelines do Azure.
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:
- 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.
- Está 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.
Como posso certificar-me de que tenho a versão mais recente do agente v2?
Navegue até a guia Pools de agentes:
Inicie sessão na sua organização (
https://dev.azure.com/{yourorganization}
).Escolha Azure DevOps, Configurações da organização.
Escolha Pools de agentes.
Inicie sessão 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 de recursos:
Na guia Pools de agentes, selecione o pool de agentes desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Nota
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.
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Na guia Pools de agentes, selecione o pool desejado.
Selecione Agentes e escolha o agente desejado.
Escolha a guia Recursos .
Procure a
Agent.Version
capacidade. Você pode verificar esse valor em relação à versão mais recente do agente publicada. Consulte Azure Pipelines Agent e verifique na página o número de versão mais alto listado.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 v2 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.
Em um computador com acesso à Internet, baixe a versão mais recente dos arquivos do pacote do agente (no formato .zip ou .tar.gz) na página Versões do GitHub do Agente de Pipelines do Azure.
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 sob a
%ProgramData%\Microsoft\Azure DevOps\Agents
pasta. Crie a pasta Agentes se ela não estiver presente.Está 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
usa systemctl
, o que requer sudo
.
Código fonte: systemd.svc.sh.template no GitHub
Estou a executar uma firewall e o meu código está nos Repositórios do Azure. 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 | Description |
---|---|
https://{organization_name}.pkgs.visualstudio.com |
API de empacotamento do Azure DevOps para organizações que usam o {organization_name}.visualstudio.com domínio |
https://{organization_name}.visualstudio.com |
Para organizações que usam o {organization_name}.visualstudio.com domínio |
https://{organization_name}.vsblob.visualstudio.com |
Telemetria de DevOps do Azure para organizações que usam o {organization_name}.visualstudio.com domínio |
https://{organization_name}.vsrm.visualstudio.com |
Release Management Services para organizações que usam o {organization_name}.visualstudio.com domínio |
https://{organization_name}.vssps.visualstudio.com |
Serviços da Plataforma Azure DevOps para organizações que usam o {organization_name}.visualstudio.com domínio |
https://{organization_name}.vstmr.visualstudio.com |
Serviços de Gerenciamento de Teste de DevOps do Azure para organizações que usam o {organization_name}.visualstudio.com domínio |
https://*.blob.core.windows.net |
Artefactos do Azure |
https://*.dev.azure.com |
Para organizações que usam o dev.azure.com domínio |
https://*.vsassets.io |
Artefatos do Azure via CDN |
https://*.vsblob.visualstudio.com |
Telemetria de DevOps do Azure para organizações que usam o dev.azure.com domínio |
https://*.vssps.visualstudio.com |
Serviços da Plataforma Azure DevOps para organizações que usam o dev.azure.com domínio |
https://*.vstmr.visualstudio.com |
Serviços de Gerenciamento de Teste de DevOps do Azure para organizações que usam o dev.azure.com domínio |
https://app.vssps.visualstudio.com |
Para organizações que usam o {organization_name}.visualstudio.com domínio |
https://dev.azure.com |
Para organizações que usam o dev.azure.com domínio |
https://login.microsoftonline.com |
Entrada no Microsoft Entra |
https://management.core.windows.net |
API de Gerenciamento do Azure |
https://vstsagentpackage.azureedge.net |
Pacote do agente |
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 você estiver listando os endereços IP e 13.107.9.183
no 13.107.6.183
momento, deixe-os no lugar, pois não precisa 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
Nota
Para obter mais informações sobre endereços permitidos, consulte Listas de endereços permitidos e conexões de rede.
Como executar o agente com certificado autoassinado?
Execute o agente com certificado autoassinado
Como executar o agente por trás de um proxy da Web?
Execute o agente por trás de um proxy da Web
Como reiniciar o agente
Se você estiver executando o agente interativamente, consulte as instruções de reinicialização em Executar interativamente. Se você estiver executando o agente como um serviço systemd, siga as etapas para Parar e, em seguida , Iniciar o agente.
Como 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 *.visualstudio.com
domínio:
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 dev.azure.com
domínio:
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 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 você estiver listando os endereços IP e 13.107.9.183
no 13.107.6.183
momento, deixe-os no lugar, pois não precisa 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
Nota
Este procedimento permite que o agente ignore um proxy da Web. Seu pipeline de compilação e scripts ainda devem lidar ignorando seu proxy da Web para cada tarefa e ferramenta que você executa em sua compilação.
Por exemplo, se você estiver usando uma tarefa NuGet, deverá configurar seu proxy da Web para oferecer suporte ao ignorar a 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 posso obter ajuda?
Eu uso o TFS local e não vejo alguns desses recursos. Porque não?
Alguns desses recursos estão disponíveis apenas no Azure Pipelines e ainda não estão disponíveis localmente. Alguns recursos estão disponíveis no local se você tiver atualizado para a versão mais recente do TFS.
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários