Azure Pipelines-Agents

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Sie benötigen mindestens einen Agent, um Ihren Code zu erstellen oder Ihre Software mithilfe von Azure Pipelines bereitzustellen. Wenn Ihre Codebasis und Ihr Team wachsen, benötigen Sie mehrere Agents.

Wenn Ihre Pipeline ausgeführt wird, startet das System einen oder mehrere Aufträge. Ein Agent ist die Computinginfrastruktur mit installierter Agentsoftware, die Aufträge einzeln ausführt.

Azure Pipelines stellt verschiedene Agent-Typen bereit.

Agent-Typ	Beschreibung	Verfügbarkeit
Von Microsoft gehostete Agents	Von Microsoft gehostete und verwaltete Agents.	Azure DevOps Services
Selbstgehostete Agents	Agents, die Sie konfigurieren und verwalten, die auf Ihren virtuellen Computern (VMs) gehostet werden.	Azure DevOps-Dienste, Azure DevOps-Server
Managed DevOps Pools-Agents	Verwaltete DevOps-Pools sind ein vollständig verwalteter Dienst. Virtuelle Maschinen oder Container, die die Agents betreiben, befinden sich in einem Microsoft Azure-Abonnement und nicht in Ihrem eigenen Azure-Abonnement.	Azure DevOps Services
Azure Virtual Machine Scale Sets-Agenten	Eine Form von selbst gehosteten Agents, die Azure Virtual Machine Scale Sets verwenden und automatisch skaliert werden können, um Anforderungen zu erfüllen. Wenn Sie die Verwendung von automatisch skalierbaren, selbst gehosteten Agentpools in Betracht ziehen, empfehlen wir, verwaltete DevOps-Agentpools in Erwägung zu ziehen. Weitere Informationen finden Sie unter Vergleich verwalteter DevOps-Pools mit Azure Virtual Machine Scale Sets Agents und Managed DevOps Pools (Übersicht).	Azure DevOps Services

Sie können Aufträge direkt auf dem Hostcomputer des Agents oder in einem Container ausführen.

Von Microsoft gehostete Agents

Wenn Sich Ihre Pipelines in Azure-Pipelines befinden, können Sie Ihre Aufträge bequem mit einem von Microsoft gehosteten Agent ausführen. Mit von Microsoft gehosteten Agents erfolgen Wartungs- und Upgrades automatisch.

Sie verfügen immer über die neueste Version des VM-Images, das Sie in Ihrer Pipeline angeben. Bei jeder Ausführung einer Pipeline erhalten Sie für jeden Auftrag in der Pipeline einen neuen virtuellen Computer (VM). Die virtuelle Maschine wird nach einem Arbeitsauftrag verworfen. Jede Änderung, die ein Auftrag am Dateisystem des virtuellen Computers vorgibt, z. B. das Auschecken von Code, ist für den nächsten Auftrag nicht verfügbar.

Von Microsoft gehostete Agents können Aufträge direkt auf der VM oder in einem Container ausführen.

Azure Pipelines stellt einen vordefinierten Agentpool namens Azure Pipelines mit von Microsoft gehosteten Agents zur Verfügung.

Für viele Teams ist dieser Prozess die einfachste Möglichkeit, Ihre Aufträge auszuführen. Sie können es zuerst ausprobieren, um zu sehen, ob es für Ihren Build oder Ihre Bereitstellung geeignet ist. Andernfalls können Sie Virtual Machine Scale Sets Agents oder einen eigengehosteten Agent verwenden.

Tipp

Sie können einen von Microsoft gehosteten Agent kostenlos ausprobieren.

Erfahren Sie mehr über von Microsoft gehostete Agents.

Selbstgehostete Agents

Ein selbst gehosteter Agent ist ein Agent, den Sie einrichten, um Aufträge auszuführen und den Sie selbst verwalten. Sie können selbst gehostete Agents in Azure Pipelines oder Azure DevOps Server verwenden. Selbst gehostete Agents bieten Ihnen mehr Kontrolle über die Installation abhängiger Software, die Sie für Ihre Builds und Bereitstellungen benötigen. Außerdem bleiben Caches und Konfigurationen auf Computerebene zwischen den Ausführungen erhalten, was die Geschwindigkeit erhöhen kann.

Obwohl mehrere Agents pro Computer installiert werden können, empfehlen wir dringend, nur einen Agent pro Computer zu installieren. Wenn Sie zwei oder mehr Agents installieren, kann sich dies negativ auf die Leistung und das Ergebnis Ihrer Pipelines auswirken.

Tipp

Bevor Sie einen selbst gehosteten Agent installieren, sollten Sie überprüfen, ob ein von Microsoft gehosteter Agentpool für Sie funktioniert. In vielen Fällen ist ein von Microsoft gehosteter Agentpool die einfachste Möglichkeit, loszulegen. Probieren Sie es aus.

Sie können den Agent auf Linux-, macOS- und Windows-Computern installieren. Sie können den Agent auch in einem Docker-Container installieren. Weitere Informationen zum Installieren eines selbstgehosteter Agents finden Sie unter:

• macOS-Agent
• Linux-Agent
• Windows-Agent
• Docker-Agent

Unter macOS müssen Sie das spezielle Attribut im heruntergeladenen Archiv löschen, um zu verhindern, dass der macOS Gatekeeper-Schutz für jede Komponente in der TAR-Datei angezeigt wird, wenn ./config.sh ausgeführt wird. Der folgende Befehl löscht das erweiterte Attribut für die Datei:

xattr -c vsts-agent-osx-x64-V.v.v.tar.gz  ## replace V.v.v with the version in the filename downloaded.
 
# then unpack the gzip tar file normally:

tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz

Nachdem Sie den Agent auf einem Computer installiert haben, können Sie jede andere Software auf diesem Computer installieren, die Ihre Aufträge benötigen.

Hinweis

