• 26 mai 2016

    Retrouvez Oxalide au forum DRUPAGORA 2016

    L’équipe Oxalide participe à la 6ème édition du forum Drupagora : LE premier événement francophone sur Drupal dédié aux chefs de projets et DSI

    Rendez-vous sur notre stand pour échanger sur vos projets Drupal

    Vendredi 03 Juin 2016 de 8h15 à 18h

    Les thématiques développées au travers de conférences ou de retours d’expériences :

    • Pourquoi choisir Drupal plutôt que J2EE, .NET ou Symfony pour votre application métier
    • Drupal Commerce passe à Drupal 8
    • La battle Elastic vs Solr vs Solution propriétaire : le meilleur moteur de recherche Drupal
    • La refonte du site France Télévisions sur Drupal 8

    Bénéficiez de -10% sur votre entrée avec le code  SILVEROXALIDE2016

     

  • 18 mai 2016

    Paris Varnish Cache meet-up : Varnish, Tomcat et déploiement blue/green

    Théo Chamley, consultant architecture & DevOps chez Oxalide était speaker au dernier meet-up parisien dédié à Varnish organisé dans les locaux de Mobiskill.

    Retrouvez sa présentation : Varnish, Tomcat et déploiement blue/green

    Simplifier et fluidifier la mise à jour et le déploiement sur serveurs Tomcat derrière Varnish

     

    Retrouvez aussi ces articles rédigés par Théo Chamley : Tomcat clustering, Varnish and Blue/Green deployment – @oxalide Part 1 et Tomcat clustering, Varnish and Blue/Green deployment – @oxalide Part 2

  • 18 mai 2016

    Retrouvez Oxalide à l’AWS Summit Paris 2016

    Summit-Banner-728x90

     

    AWS Summit Paris, les inscriptions sont ouvertes.

    Nous sommes heureux de vous inviter à l’AWS Summit de Paris qui aura lieu le 31 mai 2016 au Carrousel du Louvre.

    Cet évènement gratuit d’une journée est destiné à faire découvrir à nos futurs clients la plateforme AWS ainsi qu’à partager avec nos clients existants des informations sur les nouveaux services du Cloud AWS. Les développeurs ne seront pas en reste avec une track technique qui leur sera dédiée. Vous pourrez en outre assister à des formations réalisées par les experts AWS et découvrir les bonnes pratiques utilisées par nos clients. Venez également rencontrer des utilisateurs de la plateforme avec lesquels vous pourrez échanger. Les places étant limitées, nous vous invitons à réserver votre place dès maintenant.

    Les sessions que l’AWS Summit vous propose : 

    • Adoptez le cloud maintenant pour préparer votre stratégie de demain
    • Repoussez les limites du développement
    • Bénéficiez du cloud maintenant; ils l’ont déjà fait, pourquoi pas vous ?
    • Créez une nouvelle chaine de valeurs et de nouvelles opportunités avec le Cloud AWS

    Nous vous donnons rendez-vous à 16h30 au Colyseum pour notre présentation : Design et exploitation de plateforme SAAS

    Vous pourrez rencontrer notre team sur notre stand de 8h à 19h , au plaisir de vous rencontrer.

    Découvrez l’agenda complet de cette journée.

    ,

  • 13 mai 2016

    Paypal renforce la sécurité de l’accès à ses API à compter du 16 juin 2016

    Paypal renforcera le niveau de sécurité requis pour communiquer avec ses services en forçant l’utilisation de TLSv1.2 et HTTP/1.1 pour les communications en HTTPS en désactivant TLSv1.0 et TLSv1.1.

    Ce niveau de sécurité sera obligatoire à compter du 17 juin 2016 (source 1) dans le cas contraire, ces services ne seront plus accessibles.

    La page Github TLS-update (source 3) indique des niveaux de versions requis selon les différents frameworks (java, .net,  php, python, ruby, node.js)

    Dans le cas de certains de ces frameworks, comme php, le support de TLSv1.2 dépend de la version d’openssl installée sur le système, openssl doit être au minimum en version version 1.0.1 ce qui signifie que les systèmes debian antérieur à la version wheezy (disposant d’OpenSSL 1.0.1e) ne permettront pas d’utiliser TLSv1.2

    Pour vérifier la version d’openssl installée :

    openssl version

    Pour vérifier si cette version support TLS et quelle version :

    openssl ciphers -v | grep TLS

    Dans le cas d’une version supportant TLSv1.2, vous devriez avoir un affichage similaire à :

    Capture d’écran 2016-05-12 à 12.08.41

     

    La page Github TLS-update (3) donne aussi un bout de code php permettant de tester l’accès à Paypal en TLSv1.2

    # il faut php5-curl installé
    php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'

     

    Références

    https://devblog.paypal.com/upcoming-security-changes-notice/

    https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1914&expand=true&locale=en_US

    https://github.com/paypal/TLS-update

     

    Article rédigé par Stéphane Clodic – ITWO WebOps Sénior chez Oxalide

  • 19 avril 2016

    Comment marier la sécurité et l’agilité dans une organisation web ?

    La sécurité est vue comme une contrainte qui ralentit le business. Traitée en bout de chaîne, elle intervient souvent de manière réactive et ne fait que combler des failles. Au-delà des contre-mesures, la bonne pratique est de traiter la sécurité en continu, c’est-à-dire du début jusqu’à la fin du projet. Le challenge est le suivant : »Comment marier la sécurité et l’agilité dans une organisation qui doit produire de plus en plus vite ? »

    Voici notre retour d’expérience qui vise à améliorer la sécurité au sein d’une organisation qui doit avoir des résultats.

  • 12 avril 2016

    AWS IAM – exemple avancé

    Oxalide gère un grand nombre de comptes AWS différents pour ses besoins internes et pour ses clients. L’industrialisation de la gestion des comptes AWS est donc un enjeu pour Oxalide. L’une des principales problématiques à laquelle nous sommes confrontés est la gestion des accès et des droits sur ces différents comptes. Ce besoin nous a amené à étudier en profondeur AWS Identity and Access Management (IAM), le service d’authentification et autorisation d’AWS.

    IAM est souvent délaissé à cause de sa complexité. C’est un service méconnu, mais qui permet de faire des choses très intéressantes pour la sécurité de son compte AWS et la gestion des ressources. J’ai récemment dû me pencher plus en détails sur IAM pour configurer un compte « bac à sable » dans lequel les utilisateurs doivent avoir des droits très larges, mais tout de même limités sur certains points :

    • accès minimal à IAM (i.e pouvoir changer son password),
    • accès interdits à certains services non-orientés « web »,
    • limité à eu-west-1 pour EC2,
    • limité à un certain type d’instance pour EC2.

    Voici la policy IAM finale :

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "iam:ChangePassword",
            "iam:GetAccountPasswordPolicy"
          ],
          "Resource": "*"
        },
        {
          "NotAction": [
            "iam:*",
            "devicefarm:*",
            "cloudtrail:*",
            "cloudhsm:*",
            "devicefarm:*",
            "directconnect:*",
            "aws-marketplace:*",
            "aws-marketplace-management:*",
            "mobilehub:*",
            "appstream:*",
            "gamelift:*",
            "mechanicalturk:*",
            "workdocs:*",
            "workmail:*",
            "workspaces:*",
            "wam:*"
          ],
          "Effect": "Allow",
          "Resource": "*"
        },
        {
          "Action": [
            "ec2:RunInstances"
          ],
          "Effect": "Deny",
          "Resource": "arn:aws:ec2:*:123456789000:instance/*",
          "Condition": {
            "StringNotLikeIfExists": {
              "ec2:InstanceType": [
                "t2.micro",
                "t2.small",
                "t2.medium"
              ]
            }
          }
        },
        {
          "Action": [
            "ec2:RunInstances"
          ],
          "Effect": "Deny",
          "Resource": "arn:aws:ec2:*:123456789000:instance/*",
          "Condition": {
            "StringNotLikeIfExists": {
              "ec2:region": [
                "eu-west-1"
              ]
            }
          }
        }
      ]
    }
    Lorsque AWS vérifie si un utilisateur a le droit d’effectuer une action, sa chaine de décision est la suivante :
    AWS_IAM oxalide
    Reprenons donc les différents statements pour analyse :
    • Changer son password
    {
      "Effect": "Allow",
      "Action": [
        "iam:ChangePassword",
        "iam:GetAccountPasswordPolicy"
      ],
      "Resource": "*"
    }
    Ce bloc, relativement simple, autorise l’utilisateur à changer son password.
    • Autorisation de la plupart des services

    {
      "NotAction": [
        "iam:*",
        "devicefarm:*",
        "cloudtrail:*",
        "cloudhsm:*",
        "devicefarm:*",
        "directconnect:*",
        "aws-marketplace:*",
        "aws-marketplace-management:*",
        "mobilehub:*",
        "appstream:*",
        "gamelift:*",
        "mechanicalturk:*",
        "workdocs:*",
        "workmail:*",
        "workspaces:*",
        "wam:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
    Ce bloc donne accès à la plupart des services AWS. On remarque la combinaison du « NotAction » et du « Effect: Allow ». Ce bloc fonctionne par négation : on autorise toutes les actions non listées ici. Autrement dit, on interdit toutes les actions listées ici.
    • Restrictions sur le service EC2

    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:*:123456789000:instance/*",
      "Condition": {
        "StringNotLikeIfExists": {
          "ec2:InstanceType": [
            "t2.micro",
            "t2.small",
            "t2.medium"
          ]
        }
      }
    },
    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:ec2:*:123456789000:instance/*",
      "Condition": {
        "StringNotLikeIfExists": {
          "ec2:region": [
            "eu-west-1"
          ]
        }
      }
    }

    Ces deux statements sont identiques, ils portent juste des conditions différentes. Plusieurs choses à noter :

    • L’action « Deny », qui malgré le « Allow » du bloc au dessus est appliqué, car évalué avant dans la chaîne de décisions.
    • Le bloc « Condition » qui pose, comme son nom l’indique, une condition sur la prise en compte du statement, ici un « StringNotLikeIfExists ». En traduisant en français, le bloc veut dire :
      • Sur la ressource concernée,
      • Si l’attribut « ec2:InstanceType » existe,
      • Et si l’attribut « ec2:InstanceType » est différent de « t2.micro », « t2.small » ou « t2.medium »
      • Alors Deny.

    Références

     

    Article rédigé par : Théo Chamley – Consultant Architecte DevOps chez Oxalide

  • 06 avril 2016

    Outils d’enquêteur pour analyser la webperformance en profondeur

    40% des personnes abandonnent un site qui met plus de 3 secondes à charger. Une seconde de délai entraîne jusqu’à 7% de réduction de conversion.
    Si un site e-commerce génère 100.000€ de chiffre d’affaires par jour, 1 seconde de délai induit potentiellement une perte de 2.5 millions d’euros chaque année.

    Katherine Daniel VelocityConf 2015 @beerops 

    Fort de ce constat, il est nécessaire d’adresser les problématiques de performance au cœur des enjeux business.

    Des connexions inégales face aux performances des sites

    La première cause de lenteur est le poids des pages du site. Théoriquement, voici le temps de chargement des pages en fonction de la connexion à Internet.

    Taille ADSL (2Mbs/s) 3G ADSL (24Mbs/s) Fibre
    500Ko 2s 0s 0s 0s
    1Mb 4s 1s 0s 0s
    5Mb 20s 5s 1s 0s

     

    Mais ce n’est que théorique, car pour apprécier la performance d’une page, la qualité de connexion est essentielle dans cet exercice. Tout le monde n’est pas en plein centre d’une grande ville où l’accès au haut-débit ou très haut-débit (ADSL, Fibre ou encore la 4G) est un standard. Et souvent, on oublie ces zones où les connexions ADSL et mobile sont présentes mais où la vitesse et/ou la stabilité d’accès au haut-débit font quelques fois défaut. Sans compter leur temps de génération, une bonne pratique DevOps vise à s’octroyer une charge utile (payload) maximum sur une page 500Ko. Au-delà de cette préconisation, mesurer et surveiller cet indicateur est nécessaire pour apprécier la balance « bénéfice et risque ».

    Optimiser les performances d’une page web : limiter les transactions avec le serveur

    Trouver les leviers de performance : s’outiller

    L’optimisation du poids peut se faire autour de fonctionnalités à optimiser. Elle se base sur de nombreux outils pour analyser la construction complète des pages. Ils nous aident à déceler des problèmes évidents de performance comme des fichiers statiques volumineux tels que les images mais également les ressources externes comme des javascript, les bannières publicitaires.

    Des sites comme www.webpagetest.orggtmetrix.com ou encore https://developers.google.com/speed/pagespeed/insights

    Une autre aide précieuse, celle du navigateur, disposant d’un mode développement qui analyse le temps de chargement d’une page.

    L’analyse de la construction des pages nous oriente dans les axes d’amélioration mais également de performance technique dans le choix de prestataires.

    Gratter quelques millièmes de seconde : le poids insoupçonné des requêtes DNS et des redirections

    Dans ce monde où chaque transaction, chaque bit, chaque appel compte, il y a des points dont on ne mesure pas suffisamment l’impact : les requêtes DNS et les redirections.

    Les nombreuses requêtes DNS, l’idée étant de réduire au maximum l’appel à des ressources extérieures, il est également possible en HTML au navigateur de ne faire la résolution DNS qu’une fois pour une liste de ressources données. En effet, une requête DNS par ressource externe induit des requêtes inutiles et donc contre-performantes.

    L’idée étant d’indiquer au navigateur la liste des domaines présents dans la page afin de pré-résoudre les requêtes une fois pour toutes.

    <html>
      <head>
        <link rel="dns-prefetch" href="//www.domain1.com">
        <link rel="dns-prefetch" href="//www.domain2.com">
      </head>
      <body>
        <img src="www.domain1.com/image1.jpeg">
        <script src="www.domain2.com/script1.js">
      </body>
    </html>

     

    Les redirects, on ne se rend pas forcément compte quand on navigue sur internet , mais bien souvent , une simple page web est composée d’énormément de liens qui finissent parfois par des enchaînements de redirections. Par exemple les liens de tracking de Google peuvent rediriger jusqu’à 4 fois l’internaute.

    Grâce aux graphiques de bande passante et de l’utilisation du CPU fournis par www.webpagetest.org il est possible de voir à quel moment du chargement de la page ces ressources ne sont pas correctement utilisées.

    D’une manière générale ce sont les ressources javascript qui consomment le plus de CPU , c’est pour cela qu’il est conseillé dans la mesure du possible de charger ces éléments à la fin de la page et ainsi privilégier le rendu client.

    Un site web non optimisé

    Un site web optimisé
    web-perf-optimise

    Au-delà des performances brutes, il faut bien prendre en considération que ces petites améliorations permettent bien souvent de mettre en avant son site sur les moteurs de recherche.

    Communément appelé le référencement naturel, il s’agit bien là de trouver sa place sur ces moteurs, gratuitement.

    Ne transférez pas plusieurs fois la même donnée : accélérer avec le cache

    Le cache est le mécanisme pour livrer rapidement un élément sans repasser par la case transfert dans notre cas. Il existe deux niveaux de cache utilisables, celui navigateur (Chrome, Firefox, Safari, Opéra, …) et Varnish.

    • Le cache navigateur  » La mise en cache de document Web (ex : page web, images) est utilisée afin de réduire la consommation de bande passante, la charge du serveur web (les tâches qu’il effectuent), ou améliorer la rapidité de consultation lors de l’utilisation d’un navigateur web. Un cache Web conserve des copies de documents transitant par son biais. Le cache peut, dans certaines conditions, répondre aux requêtes ultérieures à partir de ces copies, sans recourir au serveur Web d’origine. » Source Wikipédia.
    • Le cache Varnish :  » Varnish est un serveur de cache HTTP apparu en 2006 et distribué sous licence BSD. Déployé en tant que proxy inverse entre les serveurs d’applications et les clients, il permet de décharger les premiers en mettant en cache leurs données, selon des règles définies par l’administrateur système et les développeurs du site, pour servir plus rapidement les requêtes, tout en allégeant la charge des serveurs. » Source Wikipédia.

    Pour le navigateur : c’est le « header expire » défini dans la RFC 2616 qui permet de définir la validité dans le temps d’une ressource. Interprété par les navigateurs, elle permet aux clients web de conserver les éléments statiques (Images, css, html, javascript) dans le cache (Stocké sur le disque dur).

    Ainsi, si une ressource est appelée dans une autre page le navigateur n’ira pas interroger le serveur et économisera ainsi énormément de temps.

    Par exemple, lorsque l’index d’un site Magento avec les images, les feuilles de style et javascript est téléchargé une fois. Au prochain appel, si le « header expire » indique une date supérieure à l’instant présent, alors mon navigateur n’ira pas redemander la ressource mais utilisera celle qu’il a mémorisée.

    Pour ce faire, il faut activer le mod_expire dans Apache. La configuration peut se réaliser de 2 manières soit dans la configuration d’Apache ou en ajoutant dans le .htaccess à la racine du site :

    /etc/apache2/sites-enables/monsite.fr ou .htaccess

    <IfModule mod_expires.c>
    # Enable expirations
    ExpiresActive On
    # Default directive
    ExpiresDefault "access plus 1 month"
    # My favicon
    ExpiresByType image/x-icon "access plus 1 year"
    # Images
    ExpiresByType image/gif "access plus 1 month"
    ExpiresByType image/png "access plus 1 month"
    ExpiresByType image/jpg "access plus 1 month"
    ExpiresByType image/jpeg "access plus 1 month"
    # CSS
    ExpiresByType text/css "access plus 1 month"
    # Javascript
    ExpiresByType application/javascript "access plus 1 year"
    </IfModule>

    Il est plus commode d’utiliser un fichier .htaccess car le fichier est directement accessible à un développeur pour modifier la configuration des durées de rétention.

    Imaginons, nous sommes le 10 février 2016 avec la configuration ci-dessus, le header renvoyé pour toutes images et css sera : Expires : Tue, 10 Mar 2016 12:08:08 GMT

    Pour Varnish : le « header expire » est également interprété, lorsqu’un client A télécharge depuis le serveur une image qui sera immédiatement stockée en RAM dans Varnish le temps du « expire  » pour les clients suivants. Cela garantit une réponse rapide des statiques, il faut ici imaginer qu’il agisse comme un cache navigateur mutualisé. Un premier visiteur télécharge une page produit sur un site marchand avec ces images, feuilles de style, javascript. Varnish mémorise le retour que lui fait le serveur web sur les requêtes du type GET sans paramètre le temps du « expire » indiqué. Ainsi le second visiteur qui télécharge la même page produit verra les éléments statiques renvoyés par Varnish sans computing (intelligence CPU) que génère les serveurs web.

    Aucune configuration d' »expire » est nécessaire car le « header expire » est natif dans Varnish, en revanche il est possible de récupérer le header cache-contrôle renvoyé par certains applicatifs comme Drupal:

    /etc/varnish/default.vcl

    if (resp.http.cache-control ~ "max-age=" ) {
            set resp.http.Expires = "" + (now + std.duration(regsub(resp.http.cache-control,"max-age=([0-9]+).*$","\1")+"s", 0s));
    }

     

    Des solutions côté serveur : le HTTP/2 et le SaaS

    Ces modifications sont bien souvent à appliquer côté client (développement), notre position de DevOps nous oblige à travailler avec le client pour améliorer ces points.

    Le HTTP/2 issu du travail sur le protocole parent SPDY est de plus en plus implémenté sur les navigateurs modernes. En revanche Apache et Nginx les serveurs web les plus populaires, ne supportent pas officiellement ce protocole sauf par le biais de modules tiers expérimentaux.

    Il est pour le moment risqué d’implémenter uniquement ce protocole directement en production, mais néanmoins nécessaire de préparer dès à présent la transition.

    Le module Apache/Nginx PageSpeed développé par Google permet à la volée, de compresser et minifier les images, javascript, CSS. Il est intéressant et même indispensable de coupler ce module avec un système de cache HTTP type Varnish. D’autant plus qu’il intègre une gestion des headers expirés utilisée par défaut par Varnish pour la durée du cache des objets.

    Si le souci de performance est au centre de la préoccupation client et que malheureusement il n’a pas les moyens d’améliorer la situation, il existe des services comme Fasterize qui est un reverse proxy – cache qui fait de la compression de données et l’optimisation de réseau avec le support du protocole HTTP2 par exemple.

    Article rédigé par Adrien Le Priol, ITWO chez Oxalide.

  • 30 mars 2016

    Oxalide accompagne 20 Minutes dans sa stratégie « mobile first » qui réalise des records d’audience

    En seulement quelques années, 20 Minutes s’est hissé à la 2ème  place des marques de presse en France. Avec une augmentation de trafic de +172% en 2015, 20 Minutes bat des records d’audience sur son site mobile. Des performances que la marque doit notamment à son orientation stratégique majeure mobile first, menée tambour battant avec les experts d’Oxalide.

    20 Minutes…

    Avec plus de 17,7 millions d’utilisateurs* chaque mois, print, web mobile et tablette, 20 Minutes s’est imposé dans le paysage médiatique français. En quelques années, 20 Minutes est devenu la marque d’info la plus puissante sur la cible 15-49 ans. Au coeur de son projet, le jeune actif urbain auquel 20 Minutes délivre chaque jour, chaque seconde, une info utile, pertinente et accessible.

    … et toujours quelques secondes d’avance

    Avec une audience du site mobile en hausse de +113%** en 2015, 20 Minutes a réalisé la meilleure progression de l’univers info.

    Les scores d’audience exemplaires et en forte croissance ces deux dernières années, confirment la stratégie mobile prioritaire du groupe, à destination de ses lecteurs suréquipés et particulièrement jeunes. En effet, cette croissance est principalement portée par le mobile qui représente désormais plus de 57% du trafic numérique.

    Afin de rester visionnaire et se doter des moyens d’innover

    En 2007, 20 Minutes confie à Oxalide le déploiement de son site mobile, miroir du site web. Puis rapidement, de nouveaux besoins sont identifiés :

    « Les technologies et les usages changent, nous avons misé sur le mobile et les applications, en parallèle de la fusion de nos rédactions. Cela signifiait notamment refondre entièrement notre back office », se souvient Winoc Coppens, DSI de 20 Minutes.

    20 Minutes cherchait plus de cohérence dans ses supports et la convergence de son information, pour répondre aux usages des multi-readers. Il était donc essentiel de renouveler les outils éditoriaux, de se mettre à jour techniquement, d’adapter l’architecture informatique à l’augmentation annuelle de l’audience, mais également de mettre en œuvre des processus pour faire face à l’imprévisibilité de l’actualité.

    « L’important est de délivrer l’information. Il faut rester performant quoiqu’il arrive. » souligne Winoc Coppens.

    Pour répondre au triple challenge de réussir la migration, gagner en performance et supporter les montées en charge.

    « Oxalide a été très actif sur toutes ces questions » souligne Winoc Coppens. Les équipes d’Oxalide ont récupéré l’ensemble du contenu et effectué la migration sans aucune incidence sur l’utilisateur final, tout en conservant le bon référencement des pages.

    Avec un CMS développé chez 20 Minutes, optimisé et supervisé par Oxalide,  la production de contenus est devenue plus riche, mieux référencée mais également mieux partagée en interne. La maîtrise de l’outil par les équipes de rédaction place 20 Minutes en tête de la diffusion de l’information, notamment pour les événements de grande ampleur.

    C’est en travaillant à la performance de l’outil avec Oxalide que le journal a constaté une nette amélioration du trafic.

    Afin de faire face sereinement aux pics de charge, disposer d’une architecture capable d’absorber d’importantes montées en charge relevait d’une exigence forte. Outre la fiabilité des outils et des matériels mis à disposition par Oxalide et le savoir-faire de ses équipes, la parfaite tenue des plateformes de 20 Minutes repose sur une organisation millimétrée.

    Evénements prévisibles ou non, un dispositif spécifique est mis en œuvre. Les équipes du journal comme de l’infogéreur sont en contact quasi permanent.

    Si les équipes en interne chez 20 Minutes sont maintenant bien rodées, les experts Oxalide monitorent le système en temps réel pour offrir l’appel d’air nécessaire, au besoin. C’est à la minute que les ingénieurs déterminent l’interruption d’un dispositif ou l’ajout d’un serveur.

    Pour Winoc Coppens « C’est appréciable de travailler avec les équipes d’Oxalide. Elles ont l’expérience et le calme nécessaire dans ces moments de très grande pression. »

  • 24 mars 2016

    Tomcat clustering, Varnish and Blue/Green deployment – @oxalide Part 2

    Part 2 – Varnish

    Previously on part 1 : http://goo.gl/mpXbmU

    In part 1, we set up a Tomcat cluster with parallel deployement and cluster-wide deployment. Go back to the first part if you have not read it, this article assumes that you have read it.

    Installing Varnish in front of everything

    Now, let’s install Varnish. For this to work, you need the curl vmod. Installing this vmod is outside the scope of this post, so it is assumed that it is already installed.

    As a reminder, the problem we have is that the cache of the 2 versions of the app will be mixed up in Varnish since they have exactly the same URLs.

    The solution

    The solution for this is to modify the vcl_hash function in Varnish and to introduce the app’s version in the objects identifiers in the cache. 

    Here is how the function looks like:

    sub vcl_hash {
            hash_data(req.url);
            hash_data(req.http.host);
            if(req.http.X-Version) {
                    hash_data(req.http.X-Version);
            }
            return(hash);
    }
    
    Of course, now we have to fill this "X-Version" header with some data. Here is the code you need:
    import std;
    import curl;
     
    acl trusted {
        "10.0.0.0"/24;
    }
     
    sub vcl_recv {
    	[ ... some stuff ... ]
    	if ((req.url ~ "^/version"  && client.ip !~ trusted) {
    		error 403 "Forbidden";
    	} elsif (req.url ~ "^/version")  {
    		return (pass);
    	}
    	[ ... some stuff ... ]
    	call app_version;
    	[ ... some stuff ... ]
    	return(lookup);
    }
    sub app_version {
            if (req.http.Cookie ~ "version=") {
                    # If there is a version cookie, then we use it
                    set req.http.X-Version = regsub(req.http.Cookie, ".*version=([^;]+).*", "\1");
            } else {
                    # If there is no such cookie we call the app to determine the last version
                    curl.set_proxy("");
                    curl.header_add("Host: "+req.http.host);
                    curl.get("http://localhost/version");
                    if (curl.status() == 200) {
                            set req.http.X-Version = curl.body();
                            curl.free();
                    } else {
                            curl.free();
                            std.log("Got an error "+curl.error()+" from version API: generating a 500 error.");
                            error 500 "Internal Server Error";
                    }
            }
    }

    Let’s walk through this:

    • The app_version function does the following:
      • If the request comes with a « version » cookie, then we use the value of this cookie to fill the « X-Version » header that will be used in vcl_hash.
      • Else, we make a call to an API in the Tomcat app that returns the version of the application:
        • This calls has to go through Varnish again (that’s why we call « http://localhost/version ») to use the load-balancing provided by Varnish. If we do not request through Varnish again, we have no garanty that the chosen backend is healthy.
        • As this call has no Cookie (thus, no session), it will be answered by the newest version of the app available in Tomcat.
    • The vcl_recv function must include:
      • A restriction on the API. It’s an internal API and must not be accessible from outside. The answer to this call must also not be cached.
      • Of course, a call to app_version.

    App requirements

    For this to work, a few things must be implemented in the app:

    1. It must be able to answer the API call.
    2. The version number must be different for each WAR file deployed in Tomcat.
    3. The app must place a Cookie called « version » which has the same value as the API answer on users that do not alread have it. This way, Varnish will call the API only for new users that have no cookies.

    + Astuce : the caching policy is here implemented in the app: it sends the responses with the right Cache-Control headers to tell Varnish what to cache and for how long.

    ! Avertissement : a lot of the VCL code has been stripped from this example. You still have to implement the rest of the configuration around this. This depends on your app.

    Varnish_app_version_handling

    Results

    Here is a graph of the trafic on one of our Varnish servers during a deployment.

    image2015-8-10 10-35-36

     

    The deployment was made just after 9a.m. You can see a (very) little drop in the hit rate on Varnish. This is because new users arrive on the new version of the app and Varnish has no cache for this new version. But since at this moment most of the users still are on the old version, Varnish still serves most of the requests from its cache. As time passes, the cache for the new app warms up and more and more users are on the new app. The two processes (cache warmup and trafic transition to the new app) naturaly occurs at the same time, keeping the hit rate in Varnish high. On this infrastructure, the old app is usually undeployed 30 minutes after the new one was deployed.

    Article rédigé par : Théo Chamley – Consultant Architecte DevOps chez Oxalide

  • 23 mars 2016

    Tomcat clustering, Varnish and Blue/Green deployment – @oxalide Part 1

    Prerequesites :

    →To best understand, you should know what Varnish is (a caching reverse-proxy), its basics (VCL, hash, etc.) and have a simple understanding of Tomcat.

    →The software versions used in this post are: OS Debian 7 |Tomcat >= 8.0.15 |Apache 2.2 |Varnish 3.0.x |vmod curl  –  It should work without much adaptation on other distros.

    At Oxalide, we aim to provide the best possible uptime to our customers while encouraging them to adopt an agile workflow where they push new versions of their apps often and seemlessly.

    Because most of our clients are using PHP (or Ruby), we usually help them to setup Capistrano: it’s efficient and there are a lot of plugins for different frameworks (capifony for instance). Varnish is also quite often in our list of requirements, because of its sheer capacity to absorb trafic and deliver content.

    When UGC came to us with their Java app, they had a set of strong requirements in response to which we had to innovate. With Alteis, their developpers, we set up a way to easily deploy apps in their Tomcat cluster while using Varnish in front of the whole infrastructure. On an infrastructure like UGC’s, Varnish is mandatory if we want to keep the number of servers used reasonable. It also allows us to (greatly) lessen the load when there is a lot of  trafic (typically, on rainy days for cinemas!).

    I will try to demonstrate how you can setup Varnish in front of a Tomcat cluster using Blue/Green deployment (known as Parallel Deployment in Tomcat parlance).

    The goal here is to provide the following functionalities:

    • Being able to deploy an app in a Tomcat cluster by a simple operation,
    • Doing so without any downtime,
    • Having a good caching policy in Varnish (i.e, being able to cache more than just static files).

    Part 1 – Tomcat

    Analysis

    Because we don’t want to reinvent the wheel, the best is to use tools and methods that already exist. With this in mind, Tomcat already provides a lot of the functionnalities we need:

    Let’s talk a little about parallel deployment. It allows you to deploy multiple apps under the same URL. You can use it to upgrade an app: just deploy the new version under the same URL and new users are going to use the new version while users with sessions on the old version will stay on the old version. When all users are on the new version, you can delete the old one.

    ! The problem

    The problem you now have is that you want to use Varnish and by default Varnish identifies objects to cache by their URL. As app 001 and 002 have exactly the same URLs, their cache will be mixed up and the result will be desastrous: Varnish will serve a mix of app 001 and 002 to users.

    To solve this problem, we will isolate the cache of both versions of the app and identify which version is used by a given user.

    Implementation

    Set-up of a Tomcat cluster and cluster-wide deployment

    As long as you can use multicast in your environment (which is NOT the case in some popular public cloud offers), this is pretty straightforward. In your tomcat’s server.xml, you can define it either in the « Engine » node (which will make the whole Tomcat member of the cluster), or in a « Host » node (which will make only this virtual host member of a cluster). I advise you to choose the later because you can then configure the FarmDeployer which allows you to deploy a webapp in your whole cluster.

Newsletter

Inscrivez-vous et tenez vous au courant de l’actualité Oxalide