Archives par mot-clé : devops

Meetup Puppet Paris

Publié le par
Répondre

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

Publié le par
Répondre

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

Continuer la lecture →

DevOps – Présentation – 2

Publié le par
Répondre

Le rapprochement entre les équipes de développement et d’exploitation est l’élan principal du mouvement DevOps. Pour appréhender l’interactions entre ces deux équipes, il faut comprendre le cycle de vie d’une application. Si celui-ci comporte une phase initiale d’analyse des besoins et d’études de faisabilité entre autre, il passe, pour ce qui concerne notre sujet, par une chaine de montage (un workflow pour les anglophones) qui va de la conception à la mise en production. Du développement à l’exploitation.

Cette présentation est plus de la vulgarisation qu’un discours hautement académique, je prends donc le parti de la simplification et de présenter le cycle de vie comme l’adjonction de deux cycles distincts, celui du développement et celui du déploiement dans les environnements de recette et de production. On pourrait palabrer sur la pertinence de cette césure, et il est vrai que certaines méthodes voire outils ne les distinguent pas aussi franchement, mais le but avoué de cet article est de présenter les deux concepts qui ainsi s’appuient sur un cycle de vie, respectivement le Continuous Integration et Continuous Delivery (Intégration continue et Livraison continue pour les francophones).

LifeCycle-Continuous

Continuer la lecture →

DevOps – Présentation – 1

Publié le par
Répondre

Dans une DSI, les équipes d’exploitation sont garantes de la stabilité et de l’intégrité du système, alors que les équipes de développement sont sollicitées pour des aménagements et des nouvelles fonctionnalités. Leurs objectifs sont source de discorde dont la principale victime est l’activité. Et j’emploie le terme d’activité pour l’activité commerciale de biens ou de services d’une entreprise, pour l’activité morale, sociale, éducative d’une association, pour l’activité politique d’un parti, ou pour tout autre forme d’activité parce que la finalité de l’outil informatique est bien de porter une activité.

Cette activité demande de pouvoir, d’une part exprimer un besoin, soit une entrée pour le développement et d’autre part utiliser son système d’informations dans de parfaites conditions soit une sortie pour l’exploitation. Les plus acerbes diraient que le serpent se mord la queue. Et les querelles de clocher.
Pour le bien de l’activité, le mouvement DevOps promeut la suppression de ce point de friction par le rapprochement entre les équipes. Et pour ce faire, le mouvement DevOps réfléchit, explore et propose de nouvelles organisations, de nouvelles méthodes en privilégiant la motivation de chacun et la coopération de tous.

Continuer la lecture →

La petite graine – 2

Publié le par
Répondre

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.

Continuer la lecture →

Le punk et le DevOps

Publié le par
Répondre

Comment recruter un DevOps ? Parcourant un réseau social, je suis resté interdit devant cette question. Si ce chasseur de tête s’était un minimum informé, il saurait que DevOps n’est pas ni un poste, ni une fonction, ni une qualification mais un mouvement. Mettons de côté cette grossière erreur en reformulant la question : Comment un recruteur peut-il s’assurer qu’un candidat est bien emprunt de la culture DevOps ?

Comment caractériser un mouvement ? Prenons pour exemple le mouvement punk, si nous devions le caractériser, ce serait en citant l’aphorisme No future, en précisant les attributs vestimentaires, les coupes de cheveux, en listant des groupes de musiques, et c’est tout ? Viennent ensuite la contestation, la solidarité, les alternatives sociales, et les différentes tendances politiques. C’est tout un ensemble qui définit un mouvement. Et pour revenir sur le DevOps appliqué au recrutement, comment tester un candidat ?
Continuer la lecture →

Vers l’automatisation de la recette

Publié le par
Répondre

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.

Continuer la lecture →

De la valorisation des constantes

Publié le par
Répondre

Cas pratique ! Dans tout environnement il faut valoriser ses constantes. Que ce soit le nom de l’environnement lui-même, d’un serveur tiers, d’une arborescence… ce n’est pas ce qu’il manque. A la B. Mouret, un fichier de configuration avec toutes ces constantes est défini pour chaque environnement. Malheureusement, quand par exemple une arborescence est redéfinie, il faut, passez-moi l’expression, se pastiller l’ensemble des fichiers à réviser. Comment procéder autrement ?

Voyons donc ici un ensemble de pratiques qu’appliquera la B. Mouret pour tendre vers plus de Continuous Delivery. Au travers de ces quelques principes simples, c’est tout une uniformisation qui en découlera et en conséquence une facilité de maintenance et d’automatisation.

Continuer la lecture →

Vers le Continuous Delivery

Publié le par
Répondre

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

Continuer la lecture →

grub rescue>

Publié le par
Répondre

Fichtre ! Ce n’est pas le résultat escompté. On procède parfois à tâtons, avec trop d’assurance ou à brûle-pourpoint à des aménagements ou des installations. On reboot, et là paf ! On se retrouve face à un grub rescue> qui nous regarde droit dans les yeux. Et un frisson de nous parcourir l’échine.

Il ne faut pas se leurrer, quand on se retrouve dans cette situation c’est qu’on l’a provoquée. Ce sont nos dernières actions d’administrateur système plus ou moins averti qui portent leur fruit pourri. Cet article présente quelques grandes lignes pour se sortir de ce mauvais pas, avec des vrais morceaux de pédagogie dedans.

Continuer la lecture →