Automatizzare i deploy con Jenkins: la mia configurazione dietro VPN

Automatizzare i rilasci è stata una delle priorità nella mia infrastruttura. Ho scelto Jenkins per la sua flessibilità e perché posso eseguirlo su una mia macchina, all’interno di una rete VPN isolata, al sicuro da accessi esterni. In questo articolo ti spiego come l’ho installato e come ho configurato un job per fare deploy automatici da Git.

🛡️ Architettura

Tutto il sistema è isolato su una rete VPN. Jenkins gira su una macchina interna che comunica con il resto dei servizi (container o server bare-metal) attraverso un network privato. Niente è esposto all’esterno se non tramite reverse proxy autenticati (es. Nginx Proxy Manager su rete interna).

🧱 Installazione di Jenkins

L’installazione l’ho fatta su una VM Debian 12. Ecco i comandi principali:

# Aggiungo la chiave e il repo ufficiale
curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null

echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

# Installazione Java + Jenkins
sudo apt update
sudo apt install -y openjdk-17-jdk jenkins

# Abilito il servizio
sudo systemctl enable jenkins
sudo systemctl start jenkins

Una volta installato, Jenkins è accessibile sulla porta 8080:

http://<ip-server>:8080

Il primo accesso richiede l’admin password, che trovi qui:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

⚙️ Configurazione base

Durante il setup iniziale:

Ho installato i plugin suggeriti.
Ho creato un utente admin dedicato.
Ho configurato l’URL di Jenkins con l’indirizzo interno della VPN.

🔧 Impostare un job di deploy da Git

Obiettivo

Ogni push su un ramo specifico (main o release) attiva il deploy automatico su un server interno (anche questo raggiungibile solo via VPN).

1. Preparazione SSH

Ho generato una chiave SSH sul server Jenkins:

ssh-keygen -t ed25519 -C "jenkins@local"

Ho aggiunto la chiave pubblica al file ~/.ssh/authorized_keys del server di destinazione.
Ho testato che Jenkins potesse connettersi via SSH al target (senza password).

2. Creazione di un nuovo Freestyle Project

Dal pannello di Jenkins:

Clic su “New Item”
Nome: deploy-mio-progetto
Tipo: Freestyle project

➤ Sezione “Source Code Management”

Git repository: [email protected]:utente/mio-repo.git
Credenziali: aggiunta una chiave SSH privata usata da Jenkins

➤ Branch to build

*/main

➤ Build Triggers

Attivo:

Poll SCM
(con H/5 * * * * per controllare ogni 5 minuti oppure webhook Git)

3. Build step: deploy script

Nel campo “Build → Execute shell” inserisco:

#!/bin/bash
set -e

# Path di lavoro
DEPLOY_DIR="/opt/mio-servizio"

# Pull nuovo codice
if [ ! -d "$DEPLOY_DIR" ]; then
  git clone [email protected]:utente/mio-repo.git "$DEPLOY_DIR"
else
  cd "$DEPLOY_DIR"
  git pull origin main
fi

# Restart del servizio (es. Docker o systemd)
cd "$DEPLOY_DIR"
docker compose down
docker compose up -d --build

Puoi adattarlo se usi systemd o un altro tipo di deploy.

🔒 Sicurezza nella rete VPN

Jenkins e il server target si parlano solo all’interno della VPN, tramite indirizzi 10.x.x.x.
Nessuna porta è esposta direttamente su Internet.
I job di Jenkins possono essere lanciati solo da utenti autenticati.
Gli accessi via SSH sono limitati all’utente Jenkins con autorizzazioni minime.

📈 Considerazioni finali

Con questo setup posso:

Effettuare rilasci in automatico su ogni push
Controllare tutto da un’interfaccia centrale
Mantenere l’intera infrastruttura protetta e chiusa in rete privata

Un approccio semplice, robusto e adatto a progetti personali, professionali o ambienti di test controllati.

💬 Feedback?

Se vuoi approfondire come gestisco più ambienti (dev/staging/prod) o trigger via webhook, scrivimi pure o apri una discussione sul mio repo GitHub.