Accueil
Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
package.json
: "resolutions": { "ua-parser-js": "^0.7.30" }
via Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-jsAnnonces & Produits :
Articles & Vidéos :
yield()
peut être très pratique pour débugguer son code flux mais permet aussi de récupérer le résultat de plusieurs requêtes pour faire des aggrégationspivot()
pour revenir à des manipulations en ligne.Pour le retour sur les InfluxDays North America qui ont lieu cette semaine, ce sera pour un prochain billet ou édition du Time Series France Meetup
exec
.SELECT DISTINCT
entre 28x et 8000x. Cela est valable tant pour les données Timescale que les données natives Postgres. Une contribution upstream est prévue.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.
Bonnes fêtes de fin d'année à tous !
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).