Comment enquêter sur un processus principal mort dans un conteneur docker?

13

Parfois, vous devez enquêter sur un conteneur qui est arrêté ou un conteneur qui, après le démarrage, meurt très rapidement et s'arrête.

docker exec -ti <id> bash ne fonctionne que sur les conteneurs en cours d'exécution, une fois terminée, l'invite bash se termine également.

Avec docker startvous ne pouvez pas fournir une commande différente, et si le conteneur meurt à nouveau brutalement, vous n'aurez pas assez de temps pour entrer dans le conteneur et faire vos investigations.

Nous pouvons le faire docker commit, puis docker runsur la nouvelle image avec une commande différente, mais je me demande s'il existe d'autres alternatives.

Remarque : docker logsrenvoie simplement les applications imprimées sur stdout / stderr. Cela ne suffira peut-être pas pour déterminer le problème.

SztupY
la source
Après un certain temps de réflexion: le processus principal de Docker ???? Comme un conteneur vise à exécuter un seul processus, soit le terme `` principal '' doit être supprimé, soit vous faites quelque chose de bizarre (comme exécuter un processus init), ou vous prenez des threads comme processus ... Je suppose que c'est première option, mais je devais le dire parce que cela me dérange
Tensibai
@Tensibai vous devez parfois exécuter quelque chose comme dumb-init, pour gérer le problème de signalisation pid 1 dans les conteneurs, si votre commande principale ne peut pas le gérer elle-même. Il peut également y avoir d'autres cas où un conteneur
Docker
Oui, c'est ce que j'appelle bizarre, principalement parce que des conteneurs ont été faits pour isoler un processus. Parfois, les conteneurs ne sont pas la solution pour une application et vouloir tout mettre à l'intérieur d'un conteneur est plus un chemin vers des maux de tête qu'autre chose.
Tensibai

Réponses:

9

Les moyens généraux de suivre pourquoi un processus sous Linux a échoué sont bons. L'une de ces méthodes consiste à exécuter un processus à l'aide de stracece qui vous indiquera le processus d'appels système et indique généralement la raison de l'échec.

Vous pouvez créer un Dockerfilequi ressemble à ceci:

FROM original_image

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

# build with `docker build -t debug_version`

Exécutez ensuite votre nouvelle image à l'aide de docker run debug_version strace original_cmd.

Pour les processus qui bifurquent des enfants (puis meurent), vous souhaitez exécuter stracel' -ffoption. Vous pouvez également mapper certains fichiers à l'aide des volumes de données Docker et utiliser l' -ooption de stracepour y écrire. Mais en général strace, la sortie sera stdout, ce qui est lisible en utilisant docker log.

Connexes Q: processus Linux se termine mystérieusement

Evgeny
la source
Cela signifie que je dois toujours docker commitcommencer par mon conteneur arrêté pour avoir une image à partir de
SztupY
Vous avez dit qu'il meurt au début. Je suppose que vous avez alors une image. Pour ceux qui sont arrêtés, oui un commit est requis.
Evgeny
Ce n'est qu'un des scénarios pour obtenir un conteneur arrêté
SztupY
Il existe également un package pour straceAlpine Linux, pkgs.alpinelinux.org/package/edge/main/x86_64/strace . Utilisez le gestionnaire de paquets Alpine pour l' installer, apk install strace.
Evgeny
3

Pour autant que je sache, commitet runsont les meilleures options ici pour vous donner un accès complet au conteneur tel qu'il était quand il est mort.

Idéalement, votre conteneur cracherait des informations plus utiles en cas d'échec, mais c'est un tout autre sujet.

Modifier: pour développer ma réponse, si le conteneur est en train de mourir dès le début, vous pouvez également utiliser docker runpour spécifier une alternative --entrypointet CMD. En général, je vais définir cela sur une boucle ou quelque chose qui ne sortira pas de lui-même. Une fois dans le conteneur, vous pouvez exécuter manuellement les étapes qui échouent, puis inspecter le résultat sans avoir à vous soucier de la sortie du conteneur.

tayworm
la source