La cuisine de Gandi

Accueil > Hébergement

Hébergement

Fil des billets - Fil des commentaires

ShellShock : statut

Comme vous êtes nombreux à nous poser la question :

Concernant notre plateforme :

L'infrastructure de Gandi a été mise à jour. Nous ne sommes donc pas vulnérables aux différentes CVE publiées (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187) ciblant le shell bash.

Concernant vos serveurs virtuels et vos instances :

Si vous êtes client sur notre plateforme IAAS, assurez-vous de bien mettre à jour votre version de bash.

Si vous utilisez Gandi AI, nous vous recommandons vivement de migrer vers la plateforme PaaS/SimpleHosting. Il n'existe pas de mise à jour pour cette distribution qui n'est plus supportée depuis 2012.

Concernant la plateforme Simple Hosting :

Nos services ont été patchés au fur et à mesure de la sortie des mises à jour de sécurité. Il est cependant nécessaire de redémarrer vos instances pour que la nouvelle version de bash soit utilisée.

Comment tester la vulnérabilité de votre version de bash pour chaque CVE :

- CVE-2014-6271 :

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

> Il ne doit pas y avoir écrit "vulnerable".

- CVE-2014-7169 :

cd /tmp; env x='() { (a)=>\' bash -c "echo date"; cat echo

> Vous ne devez pas recevoir le résultat de la commande 'date' qui retourne la date et l'heure.

- CVE-2014-7186 :

bash -c 'true <<EOF <<EOF <<EOF  <<EOF <<EOF \
<<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF \
<<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

> Il ne doit pas y avoir écrit "CVE-2014-7186 vulnerable, redir_stack".

- CVE-2014-7187 :

(for x in {1..200} ; do echo "for x$x in ; do :"; done;  \
for x in {1..200} ; do echo done ; done) | \
bash || echo "CVE-2014-7187  vulnerable, word_lineno"

> Il ne doit pas y avoir écrit "CVE-2014-7187 vulnerable, word_lineno".

Si vous avez besoin de tester vos scripts CGI exécutés par un service web, de nombreux testeurs en CLI ou sur le Web sont disponibles, vous les trouverez aisément en utilisant votre moteur de recherche préféré.

La communauté ayant commencé une analyse plus approfondie de bash, il est possible que de prochaine failles soient découvertes. De ce fait des mises à jour de sécurité seront probablement à effectuer prochainement. La communauté impliquée dans la sécurité des projets opensource estime que les derniers patchs publiés ne corrigent pas complètement le problème sous-jacent dans bash.

Nous vous invitons à suivre cet article pour être informé sur les mises à jour de la liste des CVEs concernant bash pour le PaaS/SimpleHosting.

PaaS Gandi :

version disponible: 4.2+dfsg-0.1+deb7u3

Statut pour :

CVE-2014-6271 : non vulnérable

CVE-2014-7169 : non vulnérable

CVE-2014-7186 : non vulnérable

CVE-2014-7187 : non vulnérable

CVE-2014-6277 : vulnérable (patch non disponible)

CVE-2014-6278 : vulnérable (patch non disponible)


Déployez vos applications Web en Ruby avec Simple Hosting

Vous étiez nombreux à nous demander de pouvoir déployer avec Ruby sur Simple Hosting, et c'est désormais possible !

Ruby est le langage derrière le framework Web de référence de ces dernières années, Ruby on Rails, et vous pouvez dès aujourd'hui commencer à déployer vos applications couplées à la base de données de votre choix: MongoDB, PostgreSQL ou MySQL.

D'ailleurs, vous pouvez déployer toute application basée sur Rack, comme des applications faites avec Sinatra ou Padrino.

Déploiement simplifié: push et deploy

Chaque instance Simple Hosting est fournie avec un répertoire Git et un accès SSH, qui vous permettent de déployer votre application en quelques commandes. Un panneau d'administration permet aussi la gestion de tous les outils via un navigateur web (base de données, logs, redémarrage de l'appli, nettoyage du cache).

