Le fonctionnement

Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

Le principe de Varnish s’appuie sur la machine à état suivante :

Varnish permet d’intervenir au niveau de chacun des états pour effectuer des opérations sur HTTP ou sur lui-même. C’est cette finesse d’intervention qui permet à Varnish d’être véloce et complet.

Un client effectue une requête sur une ressource qui n’est pas en cache suivra le cheminement suivant :

Si cette ressource est demandée à nouveau, le chemin suivi change car la ressource est maintenant en cache :

Toutes ces étapes sont symbolisées en VCL par des “procédures standards” (vcl_recv, vcl_fetch, vcl_deliver… etc). Toutes ces procédures sont surchargables et nous pouvons aussi déclarer les nôtres qui seront appelées dans les procédures standards. Le langage VCL ne tolère aucun code orphelin, tout ce qui est déclaré doit être utilisé.

Le Cache

Varnish propose un cache en mémoire et un cache sur disque. Mais il faut faire un choix, les deux ne sont pas cumulables. Le cache accepte à peu près tout ce qui passe dans les mains de Varnish (pages HTML, fichiers statics, flux de données en JSON… etc), à partir du moment où l’on déclare l’objet cachable et qu’il a une TTL.
Le cache est alimenté juste après l’étape “Fetch”, en réalité c’est juste après la récupération de la donnée sur le backend. C’est à cet endroit que l’on va faire toutes les modifications de l’entête HTTP de la ressource cachée. Faire ces modifications au niveau du “Fetch” va permettre de garantir une entrée cache propre (ne pas avoir plusieurs entrées cache car une même ressource va avoir un payload différent). De plus l’objet est stocké dans le cache avec son entête HTTP, il est donc plus efficace de traiter une fois pour toute l’entête et la resservir avec l’objet.
Comme nous le verrons plus loin, la compression d’objet influe aussi sur les performances du cache. Il est préférable de stocker un objet compressé et laisser Varnish le délivrer compressé ou non suivant l’entête “Accept-Encoding”.

La définition correct de la TTL d’un objet pour manager le cache-control est un élément important de Varnish. Nous pouvons contrôler le cache de façon précise en définissant la TTL pour un type de ressource ou pour une url par exemple :

if(beresp.ttl > 0s){
  unset beresp.http.Expires;
  if ( req.backend == backend_S3 ) {
     set beresp.http.Cache-Control = "public, max-age=60";
     set beresp.ttl = 60s;
  } else {
     set beresp.http.Cache-Control = "public, max-age=7200";
     set beresp.ttl = 2h;
  }
}

Ici nous demandons à Varnish de cacher sur 60 secondes tout ce qui vient de le backend “backend_S3” et le reste sera caché deux heures.

Le cache peut se manager de deux façons différentes :

La Compression

Depuis la version 3.0, Varnish a la possibilité de compresser et décompresser des ressources. Cette fonctionnalité est importante pour 3 raisons :

Elle peut être activée simplement en harmonisant l’entête “Accept-Encoding” et en positionnant la variable “do_gzip” au niveau du backend ou de la réponse du backend. Pour le reste Varnish va adapter la réponse (objet compressé ou non) au client en s’appuyant sur le “Accept encoding” de la requête.
Il est bien sûr évident que la stratégie de compression doit être adaptée au type d’objet. On ne compressera pas un objet déjà compressé (gif, jpg…etc) :).

Le Loadbalancing

Varnish peut gérer des backends de tous horizons. Avec des sites de plus en plus chargés, il est capable d’offrir la possibilité de faire du loadbalancing. Varnish dispose de 3 types de loadbalancing qui sont appelés “Director” :

Varnish sait gérer l’éviction d’un backend lorsqu’il est indisponible. Cette fonctionnalité est d’autant plus utile quand nous activons le “probe” sur les backends.

backend server1 {
   .host = "server1.example.com";
   .probe = {
     .url = "/";
     .interval = 5s;
     .timeout = 1s;
     .window = 5;
     .threshold = 3;
   }
}

