Ga naar inhoud

Build agents in het netwerk

Elke Azure DevOps-job (een build, een deployment, alles) draait op een agent. Microsoft-hosted agents worden beheerd door Microsoft, maar ze draaien buiten je netwerk en kunnen private endpoints niet bereiken. Een self-hosted agent pool binnen het platformnetwerk kan dat wel. Deze pagina legt uit hoe zo'n gedeelde pool meestal is opgebouwd (een VM-gebaseerd en een container-gebaseerd voorbeeld), hoe je hem gebruikt en wat je doet als het OS-image van de pool verandert.

Platformspecifiek

Of je platform een gedeelde agent pool aanbiedt, en wat de naam, de grootte en het OS-image zijn, hangt af van je platform. Het onderstaande poolontwerp is een voorbeeld. De pools die de MCP-pipelines voor het platform zelf gebruiken (zie Job runners) zijn voor platformdeployments. Vraag je platformteam welke pool je mag gebruiken. De korte samenvatting staat bij Shared services. Het platformteam beheert de pool, of je beheert hem zelf in het zelfbeheerde model (Beheermodellen).

Voorbeeldontwerp van een gedeelde pool

Onderwerp Voorbeeld
Compute Een Virtual Machine Scale Set in de shared services van de hub, gekoppeld aan Azure DevOps als agent pool
Image Gebouwd in een private Shared Image Gallery en volgens schema ververst (bijvoorbeeld elke zondag) vanuit dezelfde bron als het image van de Microsoft-hosted agents. De pool biedt dezelfde tools als de Microsoft-hosted agents, lijst met geïnstalleerde software.
OS In het voorbeeld alleen Linux
Levenscyclus Agents worden na elk gebruik afgebroken, zodat er geen secrets of certificaten achterblijven
Schaling Een maximumaantal VM's in de scale set, een aantal agents dat stand-by blijft, en een vertraging voordat inactieve agents worden verwijderd
Netwerk Een eigen subnet in het shared services-netwerk van de hub, verbonden met de spokes (via Virtual WAN)
Firewall HTTPS (en SQL) van het agent-subnet naar Azure-bestemmingen. Al het andere vraagt een firewallregel.
Toegang tot de Azure-resources van de pool Alleen het platformteam
Uitval van de image-pipeline Bestaande agents blijven werken. Nieuwe images worden niet uitgerold totdat de pipeline is hersteld. De gebruikelijke oorzaak is een wijziging in de upstream image-repository.

Securitymodel. De pool is beschikbaar voor alle aangesloten workload teams, maar een job kan alleen doen wat de service principal van jouw pipeline mag. Die service principal wordt aangemaakt met je spoke en heeft de rechten van je spoke (Wat je krijgt). De eerste keer dat een pipeline een service connection gebruikt, moet jouw team die autoriseren, zodat een pipeline van een ander team jouw service principal niet kan gebruiken. Omdat de agent na gebruik wordt afgebroken, kunnen er achteraf geen credentials uit worden gehaald.

De pool gebruiken

  1. Vraag je platformteam om toegang tot de pool en om de naam van de pool. Staat je pipeline in een ander Azure DevOps-project dan het project dat de pool bezit, dan moet de pool ook beschikbaar worden gemaakt voor dat project.
  2. Stel de pool in in je YAML-pipeline:
trigger:
  batch: true
  branches:
    include:
      - main

pool: <agent pool name>

variables:
  - group: "<variable group>"

stages:
  # your stages
  1. Gebruik een service connection die bij je spoke hoort (Azure DevOps).

Pooltypen en hun limieten (VM-gebaseerd en container-gebaseerd) staan beschreven bij Shared services.

Voorbeeld: container-gebaseerde pool op Container Apps jobs

Een container-gebaseerde pool draait elke pipelinejob in een eigen container op Azure Container Apps jobs. Een scaler houdt de wachtrij van de Azure DevOps-pool in de gaten en start één container per wachtende job. De container registreert zich als agent, draait die ene job, verwijdert zichzelf uit de pool en stopt. Als er niets in de wachtrij staat, draait er niets.

Onderwerp Voorbeeld
Levenscyclus Eén verse container per job. Daarna blijven er geen bestanden of credentials achter.
Schaling Van 0 tot een maximumaantal containers (25 in het voorbeeld), de wachtrij wordt elke 10 seconden gecontroleerd
Starttijd Ongeveer 50 seconden als de node warm is, 3 tot 4 minuten als hij koud is (eerste job na een rustige periode)
Grootte 1 vCPU en 2 GiB geheugen per job
Tijdslimiet Een job wordt in het voorbeeld na 30 minuten gestopt
Identiteit De container gebruikt een managed identity om zijn image op te halen en zich in Azure DevOps te registreren. Wat je job in Azure mag, komt uit je service connection, zoals bij elke andere pool.
Netwerk In een subnet van een spoke. Uitgaand verkeer loopt via de hub firewall.
OS Linux, als container image

Koude starts zijn de prijs van schalen vanaf nul. Als je platform één agent draaiend houdt, start de eerste job sneller, tegen een constante kostenpost voor het platform.

Tools in het container image

