Qu'est-ce qu'un conteneur ?
Un processus isolé qui partage le noyau de la machine hôte
Un processus isolé qui partage le noyau de la machine hôte
Le matériel : une VM embarque son propre noyau et son propre OS
Un modèle immuable, en lecture seule, à partir duquel on lance des conteneurs
Une fine couche propre au conteneur, ajoutée au-dessus de l'image en lecture seule
Un fichier texte d'instructions pour construire une image
Définit l'image de base sur laquelle on construit
Exécute une commande au moment du build et crée une nouvelle couche
La commande par défaut du conteneur, remplaçable par les arguments de docker run
L'exécutable fixe du conteneur : les arguments de docker run s'y ajoutent au lieu de le remplacer
Forme exec (tableau) : node est PID 1. Forme shell : c'est /bin/sh -c qui est PID 1
Copie des fichiers du contexte de build vers l'image
8080 : l'ordre est toujours hôte:conteneur
Non : EXPOSE est de la documentation, c'est -p qui publie le port
Le résultat d'une instruction du Dockerfile, empilé en lecture seule sur les précédentes
Pour que le cache de build survive aux modifications du code
Le contexte de build : le dossier envoyé au démon Docker
À exclure des fichiers du contexte de build (node_modules, .git, secrets…)
Un Dockerfile à plusieurs FROM, où l'image finale ne garde que les artefacts du stage de build
Rien de spécial : c'est juste le tag par défaut, pas forcément la version la plus récente
registre / dépôt : tag
Supprime automatiquement le conteneur quand il s'arrête
ps : conteneurs en cours. ps -a : tous, y compris les arrêtés
docker exec -it
docker logs
Perdus avec sa couche d'écriture, sauf s'ils sont dans un volume
Un espace de stockage persistant géré par Docker, monté dans un conteneur
Un dossier de l'hôte monté tel quel dans le conteneur
Sur un réseau défini par l'utilisateur, les conteneurs se contactent par leur nom (DNS intégré)
Le conteneur utilise directement la pile réseau de l'hôte, sans isolation ni -p
Un outil pour définir et lancer une application multi-conteneurs depuis un fichier YAML
Définit une commande périodique qui dit si le conteneur est en bonne santé
Non : seulement que le conteneur db est démarré, pas que Postgres accepte des connexions
Le build uniquement : la valeur n'existe plus dans le conteneur
Pour ne pas exécuter l'application en root dans le conteneur
Le démon dockerd : la commande docker n'est qu'un client qui lui parle via une API
Qui parle au démon Docker peut lancer un conteneur privilégié : c'est root sur l'hôte
Les standards ouverts du format d'image et du runtime de conteneur
Les namespaces
Les cgroups (control groups)
Redémarre le conteneur s'il plante ou au reboot, sauf si on l'a arrêté à la main
Le ménage : conteneurs arrêtés, réseaux inutilisés, images orphelines et cache de build pendant
Distribution minimaliste (~5 Mo) avec musl et busybox au lieu de glibc et coreutils
docker inspect
La référencer par son digest : image@sha256:…
Le build et le runtime : la variable est vue par le processus du conteneur
Il reste visible dans l'historique de l'image (docker history)
Extraire automatiquement une archive tar locale, et télécharger depuis une URL
Fixe le dossier courant pour les instructions suivantes et pour le processus du conteneur
stop envoie SIGTERM puis SIGKILL après 10 s ; kill envoie SIGKILL tout de suite
Non : il faut ajouter -v pour les supprimer