*.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.
Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)