Het voorbeeldimage is klein. Het is gebaseerd op Ubuntu 22.04 en bevat de Azure CLI, PowerShell, git, curl, jq, unzip, wget, rsync en een SSH-client. De agent draait als niet-root gebruiker en er is geen Docker daemon. Dit verschilt van de VM-gebaseerde pool, die de tools van het Microsoft-hosted image heeft.

  • Installeer wat je nodig hebt in de pipeline met de tasks uit Ontbrekende tools in de pipeline installeren. De agent kan alleen downloaden van bestemmingen die de firewall toestaat (in het voorbeeld HTTPS 443), dus een download vanaf een andere poort of een gewone HTTP-URL mislukt. Vraag een firewallregel aan als je een andere bron nodig hebt.
  • Container images bouwen zonder Docker daemon: zie de opties bij Shared services.
  • Houd jobs kort. Splits een lange job in stages, want een job die langer draait dan de tijdslimiet wordt gestopt.
  • Pin de versies van je tools in de pipeline, want het image van de pool kan veranderen.

Een container-gebaseerde pool gebruiken

  1. Vraag het platformteam om de poolnaam en om toegang. De pool bestaat op organisatieniveau, dus hij moet aan je Azure DevOps-project worden gekoppeld (Project settings, Pipelines, Agent pools, Add pool, Existing pool).
  2. Stel de pool in in je pipeline, zoals bij De pool gebruiken. Een eerste run kan een paar minuten duren door de koude start.
  3. Gebruik een service connection die bij je spoke hoort.
Symptoom Oorzaak
The pool does not exist or has not been authorized for use De pool is niet aan je project gekoppeld, of je pipeline mag hem niet gebruiken
De job wacht lang voordat hij start Een koude start (3 tot 4 minuten), of het maximumaantal containers is in gebruik
De job stopt na 30 minuten De tijdslimiet van de job
Een tool ontbreekt Installeer hem in de pipeline

Hoe het platformteam deze pool deployt en beheert: Container agent pool.

Als het OS-image van de pool verandert

Het OS van het image raakt uiteindelijk uit support, en het platformteam vervangt het (bijvoorbeeld Ubuntu 20.04 door 24.04). De tools in het nieuwe image zijn andere versies, en sommige tools zijn niet meer geïnstalleerd. Pipelines die daarvan afhangen, gaan stuk. Het platformteam hoort de wijziging aan te kondigen, met de datum, de lijst met verschillen en een manier om te testen.

Wat je doet:

  1. Lees de aankondiging en de lijst met verschillen. De softwarelijsten van de Microsoft-hosted images staan op GitHub.
  2. Draai je pipelines vóór de overstap tegen het nieuwe image als het platformteam een testpool of een testdatum aanbiedt.
  3. Herstel pipelines die een ontbrekende tool of versie gebruiken: installeer de tool in de pipeline voordat je hem gebruikt.

Een voorbeeld van wat er veranderde bij één echte image-upgrade (Ubuntu 20.04 naar 24.04):

Gebied Wijziging
Runtimes Node.js 18 naar 20, Python 3.8 naar 3.12, Ruby 2.7 naar 3.2, Perl, Bash, GNU-compilers nieuwer
Uit het image verwijderd Terraform, NuGet, Mono en MSBuild, Erlang, Sbt, Heroku, enkele CLI-tools (Netlify, Vercel, OpenShift, ORAS, Alibaba Cloud), PhantomJS, R, SVN, MongoDB, sqlcmd en SqlPackage
Tools met een nieuwe versie Ansible, Bicep, Docker, Podman, Pulumi, OpenSSL, PostgreSQL, browsers
.NET Minder SDK-versies geïnstalleerd (bijvoorbeeld alleen 8.0 op het 24.04-image destijds)

Zie deze tabel als illustratie. De lijst van het image dat je echt krijgt staat op de GitHub-pagina van het image (Ubuntu2404-Readme.md voor Ubuntu 24.04).

Ontbrekende tools in de pipeline installeren

Tool Task Opmerkingen
Node.js UseNode@1 Stel version in, bijvoorbeeld '18.x'
Python UsePythonVersion@0 Het downloaden van Python-versies wordt op self-hosted agents niet ondersteund. Alleen vooraf geïnstalleerde versies kunnen worden gekozen.
NuGet NuGetCommand@2 Om dependencies van een project of solution te herstellen
.NET SDK UseDotNet@2 Stel version in, bijvoorbeeld '6.x'
Terraform TerraformInstaller@1 Stel terraformVersion in op latest of op een specifieke versie 
- task: UseNode@1
  displayName: 'Install Node.js'
  inputs:
    version: '18.x'

- task: UseDotNet@2
  displayName: 'Install .NET SDK'
  inputs:
    version: '6.x'

- task: ms-devlabs.custom-terraform-tasks.custom-terraform-installer-task.TerraformInstaller@1
  displayName: 'Install Terraform'
  inputs:
    terraformVersion: '<version>'

Gebruikt je team gedeelde pipeline-templates voor Terraform, kijk dan of ze een parameter voor de Terraform-versie hebben. Pin de versie in je pipeline zodra het nieuwe image live is, zodat een later image hem niet ongemerkt wijzigt.

Voor platformteams: de pool beheren

  • Kondig wijzigingen van het OS-image ruim voor het einde van de support aan, met de tabel met verschillen (genereer die uit de twee upstream softwarelijsten) en een testpool of een testvenster.
  • Monitor de image-pipeline, en de grootte en wachttijden van de pool. In het voorbeeldontwerp was er geen actieve monitoring: controleer of dat voor jouw teams voldoende is.
  • Begin met eenvoudige schalingswaarden en pas ze aan als meer teams de pool gebruiken.
  • Review de firewallregel voor het agent-subnet als de set spokes verandert.
  • Documenteer wie de pool mag gebruiken en hoe een team toegang krijgt.
  • Wijzig voor een container-gebaseerde pool het image door een nieuwe tag te pushen, en kondig de wijzigingen in de tools aan zoals bij een VM-image. De toolslijst van het voorbeeldimage is kort, dus de verschillen zijn klein. Zie Container agent pool.