Infrastruktur des Auto-Scaling-Agenten: Ein praktischer Schnellstart

Einführung in die Infrastruktur von auto-skalierbaren Agenten

In der Welt der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) sind Build-Agenten (oder Worker, Executor) unverzichtbar, da sie den Code kompilieren, Tests ausführen und Anwendungen bereitstellen. Mit dem Wachstum der Entwicklungsteams und der zunehmenden Komplexität der Projekte kann die Nachfrage nach diesen Agenten erheblich schwanken. Das manuelle Bereitstellen und Deprovisionieren von Agenten ist nicht nur zeitaufwendig, sondern führt auch zu Ineffizienzen: Entweder bleiben die Agenten inaktiv, was Geld kostet, oder die Builds stauen sich, was die Entwicklung verlangsamt. Hier wird die Infrastruktur von auto-skalierbaren Agenten unerlässlich.

Auto-Scaling ermöglicht es Ihrer Flotte von Agenten, ihre Kapazität dynamisch an die Nachfrage anzupassen. Wenn die Nachfrage nach Builds steigt, werden automatisch neue Agenten erstellt. Wenn die Nachfrage sinkt, werden inaktive Agenten gestoppt, was die Ressourcennutzung und die Kosten optimiert. Dieser Artikel bietet einen praktischen Leitfaden zur Implementierung von Auto-Scaling in Ihrer CI/CD-Agenteninfrastruktur, wobei der Fokus auf gängigen Modellen liegt und konkrete Beispiele bereitgestellt werden.

Warum Auto-Scaling? Die Hauptvorteile

• Kostenoptimierung: Zahlen Sie nur für die Ressourcen, die Sie nutzen. Inaktive Agenten in der Cloud sind eine direkte Belastung für Ihr Budget.
• Erhöhung des Durchsatzes: Beseitigen Sie die Warteschlangen von Builds. Mehr Agenten bedeuten mehr gleichzeitige Builds, was schnellere Rückmeldeschleifen für die Entwickler zur Folge hat.
• Erhöhte Zuverlässigkeit: Verteilen Sie die Arbeitslast auf mehrere Agenten, wodurch das Risiko eines einzelnen Ausfallpunkts verringert wird.
• Reduzierung der Betriebskosten: Automatisieren Sie den Skalierungsprozess und befreien Sie Ihr Team von manuellen Bereitstellungsaufgaben.
• Elastizität: Verwalten Sie mühelos unvorhersehbare Nachfragespitzen und -täler ohne manuelle Eingriffe.

Übliche Auto-Scaling-Architekturen

Obwohl die spezifischen Anforderungen je nach CI/CD-System und Cloud-Anbieter variieren, folgen die meisten Infrastrukturen von auto-skalierbaren Agenten einigen grundlegenden Modellen:

1. Cloud-Anbieter spezifische Auto-Scaling-Gruppen (ASG)

   Viele CI/CD-Systeme integrieren sich direkt in die cloud-spezifischen Auto-Scaling-Gruppen (z. B. AWS Auto Scaling Groups, Azure Virtual Machine Scale Sets, Google Cloud Managed Instance Groups). Sie definieren ein Basis-Image (AMI, VHD, VM-Image) für Ihren Agenten, spezifizieren Skalierungsrichtlinien (basierend auf CPU-Nutzung, Warteschlangenlänge, benutzerdefinierten Metriken), und der Cloud-Anbieter verwaltet das Lebenszyklusmanagement.

   Vorteile:

   • Stark in die Cloud-Infrastruktur integriert.
   • Verwendet bewährte Cloud-Dienste.
   • Oft am einfachsten für eine grundlegende Skalierung zu konfigurieren.

   Nachteile:

   • Kann weniger granular für die Kontrolle spezifischer Agententypen oder -bedingungen sein.
   • Gebunden an einen einzigen Cloud-Anbieter.

2. CI/CD-spezifische Integrationen

   Viele moderne CI/CD-Plattformen (z. B. Jenkins, GitLab CI, Buildkite, CircleCI, GitHub Actions) bieten ihre eigenen Auto-Scaling-Mechanismen oder direkte Integrationen mit verschiedenen Cloud-Anbietern/Container-Orchestratoren an. Dies beinhaltet oft einen “Controller” oder ein “Plugin”, das die Build-Warteschlange überwacht und bei Bedarf neue Agenten anfordert.

   Vorteile:

   • Optimiert für die spezifischen Bedürfnisse der CI/CD-Plattform.
   • Bietet oft eine ausgefeiltere Logik für die Bereitstellung von Agenten (z. B. spezifische Labels, Ressourcenanforderungen).
   • Kann heterogene Agententypen unterstützen.

   Nachteile:

   • Kann mehr Konfiguration im CI/CD-System selbst erfordern.
   • Manchmal weniger leistungsfähig als das native Cloud-Auto-Scaling bei sehr schnellen Änderungen.

