Zur Ausführung von CI- (Continuous Integration) und benutzerdefinierten Aufgaben müssen Sie einen Arbeitsbereich für Ihre Automation Pipelines-Pipeline konfigurieren.
Wählen Sie im Pipeline-Arbeitsbereich „Docker“ oder „Kubernetes“ als Typ aus und geben Sie den entsprechenden Endpoint an. Die Docker- und Kubernetes-Plattformen verwalten den gesamten Lebenszyklus des von Automation Pipelines bereitgestellten Containers für die Ausführung der CI- (Continuous Integration) oder benutzerdefinierten Aufgabe.
- Der Docker-Arbeitsbereich benötigt den Docker-Host-Endpoint, die Builder-Image-URL, die Image-Registrierung, das Arbeitsverzeichnis, den Cache, die Umgebungsvariablen sowie den CPU- und Arbeitsspeichergrenzwert. Sie können auch einen Klon des Git-Repositorys erstellen.
- Der Kubernetes-Arbeitsbereich benötigt den Kubernetes-API-Endpoint, die Builder-Image-URL, die Image-Registrierung, den Namespace, den NodePort, PVC (Persistent Volume Claim, Beanspruchung eines persistenten Volumes), das Arbeitsverzeichnis, Umgebungsvariablen sowie den CPU- und Arbeitsspeichergrenzwert. Sie können auch einen Klon des Git-Repositorys erstellen.
Die Konfiguration des Pipeline-Arbeitsbereichs verfügt über viele gemeinsame sowie andere Parameter, die für den Arbeitsbereichstyp spezifisch sind. Diese werden in der folgenden Tabelle beschrieben.
| Auswahl | Beschreibung | Details und Verfügbarkeit |
|---|---|---|
| Typ | Typ des Arbeitsbereichs. | Verfügbar mit Docker oder Kubernetes. |
| Host-Endpoint | Host-Endpoint, auf dem die kontinuierliche Integration (CI) und benutzerdefinierte Aufgaben ausgeführt werden. | Verfügbar im Docker-Arbeitsbereich, wenn Sie den Docker-Host-Endpoint auswählen. Verfügbar im Kubernetes-Arbeitsbereich, wenn Sie den Kubernetes-API-Endpoint auswählen. |
| URL des Builder-Images | Name und Speicherort des Builder-Images. Ein Container wird mithilfe dieses Images auf dem Docker-Host und dem Kubernetes-Cluster erstellt. Die CI- (Continuous Integration) und benutzerdefinierten Aufgaben werden in diesem Container ausgeführt. | Beispiel: fedora:latest Das Builder-Image muss über curl oder wget verfügen. |
| Image-Registrierung | Wenn das Builder-Image in einer Registrierung verfügbar ist und die Registrierung Anmeldedaten erfordert, müssen Sie einen Image-Registrierungs-Endpoint erstellen und hier auswählen, damit das Image aus der Registrierung abgerufen werden kann. | Verfügbar in den Docker- und Kubernetes-Arbeitsbereichen. |
| Arbeitsverzeichnis | Beim Arbeitsverzeichnis handelt es sich um den Speicherort innerhalb des Containers, in dem die Schritte der CI-Aufgabe (Continuous Integration) ausgeführt werden, sowie um den Speicherort, in dem der Code geklont wird, wenn ein Git-Webhook eine Pipeline-Ausführung auslöst. | Verfügbar mit Docker oder Kubernetes. |
| Namespace | Wenn Sie keinen Namespace eingeben, erstellt Automation Pipelines einen eindeutigen Namen im angegebenen Kubernetes-Cluster. | Spezifisch für den Kubernetes-Arbeitsbereich. |
| Proxy | Für die Kommunikation mit dem Arbeitsbereichs-Pod im Kubernetes-Cluster stellt Automation Pipelines für jeden Kubernetes-Cluster eine einzelne Proxy-Instanz im Namespace Welche Option Sie auswählen, hängt von der Art des bereitgestellten Kubernetes-Clusters ab.
|
|
| NodePort | Automation Pipelines verwendet NodePort für die Kommunikation mit dem Container, der innerhalb des Kubernetes-Clusters ausgeführt wird. Wenn Sie keinen Port auswählen, verwendet Automation Pipelines einen flüchtigen von Kubernetes zugewiesenen Port. Sie müssen sicherstellen, dass die Konfiguration von Firewallregeln eingehenden Datenverkehr im Bereich (30000- 32767) des flüchtigen Ports zulässt. Bei der Eingabe eines Ports müssen Sie sicherstellen, dass er nicht bereits von einem anderen Dienst im Cluster verwendet wird und dass die Firewallregeln den Port zulassen. |
Spezifisch für den Kubernetes-Arbeitsbereich. |
| Beanspruchung eines persistenten Volumes | Ermöglicht dem Kubernetes-Arbeitsbereich, Dateien über Pipeline-Ausführungen hinweg beizubehalten. Wenn Sie einen Beanspruchungsnamen für ein persistentes Volume angeben, können die Protokolle, Artefakte und der Cache gespeichert werden. Weitere Informationen zum Erstellen einer Beanspruchung eines persistenten Volumes finden Sie in der Kubernetes-Dokumentation unter https://kubernetes.io/docs/concepts/storage/persistent-volumes/. |
Spezifisch für den Kubernetes-Arbeitsbereich. |
| Umgebungsvariablen | An dieser Stelle übergebene Schlüssel-Wert-Paare stehen allen CI- (Continuous Integration) und benutzerdefinierten Aufgaben in einer Pipeline zur Verfügung, wenn diese ausgeführt wird. | Verfügbar mit Docker oder Kubernetes. Verweise auf Variablen können hier übergeben werden. Im Arbeitsbereich bereitgestellte Umgebungsvariablen werden an alle CI- (Continuous Integration) und benutzerdefinierten Aufgaben in der Pipeline übergeben. Wenn Umgebungsvariablen nicht an dieser Stelle übergeben werden, müssen diese Variablen explizit an jede CI- (Continuous Integration) und benutzerdefinierte Aufgabe in der Pipeline übergeben werden. |
| CPU-Grenzwerte | Grenzwerte für CPU-Ressourcen für den CI-Container (Continuous Integration) oder den Container mit benutzerdefinierten Aufgaben. | Der Standardwert ist 1. |
| Arbeitsspeichergrenzwerte | Arbeitsspeichergrenzwerte für den CI-Container (Continuous Integration) oder den Container mit benutzerdefinierten Aufgaben. | Die Einheit ist MB. |
| Git-Klon | Bei Auswahl von Git-Klon und Aufruf der Pipeline mittels eines Git-Webhooks wird der Code in den Arbeitsbereich (Container) geklont. | Wenn Sie Git-Klon nicht aktivieren, müssen Sie eine andere, explizite CI-Aufgabe (Continuous Integration) in der Pipeline konfigurieren, um zuerst den Code zu klonen und dann andere Schritte durchzuführen, wie z. B. Build und Test. |
| Cache | Im Automation Pipelines-Arbeitsbereich können Sie eine Reihe von Verzeichnissen oder Dateien zwischenspeichern, um nachfolgende Pipeline-Ausführungen zu beschleunigen. Zu den Beispielen für diese Verzeichnisse gehören .m2 und npm_modules. Wenn Sie keine Zwischenspeicherung von Daten zwischen Pipeline-Ausführungen benötigen, ist keine Beanspruchung eines persistenten Volumes erforderlich. Artefakte wie Dateien oder Verzeichnisse im Container werden für die erneute Verwendung über Pipeline-Ausführungen hinweg zwischengespeichert. Beispiel: Der Ordner node_modules oder .m2 kann zwischengespeichert werden. Cache akzeptiert eine Liste von Pfaden. Beispiel: workspace:
type: K8S
endpoint: K8S-Micro
image: fedora:latest
registry: Docker Registry
path: ''
cache:
- /path/to/m2
- /path/to/node_modules
|
Spezifisch für den Typ des Arbeitsbereichs. Im Docker-Arbeitsbereich erreichen Sie den Cache mithilfe eines gemeinsam genutzten Pfads im Docker-Host zur Beibehaltung der zwischengespeicherten Daten, Artefakte und Protokolle. Um im Kubernetes-Arbeitsbereich die Verwendung des Cache zu aktivieren, müssen Sie eine Beanspruchung eines persistenten Volumes angeben. Andernfalls ist der Cache nicht verfügbar. |
Wenn Sie einen Kubernetes-API-Endpoint im Arbeitsbereich der Pipeline verwenden, erstellt Automation Pipelines die erforderlichen Kubernetes-Ressourcen, wie z. B. ConfigMap, geheimen Schlüssel und Pod, um die CI- (Continuous Integration) oder benutzerdefinierte Aufgabe auszuführen. Automation Pipelines kommuniziert mit dem Container über den NodePort.
Zur Freigabe von Daten über Pipeline-Ausführungen hinweg müssen Sie eine Beanspruchung eines persistenten Volumes bereitstellen. Automation Pipelines mountet die Beanspruchung eines persistenten Volumes dann auf den Container, um die Daten zu speichern und für nachfolgende Pipeline-Ausführungen zu verwenden.
Wenn Sie im Kubernetes-Arbeitsbereich einen lokalen Kubernetes-API-Endpoint mit zertifikatsbasierter Authentifizierung verwenden, müssen Sie sicherstellen, dass Ihr Cloud-Proxy mit der aktuellen Version ausgeführt wird. Andernfalls kann die Authentifizierung fehlschlagen.
