Selbstgehostete Linux-Agenten

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Dieser Artikel enthält Anleitungen zur Verwendung der 3.x-Agentsoftware mit Azure DevOps Services und aktuellen Versionen von Azure DevOps Server. Eine Liste der Azure DevOps Server-Versionen, die den 3.x-Agent unterstützen, finden Sie unter Unterstützt Azure DevOps Server den 3.x-Agent.

Um Ihre Aufträge auszuführen, benötigen Sie mindestens einen Agent. Ein Linux-Agent kann verschiedene Arten von Apps erstellen und bereitstellen, einschließlich Java- und Android-Apps. Eine Liste der unterstützten Linux-Distributionen finden Sie unter Überprüfen der Voraussetzungen .

Hinweis

In diesem Artikel wird beschrieben, wie Sie einen selbst gehosteten Agentkonfigurieren. Wenn Sie Azure DevOps Services verwenden und ein von Microsoft gehosteter Agent Ihre Anforderungen erfüllt, können Sie die Einrichtung eines selbst gehosteten Linux-Agents überspringen.

Informationen zu Agents

Wenn Sie bereits wissen, was ein Agent ist und wie es funktioniert, können Sie direkt in die folgenden Abschnitte springen. Wenn Sie jedoch mehr Hintergrundinformationen zu ihren Aufgaben und ihrer Funktionsweise benötigen, lesen Sie Azure Pipelines-Agents.

Überprüfen der Voraussetzungen

Der Agent basiert auf .NET 6. Sie können diesen Agent auf mehreren Linux-Distributionen ausführen. Wir unterstützen die folgende Teilmenge der unterstützten .NET 6-Verteilungen:

• Unterstützte Verteilungen
  • x64
    • Debian 10 und höher
    • Fedora 36+
    • openSUSE 15+
    • Red Hat Enterprise Linux 7+
      • Erfordert kein separates Paket mehr
    • SUSE Enterprise Linux 12 SP2 oder höher
    • Ubuntu 22.04, 20.04, 18.04, 16.04
    • Azure Linux 2.0
    • Oracle Linux 7 und höher
  • ARM64
    • Debian 10 und höher
    • Ubuntu 22.04, 20.04, 18.04
  • Alpine x64
    • Alpine Linux 3.13 und höher (erfordert Agent 3.227 oder höher)
• Git – Unabhängig von Ihrer Plattform müssen Sie Git 2.9.0 oder höher installieren. Es wird dringend empfohlen, die neueste Version von Git zu installieren.
• .NET – Die Agentsoftware wird auf .NET 6 ausgeführt, installiert jedoch eine eigene Version von .NET, sodass keine .NET-Voraussetzung vorhanden ist.
• Subversion – Wenn Sie aus einem Subversion-Repository erstellen, müssen Sie den Subversion-Client auf dem Computer installieren.
• TFVC: Wenn Sie einen Build anhand eines TFVC-Repositorys erstellen, finden Sie weitere Informationen unter Voraussetzungen für TFVC.

Hinweis

Das Agent-Installationsprogramm weiß, wie nach anderen Abhängigkeiten gesucht wird. Sie können diese Abhängigkeiten auf unterstützten Linux-Plattformen installieren, indem Sie im Agentverzeichnis ausgeführt ./bin/installdependencies.sh werden.

Beachten Sie, dass einige dieser Abhängigkeiten, die von .NET benötigt werden, von Websites von Drittanbietern abgerufen werden, z packages.efficios.com. B. . Überprüfen Sie das installdependencies.sh Skript, und stellen Sie sicher, dass von Ihrem Linux-Computer aus auf alle referenzierten Websites von Drittanbietern zugegriffen werden kann, bevor Sie das Skript ausführen.

Stellen Sie außerdem sicher, dass alle erforderlichen Repositorys mit dem entsprechenden Paket-Manager verbunden sind (z. B installdependencies.sh . oder zypper).apt

Bei Problemen mit der Installation von Abhängigkeiten (z. B. "Abhängigkeit wurde im Repository nicht gefunden" oder "Problem beim Abrufen der Repositoryindexdatei") können Sie sich zur weiteren Unterstützung an den Verteilungsbesitzer wenden.

