Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
Faîtes-vous plaisir et écouter le podcast Artisan Développeur - dans des formats de 10mn environ, un sujet autour de l’agilité, des tests, du TDD, de la responsabilité des développeurs, de SaFE, et de tout ce qui fait partie de notre quotidien de développeurs sont abordés. Depuis quelques épisodes, cela se fait en duo avec d’autres personnes (comme JP Lambert) ce qui rend les échanges encore plus intéressants. Vous retrouvez le podcast sur Soundcloud, Pocketcasts, etc.
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.*.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.
mysql_secure_installation
, voici enfin la réponse. Sur les nouvelles installations, l’accès au compte root de mariadb est protégé. Il faut passer par sudo mysql -u root -p ...
par ex pour pouvoir se connecter en root.TLS-SNI
. Avec le partage d’une même IP, il serait possible pour une personne malveillante de récupérer un certificat pour votre domaine à votre insu. Let’s Encrypt a finalement décidé de désactiver complètement les méthodes TLS-SNI-001
et TLS-SNI-002
et de travailler sur une nouvelle méthode TLS-SNI-003
qui corrigerait ce problème. En attendant, il faut utiliser les méthodes HTTP-01
ou DNS-01
.La commande docker history
(ou docker image history
) permet de voir le nombre de layers d’une image, la taille de ces layers et leur âge. Exemple avec l’image nginx:stable
:
docker image history nginx:stable
IMAGE CREATED CREATED BY SIZE COMMENT
dfe062ee1dc8 6 weeks ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) STOPSIGNAL [SIGTERM] 0B
<missing> 6 weeks ago /bin/sh -c #(nop) EXPOSE 80/tcp 0B
<missing> 6 weeks ago /bin/sh -c ln -sf /dev/stdout /var/log/nginx… 22B
<missing> 6 weeks ago /bin/sh -c set -x && apt-get update && apt… 53.1MB
<missing> 6 weeks ago /bin/sh -c #(nop) ENV NJS_VERSION=1.12.2.0.… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.12.2-… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) LABEL maintainer=NGINX Do… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 6 weeks ago /bin/sh -c #(nop) ADD file:f30a8b5b7cdc9ba33… 55.3MB
Pour avoir l’intégralité du contenu de la ligne “CREATED BY”, il suffit de rajouter un --no-trunc
.
Source : Docker - history
C’est assez pratique lorsque l’on cherche notamment à comprendre et optimiser la taille de ses images Docker.