Come investigare un processo principale che è morto in un container docker?

A volte è necessario indagare su un contenitore che viene arrestato o un contenitore che dopo l'avvio si spegne molto rapidamente e si arresta.

docker exec -ti <id> bash Funziona solo su container in esecuzione, una volta terminato, termina anche il prompt di bash.

Con docker startte non puoi fornire un comando diverso e se il contenitore muore improvvisamente di nuovo non avrai abbastanza tempo per entrare nel contenitore e fare le tue indagini.

Possiamo fare docker commit, quindi, docker runsulla nuova immagine con un comando diverso, ma mi chiedo se ci siano altre alternative.

Nota : docker logsrestituisce semplicemente qualunque app stampata su stdout / stderr. Potrebbe non essere sufficiente per capire quale fosse il problema.

docker containers post-mortem

— SztupY
fonte

Dopo un po 'a pensarci: processo principale Docker ???? Come obiettivo del contenitore di eseguire solo un processo, o il termine "principale" deve essere rimosso, o stai facendo qualcosa di strano (come eseguire un processo di init), o stai prendendo thread come processi ... Presumo che sia opzione 1, ma ho dovuto dirlo perché mi disturba

— Tensibai

@Tensibai a volte devi eseguire qualcosa come dumb-init, per gestire il problema pid 1 / segnalazione nei container, se il tuo comando principale non può gestirlo da solo. Potrebbero esserci anche altri casi in cui un container docker esegue più di un processo

— SztupY

Sì, è quello che io chiamo strano, principalmente perché i contenitori sono stati realizzati per isolare un processo. A volte i contenitori non sono la soluzione per un'app, disposti a mettere tutto all'interno di un contenitore è più un percorso per il mal di testa che altro.

— Tensibai,

Risposte:

I modi generali per tenere traccia del perché un processo in Linux è fallito sono buoni. Uno di questi modi è quello di eseguire un processo straceche ti dirà come ha fatto il processo di chiamate di sistema e di solito indica il motivo di un errore.

Puoi creare un Dockerfileaspetto simile al seguente:

FROM original_image

RUN apt-get -y update && apt-get install -y strace

# build with `docker build -t debug_version`

Quindi esegui la tua nuova immagine usando docker run debug_version strace original_cmd.

Per i processi che fork i bambini (e poi muoiono) si desidera eseguire stracecon l' -ffopzione. Puoi anche mappare alcuni file usando i volumi di dati Docker e usare l' -oopzione da straceper scrivere su di esso. Ma in generale stracelascerà l'output su stdout, che è leggibile usando docker log.

D correlato : il processo Linux termina in modo misterioso

— Evgeny
fonte

Questo vuol dire che devo ancora docker commitprima

— arrivare

Hai detto che muore all'inizio. Presumo che tu abbia un'immagine allora. Per quelli che sono stati arrestati, è necessario un commit.

— Evgeny

Questo è solo uno degli scenari per ottenere un container bloccato

— SztupY

Esiste anche un pacchetto per stracein Alpine Linux, pkgs.alpinelinux.org/package/edge/main/x86_64/strace . Utilizzare il gestore di pacchetti alpino per installarlo, apk install strace.

— Evgeny

Per quanto ne so, commite runsono le migliori opzioni qui per darti pieno accesso al contenitore com'era quando è morto.

Idealmente, il tuo contenitore sputerebbe alcune informazioni più utili quando fallisce, ma questo è un altro argomento del tutto.

Modifica: per espandere la mia risposta, se il contenitore sta morendo proprio all'inizio, puoi anche usare docker runper specificare un'alternativa --entrypointe CMD. Generalmente imposterò questo su un loop o qualcosa che non uscirà da solo. Una volta che sei nel contenitore, puoi eseguire manualmente i passaggi che non riescono e quindi ispezionare il risultato senza doversi preoccupare dell'uscita del contenitore.

— tayworm
fonte