Sie sollten das Agent-Setup beim ersten Mal manuell ausführen. Nachdem Sie ein Gefühl dafür bekommen haben, wie Agents funktionieren, oder wenn Sie die Einrichtung vieler Agents automatisieren möchten, können Sie die unbeaufsichtigte Konfiguration verwenden.

Vorbereiten von Berechtigungen

Informationssicherheit für selbstgehostete Agents

Der Benutzer, der den Agent konfiguriert, benötigt Pooladministratorberechtigungen, der Benutzer, der den Agent ausführt, jedoch nicht.

Die vom Agent gesteuerten Ordner sollten auf so wenige Benutzer wie möglich beschränkt werden, da sie geheime Schlüssel enthalten, die entschlüsselt oder exfiltriert werden können.

Der Azure Pipelines-Agent ist ein Softwareprodukt, das zum Ausführen von Code entwickelt wurde, der von externen Quellen heruntergeladen wird. Es könnte von Natur aus ein Ziel für Remote-Code-Execution (RCE)-Angriffe sein.

Daher ist es wichtig, das Bedrohungsmodell für jede einzelne Verwendung von Pipelines-Agents zur Ausführung von Arbeiten zu berücksichtigen und zu entscheiden, welche Mindestberechtigungen dem Benutzer, der den Agent ausführt, auf dem Computer, auf dem der Agent läuft, den Benutzern mit Schreibzugriff auf die Pipelinedefinition, die Git-Repositories, in denen das yaml gespeichert ist, oder der Gruppe von Benutzern, die den Zugriff auf den Pool für neue Pipelines steuern, gewährt werden können.

Es empfiehlt sich, die Identität, mit der der Agent ausgeführt wird, von der Identität mit Berechtigungen zum Verbinden des Agents mit dem Pool zu unterscheiden. Der Benutzer, der die Anmeldeinformationen (und andere agentbezogene Dateien) generiert, unterscheidet sich von dem Benutzer, der sie lesen muss. Daher ist es sicherer, den Zugriff auf den Agent-Computer selbst und die Agent-Ordner, die vertrauliche Dateien wie Protokolle und Artefakte enthalten, sorgfältig zu prüfen.

Es ist sinnvoll, nur DevOps-Administratoren und der Benutzeridentität, die den Agent-Prozess ausführt, Zugriff auf den Agent-Ordner zu gewähren. Administratoren müssen möglicherweise das Dateisystem untersuchen, um Buildfehler zu verstehen oder Protokolldateien abzurufen, um Azure DevOps-Fehler zu melden.

Entscheiden Sie, welchen Benutzer Sie verwenden möchten

Als einmaliger Schritt müssen Sie den Agent registrieren. Jemand mit Berechtigung zum Verwalten der Agent-Warteschlange muss diese Schritte ausführen. Der Agent verwendet die Anmeldeinformationen dieser Person nicht im täglichen Betrieb, sie sind aber erforderlich, um die Registrierung abzuschließen. Erfahren Sie mehr über die Kommunikation von Agents.

Vergewissern Sie sich, dass der Benutzer über die Berechtigung verfügt

Stellen Sie sicher, dass das Benutzerkonto, das Sie verwenden werden, über die Berechtigung zum Registrieren des Agents verfügt.

Ist der Benutzer ein Azure DevOps-Organisationsbesitzer oder TFS- oder Azure DevOps Server-Administrator? Halten Sie hier an, Sie haben die Erlaubnis.

Andernfalls:

1. Öffnen Sie einen Browser, und navigieren Sie zur Registerkarte Agent-Pools für Ihre Azure Pipelines-Organisation oder Azure DevOps Server- oder TFS-Server:

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

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Wählen Sie rechts auf der Seite den Pool aus, und klicken Sie dann auf Sicherheit.

3. Sollte das Benutzerkonto, das Sie verwenden möchten, nicht angezeigt werden, bitten Sie einen Administrator, es hinzuzufügen. Der Administrator kann ein Agentpool-Administrator, ein Azure DevOps-Organisationsinhaberoder ein TFS- oder Azure DevOps Server-Administratorsein.

   Wenn es sich um einen Bereitstellungsgruppen-Agent handelt, kann der Administrator ein Bereitstellungsgruppenadministrator, Azure DevOps-Organisationsbesitzer oder TFS- oder Azure DevOps Server-Administrator sein.

   Sie können der Administratorrolle der Bereitstellungsgruppe in Azure Pipelines auf der Seite Bereitstellungsgruppen auf der Registerkarte Sicherheit einen Benutzer hinzufügen.

