Eseguire job tra reti da un’interfaccia

Usa runner di progetto per reti separate, capacità e strumenti necessari. Conserva cronologia e risultati in Semaphore.

Un solo host non è adatto a ogni job

I job richiedono reti, strumenti e capacità diverse. Eseguirli tutti sul server applicativo significa condividere gli stessi limiti.

Dare a ogni job l’ambiente necessario

Scegli dove eseguire ogni job, prepara gli strumenti e aggiungi capacità indipendentemente dal server Semaphore.

Raggiungere i sistemi di destinazionePosizionare i runner vicino all’inventario
Usare gli strumenti necessari al jobPreparare l’ambiente di esecuzione
Aggiungere capacità di esecuzioneScalare i runner con la crescita dei carichi

Configurare runner e instradare i job

Scegliere come viene eseguito ogni job

Il runner determina dove viene eseguito il job. Il suo executor determina se usa l’ambiente host o parte in un container.

Locale

Esegui direttamente sull’host runner usando strumenti e dipendenze installati lì.

Docker

In Pro esegui job in container e scegli un’immagine executor per ogni Task Template.

Kubernetes

In Enterprise esegui job in pod Kubernetes con immagine e dipendenze necessarie.

Preparare l’ambiente necessario ai job

Scegliere il runner nel modello

Instrada un job preparato per tag e scegli l’immagine executor.

Modelli di task

Mantenere disponibile anche il piano di controllo

Scala esecuzione dei task e disponibilità applicativa come parti separate.

Alta disponibilità

Adattare l’esecuzione all’infrastruttura

Posizionare l’esecuzione vicino all’inventario

Esegui l’automazione nella regione o rete delle destinazioni. Un runner può raggiungere una sottorete privata, ridurre la distanza dai sistemi gestiti o fornire capacità dedicata a un team. Posizione di rete, tag ed executor risolvono parti diverse della configurazione.

Lasciare che il runner avvii la connessione

Un runner si connette al server Semaphore e lo interroga. Il server non deve avviare una connessione in ingresso verso il runner. È utile dietro NAT o in una sottorete privata, purché il runner raggiunga Semaphore e le destinazioni e fonti richieste dai suoi task.

Scegliere ambito e instradamento del lavoro

I runner globali sono disponibili tra progetti, mentre quelli di progetto appartengono a un solo progetto. I tag supportati collegano requisiti dei modelli a capacità o posizioni dei runner. Le impostazioni predefinite coprono task senza requisiti di tag. Senza un runner adatto il task può attendere anziché essere eseguito silenziosamente altrove.

Separare posizione e confine di esecuzione

L’esecuzione locale usa il contesto del processo dell’host runner e i suoi permessi. Gli executor Docker e Kubernetes supportati introducono un confine di container o pod con requisiti di configurazione ed edizione propri. Mount, rete, privilegi e immagini definiscono il confine effettivo: la sola parola runner non garantisce isolamento.

Espandere indipendentemente la capacità di esecuzione

Runner aggiuntivi possono aumentare capacità o copertura senza eseguire ogni task sull’host web. Impostazioni di parallelismo e polling influiscono sul funzionamento. Schemi avanzati monouso possono combinare registrazione, hook di assegnazione e un runner che termina dopo un job, ma richiedono automazione del deployment attorno al ciclo di vita.

Eseguire automazione in una rete disconnessa

Usa una licenza offline Enterprise per reti chiuse. Mantieni Semaphore e runner all’interno e fornisci repository, immagini executor e dipendenze senza rete pubblica.

Scegliere consapevolmente l’ambiente di esecuzione

L’esecuzione locale usa i permessi dell’host runner. Usa executor Docker o Kubernetes se i job richiedono container o pod propri, con immagini, mount e rete adeguati.

Rendere le credenziali disponibili al job

I task richiedono credenziali e configurazione del modello. Le fonti d’ambiente e file del Key Store sono risolte sul server prima dell’uso in esecuzione.

FAQ

Qual è la differenza tra runner globali e di progetto?

I runner globali sono registrati per l’intera istanza; quelli di progetto appartengono a un progetto specifico. L’esecuzione distribuita globale è disponibile in tutte le offerte; ambito di progetto e instradamento correlato sono inclusi in Pro ed Enterprise secondo i prezzi. Scegli in base a responsabilità operativa e accesso agli ambienti. Un runner dedicato rende deliberata la posizione, ma la configurazione determina ancora cosa può raggiungere il processo.

Il server Semaphore deve aprire una connessione in ingresso al runner?

Il runner avvia la comunicazione connettendosi e interrogando Semaphore. Può quindi stare dietro NAT o in rete privata senza connessioni in ingresso avviate dal server. Deve ancora raggiungere Semaphore, repository, fonti dei pacchetti, servizi esterni e destinazioni. Verifica ogni percorso: il polling in uscita non elimina gli altri requisiti di rete.

Come raggiunge un task il runner con rete e strumenti corretti?

Usa tag supportati, requisiti del modello e impostazioni predefinite per scegliere l’ambiente. Dai ai tag significati di capacità o posizione e rendi visibili disponibilità e capacità. Senza runner pronto il task può attendere. Testa con un’operazione innocua e conferma il runner nei dettagli prima della produzione.

L’esecuzione su un runner remoto isola ogni task?

Non da solo. Un executor locale usa il contesto del processo dell’host runner con i relativi accessi. Docker o Kubernetes introducono un confine diverso, ma mount, privilegi, rete e contenuti delle immagini restano importanti. Scegli separatamente posizione e modalità. Prepara le dipendenze e verifica l’host, senza considerare runner o container una garanzia completa di sicurezza.

Job diversi possono usare versioni diverse della toolchain?

Prepara l’ambiente richiesto da ogni job nel percorso scelto. Le impostazioni supportate delle immagini executor aiutano a fissare dipendenze Ansible, Terraform, Python o altre senza cambiare ogni job su un host condiviso. Verifica versione ed edizione per le opzioni pertinenti. Poi testa repository, pacchetti e connettività dentro quell’ambiente reale, non solo da una sessione amministrativa.

Aggiungere runner rende Semaphore stesso altamente disponibile?

Aggiungere runner espande o sposta l’esecuzione dei task; non crea un piano di controllo applicativo ad alta disponibilità. La HA applicativa usa più nodi Semaphore coordinati con l’architettura documentata di database condiviso, Redis e bilanciamento. Queste funzionalità si completano ma risolvono problemi diversi. Determina se il limite è capacità, raggiungibilità di rete o accesso a interfaccia e API prima di scegliere quale parte scalare.

Cosa succede senza runner online con il tag richiesto?

Il task attende finché un runner disponibile soddisfa i requisiti del modello. Verifica tag, abilitazione e ultima connessione, poi capacità. Un tag è una regola di selezione: runner senza tag o con tag diversi non prendono automaticamente il job.

Posso scegliere un’immagine Docker per un singolo Task Template?

Sì. Il modello sostituisce l’immagine predefinita con executor Docker in Pro o Kubernetes in Enterprise. I job usano così la toolchain necessaria. Prepara l’immagine con applicazioni e dipendenze; il campo non modifica l’executor locale. Vedi le impostazioni di esecuzione.