Vagrant et Ansible

Les configurations via Ansible doivent être testées et éprouvées. Et il est parfois délicat d’obtenir une infrastructure disponible. Personnellement, pour mes développements, mes essais, et mes premières validations, je provisionne des VMs Virtualbox sur mon laptop à l’aide de Vagrant. Le cas d’usage du lab’ nécessitant plusieurs VMs d’usage différent et donc de ressources variées a été présenté dans mon précédent article pour la partie provision. Voyons donc maintenant comment y intégrer Ansible en un exposé étape par étape.

Considérant que beaucoup de sites proposent des get started voire présentent en détails Ansible, je fais l’impasse pour rentrer dans le vif du sujet : Remplir son inventaire des arguments SSH, générer cet inventaire, et appliquer un playbook à cet inventaire, le tout en automatique à l’aide d’un seul vagrant up !

Lire la suite

Vagrant : ad hoc

Les configurations doivent être testées et éprouvées. Surtout quand c’est aussi aisé avec des outils de configuration management tels que Puppet, Ansible, ou SaltStack. Mais il est parfois délicat d’obtenir une infrastructure disponible. Personnellement, pour mes développements, mes essais, et mes premières validations, je provisionne des VMs Virtualbox sur mon laptop à l’aide de Vagrant.

Le cas d’usage du lab’ nécessitant plusieurs VMs d’usage différent et donc de ressources variées a été présenté dans mon précédent article pour la partie provision. Voyons donc maintenant comment se faciliter la vie côté réseau en un exposé étape par étape.

$ vagrant status
IP:           Ports:   Host:
192.168.10.10 22=>2210 kiwi.oloc
192.168.10.11 22=>2211 koala-01.oloc
192.168.10.12 22=>2212 koala-02.oloc

Current machine states:

kiwi     running (virtualbox)
koala-01 running (virtualbox)
koala-02 running (virtualbox)

Voyons comment en arriver à ce vagrant status répondant à notre besoin d’un lab’ complet aux VMs variées dans un réseau ad hoc

Lire la suite

Vagrant : Des provisions

Au-delà de la bonne pratique de versionner sa configuration infrastructure grâce au Vagrantfile, l’intérêt d’utiliser Vagrant est aussi de configurer plusieurs VMs à la fois. Le cas d’usage venant à l’esprit est le lab’ nécessitant plusieurs VMs d’usage différent et donc de ressources variées. Voyons donc ce cas pratique en un exposé étape par étape.

De bons tutoriaux vous exposeront l’installation et les premiers pas avec Virtualbox et Vagrant plus en détails. Je me permets d’être rapide. Dans un premier élan vous tentez un vagrant init qui -déception- ne fait que vous créer un Vagrantfile, le fameux que nous triturerons à souhait. Si vous lisez ce fichier de plus de 70 lignes en supprimant celles vides et les remarques (très instructives), vous obtenez bien peu de choses :

$ sed -e '/#/d' -e '/^$/d' Vagrantfile
Vagrant.configure(2) do |config|
  config.vm.box = "base"
end

Voyons comment l’étoffer pour répondre à notre besoin d’un complet lab’ aux VMs variées…

Lire la suite

DevOps sur PlovDev

De retour de la conférence PlovDev, j’ai eu à répondre à quelques questions pour la newsletter de mon ESN Proxiad. Si j’y suis responsable DevOps, je suis surtout un passionné et un profond convaincu de ce mouvement. Il entre dans la dynamique du surgissement d’un nouveau monde. Une ère passionnante s’ouvre à nous !

Ayant à coeur de dynamiser et partager cette nouvelle approche, je me permets de publier ici cet interview.

Welcome to the era of DevOps!

Une application est absolument tout ce qui existe et se passe entre le push et l’exploitation d’un commit. Quand on intègre cette notion, on comprend le DevOps.

Lire la suite

Welcome to the era of DevOps!

Welcome to the era of DevOps!

How often do you start your day earlier, because of a server crash?
O: I have to confess that I was awakened in the middle of the night hundreds of times. About server crashes, database freezes, hanging applications, and weird situations.

Which is your favorite blog?
O: I prefer to speak about articles. Sometimes I read a really good article and I browse the whole blog. To answer to your question I don’t have a favorite blog, I have favorite podcasts, french geostrategic podcasts.

Which is the book, you would recommend to anybody in the IT community?
O: May I suggest two books? In English and in French. The first one is a must-have to read the book of Jezz Humble and Dave Farley Continuous Delivery. The second one, is more philosophical about our new changing world Surgissement d’un nouveau monde – Valeurs, vision, économie, politique… tout change by Marc Luyckx Ghisi.

Which is the book that inspires you the most?
O: A whole library! Your question is a bit amazing and makes me think about Les combustibles by Amélie Nothomb. This book is about people in a library burning books to avoid the cold, and the recurring question is « which book to burn or to keep? ». So which book I prefer to keep? Utopia by Thomas More, to keep a cape, to keep a vision.

Have you been to Bulgaria? If yes, what do you like the most?
O: I will enjoy my first time in Bulgaria.

Get your lab!

Certaines sociétés veulent leur DevOps lab. Un bien grand mot pour caractériser une plate-forme de travail dédiée aux outils DevOps. A l’instar de tout bac-à-sable, ce lab est un excellent moyen de se les approprier, d’apprendre à les administrer, à les maitriser. Non seulement des sociétés mettent les moyens pour une telle mise en place, mais parfois des individus à titre personnel veulent eux aussi se parfaire voire acquérir de nouvelles compétences. Et donc les uns ou les autres commencent à installer ces fameux outils DevOps.

