ShellCheck outil d’analyse pour vos scripts shell

Qu'est-ce que ShellCheck ?

ShellCheck est un outil d'analyse de scripts shell assez puissant dans la lignée de Lint qui devrait se trouver dans la boîte à outil de tout devops Unix.

Cet utilitaire vous permettra d'identifier de manière statique (sans exécuter le code) un bon nombre de petits défauts dans vos scripts shells qui, sur votre utilisation courante, fonctionnent peut-être comme un charme mais qui mis dans les mains d'autres personnes provoqueront des erreurs pour le moins embêtantes.

Par exemple, imaginez que pour une raison X ou Y, la variable suivante n'est pas renseignée...

rm -rf "$PATH_TO_FOLDER/"*

C'est une erreur triviale mais qui peut coûter très cher; bien d'autres sont listées par Koalaman, l'auteur du script.

Parcourir l'article

DevFest Nantes 2016 : déploiement continu, IAAS et DevOps, retour sur 2 conférences qui en parlaient

devfest2016_logo

Jeudi 10 Novembre 2016, Le DevFest de Nantes nous proposait 2 conférences :

  • Continuous deployment avec Spinnaker, automatise tous tes déploiements, présenté par Stéphane Lagraulet d'Ippon Technologies
  • Docker et Rancher au service d'une infrastructure as code, la fin du métier de Ops, présenté par Olivier Bierlaire de Sparklane

Ces 2 conférences, au travers d'outils différents, nous ont présenté le concept de l'infrastructure as code (IAAS).

Déployer automatiquement vos applications avec Apache Karaf

Lors des phases de développement par itération il est parfois long et pénible de redéployer les binaires produits à chaque compilation vers les environnements de tests ou de recette.

Dans cet article je vous propose découvrir le framework Apache Karaf qui est une alternative intéressante à des solutions plus lourdes (type Jenkins, Ansible, Docker, etc...) pour déployer vos applications depuis vos repository Maven en mode 'devops'.

Découverte, installation et prise en main

Apache Karaf est ce que l'on appelle un 'conteneur d'applications', c'est-à-dire une application dont le but est d'embarquer et de gérer le cycle de vie d'autre applications. Il peut gérer des jars classiques mais également des jars répondants à la spécification OSGI, appelés 'bundle' qui contiennent les informations permettant de démarrer ou arrêter les services applicatifs et de gérer les dépendances.

Go… Perf !

Pourquoi s’intéresser à Go ? Parce qu’à Go sont associés les mots suivant : simplicité, rapidité, concurrence, microservice et surtout parce que Docker est écrit en Go. Go est fait pour la partie serveur, c’est un concurrent direct de Node.js.

Quelles sont les qualités d’une nouvelle plateforme de développement côté « serveur » ? Revenir à la simplicité, mettre en œuvre les principes de séparation d’intention et de cohérence forte. Simplicité pour le développeur, mais aussi un cycle de vie efficace de la conception, en passant par le développement, par les tests, par l’intégration et enfin par la mise en production.

JUG Summer Camp 2012 : Keynote

Nous avons eu le droit à une Keynote, exercice peu facile s'il en est, de Nicolas De Loof à propos du "développeur en 2012".

Sur un ton humoristique, simulant l'enregistrement "live" du podcast les Castcodeurs, Nicolas a utilisé des marionnettes reprenant les habitués du Podcast :

  • Emmanuel Bernard
  • Guillaume Laforge
  • Antonio Goncalves
  • Vincent Massol

Jusqu'à présent, le voie royale telle qu'on l'apprend à école consiste à commencer sa vie professionnelle en tant que développeur pour très rapidement espérer devenir chef de projets pour atteindre le Saint Graal avant 50 ans de Directeur de projets. Illustrant son propos avec une photo de Jacques Séguéla en lui faisant dire : "Si à 50 ans, tu n'es pas Directeur de Projets, tu as raté ta vie !", il nous invite à prendre du recul sur le métier de développeur en 2012.

Le développeur 2012 essaye de reprendre la main sur ce diktat et on assiste maintenant à la prise au sérieux des développeurs expérimentés. L'idée est qu'un développeur de très bon niveau peut à la fois faire une très belle carrière, voire une plus belle carrière, qu'un chef de projet. Le mouvement "Fier d'être développeur", illustré également à Devoxx France 2012 par Pierre Pezziardi, décolle en 2012 et les développeurs français prennent de plus en plus conscience de la valeur de leur métier.

En 2012, le développeur est maintenant connecté ! Il utilise abondemment ses réseaux sociaux, si bien qu'on peut assister quelques fois à des écarts entre le discours du commercial et le profil LinkedIn d'un développeur ! Le développeur est connecté, certes, sauf lorsque le proxy d'entreprise lui interdit l'accès aux ressources : IRC, Twitter, ... En France, les DSI indiquent souvent qu'il y a risque de diffusion des informations confidentielles de l'entreprise... A moins que l'entreprise n'ait peur que le développeur se rende compte de ce que les autres boîtes font !

Le développeur 2012 est polyglotte ! Il ne connait plus seulement Java ou C++ mais s'adapte aux bouleversements et se doit de connaitre plusieurs autres langages. Ne serait-ce que pour se rendre compte que des mouvements émergent et peuvent changer radicalement notre façon de développer. Il y a maintenant bientôt 20 ans, lorsque Java est sorti, peu ont considéré que ce langage pouvait servir à autre chose que d'animer des pages Web avec quelques Applets. Tout était C, C++. Aujourd'hui, ce langage est leader. Les différents langages émergeant (Scala, Ceylon, ...) connaîtront peut-être la même adhésion.

Le développeur 2012 est communiquant ! Il ne doit pas rester enfermé sur lui même et sortir de son habit de Geek. Il doit aller aux conférences, nouer des liens, proposer lui même des sujets de talk. En deux mots, il doit être sociable et aller de l'avant pour réussir dans son métier.

Le développeur 2012 est un DEVOPS ! De plus en plus, le développeur sait installer les services dont il a besoin. Il suit le courant Devops et provisionne lui-même les services dont il a besoin, que ce soit sur son poste ou en production à l'aide de solution de PAAS ou SAAS. Il pense Devops pour lui même déployer ses composants sur l'infrastructure à l'aide de code (développements de recettes pour Chef ouPuppet par exemple). Il utilise des services lui permettant sur son poste de dév de disposer d'une configuration analogue à celle qu'il trouvera en production, par exemple avec Vagrant. Le développeur 2012 ne peut plus rester dans son coin et doit impérativement parler aux ops et sortir du mode : je développe, tu exploites. Néanmoins, dans les entreprises françaises, on constate qu'il y a souvent des proxy à l'intérieur de l'entreprise pour isoler les devs et les ops. C'est une barrière à faire tomber !

Le développeur 2012 travaille avec et dans le Cloud ! De plus en plus, les ressources, les services et l'infrastructure sont dans le Cloud. L'essor de GitHub, de Amazon, de Cloudbees (dont Nicolas fait parti) ou de Cloudfoundry montre que le développeur doit prendre connaissance et utiliser intensivement ces services.

Le développeur 2012 met évidemment les mains dans le code ! Il n'a pas peur de reprendre du code existant, de le retravailler.

Pendant 30 minutes, Nicolas a donc revu les caractéristiques principales du développeur en 2012 sur un ton décalé et amusant mais avec un fond très intéressant que tout développeur devrait méditer !

DevOps @ Devoxx

J'ai eu la chance de pouvoir assister à la présentation "Les 5 mercenaires du DevOps", qui s'est tenue à l'occasion de Devoxx 2012.

Dans une très bonne ambiance, les animateurs de la session nous ont dressé un tableau très pertinent de ce qui se cache derrière le terme DevOps, agrémenté d'illustrations très pratiques. Pour ceux qui ont raté cet événement, voici ce que j'en ai retenu.

1. DevOps, kézaco?

Le terme DevOps mérite une petite explication. Dans le développement d'une application ou d'un logiciel, trois acteurs principaux sont impliqués :

- le business (le biz) : c'est le client (ou les utilisateurs)

- les développeurs (le dev) : les réalisateurs du projet ou du produit

- les opérations (les ops) : les personnes qui assurent son fonctionnement opérationnel.

Le terme DevOps désigne le point de rencontre entre le monde des développeurs et celui des opérations.

2. C'est quoi le problème?

Si vous faites partie du monde des Dev ou du monde des Ops, cette question ne vous surprend pas... Disons qu'il est difficile pour les uns et les autres de se comprendre, parce que leurs besoins sont presque antinomiques :

- les développeurs cherchent à délivrer des fonctionnalités nouvelles toujours plus rapidement

- les opérationnels cherchent la stabilité et la performance.

De plus, le dialogue est souvent perturbé par le fait que les développeurs se contentent de livrer des éléments de l'application, parfois avec une documentation (in)complète - et complexe - que les opérationnels peinent à installer. Et dans l'autre sens, les opérationnels ne savent pas quelles informations fournir aux développeurs pour les aider à reproduire ou à comprendre des dysfonctionnements de l'application.

3. Et l' intégration continue, c'est pas fait pour ça?

L'intégration continue c'est bien. Mais c'est surtout fait pour améliorer le travail des développeurs et la qualité de leurs livrables. Mais ça ne résout pas le problème de "qu'est-ce qu'un livrable"? Pour le développeur, c'est souvent un jar, ou un war, accompagné d'une bonne documentation d'installation. L'opérationnel, lui, préfèrerait un rpm, incluant les écrans de paramétrage spécifique et les procédures de migration et de rollback, au cas où...

Donc, si une intégration continue est nécessaire pour adresser les problématiques DevOps, elle n'est pas suffisante. Il faut combler l'espace entre ce que le développeur considère comme étant un livrable (le war), et ce que l'opérationnel considère comme étant un input (le rpm).

4. DevOps, c'est des outils?

Oui. Mais pas que.

DevOps c'est avant tout une philosophie, une volonté. Un peu comme l'agilité qui, elle, a permis d'améliorer le dialogue et la collaboration entre les deux premiers maillons de la chaine, le biz et le dev (mais bon... agile, ça sonne quand même mieux que BizDev!).

Mais, comme il est très difficile de faire du SCRUM sans outil, DevOps a aussi besoin d'un outillage adapté.

5. OK, je suis convaincu. De quels outils ai-je besoin?

On peut considérer que l'outillage utilisé pour l'intégration continue se prête bien à la mise en place de DevOps. Notamment :

- une repository d'artefacts qui permettra d'échanger les packages de livraison entre l'équipe de développement et celle d'exploitation.

- un moteur d'intégration continue qui permettra d'automatiser les jobs de déploiement pour une mise en production ou une livraison aux équipes de tests sans soucis.

L'outillage à adopter dépend de votre budget. Mais parmi les solutions les plus populaires on peut citer :

- SVN ou git pour la gestion de configuration

- Nexus, Archiva ou Artifactory pour la repository d'artefacts

- Bamboo, Teamcity ou Jenkins pour le moteur (de l'avis des animateurs, Bamboo et Teamcity sont plus avancés que Jenkins, mais ils ne sont pas gratuits...). On peut imaginer un moteur pour le développement, un pour la QA et un pour les Ops.

- Fisheye, Crucible pour la collaboration autour des sources et des packages

- Confluence pour la collaboration au sens large

DevOps se justifiant également pour le dialogue entre le développement et les équipes qualité, on peut ajouter à cette liste Sonar pour la validation du code.