Selbstgehostete Linux-Agents

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

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. Wir unterstützen Ubuntu, Red Hat und CentOS.

Vorbereitungen

  • Wenn Sich Ihre Pipelines in Azure Pipelines befinden und ein von Microsoft gehosteter Agent Ihre Anforderungen erfüllt, können Sie das Einrichten eines privaten Linux-Agents überspringen.
  • Andernfalls haben Sie an der richtigen Stelle einen Agent unter Linux eingerichtet. Sie können nun mit folgendem Artikel fortfahren:

Informationen zu Agents

Wenn Sie bereits wissen, was ein Agent ist und wie es funktioniert, können Sie direkt zu den folgenden Abschnitten springen. Wenn Sie jedoch mehr Hintergrund darüber wünschen, was sie tun und wie sie funktionieren, lesen Sie Azure Pipelines-Agents.

Überprüfen der Voraussetzungen

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

  • x64
    • CentOS 7, 6 (siehe Hinweis 1)
    • Debian 9
    • Fedora 30, 29
    • Linux Mint 18, 17
    • openSUSE 42.3 oder höher
    • Oracle Linux 7
    • Red Hat Enterprise Linux 8, 7, 6 (siehe Hinweis 1)
    • SUSE Enterprise Linux 12 SP2 oder höher
    • Ubuntu 20.04, 18.04, 16.04
    • CBL-Mariner 1.0 (siehe Hinweis 3)
  • ARM32 (siehe Hinweis 2)
    • Debian 9
    • Ubuntu 18.04
  • ARM64
    • Debian 9
    • Ubuntu 21.04, 20.04, 18.04

Hinweis

Hinweis 1: RHEL 6 und CentOS 6 erfordern die Installation der spezialisierten rhel.6-x64 Version des Agents.

Hinweis

Hinweis 2: ARM-Anweisungssatz ARMv7 oder höher ist erforderlich. Führen Sie die Ausführung uname -a aus, um den Anweisungssatz Ihres Linux-Distros anzuzeigen.

Hinweis

Die Mariner OS-Verteilung verfügt derzeit über teilweise Unterstützung des Azure DevOps-Agents. Wir stellen einen Mechanismus für die Erkennung dieser Betriebssystemverteilung in installdependencies.sh Skript bereit, aber aufgrund fehlender Unterstützung von der .NET Core-Seite konnten wir bei der Ausführung auf dieser Betriebssystemverteilung keine vollständige Funktionsfähigkeit aller Agentfunktionen garantieren.

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.

Hinweis

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

Beachten Sie, dass einige dieser Abhängigkeiten, die von .NET Core erforderlich sind, von Drittanbieterwebsites abgerufen werden, z packages.efficios.com. B. . Überprüfen Sie das installdependencies.sh Skript, und stellen Sie sicher, dass auf websites von Drittanbietern vor dem Ausführen des Skripts auf Ihren Linux-Computer zugegriffen werden kann.

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

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 für weitere Unterstützung an den Verteilungsbesitzer wenden.

TFS 2018 RTM und älter: Der versendete Agent basiert auf CoreCLR 1.0. Wenn möglich, sollten Sie ein Upgrade auf eine spätere Agentversion (2.125.0 oder höher) durchführen. Weitere Informationen zum Ausführen eines neueren Agents finden Sie unter Azure Pipelines-Agent-Prereqs .

Wenn Sie auf dem älteren Agent bleiben müssen, stellen Sie sicher, dass Ihr Computer mit unseren Voraussetzungen für eine der unterstützten Verteilungen vorbereitet ist:

Subversion

Wenn Sie aus einem Subversion-Repo erstellen, müssen Sie den Subversion-Client auf dem Computer installieren.

Sie sollten das Agent-Setup manuell ausführen. Nachdem Sie ein Gefühl dafür erhalten, wie Agents funktionieren oder wenn Sie das Einrichten vieler Agents automatisieren möchten, sollten Sie die unbeaufsichtigte Konfiguration verwenden.

TFVC

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.)

TEE-Plug-In wird für TFVC-Funktionalität verwendet. Es verfügt über eine EULA, die Sie während der Konfiguration akzeptieren müssen, wenn Sie die Arbeit mit TFVC planen.

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

Hinweis

