Pelisse Romain

Si Puppet vient déjà naturellement avec le support de nombreux produits et outils, et que PuppetForge regorge aussi de nombreux modules complémentaires, il n'en reste pas moins que la plupart des systèmes d'information incorporent des logiciels « maison », ou simplement trop spécifiques pour bénéficier du support de la communauté. Heureusement, Puppet, comme pratiquement toutes les solutions open source, propose un mécanisme d'extensions permettant d'ajouter aisément le support de nouvelles « ressources », que nous allons étudier en détails dans cet article.

Plus que jamais avec le "cloud" et la vague du NoSQL, les problématiques de montée en charge et de passage à l'échelle (scalability, dans le langage de Shakespeare) prédominent dans la conception d'application en ligne. Comment parvenir à atteindre le nombre d'utilisateurs concurrents attendu ou espéré ? Comment supporter un pic de charge, lorsque cette charge s'accroît temporairement ? Comment améliorer ou conserver son temps de réponse moyen, malgré cette charge variable et généralement grandissante ?

On reproche souvent au développement Java, bien que très apprécié dans les entreprises, de manquer de facilité et de pragmatisme. Ainsi, quand il s'agit de réaliser un petit applicatif, ou un outil en ligne de commandes, on se dirige souvent très naturellement vers le Shell ou des langages tels que Python. Néanmoins, avec l'utilisation de quelques bibliothèques open source bien choisies, on peut aisément utiliser Java pour réaliser de tels projets. Démonstration par l'exemple, qui j'espère aidera le lecteur si un jour le besoin de réaliser un tel outil s'impose à lui...

Un peu plus d'une dizaine d'articles [2.1] ont précédé celui-ci dans ce magazine, et ont déjà amplement décrit des outils de gestion de la configuration de serveurs [1.1], tels que Puppet [1.2], Chef [1.3], ou même encore CFEngine[1.4]. L'objectif de cet article n'est pas de reprendre cet exercice de style, mais d'étudier un cas pratique, et surtout complet, d'automatisation de déploiement d'un serveur.

L'heure du Cloud ayant sonné, il va être temps de revoir nos degrés d'exigence en termes de scripts Bash. En effet, finis les scripts à moitié dysfonctionnels ou cassés, le Cloud ne les permet plus ! Pourquoi ? Parce que le « Cloud » demande de la robustesse, les systèmes qui s'y exécutent doivent survivre aux pannes et autres coupures de réseaux... Oui, mais comment faire ? Comment rendre ses scripts plus robustes et plus propres ? Petite explication de texte dans cet article...

Depuis l'arrivée des réseaux sociaux [1] à la Facebook [1.1] ou professionnels à la LinkedIn [1.2], la notion de messagerie a clairement beaucoup évolué et les attentes des utilisateurs ont évolué de concert. Ces derniers souhaitent désormais un outil de messagerie plus élaboré et plus convivial que le mail traditionnel, et, surtout, de plus en plus de personnes réclament une amélioration de la messagerie dans le cadre de leur travail. Ainsi, l'utilisation de ces nouveaux systèmes de messagerie a même amené certains grands groupes, comme Atos Origin [1.3], à revoir leur propre infrastructure de mails pour adopter une approche dite plus « 2.0 ».

Depuis maintenant plusieurs années, l'informatique « dans les nuages » [1.1] est présentée comme le parfait nouveau « datacenter » : virtuel, simple, économique, puissant et surtout tenant parfaitement la montée en charge. Évidemment, derrière une telle image d'Épinal se cache une réalité quelque peu différente. Cet article, parmi d'autres, prend donc le parti d'étudier, de manière pratique, une problématique volontairement réduite : la mise en place de l'infrastructure nécessaire au déploiement d'applicatifs dans « les nuages ». Ceci pour illustrer que si le « Cloud » est certainement une solution très intéressante en termes d'infrastructure, elle s'accompagne néanmoins et nécessairement d'une adaptation de nos usages et habitudes dans le domaine, mais aussi d'une évolution des outils usuels comme de leur utilisation. Basculer d'une infrastructure physique « classique » à une infrastructure aussi virtuelle ne se fait donc pas de manière aussi transparente que de nombreux slides essayent de nous faire croire...

Parmi les langages émergeant, Scala a clairement le vent en poupe et fait partie, tout du moins dans le monde Java, de ceux qui sont le plus étudiés ces derniers temps. Néanmoins, sa complexité (apparente ou avérée [1.1]) paralyse souvent les développeurs qui souhaiteraient s'y frotter.

En quelques années, Sonar, un projet open source point d'origine de la société SonarSource, est rapidement devenu une référence du marché et certainement le leader de sa catégorie parmi les produits open source. La qualité incontestable du produit, ainsi que sa souplesse, justifient pleinement cette adoption. Cet article vise donc à exposer la facilité d'utilisation et de mise en place de cet outil, en espérant ainsi vous inciter vous aussi à en devenir un utilisateur régulier.