Wann sollten self-hosted CI/CD Agents in Azure DevOps Services eingerichtet werden?  

Inhaltsverzeichnis

1. Was ist ein Build Agent?   
2. Vorteile der Parallel Jobs 
3. Beschleunigung des Prozesses
4. Custom Agent Set Up  
5. Zusätzliche Vorteile
6. Ein alternativer Ansatz
7. Die Kosten für die Einrichtung von selbst gehosteten Agenten
8. Halten Sie Ihre Agents Up-To-Date 
9. Zusammenfassung

Unabhängig davon, welche Continuous Delivery-Plattform Sie verwenden, sollten Sie immer versuchen, sie so effizient wie möglich zu nutzen. Bau- und Lieferzeiten sowie die Gesamtkosten sind die zu berücksichtigenden Kernfaktoren. Die Build-Agenten spielen dabei eine wichtige Rolle. Viele moderne CI / CD-Systeme bieten integrierte, aber auch selbst gehostete Maschinen für den Betrieb der Pipelines. Welcher Ansatz ist besser? Die Antwort ist nicht einfach und hängt von den spezifischen Anforderungen Ihres Projekts ab. Mein Ziel ist es, Ihnen zu zeigen, in welchen Fällen Sie von jeder dieser Optionen profitieren können. Dieser Artikel basiert auf der Azure DevOps-Plattform für DevOps Services Die Erkenntnisse können jedoch auf jeder CI / CD-Plattform hilfreich sein, welche die Möglichkeit bietet, benutzerdefinierte Build-Agenten zu erstellen. 

Was ist ein Build Agent?   

Jedes CI-System benötigt einen Ort zum Ausführen der Pipeline-Jobs. Ein Build Agent ist eine Maschine, die diesem Zweck gewidmet ist. Abhängig von der Plattform kann es als "Agent" oder "Worker" bezeichnet werden. Entscheidend ist, dass sie eine wesentliche Komponente für die Leistung und die Kosten der Pipeline darstellt. 

Arten von Azure DevOps Agents 

Die meisten CI-Systeme bieten vom Anbieter gehostete Agenten. Das heißt, sie können als PaaS-Ressource verwendet werden. Abhängig von der Plattform können Sie auswählen, für wie viele Agenten, parallele Jobs oder Minuten Sie bezahlen möchten. In Azure DevOps verfügt jede Organisation standardmäßig über einen kostenlosen parallelen Job mit einem Limit von 1800 Minuten für private Projekte. Darüber hinaus besteht die Möglichkeit, einen selbst gehosteten Agenten hinzuzufügen. Wenn das nicht ausreicht, haben Sie zwei Möglichkeiten. Sie können entweder zusätzliche Jobs mit unbegrenzten Minuten kaufen oder mehr "Lizenzen" für selbst gehostete Agenten kaufen. Erwähnenswert ist hier, dass Sie für jede Person in der Organisation, die ein Microsoft Developer Network-Abonnement hat, einen weiteren selbst gehosteten Agentenplatz erhalten. 

Für die Open-Source-Projekte stehen 10 parallele Jobs kostenlos zur Verfügung. Sie können auch eine unbegrenzte Anzahl von selbst gehosteten Agenten erstellen. 

Arten von Azure DevOps Agents 

Vorteile der Parallel Jobs 

Der Grund, warum ich mich auf Jobs und nicht auf Agenten beziehe besteht darin, dass ein von Microsoft gehosteter Job auf vielen verschiedenen Computern ausgeführt werden kann. In der Pipeline können Sie angeben, ob sie unter einer bestimmten Version von Windows, Linux oder sogar MacOS ausgeführt werden soll. Dies wirft die Frage auf, warum Sie zusätzliche Jobs benötigen würden, wenn Sie mit nur einem Agenten mehrere verschiedene Pipelines mit Anwendungen für jede Plattform erstellen können. Technisch ist es zwar möglich, aber keine gute Idee, und ich werde Ihnen zeigen, warum.

In diesem Beispiel habe ich eine einfache Pipeline mit drei Jobs erstellt. Jeder dieser Jobs führt dieselben Schritte für eine der .NET-Beispielanwendungen aus:

1. Install NuGet 
2. Install .NET Core 3.1
3. Restore Packages 
4. Build Application 

