Accueil
Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
img
, kaniko
, etc. Pour les autres cas, il faudra peut être passer par l'API kubernetes ou trouver les alternatives qui vont bien.dockershim
pour permettre à ceux qui ont en besoin de pouvoir continuer à l'utliiser. La limite étant que si vous êtes sur du service managé et que votre provider ne le fournit pas, vous ne pourrez pas l'utiliser...docker logs
fonctionne avec tous les drivers de log et non unqiement json & journald et plein d'autres améliorations/harmonisations au niveau de la CLI. Pour ceux sous Fedora qui avaient bidouillé avec firewalld précédemment pour faire fonctionner docker et qui ont un problème lié à l'interface docker0 au démarrage du service docker, allez voir par ici.-mount
, les jpbs swarm et une synthèse de l'actualité de l'écosystème docker.network (dis)connect
, support des alias avec des noms courts, amélioration des commandes play|generate kube
et capacité de monter une image OCI dans un container.influxdb
et influxdb2
à passer pour ceux qui étaient déjà en 2.0 et ceci afin d'éviter que des gens en 1.x passent involontairement en 2.x, le "delete with predicate" a été réactivé, améliorations sur le process d'upgrade, des commandes autour des actions en mode V1, mise à jour de flux, et plein d'autres corrections/améliorations.Il ne me reste plus qu'à vous souhaiter de bonnes fêtes de fin d'année et on se retrouve l'année prochaine !
Avant de commencer cette revue de presse, un peu d'auto-promo, vu que j'ai eu le plaisir et l'honneur de participer au numéro de rentrée (épisode 59) du BigData Hebdo.
nodetool scrub <keysapce> <table>
a été suffisant.memoryview
pour accélerer les accès aux données et éviter de l'usage inutile de mémoire.J'ai cru à un bug ansible sur les surcharges de variables mais en fait non - pour des variables de même niveau (ici group_vars
), l'ordre de fusion des variables est :
Donc si on a :
all.yaml
:
monitoring:
datadog: false
cassandra.yaml
:
monitoring:
datadog: true
et infra.yaml
:
monitoring:
datadog: false
alors datadog
est à false
à la fin lorsqu’on exécute le playbook.
A l’inverse:
all.yaml
monitoring:
datadog: false
infra.yaml
:
monitoring:
datadog: false
swarm.yaml
:
monitoring:
datadog: true
alors datadog
est à true
à la fin lorsqu’on exécute le playbook.
Sources :
runc
à terme, kaniko pourrait replacer docker build
. La registry docker étant aussi en passe de standardisation, on peut s'attendre à voir un nouveau produit arriver. Si Kubernetes (+ Google + CNCF + ...) ont encore besoin de la liaison avec Docker d'un point de vue marketing, on a l'impression que cela cherche à s'éloigner des outils Docker Inc et dans une moindre mesure du projet Moby (qui lui même semble aussi avoir quelques distances avec Docker Inc). Certes, le docker engine de Docker Inc est basé sur containerd et donc Docker ne disparait pas de la plateforme mais ça semble bien en prendre le chemin.git --force
est déconseillée si ce n'est proscrite, sa variante git --force-with-lease
est plus intéressante et permet d'éviter d'écraser le travail de vos camarades alors que vous pensiez juste faire un push en force sur une branche distante suite à un rebase local.Lorsque l'on déploie une même application dans plusieurs contextes via docker-compose
, il est intéressant d'utiliser le COMPOSE_PROJECT_NAME qui permet de donner un préfixe à vos réseaux et containers docker a minima.
L'inconvénient est qu'il faut ajouter à vos commandes un -p <project_name>
:
docker-compose -p instancea build --pull
docker-compose -p instancea up -d
docker-compose -p instancea logs -f
docker-compose -p instancea stop <service>
docker-compose -p instancea down
...
Ainsi, vos conteneurs seront nommés instancea_<service name>_<occurence>
et votre réseau instancea_<network name>
.
Mais il est possible d'aller plus loin avec les fichiers d'environnement .env
.
Dans votre fichier .env
à la racine de votre dossier où se trouve votre fichier docker-compose.yml
, définissez la/les variable(s) dont vous avez besoin. Ici, nous allons nous limiter à COMPOSE_PROJET_NAME
mais ne vous privez pas.
COMPOSE_PROJECT_NAME=instancea
A partir de ce moment-là, plus besoin de précier l'argument -p <project name>
, vos commandes redeviennent :
docker-compose build --pull
docker-compose up -d
docker-compose logs -f
docker-compose stop <service>
docker-compose down
...
... et pour autant, vos réseaux et containers ont le bon préfix car le fichier .env
est lu à l'exécution de la commande docker-compose
avant de parser docker-compose.yml
.
On peut aller encore plus loin en utilisant ce COMPOSE_PROJECT_NAME
dans le taggage des images d'un container par ex ou
version: '3'
services:
nginx:
build:
context: ./nginx/
image: "registry.mycompany.com/nginx:${COMPOSE_PROJECT_NAME}"
Lors de la phase de build, l'image sera tagguée avec le nom passé au projet compose. Ensuite, vous pouvez poussez sur la registry de votre entreprise puis déployer cette version sur votre cluster Swarm par ex.
A noter justement une limitation actuelle de docker stack deploy <stack name> -c docker-compose.yml
qui ne lit pas le fichier .env
en amont et donc COMPOSE_PROJECT_NAME
reste vide lors de la lecture du fichier docker-compose.yml
.
Une solution possible est par ex dans le script (simplifié) de déploiement :
cd $BUILDDIR/compose/
source .env
# Remplace la variable COMPOSE_PROJECT_NAME par sa valeur
sed -i -e "s/\${COMPOSE_PROJECT_NAME}/${COMPOSE_PROJECT_NAME}/g" docker-compose.yml
docker stack deploy ${COMPOSE_PROJECT_NAME} -c docker-compose.yml
Et voilà !
Suite à une mission, synthèse sur la possibilité à date de gérer des conteneurs Linux et Windows avec Docker.
Les tests ont été réalisés, début mai 2017, sur les environnements suivants :
En début de mission, il était supposé qu'une application métier en C# pourrait migrer vers ASP.net Core (la version opensource de .Net et sa déclinaison ASP) et donc sur un conteneur Linux. La suite nous prouva que toutes les APIs ne sont pas (et ne seront pas forcément) dans la version opensource de .Net et qu'il nous fallait envisager des conteneurs Windows à court terme et une infrastructure hybride Windows & Linux, tant au niveau des hôtes que des conteneurs.
Avant d'aller plus loin, il faut bien avoir en tête la jeunesse du support de Windows dans le monde des conteneurs. Il faut distinguer deux niveaux de supports de l'OS Windows :
Support de Windows comme machine hôte :
Support de Windows comme OS de container :
Dans le cadre de la DockerCon d'Avril 2017, Docker et Microsoft ont annoncé le support des conteneurs Linux sous Microsoft Server 2016 via Hyper-V. Il devrait alors être possible de pouvoir lancer simultanément des conteneurs Linux ET Windows sous Windows Server 2016. Il n'y a pas de date connue pour la sortie de la version supportant cette nouveauté. Il faudra surveiller les prochaines releases trimestrielles de Docker pour savoir quand cela sera utilisable de façon "stable".
En somme, en continuant notre test plus loin, nous savons que nous entrons dans un monde immature avec un support incomplet.
La première surprise fut de voir qu'il était possible de créer un cluster Swarm avec un noeud Windows et un noeud Linux sans pré-requis particulier.
Il faut ensuite créer manuellement le réseau overlay pour son application (ce sera supporté dans docker-compose 1.13+, version 3.2 du format). Si vous utiliser docker-compose, il faudra alors spécifier ce réseau comme un réseau externe afin que l'application s'y attache à son lancement.
Afin de piloter le déploiement des conteneurs sur les bons hôtes, il convient d'ajouter des labels (ou de s'appuyer sur des labels existants comme node.platform.OS
). Ainsi, un conteneur Windows se déploira sur un hôte Windows et idem pour du Linux.
Jusque là, tout va bien mais c'est là que les limitations se font sentir :
Donc au final :
Bon à savoir également :
Une série de trois vidéos, publiées il y a quelques jours, montrent bien ce qu'il est possible de faire avec Swarm à ce jour.
Pour conclure, il est possible d'utiliser des conteneurs Windows mais que ce n'est pas encore la panacée. Cela reste néanmoins prometteur et les annonces de Microsoft vont dans le bon sens. Il va falloir attendre quelques mois pour envisager cela plus sereinement.
Update 16/8/2017 : La version 17.06 entreprise edition semble résoudre les limites évoquées précédemment.
La version 1.12 apporte son lot de nouveautés :
docker-compose
et l'idée est de pouvoir déplaoyer des applications sous la forme d'un "bundle".