Forem: Erwan Deruelle

Discovering Vector

Erwan Deruelle — Wed, 15 Apr 2020 12:00:00 +0000

TL/DR

Logstash + Rust = Vector ?

We can actually describe Vector as a Logstash built in Rust, with all the language’s advantages for free (high performance, cross-compilation), but the flaws of a still young product (few modules, no known references). Note that the documentation seems well done, and the first existing modules allow you to manage a lot of simple monitoring use-case. As we can agree that Logstash is not the best product in the world, let’s hope that Vector will find its place in the community in the coming months. In addition, Vector natively offers modules equivalent to the Logstash’s one, which means that the migration will not be complicated!

And so what ? We have time, right ? #LockedDown

Vector could be defined as an high-performance observability data router that makes transforming, collecting, and sending events (logs & metrics) easy.

Concept

Basically, it’s an ETL based on the following concepts:

Source (aka. E / Extract)

Reading raw data from the source.For example, we could read log into a file, listen a Kafka topic or get StatsD metrics

Transform (aka. T / Transform)

Transform raw data, or complete data stream.For example, we could filter entries or parse a log using a regular expression

Sink (aka. L / Load)

Destination for events. Each module’s transmission method is dictated by the downstream service it is interacting with (ie. individual events, bulk or stream). For example, we could save raw data into Amazon S3, indexing them into Elasticsearch or expose to Prometheus

Features

Fast

Built in Rust, Vector is fast and memory-efficient, all without runtime or garbage collector

One only tool, from source to destination

Vector is designed to be used by everyone, whatever the context, by offering several deployment strategies:

Daemon

In this case, it serves as serves as an light-weight agent by running in the background, in its own process, for collecting all data for that host.

Sidecar

Here, it serves also an an agent, but we will have one process by service.

Service

In ths case, Vector is a separate service designed to receive data from an upstream source and fan-out to one or more destinations.

By using and/or combining theses strategies, we can define several architecture topologies to collect our data.

Distributed

In this topology, each Vector instance will directly send data to downstream services. It’s the simplest topology, and it will easily scale with our architecture. However, it can impact local performance or lead to data losses.

Centralized

Here, each agent will send data to a dedicated centralized Vector instance, which will responsible to do the most expensive operations. So, it’s more efficient for client nodes, but a dedicated centralized service as a SPOF which could lead to data losses.

Stream based

Variant of the previous topology, in which we will add a broker upstream of the centralized service in order to remove the SPOF. This topology is the most scalable and reliable, but also the most complex and expensive.

Easy deployment

Built with Rust, Vector cross-compiles to a single static binary without any runtime.

Well, but does it really works ?

I will be inspired by a previous blog post :

An ELK stack from scratch, with Docker

Erwan Deruelle ・ Apr 9 ・ 3 min read

#monitoring #elk #elasticsearch #kibana

Proof of concept architecture

In this case, we will use:

Elasticsearch, search engine which provide full text search & analytics,
Kibana, which provide an UI for exploring data, and create interactive dashboards
Vector, as central service, to transform events and sending them to Elasticsearch,
Kafka, as an upstream broker
Vector, as an agent, to ingest raw source data and sending them to Kafka

So here, we are under a Stream based topology

Services and interactions are described in a docker-compose.yml file:

The Vector central service is configured as below:

Reading events from Kafka
JSON Parsing from events send by Vector agent
Grok Parsing (same as Logstash Grok format) from raw log line
Indexing into Elasticsearch

Fun fact, we can unit testing our configuration, as we can see in the [[tests]] section.

Note that each configuration step is based on at least one previous step.

On our webapp side, we will have an Vector agent configured as below:

Reading logs from file
Sending them to Kafka

Complete projet is available on github

d3rwan / discovering_vector

Now, I can start all my services with docker-compose:

 docker-compose build
 docker-compose up