Agents sind weitestgehend abwärtskompatibel. Jede Version des Agents sollte mit jeder Azure DevOps-Version kompatibel sein, solange Azure DevOps keine höhere Version des Agents erfordert.

Wir unterstützen nur die neueste Version des Agents, da dies die einzige Version ist, die garantiert alle up-to-date-Patches und Bugfixes enthält.

Node.js Runner-Versionen

Der Agent wird mit mehreren Versionen von Node.js-Bibliotheken ausgeliefert, um Zielaufgaben zu unterstützen, die unterschiedliche Node.js Handlern verwenden.

Alle offiziellen Azure DevOps-Aufgaben verwenden Node.js 20-Bibliothek als universellen Handler. Kunden können jedoch weiterhin benutzerdefinierte Aufgaben verwenden, die die End-of-Support-Node.js-Versionen verwenden. Autoren von Erweiterungen/benutzerdefinierten Aufgaben sollten ihre Aufgaben mit aktuellen Node.js Versionen aktualisieren/testen.

Weitere Informationen zum Node.js Runner-Lebenszyklus in Azure Pipelines finden Sie unter Node.js Läufer in Azure Pipelines Agent.

Azure Virtual Machine Scale Sets-Agenten

Azure Virtual Machine Scale Sets Agents sind eine Form von selbst gehosteten Agents, die automatisch skaliert werden können, um Ihre Anforderungen zu erfüllen. Diese Flexibilität verringert die Notwendigkeit, jederzeit dedizierte Agents auszuführen. Im Gegensatz zu von Microsoft gehosteten Agents haben Sie flexibilität gegenüber der Größe und dem Image von Computern, auf denen Agents ausgeführt werden.

Azure Pipelines verwaltet die Skalierung Ihrer Agents für Sie. Geben Sie die folgenden Faktoren an:

• Ein Skalierungssatz für virtuelle Computer
• Die Anzahl der Agents, die im Standbymodus bleiben sollen
• Maximale Anzahl virtueller Computer im Skalierungssatz

Weitere Informationen finden Sie unter Azure Virtual Machine Scale Sets-Agenten.

Managed DevOps Pools-Agents

Mit Managed DevOps Pools können Entwicklungsteams schnell und einfach Azure DevOps-Agentpools einrichten, die auf die spezifischen Anforderungen eines Teams zugeschnitten sind.

Verwaltete DevOps-Pools:

• Implementiert bewährte Methoden für die Sicherheit.
• Bietet Möglichkeiten zum Ausgleich von Kosten und Leistung.
• Stellt Pfade für die am häufigsten verwendeten Szenarien bereit.
• Reduziert erheblich die Zeit, die zum Erstellen und Verwalten von benutzerdefinierten Pools benötigt wird.

Verwaltete DevOps-Pools sind eine Weiterentwicklung von Azure Virtual Machine Scale Sets - Agentpools. Es vereinfacht die Erstellung von benutzerdefinierten Pools noch weiter, indem die Skalierbarkeit und Zuverlässigkeit von benutzerdefinierten Pools verbessert wird. Verwaltete DevOps-Pools sind ein vollständig verwalteter Dienst. Die virtuellen Maschinen oder Container, in denen Agenten betrieben werden, befinden sich in einem Microsoft Azure-Abonnement und nicht in Ihrem eigenen Azure-Abonnement, ähnlich wie Agent-Pools in Azure Virtual Machine Scale Sets. Weitere Informationen finden Sie in der Dokumentation Managed DevOps Pools.

Parallelaufträge

Das Konzept von parallelen Aufträgen stellt die Anzahl der Aufträge dar, die Sie gleichzeitig in Ihrer Organisation ausführen können. Wenn Ihre Organisation über einen einzelnen parallelen Auftrag verfügt, können Sie einen einzelnen Auftrag gleichzeitig in Ihrer Organisation ausführen. Alle anderen gleichzeitigen Aufträge werden in die Warteschlange gestellt, bis der erste Auftrag abgeschlossen ist. Um zwei Aufträge gleichzeitig auszuführen, benötigen Sie zwei Parallelaufträge. In Azure-Pipelines können Sie Parallelaufträge in der von Microsoft gehosteten Infrastruktur oder Ihrer eigenen (selbstgehosteten) Infrastruktur ausführen.

Microsoft bietet standardmäßig in jeder Organisation eine kostenlose Dienstebene an, die mindestens einen Parallelauftrag umfasst. Je nach Anzahl der gleichzeitig auszuführenden Pipelines benötigen Sie möglicherweise weitere Parallelaufträge, um mehrere von Microsoft gehostete oder selbstgehostete Agents gleichzeitig zu verwenden. Weitere Informationen zu Parallelaufträgen und verschiedenen kostenlosen Dienstebenen finden Sie unter Parallelaufträge in Azure Pipelines.

Funktionen

Jeder selbstgehostete Agent verfügt über eine Reihe von Funktionen, die angeben, welche Aufgaben er übernehmen kann. Funktionen sind Name/Wert-Paare, die eine der folgenden sind:

• Funktionen, die von der Agentsoftware erkannt werden, die als Systemfunktionen bezeichnet werden.
• Funktionen, die Sie definieren, die als Benutzerfunktionen bezeichnet werden.

Die Agentsoftware bestimmt automatisch verschiedene Systemfunktionen. Zu diesen Funktionen gehören der Name des Computers, der Typ des Betriebssystems und Versionen bestimmter Software, die auf dem Computer installiert sind. Außerdem werden auf dem Computer definierte Umgebungsvariablen automatisch in der Liste der Systemfunktionen angezeigt.