3. Container-Orchestrierung (Kubernetes)

   Die Verwendung von Kubernetes als zugrunde liegende Infrastruktur für Ihre Agenten wird immer beliebter. Die Agenten funktionieren als flüchtige Pods, und der Cluster Autoscaler von Kubernetes (oder ähnliche Tools) kann die zugrunde liegende Knoten-Gruppe basierend auf den Anforderungen der wartenden Pods skalieren. Dies bietet immense Flexibilität und Ressourceneffizienz.

   Vorteile:

   • Hohe Dichte und Ressourcennutzung (mehrere Agenten pro Knoten).
   • Portabilität zwischen verschiedenen Cloud-Anbietern oder vor Ort.
   • Exzellente Option für flüchtige, auf Aufgaben basierende Workloads.

   Nachteile:

   • Höhere anfängliche Komplexität für die Einrichtung von Kubernetes selbst.
   • Erfordert, dass Sie Ihre Build-Umgebung containerisieren.

Schnellleitfaden: Praktische Beispiele

Lassen Sie uns praktische Beispiele erkunden, um Auto-Scaling mit zwei beliebten CI/CD-Tools und einem Kubernetes-zentrierten Ansatz einzurichten.

Beispiel 1: Jenkins mit AWS EC2 Spot Instances

Jenkins, ein weit verbreiteter Open-Source-Automatisierungsserver, bietet hervorragende Unterstützung für cloud-basiertes Auto-Scaling, insbesondere mit AWS EC2. Die Verwendung von Spot Instances kann die Kosten erheblich senken.

Voraussetzungen:

• Eine laufende Jenkins-Instanz (vorzugsweise auf EC2 oder einer dedizierten VM).
• Ein AWS-Konto mit den entsprechenden IAM-Berechtigungen (EC2, VPC, S3, wenn Sie S3 für Artefakte verwenden).
• Das Jenkins EC2-Plugin ist installiert.

Schritte:

1. Bereiten Sie ein EC2-AMI für Ihren Jenkins-Agenten vor:

   Starten Sie eine EC2-Instanz (z. B. t3.medium, Ubuntu LTS). Installieren Sie das Java Development Kit (JDK), alle erforderlichen Build-Tools (Maven, Gradle, npm, Docker CLI) und konfigurieren Sie den Jenkins-Agenten. Stellen Sie sicher, dass der Agent sich korrekt mit Ihrem Jenkins-Controller verbindet. Sobald er konfiguriert ist, erstellen Sie ein AMI aus dieser Instanz. Dieses AMI wird das Modell für Ihre auto-skalierbaren Agenten sein.

   # Beispielkonfiguration auf Ubuntu für einen grundlegenden Java-Agenten
   sudo apt update
   sudo apt install -y openjdk-11-jdk maven docker.io
   sudo usermod -aG docker jenkins # Angenommen, jenkins ist der Benutzer für den Agenten
   sudo systemctl enable docker
   sudo systemctl start docker
   
   # Manuelle Konfiguration des Jenkins-Agenten (zum Testen des AMIs)
   # Laden Sie agent.jar von Ihrem Jenkins-Controller herunter
   # java -jar agent.jar -jnlpUrl <ihre-jenkins-url>/computer/<agent-name>/slave-agent.jnlp -secret <secret> -workDir <path>
   
   # Sobald überprüft, erstellen Sie das AMI aus dieser EC2-Instanz.

