Web, Ops & Data - Semaine 48


30/11/2016 traefik docker kubernetes grafana null aws alerte monitoring dashboard reverse-proxy

Container & orchrestration

  • Kompose: a tool to go from Docker-compose to Kubernetes : en cours d’incubation chez Kubernetes, ce projet permet de faciliter la transition de Docker à Kubernetes en transformant les fichier docker-compose.yml en fichiers Manifests Kubernetes. Un pivot intéressant si on considère que les développeurs vont utiliser Docker (et au mieux Swarm) pour leurs environnements de développement et en production éventuellement Swarm et ensuite vouloir migrer vers Kubernetes pour ses fonctionnalités plus évoluées.
  • Introducing Distributed Cheese: Traefik 1.1 Camembert Is Out! : Traefik, le reverse proxy moderne qui sait s’interfacer notamment avec Docker, Consul, Kubernetes et plein d’autres est sorti en version 1.1.x. Cette version apporte notamment le support de l’API Docker Swarm (Docker 1.12+), une meilleure gestion des contraintes, le support de Mesos, une meilleure gestion des affinités de sessions, un mode cluster pour Traefik (expérimental) et une image officielle docker basée sur alpine. J’ai profité de l’installation d’un nouveau serveur pour déployer Traefik et c’est vraiment agréable de pouvoir déclarer dynamiquement ses containers docker. Par ailleurs, je rappelle que je maintiens des images docker de Traefik pour sa version ARM
  • Docker for AWS Public Beta : l’offre Docker pour AWS passe d’une version alpha à une verion beta. On notera essentiellement qu’il s’agit d’une version plus intégrée avec l’offre AWS que si l’on déployait un docker soi-même. A suivre mais attention à vérifier qu’il n’y a pas un lock-in qui se crée à la fin, que l’intégration apporte un plus et ne nuit pas à la portabilité des containers.

Dashboard, Monitoring

  • What’s new in Grafana v4.0 : la fonctionnalité phare de cette version est la capacité de définir des alertes au niveau de chaque élément d’un dashboard. Pour se faire il faut définir les règles à appliquer et ensuite s’appuyer sur la partie notification. Pour ceux qui étaient tentés d’installer Chronograf 1.1 (béta) pour avoir cet alerting en plus des dashboards adhoc de Grafana, ils pourraient bien finalement rester dans Grafana (dont la maturité n’est plus à prouver) plutôt que d’attendre que Chronograf se stabilise… A moins que Chonograf n’apporte une valeur ajoutée de part son intégration native avec Telegraf.

Pépites

  • Si vous pensiez que toutes les villes commencent par une lettre, maintenant vous savez que c’est faux avec la ville de ’s_Herenelderen. Vous pouvez mettre vos regexp à jour !
  • These unlucky poeple have names that break computers : même si l’article concède que ce problème est de moins en moins vrai au fur et à mesure des progrès réalisés et de la prise de conscience par les développeurs, mais s’appeller “Null” ou avoir un nom de famille très long (36 caractères dans l’exemple donné ou même 8 au Japon quand l’habitude est de 4…), cela pose des tas de problèmes dans la vie du quotidien.

DevoxxFR 2016


25/04/2016 kafka docker devoxx hadoop code société loi travail kubernetes microservice reverse-proxy frontend javascript rancher rsyslog scale documentation médecine unikernel jwt akka electron desktop vue.js continous-delivery

J’ai pu assister aux 3 jours de Devoxx FR 2016 ; voici les conférences qui ont retenu mon attention en repnant une approche thématique plutôt que chronologique.

Code et société

