CérénIT

Automatisation

  • Ansible 2.5: Traveling space and time : au programme de cette nouvelle version : des namespaces pour les “facts”, la capacité d’interdire des modules, des nouvelles “variables magiques” (les magic vars sont des variables spécifiques à Ansible et l’exécution des playbooks). On notera aussi des améliorations sur le support Windows, des nouveaux modules cloud (AWS, GCP, Azure, VMWare) et des nouveaux plugins.

Container et Orchrestration

Dataviz

Java

  • No Free Java LTS Version? : Oracle change ses pratiques de distribution du JDK Oracle (Une version majeure tous les 6 mois, moins de report de patches, etc).

Let’s encrypt

  • ACME v2 and Wildcard Certificate Support is Live : Let’s Encrypt va donc fournir des certificats wildcard (*.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 ;-)

Postgres

Python

TICK

Astuce(s) du mois

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 :

  • Un dépôt “global”, contenant la configuration ansible, les plugins, les playbooks, les variables d’hotes ou de groupes, l’inventaire et les rôles.
  • Pour chaque rôle, je repars sur le principe d’extensibilité du code avec un rôle générique et des extensions par clients. Il y aura donc un répertoire du nom du composant et un répertoire <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.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres ansible grafana tick mysql sécurité aws chronograf influxdb python spark swarm angularjs container graphql javascript microservice rancher redis serverless stream terraform traefik api architecture arm cassandra confluent csp devops docker-compose documentation hpkp kapacitor kibana lean log microsoft npm orientdb rest rethinkdb reverse-proxy sql test windows agile azure bash big-data certificat cloud cluster cncf elastic gcp gdpr git grav hashicorp hsts https hypriot java json ksql lambda lets-encrypt licence linux mobile monitoring replication rsyslog scale service-mesh solr ssh systemd telegraf vue.js wagtail yarn accessibilité akka alerte amazon-emr anonymisation apm automatisation bastion beam beat bilan branche brigade buildkit cdc checklist cli cloud-init cockroachdb code codeurs-en-seine consul containerd continous-delivery cookie coreos cors cqrs crash cron crontab csrf css curl cérénit d3.js dashboard data-pipelining dataviz date debezium debian desktop devoxx dns docker-app dokcer draft drop-in ebs ec2 elassandra electron elk event-sourcing falcor feed filebeat firebase fish flash flask fleet fluentd flux fluxlang foundation framework frontend fullstack github glacier google grid géospatial hacker hadoop header helm html html5 http hue iaac iac immutable incident index infrastructure-as-code ingénierie inspec istio jq jwt k8s kubeadm laravel liste-de-diffusion logstatsh loi machine-learning mailing-list management mariadb message micro-service mot-de-passe multi-cloud médecine newsletter nginx nomad nosql null openshit opensource openweb over-engineering packaging password performance perspective php pip portainer prometheus publicité push queue raml react redhat reindex reinvent responsive revocation revue-de-code rkt root rpi rpo rto rwd s3 scaleway search select serverless-architecture service-worker sha1 shell shipyard société spinnaker sre sri ssl statistique superset sympa syslog-ng test-unitaire tiers timer timezone travail unikernel unit ux vie-privée virtualenv vm vnc vpc

Syndication

Atom