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

Similar Posts:

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *