Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Konfigurera skalningsinställningar för att hantera prestanda och kostnader för din hanterade DevOps-pool. Information om priser och prestanda finns i Hantera kostnader och prestanda.
Agenttillstånd
Hanterade DevOps-pooler kan konfigureras som tillståndslösa eller tillståndskänsliga.
- Tillståndslösa pooler – Ange en ny agent för varje jobb.
- Tillståndskänsliga pooler – Tillåt delning av agenter mellan flera jobb.
Standardinställningen för en hanterad DevOps-pool är tillståndslös (fresh agent varje gång) men i vissa fall kanske teamen vill återanvända agenter för att återanvända paketen eller filerna som skapades under den föregående pipelinekörningen. Skapa arbetsbelastning är ett vanligt scenario där team vill bevara tillstånds- och återanvändningsagenter. Du kan uppnå tillståndskänsliga pooler via Hanterade DevOps-pooler samtidigt som du balanserar dem med bästa praxis för säkerhet. Som standard kan en agent återanvändas i högst 7 dagar, men du kan konfigurera den så att den återanvänds tidigare.
Kommentar
Tillståndslösa pooler eller användning av agenttillståndsinställningen Fresh agent varje gång rekommenderas av säkerhetsexperter som skydd mot leveranskedjeattacker.
Tillståndslösa pooler
När en tillståndslös agent har konfigurerats anskaffas en ny agent för varje jobb och tas bort när jobbet har slutförts.
För livscykeln för tillståndslösa agenter och en förklaring av hur de används i Azure Pipelines (inklusive potentiella fördröjningar i allokeringen), se följande livscykel för agenter och potentiella fördröjningar i allokeringsavsnittet .
När agenttillståndet anges till Fresh agent varje gång, anskaffas en ny agent för varje jobb och tas bort när jobbet har slutförts.
Tillståndskänsliga pooler
När samma agent kan användas av flera versioner ("kind": "stateful" i resursmallar eller { "stateful": {...} } i Azure CLI) är aktiverad anses agenter i poolen vara tillståndskänsliga. Tillståndskänsliga pooler konfigureras med hjälp av följande inställningar.
Maximalt antal aktiva för standby-agenter (
maxAgentLifetime) konfigurerar den maximala varaktighet som en agent i en tillståndskänslig pool kan köra innan den stängs av och ignoreras. Formatet för Max time to live för standby-agenter ärdd.hh:mm:ss. Standardvärdet för Max time to live för väntelägesagenter är inställt på den maximala tillåtna varaktigheten på sju dagar (7.00:00:00).Viktigt!
Om ett jobb körs när intervallet Maximal livslängd för standbyagenter går ut, kommer agenten inte att stängas av innan jobbet har slutförts, såvida inte jobbet tar mer än två dagar att köra. Enskilda jobb i Hanterade DevOps-pooler kan köras i högst två dagar, även om standby-agenten har en konfigurerad maxlängd på mer än två dagar för Max time to live för standby-agenter. Kontakta supporten om arbetsflödet kräver att du kör ett enda jobb som tar mer än två dagar att slutföra.
Respitperiod (
gracePeriodTimeSpan) konfigurerar hur lång tid en agent i en tillståndskänslig pool väntar på nya jobb innan den stängs av när alla aktuella och köade jobb har slutförts. Formatet för respitperiod ärdd.hh:mm:ssoch standardvärdet är ingen respitperiod.
Medan agenter i tillståndslösa pooler stängs av och ignoreras efter varje jobb, fortsätter agenter i tillståndskänsliga pooler att köras om något av följande villkor uppfylls.
- Om det finns ett annat jobb i kö när det första jobbet slutförs skickar Hanterade DevOps-pooler jobbet till agenten som körde det första jobbet i stället för att stänga av det.
- Om det finns en respitperiod som konfigurerats för poolen väntar agenter på nya jobb under den varaktighet som anges av respitperioden innan de stängs av.
- Om standby-agenter är aktiverade och agentbilden uppfyller kriterierna för den aktiva etableringsperioden fortsätter agenten att köra och vänta på jobb.
Agenter som körs i tillståndskänsliga pooler stängs av och ignoreras om de körs kontinuerligt under den tid som anges av Max time to live för standby-agenter, även om de tidigare villkoren är sanna. Om maxtid för att leva för väntelägesagenter har konfigurerats i tre dagar och Läget För vänteläge är inställt på Manuell, Alla veckors schema (datorer som är tillgängliga dygnet innan), startas agenterna om efter tre kontinuerliga dagars drifttid.
Viktigt!
Agenter i tillståndskänsliga pooler kan fortfarande stängas av och ignoreras när ett jobb har slutförts om det inte finns någon respitperiod, ingen aktiv etableringsperiod för standby-agenter och inga köade jobb som matchar agenten. När en agent har ignorerats går alla tillstånd förlorade.
Respitperioden möjliggör det mest kostnadseffektiva sättet att köra tillståndskänsliga pooler för pipelines med konsekvent belastning och kräver inte användning av standby-agentläge för att hålla agenter online och redo att acceptera jobb.
Standby-agentläge
När du skapar en pool är standby-agentläget inaktiverat som standard och det finns inga standby-agenter att omedelbart tilldela till dina pipelines, som kan behöva vänta en stund, upp till 15 minuter, för att en agent ska etableras på begäran. För bättre prestanda aktiverar du standby-agentläge och konfigurerar ett väntelägesagentschema som ger kapacitet för din arbetsbelastning.
När ett väntelägesagentschema har konfigurerats jämför Hanterade DevOps-pooler regelbundet antalet etablerade agenter med antalet standby-agenter som anges i det aktuella etableringsschemat och startar nya agenter efter behov för att behålla antalet standby-agenter. Du kan visa aktuell status och antal agenter i poolen med hjälp av fönstret Agenter.
Viktigt!
Etableringsantalet i ett schema får inte vara större än de högsta agenter som konfigurerats i Poolinställningar.
Standby-agentläget konfigureras med hjälp av följande inställningar:
- Av – Standby-agentläget är inaktiverat och agenter etableras på begäran när jobb placeras i kö.
- Manuell – Konfigurera ett manuellt väntelägesschema.
- Automatisk – Använd ett automatiskt väntelägesschema baserat på agentanvändningshistorik och kan konfigureras för kostnad och prestanda.
Manuell
Manuellt läge passar bäst för team som har kunskap om användningsmönstren för CI/CD-pipelines. Om du väljer det manuella alternativet måste du definiera ditt företableringsschema baserat på din förståelse av när agenter i poolen mest sannolikt kommer att användas och hur många agenter som sannolikt kommer att användas och ange ett etableringsantal agenter som uppfyller den beräknade efterfrågan.
Du kan skapa ett eget etableringsschema eller välja mellan något av de fördefinierade schemana, och du kan konfigurera tidszonen som ska användas för att ange scheman. Standardvärdet för Pre-provisioning TimeZone är (UTC) Coordinated Universal Time.The default value for Pre-provisioning TimeZone is (UTC) Coordinated Universal Time.
Manuell konfiguration av standby-agenten kan konfigureras på något av följande tre sätt.
- Börja från början – Konfigurera en uppsättning etableringsperioder för standby-agenter
- Veckodagsschema (datorer som är tillgängliga under tidsperioden varje veckodag) – Konfigurera en start- och sluttid för standby-agenter som ska vara tillgängliga varje veckodag
- Schema för alla veckor (datorer som är tillgängliga 24/7) – Konfigurera ett fast antal väntelägesagenter som ska vara kontinuerligt tillgängliga
Var och en av snabbstarterna före etableringen har följande vanliga inställningar utöver de specifika inställningarna för den snabbstarten.
- Med företablering av tidszon kan du konfigurera tidszonen för tiderna i ditt företableringsschema. Standardvärdet för Pre-provisioning TimeZone är (UTC) Coordinated Universal Time.The default value for Pre-provisioning TimeZone is (UTC) Coordinated Universal Time.
-
Standby-agentprocent konfigurerar procentandelen väntelägesagenter som du vill ha för varje avbildning. Du kan ange
*för att se till att alla bilder etableras på samma sätt, eller så kan du ange ett heltal från 0 till 100 för att representera en procentandel. Om du anger en procentandel måste summan för alla bilder vara lika med 100. Om du har en enda bild anger du*eller 100. Standby-agentprocent konfigureras i avsnittetimagesnär arm-mallar används. Mer information finns i Konfigurera avbildningar.
Börja från början
Om du väljer att börja från början kan du lägga till en lista över etableringsperioder som ska fungera som ditt etableringsschema. Varje etableringsperiod består av en startdag, slutdag, tidszon, starttid, sluttid och ett antal. Etableringsperioder kan inte överlappa varandra.
| Fastighet | beskrivning |
|---|---|
| Flera dagar | När du är markerad kan du konfigurera både en startdag och en slutdag för ditt etableringsschema. |
| Till nästa period | När den är markerad körs etableringsperioden från starttiden till början av nästa etableringsperiod. |
| Startdag | Dagen då etableringsperioden startar. |
| Slutdag | Dagen då etableringsperioden slutar. Krävs om flera dagar är markerat. |
| Starttid | Den tid som etableringsperioden startar. |
| Sluttid | Den tid som etableringsperioden tar slut. Krävs såvida inte Till nästa period är markerad. |
| Antal | Antalet standby-agenter som ska etableras. Det här talet måste vara större än noll och får inte vara större än värdet Maximalt antal agenter som konfigurerats i Poolinställningar. |
När du har skapat en etableringsperiod kan du ta bort eller redigera perioden från listan Företableringsschema .
I följande exempel konfigureras ett manuellt schema med en agent etablerad på måndagsmorgnar från 12:00 till 05:00 EST.
Veckodagsschema
Om du väljer veckodagsschemat kan du ange en starttid och sluttid där det angivna antalet standby-agenter ska vara i vänteläge varje veckodag.
| Fastighet | beskrivning |
|---|---|
| Starttid | Den tid som etableringsperioden startar. |
| Sluttid | Den tid som etableringsperioden tar slut. |
| Antal etableringar | Antalet standby-agenter som ska etableras. Det här talet måste vara större än noll och får inte vara större än värdet Maximalt antal agenter som konfigurerats i Poolinställningar. |
I följande exempel konfigureras fyra agenter som ska användas under arbetstid med 0 agenter under icke-arbetstid och helger, med hjälp av Eastern Standard Time.
Schema för hela veckan
Om du väljer schemat för hela veckan kan du ange ett antal agenter som du vill ha tillgängliga dygnet innan.
Automatisk
Om du inte känner till dina användningsmönster och vill förlita dig på automatisk prognostisering baserat på tidigare data väljer du Automatisk. Du kan balansera mellan kostnad och agentprestanda med hjälp av ett skjutreglage med följande fem alternativ. Hanterade DevOps-pooler kör en fråga under de senaste tre veckornas historiska data (om tillgängligt), organiserar köade sessioner i poolen i fem minuter och tilldelar den angivna percentilen (för att undvika toppar) till varje timme.
-
Mest kostnadseffektiva (
MostCostEffective) – tionde percentilen -
Mer kostnadseffektiv (
MoreCostEffective) – 25:e percentilen -
Balanserad (standard) (
Balanced) – 50:e percentilen -
Mer prestanda (
MorePerformance) – 75:e percentilen -
Bästa prestanda (
BestPerformance) – 90:e percentilen
Agenternas livscykel och potentiella fördröjningar i allokeringen
Standby-agenter som använder ett tillståndslöst schema kräver att Azure Pipelines-agenten installeras och konfigureras innan de övergår från det klara tillståndet till det allokerade tillståndet och kör en pipeline. När Hanterade DevOps-pooler etablerar nya agenter försöker den ladda ned den senaste Azure Pipelines-agenten för att ha den redan nedladdad på standbyagenter innan de övergår till klart läge. Uppstart, anslutning och jobbets start kan ta allt från 10 sekunder till en minut beroende på poolens SKU-hastighet, bild som används och nätverksbelastning. Dessutom kan vissa inställningar i ett pipelinejobb orsaka en återinläsning och körning av en annan agent, och regressioner och återställningar av agenten kan också orsaka en åternedladdning av agenten. Redo agenter har alltid en potentiell fördröjning eftersom Hanterade DevOps-pooler använder den här agenten på ett "tillfälliga" sätt, vilket innebär att vi startar och kör uppgiftsagenten en gång per jobb.
Om du upplever fördröjningar med att tillgängliga agenter hämtar jobb från Azure DevOps, är följande viktigt att tänka på:
- Har du redo agenter? - Det vanligaste problemet är ett missförstånd om när agenter ska etableras i förväg. När antalet jobb i kö är större än antalet reservagenter i en pool, eller om jobben placeras i kö utanför förhandsetableringens schema, och antalet reservagenter är inställt till noll, måste nya datorer startas från grunden.
- Konfigurerar du väntelägesagenter med flera bilder korrekt? – Om du inte anger vilken avbildning som ska användas i din pipeline med ImageOverride-efterfrågan, riktas jobben mot den första avbildningen. Det innebär att du, beroende på dina skalningsinställningar, kanske inte har så många tillgängliga agenter som du kan förvänta dig eftersom vissa allokeras till andra avbildningar.
- Använder du ImageVersionOverride i dina pipelines? – När du använder
ImageVersionOverrideför att ange en annan avbildningsversion än vad som har konfigurerats i poolinställningarna startas varje agent på begäran med den angivna avbildningsversionen. Standby-agenter provisioneras med hjälp av de avbildningsversioner som anges i poolens konfiguration, så om du använderImageVersionOverride, kommer inga standby-agenter att matcha den versionen och en ny agent kommer att startas. - Påverkar inställningarna för proxy/VNet/brandvägg prestandan för din pool negativt? – Potentiell långsamhet från alla nätverksinställningar leder till att agenter tar längre tid att starta agenten och ansluta den till Azure DevOps.
- Åsidosättar du agentversionen? – Som standard körs Hanterade DevOps-pooler på den senaste versionen av Azure DevOps-uppgiftsagenten. Inställningar i Pipeline yaml (till exempel agent.versionsefterfrågan ) och Azure DevOps-organisationsinställningar kan tvinga pipelines att använda äldre versioner av aktivitetsagenten, vilket kräver en åternedladdning när en dator har allokerats.