Ich habe das Repository der DevOps-Project-Samples verwendet, welches eine Reihe von Beispielanwendungen enthält, die speziell für das Testen von Pipelines vorbereitet wurden. Zuerst habe ich die Pipeline auf einem von Microsoft gehosteten Agenten ausgeführt:

Die gesamte Pipeline-Ausführung dauerte 3 Minuten und 23 Sekunden (die Summe der Jobs + Zeit, die zum Wechseln des Kontexts benötigt wird). Die von MS gehosteten Agenten haben bereits NuGet und .NET installiert, sodass die meiste Zeit für das Wiederherstellen von Paketen und das Erstellen der App aufgewendet wurde. Als Nächstes habe ich denselben Build für einen selbst gehosteten Agentenpool ausgeführt:

Die Agenten waren saubere Ubuntu-Maschinen, daher dauerte der erste Lauf etwas länger, da alle erforderlichen Tools installiert werden mussten. Die gesamte Erstellungszeit war jedoch ähnlich wie bei dem von MS gehosteten Szenario, da parallel ausgeführt. Der interessanteste Teil ist jedoch der nächste Lauf auf dem selbst gehosteten Agenten:

Da bereits alle Tools installiert wurden, wurde erneut Zeit für die Wiederherstellung von Paketen und die Kompilierung der Anwendung aufgewendet. Einige der Pakete befanden sich jedoch bereits im Cache. Die Ausführung der gesamten Pipeline dauerte eine Minute - dies ist die Ausführungszeit des längsten Jobs. Dies lässt uns mit 3:23 vs. 1:00 auf einer Reihe von einfachen Boilerplate-Apps. Stellen Sie sich nun den Unterschied bei einer Lösung auf Unternehmensebene vor - das ist eine deutliche Verbesserung.

Beschleunigung des Prozesses

Unabhängig vom Framework wird normalerweise die meiste Zeit für die Wiederherstellung von Paketen und Abhängigkeiten benötigt. Sie werden jedes Mal wiederhergestellt, wenn der Build auf dem gehosteten Agenten ausgeführt wird. Das liegt daran, dass Sie für jeden Build eine neue Maschine erhalten. Um dies zu überwinden, können Sie mit Azure DevOps Pipeline-Caching verwenden, aber nicht jede CI-Plattform verfügt über eine solche Funktion. Hier können Sie von einem selbst gehosteten Agenten profitieren.

Wenn Sie selbst gehostete Agenten verwenden, verfügt jede Pipeline über ein eigenes Arbeitsverzeichnis. Allerdings bleiben die Tools und der Cache zwischen den Läufen erhalten. Der erste Durchlauf dauert immer einige Zeit, um alle Abhängigkeiten herunterzuladen. Es wird jedoch nicht für nachfolgende Läufe benötigt, sodass der Prozess viel schneller ist.

Es kann Fälle geben, in denen Sie tatsächlich einen sauberen Build ausführen möchten. In diesem Fall können Sie einen Wartungsjob für selbst gehostete Agenten einrichten, um diese zu bereinigen, z. B. wöchentlich. Für Scale-Set-Agent Pools besteht die Möglichkeit, virtuelle Maschinen nach jeder Verwendung herunterzufahren.

Custom Agent Set Up  

Das Erstellen eines selbst gehosteten Agenten ist eine ziemlich einfache Aufgabe. In Azure DevOps gibt es mehrere Möglichkeiten:

