Auswählen eines von Microsoft gehosteten oder selbstgehosteten Build-Agents

Abgeschlossen

In dieser Lektion erfahren Sie etwas über einige der Faktoren, die bei der Auswahl eines Build-Agents zu berücksichtigen sind. Sie erhalten Informationen zu einigen Vorteilen und Einschränkungen bei der Verwendung eines von Microsoft gehosteten Agents sowie dazu, was beim Einrichten Ihres eigenen privaten Build-Agents zu berücksichtigen ist.

Sehen wir uns an, was im Tailspin-Webteam passiert. Tim aus der IT-Betriebsabteilung möchte mehr darüber erfahren, wie Build-Agents in Azure Pipelines funktionieren. Er startet eine Unterhaltung mit unseren Entwicklern, Andy und Mara.

Tim: Hallo Andy und Mara. Ich habe verfolgt, wie Sie Microsoft Azure Pipelines zum Erstellen der Webanwendung Space Game verwendet. Ich bin neugierig, und möchte gerne mehr darüber erfahren, wie dies funktioniert. Wird eine Verbindung mit einem unserer Buildcomputer hergestellt?

Andy: Es ist möglich, eine Verbindung mit einem unserer Buildcomputer herzustellen, aber zurzeit verwenden wir einen von Microsoft gehosteten Agent.

Tim: Wir führen den Build aber doch unter Linux aus. Stellt Microsoft Linux-Build-Agents bereit?

Mara: Ja! Tatsächlich können Sie für Ihren Build-Agent Windows, Linux oder macOS auswählen. Wenn die Anwendung auf mehreren Plattformen ausgeführt wird, können Sie die Pipeline für Builds auf allen Plattformen konfigurieren.

Tim: Sehr interessant. Eines der anderen Teams hat einige der Herausforderungen in Bezug auf die Buildinfrastruktur erwähnt. Möglicherweise kann Azure Pipelines sowie ein von Microsoft gehosteter oder ein eigener Build-Agent helfen?

Andy: Das würde mich auch interessieren. Lassen Sie uns etwas mehr über Build-Agents sprechen. Vielleicht können Sie das, was Sie lernen, mit dem anderen Team teilen.

Was sind Build-Agents und Agent-Pools?

Ein Build-Agent ist ein System, das Buildaufgaben ausführt. Stellen Sie es sich als dedizierten Server vor, der den Buildprozess ausführt.

Stellen Sie sich vor, dass Sie über ein Azure Pipelines-Projekt verfügen, das mehrmals täglich Buildanforderungen empfängt. Oder vielleicht verfügen Sie über mehrere Projekte, die jeweils denselben Build-Agent-Typ verwenden können. Sie können Build-Agents in Agent-Pools organisieren, um sicherzustellen, dass ein Server für die Verarbeitung der einzelnen Buildanforderungen bereit steht.

Wenn ein Build ausgelöst wird, wählt Azure Pipelines einen verfügbaren Build-Agent aus dem Pool aus. Wenn alle Agents ausgelastet sind, wartet der Prozess, bis einer verfügbar wird.

Wenn Sie einen von Microsoft gehosteten Agent verwenden, geben Sie das zu verwendende VM-Image aus dem Pool an. Im Folgenden finden Sie ein Beispiel aus Ihrer vorhandenen Buildkonfiguration, die einen Ubuntu 20.04-Build-Agent verwendet:

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

Wenn Sie einen von Microsoft gehosteten Agent verwenden, müssen Sie mit vmImage angeben, welche Art von System Sie benötigen. Microsoft bietet viele Arten von VM-Images, einschließlich derjenigen, die Windows, macOS und verschiedene Linux-Versionen ausführen.

Derdemands-Abschnitt gibt an, welche Software oder Funktionen der Buildcomputer benötigt.

Wenn Sie einen Build-Agent aus Ihrem eigenen Pool (auch als privater Pool bezeichnet) verwenden, geben Sie den Namen des Pools an. Hier sehen Sie ein Beispiel.

pool:
  name: 'MyAgentPool'
  demands:
  - npm

Wenn Sie keinen demands-Abschnitt benötigen, können Sie die Syntax wie folgt kürzen:

pool: 'MyAgentPool'

Sie erstellen einen Build-Agent und fügen ihn später in diesem Modul zu einem Pool hinzu.

Welche Art von Agents kann ich verwenden?

