Jobs in mehreren Netzwerken über eine Oberfläche ausführen

Globale Runner werden für die gesamte Instanz registriert, während Projekt-Runner einem bestimmten Projekt gehören. Globale verteilte Ausführung ist in allen Tarifen verfügbar; Projektumfang und zugehörige Routing-Funktionen sind gemäß Preisseite in Pro und Enterprise enthalten. Wählen Sie den Umfang nach Betriebsverantwortung und Umgebungszugriff. Ein projektspezifischer Runner ermöglicht eine bewusste Platzierung; was ein ausgeführter Prozess erreichen kann, bestimmt weiterhin seine Laufzeitkonfiguration.

Der Runner baut die Verbindung auf, indem er sich mit Semaphore verbindet und nach Arbeit fragt. Das ermöglicht eine Platzierung hinter NAT oder in einem privaten Netzwerk ohne vom Server initiierte eingehende Verbindung zum Runner. Der Runner muss weiterhin den Semaphore-Endpunkt und die von seinen Tasks verwendeten Repositories, Paketquellen, externen Dienste und Ziele erreichen. Prüfen Sie diese Verbindungen einzeln; ausgehende Abfragen beseitigen nicht alle anderen Netzwerkanforderungen.

Nutzen Sie unterstützte Runner-Tags, Vorlagenanforderungen und Standard-Runner-Einstellungen, um Arbeit einer passenden Ausführungsumgebung zuzuordnen. Benennen Sie Tags nach einer aussagekräftigen Fähigkeit oder einem Standort und halten Sie Verfügbarkeit und Kapazität sichtbar. Ist kein geeigneter Runner bereit, kann ein Task warten. Testen Sie die gewählte Route mit einem ungefährlichen Vorgang und bestätigen Sie den ausführenden Runner in den Task-Details, bevor Sie denselben Weg für Produktionsänderungen nutzen.

Nicht von selbst. Ein lokaler Executor läuft im Prozesskontext des Runner-Hosts mit dem dort verfügbaren Zugriff. Eine Docker- oder Kubernetes-Ausführung führt eine andere Grenze ein; Mounts, Berechtigungen, Netzwerk und Image-Inhalte bleiben jedoch entscheidend. Wählen Sie Platzierung und Ausführungsmodus getrennt. Richten Sie die benötigten Abhängigkeiten ein und prüfen Sie den Host-Zugriff, statt Runner oder Container als vollständige Sicherheitsgarantie anzusehen.

Richten Sie die für jeden Job erforderliche Laufzeitumgebung auf seinem gewählten Ausführungsweg ein. Unterstützte Executor-Image-Einstellungen helfen, einen bestimmten Satz von Ansible-, Terraform-, Python- oder anderen Abhängigkeiten festzulegen, ohne jeden Job auf einem gemeinsamen Host zu ändern. Prüfen Sie installierte Version und Edition auf die jeweiligen Executor-Optionen. Testen Sie anschließend Repository-Zugriff, Pakete und Zielverbindungen in genau dieser Umgebung, nicht nur in einer interaktiven Administratorsitzung.

Zusätzliche Runner erweitern oder verlagern die Aufgabenausführung. Sie schaffen keine hochverfügbare Anwendungssteuerung. Anwendungs-HA verwendet mehrere koordinierte Semaphore-Knoten mit der dokumentierten Architektur aus gemeinsamer Datenbank, Redis und Lastverteilung. Beide Funktionen können sich ergänzen, lösen aber unterschiedliche Probleme. Klären Sie vor der Skalierung, ob der Engpass bei Ausführungskapazität, Netzwerkerreichbarkeit oder Zugriff auf UI und API liegt.

Der Task wartet, bis ein verfügbarer Runner den Routing-Anforderungen der Vorlage entspricht. Prüfen Sie Runner-Tag, Aktivierung und letzten Verbindungsstatus, danach die Ausführungskapazität. Ein Tag ist eine Auswahlregel. Ein Runner ohne Tag oder mit einem anderen Tag übernimmt diesen Job nicht automatisch.

Ja. Eine Vorlage kann das Standard-Job-Image überschreiben, wenn ihr Runner den Docker-Executor in Pro oder Kubernetes-Executor in Enterprise nutzt. So verwenden Jobs die benötigte Toolchain. Bereiten Sie das Image mit Anwendungen und Abhängigkeiten vor; das Feld ändert das Verhalten lokaler Executors nicht. Vorlagen-Ausführungseinstellungen ansehen.