Hinweis: Möglicherweise können Sie feststellen, dass Ihre Auscheckaufgabe lange dauert, um aufgrund dieses Downloadmechanismus zu arbeiten.

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 Agent verwenden und Probleme beim HERUNTERLADEN von TEE haben, können Sie TEE manuell installieren:

  1. Festlegen von DISABLE_TEE_PLUGIN_REMOVAL Umgebungs- oder Pipelinevariablen auf true. Diese Variable verhindert, dass der Agent das TEE-Plug-In nach dem Auschecken des TFVC-Repositorys entfernt.
  2. Laden Sie TEE-CLC Version 14.135.0 manuell aus Team Explorer Everywhere GitHub-Versionen herunter.
  3. Extrahieren Sie den Inhalt des Ordners TEE-CLC-14.135.0 in <agent_directory>/externals/tee.

Vorbereiten von Berechtigungen

Informationssicherheit für selbst gehostete Agents

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

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

Der ADO-Pipelines-Agent ist ein Softwareprodukt, das zum Ausführen von Code entwickelt wurde, der von externen Quellen heruntergeladen wird. Es könnte inhärent ein Ziel für Remotecodeausführungsangriffe (RCE) sein.

Daher ist es wichtig, das Bedrohungsmodell für jede einzelne Verwendung von Pipelines Agents zu berücksichtigen, um Arbeit auszuführen, und entscheiden, welche Mindestberechtigungen dem Benutzer gewährt werden können, auf dem der Agent ausgeführt wird, dem Computer, auf dem der Agent ausgeführt wird, den Benutzern, die Schreibzugriff auf die Pipelinedefinition haben, das Git repos, wo der Yaml gespeichert ist, oder die Gruppe der Benutzer, die den Zugriff auf den Pool für neue Pipelines steuern.

Es empfiehlt sich, die Identität, die den Agent ausführt, von der Identität mit Berechtigungen zu unterscheiden, um den Agent mit dem Pool zu verbinden. 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 Agentcomputer selbst und die Agentordner, die vertrauliche Dateien enthalten, wie Protokolle und Artefakte, sorgfältig zu berücksichtigen.

Es ist sinnvoll, nur für DevOps-Administratoren und die Benutzeridentität, die den Agentprozess ausführt, Zugriff auf den Agentordner 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 werden

Als einmaliger Schritt müssen Sie den Agent registrieren. Jemand mit der Berechtigung zum Verwalten der Agentwarteschlange muss diese Schritte ausführen. Der Agent verwendet die Anmeldeinformationen dieser Person nicht im täglichen Betrieb, aber sie müssen die Registrierung abschließen. Erfahren Sie mehr darüber , wie Agents kommunizieren.

