Exécuter des travaux dans plusieurs réseaux depuis une interface

Les runners globaux sont enregistrés pour toute l’instance, tandis que les runners de projet appartiennent à un projet particulier. L’exécution distribuée globale est disponible dans toutes les offres ; le périmètre projet et les fonctions de routage associées sont inclus dans Pro et Enterprise selon la tarification. Choisissez le périmètre selon la responsabilité opérationnelle et l’accès aux environnements. Un runner propre au projet permet un placement délibéré, mais sa configuration d’exécution détermine encore les accès du processus exécuté.

Le runner établit la communication en se connectant à Semaphore et en l’interrogeant pour obtenir du travail. Cela permet un placement derrière NAT ou dans un réseau privé sans connexion entrante initiée par le serveur. Il doit toujours joindre Semaphore ainsi que dépôts, sources de paquets, services externes et cibles utilisés par ses tâches. Vérifiez chaque chemin : l’interrogation sortante ne supprime pas les autres exigences réseau.

Utilisez tags de runners, exigences de modèle et réglages par défaut pris en charge pour associer le travail à un environnement approprié. Nommez les tags selon une capacité ou un emplacement significatif et gardez disponibilité et capacité visibles. Sans runner adapté prêt, la tâche peut attendre. Testez le parcours choisi avec une opération sans danger et confirmez le runner dans les détails avant de l’utiliser en production.

Pas à lui seul. Un exécuteur local utilise le contexte de processus de l’hôte du runner avec les accès fournis par cet environnement. Docker ou Kubernetes introduisent une autre limite, mais montages, privilèges, réseau et contenu des images restent déterminants. Choisissez séparément placement et mode d’exécution. Préparez les dépendances et vérifiez l’accès à l’hôte plutôt que de considérer runner ou conteneur comme une garantie de sécurité complète.

Préparez l’environnement requis par chaque travail sur son parcours d’exécution choisi. Les réglages d’image d’exécuteur pris en charge aident à fixer un ensemble de dépendances Ansible, Terraform, Python ou autres sans modifier tous les travaux d’un hôte partagé. Vérifiez version et édition installées pour les options concernées. Testez ensuite accès au dépôt, paquets et connexions cibles dans cet environnement réel, pas uniquement depuis une session administrateur interactive.

Ajouter des runners étend ou déplace l’exécution des tâches ; cela ne crée pas un plan de contrôle applicatif hautement disponible. La haute disponibilité applicative utilise plusieurs nœuds Semaphore coordonnés avec l’architecture documentée de base partagée, Redis et répartition de charge. Ces fonctions se complètent, mais répondent à des problèmes différents. Déterminez si votre limite concerne la capacité d’exécution, l’accès réseau ou l’accès à l’interface et à l’API avant de choisir la partie à dimensionner.

La tâche reste en attente jusqu’à ce qu’un runner disponible corresponde aux exigences de routage du modèle. Vérifiez tag, activation et dernier état de connexion du runner, puis sa capacité. Un tag est une règle de sélection : un runner sans tag ou avec un autre tag ne récupère pas automatiquement ce travail.

Oui. Un modèle peut remplacer l’image de travail par défaut si le runner utilise Docker dans Pro ou Kubernetes dans Enterprise. Chaque travail dispose ainsi de sa chaîne d’outils. Préparez l’image avec applications et dépendances ; le champ ne change pas l’exécution locale. Voir les réglages d’exécution du modèle.