“La modifica è completata!” …ma il deploy?
Tre mesi dopo il mio ingresso in azienda, proprio mentre il periodo di prova stava per finire, mi fu assegnato per la prima volta un vero compito di lavoro. Era solo una correzione molto semplice, ma ero comunque mezzo nervoso e mezzo emozionato mentre sistemavo il codice e completavo tutti i test sulla mia macchina, su localhost.
“Capo team, tutti i test in locale sono passati!”
Il team leader annuì e mi disse di fare il deploy. “Ottimo lavoro. Ora fai commit su GitLab, un repository di codice come GitHub, e poi distribuisci sul server di produzione.”
Deploy? Mi misi a frugare in fretta nel documento di handover ricevuto durante l’onboarding. Era pieno di termini che non capivo.
Intanto caricai il codice come mi era stato detto. Ora restava solo l’ultimo passaggio: connettersi al server di produzione. Mi stavo davvero quasi alzando dalla sedia. Come nelle serie TV, pensavo che avrei dovuto entrare in una sala server gelida, un IDC, e digitare direttamente su una tastiera collegata al server.
Il mio senior mi vide e si mise a ridere. “Dove vai? Siediti e collegati semplicemente via SSH.”
Il mio primo incontro con lo schermo nero
Aprii un programma chiamato SSH(Secure Shell), inserii l’indirizzo IP e la password che mi aveva dato il senior e premetti Invio. Se fosse stato Windows, mi avrebbe accolto un desktop colorato. Invece sul mio monitor apparve solo un cursore lampeggiante su uno sfondo nero.
ubuntu@ip-172-31-0-1:~$ _
Non c’erano icone da cliccare con il mouse, né un menu con il tasto destro per creare una nuova cartella. In preda al panico premetti tasti a caso, poi digitai ls, e all’improvviso comparve un elenco di file in puro testo.
“Ah, quindi questa è quella famosa CLI(Command Line Interface) di cui avevo solo sentito parlare.”
Ma la vera paura arrivò quando provai a eseguire un file. Lanciai lo script update indicato nel manuale, e ciò che in Windows sarebbe stato un semplice doppio clic qui mi tornò indietro come un messaggio di errore rosso.
Permission denied (permesso negato)
Era il mio server, eppure non potevo eseguirlo. Perché Linux era così poco amichevole?
Il magazziniere di un centro logistico digitale
Torniamo alla nostra metafora del ‘centro logistico digitale’. Se il mio portatile Windows è un comodo ufficio privato, allora un server Linux è un enorme magazzino costruito solo per la gestione della logistica. Dentro quel magazzino ci sono decine di migliaia di scatole, cioè file.
Se il magazziniere dovesse girare a piedi per controllare ogni scatola una per una, GUI, e aprire ogni porta con una chiave, clic dopo clic, il lavoro sarebbe lentissimo. Per questo Linux usa un walkie-talkie chiamato comandi.
“Mostra l’elenco completo di tutte le scatole della zona 1!” (ls) “Sposta la scatola 3 nella zona 5!” (mv) “Esegui questa scatola!” (./start.sh)
Non è scomodo perché manca il mouse. La grafica è stata rimossa apposta perché, una volta fatta l’abitudine, puoi controllare migliaia di file cento volte più velocemente che con un mouse.
[Code Verification] La legge assoluta dei permessi
Ciò che tormenta di più chi inizia con Linux è proprio il problema dei permessi. Su Windows, un clic su ‘Esegui come amministratore’ risolve quasi tutto. Linux invece controlla in modo rigoroso, per ogni singolo file, chi può fare cosa.
Per sopravvivere, devi saper leggere quel linguaggio alieno che compare con ls -l nel terminale.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Analisi: la parte fondamentale è -rwxr-xr-- all’inizio. Escludendo il primo -, che indica file, va letto in gruppi di tre.
Uno script che hai scritto non si esegue? Nove volte su dieci manca il permesso di esecuzione, cioè x. A quel punto i principianti, frustrati, tendono a lanciare l’incantesimo proibito chmod 777.
# Cosa non fare mai
$ chmod 777 myscript.sh
777 significa: “Che io, tu e persino il cane di passaggio possiamo modificare ed eseguire questo file.” È come spalancare completamente il cancello di sicurezza. Nel lavoro reale è assolutamente vietato. Bisogna abituarsi a concedere solo i permessi minimi necessari, come chmod +x.
chmod 777 è comodo, ma rende le cose comode anche per gli attaccanti.Consiglio pratico: superare la paura del terminale
Quando entrai in azienda, il mio senior mi disse di usare PuTTY come strumento per connettermi al server. Cercando su Internet, però, trovai uno strumento migliore: MobaXterm. Appena ti colleghi via SSH, questo programma mostra sulla sinistra un elenco di file tramite SFTP, quasi come l’esplora file del mio computer.
Grazie a questo, anche senza conoscere davvero i comandi del terminale, potevo aprire i file con doppio clic, modificarli e salvarli. Ma se ti affidi solo a questo tipo di scorciatoie, non farai mai davvero amicizia con Linux. In un’emergenza di produzione, non hai tempo di aspettare che si apra uno strumento grafico.
In chiusura: chi domina l’ambiente
Lasciare la serra chiamata Windows e adattarsi alla natura selvaggia chiamata Linux è doloroso. Ma una volta superato quel dolore, ottieni un livello di controllo che con un mouse non potrai mai raggiungere.
Linux non è più un territorio sconosciuto. Ma resta ancora un problema fondamentale. E se sul mio portatile, cioè nell’ambiente di sviluppo, fosse installato Java 17, mentre sul server Linux, cioè nell’ambiente di deploy, ci fosse Java 8? Oppure se esistesse una libreria su Linux che non c’è sul mio Windows?
La scusa “Ma sul mio computer funziona” nasce dalle differenze tra sistemi operativi e versioni delle librerie. Non si potrebbe eliminare del tutto questa differenza di ambiente? Non si potrebbe congelare l’ambiente del mio portatile così com’è e portarlo direttamente sul server?
Esiste una tecnologia che ha trasformato in realtà proprio questa idea apparentemente assurda. La prossima volta parleremo di Docker, la tecnologia che ha superato la virtualizzazione e dato vita alla rivoluzione dei container.