Varnish dispose aussi d’un mécanisme pour palier complètement à la défaillance d’un backend ou d’un Director. Nous appelons cela “Grace mode” ou “Saint mode”. Ces termes cachent la possibilité de servir un contenu caché même x minutes après la TTL en cas de non réponse d’un serveur. Il est aussi capable d’aiguiller une requête vers un autre serveur répondant correctement quand le serveur cible initial donne des réponses HTTP 500 à cause d’une trop grande charge par exemple.

Reverse Proxy

Nous avons vu que Varnish se place devant toute notre infrastructure. Il va permettre de masquer complètement l’architecture déployée en utilisant toute la puissance de Reverse Proxy qu’il met à notre disposition.

En fait, il nous permet de faire un découplage complet entre l’organisation des URIs d’appels et l’organisation de leurs traitements sur l’infrastructure.

Voici un exemple d’une requête cliente que nous arrivons à aiguiller avec Varnish vers un bucket S3 public du nom de “ressources” et l’aiguillage prend en compte ce qu’il y a dans le nom du host de la requete :

set req.backend = backend_s3;
if(req.url == "/ressources1.xml") {
  set req.url = regsuball(req.http.host,
              "^(?:.*[.])?([a-z]+)[.](?:net|com)$", "/ressource1.\1.xml");
}else if(req.url == "/ressource2.txt") {
  set req.url = regsuball(req.http.host,
              "^(?:([a-z]+)[0-9]*[.])(?:([a-z]+)*[.])[a-z]+$","/ressources.\1.\2.txt");
}
set req.http.host = "resources.s3.amazonaws.com";

backend  backend_s3 {
  .host = "ressources.s3.amazonaws.com";
  .port = "80";
  .connect_timeout = 5s;
  .first_byte_timeout = 3s;
  .between_bytes_timeout = 2s;
  .max_connections = 1000;
}

Sécuriser et nettoyage HTTP

Le protocole HTTP permet d’utiliser plusieurs types de méthodes (GET, POST, DELETE… etc). Ces méthodes peuvent être utilisées de différentes manières pour déclencher des actions spécifiques (cas de services REST) sur les services abrités sur les backends. Or la protection au niveau HTTP de ce genre de services est assez fastidieuse côté serveurs d’applications. Varnish va permettre de filtrer précisément ce qui doit passer et pour quelle utilisation. Nous allons donc limiter les effets de bords.
Imaginons que nous avons un service accessible uniquement en GET /service1/ et un deuxième /service2/ accessible lui en GET et POST nous allons écrire quelque chose comme ceci :

if (req.request != "GET" && req.request != "POST"){
  call error;
}

if (req.url ~ "^/service2"){
call service2;
}

if(req.request == "POST"){
  call error;
}

if (req.url ~ "^/service1"){
  call service1;
}

call error;

Dans cet exemple nous interdisons systématiquement tout ce qui n’est pas méthode GET ou POST. Ensuite pour une url qui commence par /service2 nous allons vers la routine qui va traiter le payload pour ce service. Puis nous bannissons la méthode POST et nous traitons les urls avec /service1 et enfin nous bannissons le reste.

Avec cette méthode aucune requête non prévue peut remonter vers un backend. Nous avons deux avantages :

Dans un deuxième cas de figure il peut être intéressant de normaliser les entêtes HTTP. Prenons l’exemple de l’Accept-Encoding. Varnish préconise de le normaliser ainsi :

if (req.http.Accept-Encoding) {
  if (req.http.Accept-Encoding ~ "gzip") {
    set req.http.Accept-Encoding = "gzip";
  } elsif (req.http.Accept-Encoding ~ "deflate") {
    set req.http.Accept-Encoding = "deflate";
  } else {
    remove req.http.Accept-Encoding;
  }
}

Tout simplement pour éviter de créer des entrées cache différentes pour un même payload uniquement parce que tous les clients n’écrivent pas cet entête de la même façon.

Nous pouvons aussi enlever certains headers qui peuvent donner trop d’informations sur l’infrastructure. Pour S3 par exemple nous allons passer ces commandes dans le fetch :

unset beresp.http.x-amz-id-2;
unset beresp.http.x-amz-request-id;
unset beresp.http.x-amz-meta-s3cmd-attrs;
unset beresp.http.x-amz-meta-s3fox-filesize;
unset beresp.http.x-amz-meta-s3fox-modifiedtime;