2. Konfigurieren Sie das Jenkins EC2-Plugin:

   Gehen Sie zum Jenkins-Dashboard -> Jenkins verwalten -> Knoten und Clouds verwalten -> Clouds konfigurieren.

   Fügen Sie eine neue Cloud hinzu -> Amazon EC2.

   • Name: AWS-Spot-Agents
   • Amazon EC2-Anmeldeinformationen: Fügen Sie Ihren AWS-Zugriffsschlüssel und Ihren geheimen Schlüssel hinzu (oder verwenden Sie die IAM-Rolle für den Jenkins-Controller).
   • EC2-Regionen: Wählen Sie Ihre Region (z. B. us-east-1).
   • Instanzgrenze: Setzen Sie eine angemessene Grenze (z. B. 10), um übermäßige Kosten zu vermeiden.
   • SSH-Schlüssel: Wählen Sie einen vorhandenen SSH-Schlüssel für den Zugriff auf die Agenten aus.
   • Fügen Sie ein neues AMI hinzu:
   • AMI-ID: Geben Sie die ID des AMIs ein, das Sie erstellt haben.
   • Beschreibung: Java Build Agent Ubuntu
   • Labels: java-agent linux (wird von Jenkins-Jobs verwendet, um die Agenten auszuwählen).
   • Instanztyp: t3.medium (oder passend).
   • Verfügbarkeitszone: Wählen Sie Ihre bevorzugte AZ oder lassen Sie sie leer für zufällig.
   • Spot-Instanz: Aktivieren Sie dieses Kontrollkästchen.
   • Maximaler Spot-Preis: Setzen Sie ein maximales Gebot (z. B. 0.10).
   • Remote-Home-Verzeichnis: /home/jenkins
   • Remote-Benutzer: ubuntu (oder der Benutzer Ihres AMIs).
   • Verwendung: Only build jobs with label expressions matching this node.
   • Inaktivitätszeitüberschreitung: Setzen Sie eine Dauer (z. B. 10 Minuten), nach der ein inaktiver Agent gestoppt wird.
3. Testen Sie das Auto-Scaling:

   Erstellen Sie einen Jenkins-Job und konfigurieren Sie ihn so, dass er auf einem Agenten mit dem Label java-agent ausgeführt wird. Starten Sie mehrere Builds gleichzeitig. Sie sollten neue EC2 Spot-Instanzen in Ihrer AWS-Konsole sehen, die sich mit Jenkins verbinden. Sobald die Builds abgeschlossen sind und die Agenten für die konfigurierte Zeit inaktiv sind, werden sie beendet.

Beispiel 2: GitLab CI mit GitLab Runner auf Docker Machine

GitLab CI integriert sich nahtlos mit GitLab Runner, der für das Auto-Scaling über Docker Machine bei verschiedenen Cloud-Anbietern konfiguriert werden kann.

Voraussetzungen:

• Eine laufende GitLab-Instanz (SaaS oder selbst gehostet).
• Ein Server (z. B. EC2, VM), um den GitLab Runner-Manager zu hosten.
• Docker und Docker Machine auf dem Server des GitLab Runner-Managers installiert.
• Cloud-Anbieter-Anmeldeinformationen (z. B. AWS-Zugriffsschlüssel und geheime Schlüssel, die im Runner-Manager konfiguriert sind).

Schritte:

1. Installieren und Registrieren von GitLab Runner:

   Installieren Sie GitLab Runner auf Ihrem für den Runner-Manager vorgesehenen Server:

   curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
   sudo apt install gitlab-runner
   
   # Registrieren Sie den Runner (holen Sie sich Ihr Registrierungstoken aus den Einstellungen des GitLab-Projekts/der Gruppe)
   sudo gitlab-runner register 
    --url "https://gitlab.com/" 
    --registration-token "<Ihr-Registrierungstoken>" 
    --description "Docker Machine Auto-scaling Runner" 
    --tag-list "docker,aws" 
    --executor "docker+machine"

2. Konfigurieren Sie config.toml für Docker Machine:

   Ändern Sie die Konfigurationsdatei des Runners, die sich normalerweise unter /etc/gitlab-runner/config.toml befindet.

   Fügen Sie die Sektion [[runners]] hinzu/ändern Sie sie und fügen Sie eine Sektion [runners.docker] und [runners.machine] hinzu.

   [[runners]]
    name = "Docker Machine Auto-scaling Runner"
    url = "https://gitlab.com/"
    token = "<Ihr-Registrierungstoken>"
    executor = "docker+machine"
    [runners.docker]
    tls_verify = false
    image = "ubuntu:latest" # Standard-Image für Builds
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    [runners.machine]
    IdleCount = 1 # Mindestens eine inaktive Maschine beibehalten
    IdleTime = 600 # Beenden Sie inaktive Maschinen nach 10 Minuten
    MaxBuilds = 100 # Beenden Sie die Maschine nach 100 Builds
    MachineDriver = "amazonec2"
    MachineName = "gitlab-runner-%s"
    MachineOptions = [
    "amazonec2-instance-type=t3.medium",
    "amazonec2-ami=ami-0abcdef1234567890", # Verwenden Sie ein Basis-AMI mit vorinstalliertem Docker
    "amazonec2-region=us-east-1",
    "amazonec2-vpc-id=vpc-0123456789abcdef0",
    "amazonec2-subnet-id=subnet-0abcdef1234567890",
    "amazonec2-security-group=gitlab-runner-sg",
    "amazonec2-use-private-address=true",
    "amazonec2-tags=gitlab-runner-managed,project:my-project"
    ]
    # Optional: Konfigurieren Sie Docker Machine für Spot-Instanzen
    # MachineOptions = [
    # ...,
    # "amazonec2-request-spot-instance=true",
    # "amazonec2-spot-price=0.05",
    # ]
   

   Hinweis zur AMI: Für Docker Machine muss Ihre AMI Docker vorinstalliert haben und so konfiguriert sein, dass sie beim Booten startet. Docker Machine verwendet dann dieses AMI, um neue Instanzen bereitzustellen.

