Decrypt

Varnish est un outil fabuleux à bien des égards. C’est une boite à outils qui permet de simplifier, harmoniser, sécuriser et accélérer les architectures web. Nous allons aborder dans cet article certaines fonctionnalités de Varnish pour commencer à en tirer le maximum. Il se positionne comme un reverse proxy cache. En gros nous allons le placer en amont des serveurs Web pour intercepter les requêtes, mettre en cache ce qui est généré par les backends et resservir le contenu généré depuis son cache. Mais son fonctionnement peut aller plus loin.

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.

[...]

Dans le monde élastique du Cloud et plus précisément en ce qui concerne l’IaaS, nous nous heurtons souvent au problème : “quelle est l’adresse de telle machine, quel est son mode d’accès…”. A ces questions peuvent s’ajouter la problématique du tout automatique via un Capistrano par exemple. Vous me direz qu’il existe une console Web et des API. Oui mais la console n’est pas réellement exploitable pour l’automatisation et les API ont besoin de crédentials que l’on ne préfère pas disséminer partout sur les serveurs.

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.

[...]

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.

[...]

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.

[...]

Here is the follow-up you’ve all been waiting for :o), examining the comparisons between Cloud-deployed infrastructure via AWS (Amazon Web Services) and traditional physical infrastructure. Let me remind you that when I say physical infrastructure, I examine self-hosted infrastructure as well as infrastructure supported by a hosting provider. Similarly, I also look at infrastructures based directly on hardware, as well as those based on virtualized environments. Cloud computing is also based on virtualization, but we are not so interested in that technology here, rather the way in which it is provided to customers (you).

[...]

I’ve been noticing again many questions about the differences inherent in choosing between a Cloud infrastructure such as AWS (Amazon Web Services) and a traditional physical infrastructure. Firstly, there are a certain number of preconceived notions on this subject that I will attempt to decode for you. Then, it must be understood that each infrastructure has its advantages and disadvantages: a Cloud-type infrastructure does not necessarily fulfill your requirements in every case, however, it can satisfy some of them by optimizing or facilitating the features offered by a traditional physical infrastructure. I will therefore demonstrate the differences between the two that I have noticed, in order to help you make up your own minds.

[...]

Et voici la suite tant attendue de la comparaison entre une infrastructure déployée sur le Cloud via les AWS (Amazon Web Services) et une infrastructure physique classique. Pour rappel, concernant l’infrastructure physique, je considère autant l’infrastructure hébergée soi-même que celle prise en charge chez un hébergeur spécialisé. De même, je considère autant les infrastructures reposant directement sur l’OS de la machine que celles reposant sur des environnements virtualisés. Le Cloud repose également sur de la virtualisation, mais ce n’est pas la technologie qui nous intéresse ici, mais la manière de la mettre à disposition des clients (vous).

[...]

Je constate encore beaucoup d’interrogations sur les différences impliquées par le choix d’une infrastructure Cloud de type AWS (Amazon Web Services) ou d’une infrastructure physique classique. Tout d’abord, il y a un certain nombre d’idées reçues sur le sujet que je vais tenter de décrypter pour vous. Ensuite, il faut comprendre que chaque infrastructure présente des avantages et des inconvénients : une infrastructure de type Cloud ne correspondra pas forcément à vos besoins dans tous les cas, cependant, elle peut répondre à certains d’entre eux en optimisant ou facilitant ce que propose une infrastructure physique classique. Je vais donc présenter les différences que j’ai notées entre ces 2 infrastructures afin de vous aider à y voir plus clair et que vous puissiez vous faire une idée.

[...]