Wenn Sie Umgebungsvariablen als Funktionen speichern, werden die gespeicherten Funktionswerte verwendet, um die Umgebungsvariablen festzulegen, wenn ein Agent ausgeführt wird. Wenn Sie außerdem Änderungen an Umgebungsvariablen vornehmen, während der Agent ausgeführt wird, werden sie von keiner Aufgabe abgeholt und verwendet. Wenn Sie nicht möchten, dass vertrauliche Umgebungsvariablen als Funktionen gespeichert werden, können Sie den Agent auffordern, sie zu ignorieren. Legen Sie die VSO_AGENT_IGNORE Umgebungsvariable fest, wobei eine durch Trennzeichen getrennte Liste von Variablen ignoriert werden soll. Zum Beispiel ist PATH eine kritische Variable, die Sie bei der Installation von Software möglicherweise ignorieren sollten.

Wenn Sie eine Pipeline erstellen, legen Sie bestimmte Anforderungen für den Agent fest. Das System sendet den Auftrag nur an Agents mit Funktionen, die den anforderungen entsprechen, die in der Pipeline angegeben sind. So können Sie mithilfe von Agentfunktionen Aufträge an bestimmte Agents weiterleiten.

Anforderungen und Funktionen sind für die Verwendung mit selbstgehosteten Agents konzipiert, damit Aufträge einem Agent zugewiesen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie von Microsoft gehostete Agents verwenden, wählen Sie ein Bild für den Agent aus, der den Anforderungen des Auftrags entspricht. Obwohl es möglich ist, Einem von Microsoft gehosteten Agent Funktionen hinzuzufügen, müssen Sie keine Funktionen mit von Microsoft gehosteten Agents verwenden.

Konfigurieren der Anforderungen

YAML

Um Ihrer YAML-Buildpipeline eine Anforderung hinzuzufügen, fügen Sie dem Abschnitt demands: die Zeile pool hinzu.

pool:
  name: Default
  demands: SpecialSoftware # exists check for SpecialSoftware

Sie können überprüfen, ob eine Funktion vorhanden ist, oder einen Vergleich mit dem Wert einer Funktion durchführen. Weitere Informationen finden Sie unter YAML-Schema: Anforderungen.

Klassisch

Fügen Sie auf der Registerkarte „Aufgaben“ der Pipeline die Anforderung zu Ihrem Agentauftrag hinzu.

Name	Bedingung	Wert
SpecialSoftware	Existiert	n/a
Agent.OS	Equals	Linux

Konfigurieren von Agentfunktionen

Azure Pipelines-UI

Sie können Agent-Details anzeigen, einschließlich Versions- und Systemfunktionen, und deren Benutzerfunktionen verwalten. Wechseln Sie zu Agentpools , und wählen Sie die Registerkarte "Funktionen " für den gewünschten Agent aus.

1. Wechseln Sie in Ihrem Webbrowser zu Agentpools:

   1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

   2. Wählen Sie azure DevOps>Organization-Einstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Wechseln Sie zur Registerkarte "Funktionen ":

   1. Wählen Sie auf der Registerkarte Agent-Pools den gewünschten Agent-Pool aus.

      

   2. Wählen Sie Agents und dann den gewünschten Agent aus.

      

   3. Wählen Sie die Registerkarte Funktionen aus.

      

      Hinweis

      Von Microsoft gehostete Agents zeigen keine Systemfunktionen an. Eine Liste der auf von Microsoft gehosteten Agents installierten Software finden Sie unter Verwenden eines von Microsoft gehosteten Agents.

3. Um eine neue Funktion beim Agent zu registrieren, wählen Sie "Neue Funktion hinzufügen" aus.

Erste Schritte mit der Azure DevOps-CLI

Sie können die Agentdetails anzeigen, einschließlich Version und Funktionen. Verwenden Sie die folgenden az pipelines agent Azure CLI-Methoden.

Auflisten von Agents | Anzeigen der Agentdetails

Hinweis

Wenn Sie az pipelines zum ersten Mal mit Befehlen verwenden, lesen Sie Erste Schritte mit der Azure DevOps CLI.

Auflisten von Agents

Sie können Ihre Agents mithilfe des az pipelines agent list Befehls auflisten.

az pipelines agent list --pool-id
                        [--agent-name]
                        [--demands]
                        [--detect {false, true}]
                        [--include-assigned-request {false, true}]
                        [--include-capabilities {false, true}]
                        [--include-last-completed-request {false, true}]
                        [--org]
                        [--subscription]

Parameter

• pool-id: (Erforderlich) Der Agent-Pool, der die Agenten enthält.
• agent-name: Filtert nach Agentname.
• demands: Filtern nach Anforderungen, die die Agents erfüllen können. Durch Trennzeichen getrennte Liste.
• detect: Organisation automatisch erkennen. Akzeptierte Werte sind false und true.
• include-assigned-request: Bestimmt, ob Details zur aktuellen Arbeit der Agents eingeschlossen werden sollen. Akzeptierte Werte sind false und true.
• include-capabilities: Bestimmt, ob die Fähigkeiten der Agenten in die Antwort aufgenommen werden. Akzeptierte Werte sind false und true.
• include-last-completed-request: Bestimmt, ob Details zu den zuletzt abgeschlossenen Arbeiten der Agents einbezogen werden sollen. Akzeptierte Werte sind false und true.
• org oder organization: Die Azure DevOps-Organisations-URL. Sie können die Standardorganisation mithilfe von az devops configure -d organization=ORG_URLkonfigurieren. Dieser Parameter ist erforderlich, wenn er nicht als Standard konfiguriert oder über die Git-Konfiguration aufgenommen wird. Beispiel: https://dev.azure.com/MyOrganizationName/.
• subscription: Der Name oder die ID des Abonnements. Sie können das Standardabonnement mithilfe von az account set -s NAME_OR_IDkonfigurieren.

Beispiel

Im folgenden Beispiel werden alle Agents im Tabellenformat im Pool ID: 4 aufgelistet. Um die ID von Pools abzurufen, verwenden Sie az pipelines pool list. In diesem Beispiel wird die folgende Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikam-tailspin project=FabrikamFiber.

az pipelines agent list --pool-id 4 --output table