Hinweis

Wenn eine Meldung wie „Die Identität konnte leider nicht hinzugefügt werden. Versuchen Sie es mit einer anderen Identität.“ angezeigt wird, haben Sie wahrscheinlich die oben genannten Schritte für einen Organisationsbesitzer- oder TFS- oder Azure DevOps Server-Administrator ausgeführt. Sie müssen nichts tun; Sie verfügen bereits über die Berechtigung zum Verwalten des Agentpools.

Herunterladen und Konfigurieren des Agents

Azure-Pipelines

1. Melden Sie sich beim Computer mit dem Konto an, für das Sie Berechtigungen wie im vorherigen Abschnitt erläutert vorbereitet haben.

2. Melden Sie sich in Ihrem Webbrowser bei Azure Pipelines an, und navigieren Sie zur Registerkarte Agent-Pools:

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

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

3. Wählen Sie den Pool Standard, die Registerkarte Agents und anschließend Neuer Agent aus.

4. Klicken Sie im Dialogfeld "Agent abrufen " auf "Linux".

5. Wählen Sie im linken Bereich den spezifischen Geschmack aus. Wir bieten x64 oder ARM für viele Linux-Distributionen an.

6. Klicken Sie im rechten Bereich auf die Schaltfläche Herunterladen.

7. Folgen Sie den Anweisungen auf der Seite.
   

8. Entpacken Sie den Agent in ein Verzeichnis Ihrer Wahl. cd in dieses Verzeichnis, und führen Sie ./config.sh aus.

Server-URL

Azure-Pipelines: https://dev.azure.com/{your-organization}

Authentifizierungsart

Wenn Sie Agenten registrieren, wählen Sie aus den folgenden Authentifizierungstypen aus, und die Agenteneinrichtung fordert Sie auf, die erforderlichen spezifischen zusätzlichen Informationen für jeden Authentifizierungstyp anzugeben. Weitere Informationen finden Sie unter Authentifizierungsoptionen für selbstgehostete Agents.

• Persönliches Zugriffstoken
• Gerätecodeflow
• Service Principal

Interaktiv ausführen

Anleitungen dazu, ob der Agent im interaktiven Modus oder als Dienst ausgeführt werden soll, finden Sie unter Agents: Interactive vs. service.

So führen Sie den Agent interaktiv aus

1. Wenn Sie den Agent als Dienst ausgeführt haben, deinstallieren Sie den Dienst.

2. Führen Sie den Agent aus.

   ./run.sh
   

Um den Agent neu zu starten, drücken Sie STRG+C, und führen Sie dann run.sh aus, um ihn neu zu starten.

Um Ihren Agent zu verwenden, führen Sie einen Auftrag unter Verwendung des Agentpools aus. Wenn Sie keinen anderen Pool ausgewählt haben, wird Ihr Agent im Pool Standard platziert.

Einmal ausführen

Bei Agents, die dafür konfiguriert sind, interaktiv zu laufen, können Sie auswählen, dass der Agent nur einen Auftrag akzeptiert. Ausführung in dieser Konfiguration:

./run.sh --once

Agents in diesem Modus akzeptieren nur einen Auftrag und drehen dann ordnungsgemäß nach unten (nützlich für die Ausführung in Docker auf einem Dienst wie Azure-Containerinstanzen).

Als systemd service ausführen

Wenn Ihr Agent auf diesen Betriebssystemen ausgeführt wird, können Sie den Agent als systemd Dienst ausführen:

• Ubuntu 16 LTS oder neuer
• Red Hat 7.1 oder höher

Wir stellen ein Beispielskript ./svc.sh bereit, mit dem Sie Ihren Agent als systemd Dienst ausführen und verwalten können. Dieses Skript wird generiert, nachdem Sie den Agent konfiguriert haben. Wir empfehlen Ihnen, das Skript zu überprüfen und bei Bedarf zu aktualisieren, bevor Sie es ausführen.

Einige wichtige Vorbehalte:

• Wenn Sie Ihren Agent als Dienst ausführen, können Sie den Agentdienst nicht als root Benutzer ausführen.
• Benutzer, die SELinux ausführen, haben Schwierigkeiten mit dem bereitgestellten svc.sh Skript gemeldet. Verweisen Sie auf dieses Agentproblem als Ausgangspunkt. SELinux ist keine offiziell unterstützte Konfiguration.

