virli/tutorial/docker-basis/debug.md

\newpage

Intervenir durant l'exécution

Lorsque nous lançons un conteneur, il arrive que son comportement nous échappe : une imprécision dans la documentation, un cas particulier, une erreur de configuration, ... Lorsque le conteneur est en cours d'exécution, il y a plusieurs manières de contrôler ce qu'il se passe.

docker logs

La première étape consiste bien souvent à regarder ce que le conteneur affiche sur ses sorties standard et d'erreur. Lorsqu'il est lancé en monde daemon, il convient d'utiliser la commande :

```bash docker container logs 0a1b2c3d4e ```

Cela affichera l'intégralité des journaux depuis la création du conteneur.

En ajoutant l'option --follow lorsque le conteneur est actif, cela laissera la commande active logs pour afficher en direct les nouvelles lignes inscrites sur les sorties du conteneur.

Entrer dans un conteneur en cours d'exécution

Dans certaines circonstances, les journaux ne sont pas suffisants pour déboguer correctement l'exécution d'un conteneur.

En réalisant les exercices, vous serez sans doute confronté à des comportements étranges, que vous ne pourriez comprendre qu'en ayant la main sur le conteneur, à travers un shell.

Lorsqu'un conteneur est actif, vous pouvez y lancer un nouveau processus, notamment un shell par exemple :

```bash docker container exec -it mycloud /bin/bash (inctnr)# hostname 0a1b2c3d4e5f (inctnr)# ping mysql_cntr_name ... ```

On peut aussi imaginer lancer régulièrement une commande par ce biais : pour déclencher une sauvegarde d'un conteneur serveur de base de données ou pour exécuter une tâche périodique.

::::: {.question}

Il n'est pas possible d'exec dans un conteneur éteint. Aussi, si la commande initiale du conteneur se termine, tous les exec seront instantanément tués.

:::::

docker top

Si plusieurs processus doivent s'exécuter dans un conteneur, un bon moyen de savoir s'ils sont tous actifs est d'utiliser :

```bash docker container top cntr_name ```

Cela liste tous les processus rattaché au conteneur nommé : à la fois les processus démarrés par le run, mais également les éventuels processus rattachés par exec.