ID    Name          Is Enabled    Status    Version
----  ------------  ------------  --------  ---------
3     Hosted Agent  True          offline   2.155.1

Anzeigen von Agentdetails

Sie können Agent-Details mithilfe des az pipelines agent show Befehls abrufen.

az pipelines agent show --agent-id
                        --pool-id
                        [--detect {false, true}]
                        [--include-assigned-request {false, true}]
                        [--include-capabilities {false, true}]
                        [--include-last-completed-request {false, true}]
                        [--org]
                        [--subscription]

Parameter

• agent-id oder id: (Erforderlich) Die Agent-ID, über die Informationen abgerufen werden sollen.
• pool-id: (Erforderlich) Der Agent-Pool, der die Agenten enthält.
• detect: Organisation automatisch erkennen. Akzeptierte Werte sind false und true.
• include-assigned-request: Bestimmt, ob Details zur aktuellen Arbeit der Agents eingeschlossen werden sollen. Akzeptierte Werte sind false und true.
• include-capabilities: Bestimmt, ob die Fähigkeiten der Agenten in die Antwort aufgenommen werden. Akzeptierte Werte sind false und true.
• include-last-completed-request: Bestimmt, ob Details zu den zuletzt abgeschlossenen Arbeiten der Agents einbezogen werden sollen. Akzeptierte Werte sind false und true.

Sie können Aufgaben mithilfe der Windows-Authentifizierung ausführen, um auf einen externen Dienst zuzugreifen. Der Agent muss unter einem Konto mit Zugriff auf diesen Dienst in Pipelines oder variablen Gruppen ausgeführt werden, wenn er mit dem Agent ausgetauscht wird.