Hinweis

Wenn Sie über eine andere Verteilung verfügen oder andere Ansätze bevorzugen, können Sie jeden von Ihnen gewünschten Dienstmechanismus verwenden. Weitere Informationen unter Dienstdateien.

Befehle

Zum Agentenverzeichnis wechseln

Wenn Sie beispielsweise im Unterordner myagent Ihres Basisverzeichnisses installiert haben:

cd ~/myagent$

Installieren

Befehl:

sudo ./svc.sh install [username]

Mit diesem Befehl wird eine Dienstdatei erstellt, die auf ./runsvc.sh. Dieses Skript richtet die Umgebung ein (weitere Details unten) und startet den Agents-Host. Wenn username kein Parameter angegeben ist, wird der Benutzername aus der umgebungsvariablen $SUDO_USER entnommen, die durch den Befehl "sudo" festgelegt wird. Diese Variable ist immer gleich dem Namen des Benutzers, der den sudo Befehl aufgerufen hat.

Starten

sudo ./svc.sh start

Der Status

sudo ./svc.sh status

Stopp!

sudo ./svc.sh stop

Deinstallieren

Sie sollten aufhören, bevor Sie deinstallieren.

sudo ./svc.sh uninstall

Aktualisieren von Umgebungsvariablen

Wenn Sie den Dienst konfigurieren, benötigt er eine Momentaufnahme einiger nützlicher Umgebungsvariablen für Ihren aktuellen Anmeldebenutzer, z. B. PATH, LANG, JAVA_HOME, ANT_HOME und MYSQL_PATH. Wenn Sie die Variablen aktualisieren müssen (z. B. nach der Installation einiger neuer Software):

./env.sh
sudo ./svc.sh stop
sudo ./svc.sh start

Die Momentaufnahme der Umgebungsvariablen wird in .env datei gespeichert (PATH wird in .path) im Agentstammverzeichnis gespeichert, Sie können diese Dateien auch direkt ändern, um Umgebungsvariablenänderungen anzuwenden.

Ausführen von Anweisungen vor dem Starten des Diensts

Sie können auch eigene Anweisungen und Befehle festlegen, die beim Starten des Dienstes ausgeführt werden sollen. Sie können z. B. die Umgebung einrichten oder Skripts aufrufen.

1. Bearbeiten Sie runsvc.sh.

2. Ersetzen Sie die folgende Zeile durch Ihre Anweisungen:

   # insert anything to setup env when running as a service
   

Dienstdateien

Wenn Sie den Dienst installieren, werden einige Dienstdateien eingerichtet.

systemd service file

Es wird eine systemd Dienstdatei erstellt:

/etc/systemd/system/vsts.agent.{tfs-name}.{agent-name}.service

Beispielsweise haben Sie einen Agent (siehe oben) mit dem Namen our-linux-agentkonfiguriert. Die Dienstdatei ist entweder:

• Azure Pipelines: der Name Ihrer Organisation. Wenn Sie beispielsweise eine Verbindung zu https://dev.azure.com/fabrikamherstellen, ist der Dienstname /etc/systemd/system/vsts.agent.fabrikam.our-linux-agent.service.

• TFS oder Azure DevOps Server: der Name Ihres lokalen Servers. Wenn Sie beispielsweise eine Verbindung zu http://our-server:8080/tfsherstellen, ist der Dienstname /etc/systemd/system/vsts.agent.our-server.our-linux-agent.service.

sudo ./svc.sh install generiert diese Datei aus dieser Vorlage: ./bin/vsts.agent.service.template

.service-Datei

sudo ./svc.sh start findet den Dienst durch Lesen der .service Datei, die den Namen der oben beschriebenen Systemdienstdatei enthält.

Alternative Servicemechanismen

Wir bieten das ./svc.sh Skript als bequeme Möglichkeit für Sie, Ihren Agent als systemierten Dienst auszuführen und zu verwalten. Sie können jedoch jede Art von Dienstmechanismus verwenden, die Sie bevorzugen (z. B. initd oder upstart).

Sie können die oben beschriebene Vorlage verwenden, um das Generieren anderer Arten von Dienstdateien zu vereinfachen.

Verwenden einer cgroup, um Agentfehler zu vermeiden