Then, you should be able to access the web app (http://localhost:80, in my case) Web Application example (source: https://github.com/sbilly/joli-admin)

After few minutes browsing, you can go to Kibana UI. (in my case, http://localhost:5601), then click on Management tab, then Kibana > Index Patterns

Adding vector-* index pattern

Here we go ! A vector-YYYY.MM.DD index should be created with my application logs.From there, I will be able to create my searchs, visualizations, dashboards or canvas in Kibana, and use all theses informations.

To conclude, it’s actually quite easy to use Vector as a substitute for Logstash/Beats in an Elastic stack, and it works.Remains to see if performance gains are real, and if the project can resist in the future and become a real alternative for the community.Until then, even very young, this project is full of promises and good ideas (unit tests, multi-topologies, …), and so deserves that we take a look!

A la découverte de Vector

Erwan Deruelle — Tue, 14 Apr 2020 12:00:00 +0000

TL/DR

En 2 briques,
Logstash ? ETL !
Rust ? Vector !
On peut effectivement décrire Vector comme un Logstash qu’on aurait réécrit en Rust, avec tous les avantages inhérents au langage (performance, binaire natif), mais les défauts d’une solution encore très jeune (nombre de modules limités, peu de références). On notera que la documentation semble plutôt bien faite, et que les composants natifs permettent de gérer beaucoup de use-case simple de monitoring. Et comme on peut convenir que Logstash n’est pas le meilleur produit du monde, espérons que Vector trouve sa place dans les prochains mois dans la communauté. Et en plus, ca tombe bien, Vector propose nativement des modules équivalents à ceux de Logstash, ce qui fait que la migration ne sera pas compliquée !

Après-tout, on a le temps non ? #Confinement

Vector se défini comme un routeur de données d’observabilité haute-performance, qui permet la collecte, la transformation et l’envoi d’évênements (logs et/ou métriques).

Fonctionnement conceptuel

Il s’agit basiquement d’un ETL qui s’appuie sur les notions suivantes:

Source (aka. E / Extract)

Récupération des données brutes depuis l’endroit où elles sont produites.
Par exemple, on pourra lire les logs dans un fichier, écouter une file Kafka ou récupérer des métriques de StatsD

Transform (aka. T / Transform)

Transformation des données brutes, ou du flux complet de données,
Par exemple, on pourra filtrer des entrées ou encore parser un log selon une expression régulière

Sink (aka. L / Load)

Destination des données lues et transformées. Chaque module enverra les données de manière unitaire ou sous la forme d’un stream en fonction du service cible.
Par exemple, on pourra sauvegarder les données brutes sous Amazon S3, les indexer dans un cluster Elasticsearch ou les exposer à Prometheus

Fonctionnalités

Rapide

Ecrit en Rust, Vector est très rapide avec une gestion efficiente de la mémoire.Le tout sans runtime, ni garbage collector.

Un outil unique, de la source à la destination

Vector propose plusieurs stratégies de déploiement afin de pouvoir être utilisé par tous, quelque-soit le contexte.

Déploiement en tant que Démon

Ici, on lancera une instance de Vector en tâche de fond pour collecter toutes les données du serveur hôte

Déploiement en tant que Sidecar

Dans cette stratégie, on lancera une instance de Vector par service à monitorer.

Déploiement en tant que Service

Ici, Vector est lancé en tant qu’un service dédié.

En utilisant et/ou combinant ces stratégies, on peut donc définir des topologies d’architecture de collecte de données

Collecte distribuée

Dans cette topologie, chaque instance de Vector va directement envoyer les données au(x) service(s) cibles. Il s’agit du cas le plus simple, et qui permet de scaler facilement. Néanmoins, il peut induire des pertes de performance locales ou de données.

Collecte Centralisée

Ici, chaque instance de Vector va envoyer les données à une instance centrale, chargée d’effectuer les opérations les plus coûteuses. De fait, moins d’impact sur les performances locales des applicatifs, mais un service centrale en tant que SPOF

Collecte Streamée

Variante de la topologie précédente, dans laquelle on va rajouter un broker en amont du service centrale afin de supprimer le SPOF. Cette topologie est la plus scalable et durable, mais aussi la plus complexe à mettre en place.

Simplicité de déploiement

Concu en Rust, Vector se présente donc sous la forme d’un binaire cross-compilé pour l’os cible, et ne nécessite pas de runtime type JVM

Bon, OK, mais ca marche au moins ?

Pour tester Vector, je vais m’inspirer d’un post précédent :

Une stack ELK from scratch avec Docker

Erwan Deruelle ・ Apr 9 ・ 3 min read

#monitoring #elk #elasticsearch #kibana

Architecture de notre POC

Dans le cas présent, je vais m’appuyer sur :

Elasticsearch, comme moteur d’indexation, de recherche & d’analytics,
Kibana, comme IHM de visualisation et de génération de tableaux de bord interactifs
Vector, en tant que service central, pour transformer les données et les envoyer vers Elasticsearch,
Kafka, en tant que broker en amont de ma stack de monitoring
Vector, en tant qu’agent, pour récupérer les données sources et les envoyer vers Kafka

On se positionne donc dans la topologie de Collecte Streamée décrite ci-avant

L’ensemble des services et des interactions sont décrites dans un fichier docker-compose.yml:

Le service central Vector est configuré comme suit:

Lecture des événements depuis le broker Kafka
Parsing du JSON de l’événement envoyé depuis l’agent Vector
Parsing Grok (format Logstash) de la ligne de log brute
Indexation vers Elasticsearch

Fun fact, il est possible de tester unitairement la configuration avec Vector, comme on peut le voir dans la section [[tests]] du fichier

On pourra également noter que chaque step de configuration se base sur au moins un step précédent.

Côté webapp, on ajoute un agent Vector configuré comme suit:

Lecture des logs depuis un fichier
Envoi vers le broker Kafka

Le projet de test complet est disponible sur github

d3rwan / discovering_vector

Il ne me reste qu’à lancer tous mes services

 docker-compose build
 docker-compose up

Puis me rendre sur ma webapp (dans mon cas, http://localhost:80)
Exemple d’application web (source: https://github.com/sbilly/joli-admin)

Après une rapide navigation, je peux me rendre sur mon IHM Kibana (dans mon cas, http://localhost:5601), puis dans l’onglet Management puis Kibana > Index Patterns

Ajout du pattern d’index vector-*

Et voilà ! Un index vector-YYYY.MM.DD a été crée et contient bien mes logs applicatifs. A partir de là, je vais pouvoir créer mes indexs, recherches visualisations, dashboards et autre canvas dans Kibana, et pouvoir utiliser ces informations de monitoring.

Pour conclure, il est effectivement assez facile d’utiliser Vector comme remplaçant de logtash/beats dans une stack Elastic, et le fait est que ca fonctionne. Reste à voir sur la durée si les gains de performance annoncé sont réels, et si le projet arrive durablement à s’imposer dans la communauté. En attendant, même très jeune, ce projet est plein de promesses et de bonnes idées (tests unitaires, multi-topologies natives, …), et mérite donc qu’on y jette un oeil!

Hello, new world - De Medium à Dev.to

Erwan Deruelle — Fri, 10 Apr 2020 12:00:00 +0000

Préambule

Quel jour on est déjà ? Ah, #ConfinementJour25 selon Twitter.Depuis quelques jours j’ai ressenti l’envie de refaire des articles de blog.

Lors de mes derniers articles, j’avais choisi d’utiliser la plateforme Medium, qui permettait à l’époque facilement de publier du contenu au travers d’une IHM minimaliste, tout en offrant une belle visibilité.Depuis, la plateforme a évoluée, et est devenue assez désagréable à utiliser en tant que lecteur. Affichage permanent du paywall, obligation de se connecter, exode d’une partie de la communauté tech…

L’alternative du moment, c’est dev.to, et ca a l’avantage (ou l’inconvénient) d’être orientée tech, là ou medium se voulait plus généraliste.

DEV Community 👩‍💻👨‍💻

@thepracticaldev

DEV is now open source dev.to/ben/devto-is-n…

17:04 PM - 08 Aug 2018

266 796

Néanmoins, on peut se poser la question : est-ce que ce ne serait pas qu’un nouveau medium, qui suivra le même chemin ? Sans-doute diront certains, néanmoins dev.to propose nativement une fonctionnalité de cross-posting qui permet de publier sur leur site un article que vous auriez publié ailleurs. On pourrait donc avoir les avantages d’une plateforme en vogue (visibilité, communauté), tout en gardant la propriété de ses données ? C’est même un concept : POSSE - Publish on your Own Site, Syndicate ElseWhere

De medium à un blog maison

J’ai décidé de partir sur Gatsby, un générateur de site statique basé sur ReactJS et GraphQL.Gatsby se base d’une part sur des composants React affichant la structure du blog, et permet d’autre part de parser des fichers markdown qui correspondent aux articles de blog.

Par ailleurs, la fonctionnalité Github Pages permet d’exposer un site statique.

1- Récupérer mes anciens articles sur medium.

Pour cela, j’ai utilisé le projet mediumexporter qui permet automatique de parser un article en markdown depuis son url publique.

Il a fallu néanmoins une seconde passe de nettoyage du markdown généré, notamment pour remplacer les medias importés dans medium (image, tweets ou gist).

2- Bootstraper un blog avec Gatsby

Rien de plus simple, il existe un tas de boilerplate sur Github, parmis lesquels celui de Dan Abramov, le créateur de Redux.

gaearon / overreacted.io

Personal blog by Dan Abramov.

Le plus simple est cependant de se baser sur le starter officiel qui explique le mode opératoire pas à pas.

gatsbyjs / gatsby-starter-blog

Gatsby starter for creating a blog

3- Publier sur Github Pages

Là encore, la documentation officielle est bien faite et explique le fonctionnement pas à pas.

En 2 mots, dans mon cas, depuis mon repository Github, en allant dans le menu Settings, dans la section GitHub Pages, je choisi la branche dans laquelle est versionnée la version générée du blog

Configuration de Github Pages

A noter que la branche gh-pages est la branche par défaut lors de l’utilisation du plugin gh-pages

D’un blog maison à Dev.to

Là encore, rien de très compliqué.

Une fois son compte crée, il suffit de configurer son alimentation par un flux RSS.

Pour cela, se rendre dans le menu Settings > Publishing from RSS, puis y renseigner l’url du flux RSS généré par son blog personnel (par défaut, un blog Gatsby aura généré un fichier rss.xml à la racine)

Configuration de l’alimentation par flux RSS

A partir de là, tous les articles de votre blog vont être importés dans dev.to, et seront visible depuis le menu dashboard. Par défaut, les articles sont importés en mode draft, ce qui vous laissera le soin de valider la bonne importation, et éventuellement corriger les éventuelles différences.Par exemple, dans le cas d’import d’un tweet ou d’un gist, il existe une syntaxe particulière qu’il faudra adapter pour un rendu optimal.

Edition d’un post depuis dev.to

Dernier point important, verifier que le champ canonical_url dans la configuration de votre post se réfère bien au post original sur votre blog.

Et voila, en quelques heures, j’ai pu récupérer le contenu des mes anciens posts, créer et déployer un blog personnel pour les publier, et les syndiquer sur dev.to.

Hello, new world.

Retour sur Devoxx France 2018 - Les conférences les plus…

Erwan Deruelle — Wed, 02 May 2018 12:00:00 +0000

La 7ème édition de Devoxx France (aka la conférence des développeurs passionnnés) s’est déroulée du 18 au 20 avril dernier. Voici mon retour sur les conférences les + …

La plus gourmande 🍪

Hubert Sablonnière nous présente le résultat de son enquête sur un des plus grands mystères du web actuel : les cookies HTTP. Création de Lou Montulli, également créateur du navigateur en ligne de commande Lynx ou initiateur de la balise et des gifs animés, le cookie est un protocole serveur/navigateur pour stocker un état côté client. Dans son talk, le speaker nous explique les pièges à éviter, et les bonnes pratiques à avoir pour sécuriser au maximum son application. Un *back to basics *à voir absolument quand on est pas à l’aise avec ces petites choses, élément fondateur du web actuel.

Arnaud Héritier #AtHome

@aheritier

On mange des 🍪 avec @hsablonniere à #devoxxfr

10:34 AM - 19 Apr 2018

1 9

La plus visuelle 🎨

Dans leur quickie Let’s sketchnote, Ane Diaz & Amélie Benoit nous présente les bases de la prise de note visuelle. A priori accessible à tout ceux qui ont passé le CP, le sketchnote consiste à utiliser des éléments de base tels que du texte ou des pictos, de les enrichir de flèches et de contenants, et d’agrémenter de couleur pour obtenir des compte-rendus uniques et créatifs. Et en plus ca favorise la concentration et la mémoire. On demande à voir nos oeuvres sans le talent des demoiselles, mais on ressort de là en ayant envie d’essayer. Un mini coup de coeur.

Amélie Benoit

@ameliebenoit33

Hi Sherlock ! #Sketchnote sur la conférence à propos des cookies HTTP de @hsablonniere à #DevoxxFR 🍪

Reprise des bases, questions autour de la sécurité, le tout très clair et ludique !

14:03 PM - 20 Apr 2018

28 65

La plus digitale 👋

Emmanuel Pesenti vient nous expliquer comment le programme #FrenchRoad doit permettre à la France de rattraper son immense retard numérique, avec notamment son projet de carte à tout faire, *et de faire en sorte que la France devienne une *nation digitale européenne. *Cette keynote n’est finalement qu’une variante française (et digitale) de celle d’Arnaud Castanier la veille où ce dernier nous a expliqué comment l’Estonie, avec son programme e-resident est devenue une nation à la pointe du numérique, avec 32000 e-residents de 150 nations différentes, ainsi que 5000 entreprises, et même une e-ambassade. La nation digitale hexagonale a donc beaucoup de travail devant elle. *On se sort les doigts ?

Numérique, bordel !

@numeriquebordel

On me dit dans l'oreillette que c'est plus de 10 fois en 31 min.
@DevoxxFR, faites quelque chose ! Remplacez le mot par un bip, plaquez les orateurs au sol, peu importe. Juste faites quelque chose ! #DevoxxFR twitter.com/adericbourg/st…

07:34 AM - 20 Apr 2018

Alban Dericbourg @adericbourg
#DevoxxFR Durée nécessaire avant d'entendre parler de doigts / digital : — jeudi : 48 min — vendredi : 24 min

19 42

La plus ironique 🤔

Suite au rachat de Vivendi, Dailymotion a dû se réinventer. Un des axes de travail des équipes fût d’améliorer la partie recommandations, pour passer sur du temps réel. Dans ce talk, Philippe Girolami & Didier Girard nous présente comment, face à un timing court et des équipes en reconstruction, Dailymotion a choisi de passer d’une stack OSS en interne à la stack data cloud de Google, et les gains apportés par celle-ci. Quand bien même Google est également, avec Youtube, leur principe concurrent.

Erwan Deruelle

@d3rwan

« Architecture realtime data de Dailymotion » #DevoxxFR
Ou l’on apprend que Dailymotion utilise les technologies de son principal concurrent Google pour faire marcher son infra... Ironique ?

14:28 PM - 20 Apr 2018

0 0

La plus sécuritaire 🔐

Dans son talk, Frédéric Cabestre repart des bases des clés publiques/privées et nous emmène sur les chemins des certificats et autres joyeusetés, pour enfin que nous puissions comprendre comment Let’s Encrypt a changé la donne dans le milieu des autorités de certifications. Des rappels utiles si vous avez déjà mis le nez dedans, à voir absolument pour les autres !

Guillaume Membré

@guillaumemembre

Merci @fcabestre d'avoir éclairé ma lanterne sur l'automatisation des certificats 'let's encrypt' à #devoxxfr2018

13:39 PM - 19 Apr 2018

3 4

La plus legacy (mais dans des conteneurs) 🚢

David Gageot vient nous montrer comment faire tourner une application monolithique dans Docker, puis dans Kubernetes, en quelques lignes de Yaml. Dans un second temps, il va utiliser la puissance du pattern Facade pour faciliter le décommissionnement ; notamment, comment l’utilisation du service mesh Istio peut nous faire gagner rapidement plein de fonctionnalités ultra puissante (monitoring, HTTPS everywhere, rate-limiting, déploiement blue/green, circuit-breaker) entre ses différents services exposés dans Kubernetes. Une présentation rudement menée qui donne envie de s’y mettre (quand bien même on ne fait pas de legacy) !

CANAL+ TECH 📺📱🎬

@canaltechteam

Retour à la tech : transformer une appli legacy avec #Kubernetes et #Istio avec @dgageot #DevoxxFr

10:53 AM - 19 Apr 2018

0 1

La plus mutualiste ⛩

Alexandre Delègue, Matthieu Ancelin et Francois Desmier nous racontent comment la MAIF a décidé de reconstruire son S.I de 0, et nous présenter les résultats de ce travail. Avec à la clé déjà 2 produits prometteurs open-sourcés, Otoroshi & Izanami, une méthodologie et des principes forts symbolisés par des cartes à jouer, et encore plein de choses à faire. Un exemple à suivre ?

Open Source à la MAIF : genèse et ambition

La plus barbue 🎅🏻

Quentin Adam & Clément Delafargue, C[E|T]O chez CleverCloud viennent nous parler de leurs expérimentations pour la mise en place de métriques sur leur plateforme. Les principales difficultés résultent de la méconnaissance des applications à superviser, et le volume potentiel de données à stocker, ils ont buttés sur la plupart des solutions du marché (InfluxDB, Prometheus) avant de découvrir Warp10. De leurs expérimentations sont ressorties la solution metrics en cours de déploiement chez Clever, ainsi que des projets open-source en collaboration avec OVH (poke.digital notamment). Et un utile rappel que, malgré la hype #serverless, nous vivons toujours dans un monde plein de serveurs !

Erwan Deruelle

@d3rwan

Pour finir en beauté, @waxzce et @clementd viennent nous expliquer comment monitorer l’inconnu. #devoxxFR

15:29 PM - 20 Apr 2018

1 10

La plus personnelle 😊

J’ai eu le plaisir et l’honneur cette année encore d’être speaker à Devoxx France. Et j’en profite ici pour remercier les gens qui sont *derrière la scène *pour l’énorme travail qu’ils réalisent chaque année. Tout en espérant avoir convaincu mes spectateurs d’arrêter d’utiliser les injections par champ!

Erwan Deruelle

@d3rwan

Les slides de ma présentation "Pourquoi vous devriez arrêter les field injection" à @DevoxxFR sont disponible ici : speakerdeck.com/d3rwan/pourquo…
#StopFieldInjection #DevoxxFR

12:35 PM - 20 Apr 2018

1 8

Evidemment, ce retour ne peut être que partiel étant donné le nombre de talk auquel je n’ai pas assisté (sachant qu’on parle de 200 conférences sur 3 jours!), mais n’oubliez pas que l’ensemble des talks de cette année sont dès à présent disponible en ligne.Et à l’année prochaine! 😉

DevoxxFR

@devoxxfr

Save the date. #devoxxfr 2019 aura lieu les 17, 18 et 19 avril 2019

06:44 AM - 20 Apr 2018

70 92

Régnez sur vos APIs avec Kong

Erwan Deruelle — Sat, 11 Feb 2017 12:00:00 +0000

Mashape est un catalogue public d’API, permettant à ses utilisateurs de partager ses APIs ou d’utiliser celle des autres. Afin de sécuriser et gérer ces quelques 15000 micro-services présents dans leur catalogue, Mashape a crée Kong, une solution d’API management.

Kong est une solution open-source basée sur NGinx, qui permet de répondre aux contraintes des milliards de requêtes par mois que doit gérer Mashape.

Kong s’appuie également sur une base de données Cassandra (possibilité d’utiliser PostgreSQL), ainsi que sur un ensemble de plug-ins. Par défaut, la solution offre déjà un socle de modules permettant l’authentification, la sécurité, le rate-limiting ou encore la supervision. Il vous sera également possible si besoin de créer vos propres plug-in (cf. la documentation officielle)

Dans votre infrastructure, l’API manager se place en amont des services à exposer (approche reverse-proxy), et prendra en charge les fonctionnalités que vous lui déléguez. Dès lors, chacun de vos services métiers n’aura plus à gérer ces taches techniques et pourra se concentrer sur son coeur métier.

Architecture Legacy vs. Architecture orientée API

Alors, que vous deviez gérer un ensemble de micro-services, une API qui commence à devenir populaire ou simplement un backend web/mobile, il est peut-être temps de commencer à gérer vos APIs.

Getting started

Dans cette partie, nous utiliserons comme API partenaire celle exposée par le site http://anapioficeandfire.com/ et qui expose les données relatives à l’univers de Game of Thrones.

Pour déployer Kong, nous utiliserons des conteneurs Docker orchestrés par docker-compose. La configuration de la stack est la suivante :

Démarrer la stack

Depuis le répertoire contenant le fichier docker-compose.yml décrit précédemment

    # run (daemon)
    docker-compose up -d
    # show logs
    docker-compose logs -f

Une fois la stack démarrée, nous pouvons accéder à ses différents composants

localhost si vous utilisez Docker sous Mac ou Linux, l’adresse de docker-machine sinon

API Manager - localhost:8001
- API grâce à laquelle nous allons administrer Kong
API Gateway - localhost:8000
- API grâce à laquelle nous accéderons à nos API
Kong Dashboard - localhost:8080
- IHM open-source qui utilise l’API d’administration afin d’offrir une interface d’administration

A présent, nous allons pouvoir utiliser notre API manager.

Dans la suite de l’article, nous directement l’API via des appels REST, mais nous pourrions également utiliser l’IHM de Kong Dashboard pour configurer Kong

How to

Créer une API

curl -i -X POST http://localhost:8001/apis/ \
 --data 'name=GOT' \
 --data 'upstream_url=http://anapioficeandfire.com/api/' \
 --data 'request_path=/got/' \
 --data 'preserve_host=false'\
 --data 'strip_request_path=true'

On crée une API qu’on appelle GOT et qui pointe vers notre API partenaire, sur le path /got/ de notre API gateway. On peut désormais y accéder via l’API gateway

curl -i -X GET http://localhost:8000/got/characters/583

Activer l’authentification

curl -i -X POST http://localhost:8001/apis/GOT/plugins/ \
  --data 'name=key-auth' \
  --data 'config.key_names=apiKey'

On associe le plugin key-auth de Kong à notre API qui ne sera donc plus accessible sans token d’authentification

curl -i -X GET http://localhost:8000/got/characters/583

Ajouter un utilisateur

curl -i -X POST http://localhost:8001/consumers/ \
  --data "username=erwan"

Autoriser ce nouvel utilisateur à accéder à l’API

curl -i -X POST http://localhost:8001/consumers/erwan/key-auth \
  --data "key=secret"

Notre API est donc bien sécurisée, et seulement accessible avec la clé d’authentification

curl -i -X GET [http://localhost:8000/got/characters/583](http://localhost:8000/got/characters/583)
curl -i -X GET [http://localhost:8000/got/characters/583](http://localhost:8000/got/characters/583)?apiKey=secret

Activer le rate-limiting

curl -X POST http://localhost:8001/apis/GOT/plugins \
  --data "name=rate-limiting" \
  --data "config.hour=2"

Notre API est à présent limitée à 2 appels par heure.

curl -i -X GET http://localhost:8000/got/characters/583?apiKey=secret
curl -i -X GET http://localhost:8000/got/characters/583?apiKey=secret
curl -i -X GET http://localhost:8000/got/characters/583?apiKey=secret

L’accès à notre API peut à présent se faire via notre API manager après seulement quelques minutes de configuration. Grâce à Kong, on pourra par la suite ajouter des contraintes d’accès, des règles de réécriture de requêtes ou encore du monitoring sans devoir modifier notre coeur métier, ou demander à nos partenaires de le faire.

N’hésitez pas non plus à parcourir le site de Kong, et sa documentation plutôt complète pour voir tout ce qu’il pourrait faire pour vous.

Site officiel - https://getkong.org/

Par ailleurs, vous pourrez retrouver la configuration décrite précédemnt directement sur ce repo github

Et devenez le king de vos API’s!

Yarn, un n-ième package-manager ?

Erwan Deruelle — Thu, 10 Nov 2016 12:00:00 +0000

Npm, Bower, JSPM… A chaque saison son nouveau package-manager dans l’écosystème JS. Le dernier né, Yarn, a été annoncé il y a quelques semaines par les développpeurs de Facebook. Alors, qu’est-ce que se cache vraiment derrière ce n-ième package-manager ?

Yarn: A new package manager for JavaScript

En premier lieu, Yarn n’a pas l’objectif de remplacer npm ou bower. Il s’agit avant-tout d’un nouveau client ligne de commande permettant la récupération de dépendances depuis le registry npm.

Il propose en outre les améliorations suivantes :

Performance Optimisation des appels et maximisation de l’utilisation réseau, notamment via un mécanisme d’analyse de l’arbre des dépendances et de parallélisation des requêtes (vs. en série pour npm)
Déterministe Pour un même projet, les mêmes dépendances seront installées de la même manière sur tous les environnements (plus d’effet “ it works on my machine”)
Fonctionnement offline Une fois un package installé, il est mis en cache et pourra être installé ensuite sans connexion internet
Résilience Le processus d’installation est plus robuste, notamment dans le cas de coupure réseau (rejeu des requêtes vs. processus d’installation en erreur)
Registre multiple Possibilité de récupérer des sources depuis plusieurs registres (npm, bower, github, …)
Sécurité Utilisation de checksums pour vérifier l’intégrité des dépendances

Mise en place

Pour installer Yarn, le plus simple est encore d’utiliser… npm.

npm install -g yarn

Dès lors, on peut utiliser le client yarn en lieu et place du client npm

# npm install
yarn

# npm init
yarn init

# npm install angular --save
yarn add angular 

# npm install gulp --global
yarn global agg gulp

# npm uninstall angular --save
yarn remove angular

# npm install angular-mocks --save-dev
yarn add angular-mocks --dev

Installation avec Yarn

Pour le reste, on continue d’utiliser le fichier package.json pour lister les dépendances d’un projet, dépendances qui seront toujours stockées dans le répertoire node_modules. Yarn ajoute néanmoins un nouveau fichier yarn.lock. C’est ce fichier qui va garantir l’installation déterministe, puisqu’il va lister chaque dépendance, la version exacte à utiliser, l’ordre d’installation etc… Ce fichier sera crée lors de la première installation par Yarn, puis mis à jour ensuite lors de chaque modification.

Il est important de noter que ce fichier doit être présent sur chaque environnement afin de garantir une installation déterministe , et donc qu’il doit être versionné.

Et les perfs dans tout ca ? Sur un benchmark sur le site de Yarn (donc probablement hyper objectif), les chiffres sont là. C’est vachement plus rapide dans la plupart des cas.

Benchmark NPM / YARN (source: https://yarnpkg.com/en/compare)

Et en réalité ?

Pour comparer les performance entre les deux outils, j’ai utilisé l’utilitaire npmvsyarn qui permet de comparer pour une librairie ou un projet (contenant un package.json) donnés les performances entre l’utilisation de npm & celle de Yarn.

Exemple avec les librairies Angular & React

Concernant l’ajout/suppression d’une librairie seule, Yarn est effectivement plus rapide (jusqu’à 50%), en particulier lorsque le cache et le fichier yarn.lock existe.

Exemple avec un projet React (redux-webpack-es6-boilerplate) et un projet Angular (angular1.4-ES6-material-webpack-boilerplate)

Sur un projet complet, Yarn s’en sort mieux également (jusqu’à 2.5 fois plus rapide). Là encore, on voit que la présence du cache et du yarn.lock améliore d’autant plus les performances.

Bien évidemment, ces exemples sont trop limités pour être représentatifs. Néanmoins, le site berriart.com propose un benchmark plus complet des deux outils sur différents environnements d’intégration continue.

NPM vs Yarn benchmark

Là encore, les résultats vont dans le même sens:

Yarn est entre 2x et 3x plus rapide que npm

Conclusion

Après quelques heures d’utilisation, Yarn semble répondre aux attentes qu’il a suscité: plus rapide que npm, avec des fonctionnalités équivalentes, et une migration sans heurts.

Bien qu’il soit sans doute peut-être un peu tôt pour l’utiliser sur un projet structurant en production, il semble dès aujourd’hui être une alternative crédible au client npm par défaut. On pourra donc facilement l’utiliser sur un nouveau projet ou un projet annexe, afin de confirmer toutes les bonnes prédispositions affichées.

Quant au futur, on ne peut qu’espérer qu’il permette l’amélioration de l’existant, que se soit en poussant à l’amélioration de npm ou en devenant un standard defacto. A moins qu’un petit-nouveau n’arrive d’ici là, et change encore la donne…

Une stack ELK from scratch avec Docker

Erwan Deruelle — Wed, 28 Sep 2016 12:00:00 +0000

Ou comment déployer une architecture de monitoring en quelques minutes.

Mo-ni-to-rer

En quelques années, le monitoring est devenu une activité indispensable dans le monde de l’IT. Qu’il soit technique ou fonctionnel, qu’il fournisse des métriques, charts, ou autres KPI, le monitoring de son système est devenu un must-have.

Dans la suite de l’article, nous allons voir comment déployer une architecture de monitoring à partir de zéro, en quelques minutes, grâce à Docker.

La stack

Pour commencer, nous nous appuyerons sur la stack ELK qui, en quelques années, est devenue une alternative crédible aux autres solutions de monitoring (Splunk, solutions SAAS…).

Elle se compose des éléments suivants:

E comme Elasticsearch, le moteur d’indexation, de recherche & d’analytics,
L comme Logstash, un ETL permettant de récupérer les données dans des sources hétérogènes, les transformer et les envoyer vers Elasticsearch,
K comme Kibana, un IHM de visualisation et de générations de tableaux de bord interactifs

Nous ajouterons également :

R comme *Redis, *utilisé comme broker en amont, qui servira de buffer en cas de latence du système, tout en évitant un engorgement trop important en cas de pic,
C comme Curator, un outil de management des indexs
**B *comme *Beats, sondes à installer côté client afin d’envoyer les logs/métriques à notre stack

Notre stack de monitoring

Déploiement

Nous utiliserons des conteneurs Docker pour chacun des composants de notre stack.

Elasticsearch, dans sa version 5.1.2,
Logstash, dans sa version 5.1.2,
Kibana, dans sa version 5.1.2,
Redis, dans sa version 3.2.6,
Curator, dans sa version 4.0.4

L’ensemble des services et des interactions sont décrites dans un fichier docker-compose.yml:

Pour chacun des services, on va définir si besoin les ports à exposer ou les volumes à utiliser (notamment les fichiers de configuration). Un exemple de configuration viable est disponible sur mon compte github : docker_elk_stack.

Hello, world

En se basant sur ce repository, nous allons déployer une stack fonctionnelle:

# clone repo & build images
git clone [https://github.com/d3rwan/docker_elk_stack](https://github.com/d3rwan/docker_elk_stack)
cd docker_elk_stack
docker-compose build

# run (daemon)
docker-compose up -d

# show logs
docker-compose logs

Une fois les différents composants démarrés, vous devriez pouvoir accéder à l’interface Kibana (port 5601).

Puis nous allons lancer un example d’application web (site HTML statique exposé par Nginx, ainsi qu’une sonde FileBeat permettant l’envoi des logs vers notre stack ELK)

# build image
docker build ./webapp -t dockerelkstack_webapp

# run (daemon)
docker run --network dockerelkstack_logging --link redis:redis -p 80:80 -d --name webapp dockerelkstack_webapp

# show logs
docker logs webapp

Une fois notre composant démarré, vous devriez pouvoir accéder à l’application web (port 80).

Exemple d’application web (source: https://github.com/sbilly/joli-admin)

Après avoir navigué quelques minutes, en retournant sur l’IHM de Kibana, un index logstash-* est à présent disponible.

Kibana : écran de configuration d’un pattern d’index (ici, l’index logstash-* est détecté)

Après avoir crée notre pattern d’index, nous pouvons à présent naviguer dans les logs de notre application web (onglet Discover), créer des visualisations (onglet Visualize) et des tableaux de bord (onglet Dashboard)

Kibana: Visualisation brute des logs de notre application web

Kibana: Tableau de bord analytique

And… voilà! Nous avons donc mis en place, en quelques minutes seulement, une stack de supervision opérationnelle.

An ELK stack from scratch, with Docker

Erwan Deruelle — Wed, 28 Sep 2016 12:00:00 +0000

Or how to deploy a complete monitoring architecture in few minutes.

Monitor

In few years, monitoring has become an indispensable activity in the IT world. Technical or functional, whether it provides metrics, charts, or other KPIs, monitoring its system has become a must-have.

In the rest of the article, we will learn how to deploy a monitoring architecture from scratch, in few minutes, thanks to Docker.

The stack

First off, we will use the ELK stack, which has become in a few years a credible alternative to other monitoring solutions (Splunk, SAAS …).

It is based on the following software:

E as Elasticsearch, search engine which provide full text search & analytics,
L as Logstash, an ETL for retrieving data from heterogeneous sources, transforming them and sending them to Elasticsearch,
K as Kibana, which provide an UI for exploring data, and create interactive dashboards

But also :

R as *Redis, *an upstream broker which will serve as buffer in case of latency of the system, while avoiding excessive congestion in case of a peak,
C as Curator, a tool to manage our index
**B *as *Beats, client-side agent to send the logs/metrics to our stack

The complete architecture

Deploy

We will use Docker containers for each stack component.

Elasticsearch (5.1.2),
Logstash (5.1.2),
Kibana (5.1.2),
Redis (3.2.6),
Curator (4.0.4)

Services and interactions are described in a docker-compose.yml file:

A viable configuration is also available on my github account : docker_elk_stack.

Hello, world

Based on this repository, we will deploy a functional stack:

# clone repo & build images
git clone [https://github.com/d3rwan/docker_elk_stack](https://github.com/d3rwan/docker_elk_stack)
cd docker_elk_stack
docker-compose build

# run (daemon)
docker-compose up -d

# show logs
docker-compose logs

After startup, you should be able to access Kibana (port 5601).

Then, we will deploy a basic example web app (NGinx serving HTML + Filebeat agent to send log in our stack)

# build image
docker build ./webapp -t dockerelkstack_webapp

# run (daemon)
docker run --network dockerelkstack_logging --link redis:redis -p 80:80 -d --name webapp dockerelkstack_webapp

# show logs
docker logs webapp

After startup, you should be able to access the web app (port 80).

Example web app capture (source: https://github.com/sbilly/joli-admin)

After few minutes browsing, returning to Kibana. An index (logstash-*) is now available.

Kibana: Index pattern configuration screen (here, logstash-* index is available)

After creating index, we can now exploring our web app logs (Discover tab), create visualizations (Visualize tab) and dashboards (Dashboard tab).

Kibana: Exploring the raw logs

Kibana: Analytic dashboard

And… voilà! In just few minutes, we set up, an operational monitoring stack.