Le développeur peut, seul ou avec ses collaborateurs, suivre les modifications de son projet directement à partir de l'instance, sans avoir besoin de créer des comptes sur des outils externes. En ajoutant des clés SSH, plusieurs machines (et les personnes qui les contrôlent ^^) peuvent "pousser" et déployer du code sur un même projet.

Par exemple, on peut mettre une application Rails en production en 3 étapes:

$ git push gandi master
$ ssh <login@git.dc1.gpaas.net> 'deploy default.git'
$ ssh <login@console.dc1.gpaas.net>; rake db:migrate;

Consultez la documentation de l'instance Ruby dans le Wiki de Gandi pour plus d'informations.

Idéal pour vos applications Web

Simple Hosting mutualise les ressources en amont de votre application, tout en vous allouant un conteneur avec des ressources dédiées. uWSGI (populaire dans le monde des applications web en Python, mais assez méconnu de la communauté Ruby) est utilisé pour faire passer les requêtes depuis Apache vers le serveur Web (compatible avec Rack) de votre application Ruby.

Vous bénéficiez également du chargement rapide de vos pages et autres atouts Web grâce à l'accélération fournie par le service Varnish de Simple Hosting, qui se charge de les mettre en cache.

Simple Hosting est ainsi particulièrement attractif pour déployer des applications, des sites, et des API REST. En plus de l'infrastructure polyglotte, Simple Hosting permet d'envoyer des emails, programmer des tâches récurrentes avec Cron, uploader des fichiers et même générer des PDFs depuis votre application.

Hébergez simplement vos outils de travail

Beaucoup de développeurs et leurs équipes se servent d'outils libres pour faciliter leur quotidien. Les agences web utilisent Refinery CMS ou Locomotive CMS pour faire le site de leurs clients, les équipes de prod aiment Redmine pour créer des tickets, etc..

Pour vous faciliter la vie, nous avons crée une série de tutoriels qui vous permettent à la fois d'installer certains de ces outils et de commencer à explorer l'instance Simple Hosting.

Commencez à déployer dès maintenant en suivant le tutoriel de votre choix

Montons en puissance !

L'offre de Simple Hosting comprend des instances de plusieurs tailles, du 'S' au 'XXL', pour vous permettre de déployer vos petits projets et de les accompagner jusqu'à maturité sans vous soucier de votre infrastructure.

L'instance Ruby est dès aujourd'hui disponible en Beta et nous espérons que vous y trouverez une bonne alternative pour déployer vos applications. En cas de besoin, vous trouverez de l'aide dans les Gandi Groups. Comme toujours, envoyez-nous vos commentaires et servez-vous de la Wishlist pour continuer à influencer le futur de Ruby sur Simple Hosting !


Création de VMs et déploiement de code plus rapides

Nous avons modifié la manière dont sont déclenchées les opérations de création de nouveaux serveurs IaaS et de déploiement de code avec Simple Hosting, et avons gagné de précieuses secondes.

En utilisant les fonctionnalités listen / notify de PostgreSQL, nous avons accéléré le provisionnement des VMs IaaS et conteneurs PaaS, ce qui vous permet de créer des serveurs et déployer vos projets plus rapidement.

Ce graphique donne une idée de l’évolution du temps de démarrage des opérations :

timing prov

