Pi-hole est un projet open-source prévu pour tourner sur un raspberry pi, qui permet de filtrer les requêtes DNS dans le but de bloquer les publicités et le tracking. L’idée est de faire ce filtrage au niveau du réseau afin de pouvoir bloquer aussi les publicités dans les applications et sur les navigateurs mobiles qui n’ont pas forcement d’Adblock.
Pour mon installation j’ai ressorti un vieux raspberry 1 b+ et j’ai utilisé l’installation recommandé sur le site:
curl -sSL https://install.pi-hole.net | bash
Avant de lancer la commande, pensez-bien à vérifier le script.
Par la suite j’ai laisser tout les paramètres à leurs valeurs par défaut.
Sur ma box j’ai fixé une IP fixe pour le raspberry (192.168.1.254).
Une fois l’installation terminé l’interface web est accessible à l’URL http://192.168.1.254/admin. A la fin de l’installation un mot de passe vous a été donné. Mais si vous l’avez perdu vous pouvez le réinitialiser via la commande:
pihole -a -p
Maintenant il ne reste plus qu’à utiliser notre nouveau serveur DNS en tant que DNS primaire.
Si comme moi vous avez une livebox, vous allez être heureux d’apprendre que vous ne pouvez pas/plus changer les DNSs au niveau de la box. J’ai donc coupé le wifi de la livebox et ajouté un routeur wifi qui lui va me servir de DHCP et qui va s’occuper de résoudre les requêtes DNS en passant par pi-hole.
Si vous ne souhaitez pas ajouter un routeur WIFI, et que ne vous ne pouvez pas modifier les DNS de votre box, il faudra modifier manuellement les DNS sur chaque PC, téléphone et tablette. (c’est vraiment pas idéal)
Après quelques heures d’utilisation j’ai constaté que 15% des resolutions DNS qui sont fait dans le cadre d’une navigation classique sont vers des sites de tracking ou de publicité. Je suis franchement surpris car je m’attendais à bien pire…
Il possible d’ajouter manuellement ou via un fichier accessible en HTTP des domaines à bloquer/autoriser.
En quelques minutes d’installation, grace à pi-hole, il est possible de limiter le tracking est la publicité pour l’intégralité de votre réseau local. Simple mais efficace.
Si on veux aller un peux plus loin dans le blocage ont peux ajouter des listes de noms de domaines maintenues par la communauté. Avec cette liste vous passerez à plus de 600 000 domaines de bloqués.
Pour les ajouter il faut se rendre dans Settings > Blocklists et il faut simplement coller la liste des listes de domaines tel quel dans le champs text et enregistrer.
Petit test de navigation sur mon téléphone avec et sans pi-hole:
Il existe plusieurs solutions open sources ou hébergées pour monter sa propre architecture serverless. J’ai choisi de tester les deux solutions open sources plus populaires, ainsi que deux des plus gros acteurs actuellement sur le marché afin de me faire une idée du fonctionnement de chaque solution. Je vais déployer un simple hello world sur l’ensemble des outils afin de tester l’utilisation et les temps de réponses.
Je ne connais aucunes des solutions, mais je vais me faire mon analyse autour des 5 points suivants :
Est-ce qu’il est possible d’avoir une solution hautement disponible ?
Est-ce qu’il y a un engouement autour de la solution ? (articles, conf, contributions)
Est-ce que c’est simple à utiliser pendant les développements ?
Est-ce que la solution est scallable ?
Est-ce que c’est utilisable/utilisé en prod ?
Pour les solutions hébergées je vais toujours prendre, si possible, un datacenter proche de la France. Pour les solutions open sources je vais utiliser un serveur Scaleway hébergé en France avec 4 coeurs, 4 Go de ram et 300Mo/s de bande passante entièrement dédiée au test. Chaque test sera fait sur une installation « propre » de Debian Stretch.
Bien évidement il y a d’autres facteurs qui entrent en jeux avant de choisir un solution plutôt qu’une autre tel que les SLA en cas de problème, la fiabilité du partenaire (Est-ce qu’il sera toujours présent dans 5 ans ?), le pays dans lequel les serveurs sont hébergées… Mais dans le cas présent je m’intéresse surtout à la fiabilité du service et je n’ai ni impératifs de production ni données sensibles à hébergées.
A la suite du test je choisirais une solution pour construire une petite application.
Amazon Lambda
Présentation
Le plus célèbre acteur du marcher est Amazon avec ses lambdas functions. Ce qui est vraiment pas mal avec cette solution c’est que pour un petit projet vous pouvez vous en sortir sans rien avoir à payer car le premier million de hit est gratuit.
Il y a plusieurs version de java, node, python et .Net de supportées par Amazon Lambda.
Mise en place
Les fonctions lambda sont intégrées à la solution AWS et peuvent être lancées par beaucoup d’évènements différents. Dans mon cas ce qui m’intéresse c’est les fonctions lambda déclenchées par une API Gateway. Il n’y a aucunes installation à faire avant de pouvoir les utiliser.
Hello world
Cette lambda est un bête hello world :
Développement /Déploiement
Une fois enregistrée ma lambda est automatiquement disponible via HTTPS sur une URL unique. Il est possible d’activer ou non une couche d’authentification, mais pour mon hello world je ne vais pas la mettre en place.
Via le framework serverless, dont je parlerais dans un prochain article, le déploiement / mise à jours peux se faire en ligne de commande en quelques secondes.
Benchmark
Je vais lancer un petit benchmark dessus pour voir les temps moyens de réponses sur un hello world.
➜ ~ ab -n 1000 -c 10 https://XXXXXXXXXX.execute-api.eu-central-1.amazonaws.com/default/test
[...]
Concurrency Level: 10
Time taken for tests: 16.969 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 305000 bytes
HTML transferred: 19000 bytes
Requests per second: 58.93 [#/sec] (mean)
Time per request: 169.686 [ms] (mean)
Time per request: 16.969 [ms] (mean, across all concurrent requests)
Transfer rate: 17.55 [Kbytes/sec] received
[...]
Les temps de réponses ne sont vraiment pas mauvais, en moyenne 58 requêtes par seconde.
Conférences
Une conférence en français d’amazon présente assez bien les fonctions lambda :
Ce qui est très sympa avec cette solution c’est que c’est clef en main. On a plus qu’à se concentrer sur notre application en s’abstrayant de la partie gestion des serveurs et de la problématique de haute disponibilité.
Cloud function Google
Présentation
Google, second grand acteur du serverless avec ses cloud function propose aussi un « forfait » gratuit pour les deux premiers millions d’appel.
Tout comme amazon lambda il est possible de créer et d’administer ses lambda via la console web. Il faut patienter une bonne minute entre le moment ou on crée une fonction et le moment ou elle est mise à disposition. Tout comme les lambdas d’amazon il est possible de déclencher les Cloud functions via des évènements autres que HTTP (ex: modification dans une base firebase).
Mise en place
Il n’y a rien de spécifique à faire à part avoir un compte google développeur.
Hello world
Voici le code de ma cloud function :
Développement / Déploiement
De même que pour Amazon Lambda le framework serverless va permettre de travailler avec Google Cloud function.
Ce qui est vraiment un plus, non négligeable, c’est qu’il est possible de lancer les fonctions en locale avec l’emulateur node js pour google cloud.
Benchmark
➜ ~ ab -n 1000 -c 10 https://europe-west1-XXXXXXX-XXXXX.cloudfunctions.net/function-1
Concurrency Level: 10
Time taken for tests: 15.187 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 361008 bytes
HTML transferred: 11000 bytes
Requests per second: 65.85 [#/sec] (mean)
Time per request: 151.870 [ms] (mean)
Time per request: 15.187 [ms] (mean, across all concurrent requests)
Transfer rate: 23.21 [Kbytes/sec] received
Google Cloud function ne support que du python 3.7 et du node js 6 et 8.
Apache OpenWhisk
Présentation
OpenWhisk est la solution open source serverless de la fondation apache. Il est possible mettre en place cette solution sur du kubernates, du mesos ou simplement via docker-compose.
Le support des langages est assez étendu pour les fonctions hébergées sur la solution. Il y a notamment Nodejs, python, PHP, java, Go …
Les fonctions, appelées Actions, peuvent être déclenchées par des évènements (trigger), des appels HTTP ou encore via des modifications sur un flux d’information (feed).
Mise en place
J’ai suivi la documentation pour une installation docker compose. Malgrès plusieurs tentative je n’ai jamais réussi à faire tourner OpenWhisk sur mon serveur. Le script d’install a crashé de multiples fois sur des étapes différentes et la seule fois (sur 7) ou il n’a pas crashé pendant les install il n’a pas réussi à configurer le client car la stack ne renvoyait que des 500.
J’ai donc décidé de tester sur mon macbook pro 2017. Sur le mac je n’ai eu aucun problème à l’installation.
Hello world
function main() {
return {payload: 'Hello world'};
}
Développement /Déploiement
Un client en ligne de commande est disponible pour gérer les functions déployées. Il est donc assez simple et rapide de mettre à jours une fonction pour la tester.
J’ai eu beaucoup de difficultés pour trouver l’URL pour appeler ma fonction, les crédentials pour m’authentifier sur le endpoint (une fois trouvé).
Benchmark
Le benchmark n’a pas de sens car l’éxecution se fait sur mon mac dans la docker machine. En moyenne les temps de réponses étaient aux alentours de 150ms.
OpenFaas
Présentation
OpenFaas est une solution opensource basée sur des orchestrateurs docker. Pour mon test je vais utiliser swarm avec un seul node. OpenFaas vient par défaut avec une interface web d’administration, une installation prés-configurée de prometheus afin de collecter des metrics sur la plateforme.
OpenFaas permet de créer des fonctions dans divers langages (Go, Python, Node, Ruby, Java…) mais aussi faire une passerelle entre OpenFaas et des binaires. La solution propose aussi un support des lambdas d’amazon.
La documentation est centralisée et assez complète. On peux y trouver beaucoup d’exemple sur l’ensemble des langages supportés.
Ce qui est important de noter c’est qu’il est possible de déployer openfaas sur des serveurs ARM (Raspberry par exemple).
Mise en place
L’installation sur un docker swarm se fait en moins d’une minute en lancant le script présenter dans la documentation. Pour intéragir avec openfaas il client en ligne de commande est disponible en plus de l’interface web.
Chaque fonction est une image docker qui doit être présente sur un registry docker.
faas new hello-world --lang node --gateway http://51.15.84.114:8080
# coder la fonction dans le fichier hello-world/handler.js
faas build -f hello-world.yml
faas push -f hello-world.yml
faas deploy -f hello-world.yml
Benchmark
➜ ab -n 1000 -c 10 http://51.15.84.114:8080/function/hello-world
Concurrency Level: 10
Time taken for tests: 49.517 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 257000 bytes
HTML transferred: 26000 bytes
Requests per second: 20.20 [#/sec] (mean)
Time per request: 495.166 [ms] (mean)
Time per request: 49.517 [ms] (mean, across all concurrent requests)
Transfer rate: 5.07 [Kbytes/sec] received
Conférences
J’ai aussi regardé du côté de Iron-io mais la solution, bien qu’elle fournisse un interface HTTP, semble plus axée sur les traitements asynchrones. Ce n’est pas spécialement ce qui m’intéresse. Mais pour du traitement de masse comme du travail sur des images, de l’envoie de mail… c’est une solution à explorer.
Résultat du comparatif
[table id=3 /]
OpenFaas est une solution très interessante qu’il faut surveiller mais qui, pour le moment ne me paraît pas être encore assez mature pour héberger une application de production.
Actuellement je dirais que Amazon lambda est la solution la plus fiable/stable/simple car elle est très bien intégrée à l’environnement AWS, il y a une bonne documentation, elle s’appuie sur l’expertise d’un des leaders sur le sujet de l’hébergement.
Le serverless, je ne connais pas du tout. L’idée est de faire une série d’articles découvertes sur cette architecture. L’idée est d’aller jusqu’à la création d’une petite application.
Serverless – Google trand
Depuis deux ans on parle de plus en plus de serverless mais il n’est pas toujours simple de voir exactement de ce que cela implique pour une application d’être serverless. Autre point, est-ce qu’être serverless implique qu’il n’y ait pas de serveur du tout ?
Les principes du serverless
Le serverless est une nouvelle façon d’héberger ses applications. Avec docker et des orchestrateurs comme kubernetes il est possible de faire de l’auto-scalling pour adapter le nombre d’instances d’une application en fonction de l’utilisation de l’application. M6 Web a d’ailleurs fait un retour d’expérience d’auto-scalling via la mise en place de kubernates.
Le serverless est l’étape suivante de l’auto-scalling tout en apportant une approche micro-service. Quand personne ne va utiliser une application, il n’y aura aucune instance qui tourne (selon les solutions). Et c’est seulement au premier hit que l’application sera bootée. En fonction du nombre d’appels, il y aura plus ou moins d’instances qui tourneront en même temps. L’application est donc fortement liée au backend utilisé.
Cette approche permet, selon la solution choisie, de limiter les coûts d’hébergement car les providers (Amazon, Google, Microsoft,…) facturent l’hébergement à la seconde, ou même au centième de seconde d’exécution. Si personne n’utilise l’application, les coûts d’infrastructure seront quasiment nuls.
Et c’est bien là, la force de cette approche. Quand on loue des serveurs à l’année on est obligé de payer pour un nombre de serveurs permettant d’absorber les pics maximum de charge. Le reste du temps les serveurs sont sous-exploités.
La rapidité
Le serverless n’est possible que si on est capable de démarrer un service rapidement. Si l’application met 30 secondes à démarrer, il faudra toujours conserver au moins une instance de disponible. A ce moment là on en revient à une solution d’autoscalling classique.
La fiabilité
La mise en place d’une architecture serverless déporte une partie de la complexité de l’application sur l’infrastructure qui va orchestrer nos fonctions. Il est donc primordial qu’elle soit fiable et résiliante. Il est donc préférable, pour une application de production d’utiliser une solution hautement disponible (HA).
La scallabilité
Par nature une architecture serverless est scallable car elle va devoir instancier à la demande des applications. Mais pour que ce soit possible il faut que l’infrastructure l’autorise (allocation/ libération de ressources à la volée).
Le nouveau paradigme
Cette infrastructure impose que chaque fonction soit stateless, mais vous avez la possibilité d’interagir avec d’autres services comme des bases de données ou des APIs.
Le développeur est pleinement conscient du fonctionnement de l’infrastructure. Comme on l’a vu précédemment, la frontière est mince entre l’application et la solution d’hébergement.
Cette façon de travailler permet, en théorie, de réduire le temps de déploiement d’une fonctionnalité car la complexité de chaque fonction est plus faible que celle d’une application monolithe. Néanmoins le risque est d’avoir autant de façons de faire que de fonctions hébergées. Comme chaque développeur va pouvoir travailler « dans son coin » en faisant fi de l’existant, les dérives et les mauvaises pratiques sont vites arrivées. Il y a, à mon avis, un besoin de revue de code et de tests encore plus important sur ce type d’architecture.
Le dernier point et que l’on peut avoir un langage commun sur les problèmes de performance avec la hiérarchie. Comme chaque seconde de traitement augmente la facture, il est plus simple de mettre en avant des projets techniques d’optimisation. Un temps de traitement divisé par deux c’est une fonctionnalité qui coûte deux fois moins cher. Ce n’est pas réellement le cas sur une application classique.
En conclusion, le serverless est une nouvelle approche sur la façon de concevoir une application en poussant au maximum les approches devops et micro-services afin de concevoir une application hautement scallable tout en maîtrisant les coûts.
