Escludendo tutte le basi nozionistiche su docker (entrypoint, cmd, Dockerfile, etc.),
riporto alcune fonti che tenere presente non fa mai male!
Questo e’ molto importante perche’ a discapito di quello che avviene per Docker Desktop,
in cui la Virtual Machine provvede automaticamente ad aggiustare i permessi in base all’utente che sta eseguendo la shell,
sui classici server linux questo non avviene, e quindi ci si ritrova a dover scegliere varie strategie per gestire questa problematica.
Un articolo mooolto buono da leggere e’ il seguente:
Sempre relativamente a questo punto, vedere users map (nota anche come users nampespaces):
In Docker risulta utile capire come avviene il log in stdout o stderr del main process del container, per eventualmente aggiungere dei logs che possono tornare comodi.
Il container in genere looga in /proc/1/fd/1 e /proc/1/fd/2, mente ad esempio /dev/stdout punta a /proc/self/fd/1 e quindi potrebbe non andar bene per loggare nel processo principale.
Per dettagli leggere questo bellissimo articolo che analizza in dettaglio i file descriptors e le pipe di PHP-FPM:
https://rtfm.co.ua/en/linux-php-fpm-docker-stdout-and-stderr-no-an-applications-error-logs/.
Per la gestione dei comandi del processo principale di docker con specifici utenti possono tornare utili su-exec (alpine) e gosu (linux).
Qui un esempio con su-exec per php-fpm:
https://medium.com/@callback.insanity/forwarding-nginx-logs-to-docker-3bb6283a207.
e qui un esempio concreto su come creare un link allo stdout e stderr del main process:
Build con overrides + kubernetes:
Come avere un volume comune su piu’ container nello stesso docker-compose senza bisogno di scrivere esplicitamente il path di mount in ciascun service:
I container vengono eseguiti con un processo principale con ID 1.
Questo e’ importante sopratutto per quando riguarda la procedura di shut down del container.
Un punto di notevole importanza in cui questo entra in gioco e’ nella modalita’ di entrypoint che viene utilizzata
(exec vs shell).
Per dettagli:
gracefully-stopping-docker-containers, spiega come avviene il flow dei segnali di spegnimento di docker. Ha anche un paio di esempi utili a capire.
working with signals, per capire come funzionano i segnali di sistema
Suggerisco inoltre di guardare i vari link suggeriti in queste immagini:
Non direttamente correlato, ma molto utile:
There’s two methods:
https://medium.com/better-programming/docker-tips-access-the-docker-daemon-via-ssh-97cd6b44a53, for newest docker versions
https://medium.com/@dperny/forwarding-the-docker-socket-over-ssh-e6567cfab160: ssh -nNT -L $(pwd)/docker.sock:/var/run/docker.sock user@someremote + export DOCKER_HOST=$(pwd)/docker.sock
(or docker -H $(pwd)/docker.sock <docker commands>)
See this to implement simple flow:
Per la build/gestione dell’immagine sono interessanti i seguenti strumenti:
Inoltre a titolo culturale, sapere anche come docker risolve le build con Build Kit