Ou positionner des entêtes plus personnelles :

set beresp.http.Server = « ServeurPerso »;

La dernière petite chose à penser pour le nettoyage réside dans le positionnement d’un content-type correct pour toutes des ressources. Cette opération se fait de la même manière que pour le nettoyage des headers en positionnant “set beresp.http.Content-Type” par groupe de ressources.

De par ces fonctionnalités, Varnish est capable d’assurer l’orchestration de la haute disponibilité d’une architecture. Il est capable de détecter les backends défaillants et même de les remplacer en s’appuyant sur son cache. Il va les protéger en prenant en compte une grande partie de la gestion des erreurs 404.

Uniformisation des Logs d’accès

Le process “varnishd” ne produit aucun log. Il se contente d’écrire les informations dans des segments de mémoire partagée. Ces segments sont consommés par des outils comme varnishadm, varnishlog ou encore varnishncsa. C’est principalement varnishncsa qui nous intéresse. C’est ce process qui va lire les informations et créer un fichier de log au format NCSA. L’avantage ici est énorme. Nous pouvons décharger les serveurs d’applications et front http de la production de ces logs. De plus ces logs seront moins éparpillés (quoi que, avec l’utilisation de syslog-ng ça ne soit pas un problème). Enfin les logs seront tous normalisés qu’ils soient sur Apache, Tomcat, JBoss ou encore lighttp et NginX. Nous pouvons donc penser uniquement aux traitements que nous allons bien pouvoir leur faire subir et ne plus passer du temps à tout reformater. Cette considération prend tout son sens quand on commence à atteindre plusieurs gigas de logs d’accès par jour.
Depuis la version 3.0, Varnishncsa permet de ne pas suivre la norme NCSA et nous laisse le choix du format de sortie.

Laurent ROUX

Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.

Dans le but de rester élastique dans la démarche, nous allons utiliser deux fonctionnalités DNS des plus intéressantes qui sont :

Nous allons aussi nous aider des API Amazon et tout ça dans un environnement Linux. Notre DNS va donc servir de base de données pour référencer les machines via leurs IP privées.

Liste des pré-requis

Un serveur T1-Micro sur Amazon servant de DNS est largement suffisant. Le package BIND9 doit être installé. Sachant que sur une infrastructure nous préférons utiliser des noms à la place des IP, l’utilisation d’un DNS est fortement conseillée. De plus, la configuration des différents éléments techniques d’une plate-forme est nettement plus souple en utilisant des noms.

Configuration

Pour effectuer des requêtes nsupdate sur un DNS il faut autoriser les IP des machines qui ont le droit d’émettre ces requêtes vers notre DNS (nsupdate et axfr). Ensuite il faut placer les bases du DNS (fichiers db.xxx) dans un endroit ou le process bind a le droit d’écrire. Pour des raisons de sécurité, il est hors de question que ce process puisse avoir un accès en écriture dans le répertoire /etc/ nous allons donc déplacer ces fichiers dans /var/cache/bind/.

Elements de Configuration DNS

Dans le fichier named.conf.local dans la section de la zone que nous voulons contrôler il faut ajouter l’ip de la machine autorisée à faire les requêtes nsupdate :

allow-update { xxx.xxx.xxx.xxx; };

Les requêtes AXFR sont autorisées dans ce même fichier de configuration en ajoutant l’ip des serveurs autorisés dans la sections “allow-transfer” de la zone.
Dans cette même section nous allons déplacer le fichier de la zone en modifiant son chemin :

file « /var/cache/bind/db.xxxx.yyyy »;

Démarche

Une fois cette opération réalisée nous pouvons utiliser les API Amazon pour récupérer les informations qui concernent une instance (par exemple, nous utiliserons ec2-describe-instances dont la documentation est à l’adresse suivante :  DOC API).
Les informations que nous allons récupérer (security groupes, Key, EBS ID…..), vont être réorganisées pour ensuite être injectées dans le DNS sous la forme d’enregistrements TXT en plus de l’enregistrement A utilisé pour référencer une adresse.
Pour réaliser une mise à jour automatique du DNS il est préférable d’exécuter une instruction de “delete” avant l’ajout d’un enregistrement. Vu que nous sommes sur un DNS qui sera utilisé pour les zones de notre infrastructure nous allons prendre en compte les trois enregistrements suivants :

