Web, Ops & Data - Aout 2017


30/08/2017 cloud docker microsoft aws cncf lambda serverless kubernetes linux windows elasticsearch kibana index search fullstack rethinkdb flash openweb api sécurité checklist certificat hpkp revocation performance tiers publicité

Cloud

Container & Orchestration

Documentation

  • Read & Write The Doc : les slides d’un talk donnant de bonnes pratiques sur la manière et les pratiques à adopter/éviter en matière de documentation.

Elasticsearch

  • Installing the Elastic Stack on Windows : Dans le cadre de la sortie de Elasticsearch 5.5, le support de l’installateur Windows est officiel. Ce billet montre comment installer Elasticsearch, Kibana et Filebeat sous un environnement Windows.
  • Taking A Look At Kibana’s Time Series Visual Builder : la future version 6 de Kibana va se doter d’un visualisateur orienté données temporelles (time series). L’auteur du billet rappelle que c’était un point faible de Kibana jusqu’à présent (vis à vis de Grafana notamment), que les essais avec Timelion ne répondaient que partiellement à ce besoin mais que là, Elastic semble être sur le point de rattraper son retard. A évaluer même si une plateforme TICK+Grafana (Telegraf, InfluxDB, Chronograf, Kapacitor) demandera moins de ressources qu’une stack Elastic/Kibana avec certes des capacités d’indexation moins forte mais le besoin n’est pas forcément là…
  • Elasticsearch: la grande migration : retour d’expérience des équipes Tech de M6 Web sur la migration de leur cluster Elasticsearch de la version 1.7 vers 5.2.
  • Small, Medium, or Large - Scaling Elasticsearch and Evolving the Elastic Stack to Fit : Elastic publie un billet intéressant donnant différents types de configuration & architectures pour des besoins autour d’ELK allant de simple à très complexe et fournir des pointeurs vers différentes ressources utiles.
  • Starting Down the Path of APM for the Elastic Stack : les prémices de la fonctionnalité APM (Application Performance Monitoring) d’Elastic suite au rachat d’Opbeat. Pour le moment, il s’agit de la pré-sortie des version serveurs et des clients ; pour la nouvelle UI, il va falloir attendre encore un peu mais des dashboards sont déjà accessibles via Kibana.
  • Introducing Index Sorting in Elasticsearch 6.0 : Dans sa version 6.0 à venir, il sera possible de définir des index triés dans Elasticsearch. Cette définition du tri se fera lors de la création de l’index. Si cela doit permettre de sortir des résultats plus rapidement, dans certains cas, cela peut pénaliser sérieusement la performance d’Elasticsearch. A utiliser à bon escient !

Full Stack

  • Développeur full stack ? Oui… mais… : enfin un bon article démystifiant le concept parfois fumeux de “full-stack” : “Quand nous parlons de profil full stack, cela signifie que le développeur est spécialisé dans certains domaines, tout en ayant des connaissances sur d’autres sujets. En général, nous considérons un développeur full stack comme maîtrisant au moins 3-4 sujets. Mais cela ne couvre pas l’ensemble des besoins."

NoSQL

Open Web

Sécurité

  • API Security Checklist : une check-list pour les aspects sécurité d’une API qui reprend les principaux points: authentification, traitement des entrée/sorties, infrastructure, etc.
  • CSP Cheat Sheet : Une page de présentation rapide et consise des options de configuraiton liée à CSP (Content Security Policy)
  • Revocation is broken : excellent billet sur les problèmes liés à la révocation de certificats et les nouvelles pistes à venir pour mieux traiter ce sujet.
  • I’m giving up on HPKP : l’auteur explique en quoi HPKP (HTTP Public Key Pinning) est compliqué et dangereux à mettre en place ; à la fin, le jeu n’en vaut pas la chandelle et qu’il vaudrait mieux ne pas tenir compte de cette pratique pour donner une bonne note aux configurations de sécurité des sites web. Il indique aussi les alternatives à venir et leurs avantages sur la solution actuelle.

