Lokala Windows-agenter
Azure DevOps Services
För att skapa och distribuera Windows-, Azure- och andra Visual Studio-lösningar behöver du minst en Windows-agent. Windows-agenter kan också skapa Java- och Android-appar.
Den här artikeln innehåller vägledning om hur du använder 3.x-agentprogramvaran med Azure DevOps Services och aktuella versioner av Azure DevOps Server. En lista över Azure DevOps Server-versioner som stöder 3.x-agenten finns i Har Azure DevOps Server stöd för 3.x-agenten.
Kommentar
I den här artikeln beskrivs hur du konfigurerar en lokalt installerad agent. Om du använder Azure DevOps Services och en Microsoft-värdbaserad agent uppfyller dina behov kan du hoppa över att konfigurera en lokalt installerad Windows-agent.
Lär dig mer om agenter
Om du redan vet vad en agent är och hur den fungerar kan du hoppa direkt till följande avsnitt. Men om du vill ha mer bakgrund om vad de gör och hur de fungerar kan du läsa Azure Pipelines-agenter.
Kontrollera krav
Kontrollera att datorn har följande förutsättningar:
- Operativsystemversion
- Klientoperativsystem
- Windows 7 SP1 ESU
- Windows 8.1
- Windows 10
- Windows 11
- Serveroperativsystem
- Windows Server 2012 eller senare
- Klientoperativsystem
- Agentprogramvaran installerar sin egen version av .NET så det finns ingen .NET-förutsättning.
- PowerShell 3.0 eller senare
- Subversion – Om du skapar från en lagringsplats för subversion måste du installera subversionsklienten på datorn.
- Rekommenderas – Visual Studio-byggverktyg (2015 eller senare)
Du bör köra agentkonfigurationen manuellt första gången. När du har fått en känsla för hur agenter fungerar, eller om du vill automatisera konfigurationen av många agenter, bör du överväga att använda obevakad konfiguration.
Maskinvaruspecifikationer
Maskinvaruspecifikationerna för dina agenter varierar med dina behov, teamstorlek osv. Det går inte att göra en allmän rekommendation som gäller för alla. Som referens skapar Azure DevOps-teamet koden för värdbaserade agenter med hjälp av pipelines som använder värdbaserade agenter. Å andra sidan skapas huvuddelen av Azure DevOps-koden av 24-kärns serverklassdatorer som kör fyra lokalt installerade agenter vardera.
Förbereda behörigheter
Informationssäkerhet för lokalt installerade agenter
Användaren som konfigurerar agenten behöver pooladministratörsbehörigheter, men den användare som kör agenten gör det inte.
Mapparna som styrs av agenten bör begränsas till så få användare som möjligt eftersom de innehåller hemligheter som kan dekrypteras eller exfiltrateras.
Azure Pipelines-agenten är en programvaruprodukt som är utformad för att köra kod som den laddar ned från externa källor. Det kan vara ett mål för RCE-attacker (Remote Code Execution).
Därför är det viktigt att överväga hotmodellen som omger varje enskild användning av Pipelines-agenter för att utföra arbete och bestämma vilka som är de minsta behörigheter som kan beviljas användaren som kör agenten, till den dator där agenten körs, till de användare som har skrivåtkomst till pipelinedefinitionen, git-lagringsplatserna där yaml lagras. eller den grupp användare som styr åtkomsten till poolen för nya pipelines.
Det är bästa praxis att låta identiteten som kör agenten skilja sig från identiteten med behörighet att ansluta agenten till poolen. Användaren som genererar autentiseringsuppgifterna (och andra agentrelaterade filer) skiljer sig från den användare som behöver läsa dem. Därför är det säkrare att noggrant överväga åtkomst som beviljats till själva agentdatorn och agentmapparna som innehåller känsliga filer, till exempel loggar och artefakter.
Det är klokt att bevilja åtkomst till agentmappen endast för DevOps-administratörer och användaridentiteten som kör agentprocessen. Administratörer kan behöva undersöka filsystemet för att förstå byggfel eller hämta loggfiler för att kunna rapportera Azure DevOps-fel.
Bestäm vilken användare du ska använda
Som ett engångssteg måste du registrera agenten. Någon med behörighet att administrera agentkön måste slutföra de här stegen. Agenten använder inte den här personens autentiseringsuppgifter varje dag, men de måste slutföra registreringen. Läs mer om hur agenter kommunicerar.
Bekräfta att användaren har behörighet
Kontrollera att det användarkonto som du ska använda har behörighet att registrera agenten.
Är användaren en Azure DevOps-organisationsägare eller TFS- eller Azure DevOps Server-administratör? Stanna här, du har behörighet.
Annars:
Öppna en webbläsare och gå till fliken Agentpooler för din Azure Pipelines-organisation eller Azure DevOps Server eller TFS-server:
Logga in på din organisation (
https://dev.azure.com/{yourorganization}
).Välj Azure DevOps, Organisationsinställningar.
Välj Agentpooler.
Logga in på din projektsamling (
http://your-server/DefaultCollection
).Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Välj poolen till höger på sidan och klicka sedan på Säkerhet.
Om det användarkonto som du ska använda inte visas får du en administratör att lägga till det. Administratören kan vara en administratör för agentpoolen, en Azure DevOps-organisationsägare eller en TFS- eller Azure DevOps Server-administratör.
Om det är en distributionsgruppsagent kan administratören vara administratör för distributionsgruppen, en Azure DevOps-organisationsägare eller en TFS- eller Azure DevOps Server-administratör.
Du kan lägga till en användare i administratörsrollen för distributionsgruppen på fliken Säkerhet på sidan Distributionsgrupper i Azure Pipelines.
Kommentar
Om du ser ett meddelande som det här: Det gick inte att lägga till identiteten. Prova en annan identitet. Du följde förmodligen stegen ovan för en organisationsägare eller TFS- eller Azure DevOps Server-administratör. Du behöver inte göra något; du redan har behörighet att administrera agentpoolen.
Ladda ned och konfigurera agenten
Azure-pipelines
Logga in på datorn med det konto som du har förberett behörigheter för enligt beskrivningen ovan.
Logga in på Azure Pipelines i webbläsaren och gå till fliken Agentpooler :
Logga in på din organisation (
https://dev.azure.com/{yourorganization}
).Välj Azure DevOps, Organisationsinställningar.
Välj Agentpooler.
Logga in på din projektsamling (
http://your-server/DefaultCollection
).Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Välj standardpoolen , välj fliken Agenter och välj Ny agent.
I dialogrutan Hämta agent väljer du Windows.
I den vänstra rutan väljer du processorarkitekturen för den installerade Windows OS-versionen på datorn. X64-agentversionen är avsedd för 64-bitars Windows, medan x86-versionen är avsedd för 32-bitars Windows. Om du inte är säker på vilken version av Windows som är installerad följer du de här anvisningarna för att ta reda på det.
Klicka på knappen Ladda ned i den högra rutan.
Följ anvisningarna på sidan för att ladda ned agenten.
Packa upp agenten i valfri katalog. Se till att sökvägen till katalogen inte innehåller några blanksteg eftersom verktyg och skript inte alltid är korrekt escape-blanksteg. En rekommenderad mapp är
C:\agents
. Extrahering i nedladdningsmappen eller andra användarmappar kan orsaka behörighetsproblem.
Viktigt!
Vi rekommenderar starkt att du konfigurerar agenten från ett upphöjt PowerShell-fönster. Om du vill konfigurera som en tjänst krävs detta.
Du får inte använda Windows PowerShell ISE för att konfigurera agenten.
Viktigt!
Av säkerhetsskäl rekommenderar vi starkt att du ser till att agentmappen (C:\agents
) endast kan redigeras av administratörer.
Kommentar
Undvik att använda mintty-baserade gränssnitt, till exempel git-bash, för agentkonfiguration. Mintty är inte helt kompatibelt med inbyggt In-/utdata-Windows-API (här är lite information om det) och vi kan inte garantera att installationsskriptet fungerar korrekt i det här fallet.
Installera agenten
Starta ett upphöjt fönster (PowerShell) och ange platsen där du packade upp agenten.
cd C:\agents
Kör
config.cmd
. Då får du en rad frågor om hur du konfigurerar agenten..\config.cmd
Server-URL
När konfigurationen frågar efter din server-URL svarar du https://dev.azure.com/{your-organization}
för Azure DevOps Services .
När konfigurationen frågar efter din server-URL svarar du https://{my-server}/{my-collection}
för Azure DevOps Server .
Autentiseringstyp för agentinstallation
När du registrerar en agent väljer du mellan följande autentiseringstyper, och du uppmanas att ange den specifika ytterligare information som krävs för varje autentiseringstyp. Mer information finns i autentiseringsalternativ för lokalt installerad agent.
- Personlig åtkomsttoken
- Alternativ Anslut till Azure DevOps Server eller TFS med grundläggande autentisering. När du väljer Alternativ uppmanas du att ange dina autentiseringsuppgifter.
Windows-agenter har följande två ytterligare autentiseringsalternativ på Azure DevOps Server och TFS.
- Förhandla om att ansluta till TFS som en annan användare än den inloggade användaren via ett Windows-autentiseringsschema som NTLM eller Kerberos. När du har valt Förhandla uppmanas du att ange autentiseringsuppgifter.
- Integrerad (standard) Anslut en Windows-agent till TFS med autentiseringsuppgifterna för den inloggade användaren via ett Windows-autentiseringsschema som NTLM eller Kerberos. Du uppmanas inte att ange autentiseringsuppgifter när du har valt den här metoden.
Viktigt!
Servern måste vara konfigurerad för att stödja autentiseringsmetoden för att använda alternativ, förhandla eller integrerad autentisering.
Autentiseringsmetoden som används för att registrera agenten används endast under agentregistreringen. Mer information om hur agenter kommunicerar med Azure Pipelines efter registreringen finns i Kommunikation med Azure Pipelines eller TFS.
Välj interaktivt läge eller tjänstläge
Information om huruvida agenten ska köras i interaktivt läge eller som en tjänst finns i Agenter: Interaktiv kontra tjänst.
Om du väljer att köra som en tjänst (vilket vi rekommenderar) ska användarnamnet du kör vara 20 tecken eller färre.
Kör agenten
Kör interaktivt
Om du har konfigurerat agenten att köras interaktivt kör du följande kommando för att starta agenten.
.\run.cmd
Starta om agenten genom att trycka på Ctrl+C för att stoppa agenten och sedan köra run.cmd
för att starta om den.
Kommentar
Om du kör agenten från PowerShell Core för att köra Windows PowerShell-uppgifter kan pipelinen misslyckas med ett fel som Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present
. Det beror på att Windows PowerShell ärver PSModulePath
miljövariabeln, som innehåller PowerShell Core-modulplatser, från den överordnade processen.
Som en lösning kan du ange agentens ratt AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL
till true
i pipelinen. Detta gör att agenten kan återställa PSModulePath
innan uppgifter körs.
variables:
AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"
Om den här lösningen inte löser problemet, eller om du behöver använda anpassade modulplatser, kan du ange variabeln $Env:PSModulePath
efter behov i PowerShell Core-fönstret innan du kör agenten.
Kör en gång
Du kan också välja att låta agenten endast acceptera ett jobb och sedan avsluta. Om du vill köra i den här konfigurationen använder du följande kommando.
.\run.cmd --once
Agenter i det här läget accepterar bara ett jobb och snurrar sedan ned korrekt (användbart för att köra i Docker på en tjänst som Azure Container Instances).
Kör som en tjänst
Om du har konfigurerat agenten att köras som en tjänst startar den automatiskt. Du kan visa och kontrollera statusen för agenten som körs från snapin-modulen för tjänster. Kör services.msc
och leta efter något av följande:
- "Azure Pipelines Agent (agentens namn)"
- "VSTS-agent (agentens namn)"
- "vstsagent. (organisationsnamn). (namnet på din agent)"
Kommentar
Om du vill tillåta mer flexibilitet med åtkomstkontroll för en agent som körs som en tjänst är det möjligt att konfigurera agenttjänstens SID-typ som [SERVICE_SID_TYPE_UNRESTRICTED
] via flagga eller fråga under interaktivt konfigurationsflöde.
Som standard konfigureras agenttjänsten med SERVICE_SID_TYPE_NONE
.
Mer information om SID-typer finns i den här dokumentationen.
Om du vill starta om agenten högerklickar du på posten och väljer Starta om.
Kommentar
Om du behöver ändra agentens inloggningskonto ska du inte göra det från snapin-modulen Tjänster. Se i stället informationen nedan för att konfigurera om agenten.
Om du vill använda din agent kör du ett jobb med agentens pool. Om du inte valde en annan pool finns agenten i standardpoolen.
Ersätt en agent
Om du vill ersätta en agent följer du stegen Ladda ned och konfigurerar agenten igen.
När du konfigurerar en agent med samma namn som en agent som redan finns tillfrågas du om du vill ersätta den befintliga agenten. Om du svarar Y
kontrollerar du att du tar bort agenten (se nedan) som du ersätter. Annars stängs en av agenterna av efter några minuters konflikter.
Ta bort och konfigurera om en agent
Så här tar du bort agenten:
.\config remove
När du har tagit bort agenten kan du konfigurera den igen.
Obevakad konfiguration
Agenten kan konfigureras från ett skript utan mänsklig inblandning.
Du måste skicka --unattended
och svaren på alla frågor.
För att konfigurera en agent måste den känna till URL:en till din organisation eller samling och autentiseringsuppgifter för någon som har behörighet att konfigurera agenter.
Alla andra svar är valfria.
Alla kommandoradsparametrar kan anges med hjälp av en miljövariabel i stället: ange dess namn i versaler och prepend VSTS_AGENT_INPUT_
.
I stället för att --password
till exempel VSTS_AGENT_INPUT_PASSWORD
ange .
Obligatoriska alternativ
--unattended
– Agentkonfigurationen frågar inte efter information och alla inställningar måste anges på kommandoraden--url <url>
– SERVERNs URL. Till exempel: https://dev.azure.com/myorganization eller http://my-azure-devops-server:8080/tfs--auth <type>
– autentiseringstyp. Giltiga värden är:pat
(Personlig åtkomsttoken)SP
(Tjänstens huvudnamn) (Kräver agentversion 3.227.1 eller senare)negotiate
(Kerberos eller NTLM)alt
(Grundläggande autentisering)integrated
(Standardautentiseringsuppgifter för Windows)
Autentiseringsalternativ
- Om du väljer
--auth pat
:--token <token>
– anger din personliga åtkomsttoken- Du kan också skicka en OAuth 2.0-token som
--token
parameter.
- Om du väljer
--auth negotiate
eller--auth alt
:--userName <userName>
– anger ett Windows-användarnamn i formatetdomain\userName
elleruserName@domain.com
--password <password>
– anger ett lösenord
- Om du väljer
--auth SP
:--clientID <clientID>
– anger klient-ID för tjänstens huvudnamn med åtkomst till registeragenter--tenantId <tenantID>
– anger klientorganisations-ID:t som tjänstens huvudnamn är registrerat i--clientSecret <clientSecret>
– anger klienthemligheten för tjänstens huvudnamn- Mer information finns i Registrera en agent med ett huvudnamn för tjänsten
Pool- och agentnamn
--pool <pool>
– poolnamn för agenten som ska anslutas--agent <agent>
– agentnamn--replace
– ersätt agenten i en pool. Om en annan agent lyssnar med samma namn börjar den misslyckas med en konflikt
Agentkonfiguration
--work <workDirectory>
– arbetskatalog där jobbdata lagras. Standardvärdet är_work
under roten i agentkatalogen. Arbetskatalogen ägs av en viss agent och bör inte delas mellan flera agenter.--acceptTeeEula
– Acceptera licensavtalet för Team Explorer överallt (endast macOS och Linux)--disableloguploads
– strömma eller skicka inte utdata från konsolloggen till servern. I stället kan du hämta dem från agentvärdens filsystem när jobbet har slutförts.
Start endast för Windows
--runAsService
– konfigurera agenten så att den körs som en Windows-tjänst (kräver administratörsbehörighet)--runAsAutoLogon
– Konfigurera automatisk inloggning och kör agenten vid start (kräver administratörsbehörighet)--windowsLogonAccount <account>
- används med--runAsService
eller--runAsAutoLogon
för att ange Windows-användarnamnet i formatetdomain\userName
elleruserName@domain.com
--windowsLogonPassword <password>
– används med--runAsService
eller--runAsAutoLogon
för att ange lösenord för Windows-inloggning (krävs inte för grupphanterade tjänstkonton och Inbyggda Windows-konton, till exempel "NT AUTHORITY\NETWORK SERVICE")--enableservicesidtypeunrestricted
– används med--runAsService
för att konfigurera agenten med tjänst-SID-typ somSERVICE_SID_TYPE_UNRESTRICTED
(kräver administratörsbehörighet)--overwriteAutoLogon
– används med--runAsAutoLogon
för att skriva över den befintliga automatiska inloggningen på datorn--noRestart
– används med--runAsAutoLogon
för att hindra värden från att startas om när agentkonfigurationen har slutförts
Felsöka konfiguration av agenten med alternativet runAsAutoLogon
Om du konfigurerar agenten runAsAutoLogon
med alternativet körs agenten varje gång efter att datorn har startats om.
Utför nästa steg om agenten inte körs efter att datorn har startats om.
Om agenten redan har konfigurerats på datorn
Innan du konfigurerar om agenten måste du ta bort den gamla agentkonfigurationen, så försök att köra det här kommandot från agentmappen:
.\config.cmd remove --auth 'PAT' --token '<token>'
Kontrollera om agenten har tagits bort från agentpoolen när kommandot har körts:
<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents
Ta bort agenten från agentpoolen manuellt om den inte har tagits bort genom att köra kommandot .
Försök sedan konfigurera om agenten genom att köra det här kommandot från agentmappen:
.\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>'
Ange agentnamnet (ett specifikt unikt namn) och kontrollera om agenten dök upp i agentpoolen efter omkonfigurationen.
Det blir mycket bättre att packa upp ett agentarkiv (som kan laddas ned här) och köra det här kommandot från den nya uppackade agentmappen.
Kontrollera om Windows-registernyckeln registreras och sparas korrekt
whoami /user
Kör kommandot för att hämta <sid>
. Öppna Registry Editor
och följ sökvägen:
Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Kontrollera om det finns VSTSAgent
nyckeln. Ta bort den här nyckeln om den finns och stäng Registry Editor
och konfigurera sedan agenten .\config.cmd
genom att köra kommandot (utan args) från agentmappen. Innan du svarar på frågan Enter Restart the machine at a later time?
öppnar Registry Editor
du igen och kontrollerar om VSTSAgent
nyckeln har dykt upp. Tryck Enter
på för att besvara frågan och kontrollera om VSTSAgent
nyckeln finns kvar när datorn har startats om.
Kontrollera om Windows-registernycklar fungerar bra på datorn
Skapa en autorun.cmd
fil som innehåller följande rad: echo "Hello from AutoRun!"
.
Öppna Registry Editor
och skapa i sökvägen ovanför ett nytt nyckel/värde-par med nyckeln AutoRun
och värdet
C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"
Starta om fin virtuella dator. Du har problem med Windows-registernycklar om du inte ser något konsolfönster med meddelandet Hello from AutoRun!
.
Endast distributionsgrupp
--deploymentGroup
– konfigurera agenten som en distributionsgruppsagent--deploymentGroupName <name>
– används med--deploymentGroup
för att ange distributionsgruppen som agenten ska ansluta till--projectName <name>
– används med--deploymentGroup
för att ange projektnamnet--addDeploymentGroupTags
– används med--deploymentGroup
för att ange att taggar för distributionsgrupp ska läggas till--deploymentGroupTags <tags>
– används med--addDeploymentGroupTags
för att ange kommaavgränsad lista över taggar för distributionsgruppagenten – till exempel "web, db"
Endast miljöer
--addvirtualmachineresourcetags
– används för att ange att miljöresurstaggar ska läggas till--virtualmachineresourcetags <tags>
– används med--addvirtualmachineresourcetags
för att ange kommaavgränsad lista över taggar för miljöresursagenten – till exempel "web, db"
.\config --help
visar alltid de senaste obligatoriska och valfria svaren.
Diagnostik
Om du har problem med din lokala agent kan du prova att köra diagnostik. När du har konfigurerat agenten:
.\run --diagnostics
Detta går igenom en diagnostiksvit som kan hjälpa dig att felsöka problemet. Diagnostikfunktionen är tillgänglig från och med agentversion 2.165.0.
Nätverksdiagnostik för lokala värdbaserade agenter
Ange värdet för Agent.Diagnostic
till true
för att samla in ytterligare loggar som kan användas för att felsöka nätverksproblem för lokalt installerade agenter. Mer information finns i Nätverksdiagnostik för lokalt installerade agenter
Hjälp om andra alternativ
Om du vill veta mer om andra alternativ:
.\config --help
Hjälpen innehåller information om autentiseringsalternativ och obevakad konfiguration.
Funktioner
Agentens funktioner katalogiseras och annonseras i poolen så att endast de versioner och versioner som den kan hantera tilldelas till den. Se Funktioner för bygg- och versionsagenter.
I många fall måste du installera programvara eller verktyg när du har distribuerat en agent. Vanligtvis bör du installera på dina agenter oavsett vilken programvara och vilka verktyg du använder på utvecklingsdatorn.
Om ditt bygge till exempel innehåller npm-aktiviteten körs inte bygget om det inte finns en byggagent i poolen som har npm installerat.
Viktigt!
Funktionerna omfattar alla miljövariabler och de värden som anges när agenten körs. Om något av dessa värden ändras när agenten körs måste agenten startas om för att hämta de nya värdena. När du har installerat ny programvara på en agent måste du starta om agenten för att den nya funktionen ska visas i poolen, så att bygget kan köras.
Om du vill exkludera miljövariabler som funktioner kan du ange dem genom att ange en miljövariabel VSO_AGENT_IGNORE
med en kommaavgränsad lista med variabler som ska ignoreras.
Vanliga frågor
Vilken version av Git körs min agent?
Som standard använder Windows-agenten den version av Git som paketeras med agentprogramvaran. Microsoft rekommenderar att du använder den version av Git som medföljer agenten, men du har flera alternativ för att åsidosätta det här standardbeteendet och använda den version av Git som agentdatorn har installerat i sökvägen.
- Ange en pipelinevariabel med namnet
System.PreferGitFromPath
true
i dina pipelines. - På lokalt installerade agenter kan du skapa en fil med namnet .env i agentrotkatalogen och lägga till en
System.PreferGitFromPath=true
rad i filen. Mer information finns i Hur ställer jag in olika miljövariabler för varje enskild agent?
Om du vill se vilken version av Git som används av en pipeline kan du titta på loggarna för ett checkout
steg i pipelinen, som du ser i följande exempel.
Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1
Hur ser jag till att jag har den senaste agentversionen?
Gå till fliken Agentpooler :
Logga in på din organisation (
https://dev.azure.com/{yourorganization}
).Välj Azure DevOps, Organisationsinställningar.
Välj Agentpooler.
Logga in på din projektsamling (
http://your-server/DefaultCollection
).Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Välj Azure DevOps, samlingsinställningar.
Välj Agentpooler.
Klicka på poolen som innehåller agenten.
Kontrollera att agenten är aktiverad.
Gå till fliken Funktioner:
På fliken Agentpooler väljer du önskad agentpool.
Välj Agenter och välj önskad agent.
Välj fliken Funktioner .
Kommentar
Microsoft-värdbaserade agenter visar inte systemfunktioner. En lista över programvara som är installerad på Microsoft-värdbaserade agenter finns i Använda en Microsoft-värdbaserad agent.
Välj önskad pool på fliken Agentpooler .
Välj Agenter och välj önskad agent.
Välj fliken Funktioner .
Välj önskad pool på fliken Agentpooler .
Välj Agenter och välj önskad agent.
Välj fliken Funktioner .
Leta efter funktionen
Agent.Version
. Du kan kontrollera det här värdet mot den senaste publicerade agentversionen. Se Azure Pipelines-agenten och kontrollera sidan för det högsta versionsnumret i listan.Varje agent uppdateras automatiskt när den kör en uppgift som kräver en nyare version av agenten. Om du vill uppdatera vissa agenter manuellt högerklickar du på poolen och väljer Uppdatera alla agenter.
Kan jag uppdatera mina agenter som ingår i en Azure DevOps Server-pool?
Ja. Från och med Azure DevOps Server 2019 kan du konfigurera servern så att den söker efter agentpaketfilerna på en lokal disk. Den här konfigurationen åsidosätter standardversionen som medföljer servern när den släpptes. Det här scenariot gäller även när servern inte har åtkomst till Internet.
Från en dator med Internetåtkomst laddar du ned den senaste versionen av agentpaketfilerna (i .zip eller .tar.gz formulär) från sidan Azure Pipelines Agent GitHub Releases.
Överför de nedladdade paketfilerna till varje Azure DevOps Server-programnivå med hjälp av valfri metod (till exempel USB-enhet, nätverksöverföring och så vidare). Placera agentfilerna under följande mapp:
- Windows:
%ProgramData%\Microsoft\Azure DevOps\Agents
- Linux:
usr/share/Microsoft/Azure DevOps/Agents
- macOS:
usr/share/Microsoft/Azure DevOps/Agents
Skapa mappen Agenter om den inte finns.
- Nu är det klart! Azure DevOps Server använder nu de lokala filerna när agenterna uppdateras. Varje agent uppdateras automatiskt när den kör en uppgift som kräver en nyare version av agenten. Men om du vill uppdatera vissa agenter manuellt högerklickar du på poolen och väljer sedan Uppdatera alla agenter.
Jag kör en brandvägg och min kod finns i Azure-lagringsplatser. Vilka URL:er behöver agenten kommunicera med?
Om du kör en agent i ett säkert nätverk bakom en brandvägg kontrollerar du att agenten kan initiera kommunikation med följande URL:er och IP-adresser.
Domänens URL | beskrivning |
---|---|
https://{organization_name}.pkgs.visualstudio.com |
Azure DevOps-paketerings-API för organisationer som använder domänen {organization_name}.visualstudio.com |
https://{organization_name}.visualstudio.com |
För organisationer som använder domänen {organization_name}.visualstudio.com |
https://{organization_name}.vsblob.visualstudio.com |
Azure DevOps-telemetri för organisationer som använder domänen {organization_name}.visualstudio.com |
https://{organization_name}.vsrm.visualstudio.com |
Versionshanteringstjänster för organisationer som använder domänen {organization_name}.visualstudio.com |
https://{organization_name}.vssps.visualstudio.com |
Azure DevOps Platform Services för organisationer som använder domänen {organization_name}.visualstudio.com |
https://{organization_name}.vstmr.visualstudio.com |
Azure DevOps Test Management Services för organisationer som använder domänen {organization_name}.visualstudio.com |
https://*.blob.core.windows.net |
Azure Artifacts |
https://*.dev.azure.com |
För organisationer som använder domänen dev.azure.com |
https://*.vsassets.io |
Azure Artifacts via CDN |
https://*.vsblob.visualstudio.com |
Azure DevOps-telemetri för organisationer som använder domänen dev.azure.com |
https://*.vssps.visualstudio.com |
Azure DevOps Platform Services för organisationer som använder domänen dev.azure.com |
https://*.vstmr.visualstudio.com |
Azure DevOps Test Management Services för organisationer som använder domänen dev.azure.com |
https://app.vssps.visualstudio.com |
För organisationer som använder domänen {organization_name}.visualstudio.com |
https://dev.azure.com |
För organisationer som använder domänen dev.azure.com |
https://login.microsoftonline.com |
Microsoft Entra-inloggning |
https://management.core.windows.net |
Api:er för Azure Management |
https://vstsagentpackage.azureedge.net |
Agentpaket |
Se till att din organisation fungerar med befintliga brandväggs- eller IP-begränsningar genom att se till att dev.azure.com
och *dev.azure.com
är öppna och uppdatera dina tillåtna IP-adresser så att de inkluderar följande IP-adresser baserat på din IP-version. Om du för närvarande tillåter att ip-adresserna 13.107.6.183
och 13.107.9.183
anges lämnar du dem på plats eftersom du inte behöver ta bort dem.
IPv4-intervall
13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
IPv6-intervall
2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
Kommentar
Mer information om tillåtna adresser finns i Tillåtna adresslistor och nätverksanslutningar.
Hur kör jag agenten med självsignerat certifikat?
Kommentar
Att köra agenten med ett självsignerat certifikat gäller endast för Azure DevOps Server.
Kör agenten med självsignerat certifikat
Hur kör jag agenten bakom en webbproxy?
Kör agenten bakom en webbproxy
Hur startar jag om agenten
Om du kör agenten interaktivt kan du läsa omstartsinstruktionerna i Kör interaktivt. Om du kör agenten som en tjänst startar du om agenten genom att följa stegen i Kör som en tjänst.
Hur ställer jag in olika miljövariabler för varje enskild agent?
Skapa en .env
fil under agentens rotkatalog och placera de miljövariabler som du vill ange i filen i följande format och starta sedan om agenten.
MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4
Hur konfigurerar jag agenten för att kringgå en webbproxy och ansluta till Azure Pipelines?
Om du vill att agenten ska kringgå proxyn och ansluta direkt till Azure Pipelines bör du konfigurera webbproxyn så att agenten får åtkomst till följande URL:er.
För organisationer som använder domänen *.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
För organisationer som använder domänen 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
Se till att din organisation fungerar med befintliga brandväggs- eller IP-begränsningar genom att se till att dev.azure.com
och *dev.azure.com
är öppna och uppdatera dina tillåtna IP-adresser så att de inkluderar följande IP-adresser baserat på din IP-version. Om du för närvarande tillåter att ip-adresserna 13.107.6.183
och 13.107.9.183
anges lämnar du dem på plats eftersom du inte behöver ta bort dem.
IPv4-intervall
13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
IPv6-intervall
2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
Kommentar
Med den här proceduren kan agenten kringgå en webbproxy. Bygg-pipelinen och skripten måste fortfarande hantera att kringgå webbproxyn för varje uppgift och verktyg som du kör i bygget.
Om du till exempel använder en NuGet-uppgift måste du konfigurera webbproxyn så att den stöder att url:en kringgås för den server som är värd för NuGet-feeden som du använder.
Jag använder TFS och URL:erna i avsnitten ovan fungerar inte för mig. Var kan jag få hjälp?
Jag använder TFS lokalt och jag ser inte några av dessa funktioner. Varför inte?
Vissa av dessa funktioner är endast tillgängliga i Azure Pipelines och är ännu inte tillgängliga lokalt. Vissa funktioner är tillgängliga lokalt om du har uppgraderat till den senaste versionen av TFS.
Vad är aktivera SERVICE_SID_TYPE_UNRESTRICTED för agenttjänsten?
När du konfigurerar agentprogramvaran på Windows Server kan du ange tjänstsäkerhetsidentifieraren från följande uppmaning.
Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)
Tidigare versioner av agentprogramvaran anger tjänstsäkerhetsidentifierarens typ till SERVICE_SID_TYPE_NONE
, vilket är standardvärdet för de aktuella agentversionerna. Om du vill konfigurera säkerhetstjänstidentifierartypen till SERVICE_SID_TYPE_UNRESTRICTED
trycker du på Y
.
Mer information finns i SERVICE_SID_INFO struktur och säkerhetsidentifierare.