• Manuell. Sie müssen einen Agent Pool im Azure DevOps-Portal erstellen. Dann müssen Sie nur noch das generierte Skript kopieren und auf dem ausgewählten Computer ausführen. Sie können jede virtuelle Cloud-Machine, lokale oder sogar Ihren PC verwenden. Für jedes Betriebssystem gibt es separate Skripte. Das Skript installiert den Agenten auf der ausgewählten VM und fragt nach der Organisations- / Projekt-URL und dem Agentenpool, dem er beitreten soll.
• Mit Azure Scale Set. Zunächst müssen Sie eine in Azure Cloud festgelegte Skalierung erstellen. Anschließend müssen Sie einen neuen Agent Pool generieren, als Pool-Typ "Azure Virtual Machine Scale Set" auswählen und eine Verbindung zu diesem herstellen. Auch muss eine Dienstverbindung zu dem Abonnement oder der Ressourcengruppe eingerichtet werden, in welcher der Skalensatz erstellt wurde. Die Agenten werden automatisch auf den virtuellen Maschinen installiert. Mit diesem Ansatz können Sie Ihre Agenten einfach verwalten und skalieren. Sie können das benutzerdefinierte VM-Image auch mit der gesamten erforderlichen Software verwenden, die bereits installiert ist.
• Container mit Docker oder Kubernetes. Ein benutzerdefiniertes Container-Image mit der gesamten erforderlichen Software und dem Agenten kann vorbereitet werden und optional mit Helm versehen, wenn Sie es in AKS (oder einem anderen Kubernetes-Anbieter) ausführen möchten. Helm ist ein Open Source-Verpackungstool, das Ihnen dabei hilft, Kubernetes-Anwendungen zu installieren und ihren Lebenszyklus zu verwalten. Diese Methode ähnelt der Verwendung eines Skalierungssatzes. Sie können Ihre Agenten auch skalieren, sie werden jedoch vom Azure DevOps-Server nicht automatisch skaliert. Wählen Sie diesen Ansatz, wenn Sie mehr Kontrolle über die Verwaltung der Agenten wünschen. Denken Sie jedoch daran, dass die Wartung dieser Agenten möglicherweise auch mehr Aufwand erfordert.

Zusätzliche Vorteile

Lassen Sie uns den tatsächlichen Mehrwert des selbst gehosteten Agenten weiter diskutieren. Die Beschleunigung der Pipelines ist ein Vorteil. Der andere Vorteil ist die Möglichkeit, die Agent Tools anzupassen. Stellen Sie sich vor, Sie müssen Leistungstests mit Apache JMeter ausführen. Obwohl die gehosteten Agenten mit einer Vielzahl von Tools geliefert werden, ist JMeter nicht enthalten. Für einige der Tools gibt es Installationsaufgaben, die während des Builds verwendet werden können, um die richtige Version des angegebenen Tools zu installieren und / oder festzulegen. Es ist sehr praktisch, aber denken Sie daran - jedes Installationsprogramm wirkt sich auf die gesamte Erstellungszeit aus. In den meisten Fällen ist es besser, die Tools bereits zu haben. Mit einem benutzerdefinierten Agenten können Sie eine VM oder ein Container-Image vorbereiten und als Basis für den Agenten verwenden. Das spart viel Zeit beim Erstellen.

Ein alternativer Ansatz

Wenn Sie die benutzerdefinierten Agenten nicht verwenden können, aber eine bestimmte Software verwenden müssen, deren Installation lange dauert, gibt es eine weitere Option. Sie können einen Container-Job in Azure DevOps verwenden. Auf diese Weise können Sie ein Container-Image mit allem vorbereiten, was Sie während des Builds als Kontext verwenden müssen. Das heißt, alle Schritte werden im Container ausgeführt. Das einzige Problem hierbei ist die Zeit, die zum Herunterladen und Einrichten des Images erforderlich ist. In einigen Fällen kann dies jedoch der optimale Ansatz sein.

Die Kosten für die Einrichtung von selbst gehosteten Agenten

Der finanzielle Aspekt von selbst gehosteten Agenten kann ebenfalls von Vorteil sein. Dies hängt jedoch davon ab, wie Sie Ihre virtuellen Maschinen verwenden. Die besprochenen Preise sind zum Zeitpunkt der Veröffentlichung dieses Artikels gültig, können sich jedoch in Zukunft ändern. Laut aktueller Preisliste kostet jeder zusätzliche von Microsoft gehostete Job 33,74 €. Für diesen Preis erhalten Sie einen Job, der auf einer DS2_v2-Tier-VM (2 Cores, 7 GB RAM, 6400 IOPS) ausgeführt wird. Unter Azure kostet eine VM dieser Größe 81,26 €. Auf den ersten Blick scheint es, dass es viel günstiger ist, einen von MS gehosteten Job zu bekommen. Die Frage ist jedoch, wie viel Rechenleistung Sie wirklich für einen Agenten benötigen. Schauen wir uns ein anderes Beispiel an.

