Hosting Jenkins, controller e agent separati
Un controller Jenkins sulla propria macchina a Praga o Covilhã, con le build spinte sugli agent dove è giusto che stiano - l'unico consiglio di dimensionamento che il progetto Jenkins dà e quello che la maggior parte delle installazioni ignora.
Per chi è
Un Jenkins che vive sotto la scrivania di qualcuno
Costruisce dal 2019, nessuno ricorda quali plugin contino, e l'intero processo di rilascio dipende da un tower con un disco e senza backup.
Un controller che esegue le proprie build
Gli executor sono stati assegnati sul controller perché era più semplice, e ora un job pesante si porta dietro l'interfaccia web - cosa che la documentazione Jenkins definisce cattiva pratica con quelle esatte parole.
Un team che non può passare a una CI ospitata
Dodici anni di pipeline, un plugin che nessuno ha sostituito e un job che parla con dell'hardware. Jenkins non è il problema; la macchina sotto lo è.
Che cosa vi dà una macchina tutta vostra
- Un controller che resta reattivo, perché le build girano sugli agent e non su ciò che serve l'interfaccia web.
- JENKINS_HOME su NVMe con uno snapshot prima di ogni aggiornamento dei plugin, così tornare indietro sono due clic e non una serata.
- Agent aggiunti come host separati e collegati via SSH o con il protocollo in ingresso, dimensionati diversamente dal controller.
- Un IPv4 statico da AS204057, così un registry interno, un archivio di artefatti o una destinazione di deploy può autorizzare il controller per indirizzo.
- Qualsiasi agent vi serva accanto - Linux per le build, Windows Server con licenza nostra quando un job lo richiede.
- Strutture Tier III, un backup incluso, e una macchina che non dipende dal condizionatore dell'ufficio.
Dimensionato su quello che la pipeline fa davvero
Il progetto Jenkins si rifiuta deliberatamente di pubblicare un unico numero hardware, definisce il dimensionamento una scienza inesatta e colloca la memoria del controller da qualche parte tra 200 MB per una piccola installazione e 70 GB e oltre per una grande. Quello che dice chiaramente, invece, è dove va il lavoro: non assegnate executor sul controller, perché una build può sovraccaricarlo e farlo cadere. Dimensionate quindi il controller per l'interfaccia, i plugin e lo storico dei job, e aggiungete agent per le build. Un'avvertenza sulla forma di fatturazione: un host mensile fisso costa lo stesso in una settimana tranquilla, dove i minuti di CI ospitati non costano nulla - Jenkins di solito gira quasi tutti i giorni, ed è proprio lì che questo vince.
Come installare Jenkins su Debian o Ubuntu
La linea LTS stabile, dal repository del progetto Jenkins, nell'ordine che documentano. Java 21 o successivo è un requisito, non un suggerimento.
-
Installare Java
sudo apt update sudo apt install fontconfig openjdk-21-jre java -versionJenkins richiede Java 21 o successivo. fontconfig compare insieme nel comando documentato perché i plugin che disegnano immagini falliscono in modo confuso senza di esso.
-
Aggiungere il repository LTS di Jenkins
sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \ https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \ https://pkg.jenkins.io/debian-stable binary/ | sudo tee \ /etc/apt/sources.list.d/jenkins.list > /dev/nulldebian-stable è la linea LTS; il percorso debian semplice è quella settimanale. La chiave di firma viene ruotata, quindi prendete il nome file attuale dalla pagina Jenkins e non da una guida vecchia.
-
Installarlo e avviarlo
sudo apt update sudo apt install jenkins sudo systemctl enable jenkins sudo systemctl start jenkinsJenkins ascolta sulla porta 8080 e gira con il proprio utente jenkins, con tutto ciò che conta sotto /var/lib/jenkins. Quella cartella è ciò di cui fate snapshot e backup.
-
Sbloccare il primo accesso
sudo cat /var/lib/jenkins/secrets/initialAdminPasswordAprite il server sulla porta 8080 e incollate quel valore. Non lasciatelo raggiungibile da tutta internet mentre lo configurate - mettetelo dietro il nostro gateway VPN, oppure limitate prima la porta 8080 all'indirizzo del vostro ufficio.
-
Togliere le build dal controller
# Manage Jenkins -> Nodes -> Built-In Node -> set executors to 0 # then Manage Jenkins -> Nodes -> New Node for each agent hostQuesto è l'unico consiglio di dimensionamento che la documentazione Jenkins enuncia esplicitamente: assegnare executor sul controller permette a una build di sovraccaricarlo e farlo andare in crash. Portate il nodo integrato a zero executor e aggiungete host agent, che consiglia di tenere generici e intercambiabili invece che ritagliati per job.
-
Collegare un agent via SSH
sudo -u jenkins ssh-keygen -t ed25519 -f /var/lib/jenkins/.ssh/agent sudo -u jenkins ssh-copy-id -i /var/lib/jenkins/.ssh/agent.pub jenkins@AGENT-HOSTAggiungete la chiave privata come credenziale SSH Username with private key, poi create il nodo con il metodo di avvio SSH. Ogni connessione di agent costa al controller un paio di thread e poco più di 2 MB, quindi una manciata di agent non è ciò che dimensiona un controller - lo sono i plugin e lo storico dei job.
Verificato sulla documentazione ufficiale il 2026-08-15 — leggi la fonte
Cosa non siamo
- Non siamo il progetto Jenkins. Jenkins è un marchio della Linux Foundation e il software è loro; nulla qui è approvato da loro. Vendiamo la macchina su cui gira.
- Non manteniamo i vostri plugin. Gli aggiornamenti dei plugin sono il punto in cui le installazioni Jenkins si rompono, e chi sa quali dei vostri 60 plugin contino sta dalla vostra parte - anche se lo snapshot prima di ogni aggiornamento sta dalla nostra.
- Non migriamo i vostri job come parte del prezzo. Aiutiamo con la finestra e con la copia di JENKINS_HOME, e quotiamo il resto se volete che sia fatto invece che accompagnato.
- Qui non c'è un piano di controllo Jenkins gestito. Se volete che qualcun altro si prenda interamente gli aggiornamenti, un prodotto di CI ospitata è la risposta onesta, e questo non lo è.
- Gli agent Windows hanno bisogno di licenze Windows Server, che possiamo fornire sul server, ma qualsiasi licenza di strumento serva alla build resta vostra.
Le parti che i team scoprono in ritardo
- JENKINS_HOME è l'intera installazione - configurazione, storico dei job, credenziali, plugin. Salvatelo e un controller è ricostruibile in un'ora; saltatelo e non è ricostruibile affatto.
- Snapshot prima di ogni aggiornamento dei plugin. È la modifica che con maggiore probabilità mette a terra un Jenkins funzionante, e uno snapshot la trasforma in un ritorno indietro da due clic.
- Zero executor sul controller è la raccomandazione documentata, non una preferenza. Una build che sovraccarica il controller si porta via l'interfaccia web.
- Gli agent dovrebbero essere intercambiabili. La documentazione difende agent generici e sostituibili invece di un host configurato apposta per ogni job, perché quello configurato apposta è sempre quello fuori servizio.
- La porta 8080 non è un posto dove lasciare un Jenkins non protetto. Mettetelo dietro un gateway VPN o un elenco di indirizzi autorizzati prima del primo accesso, non dopo.
- La memoria del controller cresce con i plugin, il numero di job e lo storico delle build, non con quanto sono pesanti le build - quel carico è degli agent.
Minuti di CI ospitati contro un runner vostro
| Minuti di CI ospitati dal fornitore | Un runner su DCXV | |
|---|---|---|
| Che cosa pagate | Ogni minuto di ogni job, finché il progetto esiste | Un host mensile fisso, qualunque cosa faccia la pipeline quel mese |
| Una build che rallenta | Costa di più ogni mese in cui resta lenta | Non costa nulla in più - la macchina è già pagata |
| Cache dei layer Docker | Fredda a ogni job, se non la caricate e la riscaricate voi stessi | Calda su NVMe locale, tra i job e tra i giorni |
| Parallelizzazione | Uno scalino di piano che si aumenta | Un numero che impostate nel vostro file di configurazione |
| Dove atterra il checkout | Una flotta condivisa, spesso in una regione che non potete fissare | Una macchina a Praga o Covilhã, con contratto cipriota |
| Indirizzo in uscita | Un vasto intervallo condiviso che nulla può autorizzare | Un IPv4 statico da AS204057, vostro da autorizzare |
| Che cosa può contenere la macchina | Quello che l'immagine del runner porta per caso | Qualsiasi toolchain, licenza o set di fixture installato una volta sola |
Come si mette in moto sul vostro host
Diteci che cosa fa la pipeline
Il job più pesante che eseguite oggi, quanti ne volete in parallelo e se costruisce immagini di container. Basta questo per dimensionare un host senza tirare a indovinare.
Vi consegniamo la macchina
Praga o Covilhã, accesso root e un IPv4 statico, in meno di dieci minuti. Portate la vostra immagine se il runner è già dentro.
Seguite la procedura di questa pagina
È la sequenza del produttore, presa dalla sua documentazione attuale e non da un post di blog, e su un host pulito richiede pochi minuti.
Fate uno snapshot, poi aggiungete il secondo
Fate uno snapshot appena la prima pipeline è verde, così la macchina successiva è un ripristino e non una ricostruzione. Un pool cresce aggiungendo host, non rendendone uno enorme.
Perché sceglierci
- Strutture certificate Tier III, SLA della struttura 99,982 %
- Rete propria, AS204057, IPv4 e IPv6
- Supporto 24/7/365 con circa 10 minuti di risposta media
- Società cipriota, giurisdizione UE, conforme al GDPR dal 2007
FAQ
- Che cosa mi serve per installare Jenkins su Ubuntu o Debian?
Java 21 o successivo, poi il repository apt del progetto Jenkins. Installate fontconfig e openjdk-21-jre, aggiungete il keyring e la riga sources di debian-stable da pkg.jenkins.io, apt install jenkins, abilitate e avviate il servizio, poi sbloccatelo con il valore in /var/lib/jenkins/secrets/initialAdminPassword. Jenkins ascolta sulla porta 8080. La sequenza completa è su questa pagina
- Quanta RAM serve a un controller Jenkins?
Il progetto Jenkins si rifiuta deliberatamente di dare un numero, definisce il dimensionamento una scienza inesatta e colloca la memoria del controller tra 200 MB per una piccola installazione e 70 GB o più per una molto grande. A farla crescere sono i plugin, il numero di job e lo storico delle build, non quanto sono pesanti le build - perché le build non dovrebbero girare sul controller. 8 GB sono un inizio comodo per un team piccolo
- Le build dovrebbero girare sul controller Jenkins?
No, e la documentazione lo dice apertamente: assegnare executor su un controller è cattiva pratica perché una build può saturarne CPU o memoria e farlo andare in crash. Portate il nodo integrato a zero executor e aggiungete agent. Il progetto consiglia inoltre di tenere gli agent generici e intercambiabili invece di ritagliare un host per ogni job
- Come faccio il backup di Jenkins?
JENKINS_HOME, che in un'installazione da pacchetto è /var/lib/jenkins, è l'intera installazione: configurazione, definizioni dei job, storico delle build, credenziali e plugin. Salvatelo e un controller si ricostruisce in un'ora. Ogni piano qui include un backup, e uno snapshot prima di ogni aggiornamento dei plugin trasforma la modifica che più facilmente rompe Jenkins in un ritorno indietro da due clic
- Come collego un agent di build?
La via consueta è SSH: generate una chiave come utente jenkins, mettete la metà pubblica sull'host dell'agent, aggiungete la metà privata come credenziale SSH e create il nodo con il metodo di avvio SSH. Ogni connessione di agent costa al controller un paio di thread e poco più di 2 MB, quindi non sono gli agent a dimensionare un controller
- È sicuro lasciare Jenkins sulla porta 8080?
Non su internet aperta. Mettetelo dietro il nostro gateway VPN o limitate la porta ai vostri indirizzi prima del primo accesso, non dopo - la password iniziale dell'amministratore sta in un file su un server che, fino ad allora, risponde a tutto il mondo. Un IPv4 statico da AS204057 rende semplice anche l'autorizzazione dall'altra parte
Se hai bisogno di assistenza o hai domande aggiuntive, contatta i manager o scrivi al team di supporto a support@dcxv.com
Pronto per iniziare?
Fatturazione mensile, nessun costo di attivazione, nessun vincolo