Pour enlever les enregistrements précédents (dans le cas ou le serveur est déjà référencé ou pour enlever le serveur).

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update delete monserver.domain.net A
> update delete monserver.domain.net TXT
> update delete zzz.yyy.xxx.www.in-addr.arpa. PTR
> send

Ensuite on enregistre le serveur.

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update add monserver.domain.net 86400 IN A www.xxx.yyy.zzz
> update add monserver.domain.net 86400 IN TXT informations sur le serveur
> update add zzz.yyy.xxx.www.in-addr.arpa 86400 IN PTR monserver.domain.net.
> send

Nous partons du principe que le DNS est bien déclaré au niveau du fichier /etc/resolv.conf.

Une fois tous les enregistrements en place il suffit de passer la commande suivante pour que la liste apparaisse :

dig @ip_du_dns axfr domain.net

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>> @10.211.55.5 axfr test.net;
(1 server found)
;; global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
s1.test.net. 86400 IN TXT « tout » « ce » « que » « l » « on » « peut » « dire » « sur » « un » « serveur »
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
;; Query time: 19 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:03:56 2012
;; XFR size: 7 records (messages 1, bytes 237)

Nous touchons au but. Il suffit maintenant d’exécuter la même commande avec un grep sur “TXT” pour récupérer la liste qui nous intéresse.

Avec la commande suivante nous allons enlever l’enregistrement TXT du DNS :

nsupdate
> server monserverdns.test.com
> zone test.net
> update delete monserver.test.net TXT
> send

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>>
@10.211.55.5 axfr test.net;
(1 server found);;
global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
;; Query time: 2 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:15:30 2012
;; XFR size: 6 records (messages 1, bytes 183)

Nous avons donc une base de données (le serveur DNS) qui va nous servir de référence pour y placer toutes les informations des instances tirées des API Amazon.
Cet article n’aborde pas le côté sécurité de bind et ne fait donc pas référence à la gestion de clé pour les requêtes nsupdate.

Laurent ROUX

PaaS = Un cloud orienté services où l’infrastructure nécessaire au déploiement d’une application est créée à partir des informations associées au package de déploiement de l’application. Pour faire simple, c’est l’infrastructure qui se construit autour de l’application à héberger.

Répondons à des questions de base :

Que peut-on faire ou ne pas faire avec une instance de calcul (un serveur Windows dans le cloud Microsoft) ?

• On peut y faire exécuter n’importe qu’elle type d’application compatible avec l’OS Windows : c’est-à-dire du .net, mais aussi du java, php, ruby, … L’utilisation de .net est facilitée, cependant, il existe de nombreux sdk additionnels permettant de déployer et exécuter d’autres types d’exécutables.
• On ne peut pas y faire persister ses informations : l’état d’une instance Azure est à considérer comme « stateless ». Une instance Azure peut être réinstallée à tout moment et par conséquent, toutes les données stockées localement seront perdues.

Comment gérer la persistance des données ?

• Il existe deux services essentiels pour le stockage des données :
  • SQL Azure : une base SQL Server en haute disponibilité pour le stockage des données relationnelles, limitée à 150 Go par database,
  • les Blob : un entrepôt de stockage orienté clé/valeur sans limite de taille.
• Il existe un autre mode de persistance des données appelé Azure Drive. Il s’agit de pouvoir monter un disque persistant sur les instances de calculs. Les données de ce disque virtuel sont persistées dans les blobs Azure. Un Azure Drive peut être accessible en lecture pour plusieurs instances de calculs, cependant l’écriture est réservée à une seule instance.

Idéalement, la gestion de la persistance des données ne s’effectue plus via le système de fichier NTFS, mais par l’utilisation des services de stockage : SQL Azure ou les services associés aux Blobs.

Peut-on installer d’autres SGBD / Systèmes clé/valeur ?

Oui et Non :