Travail & Société

  • De l’utopie de la fin du travail au digital labour :
    • La fin du travail pourrait-elle être un objectif ? Le lien entre travail et progrès technique était de diminuer la quantité de travail tout en améliorant sa qualité. Du coup, à terme, on pourrait imaginer que le travail de l’homme ne soit plus nécessaire.
    • L’auteur fait ensuite le panorama des théories de l’utopie, le travail ne disparait pas totalement mais est limité au juste nécessaire.
    • Passage d’une période où on travaillait par nécessité mais dégoût plutôt que par plaisir ou participer à la réalisation de soi, contrairement à maintenant.
    • Si l’ère numérique permet de faire apparaitre des formes plus intéressantes / agréables de travail, il a aussi ses à coté négatifs : ex de la précarité de certains emplois créées par l’uberisation des services (livreur ou chauffeur indépendant à la solde de qqs startups)
    • La période que l’on vie est-elle réellement la fin du travail ou bien une transformation historique et qu’il faut garder les utopies énoncées comme une boussole vers un avenir possible ? ie que nous n’en sommes qu’à une mutuation de la forme de travail mais que la fin du travail aura lieu bien plus tard ; si elle a lieu ?
  • L’entrepreunariat au féminin : retour sur 10+ ans de combat pour une meilleure prise en compte des femmes dans le monde du numérique. On y parle notamment du mouvememnt #JamaisSansElles et du fait que le numérique est une opportunité pour une meilleure mixité dans le travail. Etant déjà convaincu, je n’en dirais pas plus.
  • // TODO Implémenter le modèle de l’entreprise [de service] de demain. Retour d’expérience du patron de la société de services Zenika dans l’adoption d’une nouvelle forme d’entreprise.
    • Plutôt que d’entreprise libérée pour laquelle il y a plein de fanstasmes, il partle plutôt d’une entreprise reponsabilisante s’appuyant sur 3 piliers. Le premier est d’abaisser le centre de gravité de la décision le plus bas possible mais que cette décision se fait toujours dans l’intérêt de l’entreprise. Ensuite, les décisions sont prises par les personnes compétentes sur le sujet donné. Enfin, pour prendre de bonnes décisions, il est nécessaire d’avoir de la transparence.
    • Le micro-management est remplacé par du feedback immédiat (structure plate) d’une part et par des KPI et la transparence. Les KPI ont pour but d’illustrer le contexte de l’entreprise.
    • Le CEO doit être un Chief Enabler Officer ou facilitateur en bon français.
    • Les 5 axes à prendre en compte sont : donner du sens, le plaisir, l’humain, KISS et la transparence.

Ops, Docker & Microservices

  • Déployer vos applications sur un cluster kubernetes avec Ansible : le format Hands-on labs est compliqué à mener et c’est surement ce qui a miné cette présentation. Cela m’a néanmoins permis d’avoir une meilleure appréhension de Kubernetes. L’atelier fut l’occasion de découvrir Kargo (et kargo-cli), une surcouche à Ansible pour déployer un cluster Kubernetes ; ainsi que kpm pour déployer et gérer des applications sur un cluster kubernetes.
  • Traefik, a modern reverse-proxy : j’en ai parlé dans un précédent billet ; la présentation confirme l’intérêt d’un reverse-proxy adapté aux infrastructures micro-services et sachant s’interfacer avec des systèmes comme docker, etcd, consul, etc. J’ai bien prévu de l’utiliser pour mes prochains projets, une fois que j’aurais fini de tout transformer en container docker.
  • Building a unikernel java application : un unikernel est en gros un kernel qui ne contient que le minimum nécessaire pour lancer votre application et qui ne contient rien d’autre. Ce quickie a permis d’introduire le concept et de montrer le déploiement d’une application tomcat dans un format unikernel sur Google Cloud Platform. Si le concept est intéressant en soi, se repose un peu comme docker il y a quelques mois, la question de la maturité et de son écosystème. Même si la technologie unikernel existe depuis des années, on retrouve les problématiques de monitoring, sécurité, orchestration à adresser.
  • A la découverte du service discovery ; on manipule parfois etcd, consul ou encore zookeeper sans trop savoir ce qu’il se passe en leur sein. Cette présentation a été l’occasion de revenir aux basiques sur le concept de service discovery (un annuaire de services) et l’implémentation d’un cluster consul et son utilisation. Ce fut l’occasion de voir le mécanisme des health checks et comment des applications peuvent dynamiquement être informées de l’existence ou non d’un composant applicatif et de gérer des rechargements de configuration à la volée via consul-replicate.
  • Rancher, le (petit) orchestrateur docker qui vous veut du bien ; une introduction assez complète puisqu’elle décrit la configuration de rancher pour le déploiement d’une application 3-tiers et la mise en place d’une stratégie de mise à jour via rolling upgrade et en déploiement blue/green. A voir si Rancher peut aller jusqu’à gérer des environnements de production ou bien si cela reste un outil pour des expérimentatiosns / du dev / des labs et que l’on rebascule sur Kubernetes pour des (grosses) productions ?
  • Microservices IRL: ça fonctionne chez un client, on vous dit comment! ; un retour d’expérience sur le déploieemnt d’une architecture microservices et les problèmes rencontrés. Je suis peut être trop ce sujet en ce moment pour apprendre quelque chose de nouveau, si ce n’est l’éventuel remplacement d’Ansible par Spinnaker pour gérer les déploiements.
  • Dockerized system testing, with a dash of chaos : Arquillian est un framework (java) de test qui permet notamment de tester une application dans un container et de lui appliquer des containtes réseaux (timeout, latence, etc) avec les extensions Arquillian Cube & Arquillian Cube Q.

