Comment fonctionne l’e-reputation ?

Lancer une activité ou créer votre société n’est pas toujours facile. En effet, outre sa création, il est aussi essentiel de maintenir la réputation et la notoriété de votre société. Cela permettra de vous faire connaître davantage afin d’attirer plus de clients. Depuis quelque temps, les outils digitaux ne cessent de connaître des évolutions si bien que les notions de notoriété et de réputation d’une entreprise se propagent aussi dans le monde virtuel. Alors, comment cela fonctionne et pourquoi est-ce si important ?

Qu’est-ce que l’e-réputation ?

Souvent confondue avec l’e-notoriété, l’E-réputation se concentre surtout sur l’opinion publique en ligne. Une entreprise peut être connue (c’est-à-dire avoir une certaine notoriété), mais l’E-réputation permettra de savoir si elle a une bonne image ou non.

En général, votre e-réputation est déterminée par les contenus diffusés par les utilisateurs sur des blogs, des réseaux sociaux ou des forums. Elle constitue plus de 75% des informations sur une marque ou une entreprise. C’est-à-dire que la majorité de ce qui est dit à propos d’une marque ne vient pas de la marque elle-même, mais des internautes.

Ainsi, gérer votre e-réputation est indispensable, car, combinée avec l’E-notoriété, elles formeront votre identité numérique. En général, avant de pratiquer un achat de service ou avant de consommer une marque, les prospects vérifient tout d’abord sur les différents moteurs de recherche. Ils auront alors un aperçu général des avis des internautes et pourront décider si oui ou non, ils vont s’en tenir à la marque.

Comment améliorer votre e-réputation ?

User du SEO pour assurer votre e-réputation

Le référencement naturel peut jouer grandement sur votre e-réputation. En fait, lorsque la visibilité de votre marque ou votre société est plus claire au niveau des moteurs de recherche, cela aura un impact sur votre image. Donc, plus votre site ou page web monte en visibilité, plus votre image sera consultée par les internautes.

Effectivement, les internautes ont souvent tendance à faire des recherches et ne lire que les liens en première page des résultats de recherche. Les contenus en tête joueront donc sur la construction de l’image d’une entreprise ou d’une marque. Voilà pourquoi il est essentiel d’assurer le référencement naturel de vos contenus.

Gérer les clients mécontents

Généralement, les clients satisfaits sont les plus silencieux sur internet. Les clients mécontents, quant à eux, sont les plus actifs et font des retours par rapport à leur mésaventure. Ainsi, afin de mieux gérer les avis négatifs des clients, la réactivité est de mise.

Pour assurer une réactivité instantanée de votre marque, nous vous conseillons de former une équipe chargée de la veille. Cette dernière effectuera alors les veilles digitales pour votre marque afin que vous puissiez réagir rapidement aux commentaires désagréables des internautes. Il est essentiel de savoir que : plus vite vous réagissez, moindre sera le risque que le client en fasse une tonne.

Bref, comme tout se passe actuellement en ligne, garder une certaine E-réputation est important pour assurer une bonne image de la marque. Il est à savoir qu’une E-réputation est principalement basée sur vos clients. Ainsi, outre les activités web que vous pouvez réaliser, bien gérer les clients constitue un point clé pour garder une bonne image de votre société.

Développer rapidement votre activité grâce au webmarketing

Le développement de votre activité est votre finalité. Créer votre entreprise a été assez facile, mais pour la faire grandir le chemin se révèle compliqué. Faire évoluer votre business plus rapidement nécessite ainsi des plans d’action bien pensés. Je vais donc attirer votre attention sur le webmarketing aujourd’hui, un outil indispensable au fleurissement de votre boîte.

La visibilité sur internet, un levier de croissance à ne pas négliger

Pour faire grandir votre activité à Bordeaux, vous devez être visible et connu. Internet peut vous aider à atteindre cet objectif. D’où le webmarketing. Ce dernier regroupe tous les dispositifs mis en œuvre pour faire la promotion en ligne de votre activité. Pour booster la réussite de votre entreprise, vous devrez penser à vous faire accompagner par une agence de référencement naturel de votre ville, que vous trouverez par exemple sur https://www.adf-referencement-bordeaux.com/ .

Le marketing est incontournable pour promouvoir votre entreprise, vos produits et services auprès des consommateurs. Il est aussi nécessaire pour construire l’image et la notoriété de votre marque. Le marketing vous permet de vous faire connaître, de stimuler vos ventes et d’augmenter vos profits. Ce qui vous conduit au succès de votre activité.

Avec une évolution constante du marché, l’e-marketing s’avère être plus performant que le marketing traditionnel. À travers un affichage publicitaire par exemple, il vous est difficile de connaître avec exactitude le nombre de personnes ayant montré de l’intérêt pour votre offre. Le webmarketing permet en revanche d’atteindre efficacement une cible plus large grâce aux différents canaux pouvant être déployés . Il vous donne la possibilité de mesurer l’impact de vos campagnes publicitaires. C’est également un atout face à la concurrence.

De nos jours, les gens sont ultra connectés. Ils cherchent des informations (idées de vacances, formations…) sur Google, effectuent leur shopping ou encore d’autres opérations sur le Net, comme la recherche d’un plombier et différents services. La visibilité sur internet n’est donc plus discutable ! La stratégie digitale doit faire partie de la stratégie globale de votre startup.

Les enjeux du référencement naturel

Votre site web est enfin créé. Avant d’utiliser d’autres outils pour le développer, vous devrez vous assurer que les fondations de votre site internet soient solides. C’est là qu’intervient le référencement naturel ou SEO. Celui-ci est une arme indéniable du marketing digital. Un meilleur positionnement durable vous permet d’améliorer votre trafic, la prospection, la conversion et la fidélisation de votre clientèle.

Avec les milliers de sites qui se battent pour apparaître dans la première page des résultats Google, ce moteur de recherche est davantage sévère en matière de référencement. Seuls ceux qu’il juge pertinents obtiennent les meilleurs positionnements. Si vous voulez en faire partie, vous devez travailler votre référencement naturel pour optimiser votre présence sur la toile. Pour ce faire, recourir à une agence spécialisée en référencement naturel reste la décision la plus judicieuse.

Élaborer une stratégie webmarketing efficace

Le marketing numérique est un facteur favorisant la visibilité de votre entreprise. Ce n’est pas parce que tous les entrepreneurs se lancent dans la promotion de leur activité en ligne, que vous aussi, vous allez le faire. Cette attitude est contre-productive. Afin de faire prospérer votre business, misez uniquement sur une stratégie personnalisée . C’est de cette façon que vous foncerez vers votre succès.

Chaque enseigne est différente. Ce qui a marché pour les autres ne fonctionnera pas forcément pour vous. Vos plans d’action doivent être en phase avec la situation de votre entreprise et vos objectifs. L’élaboration de votre stratégie digitale gagnante nécessite l’intervention d’un expert. L’appui d’une agence web vous sera donc d’une grande utilité.

Filtrer vos requêtes DNS sur votre réseau local

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:

Sans

Avec

Test des solutions serverless

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

Hello world

"use strict"

module.exports = (context, callback) => {
    callback(undefined, {status: "Hello World"});
}

Développement /Déploiement

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.

C’est quoi le serverless ?

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.

Monter un registry docker privé

Si vous n’avez pas de compte payant sur docker hub mais que vous ne voulez pas publier publiquement une image docker il va falloir trouver des solutions pour pouvoir héberger vos images docker. Par exemple en montant un registry docker privé pour héberger vos images docker.

Dans cet article nous allons voir comment monter un registry docker et comment y accéder en HTTPs sans avoir à déployer de certificat. 

Pour cet exemple je vais utiliser un petit serveur START1-S chez scaleway à moins de 2 euros par mois.

Je préfère avoir de toutes petites instances de serveurs, plutôt que tout avoir sur la même machine. Si jamais une des machines se fait pirater, ou si elle a une panne matérielle, il n’y aura qu’un de mes projets perso qui sera hors ligne.

Installer docker

Dans un premier temps il va falloir installer docker sur la machine. Pour cette étape le mieux est de suivre le tuto présent sur la documentation officielle en fonction de votre OS.

Mettre en place une connexion https

Plusieurs méthodes sont possibles, de la plus simple à la plus complexe. Vous pourrez trouver des tutos pour le faire via du let’s encrypt mais je suis parti sur quelque chose de plus simple. Comme je gère mes DNS avec cloudflare je vais utiliser le SSL flexible.

Ce n’est pas un SSL de bout en bout mais c’est suffisant pour ce que je fais sur domaine lahaxe.fr. Il n’y a en effet aucune donnée critique qui transite dessus.

Créer un sous domaine

Dans le menu DNS il va falloir ajouter une entrée, par exemple dans mon cas « registry.lahaxe.fr« , et la faire pointer vers votre serveur.

Activer le SSL flexible dans cloudflare

Dans le menu Crypto il y a une section SSL. Dans le menu déroulant il faut sélectionner Flexible.

Encore une fois, c’est satisfaisant pour un projet perso, mais ça ne l’est pas pour de la vraie production.

Lancer le registry

Il existe une image officielle pour monter son propre registry. Elle est très sobrement nommé registry

L’image expose le port 5000 mais on va le mapper sur le port 80 afin de profiter du SSL flexible de Cloudflare. 

docker run -d -p 80:5000 
  --restart=always 
  --name registry 
  -v /opt/docker-registry:/var/lib/registry  
  registry:2

Vous pouvez vérifier le bon fonctionnement en consultant l’url https://registry.lahaxe.fr/v2/_catalog (dans mon cas).

A partir de ce moment vous avez un registry fonctionnel mais public. N’importe qui peut pousser et télécharger une image dessus. Nous verrons dans la section « sécuriser le registry » comment mettre en place la sécurité sur le registry.

Uploader une image

Maintenant que nous avons notre registry de disponible nous allons pouvoir lui pousser une image pour nous assurer que tout est bien configuré.

# pull d'une image sur le hub
docker pull alpine

# on re-tag l'image 
docker image tag alpine registry.lahaxe.fr/alpine

# push de l'image sur notre registry
docker push registry.lahaxe.fr/alpine

Sécuriser le registry

Avoir un registry ouvert est une très mauvaise pratique. Afin de le sécuriser un minimum nous pouvons mettre en place deux sécurités de base. 

Filtre par IP

L’idée est de donner les accès seulement à vos serveurs et aux personnes qui doivent interagir avec. Il va donc falloir sécuriser le port 80 de serveur (ou le 443 si vous faites du SSL de bout en bout).

De mon côté je vais utiliser les security policies de scaleway pour bloquer le port. Attention: Il faut bien penser à redémarrer le serveur après avoir changé les règles de firewall scaleway. Mais sinon vous pouvez mettre en place un filtrage via iptable ou via shorewall.

Mettre en place de l’authentification

Dans un premier temps il va falloir générer un fichier htpasswd avec le ou les logins et mots de passes.

mkdir auth

docker run 
   --entrypoint htpasswd 
   registry:2 -Bbn username MySuperP4ssw0rd123 > auth/htpasswd

Il suffit de dire à l’image docker de prendre ce fichier et d’activer l’authentification basique. Il est absolument nécessaire d’être en HTTPS pour cette authentification sinon le mot de passe passera en clair dans les trames HTTP. 

# si vous avez un container qui tourne déjà
docker rm -f registry

docker run -d -p 80:5000 
  --restart=always 
  --name registry 
  -v `pwd`/auth:/auth 
  -e "REGISTRY_AUTH=htpasswd" 
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" 
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd 
  -v /opt/docker-registry:/var/lib/registry  
  registry:2

Sur les pc « clients », votre desktop par exemple, il faudra faire un docker login pour pouvoir utiliser le registry.

docker login registry.lahaxe.fr

Je ne mets pas en place de system de backup sur le registry car je n’en ai pas spécialement le besoin. Je préfère stocker l’ensemble de mes dockerfiles afin de pouvoir les reconstruire en cas de besoin.

Gérer ses tunnels SSH avec Mole

Mole est une application en ligne de commande qui permet de simplifier la création de tunnels SSH.

Il est parfois utile de monter un tunnel pour accéder à un service qui n’est pas ouvert sur le WEB. Par exemple si votre serveur MYSQL, n’est accessible que depuis votre serveur web ou votre serveur de backup. Ou encore pour contourner un firewall qui bloquerait un port en particulier.

Sur cet exemple le serveur bleu ne peut pas accéder au port 80 (application web) du serveur rouge car un firewall le bloque. Mais le port 22 (ssh) est accessible. Il est donc possible de créer un tunnel qui forward le port 80 sur serveur rouge sur le port 8080 du serveur bleu. Une fois le tunnel mis en place il sera possible d’accéder à l’application web du serveur rouge via l’url: http://blue:8080.

Installation

Deux méthodes d’installation sont possibles. Via le script d’installation ou via homebrew pour les utilisateurs de mac.

L’installation via le script :

bash <(curl -fsSL https://raw.githubusercontent.com/davrodpin/mole/master/tools/install.sh)

Je vous invite à vérifier le contenu du script avant de le lancer.

L’installation via homebrew :

brew tap davrodpin/homebrew-mole && brew install mole

Mole est utile car il nous simplifie la syntaxe pour créer un tunnel ssh. En effet il n’apporte rien de plus que de la simplification.

Par exemple la commande suivante, qui permet d’accéder au port 80 local d’une machine :

➜ ssh -L 8080:xxxxx@wordpress:80 root@wordpress

Se transforme en quelque chose de plus simple via mole :

➜ mole -remote :80 -local :8080 -server xxxxx@wordpress

Utilisation

Pour se connecter à un serveur mysql qui n’est pas ouvert sur le web nous allons ouvrir un tunnel entre le port 3306 local du serveur et le port 3307 de mon mac :

➜ mole -v -remote :3306 -local :3307 -server xxxxx@wordpress

Je peux maintenant me connecter au serveur mysql du serveur sur le port 3307 de ma machine :

➜ mysql connect -h 127.0.0.1 -P 3307 -uxxxxxxx -p

Gestion des alias

Le dernier point qui est bien pratique si vous avez à jongler avec plusieurs serveurs c’est la gestion des alias. Il est possible d’enregister des alias pour les tunnels que l’on a fréquemment à créer.

➜ mole -alias wp-mysql -remote :3306 -local :3307 -server xxxxx@wordpress
➜  mole -start wp-mysql

Explorer vos json dans le terminal avec fx

Fx est une application node installable via npm ou yarn qui permet de visualiser et d’interagir avec un json directement dans le terminal.

Ce qui est intéressant c’est qu’il est possible d’explorer le json en précisant un path à afficher.

Voici un exemple sur un fichier package.json :

Il est même possible d’aller un peu plus loin et de lui donner une ou plusieurs fonctions anonymes en paramètre.

Un petit outil sympa qui va vous éviter de copier/ coller votre json dans un IDE pour le remettre en forme et naviguer dedans.

Monter un cluster swarm avec des Raspberry pi et HypriotOS

HypriotOs est une version de raspbian dans laquelle docker, et docker swarm sont pré installés. La particularité est que HypriotOs tourne sur des architectures ARM telles que les Raspberry, le Nvidia shield et quelques autres cartes comme les ODROID C2.

Dans cet article, nous allons voir comment monter un petit cluster swarm avec trois noeuds (1 manager et 2 workers). Une fois la partie serveur montée, nous ferons tourner des services dessus à la fois en lignes de commandes et via une interface graphique.

Swarm

Swarm est l’orchestrateur historiquement intégré dans docker. Il permet de distribuer automatiquement les containers sur l’un ou l’autre des noeuds du cluster en fonction de l’indisponibilité ou de la charge d’un noeud.  Docker inc a été testé pour scal

ler jusqu’à 1 000 nœuds et  50 000 conteneurs sans dégradation de performance. A mon avis nous allons avoir du mal à faire tourner autant de conteneurs sur nos Raspberry.

Il existe deux types de noeuds, les managers et les workers. Pour faire simple, les managers peuvent administrer ce qui tourne sur le cluster et répartir le travail sur les workers tandis que les workers sont de simples exécutants qui lancent des containers.

De base, le cluster va faire du mesh routing. Cela signifie, par exemple, que si vous lancez un serveur web sur le port 80 quelque part sur votre cluster, vous pourrez y accéder en attaquant n’importe quelle machine (worker ou manager) qui compose le cluster. Swarm va aussi nous proposer un système de load balancing afin de pouvoir distribuer la charge entre différentes instances d’un service. 

https://docs.docker.com/engine/swarm/ingress/#publish-a-port-for-a-service

Les deux points précédents sont disponibles, sans configuration, dès la création de votre cluster.

Choix des matériaux

Pour monter mon cluster avec trois noeuds il va me falloir le matériel suivant :

Matériel pour un cluster swarm de raspberry pie

Installer HypriotOs sur les cartes

Pour les utilisateurs de Linux et MacOs il existe un outil proposé par la communauté de Hypriot pour flasher les cartes. Malheureusement, pour les utilisateurs de Windows, les choses sont un peu plus compliquées.

Pour linux et mac

Hypriot flash est un utilitaire en lignes de commandes qui va s’occuper de tout, de la décompression de l’image à l’installation sur la carte SIM. Pour l’installation, tout est précisé dans le readme du dépôt.

Télécharger la dernière image de hypriotos

wget https://github.com/hypriot/image-builder-rpi/releases/download/v1.9.0/hypriotos-rpi-v1.9.0.img.zip

Vérifier le checksum de l’image

➜  cat ../Downloads/hypriotos-rpi-v1.9.0.img.zip.sha256
be21a702887817d8c84c053f9ee4c54e04fd55e9fb9692edc3904801b14c33a8  hypriotos-rpi-v1.9.0.img.zip

# sur linux sha256sum / sur mac gsha256sum

➜  gsha256sum hypriotos-rpi-v1.9.0.img.zip
be21a702887817d8c84c053f9ee4c54e04fd55e9fb9692edc3904801b14c33a8  hypriotos-rpi-v1.9.0.img.zip

Flasher les cartes SD

Pour notre manager:

flash hypriotos-rpi-v1.9.0.img.zip --hostname manager-01

Pour nos workers :

flash hypriotos-rpi-v1.9.0.img.zip --hostname worker-01
flash hypriotos-rpi-v1.9.0.img.zip --hostname worker-02

Votre mot de passe root vous sera demandé pendant l’installation de l’image sur la carte.

Vous devriez avoir une sortie console proche de celle ci:

flash --hostname worker-01 hypriotos-rpi-v1.9.0.img.zip
Using cached image /tmp/hypriotos-rpi-v1.9.0.img

Is /dev/disk2 correct? yes
Unmounting /dev/disk2 ...
Unmount of all volumes on disk2 was successful
Unmount of all volumes on disk2 was successful
Flashing /tmp/hypriotos-rpi-v1.9.0.img to /dev/rdisk2 ...
No 'pv' command found, so no progress available.
Press CTRL+T if you want to see the current info of dd command.
Password:
930+1 records in
930+1 records out
975765504 bytes transferred in 111.983538 secs (8713473 bytes/sec)
Mounting Disk
Mounting /dev/disk2 to customize...
Set hostname=worker-01
Unmounting /dev/disk2 ...
"disk2" ejected.
Finished.

Pour windows

Je n’ai jamais flashé mes cartes SD depuis Windows. Mais vous pourrez trouver une procédure sur le site de hypriot. 

Dans le cas de Windows il faudra, si possible, éditer le fichier user-data  (c’est un yml sans extension) à la racine de la carte SD pour changer le hostname qui est présent dedans. Il faudra en nommer un manager-01 et les deux autres worker-01 et worker-02 histoire de pouvoir suivre dans la suite de l’article.

Les branchements

Rien de bien complexe, les câbles ethernet dans les prises ethernets, les cables d’alimentation dans les micro usb et les cartes SD dans les slots prévus à cet effet. Et hop, le tour est joué. Vous devriez pouvoir détecter les machines sur votre réseau local.

Branchements raspberry pi pour un cluster swarm

Se connecter en SSH sur les différents noeuds

Sur mac, j’utilise l’application LanScan Pro depuis des années pour scanner mon réseau local.

Détection des machines du cluster swarm sur le réseau

J’ai bien mes trois Raspberry qui sont présents sur le réseau avec les ip 192.168.1.22, 23 et 24.

Pour se connecter en ssh sur les Raspberry il faut utiliser le login/ mot de passe par défaut de hypriotOS. A savoir pirate/ hypriot.

Première connexion SSH sur hypriot

A cette étape je vous conseille de faire les mises à jour avant d’aller plus loin. Ce serait dommage de faire toute sa configuration sur une version qui a des failles de sécu. De plus il est préférable d’avoir les versions de docker sur l’ensemble du cluster.

Le temps des mises à jour vous avez le temps d’aller prendre un café 😀

Les versions de docker

Création du cluster swarm

Creation du manager

Sur le rasp nommé manager-01 je vais créer le cluster swarm :

docker swarm init

La commande va créer le cluster, vous enregistrer en temps que leader et vous donner la commande pour ajouter des workers.

La création du cluster swarm
La liste des noeuds du cluster après création

Ajout des workers

Pour ajouter les workers on va utiliser la commande donnée au moment de la création du cluster en lançant sur les Raspberry worker-01 et worker-02.

Si vous avez perdu la commande vous pouvez la récupérer en vous connectant sur un manager et en exécutant la ligne de commande :

docker swarm join-token worker
Récupération de la commande pour joindre un cluster swarm

On va donc se connecter en ssh sur worker-01 et worker-02 et lancer la commande de join. Vous devriez avoir le résultat suivant :

Joindre un cluster swarm

Sur le manager on va voir apparaitre les noeuds en tant que worker si on utilise la commande docker node ls

La liste des noeuds d’un cluster swarm

Installation et utilisation de Portainer

Portainer est un outil de visualisation et d’administration et de visualisation open source pour docker. Il est assez intéressant dans notre cas car il va nous permettre de visualiser ce qu’il se passe sur l’ensemble de notre cluster depuis une interface WEB. 

Installation de portainer

On va lancer un container Portainer sur le noeud manager-01.

docker run -d -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Portainer est maintenant compatible avec notre architecture arm, il est donc possible d’utiliser l’image officielle. 

Une fois le container lancé, vous pouvez vous rendre, via votre navigateur, sur le port 9000 de votre manager. Pour moi http://192.168.1.22:9000.

Vous allez être redirigé sur la page de création du compte administrateur. Il  est préférable de ne pas conserver le nom d’utilisateur par défaut.

Installation portainer

La seconde étape de l’installation est le choix du type de connexion à docker. Nous allons choisir local car nous avons monté le socket docker lors de la création du container.

Installation portainer

Maintenant que Portainer est configuré nous allons pouvoir consulter notre cluster swarm, mais aussi lancer des services si nous le souhaitons. 

On remarque déjà, que notre cluster est présent et que nos 3 noeuds sont bien détectés.

Cluster swarm dans portainer

En l’état notre cluster est composé de 12 coeurs et de 3 Go de ram.

Cluster visualizer

Lancer un service sur swarm

Pour lancer un service, il y a deux possibilité. Soit passer par portainer soit le faire en lignes de commandes. A vous de voir ce que vous préférez. J’ai préparé une petite image pour faire cette démo. Je m’excuse d’avance du poids de l’image (120Mo) pour faire un hello world…

J’ai buildé une image apache/ php qui affiche le hostname courant (celui du container). L’idée est de déployer un service sur le cluster et de voir comment il réagit et quel est le comportement que l’on obtient.

Déployer un service en lignes de commandes

Nous allons lancer une instance de notre image sur le cluster. Nous n’avons pas à nous soucier du choix de la machine sur laquelle l’application va tourner car le routing mesh nous permettra d’y accéder depuis n’importe quel noeud.  Mais vous pouvez le savoir dans portainer en retournant sur la vue Cluster visualisation.

docker service create -p 80:80 --name hello-world docker.io/lahaxearnaud/swarm-hello-world
Création d’un service dans swarm

Il est possible de préciser beaucoup d’options pour limiter les ressources que le container pourra utiliser, la façon de vérifier que l’application est toujours up (health check)…

Déployer un service avec Portainer

Toutes les options que l’on peut donner via le cli sont disponibles via portainer pour la création de service. La mise en place de nouveau service est très simplifié grâce à l’interface graphique.

Creation d’un service dans portainer

Pour notre test nous n’avons pas besoin des configurations avancées.

Tester le load balancing

Nous avons maintenant un service qui tourne sur notre cluster et qui sert une « page » web contenant le nom du container qui le fait tourner. Pour tester le load balancing on fait une série d’appels et on va regarder si on obtient toujours le même nom de container.

for ((i=1;i<=10;i++)); do curl "http://192.168.1.22"; echo ""; done

Sans surprise pour le moment je vais obtenir 10 fois la même valeur, car nous n’avons qu’une instance qui tourne :

Dans un premier temps nous allons faire scaller notre application pour faire tourner 9 instances.

docker service scale hello-world=9

Vous pouvez aussi le faire via portainer en cliquant sur le service hello-world dans la section service et en modifiant la valeur dans le champs Replicas.

Scaller un service avec portainer

Il va falloir attendre un peu que l’image soit téléchargée sur les différents Raspberry et que les containers soient lancés. Mais une fois que tout est prêt, on va pouvoir relancer notre commande.

On se rend bien compte que la charge est distribuée entre les différentes machines. Sur les 10 hits on a touché les 9 instances.

Consulter les logs

Sur le manager vous pouvez faire un tail sur les logs d’un service via la commande docker service log -ft hello-world.

Visualisation des logs d’un service swarm

Dans portainer par contre il semblerait qu’il y ait un bug et qu’il ne remonte que les logs des instances présentes sur le manager. 

Que mettre sur le cluster ?

Pour ma part, j’utilise swarm depuis au moins deux ans pour ma domotique. Comme je voulais jouer un peu avec l’IoT j’ai mis des capteurs un peu partout dans l’appartement (luminosité, température, mouvements, capteurs d’ouverture de porte et de fenêtre…) et chaque élément envoie des messages dans un rabbitmq. Mon cluster contient l’ensemble des consommateurs et l’application symfony qui sert l’interface graphique. Les consommateurs sont des workers symfony 4 qui utilisent le composant symfony messenger

Avoir cette architecture en cluster permet de perdre ou d’ajouter un ou plusieurs serveurs sans devoir déplacer des applications à la main. Là où il faut être attentif c’est que swarm peut continuer de fonctionner en perdant un worker, mais la perte des managers est plus problématique. Il est préférable d’avoir plusieurs managers pour éviter que le cluster se retrouve sans manager en cas de panne. Un nombre impair de managers est préférable pour s’assurer que l’algorithme (Raft) arrive à élire un nouveau leader.

Retour d’expérience

La technologie est sympa et la fiabilité est au rendez-vous sur tout ce qui est worker et application web. Par contre, j’ai rencontré pas mal de problèmes en voulant mettre un rabbitmq, un elastic search ou encore un mysql dans le cluster. Après plusieurs crashes je les ai installés sur une machine séparée. Je ne sais pas à quel niveau se situe le problème, mais depuis que c’est sur un rasp séparé il n’y a plus de problèmes.

L’autre point est que j’ai une livebox à la maison, c’est elle qui me sert de DHCP (c’est dans ma todo de faire autrement). Elle a tendance à sortir du réseau les machines avec des ips fixes au bout de quelques jours. Je me suis retrouvé à plusieurs reprises avec un cluster qui était HS car toutes les machines étaient déconnectées.

Le fait d’être sur une architecture ARM nous empêche d’utiliser la plupart des images disponibles sur les hubs. Il faut donc passer du temps à faire ses propres images. Ce n’est pas forcement un mal !

Faq

Comment retirer proprement un noeud d’un cluster swarm ?

Si c’est un manager il faut se poser la question de promouvoir un worker en manager avant de commencer docker node promote worker-02 puis vous devez retirer le role manager au noeud à supprimer docker node demote manager-01. La seconde étape est de dire à l’orchestrateur d’enlever tout ce qui tourne sur le noeud docker node update --availability drain worker-01. Une fois qu’il n’y a plus rien sur le noeud on peut le sortir du cluster via la commande docker node rm worker-01. De cette manière il n’y aura pas d’interruption de service.

Comment supprimer le cluster swarm ?

Dans un premier temps il faut supprimer les services qui tournent dessus : docker service rm mon-service. Une fois que c’est fait vous pouvez supprimer les noeuds un à un via docker node rm -f node-name. Puis sur le manager faire un docker swarm leave -f.

Est-ce qu’il est possible de deployer une image locale ?

Non, il n’est pas possible de déployer une image qui n’est pas dans un registry. Mais vous pouvez monter votre propre registry et l’utiliser pour déployer vos images sur vos workers.

Est-il possible de déployer un fichier docker-compose sur swarm ?

Oui c’est possible via docker stack deploy

Est-ce que l’on peut monter des volumes dans les services ?

Oui vous pouvez, maintenant il y aura autant de volume que de noeuds sur lesquels tourneront vos applications.

Analyse de code statique avec phpstan

Phpstan est un outil en ligne de commande qui va vous permettre de détecter automatiquement les erreurs les plus simples en scannant l’intégralité de votre projet.

Démonstration phpstan

De base, l’outil va analyser une application PHP sans tenir compte des spécificités des différents frameworks et librairies. C’est pourquoi il existe des extensions comme PHPstan Symfony pour affiner l’analyse.

Si comme moi vous voulez l’utiliser sur un projet qui a beaucoup de legacy (plus de 10 ans) vous allez avoir un rapport gigantesque. Il faut trouver des solutions pour réduire le rapport à la pull request (merge request) que l’on doit relire. 

Il existe justement un outil qui permet de faire cette corrélation entre le diff et le rapport de PHPstan. Reviewdog est une application en go qui permet de prendre en entrée le rapport d’un outil d’analyse de code comme eslint, golint ou dans notre cas PHPstan.

Sans passer par reviewdog :

➜  vendor/bin/phpstan analyse src -l 4 --no-progress --error-format=raw | wc -l

     292

292 anomalies sur la globalité du projet.

En passant par reviewdog :

➜ vendor/bin/phpstan analyse src -l 4 --no-progress --error-format=raw | reviewdog -diff="git diff master" -f=phpstan | wc -l

	2

Il se reste que deux anomalies, et elles sont directement liées au diff entre la branche courante et master.

Reviewdog peut se connecter directement sur votre gitlab ou github pour ajouter des commentaires dans les pull requests.

Tout ceci ne remplace pas une relecture par un « humain » mais cela va nous donner des indicateurs de qualité et va vous délester des vérifications les plus simples (Est-ce que cette méthode/ classe existe ?). Selon le niveau de vérification que l’on donne à PHPstan on va pouvoir vérifier plus ou moins de choses, comme les dockblocks par exemple.

Ce qui est assez intéressant c’est que PHPstan est extensible et qu’il est donc possible de créer nos propres vérifications. Il serait donc possible, par exemple, de remonter une alerte quand on utilise une classe ou méthode marquée comme dépréciée dans notre code.