Flatpak, container e pacchetti:
come si installano le applicazioni su Linux Immutable
Nelle distribuzioni Linux tradizionali siamo abituati a installare un programma utilizzando il gestore pacchetti della distribuzione: apt su Debian e Ubuntu, dnf su Fedora e così via.
Con una distribuzione Atomic o Immutable, il modello cambia leggermente.
Come abbiamo visto nella nostra guida alle distribuzioni Linux Atomic e Immutable, il sistema operativo viene gestito in modo più vicino a un’immagine versionata che a una normale installazione composta da tanti pacchetti modificabili individualmente.
Questo non significa però che non possiamo installare programmi.
Al contrario, uno degli aspetti più interessanti di questo modello è proprio la possibilità di separare maggiormente sistema operativo e applicazioni.
Ed è qui che entrano in gioco Flatpak, pacchetti di sistema e container.
Non tutti i programmi si installano allo stesso modo
Prima di vedere i comandi, conviene chiarire una distinzione.
Su una distribuzione Immutable possiamo incontrare principalmente tre situazioni:
Applicazione
│
├── Flatpak
│
├── Pacchetto di sistema
│
└── ContainerNon sono semplicemente tre formati diversi dello stesso tipo di software.
Ognuno risponde a un’esigenza differente.
Flatpak è particolarmente adatto alle applicazioni desktop. Le applicazioni vengono eseguite all’interno di una sandbox e utilizzano un runtime che fornisce le dipendenze di base.
I pacchetti di sistema, invece, modificano il sistema operativo di base e sono quindi più adatti a componenti che devono far parte dell’ambiente host.
I container permettono infine di eseguire applicazioni e servizi in ambienti separati dal sistema principale, una soluzione particolarmente interessante per server, sviluppo e homelab.
La prima domanda da porsi, quindi, non dovrebbe essere “quale comando devo usare?”, ma:
che tipo di applicazione sto installando e dove deve vivere?
Flatpak: la scelta naturale per molte applicazioni desktop
Se utilizziamo una distribuzione Immutable come ambiente desktop, Flatpak è spesso il modo più semplice per installare applicazioni grafiche.
Un Flatpak contiene l’applicazione e le informazioni necessarie per eseguirla, mentre le dipendenze comuni vengono fornite dal runtime. Lo stesso runtime può essere condiviso da più applicazioni.
C’è poi un altro elemento importante: la sandbox.
Per impostazione predefinita, un’applicazione Flatpak non ha accesso indiscriminato a tutto il sistema. L’accesso a file, dispositivi, rete e altre risorse viene regolato attraverso i permessi e i portal di Flatpak.
Dal punto di vista dell’utente, però, l’installazione può essere molto semplice.
Su una distribuzione che dispone di Flathub come repository configurato, possiamo ad esempio cercare un’applicazione con:
flatpak search firefoxe installarla specificando il relativo identificativo:
flatpak install flathub org.mozilla.firefoxPer avviarla:
flatpak run org.mozilla.firefoxI nomi e gli identificativi delle applicazioni possono naturalmente cambiare, quindi è sempre meglio verificare il risultato della ricerca prima di procedere.
Per aggiornare le applicazioni Flatpak possiamo invece utilizzare:
flatpak updateQuesta separazione è particolarmente comoda su un sistema Immutable: l’applicazione può essere aggiornata senza dover intervenire direttamente sull’immagine del sistema operativo.
E se un programma non è disponibile come Flatpak?
Qui entra in gioco un altro concetto importante.
Non tutto il software può essere trattato come una normale applicazione desktop.
Pensiamo, per esempio, a:
- un driver;
- un componente di sistema;
- uno strumento che deve essere disponibile nell’ambiente host;
- un programma che deve integrarsi profondamente con il sistema operativo.
In questi casi Flatpak potrebbe non essere la soluzione appropriata.
La documentazione ufficiale di Flatpak, infatti, indica diversi casi in cui il modello sandbox non è adatto, ad esempio software che richiede privilegi elevati, accesso particolare a /proc, moduli del kernel o driver.
È proprio qui che possiamo avere bisogno dei pacchetti di sistema.
I pacchetti di sistema su una distribuzione Immutable
Su un sistema tradizionale possiamo installare direttamente un pacchetto con un apposito comando come il seguente:
sudo dnf install nome-pacchettooppure:
sudo apt install nome-pacchettoSu una distribuzione Atomic basata su rpm-ostree, invece, il concetto è leggermente diverso.
Il sistema di base viene gestito come un’immagine, ma rpm-ostree permette anche di aggiungere pacchetti attraverso il cosiddetto package layering. La documentazione Fedora descrive infatti rpm-ostree come un sistema ibrido tra gestione a immagini e pacchetti.
Per esempio:
rpm-ostree install nome-pacchettoL’operazione non va quindi interpretata come una semplice modifica al filesystem corrente.
Il pacchetto viene aggiunto alla configurazione del sistema e normalmente la modifica diventa effettiva dopo il riavvio, entrando nel nuovo deployment.
Possiamo verificare la situazione con:
rpm-ostree statusQuesto è uno dei motivi per cui sulle distribuzioni Immutable dobbiamo cambiare leggermente mentalità.
Non pensiamo più solamente:
“Installiamo questo pacchetto nel sistema.”
Pensiamo piuttosto:
“Vogliamo che questo componente faccia parte del prossimo stato del sistema?”
È una differenza piccola, ma aiuta a comprendere il modello Atomic.
Quando entrano in gioco i container?
I container rappresentano un’altra strada ancora.
Se vogliamo installare, per esempio, un servizio web, un database o un’applicazione server, spesso non abbiamo bisogno di aggiungerla direttamente al sistema operativo.
Possiamo eseguirla in un container.
Il vantaggio è che il software e gran parte del suo ambiente vengono mantenuti separati dal sistema host.
Uno schema molto semplificato può essere:
Sistema Immutable
│
├── Sistema operativo
│
├── Flatpak
│ ├── Browser
│ └── Editor
│
└── Container
├── Web server
└── DatabaseQuesta separazione si sposa particolarmente bene con il modello Immutable.
Il sistema operativo rimane relativamente stabile, mentre le applicazioni possono essere gestite con strumenti specifici.
Naturalmente un container non è semplicemente un “pacchetto più isolato”: utilizza un modello diverso e ha senso soprattutto quando l’applicazione è progettata per essere eseguita in questo modo.
Per approfondire questo aspetto possiamo collegarci alla nostra introduzione a Docker su Linux.
Come scegliere il metodo giusto?
A questo punto possiamo costruire una piccola regola pratica.
| Cosa vogliamo installare | Soluzione da valutare |
|---|---|
| Applicazione desktop | Flatpak |
| Componente necessario al sistema | Pacchetto / layering |
| Servizio o applicazione containerizzata | Container |
Non è una regola assoluta, ma rappresenta un buon punto di partenza.
Per esempio, se vogliamo installare un browser grafico, Flatpak è una scelta naturale.
Se invece abbiamo bisogno di un componente che deve integrarsi con il sistema operativo, possiamo valutare il package layering.
Se vogliamo avviare un database per il nostro homelab, un container può essere molto più adatto.
Perché questa separazione è interessante?
Il vantaggio principale non è semplicemente “avere più modi per installare programmi”.
Il vero interesse del modello Immutable sta nella separazione delle responsabilità.
Possiamo avere:
SISTEMA OPERATIVO
│
relativamente stabile
│
┌──────┴──────┐
│ │
Flatpak Container
│ │
Desktop ServiziIl sistema operativo viene aggiornato come un insieme coerente, mentre molte applicazioni possono evolvere indipendentemente.
Flatpak, per esempio, utilizza runtime che sono indipendenti dalla specifica versione della distribuzione e possono quindi fornire una base stabile alle applicazioni anche attraverso aggiornamenti del sistema operativo.
Questo riduce anche la necessità di installare direttamente nel sistema host ogni singola libreria richiesta da un’applicazione.
Non dobbiamo installare tutto come Flatpak
C’è però un equivoco che vale la pena evitare.
Immutable non significa “Flatpak per tutto”.
Flatpak è ottimo per molte applicazioni desktop, ma non è progettato per sostituire ogni tipo di software.
Allo stesso modo, non ha senso utilizzare un container per ogni piccolo programma grafico del nostro desktop.
E il package layering non dovrebbe diventare semplicemente un modo per ricreare una distribuzione tradizionale installando indiscriminatamente decine di pacchetti nel sistema base.
L’obiettivo del modello è proprio quello di mantenere il sistema il più possibile coerente e prevedibile, scegliendo di volta in volta il livello appropriato.
Una nuova mentalità per installare software
Quando passiamo da una distribuzione tradizionale a una Immutable, quindi, non dobbiamo imparare soltanto nuovi comandi.
Dobbiamo soprattutto cambiare la domanda.
Su una distribuzione tradizionale potremmo chiederci:
“Come installo questo programma?”
Su una Immutable è spesso più utile chiederci:
“Dove è più opportuno eseguire questo programma?”
Se è un’applicazione desktop, probabilmente valuteremo Flatpak.
Se è un componente che deve appartenere al sistema, potremo valutare il package layering.
Se è un servizio isolabile e containerizzabile, possiamo pensare a un container.
È proprio questa separazione a rendere interessante l’approccio Atomic.
Conclusioni
Installare applicazioni su una distribuzione Linux Immutable non significa rinunciare alla flessibilità.
Significa distribuire quella flessibilità su livelli diversi.
Flatpak si occupa molto bene delle applicazioni desktop, i pacchetti di sistema rimangono disponibili quando serve integrare qualcosa nell’host e i container permettono di gestire servizi e applicazioni in ambienti separati.
Il risultato è un sistema nel quale non tutto deve essere installato e modificato nello stesso posto.
E questa è probabilmente una delle idee più importanti da comprendere quando iniziamo a utilizzare Linux Atomic:
il sistema operativo è una cosa, le applicazioni sono un’altra.
LICENZA E CONDIZIONI D’USO
Questo How-to è rilasciato sotto licenza Creative Commons Attribution-NonCommercial 3.0 Italy.
CONTATTI DELL’AUTORE
Marco Ciammella marco@orvietolinux.it
Orvieto Linux User Group info@orvietolinux.it