Comment ça « installer » ? Vous voulez dire apt-get install etc. ? En somme, installer à la main !? Ce qui me parait assez hallucinant quand on parle de DevOps, de configuration et de déploiement automatique, avec toute la batterie d’automatisation et de scripting sous-jacente ! A mon sens, pour un DevOps Lab, il faut le constituer dans un esprit DevOps ou plus exactement en Infra-as-code. Et moi de lancer le projet G10B, le numéronyme pour Get your lab!

Voyons plus avant le concept de ce projet permettant d’obtenir ex-nihilo un DevOps lab sans les mains.

g10b - v0.3
Lire la suite

Installation de GitLab sur Debian

Le partage, un des maitres-mots du mouvement DevOps, commence par l’usage d’un référentiel (Repository pour les anglophones) communautaire. Il sert bien sûr pour partager des sources de codes que chacun pourra corriger et améliorer, mais il sert aussi au perfectionnement des configurations. La mise en commun des configurations, ce grand travail collectif précédemment abordé, permet une mise en lumière sur des besoins spécifiques, les dépendances de certains packages ou certaines versions de logiciels, ou encore certains paramétrages d’intergiciel (middleware pour les anglophones), ou les paramétrages des équipements réseaux. Quant une équipe mets en place un logiciel utilisant un port particulier autant qu’elle l’insère elle-même directement dans le fichier de configuration des plages de ports à ouvrir. A contrario de l’usage propriétaire où il faut opérer à une demande auprès de l’équipe réseau pour reprendre l’exemple, cette démarche de modification par tous -et pour tous- n’est possible que dans une dynamique communautaire.

Un des plus célèbres référentiels communautaires est GitHub.com, or pour différentes raisons, entre autre de confidentialité, il peut être interdit d’usage dans certaines sociétés (OVH : Pourquoi j’ai interdit GitHub ?). Il est donc intéressant de trouver une solution interne. Un de ces gestionnaires de référentiel Git est GitLab qui propose une Community Edition (CE) et une Enterprise Edition (EE), ainsi qu’une Continuous Integration qui sort de notre actuel sujet. Voyons dans cet article comment installer GitLab CE.

Lire la suite

Meetup Puppet Paris

Dans les locaux de D2-SI, le tout premier meetup Puppet en France fut un beau succès ! En ce 22 mai 2014, il a fallu que les organisateurs poussent les murs pour faire rentrer les 42 participants au chausse-pied dans les 35 places d’un salon moderne et confort.
Le chausse-pied en question était l’enthousiasme de l’équipe tout autant que celle des participants. La colonne vertébrale de cette rencontre était l’improvisation, autour de laquelle le partage eut pleinement sa place. Suite à une rapide présentation d’Ahmet Demir, la soirée s’est poursuivie en deux parties. Dans un premier temps une démonstration sur le pouce néanmoins pédagogique de Laurent Bernaille et dans un second temps un cocktail agrémenté de petits fours (entendre un pizza/bière digne des plus belles soirées de coding) d’échanges conviviaux d’expériences et de conseils entre meetupers.

Le second opus eut lieu hier dans les locaux haussmanniens de Xebia. En point final de la journée DevOps Day ; comme quoi ça vibre à Paris !
Cette rencontre était dans un autre format plus proche de la conférence, tout autant plaisant. A la tribune Steven Thwarts de chez Puppet Labs, a présenté Puppet Enterprise pendant que les participants remplissaient des post-its des points qu’ils souhaitaient voir aborder, quand ils ne s’aspergeaient pas en tentant de s’en décapsuler une. Prenant ces notes en ordre dispersé, Steven a animé les sujets pour que les réponses proviennent des participants eux-mêmes, puis il proposait ses propres conseils. Cette sollicitation des participants a cassé le formalisme pour s’orienter vers un réel partage, le tout clos de l’expertise de Steven Thwarts et des commentaires de Steven Coltman, dans un buddies Steven and Steven.

C’est une réelle joie cette émulation et cette spontanéité de chacun. Vivement le prochain Meetup Puppet Paris !

TweetMeetup

Je sais, c’est moche de se citer.

Mon EverNote a retenu pour moi :
http://puppetlabs.com/resources (podcasts & PuppetConf Videos)
http://puppet-lint.com/
http://rspec-puppet.com/
http://gitimmersion.com/
https://github.com/croomes/gonzo

DevOps – Présentation – 3

Le facteur humain est, à mon sens, le plus important dans une démarche DevOps. Dans les deux articles précédents, je décrivais « bonheur de produire de la qualité ensemble », et je vulgarisais rapidement les concepts de Continuous Integration et Continuous Delivery apportant respectivement le bien-être du développeur et le confort de l’exploitant. Concentrons-nous ici sur le « produire ensemble », sur la charnière entre ces deux mondes, autrement dit sur la collaboration de ces deux ensembles d’équipes.

Le terme d’ensemble est choisi pour sa confusion entre l’adverbe et le nom, subtilité de la langue française dont j’abuse. La notion d’ensemble des équipes est important et mérite une présentation. Ce qui nous aménera à se poser la question de leur collaboration ensemble.

Flow

Lire la suite