Vagrant : Le développement sur VM

Nous nous sommes tous heurter à la difficulté de mettre en place son environnement de développement, surtout dans le cadre de la mise en place d’une plateforme homogène entre plusieurs postes sans ajout de logiciels tiers et le plus proche possible de l’environnement de production.

– Exemple : une plateforme PHP, MySQL, Postgres dans le cadre de la migration d’un application PHP de MySQL vers Postgres.

Au fil de mes recherches sur le net et surement avec beaucoup de retard je suis tombé sur Vagrant. (http://vagrantup.com)

Vagrant a pour but de rendre plus simple l’utilisation de machine virtuelle dans le cadre de l’environnement de développement. On peut le dire le but est atteint pour la facilité de développement entre la machine hôte et la VM.

Le plus compliqué avec Vagrant va être de créer sa propre machine proche des habitudes de développement de l’équipe. Car Vagrant n’est pas là pour cela, il est juste là pour le montage de la machine et son utilisation au quotidien.

Heureusement, la communauté est très active sur le sujet et des outils sont là pour simplifier la création de sa propre Box avec quelques connaissances. Je pense notamment à Veewee (https://github.com/jedi4ever/veewee) qui est vraiment un outil à s’accaparer pour la création de sa propre Box, n’hésitez pas à dupliquer le projet et pusher vos modifications pour mettre à disposition vos Box, c’est d’ailleurs ce que je vais faire.

Mais, ne vous inquiétez pas, je vous prépare un petit tutoriel pour l’utilisation de Veewee avec une Box en français.

Et, important à savoir tout cela, c’est en Ruby.

Tip SQL: pourquoi Migrer de MySQL vers PostgreSQL?

Comment dire….
quand on a fini de jouer avec MySQL et que l’on veut passer en production, on cherche un moteur SQL de pros.
C’est un peu comme quand tu as cassé ta perceuse achetée chez Lidl (en promo !) et que tu bave devant la bosh dans le rayon chez casto…
Moi, mon vendeur, il m’a fait l’article et je viens tout juste de déballer le paquet:  PostgreSQL 9.
Avec ça, j’ai bien envie de percer des trous partout dans mes serveurs…
Bon, je m’emporte:

  1. MySQL c’est quand même bien!
  2. je fais toujours des courses chez lidl
  3. même facebook utilise la perceuse pas cher de chez Lidl ( MySQL)
C’est quoi les avantages de MySQL ?
  • d’abord le moteur est facilement configurable
  • l’outil de requêtage MysqlWorkBench est pas mal –  je dirais même , il s’approche de ce que fait Microsoft.
  • la doc en ligne est ok
  • la communauté est active
Mais quand on se penche un peu sur le bestiau, il y a des trucs qui me gênent : 
  1. la sauvegarde incrémentale InnoDB => pas disponible en mode gratos. Vas donc sauvegarder 400 Go d’un serveur sur-sollicité….
  2. le mode mono-thread sur les requêtes : Fais donc une auto-jointure sur une table de 25 millions d’enregistrements; ben, tu peux pas Mr patate !! en tout cas pas avec ton kimsuffi à  trois euros six sous. 
  3. pas de sharding (répartition de données)  sauf à  l’implémenter côté applicatif; Bref, réinventer ce foutu fil à couper le beurre que j’ai eu tant de mal à réinventer les 50 dernières fois.
  4. et puis j’ai aussi envie de changer les rideaux , donc je veux ma nouvelle perceuse !
Alors quelle perceuse doit-je prendre ? en général, le vendeur vous demande ce que vous allez en faire.
Moi, je veux :
  1. une Bdd gratos
  2. facile à  administrer 
  3. grosse volumétrie
  4. qui va se comporter en entrepôt de données ( peu de transactions, beaucoup de lectures, beaucoup de calculs)
  5. compatible avec ce qui a déjà  été implémenté côté applicatif
  6. le plus proche possible de l’ANSI SQL 92 ( utilisation des instructions JOIN )
Vous savez maintenant ce que j’ai choisi comme Base de données….

Et vous, vous pensez quoi des avantages de l’un et de l’autre ?