Spring-boot et Ansible sont sur un bateau

Il y a quelques jours je faisais un retweet d’un article sur lequel j’étais tombé d’une personne ayant automatisé son déploiement d’une application spring-boot sur un conteneur Docker.

Sur HopWork nous avons une approche qui peut ressembler sauf que nous n’utilisons pas Docker et que nous provisionnons avec Ansible.
Oui, donc ça ressemble de loin, dans le noir et par temps brumeux me direz-vous ?
Voyons en détail.

… 

 

Spring Boot : dans le doute reboote

spring-boot-logoLe dernier billet date de plus d’un mois, ça commence à faire. Et pour cause, beaucoup de travail à été réalisé sur Hopwork ne laissant que peu de place pour écrire.

Mais je m’y remets, car écrire un billet de blog me permet de me reposer des questions sur les choix qui ont été pris et de me laisser une sorte de doc, un historique.

Et pour ce billet, je vais parler de Spring boot.

… 

 

PAAS or not PAAS, that is the question

paasJusqu’à récemment HopWork tournait sur un PAAS, mais ça va changer. Pour les quelques uns qui ont dormi ces dernières années, un PAAS c’est l’acronyme de Platform as a service. En très gros c’est un cadre de travail pour délivrer rapidement votre code en production avec tout un ensemble de services préinstallés, gérés pour vous et qui s’associent simplement avec votre applicatif.

Pour simplifier très fort, c’est ce qui permet au développeur de faire un simple : “git push provider master” pour que magiquement votre dernière version sur git se retrouve en prod.

Remplacez ici “provider” par Cloudbees, Heroku, Clever-Cloud, Google App Engine etc…

… 

 

Ansible (timeoff LT 1ère journée)

ansibleNous y voici ! Le timeoff Lateral-Thoughts a démarré dans une super propriété a Garrigues Sainte-Eulalie. Pour résumé, le timeoff c’est une semaine de code retreat avec l’ensemble de l’équipe dans un coin sympa pour veiller, coder, livrer des choses qui nous branchent.

Challenge, je vais tenter de faire un billet par jour sur la semaine si j’apprends quelque chose d’intéressant (c’est déjà mal barré, ce billet a trainé sur deux jours…).

Et aujourd’hui, on va parler d’Ansible, et pour la première fois sur ce blog, ce sera un billet écrit à quatre mains. Mon comparse pour ce billet sera Jonathan Dray qui connaissait déjà un peu l’outil.

Petit défi, trouvez qui a écrit chaque paragraphe.
… 

 

Vagrant et Fabric : prise en main

vagrantPetit jeu, est-ce que vous vous retrouvez dans les différentes situations ci-dessous :

1) Vous avez un environnement assez complexe à reproduire pour chaque poste de dev, un serveur de bases de données, une lib particulière, une configuration système etc…

Vous avez tout tenté :

  • un manuel d’accueil de 3 pages avec toutes les procédures d’install, mais dont l’une des étapes c’est d’aller chercher Gégé bureau 451 car “il y a que lui qui sait ce qu’il faut faire à cette étape” (Vous vous rappelez de notre fameux pompier pyromane ?).

  • des échanges de fichier via USB ou NFS. Mais au fil du temps il y a des tas de versions dans différents répertoire et plus personne sait ce que c’est. A part Gégé qui a la bonne version sur son PC.

2) Vos équipes ont toutes des postes Windows car les outils bureautiques imposé par votre société tourne dessus : Outlook, Office etc… Sauf que pour le développement vous avez besoin d’utiliser une plateforme Unix. Au début vous avez même testé tous les plugins FTP pour Eclipse, SublimeText, Intellij…

 

Tiens, voici Gégé d’ailleurs…

gege

Et puis un jour, vous avez découvert l’utilité des machines virtuelles. Vous avez passé du temps à configurer une VM, vous avez installé tout ce qu’il fallait et vous l’avez diffusé.

Sauf que le temps a passé, les versions de certains outils ont évolué et chacun a effectué ces mises à jour dans son coin. La version de votre distribution aussi a changé et un beau jour la VM d’origine a tellement divergé qu’il a fallu mettre en place des procédures de mise à jour de vos VMs….

Et si on reprenait nos habitudes de dev, qu’on versionnait notre environnement, qu’on le scriptait, voire même qu’on le testait avant diffusion ? Peut-être avez vous déjà entendu parler de traiter votre infrastructure comme du code ?

Dans ce cas, ce billet vous intéressera puisque nous allons parler de création de VM et de provisionning, le tout de façon automatisé et reproductible avec Vagrant.

Si vous avez lu le dernier billet sur Fabric, celui-ci poursuit dans la lignée. Cette fois-ci je vous propose d’utiliser Vagrant pour créer une VM, et Fabric pour la configurer et installer les softs qu’il vous faut.

… 

 

Fabric moi un cluster

pythonJe vous propose dans ce billet de prendre en main Fabric, un outil que j’ai utilisé récemment et qui vous permettra de scripter des déploiements sur plusieurs machines assez simplement.

Pour résumer, Fabric est une lib Python qui vous permet d’automatiser des executions de commandes via ssh sur des serveurs distants.

En sus, Fabric permet de créer une topologie de votre application : quels sont les machines “web”, les machines “bases de données” etc…

Grâce à ces infos, Fabric permet ensuite exécuter des scripts par famille de nœud. Par exemple installer la dernière version de votre Webapp sur tous les nœuds “web”.

Peut-être que si vous connaissiez déjà Rundeck tout ceci vous rappelle quelque chose puisqu’il répond a peu près à la même problématique.

Python Fabric est plus simple d’utilisation, vous ne retrouverez pas l’application Web qui permettait de gérer votre topologie et vous ne retrouverez pas les hooks qui permettaient de déclencher des actions. Mais vous allez voir qu’on y perd pas au change.

Pourquoi Fabric et pas simplement faire du script Shell ? Nous le verrons dans la suite du billet.

Et pour illustrer ce billet par un exemple de la vraie vie, vous trouverez à la fin de ce billet les sources pour installer un Cluster de 3 noeuds pour elasticsearch, MongoDB et Cassandra qui devraient fonctionner sous Debian.

…