Si vous êtes client Simple Hosting, vous bénéficierez de cette accélération en utilisant git et ssh pour déployer votre code (http://wiki.gandi.net/fr/simple/git#deployer_son_code). Les clients IaaS en bénéficieront quant à eux à chaque création de serveur, depuis l’interface Web ou l’API.

D’ailleurs, n'hésitez pas à faire un tour sur Github, vous y trouverez des bibliothèques qui rendent la communication avec notre API plus simple dans votre langage préféré.

"Tempus fugit”, dit-on, il est donc toujours bon d’en récupérer. Faites-en bon usage !



Comment est configurée une machine virtuelle ?

Le processus de configuration actuel d'une machine virtuelle sur l'hébergement Gandi IaaS a changé mais le nouveau processus est toujours considéré comme instable et les appels API sont susceptibles de changer dans le futur. Si vous utilisez ce processus pour développer de nouveaux outils de déploiement de machine virtuelle, indiquez-le nous ! Gardez aussi à l'esprit que cette version de notre outil de provisioning est encore jeune, les interfaces sont aussi susceptibles de changer.


De nouvelles images sur l'hébergement IaaS axées supervision

Nous vous avons préparé quelques images de distribution spécialisées dans la supervision.

Vous étiez nombreux à nous faire des demandes en ce sens, ou plus directement que Gandi propose un service de supervision à travers notre interface d'administration.

Cela sort de notre périmètre, nous préférons donc que nos clients puissent gérer leur supervision eux mêmes, à savoir qu'il existe aussi des services payants de supervision sur Internet, ce qui peut être une alternative.


La plate-forme PAAS du SimpleHosting

Nous sommes heureux de vous faire profiter de notre nouvelle plate-forme PaaS. Cela fait maintenant plus d'un an que nous travaillons dessus en intégrant au fur et à mesure les dernières évolutions logiciels tout en restant homogène avec notre infrastructure et la gestion de notre hébergement IaaS.

Le but de la plateforme est de vous affranchir complètement de la partie système (en profitant de notre expertise) et de vous laisser libre sur la partie applicatif (dans les limites des paramétrages qui se veulent par défaut très ouvert).



Penser architecture web - Aller plus loin avec plusieurs centres de données

Un peu dans l'esprit de l'article Penser architecture web que nous avions publié il y a 2 ans, nous allons aborder dans cet article les problématiques que nous savons récurrentes pour nos clients hébergement ainsi que dans le monde du web en général : que faire quand mon serveur web est surchargé ou mes sites web sont lents ?


Le stockage fait sa migration

Depuis quelques mois, vous avez peut-être pu utiliser des serveurs aux États-Unis. Le changement de l’infrastructure de stockage était un des points forts dans l'infrastructure pour l'hébergement.
Avant ça, il a fallu adapter notre infrastructure afin qu'elle puisse comprendre "n" datacenters. La mise en place de la nouvelle plateforme de stockage n'a pas été si compliquée puisqu'elle était indépendante de celle existante en France. Le datacenter était nouveau, c'était donc assez simple à mettre en place : tous les nouveaux serveurs aux États-Unis ont bénéficié de cette nouvelle technologie.



Quota, parts et coeurs en option

La prochaine version (3.0.8) va apporter un changement majeur dans la gestion du quota Hébergement, ainsi que dans l'utilisation de l'API associée. Notez bien que les modifications décrites ci-dessous n'arriveront que lors de la mise en production effective de la 3.0.8, dans les prochains jours.

Le changement a principalement été motivé par l'envie de vous proposer des cœurs en options pour vos serveurs. Mais il s'est avéré que dans l'état actuel des choses, cette option n'était pas possible.

Petite explication...





API Hosting 1.0 en bêta

Comme vous le savez peut être déjà, nous sommes en train de finaliser la gestion de notre plateforme d'hébergement Cloud via une API publique. Afin de vous faciliter le travail, beaucoup de choses ont été remaniées afin de vous permettre une utilisation plus simple, et une vraie maitrise de vos ressources hébergement chez Gandi.

En guise d'introduction, ce billet sera volontairement peu technique, et ne présentera que succinctement des parties qui seront développées en détails lors de la sortie officielle de l'API.


Mandriva 2010, image en accès alpha [maj]

L'hébergement sur des serveurs Gandi permet à ses clients de choisir parmi une sélection d'image d'OS disponible à la création de la machine. Après la préparation en interne de l'image et après une batterie de test, l'image est mise à disposition d'un groupe de client 'alpha' pour l'hébergement Gandi. Ces clients peuvent ainsi créer des serveurs utilisant ces images en 'release candidate'. De notre coté, cela nous permet d'élargir le champs des tests effectués sur les images et de dénicher les bugs et problèmes en touchant un plus petit groupe de client.

Aujourd'hui - 21 Mai - sort donc l'image d'OS basée sur une Mandriva 2010.0. Cette nouvelle version de la distribution Mandriva démarre avec un kernel 2.6.27 par défaut. Cette image est pour le moment disponible pour le groupe de client hosting en 'alpha'. Cette image de système sera bientôt disponible pour tous. N'hésitez pas à nous contacter si vous souhaitez participer à nos phases de test alpha.

16 aout 2010 : L'image est maintenant disponible pour tous


Kernel et cmdline

Nous vous proposons (enfin!) de choisir la version de votre kernel (parmi une liste qui évoluera), et les options de démarrage associées (cmdline). Les 2.6.18 et 2.6.27 sont les versions "de base" fournies par Xen (backport des patches xen pour la 2.6.27). La 2.6.32 actuellement disponible utilise paravirt_ops et l'implémentation "linux" des patches de Xen.

Nous vous annoncerons les nouveaux kernels disponibles ici même.

Ça se trouve dans "Mode avancé", dans l'interface d'administration du serveur : Options avancées

Et vous donne accès à ceci : Options avancées détail

Coté cmdline, vous pouvez maintenant désactiver selinux au boot, booter en single user, changer le disque et la partition de boot (pratique pour travailler avec des "images"), choisir la console la plus appropriée. Bref, de quoi gérer plus agréablement vos mises à jour ou réparer votre serveur de façon plus autonome.

Si une option vous manque, n'hésitez pas à nous la suggérer.


Cherokee arrive chez Gandi.

Un ami m'expliquait qu'il venait de terminer l'installation d'un serveur web. Ayant décidé de changer et de ne pas utiliser le géant Apache que tout le monde connait, mon ami semblait avoir trouvé une bonne alternative. Portant le doux nom de Cherokee, il paraissait plus léger et plus performant qu'Apache. Voir les benchmarks provenant du site du projet à la fin de l'article. [1]

Personnellement, je ne le connaissais pas du tout, j'avais certainement déjà entendu son nom une ou deux fois, mais je n'y avais pas prêté attention. Pour voir ce qu'il donnait, j'ai décidé de l'installer en local. Je fus agréablement surpris ! Sur une distribution Debian like, l'installation se fait très simplement avec un apt-get install cherokee (ou aptitude).

L'interface web qu'il fournit est claire et plutôt agréable. L'idée est intéressante. Il sera possible d'activer l'interpréteur PHP avec un simple clic, pareil pour l'activation de différents virtualhost ou autres options. Il y a un assistant qui permet d'installer des technologies comme Django, Rails, ou Wordpress, etc.

Je me suis dit que présenter ce projet à une réunion devs chez Gandi pouvait être intéressant, notamment pour les personnes utilisant GandiAI. Le projet a bien été perçu. Après discussion et un coup d'œil rapide sur le code source, rien ne nous a choqués. Cela ne signifie pas qu'il n'y a pas de bugs, toutefois un code propre c'est plutôt bon signe ! Le cœur est écrit en C et l'interface d'administration en Python.

C'est donc de cette manière que Cherokee a fait son apparition chez Gandi et qu'une image a été réalisée, vous permettant ainsi de le tester rapidement.

Nous avons ajouté une distribution en mode expert avec Cherokee de préinstallé... il vous suffit de choisir cette distribution lors de la création de votre serveur. Je vous rappelle aussi que si vous n'avez pas encore essayé notre service, vous pouvez faire une demande sur notre formulaire de demande de test.

Pour avoir plus d'informations sur Cherokee, vous pourrez vous rendre sur le site du projet . Un article lui a également été consacré dans Gnu/linux magazine France par Carl Chenet dans le numéro 125.

Notes

[1] benchmark.jpg benchmark-0.8


10 ans de Gandi: retour d'expérience

À l'occasion des dix ans de Gandi, l'idée un peu folle de donner, sur dix jours, 55000 domaines, a posé une question pratique. Comment, en ouvrant les vannes d'une telle opération, maintenir une qualité irréprochable sur le site ? L'ambiance festive aurait aussi bien pu se transformer en cauchemar pour nos clients si ils avaient été privés d'accès à leurs interfaces de gestion.

La décision fût donc prise d'héberger l'événement sur un site dédié. Occasion rêvée pour se mettre un peu à la place de nos clients, et utiliser notre infrastructure d'hébergement. Règles du jeu : on utilise exclusivement les outils fournis au client, on prépare une archi qui monte en charge facilement, ça ne doit pas coûter un bras, ça peut illustrer notre flexibilité légendaire.


Keep it simple, stupid

De la décision à l'implémentation, on avait une semaine. L'idée charmante de monter un site "cloudish" à base de technos modernes, et peu maîtrisées, est donc oubliée d'office. Pour être honnête, vu les délais, le développeur désigné d'office se voit choisir la techno : "là où t'es à l'aise, tu as une semaine". Ça sera PHP/mysql, ce qui n'est pas du goût de tout le monde ! Mais permettra de sortir le site testé et dans les temps.

Pour tenir une charge correcte, plusieurs serveurs seront nécessaires.  Premier rappel de nos imperfections, Gandi ne fournit pas de load balancing ! Qu'importe, on ira donc sur un round robin DNS, à petit TTL pour pouvoir sortir facilement un frontal cassé de la production.

Notre distribution pour l'occasion, sera une ubuntu 9.10 - parce qu'elle est assez à jour, et qu'elle utilise un kernel 2.6.27.


Multiplier les petits serveurs

La meilleur façon de monter en charge sur notre infrastructure est d'isoler fonctionnellement l'architecture en nombreux petits serveurs. Là où nous assurons un minimum de "scalabilité" verticale (vous pouvez augmenter dynamiquement la RAM, le CPU alloués à un serveur), c'est à l'architecture de prévoir la scalabilité "horizontale".

Ainsi, on peut facilement monter les ressources là où les bottlenecks se font sentir, et ajouter/ou déplacer des parts d'un serveur vers l'autre lorsque la puissance allouée le demande. Les avantages des "nombreux petits serveurs" sont multiples :

  • chaque serveur bénéficie au minimum d'un core CPU en burst (oui, un core entier, même sur une part : c'est nouveau)
  • la redondance est assurée, et vos parts s'étalent un peu aléatoirement sur des centaine de serveurs physiques
  • particulièrement en environnement virtualisé, la performance mémoire est meilleure sous 1G de RAM
  • si vous avez 4 serveurs d'une part, au lieu d'un gros de 4 parts, ils montent à 8x4 parts dynamiquement, ou 24x4 parts en un reboot, tout ça sans toucher à l'archi - là ou le gros s'arrête à 8 sans reboot, ou 24
  • les ressources sont faciles à déplacer vers les serveurs qui en ont besoin.

