Web, Ops & Data - Avril 2018


25/04/2018 docker rpi cockroachdb javascript java tick grafana systemd drop-in

Container et Orchrestration

  • Au revoir : Solomon Hykes, un des fondateurs de Docker tire sa révérance dans une note qui se veut positive. Un autre article nuance un peu cette réalité. Crise de croissance ? Rachat en perspective ? Let’s see…
  • Releasing HypriotOS 1.8.0: Raspberry Pi 3 B+, Stretch and more : l’équipe Hypriot a mis à jour sa distribution Hypriot OS en version 1.8. Elle est basée sur Raspbian Stretch (et non plus Jessie), supporte le dernier modèle de Raspberry Pi et fourni les dernières versions de docker, docker-compose et docker-machine. Une version 1.8.1 est déjà en cours de préparation, suivez de près la page de release du projet
  • Docker Registry API to be standardized in OCI : après la standardisation des images et du runtime des conteneurs, c’est au tour de la distribution de faire son effort de standardisation. La registry docker, standard de fait, devrait donc devenir une norme.
  • A House of Cards: An Exploration of Security When Building Docker Containers : une revue des éventuelles failles de sécurité qui pourraient être exploitées lors de la construction d’un conteneur. Mais bon, vous relisez vos Dockerfile bien sûr !

NoSQL

  • Cockroach 2.0 (What’s New in v2.0.0 - CockroachDB 2.0 Has Arrived!) : la base de données Cockroach, implémentation open source de la base de données Spanner de Google, passe (déjà) en version 2.0. Au programme des améliorations mises en avant : support du format JSON (reprise du format de Postgres), amélioration des débits et de la scalabilité, amélioration de l’outillage pour la gestion d’un cluster géo-distribué.

De retour du Breizh Camp

Quelques liens récupérés des différentes conférences auxquelles j’ai pu assister.

  • Gazr : Outil créé par Dailymotion, cela leur permet d’uniformiser les tâches quelque soit la technologie sous-jacente (ou l’environnement d’exécution)
  • Nom de Zeus, j’ai typé mon code vanillia js : TS-check, disponible depuis TypeSCcipt 2.3, permet de commencer à typer (progressivement) du js vanilla même si on n’est pas encore prêt à passer à TypeScript ou autre) ; démo.
  • JVM & Orchestration Docker (slides - démo) : Java, dans un container, ne voit les ressources qui lui sont allouées via cgroups et s’appuie sur les ressources disponibles au niveau de la machine hôte. Java 8 Update 131+ et Java 9 ont des flags expérimentaux et Java 10 devient un bon citoyen de l’écosystème Docker. Lire aussi sur le sujet : Java inside docker: What you must know to not FAIL.
  • Tests d’intégration avec Docker et Elasticsearch : D. Pilato montre ainsi qu’il est possible de lancer des tests d’intégration d’Elasticsearch depuis Maven ou via JUnit et qu’en fonction, cela peut lancer un container docker, s’appuyer sur une instance elasticsearch local ou distante. Pour cela, il s’appuie sur les outils de Fabric8 et/ou l’initiative testcontainers. Tout est documenté dans le dépot et il faut suivre les branches pour les différentes itérations.

Et pour finir, mes propres slides sur la plateforme TICK & Grafana pour collecter et exploiter vos données temporelles. J’ai également eu l’opportunité de refaire cette conférence chez Les Furets (où je suis en mission actuellement). Je vais aussi la faire le 3 Mai prochain au NantesJUG.

Bonus : la vidéo est disponible

Astuce(s) du mois

Docker, lorsqu’il exécute un container, injecte normalement les serveurs DNS de la machine hôte. Sauf que quand il voit que c’est une IP locale (127.0.0.*), alors il met les DNS de Google (8.8.8.8 et 8.8.4.4) comme DNS. Typiqyement, Ubuntu utilise un résolveur DNS local via systemd-resolved pour la résolution DNS. Du coup, la configuration de /etc/resolv.conf pointe sur 127.0.0.*. Or sur un réseau local, les accès à un DNS public peuvent être filtrés. Dès lors, votre conteneur est incapable de faire une quelconque résolution DNS (interne ou externe à votre réseau).

La solution consiste à mettre en place un “drop-in” systemd

Source :

Nous voulons surcharger le fichier de type unit docker.service et surcharger plus précisément la valeur de ExectStart.

Etape 1 : Créer un répertoire /etc/systemd/system/docker.service.d

sudo mkdir -p /etc/systemd/system/docker.service.d

Etape 2 : Créer un fichier de configuration contenant la surcharge :

sudo $EDITOR /etc/systemd/system/docker.service.d/10-dns.conf

Contenu du fichier :

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --dns 192.168.2.1 --dns 192.168.2.2

Le “doublon” sur ExecStart est normal, cela permet de réinitialiser la commande pour en définir un autre ensuite.

Il ne reste plus qu’à rechercher la configuration de systemd et relancer le service docker :

sudo systemctl daemon-reload
sudo systemctl restart docker

Docker utilisera donc ces DNS lors du lancement d’un conteneur et cela évitera qu’il fasse un fallback sur les DNS de Google quand il voit un resolver local…

Par contre, si vous utilisez docker dans un autre contexte que celui du réseau de votre entreprise, cela peut ne plus fonctionner (ou alors il faut enrichir la configuration DNS pour rajouter d’autres DNS)

Une autre solution peut être de renseigner les DNS dans /etc/docker/daemon.json (documentation) avec les mêmes inconvénients.

Au-delà de cet exemple appliqué à Docker, l’utilisation des “drop-ins” systemd est une solution intéressante pour surcharger une configuration sans impacter les fichiers sources et évite tout conflit lors d’une mise à jour du fichier.

Systemd timer pour les Cro(o)ners


29/01/2018 cron crontab systemd timer unit

Cron et Crontab sont dans un bateau…

Il fut un temps où pour programmer le lancement des actions, notre meilleur ami était “cron” et la “crontab”. Outre la syntaxe et l’organisation de la crontab peu mémorisable, les tâches cron restaient complexes à déployer et à monitorer dans leur exécution. Si le fait d’avoir des répertoires plus génériques comme /etc/cron.{d,hourly,daily,weekly,monthly} ont un peu amélioré la partie exploitabilité/déployabilité, ils offraient assez peu de souplesses pour une plannification fine des tâches. De nombreux serveurs ont donc eu un mix de crontab classique et de ce format pendant des années.

Debian 9.0 (mais d’autres aussi comme Archlinux par ex) a fait le choix dans le cadre de son adoption de systemd de ne plus proposer un logiciel de type cron mais de s’appuyer sur l’implémentation interne à systemd, à savoir les “timers”. C’est une unité (unit) spéciale de systemd qui est controllée et supervisée par systemd et qui s’exécute selon une configuration temporelle donnée.

Voyons comment passer de cette crontab :

0 4 * * * /path/to/scripts/backup.sh >> /var/log/backup.log 2>&1

… ou de /etc/cron.daily/mybackup.sh appelant le même script à son équivalent sous un timer systemd.

Implémentation d’un timer systemd.

Si vous gérez déjà vos services via systemd, vous avez déjà utilisé des “unit” systemd de type “service”. Ces “unit” permettent de définir un process et son mode d’éxécution.

Pour implémenter un “timer” sous systemd, il va nous falloir un fichier “service”.

Pour notre tâche à planifier, nous allons avoir au final 3 fichiers :

  • Le script à exécuter ; c’est votre script /path/to/scripts/backup.sh ; il est inchangé par rapport à précédemment.
  • Le fichier “service” qui va dire quel script exécuter
  • Le fichier “timer” qui va indiquer quand il doit être exécuté.

A noter que par convention, les fichiers service et timer doivent avoir le même nom (foo.service, foo.timer).

Pour le fichier service, une base simple est la suivante :

/etc/systemd/system/mybackup.service :

[Unit]
Description=My Daily Backup

[Service]
Type=simple
ExecStart=/path/to/scripts/backup.sh
StandardError=journal

Je fournis une description à mon service, indique que c’est un process de type simple, le chemin vers mon script et je rajoute que le flux d’erreur est envoyé dans le journal. Pour plus d’information, se reporter à la doc des services et des exécutions.

Attention néanmoins, il ne faut pas de section [Install] car le script va être piloté par le fichier timer.

Ensuite, il nous faut un fichier “timer” :

/etc/systemd/system/mybackup.timer :

[Unit]
Description=My Daily Backup