Authentifizieren mit einem persönlichen Zugriffstoken (PAT)

  1. Melden Sie sich mit dem Benutzerkonto an, das Sie im Team Foundation Server-Webportal verwenden möchten (https://{your-server}:8080/tfs/).
  1. Melden Sie sich mit dem Benutzerkonto an, das Sie in Azure DevOps Server Webportal (https://{your-server}/DefaultCollection/) verwenden möchten.
  1. Melden Sie sich mit dem Benutzerkonto an, das Sie in Ihrer Azure DevOps-Organisation (https://dev.azure.com/{your_organization}) verwenden möchten.
  1. Öffnen Sie auf Ihrer Startseite Ihr Profil. Wechseln Sie zu Ihren Sicherheitsdetails.

    Wechseln Sie zu Ihren Sicherheitsdetails.

  2. Erstellen Sie ein persönliches Zugriffstoken.

    Erstellen Sie ein persönliches Zugriffstoken.

  1. Öffnen Sie über die Startseite Ihre Benutzereinstellungen, und wählen Sie dann Persönliche Zugriffstoken aus.

    Wechseln Sie zu Ihren Sicherheitsdetails.

  2. Erstellen Sie ein persönliches Zugriffstoken.

    Erstellen Sie ein persönliches Zugriffstoken.

  1. Wählen Sie für den Bereich Agentpools (lesen, verwalten) aus, und stellen Sie sicher, dass alle anderen Felder gelöscht werden. Wenn es sich um einen Bereitstellungsgruppen-Agent handelt, wählen Sie für den Bereich Die Bereitstellungsgruppe (lesen, verwalten) aus, und stellen Sie sicher, dass alle anderen Felder gelöscht werden.

    Wählen Sie unten im Fenster "Neue persönliche Zugriffstoken erstellen" alle Bereiche anzeigen, um die vollständige Liste der Bereiche anzuzeigen.

  2. Kopieren Sie das Token. Sie verwenden dieses Token, wenn Sie den Agent konfigurieren.

Bestätigen, dass der Benutzer über die Berechtigung verfügt

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

Ist der Benutzer ein Azure DevOps-Organisationsbesitzer oder TFS- oder Azure DevOps Server-Administrator? Beenden Sie hier, Sie haben die Berechtigung.

Andernfalls:

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

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

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie die Registerkarte

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools aus.

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Sammlungseinstellungen, 2019.

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools, 2019 aus.

    1. Navigieren Sie zu Ihrem Projekt, und wählen Sie "Einstellungen " (Zahnradsymbol) >Agentwarteschlangen aus.

      Wählen Sie

    2. Wählen Sie "Pools verwalten" aus.

      Wählen Sie

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

  3. Wenn das zu verwendende Benutzerkonto nicht angezeigt wird, erhalten Sie einen Administrator, um es hinzuzufügen. Der Administrator kann ein Agentpooladministrator, ein Azure DevOps-Organisationsbesitzeroder ein TFS- oder Azure DevOps Server-Administrator sein.

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

    Sie können einem Benutzer die Rolle des Bereitstellungsgruppenadministrators auf der Seite "Bereitstellungsgruppen " auf der Seite "Bereitstellungsgruppen" in Azure Pipelines hinzufügen.

Hinweis

Wenn eine Meldung wie folgt angezeigt wird: Leider konnten wir die Identität nicht hinzufügen. Bitte versuchen Sie eine andere Identität.Sie folgen wahrscheinlich den obigen Schritten für einen Organisationsbesitzer oder TFS oder Azure DevOps Server Administrator. Sie müssen nichts tun; Sie verfügen bereits über die Berechtigung zum Verwalten der Agentwarteschlange.

Herunterladen und Konfigurieren des Agents

Azure Pipelines

  1. Melden Sie sich mit dem Konto an, für das Sie berechtigungen wie oben beschrieben vorbereitet haben.

  2. Melden Sie sich in Ihrem Webbrowser bei Azure Pipelines an, und navigieren Sie zur Registerkarte "Agentpools ":

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

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie die Registerkarte

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools aus.

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Sammlungseinstellungen, 2019.

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools, 2019 aus.

    1. Navigieren Sie zu Ihrem Projekt, und wählen Sie "Einstellungen " (Zahnradsymbol) >Agentwarteschlangen aus.

      Wählen Sie

    2. Wählen Sie "Pools verwalten" aus.

      Wählen Sie

  3. Wählen Sie den Standardpool aus, wählen Sie die Registerkarte "Agents " aus, und wählen Sie "Neuer Agent" aus.

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

  5. Wählen Sie im linken Bereich den bestimmten Geschmack aus. Wir bieten x64 oder ARM für die meisten Linux-Distributionen an. Wir bieten auch einen bestimmten Build für Red Hat Enterprise Linux 6 an.

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

  7. Befolgen Sie die Anweisungen auf der Seite.

  8. Entpacken Sie den Agent in das Verzeichnis Ihrer Wahl. cd zu diesem Verzeichnis und ausführen ./config.sh.

Azure DevOps Server 2019 und Azure DevOps Server 2020

  1. Melden Sie sich mit dem Konto an, für das Sie berechtigungen wie oben beschrieben vorbereitet haben.

  2. Melden Sie sich im Webbrowser bei Azure DevOps Server 2019 an, und navigieren Sie zur Registerkarte "Agentpools":

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

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie die Registerkarte

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools aus.

    1. Wählen Sie Azure DevOps, Auflistungseinstellungen aus.

      Sammlungseinstellungen, 2019.

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools, 2019 aus.

    1. Navigieren Sie zu Ihrem Projekt, und wählen Sie "Einstellungen " (Zahnradsymbol) >Agentwarteschlangen aus.

      Wählen Sie

    2. Wählen Sie "Pools verwalten" aus.

      Wählen Sie

  3. Klicken Sie auf Agent herunterladen.

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

  5. Wählen Sie im linken Bereich den bestimmten Geschmack aus. Wir bieten x64 oder ARM für die meisten Linux-Distributionen an. Wir bieten auch einen bestimmten Build für Red Hat Enterprise Linux 6 an.

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

  7. Befolgen Sie die Anweisungen auf der Seite.

  8. Entpacken Sie den Agent in das Verzeichnis Ihrer Wahl. cdzu diesem Verzeichnis und ausführen ../config.sh

TFS 2018

  1. Melden Sie sich mit dem Konto an, für das Sie Berechtigungen vorbereitet haben, wie oben erläutert.

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

    1. Navigieren Sie zu Ihrem Projekt, und wählen Sie "Einstellungen " (Zahnradsymbol) >Agentwarteschlangen aus.

      Wählen Sie

    2. Wählen Sie "Pools verwalten" aus.

      Wählen Sie

  3. Klicken Sie auf Agent herunterladen.

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

  5. Klicken Sie auf die Schaltfläche "Herunterladen" .

  6. Befolgen Sie die Anweisungen auf der Seite.

  7. Entpacken Sie den Agent in das Verzeichnis Ihrer Wahl. cdzu diesem Verzeichnis und ausführen ../config.sh Stellen Sie sicher, dass der Pfad zum Verzeichnis keine Leerzeichen enthält, da Tools und Skripts keine ordnungsgemäßen Escapeplätze enthalten.

Server-URL

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

Azure DevOps Server 2019:https://{your_server}/DefaultCollection

TFS 2018: https://{your_server}/tfs

Authentifizierungsart

Azure Pipelines

Wählen Sie PAT aus, und fügen Sie dann das PAT-Token ein, das Sie in das Eingabeaufforderungsfenster erstellt haben.

Hinweis

Wenn Sie PAT als Authentifizierungsmethode verwenden, wird das PAT-Token nur für die anfängliche Konfiguration des Agents verwendet. Erfahren Sie mehr über die Kommunikation mit Azure Pipelines oder TFS.

TFS oder Azure DevOps Server

Wichtig

Stellen Sie sicher, dass Ihr Server so konfiguriert ist, dass die Authentifizierungsmethode unterstützt wird, die Sie verwenden möchten.

Wenn Sie Ihren Agent so konfigurieren, dass sie eine Verbindung mit TFS herstellen, haben Sie die folgenden Optionen:

  • Alternative Stellen Sie eine Verbindung mit TFS oder Azure DevOps Server mithilfe der Standardauthentifizierung her. Nachdem Sie "Alternative" ausgewählt haben, werden Sie zur Eingabe Ihrer Anmeldeinformationen aufgefordert.

  • Integrierte Wird unter macOS oder Linux nicht unterstützt.

  • Verhandeln (Standard) Herstellen einer Verbindung mit TFS oder Azure DevOps Server als anderer Benutzer als der angemeldete Benutzer über ein Windows-Authentifizierung Schema wie NTLM oder Kerberos. Nachdem Sie "Verhandeln" ausgewählt haben, werden Sie zur Eingabe von Anmeldeinformationen aufgefordert.

  • PAT Nur in Azure Pipelines und TFS 2017 und neuer unterstützt. Fügen Sie nach der Auswahl von PAT das von Ihnen erstellte PAT-Token in das Eingabeaufforderungsfenster ein. Verwenden Sie ein persönliches Zugriffstoken (PAT), wenn Ihre Azure DevOps Server- oder TFS-Instanz und der Agentcomputer sich nicht in einer vertrauenswürdigen Domäne befinden. DIE PAT-Authentifizierung wird von Ihrer Azure DevOps Server- oder TFS-Instanz anstelle des Domänencontrollers behandelt.

Hinweis

Bei verwendung von PAT als Authentifizierungsmethode wird das PAT-Token nur für die anfängliche Konfiguration des Agents auf Azure DevOps Server und die neueren Versionen von TFS verwendet. Erfahren Sie mehr über die Kommunikation mit Azure Pipelines oder TFS.

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 run.sh ihn dann aus, um ihn neu zu starten.

Um Ihren Agent zu verwenden, führen Sie einen Auftrag mit dem Agentpool aus. Wenn Sie keinen anderen Pool ausgewählt haben, befindet sich Ihr Agent im Standardpool .

Einmal ausführen

Damit Agents interaktiv ausgeführt werden können, können Sie auswählen, dass der Agent nur einen Auftrag akzeptiert. So führen Sie diese Konfiguration aus:

./run.sh --once

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

Als systemder Dienst 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 neuer

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 nach Bedarf zu überprüfen und zu aktualisieren, bevor sie ausgeführt wird.

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 jede Art von Dienstmechanismus verwenden, die Sie bevorzugen. Siehe Dienstdateien.

Befehle

Ändern in das Agentverzeichnis

Wenn Sie beispielsweise im myagent Unterordner Ihres Startverzeichniss installiert sind:

cd ~/myagent$

Installieren

Befehl:

sudo ./svc.sh install [username]

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

Start

sudo ./svc.sh start

Status

sudo ./svc.sh status

Stop

sudo ./svc.sh stop

Deinstallieren

Sie sollten vor der Deinstallation beenden.

sudo ./svc.sh uninstall

Aktualisieren von Umgebungsvariablen

Beim Konfigurieren des Diensts wird eine Momentaufnahme einiger nützlicher Umgebungsvariablen für Ihren aktuellen Anmeldebenutzer wie PATH, LANG, JAVA_HOME, ANT_HOME und MYSQL_PATH verwendet. 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 datei (PATH wird in .env.path) unter dem Agentstammverzeichnis gespeichert, Sie können diese Dateien auch direkt ändern, um Umgebungsvariablenänderungen anzuwenden.

Ausführen von Anweisungen vor dem Start des Diensts

Sie können auch eigene Anweisungen und Befehle ausführen, um beim Starten des Diensts auszuführen. 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

Eine Systemdienstdatei wird 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 z. B. eine Verbindung herstellen https://dev.azure.com/fabrikam, würde der Dienstname als "Dienstname" angezeigt. /etc/systemd/system/vsts.agent.fabrikam.our-linux-agent.service

  • TFS oder Azure DevOps Server: der Name Ihres lokalen Servers. Wenn Sie z. B. eine Verbindung herstellen http://our-server:8080/tfs, würde der Dienstname als "Dienstname" angezeigt. /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 file

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

Alternative Dienstmechanismen

Wir bieten das ./svc.sh Skript als bequeme Möglichkeit, Ihren Agent als systemd service auszuführen und zu verwalten. Sie können jedoch jede Art von Servicemechanismus verwenden, den Sie bevorzugen (z. B. initd oder upstart).

Sie können die oben beschriebene Vorlage verwenden, um die Erstellung anderer Dienstdateien zu erleichtern.

Verwenden einer Cgroup zum Vermeiden von Agentfehlern

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 zurück an den Server melden kann. Sie können das Risiko dieser Art von Problemen verringern, die durch hohen Arbeitsspeicherdruck verursacht werden, indem Sie Cgroups und einen niedrigeren oom_score_adjWert verwenden. Nachdem Sie dies getan haben, ruft Linux den Systemspeicher aus Pipelineauftragsprozessen zurück, bevor Sie den Arbeitsspeicher aus dem Agentprozess zurückfordern. Erfahren Sie, wie Sie Cgroups und OOM-Bewertung konfigurieren.

Ersetzen eines Agents

Um einen Agent zu ersetzen, führen Sie den Download aus, und konfigurieren Sie die Agentschritte erneut.

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 antworten, stellen Sie sicher, dass Sie Yden Agent entfernen (siehe unten), den Sie ersetzen. Andernfalls wird eine der Agents nach einigen Minuten Konflikte heruntergefahren.

Entfernen und Erneutes Konfigurieren eines Agents

So entfernen Sie den Agent

  1. Beenden und Deinstallieren Des Diensts wie oben erläutert.

  2. Entfernen Sie den Agent.

    ./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 die Antworten auf alle Fragen übergeben --unattended und beantworten.

Um einen Agent zu konfigurieren, muss er die URL ihrer Organisation oder Sammlung und Anmeldeinformationen einer Person kennen, die zum Einrichten von Agents autorisiert ist. Alle anderen Antworten sind optional. Ein beliebiger Befehlszeilenparameter kann stattdessen mithilfe einer Umgebungsvariable angegeben werden: Setzen Sie den Namen in Groß- und Kleinschreibung und vor VSTS_AGENT_INPUT_. Anstelle VSTS_AGENT_INPUT_PASSWORD der Angabe --passwordvon .

Erforderliche Optionen

  • --unattended - Agent-Setup fordert keine Informationen auf, und alle Einstellungen müssen in der 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.
    • negotiate (Kerberos oder NTLM)
    • alt (Grundlegende Authentifizierung)
    • integrated (Windows-Standardanmeldeinformationen)

Authentifizierungsoptionen

  • Wenn Sie folgendes ausgewählt --auth pathaben:
    • --token <token> - gibt Ihr persönliches Zugriffstoken an
    • PAT ist das einzige Schema, das mit Azure DevOps Services funktioniert.
  • Wenn Sie auswählen --auth negotiate oder --auth alt:
    • --userName <userName> - Gibt einen Windows-Benutzernamen im Format domain\userName oder userName@domain.com
    • --password <password> - gibt ein Kennwort an

Pool- und Agentnamen

  • --pool <pool> - Poolname für den Agent, der beitreten soll
  • --agent <agent> - Agentname
  • --replace - Ersetzen Sie den Agent in einem Pool. Wenn ein anderer Agent mit demselben Namen abhört, beginnt er mit einem Konflikt.

Agent-Setup

  • --work <workDirectory> - Arbeitsverzeichnis, in dem Auftragsdaten gespeichert werden. Standardmäßig unter _work dem Stamm des Agentverzeichniss. Das Arbeitsverzeichnis gehört zu einem bestimmten Agent und sollte nicht zwischen mehreren Agents freigegeben werden.
  • --acceptTeeEula- akzeptieren Sie die Team Explorer Everywhere Endbenutzerlizenzvereinbarung (nur macOS und Linux)
  • --disableloguploads - Streamen sie nicht oder senden Sie die Konsolenprotokollausgabe an den Server. Stattdessen können Sie sie nach Abschluss des Auftrags aus dem Dateisystem des Agenthosts abrufen.

Nur Windows-Start

  • --runAsService - Konfigurieren des Agents zum Ausführen als Windows-Dienst (erfordert Administratorberechtigungen)
  • --runAsAutoLogon - konfigurieren Sie die automatische Anmeldung und führen Sie den Agent beim Start aus (erfordert Administratorberechtigungen)
  • --windowsLogonAccount <account>- wird mit --runAsService oder zum Angeben des Windows-Benutzernamens im Format domain\userName oder --runAsAutoLogonuserName@domain.com
  • --windowsLogonPassword <password> - verwendet mit --runAsService--runAsAutoLogon oder zum Angeben des Windows-Anmeldekennworts (nicht erforderlich für Gruppen verwaltete Dienstkonten und Windows, die in Konten wie "NT AUTHORITY\NETWORK SERVICE" integriert sind)
  • --overwriteAutoLogon - wird verwendet, um --runAsAutoLogon die vorhandene automatische Anmeldung auf dem Computer zu überschreiben
  • --noRestart - wird verwendet, --runAsAutoLogon um den Host nach Abschluss der Agentkonfiguration neu zu starten.

Bereitstellungsgruppe nur

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

Nur Umgebungen

  • --addvirtualmachineresourcetags - wird verwendet, um anzugeben, dass Ressourcentags für Die Umgebung hinzugefügt werden sollen
  • --virtualmachineresourcetags <tags> - wird verwendet, --addvirtualmachineresourcetags um die durch Komma getrennte Liste der Tags für den Ressourcen-Agent für die Umgebung anzugeben - z. B. "web, db"

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

Diagnose

Wenn Sie Probleme mit Ihrem selbst gehosteten Agent haben, können Sie die Diagnose ausführen. Nachdem Sie den Agent konfiguriert haben:

./run.sh --diagnostics

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

Hilfe zu anderen Optionen

Informationen zu anderen Optionen:

./config.sh --help

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

Funktionen

Die Funktionen Ihres Agent werden katalogisiert und im Pool angezeigt, sodass nur die Builds und Versionen, die sie verarbeiten können, zugewiesen werden. Siehe Build- und Release-Agent-Funktionen.

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

Wenn Ihr Build beispielsweise die npm-Aufgabe enthält, wird der Build nicht ausgeführt, es sei denn, es gibt einen Build-Agent im Pool, der npm installiert hat.

Wichtig

Funktionen umfassen alle Umgebungsvariablen und die Werte, die festgelegt werden, wenn der Agent ausgeführt wird. Wenn sich eine dieser Werte ändert, während der Agent ausgeführt wird, muss der Agent neu gestartet werden, um die neuen Werte aufzunehmen. Nachdem Sie neue Software auf einem Agent installiert haben, müssen Sie den Agent für die neue Funktion neu starten, um im Pool anzuzeigen, damit der Build ausgeführt werden kann.

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

Häufig gestellte Fragen

Gewusst wie stellen Sie sicher, dass ich über die neueste v2-Agent-Version verfügt?

  1. Navigieren Sie zur Registerkarte "Agent-Pools ":

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

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Registerkarte

    1. Wählen Sie Azure DevOps, Sammlungseinstellungen aus.

      Wählen Sie

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agentpools aus.

    1. Wählen Sie Azure DevOps, Sammlungseinstellungen aus.

      Sammlungseinstellungen, 2019.

    2. Wählen Sie Agentpools aus.

      Wählen Sie Agent-Pools aus, 2019.

    1. Navigieren Sie zu Ihrem Projekt, und wählen Sie "Einstellungen " (Zahnradsymbol) >Agentwarteschlangen aus.

      Wählen Sie

    2. Wählen Sie "Pools verwalten" aus.

      Wählen Sie

  2. Klicken Sie auf den Pool, der den Agent 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 Agentpool aus.

      Wählen Sie aus Agentpools den gewünschten Agentpool aus.

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

      Wählen Sie Agents aus, und wählen Sie den Agent aus.

    3. Wählen Sie die Registerkarte "Funktionen " aus.

      Wählen Sie die Registerkarte

      Hinweis

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

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

      Wählen Sie den gewünschten Pool aus.

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

      Wählen Sie Agents aus, und wählen Sie den gewünschten Agent aus.

    3. Wählen Sie die Registerkarte "Funktionen " aus.

      Registerkarte

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

      Wählen Sie die gewünschte Registerkarte 2019 aus.

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

      Wählen Sie den gewünschten Agent 2019 aus.

    3. Wählen Sie die Registerkarte "Funktionen " aus.

      Wählen Sie die Registerkarte

    Wählen Sie den gewünschten Agent aus, und wählen Sie die Registerkarte "Funktionen " aus.

    Registerkarte

  5. Suchen Sie nach der Agent.Version Funktion. Sie können diesen Wert anhand der neuesten veröffentlichten Agent-Version überprüfen. Informationen finden Sie unter Azure Pipelines Agent , und überprüfen Sie die Seite auf die höchste Versionsnummer, die aufgelistet ist.

  6. Jeder Agent aktualisiert sich automatisch, wenn eine Aufgabe ausgeführt wird, 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.

Kann ich meine v2-Agents aktualisieren, die Teil eines Azure DevOps Server Pools sind?

Ja. Ab Azure DevOps Server 2019 können Sie Ihren Server so konfigurieren, dass Sie nach den Agent-Paketdateien auf einem lokalen Datenträger suchen. Diese Konfiguration überschreiben die Standardversion, die zum Zeitpunkt der Veröffentlichung mit dem Server enthalten ist. Dieses Szenario gilt auch, wenn der Server keinen Zugriff auf das Internet hat.

  1. Laden Sie auf einem Computer mit Internetzugriff die neueste Version der Agent-Paketdateien (in .zip- oder TAR.gz-Form) auf der Seite "GitHub-Versionen von Azure Pipelines Agent" herunter.

  2. Übertragen Sie die heruntergeladenen Paketdateien auf jede Azure DevOps Server Anwendungsebene, indem Sie eine Methode Ihrer Wahl verwenden (z. B. USB-Laufwerk, Netzwerkübertragung usw.). Platzieren Sie die Agentdateien unter dem %ProgramData%\Microsoft\Azure DevOps\Agents Ordner.

  3. Sie sind alle festgelegt! Ihr Azure DevOps Server verwendet jetzt die lokalen Dateien, wenn die Agents aktualisiert werden. Jeder Agent aktualisiert sich automatisch, wenn eine Aufgabe ausgeführt wird, die eine neuere Version des Agents erfordert. Wenn Sie jedoch einige Agents manuell aktualisieren möchten, klicken Sie mit der rechten Maustaste auf den Pool, und wählen Sie dann "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 führe eine Firewall aus 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 {organization_name}.visualstudio.com Domäne verwenden
https://{organization_name}.visualstudio.com Für Organisationen, die die {organization_name}.visualstudio.com Domäne verwenden
https://{organization_name}.vsblob.visualstudio.com Azure DevOps-Telemetrie für Organisationen, die die {organization_name}.visualstudio.com Domäne verwenden
https://{organization_name}.vsrm.visualstudio.com Release Management Dienste für Organisationen, die die {organization_name}.visualstudio.com Domäne verwenden
https://{organization_name}.vssps.visualstudio.com Azure DevOps Platform Services für Organisationen, die die {organization_name}.visualstudio.com Domäne 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 dev.azure.com Domäne verwenden
https://*.vsassets.io Azure-Artefakte über CDN
https://*.vsblob.visualstudio.com Azure DevOps-Telemetrie für Organisationen, die die dev.azure.com Domäne verwenden
https://*.vssps.visualstudio.com Azure DevOps Platform Services für Organisationen, die die dev.azure.com Domäne 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 {organization_name}.visualstudio.com Domäne verwenden
https://dev.azure.com Für Organisationen, die die dev.azure.com Domäne verwenden
https://login.microsoftonline.com Azure Active Directory-Registrierung
https://management.core.windows.net Azure Management API's
https://vstsagentpackage.azureedge.net Agent-Paket

Um sicherzustellen, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com Ihre zugelassenen IPs geöffnet und *dev.azure.com aktualisiert werden, um die folgenden IP-Adressen basierend auf Ihrer IP-Version einzuschließen. Wenn Sie derzeit die 13.107.6.183 Zulassungs- und IP-Adressen auflisten, lassen Sie sie an Ort und 13.107.9.183 Stelle, da Sie sie nicht entfernen müssen.

IPv4-Bereiche

  • 13.107.6.0/24
  • 13.107.9.0/24
  • 13.107.42.0/24
  • 13.107.43.0/24

IPv6-Bereiche

  • 2620:1ec:4::/48
  • 2620:1ec:a92::/48
  • 2620:1ec:21::/48
  • 2620:1ec:22::/48

Hinweis

Weitere Informationen zu zulässigen Adressen finden Sie unter "Zulässige Adresslisten" und "Netzwerkverbindungen".

Gewusst wie den Agent mit selbstsigniertem Zertifikat ausführen?

Ausführen des Agents mit selbstsigniertem Zertifikat

Gewusst wie den Agent hinter einem Webproxy ausführen?

Ausführen des Agents hinter einem Webproxy

Gewusst wie den Agent neu starten

Wenn Sie den Agent interaktiv ausführen, lesen Sie die Neustartanweisungen in "Interaktiv ausführen". Wenn Sie den Agent als Systemdienst ausführen, führen Sie die Schritte zum Beendenund Starten des Agents aus.

Gewusst wie konfigurieren, dass der Agent einen Webproxy umgehen 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 *.visualstudio.com Domäne 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 dev.azure.com Domäne verwenden:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://vstsagentpackage.azureedge.net
https://vssps.dev.azure.com

Um sicherzustellen, dass Ihre Organisation mit allen vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass dev.azure.com*dev.azure.com Ihre zugelassenen IPs geöffnet und aktualisiert werden, um die folgenden IP-Adressen basierend auf Ihrer IP-Version aufzunehmen. Wenn Sie derzeit die 13.107.6.183 Adressen und 13.107.9.183 IP-Adressen zulassen, lassen Sie sie an Ort und Stelle, da Sie sie nicht entfernen müssen.

IPv4-Bereiche

  • 13.107.6.0/24
  • 13.107.9.0/24
  • 13.107.42.0/24
  • 13.107.43.0/24

IPv6-Bereiche

  • 2620:1ec:4::/48
  • 2620:1ec:a92::/48
  • 2620:1ec:21::/48
  • 2620:1ec:22::/48

Hinweis

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

Wenn Sie beispielsweise eine NuGet-Aufgabe verwenden, müssen Sie Ihren Webproxy konfigurieren, um die URL für den Server zu umgehen, der den NuGet-Feed hostet, den Sie verwenden.

Ich verwende TFS und die URLs in den oben genannten Abschnitten funktionieren nicht für mich. Wo kann ich Hilfe erhalten?

Websiteeinstellungen und Sicherheit

Ich verwende TFS lokal und einige dieser Features werden nicht angezeigt. Warum nicht?

Einige dieser Features sind nur auf Azure Pipelines und noch nicht lokal verfügbar. Einige Features sind lokal verfügbar, wenn Sie ein Upgrade auf die neueste Version von TFS vorgenommen haben.