Nous avons récemment migré l’un de nos projets sur la plateforme d’hébergement Cloud de Google : Compute Engine.
Voici quelques réflexions, outils et problèmes auxquels nous avons été confronté lors de cette migration depuis notre plateforme d’hébergement classique (dédiés chez OVH + Loadbalancer Cisco ACE)

L’interface web :

Google n’a ici pas fait de miracle, et nous fourni une interface web simple et fonctionnelle. Celle-ci reste malgré tout assez limitée, et ne permet finalement que d’exécuter les tâches les plus simples. Nous avons relevés pas mal d’erreur lors de l’utilisation : Erreur inconnue, Accès refusé … apparaissant de manière un peu aléatoire ; rien que quelques F5 ne puissent corriger.

Quelques onglets

Modèles d’instances¹: vous permet de définir des classes de machines virtuelles : type de machine (quantité de RAM, cadence CPU …), les règles par défaut de pare-feux (autoriser HTTP et/ou HTTPS), ainsi que l’image de démarrage² utilisée (une liste de distributions est fournie, il est possible de fournir ces propres images personnalisées)

Groupes d’instances: Cet onglet permet de créer un pool d’instances, soit de manière statique (exemple: créer 5 instances), ou de manière dynamique (le nombre de VM est ajusté en fonction du trafic ou de la charge CPU par exemple). Ce groupe est construit sur un modèle d’instance qui est répliqué X fois.

Instance de VM : Liste des VM en fonctionnement à un instant T. Les instances présentes ici sont créées selon les règles définies dans votre groupe d’instance. Il reste possible de créer manuellement des instances en dehors de tout groupe ou modèle.

Le SDK Gcloud, téléchargeable ici : https://cloud.google.com/sdk/

Cet outil en ligne de commande est très bien conçu ; après l’avoir téléchargé et installé -rien de compliqué-, vous vous authentifiez (une seule fois !) et avez accès à toutes vos instances sans saisies de mot de passe, ou de saisies laborieuses d’ip. L’outil est fait de telle manière qu’il est facilement scriptable en bash via des outils comme awk, sed ou grep, ou de manière plus évoluée en perl, python, etc

Il est possible d’utiliser cette commande pour créer de nouvelles instances, effectuer des snapshots³, ou copier le contenu d’un disque pour construire une image utilisable ultérieurement par vos modèles d’instances.

On peut tout à fait imaginer manager ces instances via un CRM, et ainsi intégrer d’autres facteurs de charges pour calculer le nombre d’instance le plus efficient, tout en prenant en comptes les coûts.

Quelques commandes gcloud utiles :

gcloud compute instances list

Liste toutes vos instances en fonctionnement

gcloud compute ssh --zone europe-west1-b root@votre-instance-sd54d

Effectue une connexion SSH vers votre instance votre-instance-sd54d dans la zone europe-west1-b sous l’utilisateur root

Les performances :

Quelques tests de ping effectué via une instance g1-small située dans la zone europe-west1-b

— google.fr ping statistics — rtt min/avg/max/mdev = 0.511/0.586/0.636/0.055 ms
— ovh.net ping statistics — rtt min/avg/max/mdev = 9.404/9.438/9.491/0.037 ms
— orange.fr ping statistics — rtt min/avg/max/mdev = 22.555/22.712/22.913/0.119 ms
— free.fr ping statistics — rtt min/avg/max/mdev = 6.173/6.248/6.332/0.097 ms

Rien à redire sur la bande passante ou les latences, les écritures disques restent correctes (plus faible que sur un dédié classique, je n’ai pas testé en SSD). Les instances sont créées en quelques instants (une dizaine de secondes tout au plus)
Vous trouverez des comparatifs complets ici : http://www.journaldunet.com/solutions/cloud-computing/comparatif-cloud.shtml

Un scénario d’utilisation

1. Nous avons créé une première instance manuellement qui nous servira de master pour la suite : installation des paquets, configuration d’apache, de php, copie des certificats SSL
2. Le script /etc/rc.local a été modifié pour aller chercher sur notre dépot Git les sources du projet à faire tourner à chaque démarrage
3. La clef SSH du serveur a été copié sur cette instance pour permettre une connexion sans demande de mot de passe (voir ici)
4. Nous avons ensuite converti le disque dur de cette instance en image, que nous avons associé à un modèle d’instance. Ainsi dès qu’une nouvelle VM est créée à partir de cette image, tout est configuré et prêt à fonctionner. Tous les détails ici : https://cloud.google.com/compute/docs/images#creating_an_image_from_a_root_persistent_disk
5. A chaque mise en production d’une version, nous poussons notre code sur la branche master de notre dépôt git
6. Nous lançons un petit script bash qui exécute un git pull sur chacune de nos instances (un exemple se trouve ici)

Cette méthode est très pratique à l’usage : les instances peuvent être détruites ou créés très facilement sans conséquences : les sources à jour sont téléchargées au démarrage de chaque instance, et mises à jours manuellement à chaque déploiement sur l’existant. En cas de problème sur une instance, il nous suffit de la détruire puis de la recréer !

En conclusion

Le système Compute Engine est à nos yeux bien conçu, rapide et efficace (le contraire nous aurait étonné de la part de Google), seul petit bémol peut être sur l’interface web. Ce type d’hosting n’est clairement pas adapté à tous les projets, et peut s’avérer plus onéreux qu’un serveur dédié classique pour des projets trop petits. Google fourni un compte de test valable quelques jours si vous souhaitez vous faire une idée par vous même.

Lexique

¹ Instance : Machine virtuelle ou VM
² Image de démarrage : Image de base de démarrage d’une instance. Système d’exploitation de base (Linux, Windows, …) tel qu’il est juste après son installation.
³ Snapshot : Instantané, copie complète du disque dur d’une instance