Einführung in die Auto-Scaling Agenten-Infrastruktur
In der Welt der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) sind Build-Agenten (oder Arbeiter, Runner, Executor) die Arbeitspferde, die Code kompilieren, Tests ausführen und Anwendungen bereitstellen. Wenn Entwicklungsteams wachsen und die Komplexität der Projekte zunimmt, kann die Nachfrage nach diesen Agenten drastisch schwanken. Das manuelle Bereitstellen und Entfernen von Agenten ist nicht nur zeitaufwändig, sondern führt auch zu Ineffizienzen: entweder sitzen Agenten untätig herum und kosten Geld, oder Builds stauen sich, was die Entwicklung verlangsamt. Hier wird die Auto-Scaling Agenten-Infrastruktur unentbehrlich.
Auto-Scaling ermöglicht es Ihrer Agentenflotte, ihre Kapazität dynamisch basierend auf der Nachfrage anzupassen. Wenn es einen Anstieg bei Build-Anfragen gibt, werden automatisch neue Agenten erstellt. Wenn die Nachfrage nachlässt, werden untätige Agenten beendet, was die Ressourcennutzung und die Kosten optimiert. Dieser Artikel bietet einen praktischen Schnellstart zur Implementierung von Auto-Scaling für Ihre CI/CD-Agenteninfrastruktur, konzentriert sich auf häufige Muster und bietet umsetzbare Beispiele.
Warum Auto-Scaling? Die wichtigsten Vorteile
- Kostenoptimierung: Zahlen Sie nur für die Ressourcen, die Sie nutzen. Untätige Agenten in der Cloud belasten Ihr Budget direkt.
- Verbesserte Durchsatzrate: Eliminieren Sie Build-Warteschlangen. Mehr Agenten bedeuten mehr gleichzeitige Builds, was schnellere Rückmeldungszyklen für Entwickler zur Folge hat.
- Erhöhte Zuverlässigkeit: Verteilen Sie Arbeitslasten auf mehrere Agenten, was das Risiko eines einzelnen Ausfallpunkts verringert.
- Reduzierter Betriebsaufwand: Automatisieren Sie den Skalierungsprozess, um Ihr Team von manuellen Bereitstellungsaufgaben zu befreien.
- Elastizität: Bewältigen Sie nahtlos unvorhersehbare Spitzen und Täler in der Nachfrage ohne manuelles Eingreifen.
Gemeinsame Auto-Scaling-Architekturen
Obwohl die Einzelheiten je nach CI/CD-System und Cloud-Anbieter variieren, folgen die meisten Auto-Scaling-Agenten-Infrastrukturen einigen Kernmustern:
-
Auto-Scaling-Gruppen des Cloud-Anbieters (ASG)
Viele CI/CD-Systeme integrieren sich direkt in die anbieter-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, legen Skalierungspolitiken fest (basierend auf CPU-Auslastung, Warteschlangenlänge, benutzerdefinierten Metriken), und der Cloud-Anbieter übernimmt das Lifecycle-Management.
Vorteile:
- Hoch integriert mit der Cloud-Infrastruktur.
- Verwendet solide, bewährte Cloud-Dienste.
- Oft am einfachsten für die grundlegende Skalierung einzurichten.
Nachteile:
- Kann weniger granular bei der Steuerung spezifischer Agententypen oder Bedingungen sein.
- Gebunden an einen einzigen Cloud-Anbieter.
-
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. Diese beinhalten oft einen “Controller” oder ein “Plugin”, das die Build-Warteschlange überwacht und nach Bedarf neue Agenten anfordert.
Vorteile:
- Optimiert für die spezifischen Bedürfnisse der CI/CD-Plattform.
- Bietet oft komplexere Logik für die Agentenbereitstellung (z. B. spezifische Labels, Ressourcenanforderungen).
- Kann heterogene Agententypen unterstützen.
Nachteile:
- Kann mehr Konfiguration innerhalb des CI/CD-Systems selbst erfordern.
- Kann manchmal weniger leistungsfähig sein als native Cloud-Skalierung bei sehr schnellen Änderungen.
-
Container-Orchestrierung (Kubernetes)
Die Verwendung von Kubernetes als zugrunde liegende Infrastruktur für Ihre Agenten wird immer beliebter. Agenten laufen als ephemere Pods, und der Cluster Autoscaler von Kubernetes (oder ähnliche Tools) kann den zugrunde liegenden Knotenpool basierend auf ausstehenden Pod-Anfragen skalieren. Dies bietet immense Flexibilität und Ressourceneffizienz.
Vorteile:
- Hohe Dichte und Ressourcennutzung (mehrere Agenten pro Knoten).
- Portabilität zwischen verschiedenen Cloud-Anbietern oder On-Premise.
- Exzellent für ephemere, arbeitsbasierte Lasten.
Nachteile:
- Höhere anfängliche Komplexität bei der Einrichtung von Kubernetes selbst.
- Erfordert die Containerisierung Ihrer Build-Umgebung.
Schnellstart: Praktische Beispiele
Lassen Sie uns praktische Beispiele für die Einrichtung von Auto-Scaling mit zwei beliebten CI/CD-Tools und einem Kubernetes-zentrierten Ansatz erkunden.
Beispiel 1: Jenkins mit AWS EC2 Spot-Instanzen
Jenkins, ein weit verbreiteter Open-Source-Automatisierungsserver, bietet hervorragende Unterstützung für die cloudbasierte Auto-Skalierung, insbesondere mit AWS EC2. Die Verwendung von Spot-Instanzen kann die Kosten erheblich senken.
Voraussetzungen:
- Eine laufende Jenkins-Instanz (vorzugsweise auf EC2 oder einer dedizierten VM).
- Ein AWS-Konto mit entsprechenden IAM-Berechtigungen (EC2, VPC, S3, wenn S3 für Artefakte verwendet wird).
- Jenkins EC2-Plugin installiert.
Schritte:
-
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 zunächst manuell erfolgreich eine Verbindung zu Ihrem Jenkins-Controller herstellt. Nachdem Sie konfiguriert haben, erstellen Sie ein AMI aus dieser Instanz. Dieses AMI wird die Vorlage für Ihre Auto-Scaling-Agenten sein.# Beispielsetup 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, der Jenkins-Benutzer für den Agenten sudo systemctl enable docker sudo systemctl start docker # Manuelle Jenkins-Agenten-Einrichtung (zum Testen des AMI) # Laden Sie agent.jar von Ihrem Jenkins-Controller herunter # java -jar agent.jar -jnlpUrl <your-jenkins-url>/computer/<agent-name>/slave-agent.jnlp -secret <secret> -workDir <path> # Nach der Überprüfung erstellen Sie ein AMI aus dieser EC2-Instanz. -
Konfigurieren Sie das Jenkins EC2-Plugin:
Gehen Sie zum Jenkins-Dashboard -> Verwalten Sie Jenkins -> Verwalten von Knoten und Clouds -> Clouds konfigurieren.
Fügen Sie eine neue Cloud hinzu -> Amazon EC2.
- Name:
AWS-Spot-Agents - Amazon EC2-Anmeldeinformationen: Fügen Sie Ihre AWS Access Key ID und Secret Access Key hinzu (oder verwenden Sie eine IAM-Rolle für den Jenkins-Controller).
- EC2-Regionen: Wählen Sie Ihre Region (z. B.
us-east-1). - Instanzobergrenze: Setzen Sie eine angemessene Obergrenze (z. B.
10), um unkontrollierte Kosten zu vermeiden. - SSH-Schlüsselpaar: Wählen Sie ein bestehendes Schlüsselpaar für den SSH-Zugriff auf Agenten aus.
- Neu AMI hinzufügen:
- AMI-ID: Geben Sie die ID des von Ihnen erstellten AMI ein.
- Beschreibung:
Ubuntu Java Build Agent - Labels:
java-agent linux(wird von Jenkins-Jobs verwendet, um Agenten auszuwählen). - Instanztyp:
t3.medium(oder geeignet). - Verfügbarkeitszone: Wählen Sie Ihre bevorzugte AZ oder lassen Sie sie leer für zufällig.
- Spot-Instanz: Aktivieren Sie dieses Kästchen.
- Spot-Maximalpreis: Setzen Sie ein maximales Gebot (z. B.
0.10). - Remote FS Root:
/home/jenkins - Remote-Benutzer:
ubuntu(oder den Benutzer Ihres AMI). - Verwendung:
Nur Build-Jobs mit Label-Ausdrücken, die mit diesem Knoten übereinstimmen. - Leerlaufbeendigungszeit: Setzen Sie eine Dauer (z. B.
10Minuten), nach der ein im Leerlauf befindlicher Agent beendet wird.
- Name:
-
Testen Sie das Auto-Scaling:
Erstellen Sie einen Jenkins-Job und konfigurieren Sie ihn so, dass er auf einem Agenten mit dem Label
java-agentausgeführt wird. Triggern Sie mehrere Builds gleichzeitig. Sie sollten sehen, dass neue EC2-Spot-Instanzen in Ihrer AWS-Konsole gestartet und mit Jenkins verbunden werden. Nachdem die Builds abgeschlossen sind und die Agenten für die konfigurierte Zeit im Leerlauf sind, werden sie beendet.
Beispiel 2: GitLab CI mit GitLab Runner auf Docker Machine
GitLab CI integriert sich nahtlos mit GitLab Runner, der so konfiguriert werden kann, dass er mit Docker Machine auf verschiedenen Cloud-Anbietern Auto-Scaling unterstützt.
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 GitLab Runner-Manager installiert.
- Cloud-Anbieter-Anmeldeinformationen (z. B. AWS Access Key ID und Secret Access Key, die auf dem Runner-Manager konfiguriert sind).
Schritte:
-
Installieren und Registrieren des GitLab Runners:
Installieren Sie auf Ihrem dedizierten Runner-Manager-Server GitLab Runner:
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 GitLab-Projekt-/Gruppeneinstellungen) sudo gitlab-runner register --url "https://gitlab.com/" --registration-token "<your-registration-token>" --description "Docker Machine Auto-scaling Runner" --tag-list "docker,aws" --executor "docker+machine" -
Konfigurieren Sie
config.tomlfür Docker Machine:Bearbeiten Sie die Konfigurationsdatei des Runners, normalerweise unter
/etc/gitlab-runner/config.toml.Fügen Sie den Abschnitt
[[runners]]hinzu/modifizieren Sie ihn und fügen Sie einen Abschnitt[runners.docker]und[runners.machine]hinzu.[[runners]] name = "Docker Machine Auto-scaling Runner" url = "https://gitlab.com/" token = "<dein-registrierungs-token>" 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 # Halte mindestens eine Maschine inaktiv IdleTime = 600 # Beende inaktive Maschinen nach 10 Minuten MaxBuilds = 100 # Beende die Maschine nach 100 Builds MachineDriver = "amazonec2" MachineName = "gitlab-runner-%s" MachineOptions = [ "amazonec2-instance-type=t3.medium", "amazonec2-ami=ami-0abcdef1234567890", # Verwende 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: Konfiguriere Docker Machine für Spot-Instanzen # MachineOptions = [ # ..., # "amazonec2-request-spot-instance=true", # "amazonec2-spot-price=0.05", # ]Hinweis zum AMI: Für Docker Machine muss dein AMI Docker vorinstalliert haben und so konfiguriert sein, dass es beim Booten startet. Docker Machine wird dieses AMI verwenden, um neue Instanzen bereitzustellen.
-
GitLab Runner neu starten:
sudo gitlab-runner restart -
Auto-Scaling testen:
Push einige Änderungen in ein GitLab-Repository, das eine CI-Pipeline auslöst. Trigger mehrere Pipelines gleichzeitig. Du solltest sehen, wie neue EC2-Instanzen (oder VMs in deiner gewählten Cloud) hochgefahren werden und deine Jobs ausführen. Nach einer Zeit der Inaktivität werden sie beendet.
Beispiel 3: Kubernetes mit Cluster Autoscaler
Für hochdynamische und containerisierte Workloads bietet Kubernetes eine leistungsfähige Auto-Scaling-Lösung. Hier laufen deine CI/CD-Agenten als Pods, und der Kubernetes Cluster Autoscaler passt den zugrunde liegenden Knotenpool an.
Voraussetzungen:
- Ein laufender Kubernetes-Cluster (z. B. EKS, AKS, GKE oder selbstverwaltet).
kubectlkonfiguriert zum Zugriff auf deinen Cluster.- Ein CI/CD-System, das in der Lage ist, Jobs als Kubernetes-Pods bereitzustellen (z. B. Jenkins Kubernetes-Plugin, GitLab CI Kubernetes-Executor, Tekton, Argo Workflows).
Schritte (konzeptionell für GitLab CI Kubernetes Executor):
-
Cluster Autoscaler bereitstellen:
Folge der Dokumentation zum Bereitstellen des Cluster Autoscalers, die auf deinen Cloud-Anbieter zugeschnitten ist (z. B. EKS Cluster Autoscaler, GKE Cluster Autoscaler). Diese Komponente überwacht wartende Pods und passt die Knotenpools an.
Beispiel (EKS – vereinfacht, siehe offizielle Doku):
# Erstelle eine IAM-Richtlinie für Cluster Autoscaler # Erstelle eine IAM-Rolle und befestige die Richtlinie # Erstelle ein Dienstkonto und assoziiere es mit der IAM-Rolle # Stelle das Cluster Autoscaler-Deployment mit Helm oder YAML bereit # Beispiel Helm-Befehl für EKS Cluster Autoscaler helm upgrade --install cluster-autoscaler stable/cluster-autoscaler \ --namespace kube-system \ --set autoDiscovery.clusterName=<dein-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 # Stimmt mit deiner K8s-Version überein -
Konfiguriere dynamische Knoten-Gruppen/Knoten-Pools:
Stelle sicher, dass dein Kubernetes-Cluster Knoten-Gruppen/Pools für Auto-Scaling konfiguriert hat. Definiere Mindest- und Höchstgrößen für diese Gruppen.
Beispiel (GKE):
gcloud container node-pools create ci-agents-pool \ --cluster <dein-cluster-name> \ --machine-type=e2-medium \ --num-nodes=0 \ --min-nodes=0 \ --max-nodes=10 \ --enable-autoscaling \ --region=<deine-region> -
CI/CD-System konfigurieren, um Kubernetes Executor zu verwenden:
Für GitLab CI registriere einen Runner mit dem Kubernetes-Executor. Dieser Executor wird für jeden Job einen neuen Pod hochfahren.
sudo gitlab-runner register --url "https://gitlab.com/" --registration-token "<dein-registrierungs-token>" --description "Kubernetes CI Runner" --tag-list "kubernetes,docker" --executor "kubernetes"Bearbeite
/etc/gitlab-runner/config.toml:[[runners]] name = "Kubernetes CI Runner" url = "https://gitlab.com/" token = "<dein-registrierungs-token>" executor = "kubernetes" [runners.kubernetes] host = "" # Leer lassen für die Konfiguration im Cluster namespace = "gitlab-runner" cpu_limit = "500m" memory_limit = "1Gi" image = "docker:20.10.16-dind-rootless" # Oder dein bevorzugtes Basis-Image pull_policy = ["if-not-present", "always"] # Optional: Konfiguriere ein Basis-Image für deine Builds # helper_image = "gitlab/gitlab-runner-helper:latest" -
Auto-Scaling testen:
Trigger mehrere CI/CD-Pipelines. Beobachte neue Pods, die im Namespace
gitlab-runnererstellt werden. Wenn nicht genügend Knoten vorhanden sind, wird der Cluster Autoscaler neue Knoten in deinemci-agents-poolbereitstellen. Sobald Jobs abgeschlossen sind, werden Pods beendet, und inaktive Knoten werden skaliert.
Best Practices für Auto-Scaling-Agenten
- Verwende unveränderliche Agenten-Images: Baue deine Agenten-Images (AMIs, Docker-Images) mit allen notwendigen Tools vorinstalliert. Dies gewährleistet Konsistenz und beschleunigt die Startzeiten der Agenten.
- Verwende Spot-/Preemptible-Instanzen: Für nicht-kritische oder fehlertolerante Builds kann die Verwendung von Spot-Instanzen die Kosten erheblich senken. Implementiere eine Retry-Logik in deinem CI/CD, wenn Jobs unterbrochen werden könnten.
- Konfiguriere aggressive Abschaltung: Um Kosten zu optimieren, konfiguriere Agenten so, dass sie schnell beendet werden, nachdem sie inaktiv geworden sind.
- Setze Instanzobergrenzen: Definiere immer maximale Grenzen für deine Auto-Scaling-Gruppen oder Knoten-Pools, um unerwartete Kostenüberschreitungen zu vermeiden.
- Überwache deine Infrastruktur: Behalte Build-Warteschlangen, Agenten-Nutzung und Cloud-Kosten im Auge. Passe die Skalierungsrichtlinien nach Bedarf an.
- Optimiere die Startzeit der Agenten: Minimieren die Zeit, die benötigt wird, bis ein Agent bereit ist. Dies umfasst die Optimierung der Bildgröße, die effiziente Nutzung von Cloud-Init-Skripten und das Caching von Abhängigkeiten.
- Verwende Labels/Tags für Granularität: Verwende Labels (Jenkins, Kubernetes) oder Tags (GitLab), um spezifische Jobs an Agenten mit den richtigen Fähigkeiten (z. B.
java-17,node-lts,gpu-enabled) zu lenken. - Berücksichtige warme Pools: Für Szenarien, in denen schnelles Scaling entscheidend ist, halte einen kleinen „warmen Pool“ von inaktiven Agenten bereit, die sofort Jobs übernehmen können, während weiterhin auf Bedarf skaliert wird.
Fazit
Die Auto-Scaling-Agenten-Infrastruktur ist keine Luxus-Option mehr, sondern eine Notwendigkeit für moderne CI/CD-Pipelines. Durch die dynamische Anpassung deiner Agenten-Kapazität kannst du erhebliche Kosteneinsparungen erzielen, die Produktivität der Entwickler durch schnellere Rückmeldungen verbessern und ein widerstandsfähigeres und elastischeres Liefersystem aufbauen. Egal, ob du dich für Cloud-Anbieter-Auto-Scaling-Gruppen, CI/CD-spezifische Integrationen oder einen Kubernetes-zentrierten Ansatz entscheidest, die Prinzipien bleiben gleich: automatisieren, optimieren und skalieren, um der Nachfrage gerecht zu werden. Beginne mit einer einfachen Konfiguration, überwache ihre Leistung und verfeinere deine Auto-Scaling-Strategie schrittweise, um die Bedürfnisse deines Teams perfekt zu erfüllen.
🕒 Published: