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

Syndication

Atom