Konfigurera skalning

Du kan hantera prestanda och kostnader för instansen av hanterade DevOps-pooler genom att konfigurera skalningsinställningar. Information om priser och prestanda finns i Hantera kostnader och prestanda.

Agenttillstånd

Du kan konfigurera pooler som:

  • Tillståndslös: Tillhandahåll en ny agent för varje jobb.
  • Stateful: Tillåt delning av agenter mellan flera jobb.

Standardinställningen för en pool är stateless, vilket du kan uppnå genom att använda inställningen Varje gång ny agent. 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. En agent kan återanvändas i högst sju dagar som standard, men du kan konfigurera den så att den återanvänds tidigare.

Kommentar

Säkerhetsagenter rekommenderar att användare använder tillståndslösa pooler som skydd mot leveranskedjeattacker. Använd agenttillståndsinställningen Fresh agent varje gång.

Tillståndslösa pooler

När du konfigurerar en tillståndslös agent skaffas en ny agent för varje jobb. Agenten tas bort när jobbet har slutförts.

Mer information om livscykeln för tillståndslösa agenter och hur de används i Azure Pipelines finns i avsnittet Livscykel för agenter och potentiella fördröjningar i allokering .

Skärmbild som visar en tillståndslös agent.

När du anger Agenttillstånd till Fresh agent varje gång, anskaffas en ny agent för varje jobb. Agenten tas bort när jobbet har slutförts.

Tillståndskänsliga pooler

Skärmbild som visar en tillståndskänslig agent.

När du aktiverar Samma agent kan användas av flera versioner ( "kind": "stateful" inställningen i resursmallar eller { "stateful": {...} } inställningen i Azure CLI) är agenterna i poolen tillståndskänsliga. Du kan konfigurera tillståndskänsliga pooler med hjälp av följande inställningar:

  • Maximal livstid 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 kasseras. Formatet för Max time to live för standby-agenter är dd.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).

  • Grace Period (gracePeriodTimeSpan) konfigurerar hur länge en agent i en tillståndskänslig pool väntar på nya jobb innan den stängs av efter att alla aktuella och köade jobb har slutförts. Formatet för respitperiod är dd.hh:mm:ss och standardvärdet är ingen respitperiod.

    Viktigt!

    Om ett jobb körs när intervallet för maximal livslängd för standby-agenter upphör, stängs inte agenten av förrän jobbet slutförts, såvida inte jobbet tar mer än två dagar att genomföra. Enskilda jobb i Hanterade DevOps-pooler kan köras i högst två dagar, även om de körs på en standby-agent med mer än två dagar konfigurerade för Max tid att leva 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.

Agenter i tillståndslösa pooler stängs av och kasseras efter varje jobb. Agenter i tillståndskänsliga pooler fortsätter att köras om något av följande villkor uppfylls:

  • Om ett annat jobb placeras i kö när det första jobbet är klart skickar Managed DevOps Pools det köade 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 agenterna på nya jobb under den tid 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åndsbevarande pooler stängs av och kasseras om de körs kontinuerligt under den tid som anges av Maximal livstid för standby-agenter, även om de tidigare villkoren är uppfyllda. Om maximal tid att leva för reservagenter till exempel har konfigurerats till tre dagar och reservagentläge är inställt på Manuellt, alla veckoschema (maskiner tillgängliga 24/7), startar agenterna om efter tre kontinuerliga dagar av drifttid.

Viktigt!

Agenter i tillståndskänsliga pooler kan fortfarande stängas av och kasseras 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 kasseras går alla tillstånd förlorade.

Grace-perioder möjliggör det mest ekonomiska sättet att driva stateful pooler för pipelines med jämn belastning. Respitperioder 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. När standbyagentläget är inaktiverat finns det inga standbyagenter att omedelbart tilldela till dina pipelines. Era pipelines kan behöva vänta från några minuter 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 du konfigurerar ett väntelägesagentschema jämför Hanterade DevOps-pooler regelbundet antalet etablerade agenter med antalet standby-agenter som du anger i det aktuella etableringsschemat. Den 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 värdet Maximalt antal agenter som du konfigurerar i Poolinställningar.

Du kan konfigurera standby-agentläge med hjälp av följande inställningar:

  • Av: Vilolägesagent är inaktiverat och agenter tilldelas 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. Du kan konfigurera den för kostnad och prestanda.

Skärmbild som visar valen för standby-agentläge.

Manuell

Manuellt läge passar bäst för team som känner till användningsmönster för kontinuerlig integrering och kontinuerlig leverans (CI/CD). När du använder det manuella alternativet måste du definiera ditt förberedelseschema. Du definierar ditt schema baserat på din förståelse av vilka agenter i poolen som mest sannolikt kommer att användas och hur många agenter som sannolikt kommer att användas. Du anger ett tilldelningsantal agenter som ska uppfylla den beräknade efterfrågan.

Du kan skapa ett eget distributionschema eller välja något av de fördefinierade schemana. 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.

Du kan konfigurera manuella standby-agenter på något av följande tre sätt:

Var och en av snabbstarterna för företablering har följande vanliga inställningar (utöver de inställningar som är specifika för den snabbstarten):

  • Tidszon för prekonfigurering: Så att du kan ställa in tidszonen för perioderna i din prekonfigureringsplan. Standardvärdet för Pre-provisioning TimeZone är (UTC) Coordinated Universal Time.The default value for Pre-provisioning TimeZone is (UTC) Coordinated Universal Time.
  • Standbyagenters procentandel: Konfigurerar procentandelen Standby-agenter som du vill använda för varje bild. 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. När du använder Azure Resource Manager-mallar (ARM-mallar) kan du konfigurera inställningen För standby-agentprocent i images avsnittet. Mer information finns i Konfigurera avbildningar.

