Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
python == python2
pour le motif de ne pas se tirer une balle dans le pied et qu’il y a alternatives --set python /usr/bin/python3
pour ça.Feature-Policy
indique au navigateur les fonctionnalités nécessaires pour le bon fonctionnement du site et désactiver les autres.J’ai eu le plaisir et l’opportunité de participer à la réalisation de l’épisode 10 de Dev’Obs, le magazine du DevOps, pendant lequel nous avons parlé de formation, d’innovation et des tests dans la mouvance Infrastructure As Code.
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 :
*.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.