Podman È un motore di container che può sostituire Docker. Questo motore è stato sviluppato dalla società Red Hat (ora di proprietà di IBM) e intende spostarlo a poco a poco. Avrà successo? Bene vedremo ...
El progetto open source ha una grande facilità d'uso, che è una grande attrazione. Tale è la facilità che c'è un articolo di Dan Walsh, un ingegnere di Red Hat, in cui mostra i passaggi di una migrazione per sostituire Docker con Podman, ed erano questi:
dnf install -y podman alias docker=podman
E sotto quella descrizione finì per dire «Qualsiasi domanda?»Con un po 'di umorismo per quanto sia semplice ...
Oltre a ciò, se sei già abituato a usare Docker non devi preoccuparti troppo i comandi, poiché Podman utilizza gli stessi per la maggior parte. Cioè, se per eseguire un contenitore devi usare run docker, per farlo con questo altro progetto devi usare podman corri. È così semplice ricordare le opzioni.
Bene, finora tutto sembra simile. Entrambi i progetti sono buoni, open source, funzionano con contenitori, sono semplici, usano la stessa sintassi, ecc. Ma allora? Cosa deve avere Podman per renderlo degno? Ebbene, una delle differenze è questa non basato sui demoni (servizi nel mondo * nix).
Come sai, Docker ha un demone associato ad esso. Questo demone è unico e centralizzato, il che significa che più contenitori usi, la sua complessità crescerà e diventerà più pesante e più pesante. Ecco perché Red Hat ha deciso di creare questo altro strumento per correggere questo svantaggio.
A Podman l'hanno fatto componenti decentralizzati per la gestione dei container e quindi evitare quell'ampliamento del daemon come avviene in Docker. Quei singoli componenti vengono utilizzati solo quando necessario, il che si tradurrà in un minor consumo di risorse.
Oltre a questo vantaggio, ha un altro grande vantaggio. Podman può gestire i contenitori allo stesso modo di Docker, ma anche puoi farlo con Pods, ovvero le unità utilizzate in Kubernetes. La differenza essenziale tra un contenitore e un Pod è che ogni Pod può a sua volta contenere più di un contenitore.
Quel container e container handler trionferà che, in linea di principio, è più efficiente nelle risorse, consente l'isolamento sia dei programmi che delle applicazioni del sistema nel modo più decentralizzato possibile e, infine, deve poter essere installato in differenti Operating I sistemi senza che influenzano la costruzione dei contenitori, l'esecuzione e la distribuzione.
PS: sebbene non meno importante, è possibile aggiungere uno strumento grafico che consente di eseguire le stesse azioni della console.