Pendant longtemps j'ai fuit Docker. D'abord parce que je n'y comprenais rien, ensuite parce que c'était la mode (et j'aime pas la mode).

Mais le temps passant, les besoins changent et je dois maintenant déployer des applications au boulot. Puis je n'ai ni le temps (et peut-être pas le courage), de gérer le déploiement de ces applications à partir des sources ou autre solution très consommatrices de temps et de skill.

Enfin, la containerisation n'est plus une mode, mais c'est devenu un véritable moyen de faire de l'admin sys pour avoir des compatibilités parfaites et de l'isolation des applicatifs pour plus de sécurité.

Bref, je me suis mis (un peu) à Docker

Pas de difficultés, les docs de Docker sont bien fichues. Pour Debian, il est recommandé d'installer un nouveau dépôt géré par la société docker dans source.list, ce qui permet d'avoir les versions stables à jour. CHECKED

Il faut différencier les images et les containers. L'image est comme un DVD/.iso, le container est l'image installée pour être executée.

On peut créer des containers (à partir de notre propre travail ou d'une image récupérée sur le Hub).\ On peut démarrer des containers.\ On peut arrêter des containers.

Ces containers contiennent l'application et l'environnement nécessaire (choisi par le dev) pour le faire tourner.

Les données persistantes (indépendantes de l'image et de l'instance) sont gérées dans des Volumes.

On peut automatiser le déploiement de service Docker avec Docker-compose.

Pour l'usage simple que j'en ai, on pilote docker via la cli

De base la commande Docker s'execute en root

### DOCKER RUN
# créer et démarrer un container
docker run -p 8080:80 -v ~/projet/etc:/etc/mon_projet -d --name POUPETTE <image>
 
# /!\ la commande ne rend la main QUE lorsque tous les process à l'intérieur du container sont éteints. ça peut bloquer le prompt
# options utiles :
#-d
#    (detach) run le container en background (non bloquant sur la cli, et ça c'est bien)
#-v /path/to/host:/path/inside/container
#    (volume) crée un bind entre un dossier sur le système de fichier de l'hôte et le système de fichier du container,
#    utile pour la persistance de données et/ou le backup
#-p host:container
#    fait un renvoi des ports de l'host vers le container (utile si plusieurs containers servent du web, chacun sur le port 80 par exemple)
#--name NOM
#    pour nommer le container que l'on crée
# -e ENV_VARIABLE=value
#    Passer des variables env au container lors de sa création
# <image>
#    nom de l'image pour laquelle il faut créer un container
#    si l'image n'est pas déjà présente, la télécharge (sur le Docker Hub)
 
 
### DOCKER CREATE
# crée un container sans le démarrer
 
 
### DOCKER START
# démarre un container déjà créé
docker start <ID>
 
#est-ce que ça marche avec le name ? à tester
 
 
### DOCKER STOP
# arrête un container
docker stop <ID>
 
 
### DOCKER PS
# liste les containers actifs (run)
docker ps 
 
# liste tous les containers
docker ps -a
 
 
### DOCKER RM
# supprimer des containers
# on peut récupérer les id avec 'docker ps'
docker rm <ID>  
 
 
### DOCKER IMAGES
# lister les images
# car plusieurs container peuvent être réalisés à partir d'une même image
# ou avoir plusieurs versions
# c'est un cache de DL des images en fait :)
docker image ls
 
# supprimer les images (et pas les containers)
# il ne doit plus y avoir de container faisant référence à cette image
docker image rm <IMAGE>
docker rmi <IMAGE>  # alias
 
# Supprimer toutes les images inutilisées (pas de container y faisant référence)
docker image prune
 
 
### Démarrage auto
# sur un nouveau container
docker run -d --restart unless-stopped redis
 
# sur un container existant
docker update --restart always metabase
 
# options :
#    no: don't start automatically (default)
#    on-failure[:max-retries]: redémarrer le container s'il ferme à cause d'une erreur, avec limite optionnelle de tentatives. Pas de démarrage au boot
#    always: démarre le container au démarrage du daemon docker, même si arrêté à la main
#    unless-stopped: démarre le container au démarrage du daemon, sauf si arrêté à la main

Les volumes sont des espaces de stockage existant hors des containers. Ils sont utilisés pour avoir un stockage permanent de données.\ Fonctionnalités:

• Ils peuvent être partagés entre plusieurs containers
• Ils peuvent avoir un nom (named volume) ou être “annonymes” (un nom automatique est donné)
• Ils peuvent être créés et manipulés sans container
• Il peut exister plusieurs “driver” de volume (par défaut “local”, mais il peut y avoir du rclone …)
• Si on démarre un container avec un volume, si le volume n'existe pas, il est créé
• Quand on supprime un container, le named volume associé reste. Il faut le supprimer à la main si on veut s'en débarrasser.
• Le concept est de créer un container avec un volume, puis de facilement supprimer le container, l'update, le relancer, les données restent
• Quand on monte un volume sur un dossier déjà existant (dans le container), les données sont copiées dans le volume (utile pour le backup)

Par défaut, les volumes sont ici : /var/lib/docker/volumes/

### DOCKER VOLUME
## Les dockers volume sont les couches de données 
# Lister les volumes
docker volume ls 
 
# Inspecter un volume (sa localisation sur le système de fichier de l'hôte, son nom, son mount-dest etc.)
docker volume inspect <volume_name>
 
# supprimer tous les volumes non utilisés
docker volume prune
 
# supprimer un volume en particulier
docker volume rm <volume_name>
 
# Créer un volume hors container
docker volume create <volume_name>
 
# monter un volume dans un container
docker run --mount type=volume,src=<volume-name>,dst=<mount-path>
# dst=<mount_path> : point de montage DANS le container
# autres options :
#    readonly
#    dst aliases : destination, target, dst
#    volume-nocopy : If present, data at the destination isn't copied into the volume if the volume is empty.
#                    By default, content at the target destination gets copied into a mounted volume if empty.

Une procédure simple de sauvegarde:

• On arrête le container
• sur le système hôte, on copie le volume (rsync, borg)
• On redémarre le container

Docker en propose une autre, basé sur le partage de volume entre plusieurs container, voir la doc officielle.

Docker compose est à la fois un programme docker compose et à la fois un fichier de configuration (en YAML).
L'idée est d'avoir une recette de cuisine contenue dans un fichier pour créer un service (qui peut faire appel à plusieurs containers : serveur web, bdd, … avec des montages de volumes bien définis). ça évite de faire des commandes CLI à rallonge.
Et ça épouse bien le cycle de vie d'un service sous Docker, qui consiste à séparer les données (volumes) de l'application (image), en faisant des containers qui suivent des cycles de création à partir de la dernière image de l'app dispo sur le web et de destruction du container, tout en conservant les données dans les volumes pour avoir une persistance de celles-ci.

Voici l'article détaillé sur l'utilisation des fichiers de config pour docker compose.

Ci dessous un recueil de recommandations lues ici ou là, à méditer, à approfondir au besoin :

• Ne pas utiliser Docker au sein d'un autre système de container style LXC, si besoin d'isolation particulière au sein du système hôte, il vaut mieux créer une VM
• Mieux vaut ne pas gérer les auto-start & co via systemd et consorts. Il vaudrait mieux passer directement par l'interface Docker. ça peut se faire avec l'argument –restart de la ligne de commande
• Les docker-files sont des recettes de cuisine pour construire une image
• docker run ne rend la main (prompt) que lorsqu'il n'y a plus de process actif dans le container (/!\ serveur web attendant des connexions), penser à utiliser –detach