Skärmbild som visar manuellt vänteläge.

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 ditt etableringsschema. Varje tilldelningsperiod består av en startdag, en slutdag, en tidszon, en starttid, en sluttid och ett antal. Etableringsperioder kan inte överlappa varandra.

Fastighet beskrivning
Flerdagars När du väljer det här alternativet kan du konfigurera både startdag och slutdag för ditt etableringsschema.
Till nästa period När du väljer det här alternativet körs etableringsperioden från starttidsvärdet till början av nästa etableringsperiod.
Startdag Dagen då etableringsperioden startar.
Slutdag Dagen då provisioneringsperioden upphör. Krävs om flera dagar har valts.
Starttid Den tid då tilldelningsperioden startar.
Sluttid Den tidpunkt då etableringsperioden slutar. Krävs såvida inte Till nästa period har valts.
Räkna 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 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 visas hur du konfigurerar ett manuellt schema med en agent som etableras på måndagsmorgnar från 12:00 till 05:00 EST.

Skärmbild som visar ett manuellt skalningsschema.

Veckodagsschema

Om du väljer veckodagsschemat kan du ange en starttid och sluttid, mellan vilken det angivna antalet standby-agenter är i vänteläge varje veckodag.

Fastighet beskrivning
Starttid Den tid då tilldelningsperioden startar.
Sluttid Den tidpunkt då etableringsperioden slutar.
Antal provisioneringar 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 och inga agenter under lediga timmar och helger, med hjälp av Eastern Time (UTC-5).

Skärmbild som visar ett veckodagsschema.

Schema för hela veckan

Om du väljer schemat för hela veckan kan du ange det antal agenter som du vill ha tillgängliga hela tiden.

Skärmbild som visar ett schema för hela veckan.

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 förfrågan över de senaste tre veckornas historiska data, om sådana finns. Den organiserar köade sessioner i poolen i femminutersperioder och tilldelar den angivna percentilen (för att undvika toppar) till varje timme.

  • Mest kostnadseffektiva (MostCostEffective): tionde percentilen.
  • Mer kostnadseffektivt (MoreCostEffective): 25:e percentilen.
  • Balanserad (standard) (Balanced): 50:e percentilen.
  • Mer prestanda (MorePerformance): 75:e percentilen.
  • Bästa prestanda (BestPerformance): 90:e percentilen.

Skärmbild som visar inställningen för automatisk skalning.

Agenternas livscykel och potentiella fördröjningar i allokeringen

När du aktiverar standby-agenter med hjälp av ett tillståndslöst schema måste du installera och konfigurera Azure Pipelines-agenten innan du övergår från det klara tillståndet till det allokerade tillståndet och kör en pipeline.

När hanterade DevOps-pooler tillhandahåller nya agenter försöker den ladda ned den senaste Azure Pipelines-agenten så att den redan laddas ned på standby-agenter innan de övergår till färdig status. Start, anslutning och början av jobbet kan ta allt från 10 sekunder till en minut beroende på poolens SKU-hastighet, den avbildning som används och nätverksbelastningen. När du anger vissa inställningar i ett pipelinejobb kan det dessutom orsaka en ny nedladdning och körning av en annan agent. Regressioner och återgångar av agenten kan också orsaka en omladdning av agenten.

Färdiga agenter har alltid en potentiell fördröjning eftersom Hanterade DevOps-pooler använder den här agenten på ett "tillfälligt" sätt, vilket innebär att vi startar och kör uppgiftsagenten en gång per jobb. Om du ser fördröjningar hos agenter som är beredda att hämta jobb från Azure DevOps, bör du överväga följande frågor:

  • Har du redo agenter? Det vanligaste problemet är ett missförstånd om när agenter ska förkonfigureras i förväg. Datorer måste snurras upp från grunden när följande villkor uppfylls:
    • Antalet jobb i kö är större än antalet väntelägesagenter i en pool.
    • Jobb placeras i kö utanför företableringsschemat.
    • Antalet standbyagenter är inställt till noll.
  • Konfigurerar du väntelägesagenter som har flera bilder på rätt sätt? Om du inte anger vilken bild som ska användas i din pipeline med hjälp av kravet ImageOverride, riktar sig jobben mot den första bilden. Beroende på dina skalningsinställningar kanske du inte har så många agenter tillgängliga som du förväntar dig, eftersom vissa allokeras till andra avbildningar.
  • Använder du ImageVersionOverride-efterfrågan i dina pipelines? När du använder ImageVersionOverride begäran för att ange en annan avbildningsversion än vad som har konfigurerats i poolinställningarna startar varje agent på begäran med den angivna avbildningsversionen. Standby-agenter etableras med hjälp av de avbildningsversioner som anges i poolens konfiguration. Om du använder ImageVersionOverridematchar inte väntelägesagenter den versionen och en ny agent startar.
  • Saktar proxy-, virtuellt nätverk eller brandväggsinställningar ner poolen? 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 Managed DevOps-pooler på den senaste versionen av Azure DevOps-uppgiftsagenten. Inställningar i YAML-pipelinen (till exempel Agent.Version efterfrå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.