• 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.

  • 16 mars 2016

    Les best-practices de SushiShop lors de ses grands rendez-vous commerciaux

    L’atelier d’Oxalide au salon e-commerce one-to-one de Monaco

    Oxalide est partenaire du salon e-commerce one-to-one du 23 au 25 mars 2016 à Monaco et animera un atelier de retour d’expériences le vendredi 25 mars à 10h en partenariat avec SushiShop.

    L’atelier « Comment SushiShop maximise ses ventes lors de ses grands RDVs e-commerce »  animé par Nikola Petrovski, responsable de l’offre e-commerce chez Oxalide, se tiendra le 25 mars 2016 à 10 heures Salle Auric 2, et reviendra sur les aspects essentiels de la nécessaire modernisation du e-commerce.

     Avec le témoignage de Gwénaël Robert, Directeur e-commerce Sushishop, Nikola Petrovski présentera les best-practices autour de la gestion des grands rendez-vous commerciaux. Saint Valentin, week-ends, événements sportifs… exigent, pour devenir des succès commerciaux, de la méthodologie et une organisation souple et réactive.

    Comment impliquer les équipes marketing et e-commerce dans le processus, aux côtés des équipes techniques ? Quels KPIs partager ? Quel processus définir avec son hébergeur ? L’atelier fera le point sur tous les facteurs clés pour garantir le succès de ses grands RDVs e-commerce.

    L’expertise Oxalide au service du e-commerce

    Avec des équipes d’ingénieurs « WebOps » naturellement sensibilisés à l’e-commerce, Oxalide possède le savoir et le savoir-faire pour améliorer la capacité de trafic d’une plateforme pendant les soldes, le temps de chargement des pages, la recherche et l’indexation d’un volume important de produits, le déploiement de boutiques à l’international par l’industrialisation…, afin de permettre à leurs clients de répondre à leurs enjeux digitaux et concentrer leurs forces sur leur cœur de métier.

    Les équipes Oxalide seront présentes pendant les 3 jours pour apporter des réponses concrètes et adaptées dans l’accompagnement de service web à fort trafic.

    E-Commerce one-to-one est le rendez-vous d’affaires des leaders du e-commerce, pour sa 6ème édition, ce rendez-vous incontournable pour tous les acteurs du marché, réunira tous les dirigeants du secteur autour de 6 conférences plénières, 110 ateliers experts et 3000 rendez-vous d’affaires. http://www.ecommerce1to1.com/

     

  • 15 mars 2016

    Retrouvez @Oxalide au salon Agora CMS

    logo-AgoraCMS

    L’équipe Oxalide sera présente sur lédition 2016 du Salon Agora CMS qui se déroule le Vendredi 1 Avril 2016 à la Maison des Associations de Solidarité dans le 13ème arrondissement de Paris de 9h00 à 18h00. Réservé aux professionnels, vous y rencontrerez principalement des chefs de projet, DSI, direction de communication et autres profils moins techniques.

    La journée s’articulera autour de nombreuses conférences, ateliers, démos et tables rondes animés par un panel d’experts reconnus sur le marché autant sur des problématiques techniques et métiers des CMS. Comme par exemple :

    • CMS et médias : l’entente impossible ? – Rue 89 – Radio France – Le Monde
    • Un projet d’accessibilité réussi avec SNCF réseau par Sébastien DELORME – Webtales & Jérémie JURAVER – SNCF
    • Comment Drupal Commerce innove avec Drupal 8 par Anne-Sophie PICOT – Commerce Guy’s
    • Le choix du bon prestataire avec une évaluation financière réaliste par Maxime TOPOLOV – Adyax
    • Le choix d’un CMS dans un contexte agile par Christophe NEY – Agence Interactive

    Voir le programme complet

    Vous souhaitez participer à l’édition 2016, inscrivez-vous gratuitement, et venez échanger avec nous sur vos projets digitaux !

     

     

  • 15 mars 2016

    Oxalide Academy #3 : Workshop Elastic Search

    Vous avez été nombreux à vous inscrire à la 3ème édition d’Oxalide Academy. Après les 2 précédents ateliers Varnish, c’est autour d’Elastic Search de passer entre les mains d’Oxalide (Ludovic Piot) avec Kernel 42 (Edouard Fajnzilberg). Compte tenu des places limitées, nous avons pu accueillir que 26 personnes pour garantir une qualité dans les interactions de l’atelier. Pour ceux qui souhaitent voir ou revoir, la présentation est maintenant disponible.

    A bientôt pour la 4ème édition.

  • 09 mars 2016

    AWS ELB Best Practices

    Cross-Zone

    La première fonctionnalité importante au niveau des ELB est appelée cross-zone.

    Celle-ci permet de répartir la charge sur plusieurs AZ en tenant compte du nombre d’instances sur chaque AZ. La répartition n’est donc pas simplement effectuée entre chaque AZ.

    Par exemple nous disposons de 4 instances sur la zone A et de 2 instances sur la zone B. Sans l’activation de cette fonctionnalité, le trafic serait réparti de manière égale sur les deux zones. Les instances de la zone B étant moins nombreuses la charge serait donc plus importante sur ces instances.

    aws elb best pratices oxalide

    aws elb best practices oxalide

    Pre-Warming

    Le service AWS ELB est un service flexible. En effet, celui-ci évolue en fonction de son utilisation. Concrètement, si votre trafic augmente progressivement, les ressources allouées au service ELB évolueront également afin de pouvoir absorber l’augmentation du trafic.

    Cependant si le trafic augmente de manière importante, il est possible que l’augmentation des ressources au niveau de l’ELB ne soit pas assez rapide. Dans ce cas, le service ne sera pas en mesure de traiter l’ensemble des demandes. Ce qui aura pour conséquence l’apparition d’erreurs 503. Ce fonctionnement peut donc être très contraignant notamment lors de test de charge.

    Pour cela AWS met à disposition une fonctionnalité de pre-warming. Celle-ci va donc nous permettre en amont d’augmenter les ressources d’un l’ELB en prévision d’un pic de trafic. Il faut pour cela contacter le support AWS.

    Health-check

    Un autre point important concerne la fonctionnalité « Healt-check ». Cette fonctionnalité permet de détecter un disfonctionnement sur un serveur de backend. En cas d’erreur, le trafic ne sera plus redirigé vers ce serveur.

    Il ne faut donc pas négliger cette partie. En effet, en cas de mauvaise politique de « healt-chek », le trafic pourra toujours être envoyé sur un backend alors que celui-ci est non fonctionnel.

    En fonction des besoins il est donc recommandé d’effectuer des test de validation plus lourd en les espacent, plutôt que des tests rapide mais très rapprochés.

    Il faut donc bien définir vos besoins. Avez-vous besoin d’une page légère qui effectue une vérification fréquemment afin de vous assurer que le serveur web répond correctement ou à l’inverse avez-vous besoin d’une page plus évoluée avec une fréquence moins importante, mais qui vérifie que toutes les parties de votre application fonctionnent correctement

    Monitoring

    Lors de cette conférence, il a été montré qu’il est également très important de monitorer le service ELB. Pour cela AWS CloudWatch fournit un nombre intéressant de sondes :

    • Latence
    • Nombre de requêtes
    • Hosts actifs
    • Hosts inactifs
    • Nombre de requêtes en status 2xx-5xx sur le backend.
    • Nombre d’erreurs 4xx et 5xx

    Ces métriques peuvent également être exploitées grâce à une stack ELK.

    Article rédigé par Mathieu Cassan – RTE chez Oxalide

Newsletter

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