Coté Back

  • Stream processing avec les acteurs Akka : où comment via des composants simples que l’on peut combiner pour traiter des piles de messages de façon concurrente et distribuée (potentiellement). Cela peut éviter de déployer des clusters Spark/Storm/Flink qui ont un coût d’infrastructure non négligeable. Akka fonctionne sur la JVM aussi sur la plateforme .net. Si le pattern des actors vous intéresse, vous pouvez regarder ce qu’il existe pour votre langage favori.
  • 100% Stateless avec JWT (JSON Web Tokens : les JSON Web Tokens peuvent être vu comme les remplaçants des ID de sessions. Au travers des cookies, ils peuvent porter des informations qui sont signées et avec une date d’expiration mais en aucun cas chiffrées. Dans le cas d’une architecture distribuée et contrairement aux id de sessions, n’importe quel frontaux de votre application est en mesure de valider le token, contrairement aux id de sessions, qui, sauf à avoir un système de cache distribué, sont spécifiques à un frontal. Des articles complémentaires sur le sujet chez Stormpath et Auth0.
  • Hadoop à grand échelle : comment croitre sur le long terme ? : un retour d’expérience des équipes de Criteo sur l’exploitation et l’évolution de leur plateforme Hadoop avec des points d’attention sur
    • HDFS et la problématique de la gestion des espaces disques (taille), du nombre d’inodes (HDFS n’aime pas les petits fichiers). Mais aussi les aléas de ma JVM (152 Go) des Name Nodes avec la gestion de la RAM, du Garbage Collector, qui peuvent créer des surprises.
    • La gestion des jobs (1.3 millions lancés sur 15 jours) où il faut gérer les arbres de dépendances des jobs et la dépendance aux données pour bien les faire tourner ; un outil interne “langoustine” permet de visualiser cela.
    • La gestion des utilisateurs pour savoir qui (a) fait quoi et accompagner les utilisateurs du cluster
    • La nécessité de tout automatiser ! Avec 2000+ noeuds, pas le choix. Idem pour les utilisateurs !
    • Le choix de gérer leur infrastructure en interne ; Historiquement, Criteo a démarré avant que le cloud ne soit assez mature pour accueillir leur contacte. le cloud peut être vue comme trop lent (latence, etc) et vu que la charge est assez linéaire, l’elasticité du cloud n’est pas un argument. Ils estiment au final que leur infrastructure leur coûte 12 fois moins cher que si elle était hébergé chez un fournisseur de cloud.
    • Passage de 200 à 2600 serveurs en 2 ans.
    • Gestion des backups : définir la quantité strictement nécessaire de donénes vitales (entre 3 et 8 Po) ; snapshoté dans un 3ème datacenter.
  • Systèmes distribués, scotch, bouts de ficelle et doigts croisés : une histoire du streaming à Criteo - (Duct-tape streaming at scale (slides)). Récit du passage de la centralisation des logs d’une base MySQL à RSyslog puis à Kafka avec de nombreuses annecdotes et un retour humble puisque c’est toujours en cours (en tous cas, le sujet n’est pas encore fini, il reste des améliorations à porter). Sur Kafka, je retiendrais que si Kafka coté serveur est très performant, il faut par contre prendre le temps de comprendre comment fonctionne le client pour ne pas avoir des comportements “étranges”. Coté serveur, il est important de borner les queues dans la logique qu’il vaut mieux perdre des données que de ne plus avoir de système.

Coté Front

  • Conquérir le desktop avec Electron : Electron permet de développer des applications desktop avec des technologies Web. Pour cela, il embarque une instance de Chrome, V8 et Node.JS. La présentation s’attachera à démontrer comment il est simple de développer un petit logiciel de prise de note.
  • Vue.js, une alternative plus simple que React.js et Angular2 : Vue.js se veut un framework très orienté frontend ; Si la syntaxe est assez proche/similaire à celle d’Angular, vue.js se concentre vraiment sur la partie “Vue”. Contrairement à Angular par ex, il n’y a pas d’équivalent du module $http dans le coeur de vue.js. Pour autant, il peut être très complet et embarqué de quoi faire des tests e2e. Un framework a étudier si vous n’avez pas besoin de toute les fonctionnalités d’Angular mais plus des besoins de restituions uniquement (?).
  • Modulariser votre JavaScript avec JSPM et SystemJs ; SystemJS est un “module loader” pour ES6 et le reste par extension. JSPM est un gestionnaire de paquet qui s’appuie sur SystemJS. s’il n’y avait pas le fait que SystemJS était intégré à Angular2, je dirais bien que ce n’est qu’un n-ième système de gestion de packages javascript/css.

Côté Bonnes pratiques

  • L’odyssée du Continuous Delivery ; un retour très complet sur le passage de la Société Générale d’une application monolithique avec du code historique et l’équipe associée vers du continous delivery. Cela couvre aussi bien les thèmes humains (passage component teams > feature teams, gestion de la montée en compétence et du changement de culture de l’équipe, etc) que les thèmes techniques (mise en place d’un release train, feature toggling, etc).
  • Living Documentation : vous allez aimer la documentation ! :
    • Après avoir rappelé que la documentation sert à partager un savoir, le rendre accessible et à transmettre pour plus tard, le présentateur indique aussi que certaines documents sont inutiles : shameful comments (le commentaire qui sert à rien et dont on peut se passer avec un code plus lisible, mieux nommé) ou parfois qu’il vaut mieux une bonne conversation plutôt qu’une (mauvaise) documentation pour former quelqu’un qui rejoint une équipe par ex.
    • Lire la documentation doit permettre de comprendre le métier.
    • Plutôt qu’une documentation, il est aussi possible de coller sur un mur (investigation wall) tous les éléments qui permettent d’appréhender le métier, sans parler de stage terrains, etc. Cela peut être plus efficace/performant qu’une documentation classique.
    • Nécessité de séparer la documentation stable (evergreen documentation) de la documentation instable. Pour cette documentation instable, possibilité d’utiliser le BDD (Behaviour Driven Development) qui, au travers d’un scénario, formalise une intention, des exemples concrets et les exceptions le cas échéant.
    • La documentation peut être au milieu du code (commentaires, annotations, etc) et elle est générable par automatisation.
    • Au final, l’auteur cherche à montrer qu’une bonne documentation permet d’améliorer le design de son application et réciproquement.
    • Côté outil et BDD, on parlera surtout de Cucumber et Pickles.

Côté Nouveaux horizons

  • La blockchain en détail : une présentation progressive sur les principes, la technologie et les enjeux de la blockchain au travers notamment du bitcoin et d’ethereum. A regarder absolument pour mieux comprendre ce nouvel écosystème, en plus de consulter le site Blockchain France.

En synthèse, une belle première expérience à Devoxx, même pour un non-javaiste comme moi ; des retours d’expérience qui font réfléchir et instructifs dans l’immédiat ou bien à plus long terme à titre pro ou perso. Il se pourrait bien que j’y retourne l’année prochaine !

Web, Ops & Data - Semaine 14


08/04/2016 reverse-proxy docker kubernetes elasticsearch kibana vnc ssh openshit influxdb tick reindex

Infrastructure

Container

  • Elastikube : une solution de gestion d’une infrastructure Kubernetes ; cela fait penser à une version allégée d’Openshift. Containers
  • Containers are not VM : Une clarification par l’équipe Docker sur la différence entre un container et une VM sur la base de l’analogie avec l’appartement (le container) et la maison (la VM). Une maison (VM) contient tout ce dont elle a besoin pour fonctionner alors que pour un immeuble, des ressources sont partagées et chaque appartement de l’immeuble en profite dans une certaine mesure.
  • Docker a annoncé Docker pour Windows/Mac (beta) ; cela permet d’utiliser Docker de façon plus native et intuitive sous Windows/Mac. Pour Windows, cela demande d’avoir Windows 10 pour bénéficier de l’hypervision via Hyper-V. Sur ce sujet, l’équipe Hypriot dans leur revue de Docker pour Mac et Docker pour Windows montre le bonus (easter egg) de cette version à savoir qu’il est possible de faire tourner des conteneurs ARM sous environnement OSX/Windows ; cela permettrait de batir des conteurs pour Raspberry ou des projets IoT plus facilement. Je ne peux hélas pas le tester pour le moment, mais cela semble plus prometteur que Docker Toolbox qui reste un peu complexe à mettre en oeuvre.
  • Rancher, une solution d’orchestration de conteneurs, après avoir annoncé le support de Kubernetes, vient d’annoncer la sortie de la version 1.0. A suivre, même si la notion d’environnement ne permettrait pas une allocation optimale des capacités d’infrastructure (chaque environnement aurait ses hôtes alors que Kubernetes pourrait a priori permettre une mutualisation totale via la gestion des “namespaces” ; à creuser !).
  • Kubernetes, la solution d’orchestration de container (Docker/Rocket) développée par Google, est sorti en version 1.2 avec diverses améliorations et notamment une nouvelle GUI.
  • Kubernetes on ARM vient de sortir sous la version 0.7.0 ; de quoi se faire la main sur Kubernetes avec vos Raspberry ;-) ; une image Rancher est d’ailleurs disponible.
  • Docker en production : la bataille sanglante des orchestrateurs de conteneurs : Pour conclure, Octo compare Docker Swarm, Kubernetes et Openshift et donnant Kubernetes gagant pour le moment. Personellement, vu qu’a minima pour Kubernetes et Docker Swarm, on peut utiliser des containers docker, il est peut être intéressant de combiner les 2 solutions qui répondent plus ou moins bien à différentes problématiques. Je vois assez bien l’utilisation de Docker Swarm dans une logique de développement / labs et plus Kubernetes en effet dans une logique de production pure. Il ne faut pas se cacher que Kubernetes est plutôt “Ops friendly” et remonte la chaine de valeur vers les développeurs quand Docker fait le contraire…