Wenn Sie einen Build-Agent auswählen, müssen Sie zwei Faktoren berücksichtigen:

  • Das Betriebssystem, auf dem Sie den Build ausführen möchten
  • Ob Sie einen von Microsoft gehosteten Agent verwenden können oder einen eigenen Agent bereitstellen müssen

Azure Pipelines unterstützt die folgenden Betriebssysteme:

  • Windows
  • macOS
  • Linux (Ubuntu, Red Hat Enterprise Linux und CentOS)

Welchen Build-Agent Sie auswählen, hängt hauptsächlich davon ab, welche Tools Sie zum Erstellen Ihres Codes verwenden. Wenn Sie z. B. Xcode zum Erstellen von Anwendungen verwenden, könnten Sie einen macOS-Agent auswählen. Wenn Sie Visual Studio benötigen, würden Sie wahrscheinlich einen Windows-Agent auswählen.

In der vorhandenen Buildkonfiguration wird ein von Microsoft gehosteter Agent verwendet. Gehostete Agents werden in der Infrastruktur ausgeführt, die Microsoft für Sie bereitstellt.

Ein privater Agent verwendet die von Ihnen bereitgestellte Infrastruktur. Der Agent kann ein System sein, das in der Cloud oder in Ihrem Rechenzentrum ausgeführt wird. Beide Systeme funktionieren, solange der Agent Ihre Anforderungen erfüllt und eine Verbindung mit Azure Pipelines herstellen kann. In diesem Modul wird ein in Azure ausgeführter bereitgestellter virtueller Computer verwendet.

Wann sollte ich meinen eigenen Build-Agent verwenden?

Für viele Buildaufgaben erledigt ein von Microsoft gehosteter Agent alles, was Sie benötigen. Dies ist die einfachste Möglichkeit, um direkt loszulegen.

Microsoft kümmert sich um alle Sicherheits- und anderen Betriebssystemupdates für Sie. Sie müssen lediglich die Buildkonfiguration definieren, die Sie ausführen möchten.

Gehostete Agents enthalten außerdem Software, mit der viele gängige Anwendungstypen erstellt werden können. Sie können während des Buildprozesses sämtliche weitere Software hinzufügen, die Sie benötigen.

Für von Microsoft gehostete Agents gelten ein paar Einschränkungen, z. B.:

  • Builddauer: Ein Buildauftrag kann bis zu sechs Stunden laufen.
  • Speicherplatz: Gehostete Agents stellen eine festgelegte Speichermenge für Ihre Quellen und Buildausgaben bereit. Dies ist möglicherweise nicht genügend Speicher.
  • CPU, Arbeitsspeicher und Netzwerk: Gehostete Agents werden auf Microsoft Azure-VMs der Dienstebene „Universell“ ausgeführt. Standard_DS2_v2 beschreibt die CPU-, Arbeitsspeicher- und Netzwerkeigenschaften, die Sie erwarten können.
  • Interaktivität: Sie können sich nicht bei einem gehosteten Agent anmelden.
  • Dateifreigaben: Sie können Buildartefakte nicht auf UNC-Dateifreigaben (Universal Naming Convention) ablegen.

Gehostete Agents sind zwar relativ einfach einzurichten, jedoch hat die Verwendung Ihrer eigenen Build-Agents, abgesehen von den eben erläuterten Einschränkungen, einige Vorteile.

Wenn Sie gehostete Agents verwenden, teilen Sie beispielsweise die Infrastruktur mit anderen Azure DevOps-Benutzern. In der Regel dauert es nur wenige Sekunden, um Ihren Build zu starten, je nach Auslastung des Microsoft-Systems kann es aber auch länger dauern.

Außerdem erhalten Sie bei Verwendung gehosteter Agents für jeden Build ein bereinigtes System. Wenn Sie Ihren eigenen Build-Agent bereitstellen, können Sie entscheiden, ob jedes Mal ein bereinigter Build oder ob ein inkrementeller Build durchgeführt werden soll. Bei einem inkrementellen Build führen Sie den Build mit vorhandene Buildtools und kompiliertem Code aus. Ein inkrementeller Build kann weniger Zeit erfordern, da bereits viele der Buildtools und abhängigen Komponenten auf dem System installiert sind.

Der Kompromiss besteht darin, dass es in Ihrer Verantwortung liegt, sicherzustellen, dass Ihre Build-Agents die neueste Software und die neuesten Sicherheitspatches enthalten, da es sich um Ihre eigene Buildinfrastruktur handelt.