• Oui, il est possible de démontrer qu’on peut arriver à faire fonctionner MySQL, Oracle,… par des procédures de déploiement complexes, mais c’est sans aucun support et en s’assurant soi-même de la bonne écriture des données principalement dans des Azure Drive ou en faisant le pari qu’avec « x » instances en cluster et en répliquant les données, il est peu probable que l’ensemble du pool d’instances soit arrêté à un même instant. A cela on peut ajouter le fait que l’utilisation des upgrade domains et des fault domains réduit à presque rien ce risque.
• Oui, pour des solutions comme un moteur de recherche dont la donnée peut être reconstruite. C’est le cas par exemple avec Apache SOLR que nous avons déjà déployé en production dans le Cloud Windows Azure. Mais aussi pour d’autres services comme Hadoop, Memcache, … Cependant, certains services comme la base NoSQL MongoDB propose maintenant un package d’installation compatible avec le stockage sur des blobs (MongoDB sur Azure).
• Non, car pour un déploiement en production, il est indispensable, au final, de s’appuyer sur SQL Azure et les Blob afin de disposer des garanties indispensables à la pérennité des données. Cependant, comme pour le cas de MongoDB, les logiciels proposent de plus en plus des adaptations afin d’assurer une compatibilité avec ces modes de stockage. L’avenir n’est plus au stockage des données dans des « file systems » ntfs/fat/…

La mise en oeuvre d’applications dans un PaaS nécessite une bonne compréhension de ses caractéristiques. Une fois cet apprentissage réalisé, il est possible de faire bien plus de choses qu’avec une architecture physique . L’ensemble des services proposés par le cloud est utilisable via des APIs, ainsi une application peut elle-même décider d’actions sur son hébergement afin d’adapter sa consommation en ressources.

Olivier LEAL

Voici 3 videos de plateaux TV (techtoc.tv), où Olivier LEAL et moi-même avons participé, sur divers sujets autour du Cloud Computing tels que :

o Migration du SI vers le Cloud : à quelles conditions ? Pour quelles parties du SI ? Pour qui ?, revue des bonnes pratiques déjà établies pour se déterminer à aller vers le Cloud, et vers lequel.

——————————————————————————————

o Impacts du Cloud sur la gouvernance des SI ?, redistribution des cartes !

——————————————————————————————

o Ou bien encore Le Cloud pour ma PME ?, les grandes entreprises auraient-elles plus d’avantages à utiliser le Cloud qu’une PME ? Ou les raisons sont-elles ailleurs ?

Je les mets à votre disposition si vous souhaitez les regarder !

Frédéric FAURE @Twitter @Ysance

1. Champ Libre pour l’Open Source
2. La Portabilité dans le Cloud
3. DevOps
4. AWS, l’Unique ?
5. Cloud Privé : Mythe ou Réalité ?
6. Moteur Hybride
7. Infogérance

En vous souhaitant bon visionnage !

Frédéric FAURE @Twitter @Ysance

Decrypt, Le Forum est ouvert ! Venez échanger avec nous et avec la communauté. Notre forum flambant neuf s’articule autour de nos domaines d’expertYse que sont le Cloud Computing, l’industrialisation des développements, l’e-commerce et le CRM. Une dernière catégorie Autour d’un café permet d’échanger sur divers sujets techniques. Nous pourrons répondre à vos interrogations sur ces thèmes, mais vous pourrez également partager vos retours d’expérience et présenter les nouveautés que vous avez vous-même testées si vous le souhaitez.

C’est un espace d’échange que nous souhaitons convivial et qui, nous l’espérons, vous plaira !

A bientôt donc sur Decrypt, Le Forum !

Frédéric FAURE @Twitter @Ysance

Urbandive is an immersive view service launched by the French YellowPages which allows you to travel in cities in France thanks to a 360° view. Urbandive focuses on providing high definition pictures and accurate professional and social content. One of the biggest jobs was to enable a fast scalable architecture, because it was really difficult to forecast the traffic load at production time. Traffic load may be influenced if the service receives attention from users as a result of advertising.

Below you will find a summary of the goals we achieve by using a Ruby scheduler built on top of Puppet on AWS to create a complete infrastructure.

Workflow & XTR-Lucid
Our scalability combo is : a home-made Ruby scheduler (XTR-Lucid) to deal with AWS APIs + the Puppet Master to install services and configure EC2 instances and keep them up-to-date during all the production time. This leads to full automation.

