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.

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 images
 
 
### DOCKER RMI
# supprimer les images (et pas les containers)
# il ne doit plus y avoir de container faisant référence à cette image
 
 
### DOCKER SEARCH 
# chercher des images dans le Docker Hub

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. Comment ? à creuser
• Les docker-files sont parait-il hyper bien, mais je ne sais pas ce dont il s'agit (un système pour ne pas avoir des cli ultralongues et ainsi éviter les typo ?)
• 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