3. GitLab Runner neu starten:

   sudo gitlab-runner restart

4. Testen des Auto-Scaling:

   Pushen Sie einige Änderungen in ein GitLab-Repository, das einen CI-Pipeline auslöst. Starten Sie mehrere Pipelines gleichzeitig. Sie sollten neue EC2-Instanzen oder VMs in der gewählten Cloud sehen, die gestartet werden und Ihre Aufgaben ausführen. Nach einer Inaktivitätsphase werden sie beendet.

Beispiel 3: Kubernetes mit Cluster Autoscaler

Für hochdynamische und containerisierte Workloads bietet Kubernetes eine leistungsstarke Auto-Scaling-Lösung. Hier laufen Ihre CI/CD-Agenten als Pods, und der Cluster Autoscaler von Kubernetes passt den zugrunde liegenden Knotenpool an.

Voraussetzungen:

• Ein laufender Kubernetes-Cluster (z. B. EKS, AKS, GKE oder selbst verwaltet).
• kubectl konfiguriert, um auf Ihren Cluster zuzugreifen.
• Ein CI/CD-System, das in der Lage ist, Aufgaben als Kubernetes-Pods bereitzustellen (z. B. Jenkins Kubernetes-Plugin, GitLab CI Kubernetes-Executor, Tekton, Argo Workflows).

Schritte (Konzeptionell für den GitLab Kubernetes CI-Executor):

1. Bereitstellen des Cluster Autoscalers:

   Befolgen Sie die Dokumentation, um den Cluster Autoscaler für Ihren Cloud-Anbieter bereitzustellen (z. B. EKS Cluster Autoscaler, GKE Cluster Autoscaler). Diese Komponente überwacht wartende Pods und passt die Knotengruppen nach oben oder unten an.

   Beispiel (EKS – vereinfacht, siehe offizielle Dokumentation):

   # Erstellen Sie eine IAM-Richtlinie für den Cluster Autoscaler
   # Erstellen Sie eine IAM-Rolle und fügen Sie die Richtlinie hinzu
   # Erstellen Sie ein Dienstkonto und verknüpfen Sie es mit der IAM-Rolle
   # Bereitstellen des Deployments des Cluster Autoscalers mit Helm oder YAML
   
   # Beispielbefehl Helm für den Cluster Autoscaler EKS
   helm upgrade --install cluster-autoscaler stable/cluster-autoscaler \
    --namespace kube-system \
    --set autoDiscovery.clusterName=<Ihr-Cluster-Name> \
    --set rbac.create=true \
    --set serviceAccount.create=true \
    --set serviceAccount.name=cluster-autoscaler \
    --set image.repository=k8s.gcr.io/cluster-autoscaler \
    --set image.tag=v1.22.0 # Entspricht Ihrer K8s-Version
   

2. Konfigurieren Sie dynamische Knotengruppen/Knotenpools:

   Stellen Sie sicher, dass Ihr Kubernetes-Cluster Gruppen/Pools von Knoten für das Auto-Scaling konfiguriert hat. Definieren Sie minimale und maximale Größen für diese Gruppen.

   Beispiel (GKE):

   gcloud container node-pools create ci-agents-pool \
    --cluster <Ihr-Cluster-Name> \
    --machine-type=e2-medium \
    --num-nodes=0 \
    --min-nodes=0 \
    --max-nodes=10 \
    --enable-autoscaling \
    --region=<Ihre-Region>