Web Performance

Docker, dans un contexte hybride Windows et Linux


15/05/2017 docker swarm container windows linux

Suite à une mission, synthèse sur la possibilité à date de gérer des conteneurs Linux et Windows avec Docker.

Contexte

Les tests ont été réalisés, début mai 2017, sur les environnements suivants :

  • VM Ubuntu 16.04 LTS, à jour, avec Docker 17.03-ee
  • VM Windows Serveur 2016, à jour, avec Docker 17.03-ee.

En début de mission, il était supposé qu’une application métier en C# pourrait migrer vers ASP.net Core (la version opensource de .Net et sa déclinaison ASP) et donc sur un conteneur Linux. La suite nous prouva que toutes les APIs ne sont pas (et ne seront pas forcément) dans la version opensource de .Net et qu’il nous fallait envisager des conteneurs Windows à court terme et une infrastructure hybride Windows & Linux, tant au niveau des hôtes que des conteneurs.

Support de Windows dans le monde des conteneurs.

Avant d’aller plus loin, il faut bien avoir en tête la jeunesse du support de Windows dans le monde des conteneurs. Il faut distinguer deux niveaux de supports de l’OS Windows :

  • Support de Windows comme machine hôte et au sein de laquelle seraient exécutés des conteneurs,
  • Support de Windows comme OS de conteneur, celui-ci s’exécutant sur une machine hôte Windows et/ou Linux

Support de Windows comme machine hôte :

  • Docker Toolbox : annoncé en Aout 2015 avec le pré-requis de Virtualbox pour avoir une VM linux en intermédiaire, le projet est maintenant abandonné au profit de Docker for Windows.
  • Docker for Windows 10 : disponible depuis Juillet 2016, il permet d’exécuter soit des containers windows, soit des containers linux mais pas les deux en même temps.
  • Docker for Windows Server 2016 : disponible depuis septembre 2016. Il ne supporte que des conteneurs Windows.
  • Kubernetes supporte, en version alpha, Windows Server 2016 depuis la version 1.5 (décembre 2016). Néanmoins, toutes les fonctionnalités de Kubernetes ne sont pas encore implémentées à date : Kubernetes 1.5 supporting production workloads & Windows Server Support Comes to Kubernetes
  • Rancher supporte Windows en version expérimentale depuis la version 1.3 (Janvier 2017) ; Support de Windows dans Rancher

Support de Windows comme OS de container :

  • disponible depuis l’été 2016 pour Docker,
  • Depuis fin 2016 pour Kubernetes en version alpha,
  • Depuis début 2017 en version expérimentale pour Rancher 1.3+.

Dans le cadre de la DockerCon d’Avril 2017, Docker et Microsoft ont annoncé le support des conteneurs Linux sous Microsoft Server 2016 via Hyper-V. Il devrait alors être possible de pouvoir lancer simultanément des conteneurs Linux ET Windows sous Windows Server 2016. Il n’y a pas de date connue pour la sortie de la version supportant cette nouveauté. Il faudra surveiller les prochaines releases trimestrielles de Docker pour savoir quand cela sera utilisable de façon “stable”.

En somme, en continuant notre test plus loin, nous savons que nous entrons dans un monde immature avec un support incomplet.

Cluster Swarm hybride Windows/Linux

La première surprise fut de voir qu’il était possible de créer un cluster Swarm avec un noeud Windows et un noeud Linux sans pré-requis particulier.

Il faut ensuite créer manuellement le réseau overlay pour son application (ce sera supporté dans docker-compose 1.13+, version 3.2 du format). Si vous utiliser docker-compose, il faudra alors spécifier ce réseau comme un réseau externe afin que l’application s’y attache à son lancement.

Afin de piloter le déploiement des conteneurs sur les bons hôtes, il convient d’ajouter des labels (ou de s’appuyer sur des labels existants comme node.platform.OS). Ainsi, un conteneur Windows se déploira sur un hôte Windows et idem pour du Linux.

