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 mysql tick influxdb sécurité python aws chronograf redis swarm cassandra cloud microservice spark terraform traefik angularjs confluent container graphql hashicorp javascript rancher serverless stream test api architecture arm csp devops docker-compose documentation elastic hpkp java kapacitor kibana lambda lean log microsoft npm orientdb rest rethinkdb reverse-proxy service-mesh sql ssh windows agile azure bash big-data certificat cli cluster cncf cookie dns fluxlang gcp gdpr git grav hsts https hypriot iac istio json ksql lets-encrypt licence linux mobile monitoring nginx opensource php prometheus redhat replication rsyslog scale solr systemd telegraf timescaledb vue.js wagtail yarn accessibilité akka alerte amazon-emr anonymisation apm ara automatisation bastion beam beat bilan bounded-context branche brigade browser buildkit cdc certificats checklist cloud-init cloud-storage cockroachdb code codeurs-en-seine consul containerd continous-delivery coreos cors cqrs crash cron crontab csrf css curl cérénit d3.js dashboard data-pipelining dataviz date ddd debezium debian desktop devoxx distributed-systems dive docker-app dokcer draft drop-in ebs ec2 elassandra electron elk engineering event-sourcing facebook falcor feature-policy feed filebeat firebase firefox fish flash flask fleet fluentd flux foundation framework frontend fullstack github glacier google grid géospatial hacker hadoop hdfs header helm html html5 http http/3 hue ia iaac ibm immutable incident index infrastructure-as-code ingénierie inspec jq jquery jwt k8s kubeadm laravel liste-de-diffusion logstatsh loi machine-learning mailing-list management mariadb message micro-service molecule mot-de-passe multi-cloud médecine newsletter nomad nosql null openmetrics openshit openweb over-engineering packaging password performance perspective pip portainer publicité push queue quic raml react reaper reindex reinvent responsive revocation revue-de-code rkt rolespec 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 tls training travail ubuntu unikernel unit ux vault vie-privée virtualbox virtualenv vm vnc voxxeddays vpc

Syndication

Atom