3. Konfigurieren Sie das CI/CD-System zur Verwendung des Kubernetes-Executors:

   Für GitLab CI registrieren Sie einen Runner mit dem Kubernetes-Executor. Dieser Executor startet einen neuen Pod für jede Aufgabe.

   sudo gitlab-runner register 
    --url "https://gitlab.com/" 
    --registration-token "<Ihr-Registrierungstoken>" 
    --description "Kubernetes CI Runner" 
    --tag-list "kubernetes,docker" 
    --executor "kubernetes"

   Bearbeiten Sie /etc/gitlab-runner/config.toml:

   [[runners]]
    name = "Kubernetes CI Runner"
    url = "https://gitlab.com/"
    token = "<Ihr-Registrierungstoken>"
    executor = "kubernetes"
    [runners.kubernetes]
    host = "" # Leer lassen für die Cluster-Konfiguration
    namespace = "gitlab-runner"
    cpu_limit = "500m"
    memory_limit = "1Gi"
    image = "docker:20.10.16-dind-rootless" # Oder Ihr bevorzugtes Basis-Image
    pull_policy = ["if-not-present", "always"]
    # Optional: Konfigurieren Sie ein Basis-Image für Ihre Builds
    # helper_image = "gitlab/gitlab-runner-helper:latest"
   

4. Testen des Auto-Scaling:

   Starten Sie mehrere CI/CD-Pipelines. Beobachten Sie neue Pods, die im Namespace gitlab-runner erstellt werden. Wenn nicht genügend Knoten vorhanden sind, wird der Cluster Autoscaler neue Knoten in Ihrem ci-agents-pool bereitstellen. Sobald die Aufgaben abgeschlossen sind, werden die Pods gestoppt und die inaktiven Knoten reduziert.

Best Practices für Auto-Scaling-Agenten

• Verwenden Sie Unveränderliche Agentenbilder: Erstellen Sie Ihre Agentenbilder (AMIs, Docker-Images) mit allen notwendigen vorinstallierten Tools. Dies gewährleistet Konsistenz und beschleunigt die Startzeiten der Agenten.
• Verwenden Sie Spot-/Preemptible-Instanzen: Für nicht kritische oder fehlertolerante Builds kann die Verwendung von Spot-Instanzen die Kosten erheblich senken. Implementieren Sie eine Retry-Logik in Ihrem CI/CD, wenn Aufgaben unterbrochen werden könnten.
• Konfigurieren Sie eine Aggressive Reduzierung: Um die Kosten zu optimieren, konfigurieren Sie die Agenten so, dass sie schnell beendet werden, nachdem sie inaktiv geworden sind.
• Setzen Sie Limits für Instanzen: Setzen Sie immer maximale Limits für Ihre Auto-Scaling-Gruppen oder Knotenpools, um unerwartete Kostenüberschreitungen zu vermeiden.
• Überwachen Sie Ihre Infrastruktur: Behalten Sie die Build-Warteschlangen, die Nutzung der Agenten und die Cloud-Kosten im Auge. Passen Sie die Skalierungsrichtlinien bei Bedarf an.
• Optimieren Sie die Startzeit der Agenten: Minimieren Sie die Zeit, die benötigt wird, damit ein Agent bereit ist. Dazu gehört die Optimierung der Bildgröße, die effiziente Nutzung von cloud-init-Skripten und das Caching von Abhängigkeiten.
• Verwenden Sie Labels/Tags für Granularität: Verwenden Sie Labels (Jenkins, Kubernetes) oder Tags (GitLab), um spezifische Aufgaben an Agenten mit den richtigen Fähigkeiten zuzuweisen (z. B. java-17, node-lts, gpu-enabled).
• Berücksichtigen Sie Temperierte Pools: Für Szenarien, in denen schnelle Skalierbarkeit entscheidend ist, halten Sie einen kleinen “temperierten Pool” inaktiver Agenten bereit, die sofort Aufgaben übernehmen können, während Sie zusätzliche Skalierung nach Bedarf ermöglichen.

Fazit

Eine Auto-Scaling-Agenteninfrastruktur ist kein Luxus mehr, sondern eine Notwendigkeit für moderne CI/CD-Pipelines. Durch die dynamische Anpassung Ihrer Agentenkapazität können Sie erhebliche Einsparungen erzielen, die Produktivität der Entwickler durch schnellere Rückmeldungen verbessern und ein widerstandsfähigeres und elastischeres Liefersystem aufbauen. Egal, ob Sie Cloud-Anbieter-Auto-Scaling-Gruppen, CI/CD-spezifische Integrationen oder einen Kubernetes-zentrierten Ansatz wählen, die Prinzipien bleiben gleich: automatisieren, optimieren und skalieren, um der Nachfrage gerecht zu werden. Beginnen Sie mit einer einfachen Konfiguration, überwachen Sie deren Leistung und verfeinern Sie schrittweise Ihre Auto-Scaling-Strategie, um den Bedürfnissen Ihres Teams perfekt zu entsprechen.

🕒 Published: March 29, 2026