Es ist wichtig, Situationen zu vermeiden, in denen der Agent fehlschlägt oder unbrauchbar wird, da andernfalls der Agent keine Pipelineprotokolle streamen oder den Pipelinestatus wieder an den Server melden kann. Sie können das Risiko dieser Art von Problem verringern, das durch hohen Arbeitsspeicherdruck verursacht wird, indem cgroups Sie und eine niedrigere oom_score_adj. Nachdem Sie dies getan haben, gibt Linux den Systemspeicher aus Pipelineauftragsprozessen zurück, bevor Der Speicher aus dem Agentprozess zurückgibt. Erfahren Sie, wie Sie die OOM-Bewertung konfigurieren und konfigurierencgroups.

Einen Agenten ersetzen

Um einen Agent zu ersetzen, führen Sie die Schritte unter Herunterladen und Konfigurieren des Agents erneut aus.

Wenn Sie einen Agent mit demselben Namen wie ein bereits vorhandener Agent konfigurieren, werden Sie gefragt, ob Sie den vorhandenen Agent ersetzen möchten. Wenn Sie Ybeantworten, stellen Sie sicher, dass Sie den Agent entfernen (siehe unten), den Sie ersetzen. Andernfalls wird einer der Agents nach einigen Minuten mit Konflikten heruntergefahren.

Entfernen und Neukonfigurieren eines Agents

So entfernen Sie den Agenten:

1. Beenden und deinstallieren Sie den Dienst, wie im vorherigen Abschnitt erläutert.

2. Entfernen Sie den Agenten.

   ./config.sh remove
   

3. Geben Sie Ihre Anmeldeinformationen ein.

Nachdem Sie den Agent entfernt haben, können Sie ihn erneut konfigurieren.

Unbeaufsichtigte Konfiguration

Der Agent kann aus einem Skript ohne menschliche Intervention eingerichtet werden. Sie müssen --unattended und die Antworten auf alle Fragen übergeben.

Um einen Agent zu konfigurieren, muss er die URL zu Ihrer Organisation oder Sammlung sowie die Anmeldeinformationen einer Person kennen, die zum Einrichten von Agents autorisiert ist. Alle anderen Antworten sind optional. Befehlszeilenparameter können stattdessen mithilfe einer Umgebungsvariablen angegeben werden: Geben Sie den Namen in Großbuchstaben ein, und stellen Sie VSTS_AGENT_INPUT_ voran. Beispiel: VSTS_AGENT_INPUT_PASSWORD statt --passwordanzugeben.

Erforderliche Optionen

• --unattended: Bei der Einrichtung des Agents werden keine Informationen angefordert, und alle Einstellungen müssen über die Befehlszeile bereitgestellt werden.
• --url <url> – URL des Servers. Beispiel: https://dev.azure.com/myorganization oder http://my-azure-devops-server:8080/tfs.
• --auth <type> – Authentifizierungstyp. Gültige Werte sind:
  • pat (Persönliches Zugriffstoken) – PAT ist das einzige Schema, das mit Azure DevOps Services funktioniert.
  • alt (Standardauthentifizierung)

Authentifizierungsoptionen

• Wenn Sie --auth patausgewählt haben:
  • --token <token> – Gibt Ihr persönliches Zugriffstoken an.
  • PAT ist das einzige Schema, das mit Azure DevOps Services funktioniert.
• Wenn Sie --auth negotiate oder --auth altausgewählt haben:
  • --userName <userName> – Gibt einen Benutzernamen an
  • --password <password> – Gibt ein Kennwort an.

Pool- und Agentnamen

• --pool <pool>: Name des Pools, dem der Agent beitreten soll
• --agent <agent> - Agentenname
• --replace: Option zum Ersetzen des Agents in einem Pool. Wenn ein anderer Agent mit dem gleichen Namen lauscht, tritt ein Konflikt auf

Einrichtung des Agents

• --work <workDirectory> – Arbeitsverzeichnis, in dem Auftragsdaten gespeichert werden. Der Standardwert _work befindet sich im Stammverzeichnis des Agent-Verzeichnisses. Das Arbeitsverzeichnis gehört einem bestimmten Agent und sollte nicht zwischen mehreren Agents geteilt werden.
• --acceptTeeEula - den Endbenutzer-Lizenzvertrag für Team Explorer Everywhere akzeptieren (nur macOS und Linux)
• --disableloguploads: legt fest, dass die Ausgabe des Konsolenprotokolls nicht an den Server gestreamt oder gesendet werden soll. Stattdessen können Sie sie nach Abschluss des Auftrags aus dem Dateisystem des Agent-Hosts abrufen.

