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

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

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

L’apprenti sorcier

Ne maitrisant plus la situation, l’apprenti est dépassé par les événements. Le poème symphonique de Paul Dukas dont la création (première représentation) eu lieu le 18 mai 1897 à Paris, est bien connu. Sans doute plus grâce à une souris à 8 digits doigts, que par Der Zauberlehrling de Goethe.
Expérimentant l’automatisation d’installations, j’ai eu un geste malheureux. Sortez les violons… Mon disque est totalement nettoyé. Je dois tout réinstaller. Rien de bien sorcier.

Quand on bricole ses configurations, il est toujours important de sauvegarder ses données, vous le savez déjà vu le nombre de fois où vous l’avez lu, mais il est tout autant important de se préparer une petite clef USB de réinstallation sans les mains. Tout simplement parce que c’est si facile quand on a tout à disposition et si compliqué avec un disque vierge…
Afin d’éviter l’immobilisation perpétuelle d’une clef, je ne vais lui implanter l’installeur qu’à la demande. Et en démarche devops, j’ai créé un script qui fait le café, et cet article présente les grandes lignes d’une installation ex-nihilo à l’aide d’une simple clef USB, choix effectué en constatant que les lecteurs CD/DVD disparaissent des configurations matériel (qui a dit Raspberry ?). Ce simple passage en revue peut donner des idées ou des indications à tout un chacun.
Lire la suite

La petite graine – 2

Pour automatiser ses installations Debian, il faut savoir concevoir sa petite graine, preseed pour les anglophones. C’est ainsi que je commençais mon premier volet décortiquant partiellement la fameuse petite graine.
Depuis 2 mois, je vous laisse sur votre faim et pour cause ! Force est de constater que je ne sais pas encore comment parfaire ma pré-configuration. Le point d’achoppement est le partitionnement automatique, tout ce qui est partman…

A l’heure actuelle, même si j’ai encore des pistes de recherches et des tests à effectuer, je n’ai toujours pas de réponses satisfaisantes.
Voyons donc dans ce second volet, l’ensemble des recherches effectuées. Parce que savoir s’informer et chercher fait partie intégrante de la culture DevOps.

Lire la suite

Vers l’automatisation de la recette

Comment ça on ne teste pas !? Bin non, ce n’est pas possible. C’est la réponse qui m’irrite le plus juste après le « on a toujours fait comme ça ». Quel est l’intérêt d’une plate-forme de tests où la moitié des jobs est en rouge ? Comment valider un tel fourbi d’erreurs ?
Dans de telles conditions il est nécessaire de connaitre par coeur les enchainements, pour opérer à des évictions, des relances, bref il est délicat et déconseillé d’automatiser ces pratiques.

Afin d’être le plus proche de la production tout en prenant en compte certaines limites des recettes, voyons donc ici un ensemble de pratiques, non pour automatiser mais pour s’y préparer. Une petite remise à plat pour éliminer tous ces incidents normaux (ça me fait mal de l’écrire). Etape nécessaire pour automatiser ses tests et tendre vers plus de Continuous Delivery.

Lire la suite

Vers le Continuous Delivery

DevOps et Continuous Delivery sont les actuels mots à la mode (buzzword pour les anglophones). Après quelques lectures et présentations, certains décideurs se posent la question de l’inflexion vers de telles méthodes. Il faut bien comprendre que derrière ces mots se cache une révision complète des DSI. C’est la fin des fameux silos enfermant chacun dans une mono-tâche technicienne au profit d’un flux automatique organisé par des experts. D’aucuns disent que ce bouleversement est un tsunami, voire un big bang. Il est donc naturel que certains responsables se demandent : Comment opérer à un tel virage vers le Continuous Delivery ?

Cet article orientera vers des perspectives de réponses. Et pour cela, citons d’abord Martin Fowler, un ponte du Continuous Delivery :

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle

  • Your team prioritizes keeping the software deployable over working on new features

  • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

  • You can perform push-button deployments of any version of the software to any environment on demand

Lire la suite

De l’intérêt du Continuous Delivery pour le business

Le déploiement de tout logiciel, installation ou amélioration, est motivé par un besoin business. Et plus l’IT répond promptement à ce besoin, plus rapidement le client ou l’utilisateur interne pourra tirer rapidement profit de ce déploiement.
Cette accroche est le point de départ du concept de Continuous delivery, traduit par Livraison en continu. Cet article est une présentation conceptuelle et non technique à l’attention des décideurs et des techniciens cherchant des arguments pour inciter leurs décideurs à entrer dans le XXIème siècle.

Depuis trop longtemps, un déploiement est le bout d’une chaine bien longue d’un projet, en cascades (le fameux waterfalls). Phase après phase, un tel projet s’étale sur plus d’un trimestre. Certaines sociétés sont rythmées sur des livraisons semestrielles voire annuelles.
Aucun besoin d’études de management pour comprendre que quatre mois après le développement, il peut arriver que le codeur ne se souvienne plus de ses intentions, voire qu’il ne soit plus présent. Si un besoin de remettre l’ouvrage sur le métier se fait sentir, il est à prévoir une latence dans l’aménagement.
Nous sentons bien que nous sommes aux antipodes du concept de Continuous delivery dont le paradigme est le prompt profit.

« Until your code is in production making money or doing what it is meant to do, you have simply wasted your time. » – Chris Read

Lire la suite