Nous partons sur l'infrastructure simpliste :

  • 24 (!) serveurs d'une part, pour gérer le web et PHP : 10 en anglais, 10 en français, et 2 + 2 pour l'IPv6
  • 2 serveurs de 4 parts, des memcached répliqués pour soulager la DB et gérer les sessions
  • 1 serveur mysql de 4 parts, qui contiendra les coupons pré-générés (ils tiennent en RAM, la base doit théoriquement s'ennuyer)

Après quelques belles surcharges et un bout de code revu, la base de donnée sera finalement épargnée au maximum par memcached (voir chapitre « un code léger… »)

Soit 36 parts, pour une durée de dix jours : environ 140 euros.

C'est un admin qui s'usera les doigts sur notre site pour créer, et configurer les 24 serveurs en parallèle. Visiblement, la sortie de l'API hosting ou une fonction dans l'interface web seraient les bienvenus. (Merci à cssh pour l'occasion).


Sécuriser (un peu) les machines

Une distribution par défaut mérite toujours quelques retouches. Exporter mysql sur le réseau « public » du hosting gandi nous ennuyait un peu. À grands coups de netstat, fermer les services inutiles qui écoutent sur un port public. Avec l'aide de tcpwrappers (hosts.allow, hosts.deny), on ferme toutes les interfaces « privées » (sshd, mysql réservé aux machines frontales du web).

Restera à bien faire attention au code php et à nos queries mysql : le meilleur moyen d'éviter les injections est encore de binder tous les params après un prepare(). En plus, ça décharge la DB lorsqu'on effectue plusieurs execute.

Un détail important : notre site autorisant l'envoi de mail à un destinataire « arbitraire », il était critique de limiter au maximum son exploitation potentielle par un spammer malin : restrictions du nombre d'envoi par coupon, au minimum, et monitoring.


Prévoir l'environnement de dev et le déploiement

Partager les données entre les sites, c'est ajouter un "single point of failure" et un point de contention à l'archi. Nous optons donc pour un déploiement "local" à chaque serveur du contenu du site. Un site de développement et de "staging" sur une VM sert à tester et développer les mises à jour. Un script et quelques rsync permettent de déployer l'ensemble sur tous les frontaux de l'architecture. On a dit simple !


Surveiller ses ressources

Quelques minutes avant l'opération, pour prévenir plutôt que guérir, la totalité des machines virtuelles sont augmentées d'une à deux parts. En utilisant l'interface des stats, dès le premier jour, on peut constater l'ennui total qui habitait les machines virtuelles:

Cpu sur un front FR Interface réseau sur un front FR

Il aurait été malin, à ce moment précis, de revenir à une part par machine. Ou d'exploiter gandi "autoflex", ou encore, vu le type de charge observée, de préparer des flexs programmés pour les heures de lâcher des coupons ! Malheureusement, beaucoup de monde sur beaucoup de ponts, on a raté l'occasion de vous faire cette belle démonstration (écono-techno-(éco ?)logique).


Un code léger vaut mieux que mille CPU costauds

Même si nous avions à notre disposition plusieurs milliers de CPU et beaucoup de teras de RAM, mardi fut suffisamment chaotique pour qu'on en reparle ici : après un lundi très bien tenu en charge, le plan d'exécution de notre unique SELECT COUNT changea brutalement et devint terriblement plus lent (300ms). Avec foi, nous avions pensé que ce query « unique », sur une table présente complètement en mémoire, ne poserait pas de problème : il était donc exécuté sur toutes les pages du site. La concurrence d'accès avec les UPDATEs des coupons finit par avoir raison de la base qui, malgré des stats systèmes proches de l'idle, entra discrètement en contention de lock.

La réaction habituelle est d'ajouter des parts pour monter en charge. C'est une solution temporaire acceptable, mais ça ne suffit pas !

Un analyse système, une remise en question du code, et une utilisation salvatrice de memcached permit de retrouver des performances acceptables. Une modification des queries utilisés aurait peut-être pu faire l'affaire également.

Une moralité à cet épisode: le code, les indexes, l'architecture, (…) sont les garants de votre montée en charge, et si ils sont « cpu friendly » vous épargneront, sinon une catastrophe, au moins un achat de parts inutiles.

En plus, comme on dit ici en plaisantant, c'est écolo.


Quelques chiffres


  • 36 parts, mais on aurait pu tenir sur moins (snif)
  • 5% de CPU en peak
  • 4000 requêtes par frontal dans la première minute de chaque heure de pointe (environ 1400 req/seconde au total)
  • un minimum de 11 secondes pour donner 1000 coupons
  • pour le même nombre de coupons, un maximum de 40 minutes, pendant l'incident.

- page 1 de 2