Passage du dédié au cloud : conférence, détail techniques

Dans le cadre de ma série d’articles intitulés « Passage du dédié au cloud« , après un récapitulatif de la conférence, voici quelques détails plus techniques, concernant cette partie.

Plusieurs apprentissages ont été nécessaires, apprentissage plus ou moins simple suivante votre background, mais aussi pas mal de petit ajustement de code et de technique de développement. Commençons donc par ces derniers.

Adaptation de la pratique du développement

Pas mal de petit ajustement sont a prévoir dans la manière dont on fabrique le code applicatif, mais au final tous se réfèrent grossièrement à deux points : gestion des ressources et gestion de l’environnement.

Par gestion de l’environnement, j’entends pouvoir, par des configurations propre à un environnement (production, développement …), souvent définie au travers de variable d’environnement, pouvoir adapter l’applicatif. En gros, on évite d’hardcoder le mot de passe de la base de données de production dans le code. Dans un premier temps cela évite qu’en cas de leak de code on aie, en plus, accès a votre base de données. De deux, cela permet de partager ce code avec plus de personnes en évitant des soucis du type « j’ai tué la base de données de production mon premier jour » 😉 De trois, peux importe l’endroit où vous exécuter le code, celui-ci pourra facilement aller chercher des infos dans la base de données de votre choix, gérer les sessions en fonction de ce qui est disponible, etc.

Par gestion des ressources, j’entends le fait de se dire que si on migre sur le cloud il est normal de ce dire que l’on aura au moins deux instances1 différentes, par conséquent en cas de session, de fichier uploader téléverser, etc. il faut des solutions appropriées.

Techniquement, ceci est réalisé à travers diverses choses. Je vais parler uniquement de ce que l’on a utilisé, car dans bien des cas cela devrait vous suffire, où être un début suffisant pour vous.

  • Gestion des sessions : au lieu d’utiliser le système de base fourni par PHP, à savoir les fichiers, nous sommes simplement passés par memcached, via la configuration au sein du framework utilisé 2.
  • Concernant les fichiers téléverser3, nous avons choisi d’utiliser AWS S3 à l’époque et ce au travers de la librairie Flysystem, qui est une libraire de gestion de système de fichier. Néanmoins, un partage de dossier monter au travers le réseau aurait pu suffire, tout dépend de vos besoins.
  • Gestion de la configuration par environnement : on a utilisé un simple switch dans le fichier de configuration principal. À l’époque on utilisait encore CakePHP et soit ce n’était pas possible de gérer les différents environnements dans les fichiers de configuration, soit le truc était tellement mal foutu 4 que c’était impossible… Ce switch permet de définir le type de session (fichier ou memcache), la configuration d’accès à la base de données …
  • Supprimer certains hardcoding dans le code du genre si on est sur tel nom de domaine alors il faut faire ceci.

Cela semble simple, mais on a quand même pas mal galéré. En effet, à l’époque le code n’était pas si simplement que cela déplaçable sur un autre environnement (plusieurs jours de configuration avant que cela tourne en local).

Grossièrement, c’est les seules adaptations que l’on a réellement du faire pour que cela tourne sans soucis en mode cloud.

Toutes les applications ne sont pas aussi simples ou complexes a migré, surtout si vous utiliser l’un des frameworks open source récent du monde de PHP, cela devrait se passer sans soucis.

Après le code, l’infrastructure

Le code c’est bien, maintenant faut-il encore une infrastructure adéquate pour le faire tourner. Pour cela, il a fallu documenter et tester ce que l’on avait 😉 Et surtout comprendre pourquoi certains modules PHP présent en production, et absent en local était nécessaire en production!

Une fois cette analyse faite, on a tenté de déployer le code, mais cela nous y reviendrons juste après. Restons donc sur l’infrastructure, Engine Yard nous a proposé de passer par Chef pour provisionner et configurer l’environnement de production.
Outre l’apprentissage des pratiques DevOps, il a aussi fallu apprendre un minimum de Ruby 😉 Mais le tout partait sur une base plutôt complète et existante, permettant la construction d’une gentoo. Je n’ai pas grand-chose d’autre à dire sur ce sujet, le net sera plus explicite à ce sujet. 😉

Ça build? Et maintenant on déploie

Une fois le code prêt, et l’infrastructure aussi, il est temps de travailler sur le déploiement de l’application. Pour pouvoir déployer, il faut d’abord pouvoir effectuer un build isolé et reproductible. Soit pouvoir faire tourner une série de commandes permettant de préparer les sources issue du repository git en un code utilisable en production.

À l’époque, dans notre cas, cela se résumait a faire un composer install, quelques chmod et lié le dossier des logs par un lien symbolique. Bref, rien de complexe, en théorie!
On a quand même pas mal galéré sur le sujet. Comme expliquer précédemment le code n’avait pas vraiment été réalisé pour des pratiques modernes et était complexe a installer même localement.
Pour faire simple, on a surtout du faire pas mal de git clone, composer install, chmod, etc. dans des vm juste avant de les tuer et de recommencer 😉 Ceci en corrigeant la tonne d’erreurs qu’il y avait au passage.

Après le build, viens le déploiement qui consiste a prendre le résultat du build et faire en sorte que les processus en ayant besoin (aka le serveur web) pointe sur le bon dossier. Ceci étant fourni out-of-the-box par le fournisseur, il n’y a donc rien a faire. 😉

En conclusion

