Weitere Überlegungen
Authentifizierung
Zum Registrieren eines Agents müssen Sie Mitglied der Administratorrolle im Agentpool sein.
Die Identität des Agentpooladministrators wird nur zum Zeitpunkt der Registrierung benötigt. Sie wird nicht für den Agent gespeichert und auch nicht bei der weiteren Kommunikation zwischen Agent und Azure Pipelines verwendet.
Außerdem müssen Sie ein lokaler Administrator auf dem Server sein, um den Agent zu konfigurieren.
Ihr Agent kann sich mit einer der folgenden Methoden bei Azure DevOps authentifizieren:
Persönliches Zugriffstoken (Personal Access Token, PAT)
Generieren und verwenden Sie ein PAT zum Verbinden eines Agents mit Azure Pipelines. PAT ist das einzige Schema, das mit Azure Pipelines funktioniert. Wie oben erläutert, wird dieses PAT nur bei der Registrierung des Agents und nicht für die nachfolgende Kommunikation verwendet.
Interaktiv im Vergleich zu Dienst
Sie können Ihren Agent entweder als Dienst oder als interaktiven Prozess ausführen. Unabhängig davon, ob Sie einen Agent als Dienst oder interaktiv ausführen, können Sie auswählen, welches Konto Sie zum Ausführen des Agents verwenden.
Hier besteht ein Unterschied zu Ihren Anmeldeinformationen, die Sie beim Registrieren des Agents bei Azure Pipelines verwendet haben. Die Auswahl des Agent-Kontos hängt ausschließlich von den Anforderungen der Aufgaben ab, die in Ihren Build- und Bereitstellungsaufträgen ausgeführt werden.
Beispielsweise müssen Sie für die Ausführung von Aufgaben, die die Windows-Authentifizierung für den Zugriff auf einen externen Dienst verwenden, den Agent mit einem Konto mit Zugriff auf diesen Dienst ausführen.
Wenn Sie jedoch UI-Tests wie Selenium oder Tests der programmierten UI ausführen, die einen Browser erfordern, wird der Browser im Kontext des Agent-Kontos gestartet.
Nach dem Konfigurieren des Agents wird empfohlen, ihn zunächst im interaktiven Modus zu testen, um sicherzustellen, dass er funktioniert. Anschließend wird empfohlen, den Agent in einem der folgenden Modi auszuführen, damit er weiterhin zuverlässig für die Produktion arbeitet. Diese Modi stellen auch sicher, dass der Agent automatisch gestartet wird, wenn der Computer neu gestartet wird.
Sie können den Dienst-Manager des Betriebssystems verwenden, um den Lebenszyklus des Agents zu verwalten. Außerdem läuft das automatische Upgrade des Agents besser ab, wenn er als Dienst ausgeführt wird.
Als interaktiver Prozess mit aktivierter automatischer Anmeldung. In einigen Fällen müssen Sie den Agent möglicherweise interaktiv für die Produktion ausführen, z. B. für UI-Tests.
Wenn der Agent für die Ausführung in diesem Modus konfiguriert ist, ist auch der Bildschirmschoner deaktiviert.
Einige Domänenrichtlinien verhindern möglicherweise, dass Sie die automatische Anmeldung aktivieren oder den Bildschirmschoner deaktivieren.
In solchen Fällen müssen Sie möglicherweise eine Ausnahme von der Domänenrichtlinie beantragen oder den Agent auf einem Arbeitsgruppencomputer ausführen, auf dem die Domänenrichtlinien nicht gelten.
Hinweis
Es bestehen Sicherheitsrisiken, wenn Sie die automatische Anmeldung aktivieren oder den Bildschirmschoner deaktivieren. Sie ermöglichen anderen Benutzern, auf Ihren Computer zuzugreifen und das Konto zu verwenden, das sich automatisch anmeldet. Wenn Sie den Agent so konfigurieren, dass er auf diese Weise ausgeführt wird, müssen Sie sicherstellen, dass der Computer physisch geschützt ist (sich beispielsweise in einer sicheren Einrichtung befindet). Wenn Sie den Remotedesktop verwenden, um auf den Computer zuzugreifen, auf dem ein Agent mit automatischer Anmeldung ausgeführt wird, führt das einfache Schließen des Remotedesktops dazu, dass der Computer gesperrt wird; UI-Tests, die auf diesem Agent ausgeführt werden, können fehlschlagen. Damit dies vermieden wird, trennen Sie die Verbindung mit dem Remotedesktop mit dem Befehl „tscon“.
Agent-Version und Upgrades
Microsoft aktualisiert die Agent-Software alle paar Wochen in Azure Pipelines.
Die Agent-Version wird im Format {Hauptversion}.{Nebenversion} angegeben. Wenn die Agent-Version beispielsweise 2.1 ist, ist die Hauptversion 2 und die Nebenversion 1.
Wenn eine neuere Version des Agents sich nur bei den Nebenversionen unterscheidet, führt Azure Pipelines automatisch ein Upgrade für ihn durch.
Dieses Upgrade erfolgt, wenn eine der Aufgaben eine neuere Version des Agents erfordert.
Wenn Sie den Agent interaktiv ausführen oder eine neuere Hauptversion des Agents verfügbar ist, müssen Sie manuell ein Upgrade für den Agent durchführen. Dies kann auch über die Registerkarte „Agentpools“ in Ihrer Projektsammlung oder Organisation geschehen.
Sie können die Version eines Agents anzeigen, indem Sie zu Agentpools navigieren und die Registerkarte „Funktionen“ für den gesuchten Agent auswählen.
Azure Pipelines: [https://dev.azure.com/{your_organization}/_admin/_AgentPool](https://dev.azure.com/{your_organization}/_admin/_AgentPool)
Fragen und Antworten
Haben selbstgehostete Agents gegenüber von Microsoft gehosteten Agents Leistungsvorteile?
In vielen Fällen ja. Dies gilt insbesondere in folgenden Fällen:
- Wenn Sie einen selbstgehosteten Agent verwenden, können Sie inkrementelle Builds ausführen. Sie definieren z. B. eine CI-Buildpipeline, die das Repository nicht bereinigt, oder einen bereinigten Build ausführen. Ihre Builds werden in der Regel schneller ausgeführt.
- Sie erhalten diese Vorteile nicht, wenn Sie einen von Microsoft gehosteten Agent verwenden. Der Agent wird nach Abschluss der Build- oder Releasepipeline zerstört.
- Es kann länger dauern, bis der Build von einem von Microsoft gehosteten Agent gestartet wird. Obwohl es häufig nur wenige Sekunden dauert, bis Ihr Auftrag einem von Microsoft gehosteten Agent zugewiesen wird, kann es je nach Auslastung des Systems manchmal mehrere Minuten dauern, bis ein Agent zugeordnet wird.
Kann ich mehrere selbstgehostete Agents auf demselben Computer installieren?
Ja. Dieser Ansatz kann gut für Agents funktionieren, 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 können Sie feststellen, dass Sie die Effizienz kaum steigern, indem Sie mehrere Agents auf demselben Computer ausführen.
Beispielsweise ist es möglicherweise nicht sinnvoll für Agents, die Builds ausführen, die viele Datenträger- und E/A-Ressourcen verbrauchen.
Es können auch Probleme auftreten, wenn parallele Buildaufträge dieselbe Singleton-Toolbereitstellung verwenden, z. B. npm-Pakete.
Beispielsweise kann ein Build eine Abhängigkeit aktualisieren, die von einem anderen Build gerade verwendet wird. Dies kann unzuverlässige Ergebnisse und Fehler verursachen.
Weitere Anweisungen zum Einrichten selbstgehosteter Agents finden Sie unter: