E-commerçants, préparez-vous !

visuel-article-infra

Les fêtes approchent et si votre activité dépend grandement d’Internet et de votre site Web, vous vous posez sans doute la question : « Mon site va-t-il tenir le coup ? ».

Nombreux sont les commerçants qui misent beaucoup sur leur site e-commerce et cette période de fête est cruciale, voire vitale.
Il ne suffit pas de disposer de son site Web hébergé chez 1and1 ou Hostpapa à moindre coût pour assurer sa présence en ligne en tout temps et en toute circonstance.
Même si ce genre d’offre peut suffire à beaucoup et pour la majorité de l’année, les fêtes et autres périodes de soldes génèrent un trafic (beaucoup) plus élevé pour votre site.
Le défi, c’est de faire en sorte que votre boutique en ligne reste disponible et fluide pour le visiteur, augmentant ainsi la satisfaction client et votre taux de transformation.

Voici 5 points importants pour préparer votre site à affronter cette période de trafic intense :

  • Backups : L’assurance vie
    On ne le répète jamais assez, mais un incident est vite arrivé. Erreur humaine ou défaillance matériel, ce n’est jamais le bon moment. Il faut être prêt et disposer de procédures de sauvegarde et de restauration propres et éprouvées.
    Prenez donc le temps de vérifier l’état de vos sauvegardes et de corriger en cas de soucis.
  • Le CDN : La qualité a un prix
    Voilà une solution performante mais onéreuse. Le CDN (ou Content Delivery Network) vous permet d’assurer « un point de présence » au plus proche du visiteur en mettant à disposition des nœuds de « cache » géographiques.
    Si votre budget vous le permet, souscrire à un service de CDN est une option plus que viable pour la tenue en charge de votre site Web.
    Si cet élément est un des premiers de la liste, c’est surtout parce que sa mise en place doit être anticipée et réfléchie. Nombreux sont les acteurs du monde des CDNs (Akamaï, CDNetworks, CloudFlare, etc.) et chacun propose de plus en plus d’offres. Il s’agit surtout de vous poser les bonnes questions pour faire le bon choix. Où souhaitez-vous être présent ? Que souhaitez-vous accélérer ?
    Bref, prenez le temps d’y penser.
  • Le test de charge : La preuve par 3
    Indispensable à toute plateforme ayant pour vocation d’accueillir des visiteurs/utilisateurs, un test de charge est un moyen empirique de vous donner une idée des performances de votre site.
    Ce genre de benchmark ne se réalise bien entendu pas pendant la période fatidique mais bien avant. L’idéal étant de réaliser ces tests sur la plateforme telle qu’elle sera au moment des fêtes (i.e : code source, produits, infrastructure, etc.).
    Un seul changement, et le test ne sera plus représentatif.
    Il existe plusieurs outils OpenSource pour réaliser ce genre de tests par vous-même, notamment JMeter (http://jmeter.apache.org/) qui vous permettra de définir un scénario de navigation et de le « jouer » plusieurs fois, en parallèle, selon des critères que vous aurez définis, et ce, jusqu’à atteindre les limites de votre hébergement. Il ne tient qu’à vous, ensuite, d’analyser les résultats pour en tirer les conclusions les plus pertinentes.
  • Le cache : À tous les niveaux
    Pour améliorer les performances de votre site Web, il faut faire en sorte de le solliciter le moins possible ; et si vous ne pouvez pas jouer sur le nombre de visiteurs, vous pouvez « soulager » votre infrastructure par la mise en place et/ou l’optimisation du cache à plusieurs niveaux.

    • Cache navigateur : c’est le niveau de cache le plus important. C’est celui qui est géré par le navigateur de l’utilisateur. En définissant la politique de cache (via les en-têtes Cache-Control et Expire) des éléments et leur durée de mise en cache, vous permettez au navigateur de conserver, en local, certains éléments et ainsi, de ne pas solliciter continuellement votre serveur Web. L’utilisateur y gagne en rapidité et vous en performance.
    • Cache code : Situé côté serveur, le cache de code (géré par APC, OPCache, etc.) va permettre la mise en cache des fichiers pré-compilés de votre application (PHP par exemple). Le gain est significatif puisqu’on évite les étapes lourdes de parsing et compilation du code.
    • Cache Applicatif : En plus du cache de code, vous pouvez utiliser un serveur de cache applicatif tel que Redis ou Memcached. Basés sur du stockage clé-valeur, en RAM, le gain de performances est également fortement appréciable. Attention, votre application doit être conçue pour utiliser ces serveurs de cache ; via plugin ou développement spécifique.
    • Reverse Proxy : Le reverse proxy ou proxy inverse est une brique intermédiaire entre l’application et le client. Possédant son propre cache, il va décharger votre serveur web en utilisant ce qu’il possède déjà plutôt que de faire suivre la requête. La configuration de ce genre de logiciel est très fine et vous permet de mettre en cache quasiment tout et « n’importe quoi ». On peut même y faire de la mise en cache de page « partielle » via les blocs ESI (cf: https://fr.wikipedia.org/wiki/Edge_Side_Includes). On peut citer Varnish (https://varnish-cache.org/), un projet opensource populaire et performant.
    • CDN : Comme précédemment dit, le CDN est un réseau de livraison de contenus qui  diminuera sensiblement le temps d’ouverture de vos pages Internet et facilitera également l’accès à vos différentes applications Web. Un service CDN se révèle particulièrement judicieux voire indispensable pour desservir efficacement des régions éloignées.
  • Le Jour-J : On ne touche à rien !
    Ça peut paraître extrême, mais il faut limiter au maximum les actions en back-office. Peu importe votre CMS, les actions significatives (changement des prix, contributions, réindexations, etc.) sont lourdes pour votre application et donc pour votre infrastructure. Votre site étant déjà en train de supporter un trafic inhabituel, laissez-le tranquille et contentez vous de regarder.

Voilà un petit tour de quelques points à avoir en tête lorsqu’on est e-commerçant pour optimiser ses activités sans craindre les incidents techniques. La liste n’est bien entendu pas exhaustive et on peut citer d’autres pistes d’améliorations comme l’optimisation des médias de votre site pour gagner en légèreté, l’augmentation temporaire de la puissance de votre infrastructure ou encore l’utilisation du Responsive Web Design pour les nombreux terminaux mobiles qui envahissent de plus en plus le marché.

Vous l’aurez compris, les options sont donc infinies. Pour une expérience utilisateur optimale, tenez compte des caractéristiques spécifiques de vos visiteurs et prenez des décisions qui répondent à vos enjeux stratégiques d’affaires. Avec un investissement minime et des choix éclairés, les résultats peuvent être bluffants. Sachez que l’équipe Infrastructure de Savoir-faire Linux peut vous guider dans vos démarches pour un temps des fêtes couronné de succès !

Des nouvelles du projet LDAP Tool Box, la boîte à outils pour les annuaires LDAP

Le projet LDAP Tool Box rassemble différents outils pour aider les administrateurs LDAP, que ce soit des paquets OpenLDAP, des scripts de supervision ou encore des applications Web. L’objectif est de simplifier la vie des administrateurs LDAP, car comme l’indique la description du projet :

Même les administrateurs LDAP ont besoin d’aide

Tous les outils proposés sont sous licence libre et disponibles sur GitHub.

Supervision

Des greffons de supervision sont fournis pour Nagios (ou tout autre logiciel compatible) et Cacti. Ils permettent par exemple de vérifier le statut de la réplication OpenLDAP, de collecter les statistiques sur les opérations LDAP ou encore surveiller le taux de remplissage d’une base MDB.

16c97f6538278bee29e8b9de1aac3516-media-593x381

Des configurations sont également disponibles pour la pile logicielle ELK (ElasticSearch, Logstash, Kibana) afin de tracer en temps réel l’utilisation des annuaires OpenLDAP.

openldap-elk-ldap-operations

Paquets OpenLDAP

OpenLDAP est le serveur LDAP le plus répandu, très proche du standard et offrant d’excellentes performances. Il est présent dans la plupart des distributions GNU/Linux mais celles-ci font souvent des choix de compilations non avalisées par les développeurs du projet, l’exemple le plus représentatif étant la bibliothèque SSL/TLS.

Le projet LDAP Tool Box fournit des paquets pour les environnements Debian/Ubuntu et Red Hat/CentOS. Ils sont compilés avec OpenSSL et embarquent les overlays officiels ainsi que certains overlays contribués comme « lastbind » et « smbk5pwd ».

Ils offrent également des modules spécifiques de gestion de la qualité des mots de passe comme check_password et ppm. Un script de gestion du service est installé par défaut, permettant les sauvegardes/restaurations des données et de la configuration.

Interface de gestion du mot de passe

L’application Self Service Password permet de fournir aux utilisateurs une interface simple pour changer son mot de passe, ou le réinitialiser quand celui-ci est perdu (ou expiré). Cette réinitialisation peut se faire :

  • Par un lien envoyé par mail
  • Par un code envoyé par SMS
  • Par la réponse à une question

Cette interface est compatible avec différents annuaires LDAP dont Active Directory et Samba 4.

ssp_1_0_change_password

La version 1.0 de ce logiciel est sortie en octobre 2016 (voir l’article sur LinuxFR).

Interface de consultation des données

L’application White Pages est une interface de consultation des données d’un annuaire LDAP, avec les fonctionnalités suivantes :

  • Recherche rapide : une invite de recherche dans le menu permet de retrouver directement des entrées à partir du nom, du prénom, du mail ou de l’identifiant
  • Recherche avancée : un formulaire liste les différents attributs sur lesquels une recherche peut être faite
  • Trombinoscope : toutes les entrées de l’annuaire sont affichées avec leur photo

Ces fonctions peuvent être activées/désactivées et les attributs cherchés ou affichés sont configurables. L’interface peut donc être utilisée avec n’importe quel annuaire LDAP.

wp_0_1_full_display

La version 0.1 de ce logiciel est sortie en novembre 2016 (voir l’article sur LinuxFR).

Relier son application à FranceConnect avec le logiciel libre LemonLDAP::NG

Développé depuis 2014 sous l’égide de la DINSIC, FranceConnect est la nouvelle plate-forme d’authentification à destination des citoyens français pour simplifier l’accès à l’administration en ligne.

Annoncé officiellement il y a quelques jours par le secrétaire d’État chargé de la réforme de l’État et de la simplification, FranceConnect est déjà utilisé par de nombreuses administrations.

Le protocole OpenID Connect

C’est le protocole OpenID Connect qui a été retenu pour FranceConnect, choix risqué en 2014 car le standard n’en était qu’à ses débuts, mais il a depuis fait ses preuves, comme en témoigne son adoption par Google.

J’ai eu l’occasion de présenter ce protocole dans différentes conférences, comme à la LDAPCon en novembre dernier :

LDAPCon2015_OpenIDConnect-Diapos

L’avantage d’avoir opté pour un standard comme OpenID Connect, c’est que cela permet d’utiliser n’importe quel logiciel ayant implémenté ce standard pour se relier à FranceConnect.

lemonldap-ng-france-connect

Depuis la version 1.9 de LemonLDAP::NG, on peut utiliser OpenID Connect, soit comme client (Relying Party), soit comme fournisseur (OpenID Provider).  Une application compatible avec LemonLDAP::NG peut donc alors très facilement récupérer une identité via FranceConnect sans développement supplémentaire !

Configuration de LemonLDAP::NG

Nous allons configurer LemonLDAP::NG comme client OpenID Connect. Pour cela il faut tout d’abord paramétrer le service OpenID Connect :

  • Gérer les règle de redirections (Apache ou Nginx) pour le chemin /oauth2/
  • Choisir « OpenID Connect » comme module d’authentification
  • Définir l’identifiant de l’entité (par défaut l’URL du portail)
  • Laisser les valeurs par défaut pour les points d’accès OAuth2
  • La configuration d’une clé de signature n’est pas nécessaire

Il reste ensuite à inscrire FranceConnect comme fournisseur OpenID Connect :

  • Créer les métadonnées JSON (non fournies par FranceConnect), par exemple (valeurs de la plate-forme de développement) :
{
"issuer": "https://fcp.integ01.dev-franceconnect.fr",
"authorization_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/authorize",
"token_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/token",
"userinfo_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/userinfo",
"end_session_endpoint":"https://fcp.integ01.dev-franceconnect.fr/api/v1/logout"
}
  • Déclarer les attributs de l’identité pivot à collecter, par exemple : given_name, family_name, birthdate
  • Dans les options, renseigner le client_id et client_secret fourni par FranceConnect (voir l’étape suivante), et le scope lié aux attributs demandés, par exemple : openid email profile birth

Enregistrement auprès de FranceConnect

Pour que votre instance de LemonLDAP::NG puisse être reliée à FranceConnect, il faut formuler une demande officielle via ce formulaire.

Il est important de fournir l’URL de callback, qui par défaut dans LemonLDAP::NG est http://auth.example.com/?openidcallback=1. Mais vous devrez adapter cette URL avec votre propre nom de domaine, et si besoin d’autres paramètres en fonction des modules utilisés dans LemonLDAP::NG.

FranceConnect vous fournira alors les valeurs de client_id et client_secret dont vous avez besoin dans la configuration de LemonLDAP::NG.

C’est terminé !

LemonLDAP::NG est désormais configuré pour s’authentifier sur FranceConnect. Si certaines choses ne fonctionnent pas, référez-vous à la documentation technique disponible sur le site.

Les attributs collectés lors de l’authentification sont disponibles dans la session SSO et peuvent être transmis par LemonLDAP::NG aux applications de différentes façons : en-têtes HTTP, CAS, OpenID Connect ou SAML.

À vous de jouer !

Utilisation de Keepalived pour la haute-disponibilité LDAP et HTTP

Nous déployons régulièrement des infrastructures LDAP et WebSSO chez nos clients, et se pose toujours la question de la haute-disponibilité : la plate-forme d’authentification devenant centrale, il est indispensable de se prémunir d’un arrêt de service, que ce soit de l’annuaire LDAP ou du portail d’authentification Web. Nous allons voir comment le logiciel Keepalived peut nous aider à répondre à ce besoin.

ka-header

Des logiciels d’infrastructure adaptés

Avant d’envisager la mise en place d’outils de haute-disponibilité, il faut s’assurer que les logiciels principaux de l’infrastructure sauront fonctionner dans ce mode, c’est-à-dire qu’ils peuvent être installés sur plusieurs nœuds (serveurs physiques, virtuels ou conteneurs) et opérer de la même façon quelque soit le nœud actif.

Dans notre cas, nous utiliserons les logiciels suivants :

  • OpenLDAP : serveur d’annuaire compatible LDAPv3
  • LemonLDAP::NG : produit de WebSSO compatible CAS, SAML et OpenID Connect

OpenLDAP-logo

OpenLDAP sait fonctionner en mode multi-maîtres depuis plusieurs années, via le protocole SyncRepl. Le mode « miroir » (mirror mode) est particulièrement pertinent dans une architecture à deux nœuds où un seul d’entre eux sera contacté par les clients (l’important ici est d’éviter que des opérations d’écriture soient faites simultanément sur les deux nœuds). La configuration de ce mode est détaillée dans le guide d’administration d’OpenLDAP.

LemonLDAP::NG

LemonLDAP::NG pour sa part a été conçu dès le départ pour pouvoir utiliser des bases externes pour la gestion de ses données (configuration et sessions). Ainsi il est possible de déployer autant de nœuds que nécessaire en partageant les données entre les nœuds. Pour ma part, j’utilise régulièrement l’annuaire OpenLDAP comme stockage de la configuration et des sessions : l’annuaire étant déjà redondé, pas besoin de travail supplémentaire pour le WebSSO. Mais vous pouvez également utiliser des bases de données SQL (MySQL, PostGreSQL) ou NoSQL (MongoDB, Redis, Cassandra) pour assurer ce service.

Utilisation d’une adresse virtuelle

Une fois les deux nœuds installés, chacun possède son adresse IP propre et il faut trouver un moyen d’indiquer aux applications clientes quel nœud utiliser.

Une première solution est le Round-Robin DNS : au nom DNS ldap.example.com ou auth.example.com on associe les deux adresses IP, et charge aux clients de se débrouiller avec ça. Dans le cas de HTTP, la plupart des clients sauront rejouer les requêtes sur la seconde IP si la première ne fonctionne pas, mais ce n’est pas aussi évident pour les clients LDAP.

L’autre solution est d’utiliser une adresse IP virtuelle qui sera associée au nœud principal. Le nœud secondaire est opérationnel mais ne sera pas associé à l’adresse IP virtuelle, jusqu’à ce que celle-ci bascule en cas de problème du nœud principal. Dans cette situation, la haute-disponibilité est bien gérée du côté des serveurs, et non du côté des clients qui ne contacte qu’une seule adresse, l’adresse IP virtuelle.

Utilisation de Keepalived

Le logiciel Keepalived permet de gérer une IP virtuelle qui sera associée au nœud principal tant que celui-ci est opérationnel. Le protocole VRRP est utilisé entre les nœuds pour gérer cette adresse IP virtuelle.

Sa configuration est assez simple :

vrrp_instance VI_SFL {
  state MASTER
  priority 150
  nopreempt
  interface eth0
  virtual_router_id 69
  advert_int 5
  authentication {
     auth_type PASS
     auth_pass KEEPALIVED_PASSWORD
  }
  virtual_ipaddress {
    10.10.0.10/22 brd 10.10.0.255 dev eth0 scope global
  }
}

Il est intéressant de paramétrer la partie « authentication » pour éviter que les ordres VRRP soient pris en compte par d’autres routeurs non associés à la grappe de serveurs. Seuls les serveurs disposant du même mot de passe consommeront les requêtes.

Le paramètre « priority » permet d’indiquer le nœud principal. Le ou les nœuds secondaires auront une priorité plus faible (par exemple 100).

Script de surveillance

Cette configuration initiale n’est pas suffisante pour palier à des problèmes applicatifs : l’adresse IP virtuelle basculera si le nœud principal ne répond plus au protocole VRRP, mais rien n’est fait pour surveiller l’annuaire LDAP ou le serveur HTTP.

Keepalived permet d’utiliser un « track_script » dans lequel nous sommes libres de lancer les commandes que nous souhaitons. Si ce script s’exécute sans erreurs, alors le nœud est considéré comme opérationnel, sinon il est mis en quarantaine.

L’appel au script se configure simplement :

vrrp_script check_server_health {
  script "/usr/local/bin/check_server_health.sh"
  interval 2
  fall 2
  rise 2
}

vrrp_instance VI_SFL {
  ...
  track_script {
    check_server_health
  }
}

Voici un exemple de script :

#!/bin/bash

# Script that do several checks to verify LDAP/SSO service is up
#
# Returns 0 if all is fine
#
# Copyright (c) 2016 Clement Oudot @ Savoir-faire Linux


# Disks

rootuse=$(df -H / | grep -v 'Filesystem' | awk '{ print $5 }' | cut -d'%' -f1)

if [ $rootuse -ge 95 ]; then
        echo "Partition / is full ($rootuse%)"
        exit 1
else
        echo "Partition / is OK ($rootuse%)"
fi

# Process
            
openldapprocess=$(/bin/pidof slapd)
apacheprocess=$(/bin/pidof apache2)

/usr/local/openldap/bin/ldapsearch -x -H ldap://localhost -b '' -s base -l 3 > /dev/null 2>&1
ldapresponse=$?

if [ -z "$openldapprocess" ]; then  
        echo "OpenLDAP is not running"
        exit 1
else
        echo "OpenLDAP is running (PID $openldapprocess)"
fi

if [ "$ldapresponse" -gt 0 ]; then
        echo "OpenLDAP is not anwering on RootDSE"
        exit 1
else
        echo "OpenLDAP is answering on RootDSE"
fi

if [ -z "$apacheprocess" ]; then
        echo "Apache is not running"
        exit 1
else
        echo "Apache is running (PID $apacheprocess)"
fi

# Exit without problem
exit 0

J’utilise plusieurs type de vérifications dans ce script :

  • Contrôle de l’espace disque
  • Contrôle des démons lancés
  • Réponse à une requête LDAP

Bien entendu, charge à vous d’y mettre les vérifications qui vous semblent pertinentes.

Découverte d’OpenStack à l’OpenStack Workshop Lyon

La communauté OpenStack FR a organisé le 15 juin 2016 une journée sur Lyon dédié à OpenStack : OpenStack Workshop Lyon (ou OWL pour les intimes).

OpenStack FR

J’ai participé à cet atelier pour découvrir un peu mieux OpenStack et rencontrer les membres influents de sa communauté en France.

La journée est introduite par Adrien Cunin de chez Osones qui présente les différents ateliers de la journée : introduction à OpenStack, déploiement, contribution.

20160615_094813 Pour ma part, bien qu’ayant déjà touché à OpenStack, je choisi l’atelier introduction animé par Christophe Sauthier d’Objectif Libre.

20160615_110128

Après une présentation théorique d’OpenStack et de ses différents composants, nous passons à la pratique en utilisant un compte OVH (qui dispose de sa propre offre OpenStack).

Notre première étape est le démarrage d’une instance basée sur une image fournie par Christophe, image qui n’est autre qu’une installation d’OpenStack : nous voici alors avec un serveur OpenStack maison installé sur une instance OpenStack d’OVH (qui a dit Inception ?).

Grâce à ce serveur, nous pouvons découvrir les outils d’administration d’OpenStack et dans un « tenant » de démonstration créer nos premières instances. Toujours via l’interface d’administration (module horizon) nous paramétrons le réseau, les règles de sécurité, les clés SSH, etc. Nous obtenons rapidement un environnement fonctionnel.

Le reste de la journée est consacré à quelques détails sur les différents modules :

  • neutron pour la partie réseau
  • cinder pour la gestion des volumes
  • swift pour le stockage objet
  • heat pour l’orchestration
  • et bien entendu nova pour le déploiement des instances

Nous apprenons à nous servir de la ligne de commande (et par un hasard fortuit également comment analyser les messages d’erreur d’OpenStack). On conclut cette journée en déployant une instance avec la ligne de commande nova, ce qui nous laisse entrevoir toutes les possibilités d’automatisation de déploiement, mais cela sera pour un prochain atelier.

Un grand merci aux organisateurs et aux sponsors qui ont permis la tenue de cet événement :

sponsorfinal2