Here is the workflow (for the creation step, there are other workflows for stop/reboot/health-check/…) of our automation tool. The dashboard allows you to select a template (which contains the following informations : AMI id, instance type, availability zone, key, list of security groups, list of EBS – from snapshots or not -, …) and to set a name for the instance in the « create » workflow.

This schema gives the general idea of how it works.

To be more accurate and to explain the workflow just a bit :

• The scheduler can be outside or inside of AWS.
• First an action file is put into the TODO directory, by the web application (simple rhtml dashboard) or by the monitoring tool directly. For posting files from the monitoring tool, we will have to define thresholds after some weeks of use of the application. At this time, we have not enough data feedback as we just commenced production.
• The action file is then processed by the scheduler :

1. Connection to AWS and request to start an EC2 instance from the AMI.
2. Scheduler checks that instance is running, EBS (Elastic Block Store) are available, then in-use, and eventually that EC2 TCP stack is up and SSH is OK. Then it connects to the brand-new instance.
3. Puppet client is installed and started, so it sends a certificate request to the master.
4. Puppet client is stopped to avoid any interaction.
5. Connection to the PuppetMaster : update the main files (nodes files of PuppetMaster, « /etc/hosts » file, roles file of Capistrano) and then accept the certificate request of the client.
6. Capistrano updates the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients.
7. Connection to the new instance.
8. Puppet client is started.
9. Puppet client connects to the master and authenticate. Then it gets what it needs to install and configure the new instance.
10. The installation occurs on the new instance that will be soon available.

• The scheduler doesn’t wait until the instance is fully configured to end the task : installation by Puppet is asynchronous. The scheduler just ends by updating its repository and the monitoring tool.

Technical note 1 : we use Capistrano mainly for application deployment. In the above case (create instance), we use it to update the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down – it is the same use for stop instance), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients (bad idea ;ob). That’s just a little tip for this workflow.

Technical note 2 : the Ruby scheduler works in asynchronous mode (for security reasons & to be called by other tools – like a monitoring one) by creating action files from the web application in the TODO directory (which can be filled by the monitoring tool for auto-scalability) checked every minute by a CRON which calls the heart of the automation tool.

Technical facts

• We have actually 40 – 50 servers, that’s our base, but we probably will go higher when the traffic will come with marketing campaigns.
• We use Lucid Lynx Ubuntu OS (from a standard AMI powered by Canonical).
• We use the PuppetMaster installed on Apache with Phusion Passenger to increase performances.
• We took Puppet (standard version) right from the Ubuntu repositories packaged in the AMI.

Why using Puppet (and especially on AWS) ?
Consistency & Flexibility
We have multiple services, so we need to be sure that each group of servers is consistent in terms of configuration. If we need to push a quick change on all nodes of a type at a given time, we can even push (trigger « pull », to be more accurate, with puppetrun) this new setting from the PuppetMaster without waiting the pull of Puppet client (30min period) and we are sure that this one is pushed everywere it is needed.
AWS offer AMIs to « snapshot » an instance and clone this one as many as we want. This is very good for developpement, load tests, .. But when we come into production, we cannot build another AMI each time we do a change on a setting and deploy again EC2 instances from the new AMI. We need something flexible to patch our configurations quickly, keeping consistency at all times.

Scalability & Ease
This is a new Internet service which can have a load peak at anytime depending on marketing campaigns. But we have to deal with financial things too. So we keep a base and have to start quickly full configured up-to-date instances within a few minutes. We achieve this by writing a home-made ruby-script-based scheduler (XTR-Lucid) that deals with AWS APIs to launch/stop EC2, add EBS (empty or from snapshot), add/remove to/from ELB, add/delete the new/old host to/from our monitoring tool, … AWS EC2 instances are kept in a repository on our Ruby scheduler. Then our tool lets Puppet take over which ensures for each brand-new instance started from a standard Lucid Lynx AMI that all services, configurations, security rules are installed/applied. So with the feedback of our monitoring tool, the infrastructure can grow and decrease alone (depending on the thresholds set) or we can deploy and stop instances in just one click on our web dashboard.

