Interesse per Podman?

Sviluppatore
20

Ho dato una prova per circa mezz’ora. Podman è compatibile a livello di comandi ma non a livello di output, quindi launcher si confonde quando tenta di analizzare l’output. (Non è difficile distinguerli: docker --version risponde con podman version 1.0.5, quindi non si tratta di un ostacolo serio.)

Non esiste il dispositivo di rete docker0. Il driver di storage overlay predefinito in Podman è sostanzialmente l’implementazione overlay2 ed è alias di quest’ultimo, ma l’output non riporta overlay2 e l’output del comando docker info è leggermente diverso. Ho utilizzato --skip-prereqs per bypassare i controlli. Le directory condivise non sono state create automaticamente; non ho indagato il motivo. Ho eseguito mkdir -p /var/discourse/shared/standalone/log/var-log per procedere. Successivamente ho riscontrato problemi di permessi dovuti al fatto che SELinux era in modalità enforcing ma non configurato per /var/discourse.

Se si monta un volume di una directory in un container e si aggiunge :z o :Z, i motori dei container rinominano il contenuto sotto i volumi a container_file_t.

La documentazione di podman build afferma:

L’opzione z indica a Podman che due container condividono il contenuto del volume. Di conseguenza, Podman etichetta il contenuto con un’etichetta condivisa. Le etichette dei volumi condivisi consentono a tutti i container di leggere e scrivere il contenuto. L’opzione Z indica a Podman di etichettare il contenuto con un’etichetta privata non condivisa. Solo il container corrente può utilizzare un volume privato.

Ho deciso di impostare setenforce 0 per ora su questa installazione temporanea e riprenderlo in seguito, forse. Ho modificato i volumes per utilizzare la versione in minuscolo :z in questo modo:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared:z
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log:z

Con queste piccole modifiche, sono riuscito a far avviare Discourse. Redis non è soddisfatto perché le pagine trasparenti di grandi dimensioni (transparent huge pages) sono supportate nel kernel e suggerisce di disabilitarle, oltre a modificare le impostazioni di overcommit della memoria. Probabilmente molti altri messaggi di debug utili sono passati inosservati tra i megabyte di output del log!

./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers

Ho modificato lo script per non utilizzare --restart e ho scoperto la necessità di --skip-prereqs anche nella modalità start, il che mi ha finalmente portato a provare docker run, momento in cui:

./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address option not currently supported

Quindi non funziona sicuramente fuori scatola e non so quanto lavoro richiederebbe adattare launcher per funzionare con Docker o Podman. Gestire i prerequisiti sarebbe “semplice” e probabilmente non troppo difficile con un controllo preliminare per Podman, ma non so quanto profondamente le ipotesi sulla configurazione di rete siano incorporate nella configurazione dello stack sottostante, e sembra che questa modalità di rete non sia semplicemente supportata da Podman.

In base a questa preoccupazione, ho deciso di non svolgere il lavoro necessario per far funzionare launcher con Podman. Sto solo riportando i risultati di un esperimento iniziale rapido.

Detto questo, probabilmente non è un lavoro difficile per qualcuno che conosce meglio lo stack. Ho svolto tutto il mio lavoro di sviluppo questa primavera con un’installazione manuale di sviluppo su Fedora 29, apportando adattamenti banali come l’uso di dnf invece di apt-get e alcune traduzioni minori dei nomi dei pacchetti, senza utilizzare Docker o Podman. Mi aspetto che qualcuno che conosca bene Podman così come l’amministrazione normale dell’intero stack tecnologico di Discourse troverebbe probabilmente un lavoro moderato e relativamente semplice. Se conoscessi tutto il lavoro necessario, avrei una migliore idea di se si tratti di un tipo di lavoro che potrebbe “deteriorarsi” e richiedere manutenzione continua o meno. Ma… non lo so. :roll_eyes: