Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
*.domaine.fr
). Si je m’étais réjoui de l’idée au début, je ne vois finalement pas ou peu l’intérêt du fait de la méthode de validation (enregistrement DNS avec le temps de propagation associé). En dehors du cas où l’on dépassait les limites d’enregistrement de Let’s Encrypt en terme de nombre de certificats, la génération dynmique et unitaire via une méthode HTTP me semble plus simple. Surtout quand on utilise Traefik ;-)J’utilise Ansible dans une logique d’IAC et pour automatiser un maximum des actions pour la gestion de l’infrastructure et des applications de mes clients. Toutefois, chaque client avait son arborescence et la réutilisation d’un composant d’un client à l’autre était fastidieuse (copier/coller).
Un premier travail a consisté à extraire les rôles commun dans un dépôt git tiers et faire des liens symboliques mais cela n’était pas très pratique. Suite à un travail chez un autre client, j’ai revu mon approche et je pars pour le moment sur la solution suivante :
<composant>.<client>
ou <client>.<composant>
(le choix n’est pas encore arrêté). Le second répertoire contenant les éléments spécifiques au client.Exemple avec un rôle MariaDB :
mariadb/
├── README.md
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
├── tasks
│ └── main.yml
├── templates
│ └── my.cnf.j2
└── vars
└── main.yml
co.mariadb/
├── README.md
├── handlers
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
│ ├── my-primary.cnf.j2
│ └── my-replica.cnf.j2
Ainsi, la partie générique et la partie spécifique à mon client sont isolées. Il faut juste envisager le séquencement entre les deux rôles pour que cela se passe bien. Pour le moment, le seul code dupliqué se retrouve au niveau des handlers.
Si je devais donner accès à mes clients à leurs playbooks respectifs, il faudrait que je revois l’organisation pour ne leur donner accès qu’à leurs données. Il faudrait alors recréeer n dépots mais avec cette méthode, il est aussi facile de reconstruire a posteriori des dépots par clients depuis un dépot global. L’intérêt étant pour moi de conserver ma flexibilité et d’améliorer la réutilisabilité de mes composants.
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à !
EXPLAIN
& SHOW CARDINALITY
), le support des endpoints prometheus en lecture/ecriture, des améliorations sur la compaction ainsi que le serveur http et le client (gestion des connexions). D’autres fonctionnalités plus expérimentales sont aussi disponibles.select(db:"foo")
.where(exp:{"_measurement"=="cpu" AND
"_field"=="usage_system" AND
"service"=="app-server"})
.range(start:-12h)
.window(every:10m)
.max()
.bashrc
sans que cela devienne une pagaille monstre : mettre tout dans un dossier et “sourcer” l’ensemble des fichiers s’y trouvant. Du coup, ça peut se versionner plus facilement/atomiquement ;-)Dockerfile
que l’on soit sur un serveur 64 bits ou un raspberry, cela va faciliter les chaines de développement et déploiement.immutable
pour l’entête Cache-Control
de sorte que le navigateur ne vérifie plus si la ressource a été modifiée ou pas (fini les 304) durant la période de cache qui a été définie pour cette ressource.npm
pour gérer le cycle de release de son application (génération du changelog, gestion des numéros de versions, création des tags git, etc).