Podman in Podman
Un container, in un altro container, che esegue dei comandi. Docker in Docker, o Podman in Podman. Ma come funziona? 🚀
TOC
Docker in Docker, Podman in Podman
Docker in Docker (o anche Podman in Podman, e abbreviato in DinD) è un esperimento di container annidati che viene fatto nel 2013 da Jérôme Petazzoni, un Software Engineer che ha lavorato per Docker a lungo e che ha deciso di utilizzare una delle feature prodotte in quella release, ossia la modalità di esecuzione privileged, per fare questo test.
Per rendere questo esperimento più “leggero”, useremo Podman, un engine daemonless che ci permette di eseguire i nostri container senza dover avere i privilegi di root.
Useremo un dockerfile come il seguente, che utilizza l’immagine di Podman (ossia quay.io/podman/stable) prodotta da Red Hat e disponibile su quay.io, e poi andremo a richiamare al suo interno sempre Podman, per eseguire il pull dell’immagine di Alpine che produce una semplice stampa di “Hello world”.
Come utente, specifichiamo podman, per rispettare quelli che sono i criteri di sicurezza applicati dalla tecnologia stessa, e anche dalle best practices.
FROM quay.io/podman/stable
USER podman
ENTRYPOINT ["podman", "run", "--rm", "docker.io/library/alpine"]
CMD ["echo", "Hello", "world"]
E ora la parte facile: è necessario procedere con la build dell’immagine (con il primo comando) e poi eseguire il deploy del container. Ci sono però alcune opzioni che vale la pena menzionare: --rm rimuove automaticamente il container quando viene arrestato e aiuta a ripulire le risorse senza lasciare container appesi.
Poi, --security-opt label=disable: questa opzione disabilita SELinux (Security-Enhanced Linux) per il container, una funzionalità del sistema operativo che fornisce un ulteriore livello di sicurezza applicando controlli di accesso.
La disabilitazione potrebbe essere necessaria in determinati contesti, in particolare quando si eseguono container che richiedono un accesso più ampio di quello che SELinux normalmente consentirebbe.
In ultimo, --user podman: questo specifica che il container deve essere eseguito dall’utente denominato “podman” anziché come utente root predefinito.
podman build -t test .
# e
podman run --rm --security-opt label=disable --user podman test
Questa struttura di comando dimostra efficacemente come Podman può essere utilizzato per gestire container all’interno di altri container, spesso definiti scenari “Docker in Docker”, mantenendo al contempo le pratiche di sicurezza e gestione delle risorse.
Schema di architettura di Podman in Podman
Tip
Per evitare di eseguire il pull dell’immagine del container interno ogni volta che eseguiamo il container più esterno, è possibile creare un volume con il seguente comando:
podman volume create myvolume
e aggiungere l’opzione seguente al comando di run precedente:
podman run --rm --security-opt label=disable --user podman test -v mystorage:/home/podman/.local/share/containers:rw
In altre parole
Perché usare Docker in Docker
L’utilizzo di un container annidato può essere vantaggioso per diversi motivi, in particolare in casi d’uso specifici come in ambienti di CI o di build isolati: DinD consente ai sistemi CI, come Jenkins o GitLab CI, di eseguire container Docker all’interno di un ambiente containerizzato.
Questa configurazione consente al sistema CI di creare, testare e distribuire applicazioni in ambienti isolati senza influire sul sistema host o su altre build.
Anche in ambienti sandbox può essere utile: DinD fornisce un ambiente sandbox in cui chi sviluppa può sperimentare comandi e configurazioni Docker senza mettere a rischio la stabilità del sistema host.
Un altro approccio in ambito di sviluppo è quello dei dev container: container già pronti all’uso con tutti i contenuti e i metadata necessari per poter sviluppare al loro interno, particolarmente utile per testare nuove funzionalità o configurazioni in modo sicuro. In questo modo, è anche possibile pulire l’intero ambiente distruggendo il container esterno, semplificando il ripristino dell’ambiente di test.