Elasticsearch & friends

InfluxDB & Friends

Sysadmin

  • Teleport ; Une passerelle (bastion) SSH qui permet d’accéder à ses serveurs via SSH ou en HTTPS via une IHM Web. A tester !

Sécurité

  • VNCFail ; vous reprendrez bien un peu de non sécurité: l’analyse des 4 milliards de plage IPv4 remonte 5 millions d’adresse pour lesquelles le logiciel VNC (prise de contrôle à distance) est accessible et au final 2.246 hotes avec des systèmes accessibles sans mot de passe dont des systèmes sensibles (contrôle d’aération, usine éléctrique, etc).

Syndication

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

Nuage de tags

kubernetes docker timeseries influxdb warp10 grafana traefik elasticsearch kafka postgres python ansible aws sécurité terraform mysql redis telegraf git ovh tick chronograf cloud dashboard docker-compose hashicorp timescaledb cassandra helm podman ptsm swarm test vector flux iot kapacitor rancher timescale cérénit influxdata log machine-learning monitoring postgresql raspberrypi s3 spark sql vscode arm bilan comptabilité confluent devops gitlab gitlab-ci iac java ksql microservice nomad perspective prometheus serverless service-mesh angularjs api bigdatahebdo cli cncf consul container discovery dns flows gcp gke graphql influxace ingress javascript npm opensource operator rook scaleway ssh stream vault warpscript windows architecture cert-manager containerd csp documentation elastic forecast geospatial golang hpkp json kafka-streams kibana kubedb lambda lean licence maesh mariadb microsoft mqtt nginx orientdb quasardb redhat registry rest rethinkdb reverse-proxy rgpd warpstudio wireguard agile anomalie apm arima azure bash big-data ceph certificat challenge cluster co2 continous-delivery continous-integration cookie datatask dataviz dbt deployment diff django edge esp32 facebook fec fluxlang gdpr google-analytics grav hsts http/3 https hypriot ia influxdays istio jq k3s lets-encrypt linux load-balancer longhorn meetup metabase mobile molecule mongodb nosql nvidia openebs openhab openssh ovhcloud pandas parquet percona performance php pip pipeline questdb reaper replication rootless rpi rsyslog runc résilience scale secrets société solr sre systemd tempo timezone tinygo tls virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme adoptopenjdk agpl akka alerte alertes alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arduino arrow artefact asgi automation automatisation automl awstats banque bastion beam beat bi bme680 bootstrap bounded-context branche brigade browser buildah buildkit calico cd cdc cdk centos certificats cgroups chart check checklist chrome ci cilium cio circuitpython clever-cloud clickhouse cloud-init cloud-native cloud-storage cloudflare clusterip cnab cni 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 cto curl d3.js daemonset data 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 dockerfile dockershim documentdb dog dokcer données-personnelles draft dredd drop-in dsi duckdb duration déploiement ebs ec2 elassandra electron elk engineering entreprise etcd euclidia event-sourcing faas falco falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink flovea fluentd font foundation framework frenchtech frontend fsync fugue fullstack git-filter-repo github gitignore gitpod glacier glowroot goaccess google google-cloud-next gpg gpu grep grid géospatial hacker hadoop haproxy harbor hdfs header holt-winters html html5 http httpx hue iaac ibm iiot immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jenkins jless jquery jvm jwt k3d k6 k8s k9s kaniko katz 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 matomo maturité mesh mesos message metallb micro-service minio mot-de-passe multi-cloud médecine métrique n8n nebula network newsletter nodejs nodeport notebook notifications nrtsearch null numérique object-storage observability observabilité opa opendata openmetrics openshit openstack openweb opnsense over-engineering packaging partiql password persistent-volume-claim pico pipenv pivot pod portainer portworx prediction prescience privacy-shield 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 rhel rkt robotframework rolespec root rpo rto rust rwd réseau résultat safe-harbor sarima scanner schema scp search select semiconducteur serverless-architecture service service-account service-worker setuptools sftp sha1 shard shard-duration shard-group sharding shell shipyard sidecar singer socket souveraineté-numérique spectre spinnaker sqlite sri ssh-agent ssl stabilité stash statistique stm32 storage sudo superset suse sympa sysdig syslog-ng sérénité task tavern template terracost terrascan test-unitaire thingspeak tidb tiers time timecale timer timestream training transformation travail trésorerie tsfel tsfr tsl ubuntu unikernel unit ux velero vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc vpn wasm workflow yaml yield yq yubikey zip