Decrypt

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.

[...]

Puppet est un produit open source qui permet de gérer à moindre frais une infrastructure importante en centralisant la gestion de la configuration des machines : il permet de maintenir la configuration des différents types de machines d’une infrastructure iso entre elles et de démarrer rapidement une instance en l’associant à un type de nœud Puppet. Il capitalise également les connaissances sur les composants/paramétrages de chaque type de machines via ses descripteurs.

Capistrano est produit open source qui permet d’associer des machines à des rôles (exemple : role :web, « frontal1 », « frontal2 ») et d’exécuter une tâche donnée en parallèle sur toutes les machines d’un ou plusieurs rôles. Il permet également de capitaliser les connaissances sur les différentes tâches de l’infrastructure et les rend reproductibles et centralisées, donc fiables. il se connecte en SSH et donc assure un niveau de sécurité minimum.

[...]

Comment structurer un projet de manière évolutive, surtout si ce projet propose plusieurs accès/modules (un Front et un Back Office par exemple), utilise un outil d’un éditeur lui-même soumis à ses propres changements de version, un framework et éventuellement gère du contenu ? C’est-à-dire comment faire en sorte que le projet soit maintenable au fil du temps et puisse profiter des dernières améliorations de chaque composant sans avoir à payer de monstrueux surcoûts.

La clé est d’organiser le projet de façon modulaire en évaluant correctement les différentes briques fonctionnelles et techniques du projet à mettre en place.

Nous prendrons dans notre exemple le cas d’un projet développé sous Eclipse et dont le serveur d’application cible est Tomcat. Tout autre technologie est bien sûr envisageable.

[...]

Ce post va présenter une description détaillée de la mise en place de l’infrastructure sur AWS (Amazon Web Services). Je me base sur ce que j’ai mis en place, en l’occurrence, à destination d’une application sociale à forte sollicitation. Cependant, quelque soit la typologie de l’infrastructure sous AWS, les éléments à mettre en place seront toujours les mêmes.

[...]