Runner di Semaphore UI spiegati: deployment più veloci, migliore isolamento, costi cloud ridotti

Che cos’e un runner? #

Un runner di Semaphore UI e un’istanza standalone di Semaphore senza interfaccia utente. Si connette al server Semaphore principale, preleva i task e li esegue. I runner possono essere ospitati su server separati in qualsiasi regione o rete, completamente indipendenti da dove si trova la tua interfaccia Semaphore.

Quale problema risolve? #

Senza runner, tutte le tue attivita di automazione vengono eseguite su un unico server. All’inizio funziona bene, ma man mano che il tuo team, o il numero di team, cresce, tendono a comparire tre problemi:

• Carico. Una coda lunga di task che competono per le risorse di un solo server rallenta tutto.
• Isolamento. Quando piu team condividono lo stesso ambiente di esecuzione, una pipeline guasta puo influire su tutti gli altri.
• Geografia. Ansible si connette ai tuoi server tramite SSH. Se la tua infrastruttura e a Sydney ma la tua istanza di Semaphore si trova a Francoforte, ogni deploy passa attraverso una connessione intercontinentale. I runner risolvono tutti e tre i problemi.

Runner globali vs runner di progetto #

Semaphore offre due tipi di runner e la differenza conta se stai valutando il piano Pro.

Funzionalita	Runner globali (OSS)	Runner di progetto (Pro)
Disponibile in	OSS (gratuito)	Pro
Distribuzione del carico	✅	✅
Isolamento di rete	❌	✅
Routing basato su tag	❌	✅
Controllo per progetto	❌	✅

I runner globali vengono assegnati in modo casuale tra tutti i progetti. Sono ottimi per distribuire il carico, ma non puoi controllare quale runner preleva quale task. I runner di progetto ti permettono di associare un tag a qualsiasi template o inventory e poi instradare task specifici verso runner specifici. E proprio questo che abilita isolamento e routing geografico.

3 casi d’uso reali dei runner #

1. Piu team, zero interferenze Il tuo team platform e il tuo team di prodotto usano entrambi Semaphore. Lavorano in modo indipendente: progetti diversi, server diversi, tolleranze al rischio diverse. Con i runner di progetto, ogni team ha il proprio runner. Se il runner di un team va giu, l’altro team non se ne accorge nemmeno.

2. Infrastruttura distribuita su piu regioni Il tuo sito web gira in un data center di New York. Un servizio backend gira in Australia. Con un solo runner centralizzato in Europa, ogni deploy passa via SSH attraverso il pianeta: lento e inutile.

   Configura un runner a New York e uno in Australia. Assegna i tag ai tuoi inventory di conseguenza. Ora ogni task si connette localmente, nella stessa rete e alla massima velocita. Deploy piu rapidi e una superficie di attacco ridotta come bonus.

3. Ridurre i costi cloud con webhook + AWS Lambda Vale la pena soffermarsi su questo punto, perche e un’ottimizzazione dei costi significativa. I runner supportano webhook per due eventi: avvio del task e fine del task. Puoi usarli per avviare e spegnere automaticamente le risorse cloud.

   Ecco il setup: il tuo runner gira su un’istanza AWS EC2. Quando e in esecuzione, costa denaro. Quando e fermo, non costa nulla.

   • All’avvio del task -> il webhook attiva una funzione Lambda -> Lambda avvia l’istanza EC2 -> il runner va online, si connette a Semaphore e preleva il task
   • Alla fine del task -> un altro webhook attiva un’altra Lambda -> Lambda arresta l’istanza EC2

   Il tuo runner funziona solo quando sta davvero lavorando. Per i team con carichi sporadici, questo da solo puo giustificare il piano Pro.

Come configurare un runner di progetto #

1. Vai nelle impostazioni del progetto e apri la scheda Runners. Qui vedrai tutti i runner esistenti.

2. Fai clic su New Runner. Dagli un nome e un tag, ad esempio new-york.

3. Dopo il salvataggio, Semaphore genera due credenziali: un token, archiviato da entrambe le parti e usato per l’identificazione, e una chiave privata, archiviata solo sul runner e usata per cifrare i dati in transito. Scarica la chiave privata: ti servira nel passaggio successivo.

4. Distribuisci il runner sul server di destinazione. Il modo piu semplice e usare Docker:

   docker run \
   -e SEMAPHORE_WEB_ROOT=https://semaphore.example.com \
   -e SEMAPHORE_RUNNER_TOKEN=/ADwjSWmWV8FZB4pwQaaEOWgqIdOR+oDOeOXe2a3JD0= \
   -e SEMAPHORE_RUNNER_PRIVATE_KEY_FILE=/config.runner.key \
   -v "/path/to/private/key:/config.runner.key" \
   -d semaphoreui/runner:v2.17.28
   

   In alternativa, puoi usare il comando di configurazione interattiva:

   semaphore runner setup
   

5. Tornato in Semaphore, apri qualsiasi Template o Inventory e assegna il tag del runner new-york. Da quel momento, quel task verra sempre eseguito sul tuo runner di New York.

Taggare gli inventory, non solo i template #

Esiste un modo piu intelligente per instradare i task se hai server raggruppati per regione o rete. Invece di taggare ogni template singolarmente, puoi assegnare un tag del runner direttamente a un inventory.

Un inventory in Semaphore e un elenco di indirizzi IP che Ansible usa per connettersi ai tuoi server. Se sai che un certo gruppo di server si trova a New York, assegna a quell’inventory il tag new-york. Da quel momento, qualsiasi template che usa quell’inventory verra eseguito automaticamente sul runner di New York, senza bisogno di configurazione per singolo template.

Questo e particolarmente utile quando introduci nuovi template. Scegli l’inventory giusto e il routing del runner funziona da solo.

Un’ultima cosa: i limiti di concorrenza #

Se vuoi limitare la concorrenza, imposta un numero massimo di task paralleli per runner. Per impostazione predefinita e illimitato (0). Se lo imposti a 5 e quel runner e gia occupato, Semaphore instradera il task verso un altro runner con lo stesso tag.

Pronto a provarlo? #

I runner di progetto sono disponibili con il piano Semaphore Pro. Se il tuo team si trova in uno degli scenari sopra - code di task in crescita, piu team, infrastruttura distribuita - vale la pena approfondire.