Einrichten eines privaten Build-Agents

Ein privater Build-Agent enthält die Software, die zum Erstellen Ihrer Anwendungen benötigt wird. Er enthält außerdem Software, mit der das System eine Verbindung zu Azure Pipelines herstellen und Buildaufträge empfangen kann.

Beim Einrichten eines privaten Agents stellen Sie die Infrastruktur bereit, auf der die Builds ausgeführt werden. Dadurch können Sie beim Erstellen und Verwalten Ihrer Agents flexibel bleiben.

Beispielsweise können Sie folgende Aktionen ausführen:

  • Manuelles Einrichten des Build-Agents: Sie rufen das System auf, melden sich an und installieren ihre Buildtools und die Agent-Software interaktiv.

  • Automatisieren des Prozesses: Hierbei rufen Sie das System auf und führen ein Skript oder Tool aus, um Ihre Buildtools und die Software für den Agent zu installieren. Sie können den Agent, während des Bereitstellungsprozesses oder sobald das System ausgeführt wird, konfigurieren.

    Wenn Sie Build-Agents beispielsweise in Azure ausführen, können Sie eine Azure Resource Manager-Vorlage (ARM-Vorlage) oder Bicep verwenden, um das System in nur einem Schritt aufzurufen und zu konfigurieren, damit diese als Build-Agent fungiert. Terraform von HashiCorp ist eine weitere Möglichkeit zum Automatisieren des Prozesses. Terraform funktioniert mit vielen Arten von Infrastrukturen, einschließlich Azure.

  • Erstellen eines Images: Sie erstellen ein Image oder eine Momentaufnahme einer konfigurierten Umgebung. Anschließend verwenden Sie das Image zum Erstellen der für Ihren Pool erforderlichen Menge identischer Systeme.

Die manuelle Konfiguration ist ein guter Startpunkt, da der Prozess so einfacher zu verstehen ist. Dies ist auch die schnellste Einrichtungsmöglichkeit, wenn Sie nur einen Build-Agent benötigen.

Die Automatisierung ist nützlich, wenn Sie viele Agents erstellen oder regelmäßig Buildinfrastrukturen errichten und auflösen müssen. Sie können von einem manuellen zu einem automatisierten Prozess wechseln, wenn Sie mehrere Agents benötigen.

Images sind eine Form der Automatisierung. Sie helfen dabei, Zeit zu sparen, da die gesamte Software vorkonfiguriert ist. Dafür müssen Sie Ihre Images möglicherweise regelmäßig neu erstellen, um die neuesten Betriebssystempatches und Buildtools zu integrieren. Packer von HashiCorp ist ein beliebtes Tool zum Erstellen von Images.

Wie entscheidet sich das Team?

Hören wir uns an, was das Team zu sagen hat.

Tim: Ich glaube, ich verstehe einige der verschiedenen Ansätze. Ich wäre daran interessiert, einen privaten Build-Agent zu erstellen, der die Space Game-Website so erstellen kann, dass ich diese dann den anderen Teams vorführen kann. Wäre es schwer, das einzurichten?

Mara: Ich denke, wir können das machen. Wir könnten eine VM aus dem Lab verwenden, oder besser: wir verwenden eine VM, die in Azure ausgeführt wird, als Build-Agent. Wir könnten ein paar Skripts einrichten, um das Setup der VM durchzuführen. Sobald wir das ausreichend getestet haben, können wir die VM auflösen, damit wir nicht mehr dafür bezahlen müssen.

Tim: Das klingt gut. Dabei lerne ich, wie ich VMs in Azure verwende.

Andy: Viel Spaß! Ich freue mich darauf, von euren Erfahrungen zu hören.

Überprüfen Sie Ihr Wissen

1.

Angenommen, Sie entwickeln ein Videospiel. Der Buildprozess dauert zwei Stunden und verbraucht 18 bis 20 GB Speicherplatz für die Kompilierung der Spieleobjekte. Welche Art von Build-Agent können Sie verwenden?

2.

Angenommen, Sie erstellen eine Anwendung, die unter macOS, Linux und Windows ausgeführt werden kann. Wie können Sie die App für die einzelnen anvisierten Zielplattformen erstellen?

3.

Ein selbstgehosteter Build-Agent: