Varnish, du load balancing sans tâche !

Varnish est un excellent serveur de cache HTTP, mais il peut aussi être un très bon load balancer.

Photo des produits Vanish

Pour se faire nous allons commencer par définir dans notre fichier .vcl les différents backend


backend server01 {
    .host = "172.16.1.1";
    .port = "80";
}

backend server02 {
    .host = "172.16.1.2";
    .port = "80";
}

backend server03 {
    .host = "172.16.1.3";
    .port = "80";
}

Puis nous allons définir le director qui va lier les backend entre eux selon une règle. Ici la règle sera le round robin.


director servers round-robin {
    { .backend = server01; }
    { .backend = server02; }
    { .backend = server03; }
}

Et en fin dans la partie sub vcl_recv de votre .vcl nous allons déclarer le director comme backend à utiliser.


sub vcl_recv {
    #votre code

    set req.backend = servers;
}

Il suffit de relancer Varnish pour que cela fonctionne.

Ce n’est pas fini car il faut surtout rajouter un probe sur les backend, cela permettra de vérifier la santé de ceux-ci et de les exclure si besoin.


probe checkserver {
    .url = "/";
    .timeout = 1s;
    .interval = 10s;
    .window = 8;
    .threshold = 6;
}

  • url : indique l’url que varnish va demander pour vérifier que le backend fonctionne
  • timeout : le temps que varnish va attendre avant de considéré que la vérification a échoué.
  • interval : le temps entre chaque vérification
  • window : le nombre de vérification permettant de déterminer la santé du backend
  • threshold : le nombre de vérification réussi sur le pool window permettant de dire que le backend est en bonne santé

Dans l’exemple si dessus pour le serveur server01 varnish va appeler http://172.16.1.1/ toutes les 10 secondes et comptabiliser l’appel comme bon si la page répond une page valide (code http 200) en moins d’1 secondes.

Varnish regardera les 8 dernières vérification et si le serveur a mal (ou pas répondu) plus de 2 fois alors il sera considéré comme malade et sorti des backend tant qu’il ne répondra pas bien à nouveau.

Vous pouvez faire en sorte que l’url appelée par Varnish soit un script qui va faire des vérifications supplémentaires (ecrire un fichier sur le disque par exemple) et répondre une erreur 500 si les vérifications ne sont pas bonnes. Ainsi même si le serveur répond, Varnish va quand même considérer la vérification échouée.

Donc un fois votre probe défini il faudra le rajouter dans la config de vos backend.

Comme cela :


backend server01 {
    .host = "172.16.1.1";
    .port = "80";
    .probe = checkserver;
}

backend server02 {
    .host = "172.16.1.2";
    .port = "80";
    .probe = checkserver;
}

backend server03 {
    .host = "172.16.1.3";
    .port = "80";
    .probe = checkserver;
}

Une fois Varnish relancé vous pourrez voir l’état de vos backend avec la commande varnishadm puis dans la console backend.list vous donnera :


server01(172.16.1.1,,80)        3     probe      Healthy 8/8
server02(172.16.1.2,,80)        3     probe      Healthy 8/8
server03(172.16.1.3,,80)        3     probe      Healthy 8/8

Dans varnishadm vous pouvez aussi utiliser debug.healt pour voir l’état détaillé de chaque vérification faites par Varnish pour chaque backend.


Backend server01 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.003597
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Backend server02 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.007632
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Backend server03 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.004433
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Dans l’exemple ci-dessus on remarquera qu’il y a un trou dans l’état de server02, cela indique que lors de cette vérification la page n’a pas répondu correctement.

Enfin, toujours dans Varnish, si vous souhaitez exclurcommee manuellement un backend il suffit de faire :


backend.set_health server01 sick

Cela forcera Varnish à considérer server01 comme malade et il ne l’utilisera plus tant que vous ne lui dirai pas de le gerer automatiquement comme ceci :


backend.set_health server01 auto

Voir les commentaires →

Rancher, le cow-boy de Docker

Pour ordonnancer le lancement de vos containers nous avons vu précédemment que Docker Compose fait bien le boulot.

Néanmoins, si vous souhaitez pouvoir le faire depuis une interface claire et facile d’utilisation alors Rancher est la solution !

Impression d’ecran de rancher

De plus, Rancher ne se contente pas de lancer les containers souhaités, il va aussi créer un réseau privé entre vos différentes machines. Cela va permettre de lier des containers qui ne sont pas sur les même machines.

Pour l’installer il vous suffit de simplement lancer ce container :


docker run -d -p 8080:8080 rancher/server

Puis en vous rendant sur http://[ip_de_votre_machine]:8080/ vous pourrez configurer toutes les machines dont il doit prendre la main.

Là encore c’est simple comme bonjour, l’interface vous donnera une commande docker de ce type à lancer :


docker run -d --privileged -v /var/run/docker.sock:/var/run/docker.sock rancher/agent:v0.5.2 http://[ip_de_votre_machine]/v1/scripts/xxxxxx:xxxxx:xxxx

Les différentes machines apparaîtront dans votre Rancher et vous pourrez depuis l’interface ajouter les containers que vous souhaitez.

Attention quand même, Rancher est en bêta et ne doit pas être utilisé pour de la production.

Voir les commentaires →

Rajoutez du sel dans votre mot de passe !

Photo de gros sel

Aujourd’hui les mots de passe sont partout sur internet. Vous vous en servez tous les jours (surement enregistré dans votre navigateur…).

La majorité des gens utilisent le même mot de passe et je ne peux pas leur en vouloir. Mais si cette unique mot de passe tombe dans les mains de quelqu’un de mal intentionné alors les conséquences peuvent être grave.

Surtout que certains services enregistrent votre mot de passe en clair dans leurs bases de données…

Moi non plus je n’ai pas la possibilité d’inventer un nouveau mot de passe et surtout de le retenir pour chacun de nouveaux services où je m’enregistre.

J’ai donc pris la décision de saler moi-même mon mot de passe en me basant sur le nom du service. Lors de l’inscription je vais rajouter dans mon mot de passe à la deuxième position et à l’avant dernière position les lettres se trouvant à la deuxième position et à l’avant dernière position du service.

Vous allez voir c’est très simple en prenant un exemple.

Imaginons que mon mot de passe soit : Mo1D3pA$$3
Selon ma logique (deuxième position et avant dernière position) mon mot de passe ressemble en fait plus à ça : MXo1D3pA$$X3 ou les X seront remplacés par les lettres du service.

Pour Facebook mon mot de passe devient Mao1D3pA$$o3
Pour Twitter mon mot de passe devient Mwo1D3pA$$e3
Pour Amazon mon mot de passe devient Mmo1D3pA$$o3

Le gras, sur les lettres, est simplement là pour que vous puissiez visualiser rapidement.

Je n’ai donc que deux choses à connaitre : le mot de passe original et la logique d’ajout de lettre. De cette façon il y a peu de chance que la personne qui me vole mon mot de passe Facebook puisse accéder à un autre de mes services comme il ne connait pas la logique d’ajout de lettre que j’ai choisi.

Une dernière chose, je vous conseille quand même grandement d’avoir un mot de passe totalement différent pour votre boite mail et d’activer (si possible) la double authentification


Crédit photo : 25891 sur Pixabay

Voir les commentaires →

Docker-compose par l’exemple

Dernièrement j’ai eu besoin d’une stack Nginx, PHP FPM, MariaDB et Memcached pour faire des tests. Dans ce cas Docker répond parfaitement à la demande. Pour cela nous avons besoin de créer quatre containers (un pour chaque service) et de les lancer ensemble.

Néanmoins cette gestion de la création, ordonnancement et lancement des containers est fastidieuse car il faut le faire manuellement et respecter chaque étape.

Photo de contenaires dans un port

C’est là que docker-compose vous simplifie la vie.

En se basant sur un fichier docker-compose.yml contenant la configuration de votre stack, docker-compose va créer, lancer, ouvrir les ports, créer les volumes et lier vos containers tout seul.

Pour comprendre vous pouvez retrouver ma stack sur GitHub et surtout regarder comment se compose le fichier docker-compose.yml.


Si vous avez la chance d’être dans le Jura et que vous voulez en savoir plus sur Docker, je ferai une présentation de l’outil ce jeudi 19 mars 2015 à Lons Le Saunier lors d’un Digital apéro organisé par Silicon Comté


Crédit photo : Huskyherz sur Pixabay

Voir les commentaires →

Mozilla, Google et Microsoft mettent SHA-1 à la porte !!

SHA et les certificats

Pour valider la signature d’un certificat nous utilisons l’algorithme SHA. Celui ci se decline en plusieurs versions.

SHA-1 est la version la plus utilisé aujourd’hui pour signer la majorité des certificats SSL. Mais le risque de collision est de plus en plus grand (avec les performances grandissantes des ordinateurs).

Du coup SHA-1 doit être abandonné pour SHA-2 (plus précisement SHA-256 préconisé par la majorité des éditeurs de certificat).

Google tire le premier

Dans Chrome 41, prévu pour début Mars, l’affichage va changer.

Si votre certificat est signé avec SHA-1 et que sa date de fin de validité est avant 2017 alors une icone avec un triangle avertira vos visiteurs.

Pire ! Si votre certificat est signé avec SHA-1 et que sa date de fin de validité est après 2016 alors le certificat sera considéré comme dangereux, comme pour les certificats expirés.

Microsoft et Mozilla suivent

Janvier 2016, Microsoft n’acceptera plus du tout ces certificats.

Janvier 2017, Firefox fera de même.

Quand changer son certificat signé en SHA-1 ?

Maintenant ! Chrome est majoritairement utilisé dans beaucoup de pays (dont la France) et surtout il se met à jour de facon silencieuse.

Shaaaaaaaaaaaaa.com
Ce site vous permettra de vérifier très rapidement si votre certificat signé est en SHA-1 ou SHA-2.

Voir les commentaires →