Die Nutzlast der zwischen dem Agent und Azure Pipelines ausgetauschten Nachrichten wird durch asymmetrische Verschlüsselung gesichert. Jeder Agent verfügt über ein Paar aus öffentlichem und privatem Schlüssel, und der öffentliche Schlüssel wird während der Registrierung mit dem Server ausgetauscht. Der Server verwendet den öffentlichen Schlüssel, um die Nutzlast des Auftrags zu verschlüsseln, bevor er ihn an den Agent sendet. Der Agent entschlüsselt den Auftragsinhalt mithilfe seines privaten Schlüssels. gentCloudRequest": null,

  <Some properties omitted for space>

  "status": "offline",
  "statusChangedOn": null,
  "systemCapabilities": {
    "ANDROID_HOME": "",
    "ANDROID_NDK_HOME": "",
    "Agent.Name": "Hosted Agent",
    "Agent.Version": "2.160.1",

    <Some capabilities omitted for space>

    "sh": "",
    "subversion": "",
    "svn": "",
    "To run tasks using Windows authentication to access an external service, the agent must run under an account with access to that service.

Wenn Sie UI-Tests wie Selenium oder codierte UI-Tests ausführen, die einen Browser erfordern, wird der Browser im Kontext des Agentkontos geöffnet.

Unter Windows wird empfohlen, ein Dienstkonto wie Netzwerkdienst oder lokaler Dienst zu verwenden. Diese Konten verfügen über eingeschränkte Berechtigungen und Kennwörter, die nicht ablaufen. Dieser Prozess reduziert die Notwendigkeit der Agentverwaltung im Laufe der Zeit.

Diese Anmeldeinformationen unterscheiden sich von den Anmeldeinformationen, die Sie beim Registrieren des Agents bei Azure Pipelines oder Azure DevOps Server verwenden.

Tipp

Nachdem Sie eine neue Software auf einem selbstgehosteten Agent installiert haben, müssen Sie den Agent neu starten, damit die neue Funktion angezeigt wird. Weitere Informationen finden Sie unter Neustarten des Windows-Agents, Neustarten des Linux-Agents und Neustarten des Mac-Agents.

Kommunikation

Kommunikation mit Azure Pipelines

Der Agent kommuniziert mit Azure Pipelines oder Azure DevOps Server. Er bestimmt, welcher Auftrag ausgeführt werden muss, und meldet die Protokolle und den Auftragsstatus. Diese Kommunikation wird stets vom Agent initiiert.

Alle Nachrichten vom Agent an Azure Pipelines oder Azure DevOps Server werden über HTTP- HTTPS gesendet, je nachdem, wie Sie den Agent konfigurieren. Mit diesem Pullmodell können Sie den Agent auf verschiedene Topologien konfigurieren, wie in den folgenden Beispielen gezeigt.

Hier ist ein gängiges Kommunikationsmuster zwischen dem Agent und Azure Pipelines oder Azure DevOps Server:

1. Der Benutzer registriert einen Agent bei Azure Pipelines oder Azure DevOps Server, indem er ihn zu einem Agentpool hinzufügt. Um einen Agent in diesem Agentpool zu registrieren, müssen Sie über die Administratorrolle des Agentpools verfügen. Die Rolle des Agentpooladministrators ist nur zum Zeitpunkt der Registrierung erforderlich und wird nicht für den Agent beibehalten. Sie wird in der weiteren Kommunikation zwischen dem Agent und Azure Pipelines oder Azure DevOps Server nicht verwendet.

   Nachdem die Registrierung abgeschlossen ist, lädt der Agent eine listener OAuth token herunter und verwendet ihn, um die Auftragswarteschlange abzuhören.

2. Der Agent lauscht darauf, zu sehen, ob eine neue Auftragsanforderung in der Auftragswarteschlange in Azure Pipelines oder Azure DevOps Server mithilfe einer langen HTTP-Umfrage veröffentlicht wird. Wenn ein Auftrag verfügbar ist, lädt der Agent den Auftrag und eine job-specific OAuth token. Azure Pipelines oder Azure DevOps Server generiert ein kurzlebiges Token für die in der Pipeline angegebene bereichsbezogene Identität.

   Der Agent verwendet das Token, um auf Ressourcen in Azure Pipelines oder Azure DevOps Server innerhalb dieses Auftrags zuzugreifen oder sie zu ändern. Beispielsweise wird das Token verwendet, um auf Quellcode zuzugreifen oder Testergebnisse hochzuladen.

3. Der Agent verwirft das auftragsspezifische OAuth Token, nachdem der Auftrag abgeschlossen wurde, und überprüft dann, ob eine neue Auftragsanforderung mit dem Listener OAuth-Token vorhanden ist.

Die Nutzlast der zwischen dem Agent und Azure Pipelines oder Azure DevOps Server ausgetauschten Nachrichten wird durch asymmetrische Verschlüsselung gesichert.

Jeder Agent verfügt über ein Paar aus öffentlichem und privatem Schlüssel, und der öffentliche Schlüssel wird während der Registrierung mit dem Server ausgetauscht. Der Server verwendet den öffentlichen Schlüssel, um die Nutzlast des Auftrags zu verschlüsseln, bevor er ihn an den Agent sendet. Der Agent entschlüsselt den Auftragsinhalt mithilfe seines privaten Schlüssels.

Diese Methode schützt die in Pipelines oder Variablengruppen gespeicherten Geheimnisse beim Austausch mit dem Agent.

Hinweis

Der Agent bietet Unterstützung für die UTF-8-Clientcodierungsausgabe. Wenn Ihr System jedoch keine UTF-8-Codierung verwendet, treten möglicherweise probleme mit der Protokollausgabe auf. Beispielsweise können Protokolle Zeichen enthalten, die von der Kodierung Ihres Systems nicht erkannt werden, sodass sie möglicherweise verfälscht oder als fehlende Symbole dargestellt werden.

Kommunikation für die Bereitstellung auf Zielservern

Wenn Sie den Agent verwenden, um Artefakte für eine Gruppe von Servern bereitzustellen, muss er über eine „Sichtverbindung“ mit diesen Servern verfügen. Von Microsoft gehostete Agentpools verfügen standardmäßig über Konnektivität zu Azure-Websites und -Servern, die in Azure ausgeführt werden.

Wenn Ihre Azure-Ressourcen in einem virtuellen Azure-Netzwerk ausgeführt werden, können Sie die Agent-IP-Bereiche abrufen, in denen von Microsoft gehostete Agents bereitgestellt werden. Anschließend können Sie die Firewallregeln für Ihr virtuelles Azure-Netzwerk so konfigurieren, dass der Zugriff vom Agent zugelassen wird.

Wenn Ihre lokalen Umgebungen nicht mit einem von Microsoft gehosteten Agent-Pool verbunden sind (was in der Regel aufgrund von dazwischenliegenden Firewalls der Fall ist), müssen Sie selbstgehostete Agents auf lokalen Computern manuell konfigurieren. Die Agents müssen über Eine Verbindung mit den lokalen Zielumgebungen und zugriff auf das Internet verfügen, um eine Verbindung mit Azure Pipelines oder Azure DevOps Server herzustellen. Dieser Prozess wird in der folgenden schematischen Darstellung veranschaulicht:

Authentifizierung

Zum Registrieren eines Agents müssen Sie Mitglied der Administratorrolle im Agentpool sein. Die Identität des Agent-Pooladministrators wird lediglich zum Zeitpunkt der Registrierung benötigt und persistiert nicht im Agent. Sie wird in der folgenden Kommunikation zwischen dem Agent und Azure Pipelines oder Azure DevOps Server nicht verwendet. Um den Agent zu konfigurieren, müssen Sie auch ein lokaler Administrator auf dem Server sein.

Wenn Sie einen Agent registrieren, wählen Sie aus den folgenden Authentifizierungstypen aus. Der Agent-Setupprozess fordert Sie auf, die spezifischen zusätzlichen Informationen anzugeben, die für jeden Authentifizierungstyp erforderlich sind. Weitere Informationen finden Sie unter Authentifizierungsoptionen für selbstgehostete Agents.

• Persönliches Zugriffstoken
• Gerätecodeflow
• Dienstprinzipal

Die Authentifizierungsmethode, die Sie zum Registrieren des Agents verwenden, wird nur während der Agentregistrierung verwendet. Weitere Informationen dazu, wie Agents nach der Registrierung mit Azure Pipelines kommunizieren, finden Sie unter Kommunikation mit Azure Pipelines oder Azure DevOps Server.

Interaktiv vs. Dienst

Sie können Ihren selbstgehosteten Agent entweder als Dienst oder als interaktiven Prozess ausführen.

Nachdem Sie den Agent konfiguriert haben, sollten Sie ihn zuerst im interaktiven Modus ausprobieren, um sicherzustellen, dass er funktioniert. Für die Produktionsverwendung wird empfohlen, den Agenten in einem der folgenden Betriebsmodi auszuführen, damit er zuverlässig im laufenden Zustand bleibt. Diese Modi stellen auch sicher, dass der Agent automatisch gestartet wird, wenn der Computer neu gestartet wird.

• Als Dienst: Sie können den Dienst-Manager des Betriebssystems verwenden, um den Lebenszyklus des Agents zu verwalten. Die Erfahrung mit der automatischen Aktualisierung des Agents ist besser, wenn Sie den Agent als Dienst ausführen.

• Als interaktiver Prozess mit aktivierter automatischer Anmeldung: In einigen Fällen müssen Sie den Agent möglicherweise interaktiv für die Produktionsverwendung ausführen (z. B. zum Ausführen von UI-Tests). Wenn Sie einen Agent für die Ausführung in diesem Modus konfigurieren, ist der Bildschirmschoner deaktiviert. Einige Domänenrichtlinien verhindern möglicherweise, dass Sie die automatische Anmeldung aktivieren oder das Bildschirmschoner deaktivieren. In diesen Fällen müssen Sie möglicherweise eine Ausnahme von der Domänenrichtlinie anfordern oder den Agent auf einem Arbeitsgruppencomputer ausführen, für den die Domänenrichtlinien nicht gelten.

  Hinweis

  Es gibt Sicherheitsrisiken, wenn Sie die automatische Anmeldung aktivieren oder den Bildschirmschoner deaktivieren. Andere Benutzer können möglicherweise auf den Computer zugreifen und das Konto verwenden, das sich automatisch anmeldet. Wenn Sie den Agenten so konfigurieren, dass er auf diese Weise ausgeführt wird, müssen Sie sicherstellen, dass der Computer physisch geschützt ist (z. B. in einer sicheren Einrichtung).

  Wenn Sie einen Remotedesktop verwenden, um auf einen Computer zuzugreifen, auf dem ein Agent mit automatischer Anmeldung ausgeführt wird, führt das Schließen des Remotedesktops dazu, dass der Computer gesperrt wird. Alle UI-Tests, die auf diesem Agent ausgeführt werden, können fehlschlagen. Um dieses Problem zu vermeiden, verwenden Sie den tscon Befehl, um die Verbindung mit dem Remotedesktop zu trennen. Beispiel:

  %windir%\System32\tscon.exe 1 /dest:console

Agentkonto

Unabhängig davon, ob Sie einen Agent als Dienst oder interaktiv ausführen, können Sie auswählen, welches Computerkonto Sie zum Ausführen des Agents verwenden. Die Auswahl des Agentkontos hängt ausschließlich von den Anforderungen der Aufgaben ab, die in Ihren Build- und Bereitstellungsaufträgen ausgeführt werden.

Um beispielsweise Aufgaben mithilfe der Windows-Authentifizierung für den Zugriff auf einen externen Dienst auszuführen, muss der Agent mithilfe eines Kontos mit Zugriff auf diesen Dienst ausgeführt werden. Wenn Sie jedoch UI-Tests wie Selenium- oder Codierte UI-Tests ausführen, die einen Browser erfordern, wird der Browser im Kontext des Agentkontos geöffnet.

Unter Windows wird empfohlen, ein Dienstkonto wie Netzwerkdienst oder lokaler Dienst zu verwenden. Diese Kontenberechtigungen sind eingeschränkt, und ihre Kennwörter laufen nicht ab, sodass der Agent im Laufe der Zeit weniger Verwaltung erfordert.

Diese Anmeldeinformationen unterscheiden sich von den Anmeldeinformationen, die Sie beim Registrieren des Agents bei Azure Pipelines oder Azure DevOps Server verwenden.

Agent-Version und Upgrades

Microsoft aktualisiert die Agentsoftware in Azure Pipelines alle paar Wochen. Die Version des Agents wird im Format {major}.{minor} angegeben. Wenn die Agent-Version zum Beispiel 2.1 ist, dann ist die Hauptversion 2 und die Nebenversion ist 1.

Wir halten von Microsoft gehostete Agents auf dem neuesten Stand. Wenn sich die neuere Version des Agents nur in der Nebenversion unterscheidet, können Azure Pipelines selbst gehostete Agents automatisch aktualisieren. Die Standardeinstellung ist aktiviert. Sie können diese Einstellung in Agentpools konfigurieren, indem Sie Ihren Agent und dann "Einstellungen" auswählen. Ein Upgrade wird angefordert, wenn ein Plattformfeature oder eine der Aufgaben in der Pipeline eine neuere Version des Agents erfordert.

Wenn Sie einen selbstgehosteten Agent interaktiv ausführen, oder wenn eine neuere Hauptversion des Agents verfügbar ist, müssen Sie die Agents möglicherweise manuell aktualisieren. Sie können die Agents über die Registerkarte "Agentpools " in Ihrer Organisation aktualisieren. Pipelines kann nicht ohne einen kompatiblen Agent ausgeführt werden.

So aktualisieren Sie selbstgehostete Agents

1. Gehen Sie zu Projekteinstellungen>Agent-Pools.

   

2. Wählen Sie Ihren Agentpool und dann "Alle Agents aktualisieren" aus.

   

   Sie können Agents auch einzeln aktualisieren, indem Sie den Update-Agent im Menü ... auswählen.

   

3. Wählen Sie "Aktualisieren" aus, um dies zu bestätigen.

   

4. Eine Aktualisierungsanforderung wird für jeden Agenten im Pool in die Warteschlange gestellt und ausgeführt, sobald die derzeit laufenden Aufträge abgeschlossen sind. Ein Upgrade dauert in der Regel nur ein paar Minuten. Diese Zeit ist lang genug, um die neueste Version der Agent-Software (ca. 200 MB) herunterzuladen, sie zu entzippen und den Agent mit der neuen Version neu zu starten. Sie können den Status Ihrer Agents auf der Registerkarte Agents überwachen.

Sie können die Version eines Agenten anzeigen. Wechseln Sie zu Agentpools , und wählen Sie die Registerkarte "Funktionen " für den gewünschten Agent aus, wie unter "Agent-Funktionen konfigurieren" beschrieben.

Um die Agentaktualisierung programmgesteuert auszulösen, können Sie die Agent-Update-API verwenden, wie im Abschnitt "Wie kann ich Agentupdates programmgesteuert für einen bestimmten Agentpool auslösen?" beschrieben.

Kopieren Sie die AGENT-ZIP-Datei für Server ohne Internetzugang manuell in den folgenden Ordner, um sie als lokale Datei zu verwenden. Erstellen Sie den Ordner "Agents ", wenn er nicht vorhanden ist:

• Fenster: %ProgramData%\Microsoft\Azure DevOps\Agents
• Linux: usr/share/Microsoft/Azure DevOps/Agents
• Macos: usr/share/Microsoft/Azure DevOps/Agents

Verzeichnisstruktur für Agenten

Wenn Pipelineaufträge auf Agents ausgeführt werden, wird eine Verzeichnisstruktur erstellt, um den Quellcode, binärdateien und Artefakte zu speichern.

Das Startverzeichnis des Agents ist das Verzeichnis, in dem der Agent installiert ist. Das Verzeichnis befindet sich in der Regel:

• Von Microsoft gehostete Agents: C:\agents\<agent version> unter Windows, /Users/runner/runners/<agent version> unter macOS und /home/vsts/agents/<agent version> unter Linux.
• Selbst gehostete Agents: C:\agent unter Windows, Users/<username>/agent (~/agent) unter macOS und /home/vsts/agent unter Linux.

Das Verzeichnis des Agenten enthält den Arbeitsbereich, in dem die Quelle und die Ausgabe der Aufträge aufbewahrt werden. Das Arbeitsverzeichnis befindet sich in der Regel:

• Von Microsoft gehosteter Agent: C:\a unter Windows, /Users/runner/work unter macOS und/home/vsts/work unter Linux.
• Selbst gehosteter Agent: C:\agent\_work unter Windows, ~/agent/work unter macOS und /home/agent/_work unter Linux.

Die Arbeitsverzeichnisstruktur lautet:

    - /work directory
        - /1 build directory/pipeline workspace
            - /s source/working directory
            - /b binaries directory
            - /a artifacts staging directory
            - /TestResults Test results directory

Verzeichnis	Beschreibung	Beispiele	Vordefinierte Variablen
Agentenverzeichnis	Wo der Agent installiert ist.	Von Microsoft gehosteter Agent:    Fenster: C:\agents\3.248.0    Linux: /home/vsts/agents/3.248.0    Macos: /Users/runner/runners/3.248.0 Eigengehosteter Agent    Fenster: C:\agent    Linux: home/agent    Macos: ~/agent	Agent.HomeDirectory
Arbeitsverzeichnis	Wo der Agent den Quellcode, binärdateien und Artefakte speichert.	Von Microsoft gehosteter Agent:    Fenster: C:\a    Linux: /home/vsts/work    Macos: /Users/runner/work Eigengehosteter Agent    Fenster: C:\agent\_work    Linux: /home/agent/_work    Macos: ~/agent/work	Agent.WorkFolder Agent.RootDirectory System.WorkFolder
Verzeichnis oder Arbeitsbereich erstellen	Wo der Pipelineauftrag ausgeführt wird.	Von Microsoft gehosteter Agent:    Fenster: C:\a\1    Linux: /home/vsts/work/1    Macos: /Users/runner/work/1 Eigengehosteter Agent    Fenster: C:\agent\_work\1    Linux: /home/agent/_work/1    Macos: ~/agent/work/1	Agent.BuildDirectory Pipeline.Workspace
s - Quell- oder Arbeitsverzeichnis	Enthält den aus dem Repository ausgecheckten Quellcode. Wenn es mehrere Schritte in Ihrem Auftrag gibtcheckout, wird Ihr Quellcode in Verzeichnissen ausgecheckt, die nach den Repositorys benannt und als Unterordner von s abgelegt werden.	Von Microsoft gehosteter Agent:    Fenster: C:\a\1\s    Linux: /home/vsts/work/1/s    Macos: /Users/runner/work/1/s Eigengehosteter Agent    Fenster: C:\agent\_work\1\s    Linux: /home/agent/_work/1/s    Macos: ~/agent/work/1/s	Build.SourcesDirectory Build.RepositoryLocalPath System.DefaultWorkingDirectory
b - Binärdateien-Verzeichnis	Enthält die Ausgaben des Builds.	Von Microsoft gehosteter Agent:    Fenster: C:\a\1\b    Linux: /home/vsts/work/1/b    Macos: /Users/runner/work/1/b Eigengehosteter Agent    Fenster: C:\agent\_work\1\b    Linux: /home/agent/_work/1/b    Macos: ~/agent/work/1/b	Build.BinariesDirectory
a – Verzeichnis der Artefakte, die bereitgestellt werden	Enthält die Artefakte des Builds. Wird zwischen den Ausführungen auf Selfhost-Agenten gelöscht.	Von Microsoft gehosteter Agent:    Fenster: C:\a\1\a    Linux: /home/vsts/work/1/a    Macos: /Users/runner/work/1/a Eigengehosteter Agent    Fenster: C:\agent\_work\1\a    Linux: /home/agent/_work/1/a    Macos: ~/agent/work/1/a	Build.StagingDirectory Build.ArtifactStagingDirectory System.ArtifactsDirectory
TestResults Verzeichnis	Enthält die Testergebnisse. Wird zwischen den Ausführungen auf Selfhost-Agenten gelöscht.	Von Microsoft gehosteter Agent:    Fenster: C:\a\1\TestResults    Linux: /home/vsts/work/1/TestResults    Macos: /Users/runner/work/1/TestResults Eigengehosteter Agent    Fenster: C:\agent\_work\1\TestResults    Linux: /home/agent/_work/1/TestResults    Macos: ~/agent/work/1/TestResults	Common.TestResultsDirectory

Bei von Microsoft gehosteten Agents wird für jede Ausführung ein anderer Agent verwendet, sodass das Arbeitsverzeichnis nicht zwischen ausführungsbasierten Vorgängen beibehalten wird. Bei selbst gehosteten Agents werden standardmäßig nur das Artefakte-Staging-Verzeichnis und die Testergebnisseverzeichnisse zwischen den Läufen bereinigt. Weitere Informationen zur Option "Arbeitsbereich bereinigen" finden Sie unter Arbeitsbereich.

Weitere Informationen zu vordefinierten Variablen finden Sie unter Vordefinierte Variablen.

Häufig gestellte Fragen

Wie kann ich sicherstellen, dass ich über die neueste Version des Agents verfüge?

1. Wechseln Sie zur Registerkarte "Agentpools ":

   1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

   2. Wählen Sie azure DevOps>Organization-Einstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Wählen Sie den Pool aus, der den Agent enthält.

3. Stellen Sie sicher, dass der Agent aktiviert ist.

4. Wechseln Sie zur Registerkarte "Funktionen":

   1. Wählen Sie auf der Registerkarte Agent-Pools den gewünschten Agent-Pool aus.

      

   2. Wählen Sie Agents und dann den gewünschten Agent aus.

      

   3. Wählen Sie die Registerkarte Funktionen aus.

      

      Hinweis

      Von Microsoft gehostete Agents zeigen keine Systemfunktionen an. Eine Liste der auf von Microsoft gehosteten Agents installierten Software finden Sie unter Verwenden eines von Microsoft gehosteten Agents.

5. Suchen Sie nach der Agent.Version-Funktion. Sie können diesen Wert mit der neuesten veröffentlichten Agent-Version auf der Seite Azure Pipelines Agent vergleichen.

6. Jeder Agent aktualisiert sich automatisch, wenn er eine Aufgabe ausführt, die eine neuere Version des Agents erfordert. Wenn Sie einige Agents manuell aktualisieren möchten, klicken Sie mit der rechten Maustaste auf den Pool, und wählen Sie dann "Alle Agents aktualisieren" aus.

Haben selbstgehostete Agents gegenüber von Microsoft gehosteten Agents Leistungsvorteile?

In vielen Fällen ja. Wenn Sie einen selbstgehosteten Agent verwenden, können Sie inkrementelle Builds ausführen. Wenn Sie beispielsweise eine Pipeline definieren, die weder das Repository noch den Build bereinigt, werden Ihre Builds in der Regel schneller ausgeführt. Sie erhalten diese Vorteile nicht mit einem von Microsoft gehosteten Agent, es sei denn, Sie verwenden Features wie das Zwischenspeichern, da der Agent nach Abschluss der Pipeline zerstört wird.

Es kann länger dauern, bis der Build von einem von Microsoft gehosteten Agent gestartet wird. Obwohl es oft nur ein paar Sekunden dauert, bis Ihr Auftrag einem von Microsoft gehosteten Agent zugewiesen wird, kann es je nach Auslastung unseres Systems manchmal mehrere Minuten dauern, bis ein Agent zugewiesen wird.

Kann ich mehrere selbstgehostete Agents auf demselben Computer installieren?

Ja. Dieser Ansatz eignet sich möglicherweise gut für Agents, die Aufträge ausführen, die nicht viele freigegebene Ressourcen verbrauchen. Sie können ihn beispielsweise für Agents ausprobieren, die Releases ausführen, die größtenteils Bereitstellungen orchestrieren und nicht viel Arbeit auf dem Agent selbst ausführen.

In anderen Fällen werden Sie möglicherweise feststellen, dass der Betrieb mehrerer Agents auf demselben Computer keinen großen Effizienzgewinn bewirkt. Beispielsweise lohnt es sich möglicherweise nicht für Agents, die Builds ausführen, die viel Speicherplatz und Eingabe-/Ausgaberessourcen verbrauchen.

Möglicherweise treten auch Probleme auf, wenn parallele Buildaufträge dieselbe Singleton-Toolbereitstellung verwenden (z. B. npm-Pakete). Ein Build kann eine Abhängigkeit aktualisieren, während ein anderer Build es verwendet, was zu unzuverlässigen Ergebnissen und Fehlern führen kann.

Was tun Agents, wenn Pipelineaufträge abgebrochen werden?

Bei von Microsoft gehosteten Agents wird der Agent entfernt und an den Azure Pipelines-Pool zurückgegeben.

Für selbstgehostete Agents:

• Wenn eine Pipeline abgebrochen wird, sendet der Agent eine Abfolge von Befehlen an den Prozess, der den aktuellen Schritt ausführt.
• Der erste Befehl wird mit einem Timeout von 7,5 Sekunden gesendet.
• Wenn der Prozess nicht beendet wird, wird ein zweiter Befehl mit einem Timeout von 2,5 Sekunden gesendet.
• Wenn der Prozess nicht beendet wird, gibt der Agent den Befehl aus, ihn zu beenden.
• Wenn der Prozess die beiden ersten Beendigungsanforderungen ignoriert, wird er zwangsweise beendet.

Die Zeit von der ursprünglichen Anforderung bis zur Beendigung beträgt ca. 10 Sekunden.

Die Befehle, die für den Prozess ausgegeben wurden, um die Pipeline abzubrechen, unterscheiden sich je nach Agentbetriebssystem:

• macOS und Linux: Die gesendeten Befehle sind SIGINT, gefolgt von SIGTERM, gefolgt von SIGKILL.
• Windows: Die an den Prozess gesendeten Befehle werden Ctrl+Cgefolgt von Ctrl+Break, gefolgt von Process.Kill.

Wie kann ich Agentaktualisierungen programmgesteuert für einen bestimmten Agentpool auslösen?

Sie können Agent-Aktualisierungen für den Pool auslösen, indem Sie die folgende API verwenden:

POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0

URI-Parameter

Name	Geben Sie in	Erforderlich	Type	Beschreibung
agentId	Abfrage	False	Zeichenfolge	Der zu aktualisierende Agent. Wenn sie nicht angegeben ist, wird ein Update für alle Agents ausgelöst.
organization	path	True	Zeichenfolge	Der Name der Azure DevOps-Organisation.
poolId	path	True	Integer int32	Der zu verwendende Agentpool.
api-version	Abfrage	False	Zeichenfolge	Version der zu verwendenden API. Um diese Version der API zu verwenden, sollte der Wert auf 6.0 gesetzt werden.

Um eine Agentaktualisierung auszulösen, sollte der Anforderungstext leer sein.

Der Azure Pipelines-Agent ist Open Source auf GitHub.

Verwandte Inhalte

Weitere Informationen zu Agents finden Sie in den folgenden Modulen aus dem Build-Anwendungen mit Azure DevOps-Lernpfad :

• Auswählen eines von Microsoft gehosteten oder selbstgehosteten Build-Agents
• Hosten eines eigenen Build-Agents in Azure Pipelines