Non è Canonical (sfogo)
In questi giorni sto aggiornando i miei server Linux, siccome sono i miei e non c'è l'assillo del cliente e della programmazione sono partito all'armata Brancaleone, ed era la prima volta che effettuavo il cambio verso la Ubuntu 18.04 Long Term Release.
Come puntualmente succede ogni volta che penso "eh, va mo la è una cosa semplice" è il momento esatto in cui dovrei sapere che sto per andare a stamparmi contro un TIR che procede nella corsia opposta. Ed infatti... Poi però so che dai casini in un modo o nell'altro ne esco, ed anzi ho imparato cose nuove.
Anche questa volta è così. Ma il casino è che nel mio procedere senza aver pianificato, che poi non è nemmeno vero perché nella mia testa l'avevo fatto, non ti aspetti che ti cambino le basi. Per cui pensi a tutti i potenziali problemi e poi salta fuori che erano cose date per scontate.
Mi sto riferendo alle novità introdotte da Canonical (software house che distribuisce Ubuntu Linux), come ad esempio il netplan per la configurazione delle schede di rete. Capisco il motivo per cui hanno fatto la cosa, ora con il sistema nuovo il file di configurazione della scheda di rete è scritto in YAML che poi in soldoni è un formato "digeribile" simile ad XML e quindi gestibile ad esempio dai software di gestione del cloud o di virtualizzazione. Infatti immaginate di dover cambiare o gestire centinaia di server, con questo formato dovrebbe venire facile.
Dall'altra parte però vai a rompere gli zebedei a tutti gli altri, e non sono pochi. Ma in virtù del cloud e dell'internet of things (internet delle cose) cioè del tutto distribuito, gli altri, cioè i sistemisti, contano una fava. E siccome prima utilizzavo gli alias per i failover mo' devo imparare robe nuove di cui davvero non ne sentivo il bisogno.
Ma non è nemmeno solo questo, anche i repository ufficiali che una volta erano l'immagine dell'efficienza ora sono.. meehh.. ci sono le cose, ma vecchie di anni, ma dai, ma non è possibile avere robe versione 1.3 con i bugs quando scopri che questi sono alla 3.0... e tocca buttare dentro apt gestiti da terzi, che può anche andare bene, ma tocca sempre doversi fidare. Metti che il tizio che gestisce il tal repository gli da di matto il cervello...
Anche in questo caso un perché chiaramente c'è. Canonical già da anni aveva presentato i pacchetti di tipo snap, cioè una sorta di pacchetto che includesse un po' tutto il necessario. Lo scopo era quello di avere un qualcosa di simile al DMG di Apple sebbene lo snap era pensato per i sistemi mobile. Chiaramente l'intento è bello ma poi non tutti erano d'accordo (come sempre quando si parla di Linux) e Torvalds ad esempio ha implicitamente accettato il sistema Appimage.
Anche qui non vedo perché ora si debba fracassare gli zebedei ai sistemisti con queste cose anziché mantenere il sistema debian che poi ne ha decretato il successo.
Per come vanno le cose sul lunghissimo periodo noto che dalla 14.04 in poi la qualità è decisamente calata e ci si ritrova anche a dover fare i conti con cose che si davano per assodate. Questo perché Canonical nel frattempo si è messa a correre dietro a progetti fallimentari o dubbi. Penso che per la 20.04 ci penserò su, forse è il caso di tornare da mamma Debian.
Che nostalgia mi fai venire...
Sono ormai anni che non gestisco più server linux e lo trovavo un sacco divertente proprio perchè, come hai detto tu, si imparano un sacco di cose.
Eh purtroppo è un lavoro in cui devi stare costantemente sul pezzo, perché le cose si evolvono in continuazione.
Flatpak vs Snap vs Docker vs AppImage is the new deb vs rpm
Onestamente tutte le app server che ritengo importanti le metto dentro Docker con una cartella esterna montata che ha tutti i dati.. per il server mi piace Ubuntu LTS, ma alla fine con una configurazione del genere una distro vale l'altra.
Smanettare con i file in /etc è divertente e si impara, ma una volta fatto voglio che una certa app server continui a funzionare, indipendentemente dall'host, aggiornamenti o quant'altro
Docker per me è un mezzo odio, nel senso che a livello architetturale è di fatto una virtualizzazione. Come mi dici che lo utilizzi tu lo capisco. Ma ho visto gente che su una vps, che è già una macchina virtuale di per se, mettere docker su risorse limitate e poi lamentarsi perché va tutto a rilento. E buonanotte.. Oppure come il tizio che si vantava in modo smaccato con me "non mi servono i sistemisti, io c'ho Docker e altra roba" per gestire un singolo wordpress, per l'appunto anche lui su una vps. Un mese dopo mi chiama supplicandolo di aiutarlo, non aveva messo una patch che fosse una sul sottostante linux e gli avevano sbombato l'impossibile e la cosa deve essere andata avanti per un pezzo, perchè gli avevano pure ficcato un clone di paypal. Come effetto collaterale una denuncia dalla postale... che sveglioni.. ma a lui il sistemista, bwoah, non gli serviva.
Docker per me è principalmente una sandbox per scripts non un tool per utente finale. Una volta configurata una app e modificati file in /etc o non voglio più metterci mano (a meno di non volere un comportamento diverso).
Inoltre se viene bucato un servizio il danno rimane limitato dentro il container (a meno di altri exploit livello kernel)
Ma infatti anche io la vedo così come utilizzo. Poi capisco che il sistema di per se è interessante, uno si smazza tutto il lavoro per intero ed è come se ti desse il computer su cui ha lavorato, senza possibilità di incespicare su fattori esterni. Ma comunque poi devi sapere cosa stai facendo. Nel caso che ti portavo io il tizio aveva esposto il sistema dove girava docker e il container medesimo. Quindi prima gli hanno bucato l'os, poi rimaneggiato il container per poter fare allegramente phishing.