Nur für die Bereitstellungsgruppe

• --deploymentGroup - den Agenten als Bereitstellungsgruppen-Agenten konfigurieren
• --deploymentGroupName <name>: wird mit --deploymentGroup verwendet, um die Bereitstellungsgruppe anzugeben, der der Agent beitreten soll
• --projectName <name>: wird mit --deploymentGroup verwendet, um den Projektnamen festzulegen
• --addDeploymentGroupTags: wird mit --deploymentGroup verwendet, um anzugeben, dass Bereitstellungsgruppentags hinzugefügt werden sollen
• --deploymentGroupTags <tags> – wird zusammen mit --addDeploymentGroupTags verwendet, um die durch Kommas getrennte Liste von Tags für den Bereitstellungsgruppen-Agent anzugeben, z. B. "web, db"

Nur für Umgebungen

• --addvirtualmachineresourcetags: wird verwendet, um anzugeben, dass Umgebungsressourcentags hinzugefügt werden sollen
• --virtualmachineresourcetags <tags>: wird mit --addvirtualmachineresourcetags verwendet, um die durch Trennzeichen getrennte Liste von Tags für den Umgebungsressourcen-Agent anzugeben (beispielsweise „web, db“)

./config.sh --help listet immer die neuesten erforderlichen und optionalen Antworten auf.

Diagnostik

Wenn Sie Probleme mit Ihrem selbstgehosteten Agent haben, können Sie versuchen, Diagnosen auszuführen. Nach dem Konfigurieren des Agents:

./run.sh --diagnostics

Dadurch wird eine Diagnosesuite ausgeführt, die Ihnen bei der Problembehandlung helfen kann. Das Diagnosefeature ist ab Agent Version 2.165.0 verfügbar.

Netzwerkdiagnose für selbst gehostete Agenten

Legen Sie den Wert von Agent.Diagnostic auf true fest, um zusätzliche Protokolle zu sammeln, die zur Fehlerbehebung von Netzwerkproblemen für selbst-gehostete Agents verwendet werden können. Weitere Informationen finden Sie unter Netzwerkdiagnose für selbstgehostete Agents.

Hilfe zu anderen Optionen

Um sich über andere Optionen zu informieren:

./config.sh --help

Die Hilfe enthält Informationen zu Authentifizierungsalternativen und unbeaufsichtigter Konfiguration.

Fähigkeiten

Die Funktionen Ihres Agents werden katalogisiert und im Pool angekündigt, sodass ihm nur die Builds und Releases zugewiesen werden, die er bewältigen kann. Weitere Informationen finden Sie unter Funktionen von Build- und Release-Agents.

In vielen Fällen müssen Sie nach der Bereitstellung eines Agents Software oder Hilfsprogramme installieren. Im Allgemeinen sollten Sie alle Softwarekomponenten und Tools, die Sie auf Ihrem Entwicklungscomputer verwenden, auf Ihren Agents installieren.

Wenn Ihr Build beispielsweise die npm-Aufgabe enthält, wird der Build nur ausgeführt, wenn im Pool ein Build-Agent mit einer npm-Installation vorhanden ist.

Von Bedeutung

Zu den Funktionen gehören alle Umgebungsvariablen und die Werte, die bei der Ausführung des Agents festgelegt werden. Wenn sich einer dieser Werte ändert, während der Agent ausgeführt wird, muss der Agent neu gestartet werden, um die neuen Werte zu übernehmen. Nachdem Sie neue Software auf einem Agent installiert haben, müssen Sie ihn neu starten, damit die neue Funktion im Pool angezeigt wird und der Build ausgeführt werden kann.

Wenn Sie Umgebungsvariablen als Funktionen ausschließen möchten, können Sie sie festlegen, indem Sie eine Umgebungsvariable VSO_AGENT_IGNORE mit einer durch Trennzeichen getrennten Liste von Variablen festlegen, die ignoriert werden sollen.

Häufig gestellte Fragen

Wo kann ich mehr über die neue v3-Agent-Software erfahren?

Informationen und FAQs zur v3-Agent-Software finden Sie unter Agent-Software, Version 3.

