-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Il s'agit ici d'installer les logiciels / services nécessaires pour l'hébergement de multiples sites web. On choisit d'utiliser une machine virtuelle, et ainsi se rapprocher de l'architecture réseau typique d'un cloud.
On a besoin de permettre l'éxécution en pas à pas des scripts PHP.
On se propose d'installer le stack logiciel nécessaire sur l'OS Debian. Cet OS inclut une foule d'outils qui seront utiles pour la gestion des briques logicielles (apt), la gestion des services (sudo service), ... Notre choix de technos s'est porté vers le stack LAMP, dans la mesure où :
- c'est un stack très répandu dans l'industrie
- on dispose via ce stack :
- d'un service web (apache2)
- d'un langage de programmation côté serveur (PHP)
- d'un service de bases de données (MySQL)
- d'une interface graphique pour la gestion/manipulation des bases de données (PhpMyAdmin)
- l'installation est TRES rapide et facile, puisque tout est automatique grâce à apt Ce stack logiciel sera installé sur un OS Debian 8, au sein d'une VM montée dans VirtualBox. Cette architecture est typique de ce qu'on appelle aujourd'hui le cloud
Le stack logiciel décrit ci-dessus va être installé à l'intérieur d'un conteneur hermétique, qu'on appelle une machine virtuelle. Cette VM se comporte comme un ordinateur physique sur lequel on aurait installé un OS (windaube, Linux, BSD, solaris, MacOS, ...). La VM est gérée par un hyperviseur, on a choisi virtualbox
Cette VM sera gérée et démarrée par virtualbox dans une simple fenêtre sur la machine hôte. On crée autant de VMs que nécessaire (dans la limite de la RAM de la machine hôte).
Dans la terminologie, on distingue :
- le système hôte ; c'est votre machine, sur laquelle vous installez virtualbox et grâce auquel vous démarrez les systèmes virtuels ; probablement ubuntu
- les systèmes virtuels qui sont démarrés dans des fenêtres du système hôte ; c'est le système sur lequel on va monter notre stack LAMP ; Debian 8
Dans un environnement professionnel, on doit pouvoir modifier et éxécuter des fichiers php en permanence, et surtout en évitant de :
- écraser le travail des autres collaborateurs
- introduire des bugs dans l'éventuel site en production
- exposer sur internet les nouvelles fonctionnalités en cours de développement
De plus, on a besoin d'outils qui nous permettront de :
- créer des dossiers de projets, qui permettront de configurer les dossiers séparément, et surtout une seule fois
- comprendre très précisément les contextes d'éxécution de nos scripts php
- produire du code cohérent
- versionner notre travail, comme d'habitude avec git
- travailler dans un environnement au plus proche de celui disponible sur le serveur où on va déployer notre site ; éventuellement même en utilisant le même nom de domaine final
De fait Sur la machine locale, on va augmenter l'éditeur de texte, pour qu'il fournisse les fonctionnalités de base d'un IDE. Voir la définition d'un IDE sur wikipedia. Les deux fonctionnalités principales dont on a besoin sont :
- un plugin pour dupliquer les sources php locales vers notre VM qui servira les scripts avec son apache
- un debugger php pour faire du pas à pas dans nos scripts php
Dans l'éditeur de texte, on a besoin de définir des dossiers de projets, pour isoler chaque appli ou site web sur lesquels on est amené à travailler. Chacun de ces projets aura des informations de configuration qui lui sont propres, comme l'adresse des sources distantes, les credentials pour s'y connecter, etc...
Vous aurez ainsi de multiples projets configurés dans votre IDE, qui seront autant de sites ou applis sur lesquels vous aurez agi.
Les fichiers php qu'on va éditer pour développer le projet se trouvent physiquement sur la machine locale.
A contrario, les fichiers php qui seront exécutés pour tester le code en cours de développement seront dans une machine virtuelle, qui dispose de ses propres services web et de bases de données.
On écrit sur la machine locale, on teste dans la VM. Ces fichiers doivent être strictement identiques de part et d'autre, sous peine d'aboutir à des incompréhensions... (Mais où est passée ma modife ??)
On pourrait assurer la synchronisation de ces fichiers à la main ; en envoyant le fichier modifié, à chaque écriture, via scp. Possible, mais de toute évidence source d'erreurs et d'oublis.
Il existe heureusement une foule de plugins qui vont assurer cette synchro. En effet cette technique est extrêmement répandue, en raison des nombreux avantages qu'elle présente.
La synchronisation est configurée projet par projet dans l'IDE
Ecrire du code php sans debugger revient à naviguer en mer, de nuit et dans le brouillard : on suppose qu'on connait l'environnement parce qu'on a des cartes marines, mais on n'a aucune idée d'éventuels obstacles flottants ou d'autres navires qui feraient route collision.
On a besoin d'éxécuter nos productions en pas à pas, et ainsi inspecter l'état des variables, du stack, etc... en cours d'éxécution. Cette technique permet de produire au plus vite, un code cohérent et assez optimal.
Pour le langage php, au sein d'apache, la fonctionnalité de debugger est fournie sous forme d'une architecture client/serveur :
- on ajoute à php / apache dans la VM un paquet qui tiendra lieu de client
- on ajoute à notre éditeur de texte un plugin qui tiendra lieu de serveur de debug
Ici le serveur de debug (le plugin installé dans notre éditeur de texte sur la machine locale) reçoit des messages depuis le module xdebug installé sur le php de la VM.
Hélas, le serveur de debug est configuré globalement, ce qui oblige à une rigueur d'organisation des sources php de part et d'autre. Sinon, il faudra adapter le path map à chaque switch d'un projet à l'autre.
On vise, au sein de la VM, l'architecture suivante :
Cette VM expose les fonctionnalités utiles à l'éxécution des scripts php, et permet éventuellement de faire du pas à pas, si du côté du client web on a installé les fonctionnalités idoines.
La VM représentée ci-dessus constitue le service final, tel qu'il sera déployé au moment voulu. Cette VM fait partie du schéma d'archi suivant, du point de vue de la machine hôte :