*

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.

Syndication

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

Nuage de tags

kubernetes docker timeseries influxdb warp10 traefik grafana ansible elasticsearch kafka postgres python aws sécurité terraform mysql redis telegraf ovh tick cassandra chronograf cloud dashboard docker-compose git hashicorp helm timescaledb flux ptsm swarm vector kapacitor podman rancher résilience test gcp gitlab influxdata log machine-learning monitoring prometheus s3 spark timescale vscode architecture arm comptabilité confluent devops gitlab-ci iac java ksql microservice nomad postgresql raspberrypi serverless service-mesh sql angularjs api bilan cert-manager cncf consul container cérénit dns flows gke graphql ingress javascript npm opensource operator optimisation perspective pipeline rook scaleway ssh stream vault warpscript windows cli containerd csp discovery documentation elastic forecast geospatial golang hpkp influxace iot jenkins kafka-streams kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx orientdb performance quasardb redhat registry rest rethinkdb reverse-proxy sauvegarde warpstudio agile anomalie apm arima audit automatisation azure bash big-data bigdatahebdo ceph certificat challenge ci/cd cluster continous-delivery continous-integration cookie data datatask dataviz dbt deployment diff facebook fec fluxlang framework gdpr grav hsts http/3 https hypriot hébergement ia influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup metabase molecule mongodb nosql nvidia openebs openssh ovhcloud percona php pip questdb reaper replication rootless rpi rsyslog runc scale secrets société solr sre systemd tempo timezone tls virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme adoptopenjdk agpl akka alerte alertes alerting alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arrow artefact automation automl banque bastion beam beat bi bme680 bootstrap bounded-context branche brigade browser buildah buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart check checklist chrome ci cilium circuitpython clever-cloud clickhouse cloud-init cloud-native cloud-storage cloudflare clusterip cnab cni co2 cockroachdb code codeurs-en-seine commit confluence conftest consul-connect context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data-engineer data-pipelining data.gouv.fr databricks datacenter date date-scientist ddd debezium debian delta deprek8 desktop devoxx dig distributed-systems dive docker-app docker-hub docker-registry docker-swarm dockershim documentdb dog dokcer données-personnelles draft drop-in duration déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd euclidia event-sourcing faas faisabilité falco falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frenchtech frontend fsync fullstack git-filter-repo github gitignore glacier glowroot go google google-cloud-next gpg gpu grid géospatial hacker hadoop haproxy harbor hdfs header holt-winters html html5 http hue iaac ibm immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jquery jvm jwt k3d k6 k8s k9s kaniko katz kotlin kubeadm kubecon kubectl label laravel leap-second lens letsencrypt libssh linky linter liste-de-diffusion lmap loadbalancer logstash logstatsh loi loki lstm mailing-list management maturité mesh mesos message metallb micro-service minio mot-de-passe mqtt multi-cloud médecine métrique n8n network newsletter nodejs nodeport notebook notifications nrtsearch null object-storage observability observabilité opa opendata openhab openmetrics openshit openstack openweb opnsense over-engineering packaging pandas parquet partiql password persistent-volume-claim pico pipenv pivot pod portainer portworx prediction prescience production promql prophet prévision psp ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quay queue quic ram rambleed raml react readme recaptcha recherche redistimeseries reindex reinvent reliability remote-execution repository responsive retention-policy revocation revue-de-code rexec rgpd rhel rkt rolespec root rpo rto rust rwd résultat safe-harbor sarima scalabilité scanner schema scp sdk search select serverless-architecture service service-account service-worker setuptools sftp sha1 shard shard-duration shard-group sharding shell shipyard sidecar singer souveraineté-numérique spectre spinnaker spécifications sqlite sri ssh-agent ssl stabilité stash statistique storage sudo superset suse sympa sysdig syslog-ng sérénité task template terracost terrascan test-unitaire tidb tiers time timecale timer timestream tinygo training transformation travail trésorerie tsfr tsl ubuntu unikernel unit ux velero vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc wasm web wireguard workflow yaml yield yq yubikey