Jusque là, tout va bien mais c’est là que les limitations se font sentir :

  • Le réseau “Overlay”, permettant de ne faire qu’un réseau virtuel avec l’ensemble des noeuds d’un cluser Swarm, n’est supporté que depuis février 2017. Il faut donc s’assurer d’avoir une VM à jour et le patch correspondant.
  • Le “Routing Mesh”, qui permet d’avoir de publier un service sur un port donné et d’accéder à ce service depuis n’importe quel noeud du cluster depuis l’extérieur, n’est pas encore supporté.
  • Le Service Discovery sous Swarm se fait normalement via des IPs Virtuelles. Ce mode n’est pas supporté par Windows et il faut se rabbatre sur du DNS Round Robbin. Ce mode sera utilisable dans un fichier docker-compose en version 1.13+ et le format 3.2+. En attendant, il faut déployer les services manuellement.
  • Enfin, pour exposer des ports, il est obligatoire de les publier au niveau de l’hôte faute de quoi vos conteneurs ne pourront pas communiquer ensemble. L’allocation des ports est dynamique par défaut mais semble être figeable (non testé sous Windows).

Donc au final :

  • Swarm, en dehors d’apporter une résolution DNS, n’apporte pas grand chose pour le moment. Si les ports sont figeables et sous réserve de ne pas avoir plusieurs instances d’un même composant pour cause d’unicité de port, alors cela permettrait de faire un peu plus de choses.
  • Docker-compose en version 1.13 et le format 3.2+ permettrait de piloter une application déployable sur un cluster Swarm en étant capable de gérer la partie réseau et le endpoint dnsrr. Il faudra attendre la prochaine version stable de docker-ee sous Windows pour le valider.

Bon à savoir également :

  • Published Ports On Windows Containers Don’t Do Loopback. Cela vous évitera de perdre du temps à comprendre pourquoi votre conteneur ne répond pas sur localhost sur votre poste windows.
  • Pour une docker registry privée supportant les images Windows, il faut une version 2.5+ de la Docker Registry. La version actuelle est 2.6+

Une série de trois vidéos, publiées il y a quelques jours, montrent bien ce qu’il est possible de faire avec Swarm à ce jour.

Pour conclure, il est possible d’utiliser des conteneurs Windows mais que ce n’est pas encore la panacée. Cela reste néanmoins prometteur et les annonces de Microsoft vont dans le bon sens. Il va falloir attendre quelques mois pour envisager cela plus sereinement.

Update 16/8/2017 : La version 17.06 entreprise edition semble résoudre les limites évoquées précédemment.

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 terraform tick warp10 cassandra cloud ovh helm swarm telegraf test timescaledb chronograf docker-compose git rancher résilience architecture confluent ksql log machine-learning microservice prometheus ptsm serverless spark angularjs api cert-manager cncf container devops flux gitlab graphql hashicorp iac java javascript monitoring opensource operator optimisation raspberrypi s3 service-mesh stream windows arm bilan csp cérénit dashboard 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 rook sauvegarde scaleway sql ssh vscode agile apm automatisation azure bash big-data ceph certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie deployment diff fluxlang forecast framework gdpr grav hsts http/3 https hypriot hébergement influxace influxdata influxdays istio json k3s lets-encrypt linux load-balancer mariadb meetup molecule mongodb nosql percona performance php pip pipeline postgresql reaper registry replication rpi rsyslog scale secrets société solr sre systemd tls vault virtualenv vue.js wagtail yarn accessibilité acme akka alerte alibaba amazon-emr anonymisation anthos apache-pulsar ara arima audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges cassandra-reaper cd cdc cdk centralisation-de-logs certificats chart checklist chrome ci cloud-init cloud-native cloud-storage clusterip cnab cockroachdb code codeurs-en-seine commit confluence conftest consul continous-deployment conventional-commit 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 formation foundation frontend fsync fullstack github gitignore 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 message metallb micro-service mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad 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 ptyhon 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 setuptools 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 warpstudio web yubikey

Syndication

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