Operating
In such a project, there is a lot of various services to monitor for the Ops team (And… Yes ! Ops team is always essential, even with automated infrastructure ! :o)). So this is important to capitalize upon knowledge in Puppet descriptors and XTR-Lucid repository and templates, so that by simply reading the descriptors/repository/templates, the whole team knows all what it needs to know at a glance (no need to look everywhere). Things become a lot easier.

Portable Infrastructure
Because of the diversity of services run in the project, maybe not all will fit into AWS in a long term experience (over one year). Once we have real-life feedback on traffic, some services will stay on AWS, others, maybe, will migrate into our physical datacenter. So it will be easier to migrate because all the configuration is concentrated in Puppet descriptors. This enables us to re-deploy easily a brand-new infrastructure on another plateform (even if it is not in the Cloud).

I hope you enjoyed this. You can find here some more information on the way the Ops job is evolving, based on this experience (among others) : Solutions Linux / Open Source 2011 – Le métier de l’Administration Système avec le Cloud Computing (FR). These slides are the ones used for a talk I gave at Solution Linux 2011 (France).

Frédéric FAURE @Twitter @Ysance

Après quelques formations intra-entreprise, une nouvelle session inter-entreprises est ouverte ! Je vous annonce donc que je donnerai une formation sur les AWS (Amazon Web Services) destinée aux professionnels le Jeudi 8 Septembre 2011. Elle se déroulera à Paris en une journée. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF.

Le but de la formation est de donner une vue d’ensemble des différentes offres (AWS, GAE & Azure) et de leur positionnement et d’expliquer ce qu’est le Cloud Computing (modèle économique et services), puis de se concentrer sur l’offre d’Amazon (architecture, services, résilience, support, sécurité, …) et de la mettre en pratique (EC2, EBS et S3). La dernière partie est une ouverture sur les outils à mettre en place afin d’optimiser l’utilisation de ces ressources (gestionnaire de configuration centralisée, serveur de logs, métrologie, …).

La formation sera axée à la fois sur une approche théorique et pratique, avec 30% du temps de formation passé à réaliser des travaux pratiques (sur les composants principaux que sont EC2, EBS et S3, ainsi que manipulation des outils et gestion de compte AWS), et sur une forte interactivité afin de répondre à toutes vos interrogations.

Qui peut y participer ?
Des chefs de projet, architectes techniques et fonctionnels, administrateurs système, responsables d’équipes de développement, directeur/responsable informatique.

Quel est le programme proposé ?

1ère Demi-journée
Le Cloud Computing

• De quoi s’agit-il ?
• Les acteurs du marché et leurs différentes approches (Amazon, Microsoft, Google, …)

Le cas Amazon

• De quoi s’agit-il ?
• Comparaison d’une infrastructure Cloud AWS avec une infrastructure physique classique
• Les cas d’utilisation
• Les coûts

Les outils

• Gestion de son compte (clés, certificats, facturation, support, …)
• Les consoles d’administration (Console AWS, ElasticFox, S3 Organiser)
• Les APIs

2ème Demi-journée
Les services infrastructure AWS

• Elastic Compute Cloud (EC2)
• Elastic Block Storage (EBS)
• Simple Storage Service (S3)
• Séance de TP sur EC2, EBS et S3

AWS… Encore un peu plus loin

• Overview automatisation & dynamisme : gestion de la configuration centralisée avec Puppet, déploiement automatisé avec Capistrano, monitoring avec Cacti & Centreon/Nagios, gestion des logs avec Syslog-NG, auto-scalability, LVM, …

Les informations utiles

• Forums, sites, liens, livres blancs (sécurité, extension SI, …)

Quelles sont les modalités pratiques ?
Lieu : A venir
Date : Jeudi 8 Septembre 2011
Heure : A venir

Durée : 1 journée
Tarif : 800 euros HT
Toutes les sessions se déroulent dans le centre de Paris. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF. Nous pouvons vous aider à monter votre dossier.

Pour vous inscrire, cliquez ICI.

En espérant que vous viendrez nombreux. :o)

Frédéric FAURE @Twitter @Ysance