On se retrouve avec notre production, un code buildable et déployable (y compris sur une machine locale). Le tout a donc été plus que bénéfique. L’apprentissage fut néanmoins pas des plus simples, cependant l’aide que l’on a reçue de la part du fournisseur a aidé.

Dans les prochains billets, je ferais un point sur la suite de l’évolution de la plateforme ainsi que divers techniques apprissent entre-temps.

  1. = deux serveurs, en cloud on parle d’instance pour parler d’une machine qui tourne
  2. À noter que l’on aurait pu se simplifier la vie en configurant PHP et memcache directement au sein des directives elle-même
  3. En « Français » on dit téléverser pour uploader, le terme me fait marrer 😉
  4. par le code en place

Passage du dédié au cloud : cadre de la conférence

Dans le cadre de ma série d’articles intitulés « Passage du dédié au cloud » , je commence par revenir sur le contenu de la conférence, afin de faire un petit récapitulatif.

Revenons donc en 2014, où j’ai effectué, dans le cadre de mon travail, un passage de serveur dédié au cloud de type PaaS au travers de la plateforme EngineYard (à l’époque il offrait du PaaS tout langage). Cette plateforme, à ce moment-là, possédait une surcouche sur AWS et un support qui nous a franchement aidés dans bien des cas complexes.

Mais commençons par le début, avant avril 2014, l’infrastructure c’était surtout quelques applications PHP déployés par FTP, dans des VM. Peu de temps a consacré a l’infra, et plein de choses old-school. Mais cela marchait, et c’est l’essentiel. Suite à plusieurs soucis de production, on s’est vite rendu compte qu’il fallait se bouger si l’on désirait aller plus loin, gagner en stabilité et être plus zen au quotidien.

Par ailleurs, en cas de désastre, le recovery plan c’était pire que de se jeter depuis l’espace en parachute, avec 0 garantie de retrouvée une stabilité ou une plateforme équivalente… Bref, un truc bien dégueu. 1.

 

En février 2014, au phpbenelux conference, j’ai eu l’occasion de discuter avec diverses personnes2, dont une personne technique de chez EngineYard. Chemin faisant, je me suis dit pourquoi ne pas tenter. Tout du moins préparer le terrain ne pouvait pas nuire. En mars 2014, après un peu de discutions business, on commence la vraie analyse de nos besoins en termes de plateforme d’un côté et on travail sur l’amélioration du code existant pour le rendre compatible cloud. Nous travaillons aussi si du fine tunning de notre future plateforme de production.

Avec de l’aide du fournisseur, et pas mal d’huile de coude, nous finissons par tout mettre en place et avoir le tout en production. Et en prime on améliore notre environnement de développements, avec une meilleure gestion de la configuration. Bref, on se retrouve avec les points suivants :

  • code déployable, et buildable de manière automatisés,
  • un environnement de développements plus facilement configurable,
  • du déploiement au « bouton rouge » (on click, cela déploie),
  • un environnement de validation,
  • des app scalable,

Bref, on est content, tout du moins techniquement parlant. En effet, en termes de budget on fait fois six. Cependant, ce n’est plus tout à fait la même chose.

Avant, en faisant court :

  • dédiés
  • déploiement à la main, avec risque de fausse manœuvre et de désynchronisation du code entre la prod et le dev
  • 0 support autre que matériel (genre un disque qui flanche)
  • pas de possibilités de scaler
  • pas d’environnement de validation
  • infrastructure non rebuildable
  • un support technique (moi) qui dormait mal

Après :

  • dédié (certaines applications devaient rester en dehors du cloud)
  • déploiement automatisé
  • support infra et technique
  • possibilité du cloud
  • environnement de validation
  • infrastructure rebuildable « rapidement »
  • moi : zen, sommeil réparateur 😉

Bref, pas vraiment comparable, surtout le dernier point.

 

En résumé, moins de 3 mois entre l’idée et la production, et ce avec énormément de gain. Ceci grâce au PaaS et non à du cloud du type IaaS, la différence entre les deux est surtout liée au fait que vous n’avez besoin que de vous concentrer sur votre applicatif et non sur la configuration de la plateforme. Ceci a une grande importance, même si le coût financier peut rebuter.

Certains m’ont signalé, lors de ma présentation au PHPTour, que je n’avais pas donné assez de détail technique à l’époque, ceci est corrigé avec le billet suivant « Passage du dédié au cloud : conférence, détail techniques« .

  1. Mais mieux que lors de mon arrivée, où l’environnement de développement pointait sur la base de données de production, par défaut 😉
  2. comme c’est souvent le cas dans les conférences

Passage du dédié au cloud : introduction

En 2015, j’ai eu l’occasion de présenter « Comment migrer avec succès dans le cloud » (slides) au PHPTour Luxembourg. Avec une série de plusieurs billets, je vous propose donc de revenir dessus et bien entendu d’apporter quelques informations supplémentaires.

Deux ans, c’est assez long, pas mal de choses ont évolué au niveau technologique! Nous commencerons donc par un point sur ce qui a été présenté dans la conférence, suivie de quelques détails plus techniques et pour finir, un point sur la situation actuel.

Bref, voici le plan des prochains billets :

  • Passage du dédié au cloud : cadre de la conférence
  • Passage du dédié au cloud : conférence, détail techniques
  • Passage du dédié au cloud : 2014-2016
  • Passage du dédié au cloud : vers l’infini et au-delà
  • Passage du dédié au cloud : détail technique
  • Passage du dédié au cloud : Il y en a un peu plus, je vous le mets quand même?