Wie kann ich sicherstellen, dass ich die neueste Agent-Version habe?

1. Navigieren Sie zur Registerkarte Agent-Pools:

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

   2. Wählen Sie Azure DevOps, Organisationseinstellungen aus.

      

   3. Wählen Sie Agentpools aus.

      

2. Klicken Sie auf den Pool, der den Agenten enthält.

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

4. Navigieren 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 anhand der neuesten veröffentlichten Agent-Version überprüfen. Weitere Informationen finden Sie unter Azure Pipelines-Agent. Suchen Sie auf der Seite nach der höchsten Versionsnummer.

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 Alle Agents aktualisieren aus.

Warum ist sudo erforderlich, um die Dienstbefehle auszuführen?

./svc.sh verwendet systemctl, was erforderlich ist sudo.

Quellcode: systemd.svc.sh.template auf GitHub

Ich habe eine Firewall ausgeführt, und mein Code befindet sich in Azure Repos. Mit welchen URLs muss der Agent kommunizieren?

Wenn Sie einen Agent in einem sicheren Netzwerk hinter einer Firewall ausführen, stellen Sie sicher, dass der Agent die Kommunikation mit den folgenden URLs und IP-Adressen initiieren kann.

Domänen-URL	BESCHREIBUNG
https://{organization_name}.pkgs.visualstudio.com	Azure DevOps Packaging API für Organisationen, die die domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.visualstudio.com	Für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vsblob.visualstudio.com	Azure DevOps-Telemetriedaten für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vsrm.visualstudio.com	Release Management Services für Organisationen, die die domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vssps.visualstudio.com	Azure DevOps Platform Services für Organisationen, die die domäne {organization_name}.visualstudio.com verwenden
https://{organization_name}.vstmr.visualstudio.com	Azure DevOps Test Management Services für Organisationen, die die {organization_name}.visualstudio.com Domäne verwenden
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	Für Organisationen, die die Domäne dev.azure.com verwenden
https://*.vsassets.io	Azure Artifacts über CDN
https://*.vsblob.visualstudio.com	Azure DevOps-Telemetriedaten für Organisationen, die die Domäne dev.azure.com verwenden
https://*.vssps.visualstudio.com	Azure DevOps Platform Services für Organisationen, die die domäne dev.azure.com verwenden
https://*.vstmr.visualstudio.com	Azure DevOps Test Management Services für Organisationen, die die dev.azure.com Domäne verwenden
https://app.vssps.visualstudio.com	Für Organisationen, die die Domäne {organization_name}.visualstudio.com verwenden
https://dev.azure.com	Für Organisationen, die die Domäne dev.azure.com verwenden
https://login.microsoftonline.com	Microsoft Entra-Anmeldung
https://management.core.windows.net	Azure-Verwaltungs-APIs
https://download.agent.dev.azure.com	Agentpaket

Von Bedeutung

Edgio CDN für Azure DevOps wurde eingestellt, was erfordert, dass eine neue Domänen-URL in Firewallregeln zum Herunterladen von Agentsoftware zugelassen wird. Die neue Domäne, die für den Agentdownload zugelassen werden soll, ist https://*.dev.azure.com. Wenn Ihre Firewallregeln keine Wildcards zulassen, verwenden Sie https://download.agent.dev.azure.com.

Das Azure DevOps-Team empfiehlt, diese Änderung bis zum folgenden Datum vorzunehmen:

• 1. Mai 2025 für Azure DevOps Services
• 15. Mai 2025 für Azure DevOps Server

Weitere Informationen finden Sie unter CDN Domain URL change for Agents in Pipelines.

Um zu gewährleisten, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com und *dev.azure.com geöffnet sind, und aktualisieren Sie Ihre zugelassenen IP-Adressen basierend auf Ihrer IP-Version so, dass sie die folgenden IP-Adressen enthalten. Wenn sich die IP-Adressen 13.107.6.183 und 13.107.9.183 derzeit in der Positivliste befinden, lassen Sie sie dort, da sie nicht entfernt werden müssen.

IP V4-Bereiche

13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

IP V6-Bereiche

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Hinweis

Weitere Informationen zu zulässigen Adressen finden Sie unter Listen zulässiger Adressen und Netzwerkverbindungen.

Wie kann ich den Agent mit einem selbstsigniertem Zertifikat ausführen?

