1. Compose / Docker stack
Avant la version 1.13 de Docker, le déploiement et la mise à jour des services Swarm se fait nécessairement avec les commandes docker service create et docker service update.
Parfois, nous avons besoin de déployer ou mettre à jour plusieurs services Swarm. La seule manière est de répéter dans un script Shell ces deux commandes (docker service create et docker service update) pour chaque service Swarm.
SERVICES=$(docker service ls --filter name=monservice --quiet | wc -l)
if [[ "$SERVICES" -gt 0 ]]; then
# Mise à jours du service
docker service update \
--image redis:latest \
monservice
else
docker service create \
--name monservice \
--network my-net \
redis:latest
fi
Avec plusieurs services Swarm dans la stack, maintenir ce script devient chronophage et est source d’erreurs de saisie.
Avec Docker 1.13, la fonctionnalité Stacks est arrivée pour y remédier en proposant l’utilisation de docker-compose afin de déployer ou mettre à jours des services swarm :
docker stack deploy --compose-file=docker-compose.yml my_stack
Avec le docker-compose.yml suivant :
version: "1"
services:
monservice:
image: redis:latest
networks:
- my-net
networks:
my-net:
driver: overlay
2. Commandes facilitant le nettoyage
Si vous avez déjà manipulé Docker, vous avez certainement lancé ces commandes pour effectuer le nettoyage de l’ensemble des conteneurs, images ou volumes :
- Suppression des conteneurs
docker rm $(docker ps -a -q)
- Suppression de toutes les images
docker rmi $(docker images -q)
- Suppression des volumes plus utilisés
docker volume rm `docker volume ls -q -f dangling=true`
Avec Docker 1.13, la tâche de nettoyage (c’est le cas de le dire) a été grandement facilitée grâce à ces commandes :
- Suppression de tous les conteneurs et volumes inutilisés
docker system prune
- Suppression de tous les volumes plus utilisés (dangling)
docker volume prune
- Suppression des conteneurs non utilisés
docker container prune
- Suppression des images non utilisés
docker image prune
3. Docker Cli : Compatibilité descendante du démon Docker
Ceux qui ont déjà essayé de faire une montée de version du Docker Cli, sans se soucier de la version du démon, ont sûrement eu ce fameux message d’erreur :
Error response from daemon: client is newer than server
La nouvelle version Cli sait interagir avec les anciennes versions du démon Docker.
En cas d’appel à des fonctionnalités non présentes dans le démon Docker, un message d’erreur est retourné.
4. Restructuration du Cli
Une restructuration logique des commandes Docker a été réalisée. Ceci donne uniquement une meilleur lisibilité des commandes. Bien évidemment, vous n’avez pas besoin de modifier vos anciens scripts Docker car l’ancienne façon de faire continuera de fonctionner.
Par exemple, pour les conteneurs, une restructuration a été faite de cette manière :
docker container list
docker container run container_1
docker container stop container_1
docker container start container_1
docker container rm container_1
qui remplace respectivement docker ps, docker run container1, docker stop container1, docker start container1 et docker rm container1.
Une restructuration des commandes s’applique aussi aux images, volumes et services.
5. L’intégration de l’API plugin
Cette fonctionnalité existait dans la branche expérimentale de Docker 1.12. Aujourd’hui, elle est totalement intégrée dans la nouvelle version 1.13
Les plugins enrichissent les fonctionnalités du moteur Docker. Ainsi nous pourrons:
Installer un plugin :
docker plugin install vieux/sshfs
Lister les plugins :
docker plugin ls
Utiliser les plugins :
docker volume create \
-d vieux/sshfs \
--name sshvolume \
-o sshcmd=user@1.2.3.4:/remote \
-o password=$(cat file_containing_password_for_remote_host)
Désactiver un plugin :
docker plugin disable vieux/sshfs
Supprimer un plugin :
docker plugin remove vieux/sshfs
6. Activation des fonctionnalités expérimentales
Des fonctionnalités dites expérimentales sont des fonctionnalités non prêtes à être utilisées en production mais il est possible de les tester.
Les fonctionnalités expérimentales sont aujourd’hui incluses dans la version 1.13 de Docker et inactives par défaut. Pour les activer, il vous faudra démarrer le démon Docker avec l’option --experimental
Il est possible de vérifier si cette option est activée :
docker version -f ''
Certaines de ces fonctionnalités expérimentales sont utiles à connaître et même les utiliser dès maintenant :
__Amélioration du monitoring avec la centralisation des logs : __
Avec la version 1.12 de Docker, il était fastidieux de chercher les logs des conteneurs d’un service Swarm. La nouvelle commande docker service logs remonte tous les logs des conteneurs appartenant au service pour les afficher dans la console.
__Les métriques Docker avec le format Prometheus : __
Prometheus est une solution de monitoring développée chez SoundCloud et majoritairement en Go. Dans cette version expérimentale, Docker permet d’afficher des métriques Prometheus sur les conteneurs, images et les opérations exécutés par le démon.
7. Nouvelle gestion du cache à la construction des images
Il est plus simple de comprendre cette nouvelle fonctionnalité par l’exemple.
Imaginons que nous effectuons ceci :
docker pull myapp:v0
docker build -t myapp:v1 .
Dans cet exemple simple, Docker ne peut pas savoir que l’image myapp:v0 et l’image à construire myapp:v1 sont rattachées donc la construction de la nouvelle image myapp:v1 n’utilisera pas le cache Docker suite au pull de myapp:v0 ⇒ Toutes les couches sont reconstruites dans la nouvelle version myapp:v1.
La nouvelle option --cache-from , permet d’informer cette relation entre le nouveau build et l’image rechargée du dépôt distant avec la commande :
docker build --cache-from myapp:v0 -t myapp:v1 .
8. Gestion des secrets
Il s’agit d’une des fonctionnalités les plus attendues. Le moteur Docker 1.13 introduit la gestion des secrets des conteneurs lancés uniquement en mode Swarm.
Un conteneur rattaché à un service qui a accès à un secret possède un système de fichiers monté dans : /run/secrets/ pour stocker les secrets. Il s’agit d’un système de fichier tmpfs, c’est à dire si le conteneur est arrêté pour n’importe quelle raison /run/secrets disparaîtra du système de fichiers du conteneur.
Les étapes à effectuer pour rattacher un secret à un service sont :
Il est possible de créer un secret à partir du STDIN ou à partir d’un fichier. La limite maximum d’un secret est par contre de 500 KB.
< /dev/urandom tr -dc 'a-z0-9' | head -c 32 | docker secret create mysecret
- Une fois que le secret est créé, nous pouvons lancer un inspect dessus :
docker secret inspect mysecret
Ceci affichera les informations utiles du secret mais pas son contenu (son ID, sa version, sa date de création et sa date de modification)
Le secret est consommé par les services en appliquant une association simple à sa création avec la commande :
docker service create --name myservice --secret mysecret my_app
Pour mettre à jour un service et lui rattacher un secret :
docker service update --secret-add mysecret myservice
Pour mettre à jour un service et supprimer un secret :
docker service update --secret-rm mysecret myservice
9. Autres nouveautés
La commande MAINTAINER dans les dockerfiles a été dépréciée, pour être remplacée par les labels qui sont plus flexibles et permettent de rajouter des metadatas à l’image. Il s’agit d’une paire de clé valeur :
LABEL maintainer “xxxx@wescale.fr”
La propriété --rollback du docker service update pour effectuer un retour arrière sur un service.
La commande docker inspect pour inspecter toutes sortes de ressources.
La propriété --force du docker service update pour forcer la mise à jour du service.
Conclusion
Comme attendu, Docker 1.13 a apporté plusieurs nouvelles fonctionnalités sur son nouvel orchestrateur de conteneurs Docker Swarm. Cela lui permet de rattraper un peu de retard sur ses concurrents ( Kubernetes, Mesos) mais reste malgré tout insuffisant pour gagner pleinement la confiance des entreprises frileuses à exploiter un outil encore jeune pour un environnement de production.
Ainsi, je pense que la stratégie de Docker dans les prochaines versions est de faire évoluer au maximum Docker Swarm tout en améliorant sa sécurité, à voir ...