Für den Preis von 27,70 € (das ist weniger als ein von MS gehosteter Job) können Sie eine Ubuntu-VM der Größe B2 (2 Cores, 4 GB RAM, 1280 IOPS) erwerben. Wie viele Agenten können Sie auf einer VM dieser Größe hosten? Nun, es hängt von Ihren Build-Anforderungen ab. Für einige einfache Aufgaben kann es für 3 oder sogar 4 Agenten ausreichen (wenn Sie sie in Containern einrichten). In einigen Fällen erfordert die Build-Task / das Build-Skript jedoch möglicherweise viel mehr RAM oder CPU-Leistung, und dieser Computer reicht möglicherweise nicht einmal für einen Agenten aus. Auf der anderen Seite können Sie für einen ähnlichen Betrag einen Skalensatz mit 4 VMs der Größe B1 (1 Core, 1 GB RAM, 320 IOPS) einrichten, der 27,84 € kostet.

Wie Sie sehen, ist es nicht einfach festzustellen, welcher Ansatz kostengünstiger ist. Wenn Sie eine große Anzahl nicht anspruchsvoller Builds haben, verwenden Sie einen Skalensatz mit Low-Tier-VMs. Wenn dies nicht ausreicht, um Ihren Anforderungen zu entsprechen, ist der Kauf eines zusätzlichen Jobs möglicherweise die richtige Entscheidung. Es kann jedoch einige Randfälle geben, in denen selbst der gehostete Jobagent nicht ausreicht (z. B. in Szenarien zur Erstellung von Spielentwicklern) und Sie möglicherweise eine größere, teurere VM benötigen.

Die oben genannten Beispiele basieren auf Azure Virtual Machines. Denken Sie jedoch daran, dass Sie jeden anderen Anbieter für einen selbst gehosteten Agenten verwenden können. Um festzustellen, was kostengünstiger ist - ein selbst gehosteter Agent oder ein von MS gehosteter Job - müssen Sie berechnen, welcher Job besser zu Ihren Anforderungen passt.

Halten Sie Ihre Agents Up-To-Date 

Es gibt noch einen weiteren Aspekt von selbst gehosteten Agenten, den wir besprechen sollten: Die Wartung. Die Infrastruktur des Anbieters bietet Ihnen immer neue Tools. Sie können aber auch Ihr eigenes Setup vorbereiten, um Ihre Agenten auf dem neuesten Stand zu halten. In diesem Fall wären die Containeragenten am einfachsten zu warten. Sie können eine Pipeline einrichten, die neue Bilder erstellt und diese bereitstellt, z.B. einmal pro Monat. Es ist wichtig, die Software auf dem neuesten Stand zu halten, insbesondere aus Sicherheitsgründen. In Azure DevOps gibt es auch einige Funktionen, für die eine bestimmte Version eines Agenten erforderlich ist. Diese spezielle Komponente kann jedoch problemlos im Portal aktualisiert werden. 

Zusammenfassung

Sowohl die vom Anbieter gehosteten als auch die selbst gehosteten Agenten haben ihre Vor- und Nachteile. Mit dem selbst gehosteten Ansatz können Sie kürzere Erstellungszeiten erzielen, benutzerdefinierte Software installieren und Kosten optimieren. Es gibt mehrere Möglichkeiten, benutzerdefinierte Agenten einzurichten, beginnend mit einfachen virtuellen Maschinen und endend mit Containern. Wenn Sie sich jedoch für eine vom Hersteller gehostete Lösung entscheiden, müssen Sie sich keine Gedanken über das System oder die Software-Updates machen. Es gibt keine einzige richtige Antwort, die für jedes Projekt optimal wäre. Ich würde empfehlen, einen Ansatz zu wählen, der den Anforderungen Ihres Unternehmens besser entspricht. Sie können jederzeit einen DevOps-Beratungspartner bitten, Ihnen bei der Auswahl der richtigen Option zu helfen. Wenn Sie Kosten und Geschwindigkeit optimieren möchten, können Sie Ihre eigenen Agenten einrichten. Wenn Sie jedoch nach einer einfachen Lösung suchen, die einfach ihre Aufgabe erfüllt, können Sie weiterhin die vom Anbieter bereitgestellten verwenden.