Ausführen des Agents mit selbstsigniertem Zertifikat

Wie kann ich den Agent hinter einem Webproxy ausführen?

Ausführen des Agents hinter einem Webproxy

Wie kann ich den Agent neu starten

Wenn Sie den Agenten interaktiv ausführen, lesen Sie bitte die Neustartanweisungen unter Interaktiv ausführen. Wenn Sie den Agent als systemd-Dienst ausführen, führen Sie die Schritte zum Beendenund Starten des Agents aus.

Wie konfiguriere ich den Agent so, dass er einen Webproxy umgeht und eine Verbindung mit Azure Pipelines herstellt?

Wenn der Agent Ihren Proxy umgehen und eine direkte Verbindung mit Azure Pipelines herstellen soll, sollten Sie Ihren Webproxy so konfigurieren, dass der Agent auf die folgenden URLs zugreifen kann.

Für Organisationen, die die domäne *.visualstudio.com verwenden:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

Für Organisationen, die die domäne dev.azure.com verwenden:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://download.agent.dev.azure.com
https://vssps.dev.azure.com

Um zu gewährleisten, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com und *dev.azure.com geöffnet sind, und aktualisieren Sie Ihre zugelassenen IP-Adressen basierend auf Ihrer IP-Version so, dass sie die folgenden IP-Adressen enthalten. Wenn sich die IP-Adressen 13.107.6.183 und 13.107.9.183 derzeit in der Positivliste befinden, lassen Sie sie dort, da sie nicht entfernt werden müssen.

IP V4-Bereiche

13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

IP V6-Bereiche

2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
2620:1ec:50::/48 
2620:1ec:51::/48 
2603:1061:10::/48

Hinweis

Mit diesem Verfahren kann der Agent einen Webproxy umgehen. Ihre Buildpipeline und Skripts müssen weiterhin die Umgehung Ihres Webproxys für jede Aufgabe und jedes Tool verarbeiten, die bzw. das Sie in Ihrem Build ausführen.

Wenn Sie beispielsweise eine NuGet-Aufgabe verwenden, müssen Sie Ihren Webproxy so konfigurieren, dass er die Umgehung der URL für den Server unterstützt, der den verwendeten NuGet-Feed hostet.

TFVC-Voraussetzungen

Wenn Sie TFVC verwenden, benötigen Sie auch Oracle Java JDK 1.6 oder höher. (Die Oracle JRE und OpenJDK sind für diesen Zweck nicht ausreichend.)

Das TEE-Plug-In wird für TFVC-Funktionen verwendet. Es verfügt über eine EULA, die Sie während der Konfiguration akzeptieren müssen, wenn Sie beabsichtigen, mit TFVC zu arbeiten.

Da das TEE-Plug-In nicht mehr gewartet wird und einige veraltete Java-Abhängigkeiten enthält, ist es ab Agent 2.198.0 nicht mehr in der Agent-Distribution enthalten. Das TEE-Plug-In wird jedoch während der Ausführung der Auscheckaufgabe heruntergeladen, wenn Sie ein TFVC-Repository auschecken. Das TEE-Plug-In wird nach der Auftragsausführung entfernt.

Hinweis

Hinweis: Aufgrund dieses Downloadmechanismus kann es sehr lange dauern, bis Ihre Checkoutaufgabe funktioniert.

Wenn der Agent hinter einem Proxy oder einer Firewall ausgeführt wird, müssen Sie den Zugriff auf die folgende Website sicherstellen: https://vstsagenttools.blob.core.windows.net/ Das TEE-Plug-In wird von dieser Adresse heruntergeladen.

Wenn Sie einen selbst gehosteten Agenten verwenden und Probleme mit dem Herunterladen von TEE auftreten, können Sie TEE manuell installieren:

1. Legen Sie die Umgebungs- oder Pipelinevariable DISABLE_TEE_PLUGIN_REMOVAL auf true fest. Diese Variable verhindert, dass der Agent das TEE-Plugin nach dem Checkout des TFVC-Repositories entfernt.
2. Laden Sie TEE-CLC Version 14.135.0 manuell von den GitHub-Veröffentlichungen für Team Explorer Everywhere herunter.
3. Extrahieren Sie den Inhalt des Ordners TEE-CLC-14.135.0 in <agent_directory>/externals/tee.