DSC_0001.jpg DSC_0298.jpg DSC_0426.jpg

 i need more coffee

Atteint depuis mon plus jeune âge d'hippopotomonstrosesquippedaliophobie (cultivez vous ça ne fera pas de mal) j'ai décidé de faire un blog sur ma maladie (be feeeaar..).
Blague à part c'est un blog totalement axé génie logiciel que vous trouverez ici. Du PHP, du J2EE, et évidement toutes les technologies qui leur sont liées.

Have fun !

Industrialiser la mise en production de CmsMadeSimple

4 février 2014Posté par : Kevin Danezis dans CmsMadeSimple

Premier article d'une série que j'espère riche en enseignement, basé sur une expérience -en cours- d'industrialisation de cmsmadesimple. Les problèmes que je rencontre et surtout comment cet outil merveilleux se révèle plein de ressources encore une fois !

L'industrialisation

Sous ce nom un peu barbare et four-tout se cache une réalité que peu d'utilisateur de cmsmadesimple rencontre.

Il s'agit pour moi d'automatiser une installation de cmsmadesimple ainsi que toutes ses évolutions futures au maximum, que le rôle d'administrateur système soit cantonné à "je clic ici, le reste se fait tout seul" ... et encore ...

Le cadre du projet est assez ambitieux. Nous parlons d'une série de plateforme de plusieurs milliers d'utilisateurs potentiels chacune qui auront toute comme point d'entrée un site d'accueil : CmsMadeSimple (tadaaaa). Cette volumétrie très importante impose de passer par une architecture que cmsms n'est pas habitué à rencontrer :

L'intégration continue :

  1. Je développe sur mon PC (win + mysql)
  2. Je repousse sur un Git interne
  3. Un cron récupère de Git vers une plateforme de dev (unix + mariaDB)
  4. L'équipe choisit quand copier vers la plateforme d'intégration/ de démo
  5. Le client choisit quand copier vers la plateforme de pré-prod, et de prod dans un second temps.

Nous avons donc différents environnements, différents OS, Database et toutes les emmerdes habituelles en perspectives...

Interopérabilité :

CmsMadeSimple n'est évidement pas le seul logiciel sur ces machines, je parlais au dessus d'une plateforme, il s'agit d'un gros projet Open Source basé sur Symphony2 que j’appellerais arbitrairement "Opso" (merci à mon imagination sans borne) qui aura besoin d'informations issues de CmsMadeSimple (menu, design) tandis que mon Cms aura besoin des informations de connexion côté Opso afin de personnaliser l'expérience utilisateur.

Même base de donnée, mais hors de question de taper dans les tables de l'autre. Nous allons voir comment passer ce soucis aisément.

Réutilisabilité :

Nous avons besoin de conserver une logique déjà connue dans CmsMadeSimple : on ne touche pas au noyau du cms. Donc exit les hacks, on reste dans une logique de module et de balise utilisateur.

MIQ (Make It Quick) :

Pas le temps de trainer en long développement, le client nous met la pression avant même que nous ayons eu le projet. Il s'agira donc de trancher entre le développement custom et la réutilisation de module existant. Les choix entrainant des complications parfois inattendues.

Scalabilité :

Le projet est tellement gros qu'un seul serveur serait insuffisant et surtout à la merci de la première panne venue. Découvrons ensemble les joies du Reverse Proxy, des Loads Balancers et des base de données redondées ce qui -vous verrez- donne des suées à CmsMadeSimple. En tout on démarre avec pas moins de 9 serveurs par environnement. soit un total de 36 serveurs pour l'intégralité du projet composés principalement de VMs.

Joli programme non ?

Allez commençons déjà par entrer dans le vif du sujet : pourquoi utiliser CmsMadeSimple dans ce cadre.

Le projet Opso et CmsMadeSimple

Pour la petite histoire je travail historiquement dans le monde de Java mais je n'ai jamais caché ma seconde vie de Community Manager à ma société qui l'a très bien compris.

Dernièrement, alors que je finissais une mission pour un client, nous avons été démarché pour un projet ambitieux (appelons le Opso hein... ) qui nécessitait clairement un CMS en front. Nous avons donc faire parvenir une série de préconisation en me positionnant sur la base que les CMS, si je ne les connais pas tous, ben j'en connais au moins un plutôt pas mal, et le mot est faible...

Projet gagné dans la foulée (faites péter le champ') nous voici donc partis avec dans l'équipe un expert cmsms et un bon connaisseur WP et avons laissé choisir le client en restant transparent sur le fait que les deux outils ferraient sans aucun doute le travail. Le choix a été fait sur CmsMadeSimple et j'avoue que ça fait plaisir même si la pression arrive en même temps : si je foire mon coup, je grille complètement CmsMadeSimple aux yeux de notre client (multinationale très connue) et mes supérieurs.

Je vous passe la phase d'intégration du psd livré : comme une lettre à la poste... Idem pour les 4 petites pages à la c** qui parsème le cms. L'intérêt commence au moment ou l'on s'organise entre le mec de l'infra (que j'appelerais unixman pour préserver son identité) et moi même pour livrer une première fois.

MariaDb et CmsMadeSimple

La première question était de savoir si CmsMadeSimple supporterait de passer sur une base de donnée non supportée officiellement : MariaDB. La réponse est oui ! A ce jour une installation classique de CmsMadeSimple + le module ListIt2 tournent sans aucun soucis.

MariaDb et CmsMadeSimple et Scalabilité

Aïe les emmerdes commencent... je teste une page, tout va bien, je teste une modification sur une page et là c'est le drame, la modification est affichée une fois sur 3. 3 étant également le nombre de serveurs de base de donnée en clusteur que possède l'infrastructure. Le soucis est rapidement identifié par UnixMan qui pointe du doigt le moteur MyIsam de Mysql/MariaDb qu'utilise CmsMadeSimple qui ne gère pas le clusteur de serveur (et là c'est le drame comme je disais...). Nous tentons de basculer toutes les tables en moteur Innodb (copier/remplacer dans le .sql d'import) et croisons les doigts... ça passe !

Il faut donc penser à modifier via à la commande sed unix par soucis d'automatisation le fichier une fois tiré de Git.

Le soucis ici est porté par le noyau de CmsMadeSimple lui même qui, en forçant MyIsam pour des raisons historiques liées à Wamp et à Windows, nous pose problème. A ce jour je dois encore remonter à la team core la question de changer ce comportement (innodb est globalement meilleur que MyIsam même si ...).

CmsMadesimple et cache

La copie de mon installation personnelle sur un autre environnement pose évidement problème. Le répertoire de cache n'est plus valable. La solution la plus simple est une commande unix post-installation pour nettoyer tout cela.

rm -f tmp/cache tmp/template_c

Un soucis qui donc n'en était pas un.

Passant par Git j'ai pris soin de classer le contenu de tmp/cache et tmp/template_c comme étant des répertoires à ne pas versionner via le fichier .gitignore

The end (?)

Voilà pour ce premier article. D'autres suivront évidement au fur et à mesure avec des sujets tels que le cache du module ListIt2 (le salaud), les webservices dans CmsMadeSimple, la sécurité mise en place et la configuration via $config.php, un peu différente de ce que l'on a l'habitude de faire.

Pour le reste, et bien le produit n'étant pas encore en production, je suis certain que d'autres sujets arriveront rapidement :D

comments powered by Disqus