[Timer]
# Define a calendar event (see `man systemd.time`)
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Au-delà de la description, les lignes importantes sont la section [Timer] et [Install] :

  • OnCalendar permet d’indiquer l’occurrence et la fréquence d’exécution du script. Il y a les abréviations classiques (daily, weekly, etc) mais vous pouvez avoir des choses plus complexes comme "Mon,Tue *-*-01..04 12:00:00" - voir systemd.time
  • Persistent va forcer l’exécution du script si la dernière exécution a été manquée suite à un reboot de serveur ou autre événement.
  • Enfin, la section Install va créer la dépendance pour que votre “timer” soit bien exécuté et pris en compte par systemd.

Il ne reste plus qu’à activer le timer et le démarrer :

systemctl enable mybackup.timer
systemctl start mybackup.timer

Gestion et suivi d’un timer

Pour voir la liste des “timers” actifs sur votre serveur, la date de leur dernière et prochaine exécution :

systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Mon 2018-01-29 17:25:59 CET  2h 27min left Sun 2018-01-28 22:20:35 CET  16h ago      apt-daily.timer              apt-daily.service
Tue 2018-01-30 06:36:33 CET  15h left      Mon 2018-01-29 06:37:35 CET  8h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Tue 2018-01-30 09:25:48 CET  18h left      Mon 2018-01-29 09:25:48 CET  5h 33min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

et accéder aux logs de vos “timers” :

journalctl -f -u apt-daily
-- Logs begin at Tue 2018-01-23 13:50:12 CET. --
Jan 28 22:20:35 codb2d9 systemd[1]: Starting Daily apt download activities...
Jan 28 22:20:35 codb2d9 systemd[1]: Started Daily apt download activities.

En cas de modification du .timer ou du .service, ne pas oublier de faire un system daemon-reload pour que la version actualisée de vos fichiers soit prise en compte par systemd.

Passé la petite prise en main de ce nouveau cadre d’exécution, elle me semble plus simple et surtout plus facile à intégrer dans des chaines de déploiements pilotées par Ansible ou autre.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes traefik influxdb ansible elasticsearch kafka postgres grafana timeseries python aws redis sécurité mysql tick cloud ovh terraform warp10 cassandra helm swarm telegraf test timescaledb chronograf docker-compose rancher résilience architecture confluent ksql log machine-learning microservice prometheus ptsm serverless spark angularjs api cert-manager cncf container devops flux git gitlab graphql hashicorp iac java javascript monitoring opensource operator optimisation raspberrypi service-mesh stream windows arm bilan csp cérénit dns documentation elastic gcp hpkp ingress jenkins kafka-streams kapacitor kibana kubedb lambda lean licence maesh maintenance microsoft mobile nginx npm orientdb perspective redhat rest rethinkdb reverse-proxy s3 sauvegarde scaleway sql ssh agile apm automatisation azure bash big-data certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie dashboard deployment diff fluxlang framework gdpr grav hsts http/3 https hypriot hébergement influxace influxdata influxdays istio json k3s lets-encrypt linux load-balancer meetup molecule mongodb percona performance php pip pipeline postgresql reaper registry replication rook rpi rsyslog scale secrets société solr sre systemd tls vault virtualenv vscode vue.js wagtail yarn accessibilité acme akka alerte alibaba amazon-emr anonymisation anthos apache-pulsar ara audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges cassandra-reaper cd cdc centralisation-de-logs ceph certificats chart checklist chrome ci cloud-init cloud-native cloud-storage clusterip cnab cockroachdb code codeurs-en-seine confluence conftest consul continous-deployment coreos cors covid19 cqrs crash cron crontab csrf css curl d3.js daemonset data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian delta deprek8 desktop devoxx distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dokcer données-personnelles draft drop-in déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink flows fluentd forecast formation foundation frontend fsync fullstack github gitlab-ci gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud infrastructure-as-code ingénierie inspec jq jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel letsencrypt linky liste-de-diffusion loadbalancer logstash logstatsh loi longhorn mailing-list management mariadb message metallb micro-service mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null object-storage observabilité opa opendata openebs openmetrics openshit openssh openstack openweb over-engineering packaging pandas partiql password persistent-volume-claim pipenv pod portainer prediction prescience publicité pubsub push pyenv quasardb quay questdb queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rgpd rkt rolespec root rpo rto runc rwd safe-harbor scalabilité scanner schema sdk search select serverless-architecture service-account service-worker sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl stash statistique superset suse sympa syslog-ng test-unitaire tidb tiers timer timezone training travail tsl ubuntu unikernel unit ux vendredi victoria-metrics vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc warpscript web yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)