Uno dei problemi con la programmazione del computer è che gli stessi nomi vengono costantemente utilizzati per scopi diversi. Ad esempio, il termine spazio dei nomi è usato in molti modi diversi. Spesso mi confondo quando le persone parlano di spazi dei nomi all'interno di Kubernetes. Ad esempio, alcune persone sentono il termine e pensano ai cluster virtuali, ma quando lo sento, penso agli spazi dei nomi Linux usati con pod e contenitori. Allo stesso modo, immagine può fare riferimento a un'immagine VM, a un'immagine contenitore oa un'immagine OCI archiviata in un registro contenitori.
[ Potrebbe piacerti anche: 7 divertenti contenitori Linux/funzioni di trasporto di immagini ]
Ma nel mondo dei container, non esiste un termine più abusato di container .
Di recente un utente ha creato un problema Podman, esprimendo la propria frustrazione per questa terminologia:
Terminologia poco chiara:immagine e contenitore
La mia comprensione è che quell'immagine è un modello di sola lettura, mentre il contenitore è una cosa di lettura-scrittura. Sempre. Quindi, se qualcosa è un contenitore, sia podman che buildah lo considerano un contenitore. Quando qualcosa è un'immagine, sia podman che buildah la considerano come un'immagine.
Chiamo buildah da --name abc scratch. buildah images e podman images hanno lo stesso output e non considerano la novità un'immagine.
podman containers ls non mostra nulla, quindi la novità è dal punto di vista podman non un container.
buildah container restituisce tuttavia la nuova cosa, in modo che la nuova cosa sia un container (con CONTAINER NAME=abc , IMAGE NAME=scratch , BUILDER=*=yes IMAGE ID ="").
Quindi la novità è un contenitore dal punto di vista di buildah, ma non è un contenitore dal punto di vista di Podman. Questo è completamente confuso.
Elabori la differenza tra container in termini di buildah e container in termini di podman.
Penso ai contenitori come processi in esecuzione all'interno di un ambiente o qualcosa che è pronto per essere eseguito. Al contrario, immagini sono contenitori impegnati, che sono preparati per essere condivisi con altri per creare nuovi contenitori.
I container engine con cui lavoriamo, Podman, Buildah, CRI-O e Skopeo, condividono tutti lo stesso concetto di immagini.
Le immagini sono definite in contenitori/immagini e archiviate in diversi archivi o trasporti, come registri di contenitori, archivi Docker, archivi OCI, docker-daemon e contenitori/archivi. Ho scritto di questi tipi di archiviazione o trasporti in un articolo precedente.
La maggior parte delle persone pensa alle immagini come collocate in contenitori/archiviazione o registri di contenitori. Per il resto di questa descrizione, ci concentreremo sui contenitori/stoccaggio.
A proposito, Skopeo non è davvero un motore di container poiché non ha il concetto di container. Invece, Skopeo si occupa solo di immagini di container e di spostarle tra diversi tipi di storage di container.
Contenitori/contenitori di stoccaggio
La libreria contenitore/archiviazione fornisce anche il proprio concetto di contenitore di archiviazione. Fondamentalmente, i contenitori di archiviazione sono contenuti di archiviazione intermedi di cui non è stato ancora eseguito il commit. Pensa a questo come a file su disco e alcuni JSON che descrivono il contenuto.
Podman, Buildah e CRI-O utilizzano tutti contenitori di archiviazione . Tutti e tre i motori di container hanno anche dati aggiuntivi specifici per se stessi.
Contenitori Buildah
I container Buildah includono contenuti aggiuntivi che fanno riferimento ai diversi comandi che compongono Containerfile o Dockerfile.
Ad esempio, Workingdir, variabili Env e altri dati vengono utilizzati per creare un'immagine contenitore.
Contenitori Podman
Podman ha il proprio datastore di dati relativi a un contenitore Podman. Ci sono molti più dati memorizzati nel database Podman che nel database Buildah. Potresti pensare al database Buildah come a un sottoinsieme del database Podman.
Contenitori CRI-O
CRI-O ha anche un proprio datastore per descrivere i suoi contenitori.
Tutti e tre gli strumenti si sono evoluti in modo diverso e hanno idee e requisiti diversi per i propri contenitori.
Ad esempio, i container CRI-O si sono evoluti basandosi su un singolo demone che li controlla. L'enfasi è sulle prestazioni e sulla necessità di condividere centinaia/migliaia di risposte al Kubernetes CRI al secondo. Poiché CRI-O sa di essere l'unico che si occupa del datastore, può trarre vantaggio dalla memorizzazione delle informazioni in memoria. CRI-O non ha bisogno di preoccuparsi di altri processi che entrano e cambiano i contenitori a sua insaputa.
Podman, d'altra parte, ha bisogno di gestire più utenti dei suoi container contemporaneamente. Deve fare più affidamento sul blocco del file system e garantire che centinaia di eseguibili Podman possano condividere in modo affidabile lo stesso datastore. Abbiamo parlato della possibilità di unire il datastore di Podman in CRI-O in modo che CRI-O e Podman possano lavorare meglio insieme, ma nel tempo riteniamo che il rischio/beneficio sia difficile da giustificare l'unione.
Buildah è stato sviluppato anche come strumento indipendente. I manutentori hanno respinto l'assunzione del peso e della complessità non necessari del datastore Podman per un vantaggio minimo o nullo. I contenitori Buildah hanno uno scopo:costruire un'immagine del contenitore, mentre la maggior parte dei contenitori Podman riguarda più l'esecuzione di applicazioni e servizi. I contenitori Buildah non contengono tutte le informazioni di cui avrebbe bisogno Podman.
In che modo Podman gestirebbe un container creato con buildah from scratch comando?
Avremmo comunque bisogno di trattare questi contenitori parzialmente creati in modo diverso. Pertanto, avendo Podman li vede come equivalenti o addirittura elencati per impostazione predefinita in podman ps comando creerebbe confusione negli utenti.
Compatibilità
Podman può effettivamente lavorare con questi contenitori.
Le ultime versioni di Podman ora possono elencare i contenitori di archiviazione disponibili sul sistema:
$ podman ps -a --external | grep buildah
578edf9430ee scratch buildah 13 days ago storage working-container Puoi montare e smontare questi contenitori:
# podman mount working-container
/home/dwalsh/.local/share/containers/storage/overlay/a4f596beaabdc78efc7694a67d690097e327aa12bbc59165d011e62b646e93c0/merged
# podman unmount working-container
working-container Puoi anche rimuovere questi contenitori:
$ podman rm working-container
working-container
Puoi anche creare questi contenitori usando podman build . Naturalmente, questi contenitori vengono creati solo temporaneamente durante la compilazione. Poiché questi contenitori Buildah non hanno gli stessi dati di un contenitore Podman, Podman non può avviarli e interromperli e podman ps non li mostra quando sono in esecuzione.
Podman ha anche una capacità simile di lavorare con i container CRI-O.
[ Impara le basi dell'uso di Kubernetes in questo cheat sheet gratuito. ]
Concludi
Quando si tratta del termine contenitore , il contesto è spesso critico. Comprendere la differenza tra gli usi è essenziale. Quando si tratta dei nostri strumenti contenitore, condividiamo la maggior parte del contenuto, dell'archiviazione e delle librerie sottostanti. Ma ci sono ragioni legittime per cui ogni strumento ha concetti o definizioni leggermente diversi o i loro contenitori.