De retour du salon Solutions Linux / Open Source 2011 (salon professionnel annuel dédié aux logiciels et solutions libres pour les entreprises), je publie les slides que j’ai présentés en compagnie d’Omer SHALA (Mappy) lors d’une des conférences du salon ayant pour sujet le Cloud Computing. Cette présentation porte sur l’évolution du métier de l’Administration Système avec l’utilisation du Cloud Computing. Nous avons pris comme support notre expérience du projet UrbanDive, le nouveau service de vue immersive en zone urbaine du groupe PagesJaunes.

Omer SHALA, responsable de l’infrastructure du projet, a tout d’abord exposé le contexte du projet, puis a expliqué les éléments de décision qui nous ont amené à choisir le Cloud Computing (et en l’occurrence les Amazon Web Services – AWS) pour mettre en place nos services. Il a finalement fait une synthèse de son expérience de la mise en place de cette infrastructure avec les services d’Amazon (de type IaaS – Infrastructure as a Service), par rapport à ses expériences avec des infrastructures plus classiques (en datacenter) au sein du groupe PagesJaunes.

J’ai repris la seconde partie de la conférence et ai exposé ma vision de l’évolution de l’administration système avec l’utilisation de solutions de type Iaas. Pour finir, j’ai présenté ce que nous avons mis en place pour optimiser le potentiel des services Amazon, notamment via l’automatisation :

• avec le développement d’un ordonnanceur Ruby (XTR-Lucid) pour interfacer les APIs proposées par Amazon et gérer les cinématiques de communication (création/suppression d’instances métier EC2 et disque réseaux EBS, déploiement des services, …) avec les AWS,
• avec l’utilisation d’outils Open Source comme le gestionnaire de configuration centralisé Puppet ou bien le scripteur/exécuteur de tâches Capistrano.

Je vous laisse visionner cette présentation en dessous !

Nous avons également inclus dans cette présentation la matrice de décision sur laquelle nous nous sommes basés pour décider de l’adoption du Cloud Computing pour la mise en place de l’infrastructure.

Frédéric FAURE @Twitter @Ysance

Evénement Microsoft MIX 2011

Présent depuis quelques jours à Las Vegas à l’occasion du Mix 2011 de Microsoft, voici quelques informations intéressantes :

• Un KeyNote avec des annonces importantes le deuxième jour :

• Confirmation d’un nouveau service dans le Cloud Windows Azure :  « Trafic Manager », un service en CTP (Community Technology Preview). Ce service permet par l’utilisation de plusieurs zones géographiques de répartir (loadbalancer) le trafic en fonction de la proximité de l’utilisateur. Ainsi, l’impact de la latence sur les applications est minimisé grâce à la prise en compte de la géolocalisation de l’internaute.

• Enrichissement de l’offre CDN CTP avec la gestion du streaming vidéo en avril 2011 pour les informations stockées dans Azure Blob Storage.

• IE 9 / (IE 10 pour la fin de l’année : 4/12/2011) : en avant pour HTML 5 ! Microsoft lance déjà les réflexions pour HTML 6. Cependant, il faut être encore prudent car HTML 5 c’est une centaine de spécifications qui ne sont pas totalement abouties… Et par conséquent, une partie des fonctionnalités déjà disponibles est basée sur des hypothèses d’acceptation de certaines spécifications. Pour du concret, visitez : http://www.beautyoftheweb.com/ et http://ie.microsoft.com/testdrive/ ou le blob de Giorgio Sardo http://blogs.msdn.com/b/giorgio/.

Etat des spécifications HTML5

• Sortie d’un update pour Windows Phones version 7.5 : vers un accès plus facile au catalogue d’applications par la catégorisation. Microsoft rattrape fonctionnellement son retard et va plus loin avec un focus particulier sur la performance des applications. Microsoft et Nokia travaillent ensemble dans le but de monter au deuxième rang des fournisseurs d’applications mobiles.

• Sortie de Silverlight 5 Beta : http://www.silverlight.net/getstarted/silverlight-5-beta/. Évolutions majeures du moteur de rendu 3D.

• C’est officiel : Un SDK disponible en avril permettant de réaliser des développements Windows pour la Kinect, avec pour mot d’ordre : « Créativité » !

Un moyen de transport/confort piloté par Kinect

L’accès à l’ensemble des sessions en ligne, c’est ici : http://channel9.msdn.com/events/mix/mix11.

Olivier LEAL