Nous sommes le Jeu 28 Mars, 2024 20:39
Supprimer les cookies

Idées de refonte du Framakey Webapps Manager

Support et Développement des applications web portables

Mer 31 Juil, 2013 12:30

Dans le fonctionnement des webapps portables, il y a plusieurs trucs qui me gênent :

- D'un côté c'est super pratique de faire cohabiter plusieurs webapps ensemble, de l'autre c'est quand même assez lourd de se trimbaler zwms, mysql, php, etc en autant d'exemplaire que de webapps.

- L'idée de jongler avec les ports pour rendre chaque webapp autonome ça marche bien mais ça n'aide pas à ce que d'autres contribuent à maintenir ou ajouter des webapps portable parce qu'il faut avoir un peu compris la logique qu'il y a derrière (notamment l'intérêt du startup.ini : c'est en anglais et fastidieux à tester). Alors que des développeurs qui savent installer des CMS sur un serveur ayant une configuration assez basique il y en a plein.

- Ensuite, je trouve ça tout à fait pertinent de regrouper les fichiers web et la base de donnée dans un même dossier mais en l'état il y a un pb de sécurité (dont on avait déjà parlé) du fait que la bdd est dans le dossier de la webapp au lieu d'être à côté.

- Enfin, ZazouMiniWebServer n'étant officiellement plus maintenu, ça pose un problème de pérennité du WebappsManager (cela dit peut-être que dans 10 ans plus personne n'utilisera de logiciels portables ou de pc sous windows :) ).


Du coup, je verrais plutôt les choses comme ça :

- Un WM (WebappsManager) unique contenant Nginx en remplacement de ZMWS (par nature, la version windows est portable et à mon avis c'est un choix durable), MySQL, PHP, Adminer et/ou PhpMyAdmin pour ceux qui en on l'habitude.
Il existe des projets similaires qui vont dans ce sens : WT-NMP, NMP, Winginx, Whimp ou encore celui là.
En pratique ça signifie que le WM est inclus dans le core de la Framakey. Concernant PhpMyAdmin, en terme de poids on fait tellement d'économie à côté que ce n'est plus si gênant que ça de l'ajouter mais à la limite on peut très bien le proposer comme un supplément installable via synapps.

- Concernant la structure on garde à peu près la même, exemple avec Wordpress :
WordpressPortable/
~~~~~~~~~~~~~~~>App/
~~~~~~~~~~~~~~~~~~~>AppInfo (contenu habituel mais plus besoin de startup.ini)
~~~~~~~~~~~~~~~~~~~>www/
~~~~~~~~~~~~~~~~~~~>logs/
~~~~~~~~~~~~~~~>Data/
~~~~~~~~~~~~~~~~~~~>mysql/ (et uniquement ce dossier)
~~~~~~~~~~~~~~~~~~~>master.sql (et fichiers d'export)
~~~~~~~~~~~~~~~>Other/ (comme actuellement sans FWM)
~~~~~~~~~~~~~~~~~~~~>Tools/
~~~~~~~~~~~~~~~~~~~~>CreationLanceur.exe
~~~~~~~~~~~~~~~>WordpressPortable.exe

- Que fait le lanceur ?
  1. Vérifie qu'il y a bien un dossier ../../Framakey/WebAppManager (ou ../Framakey/WebAppManager si Wordpress n'est pas installé dans le dossier "Apps", ie utilisation hors contexte de la framakey). Sinon, il télécharge le WM et le dézippe. Ce point là ne se produirait que si on a téléchargé la webapps en standalone sur framakey.org. Donc si jamais le dézippage est une fonctionnalité trop compliquée à coder en ahk, on peut aussi utiliser un .exe auto extractible. Il y aurait donc le WM inclus dans le core et une version .exe.
  2. Crée un lien symbolique dans le dossier mysql/data du WM pour faire pointer vers "Apps/WordpressPortable/Data/mysql/"
  3. Modifie le "server block" dans la config Nginx pour qu'il prenne en compte le "site" Wordpress.
  4. Lance le WM. C'est à dire fait tourner les serveurs Nginx et Mysql et affiche le menu dans la barre de notification
  5. Ouvre le navigateur (tant qu'à faire Framafox) sur localhost/wordpress et affiche le menu spécifique à Wordpress dans la barre de notif
Grâce aux points 2 et 3 on oublie la question de la gestion des ports web et sql. Et il se pourrait même qu'on puisse utiliser par la suite d'autre sgbd (postgres, sqlite...) et d'autres langages de prog (node.js...).


- Par rapport au menu unique actuel on se retrouverait donc avec 2 (ou plus) menus, Wordpress et WM :
Par défaut sur Wordpress :
> Ouvrir - Aide - Site Officiel - Support Officiel - Article Framalibre - Support Framakey
> Sous-menu Scripts : Export bdd - Réinit bdd (ces 2 là étaient en scripts génériques) - Réinit log/pass - Réinit config - Ouvrir wp-admin.php - Editer wp-setting.php - Editer scripts.ini
> Quitter : supprime lien symbolique Mysql et server block Nginx ; puis vérifie s'il est la dernière webapp au quel cas on ferme aussi le WM sinon on recharge la config serveur.

Dans le menu WM :
> Config avancée - Infos - Aide WM - A propos
> Sous-menu Scripts : Editer php.ini - Ouvre localhost/phpinfo.php - Editer scripts.ini du WM
> Sous-menu Mysql : idem actuellement avec phpmyadmin en plus
> Sous-menu Nginx : idem menu ZMWS actuel
> Quitter : supprime tous les liens symboliques Mysql et servers blocks Nginx ; ferme le WM et toutes les webapps ouvertes.

Présenté de telle manière, ça me semble plus intéressant et compréhensible pour l'utilisateur débutant. Ça peut peut-être l'inciter à essayer de comprendre comment marche wordpress avant d'être noyé sous les infos plus techniques du WM (config serveur, php.ini, mysql, etc)

EDIT :
Points positifs
  • Réduction de la taille des fichiers : bon pour la clé et pour le temps de téléchargement
  • Maintenance réduite : quand on mets à jour le WM, l'effet est immédiat pour toutes les webapps d'un coup (pas intérêt à se planter côté dev :) ).
  • Développement simplifié :
    • en gros, on a juste à faire une installation de la webapp
    • s'il y a des chemins absolus dans la bdd ou dans les fichiers de conf on garde le startup.ini mais ça devrait rester marginal.
    • et du coup, on peut se permettre de peaufiner les scripts.ini
    • et même envisager un script de synchronisation ftp avec un serveur de prod.
  • Utilisation réseau simplifiée : puisqu'il n'y a plus de gestion des ports, il suffit de donner l'ip de la machine sur laquelle tourne le WM et l'utilisateur aura accès à toutes les webapps en fonctionnement. Ça évite aussi les problèmes de configuration du pare-feu.
  • Stabilité/rapidité : parce qu'un seul processus serveur/php/sql est lancé pour toutes les webapps
  • Sécurité : cloisonnement www/sql et une seule modification à faire pour sécuriser l'accès à la bdd
  • Pérennité : logiciels très utilisés et maintenus
JosephK

Avatar de l’utilisateur
Messages : 2221

Mer 07 Août, 2013 11:42

J'ai fait un prototype avec wordpress : Téléchargement (le dossier K sert juste à désigner la racine de la clé)
Comme je ne sais pas coder en ahk ou autoit, j'ai juste travaillé sur l'architecture à partir de Whimp.
Donc il n'y a ni lanceur, ni webapp manager. C'est surtout pour vérifier la faisabilité de la refonte.
Le prototype contient : NginX 1.4.2 (version stable), Php 5.4.17 (pas moyen de mettre la 5.5.1 chez moi), MariaDB 5.5.32, Adminer 3.7.1, Wordpress 3.6

Pour lancer nginx, fast-cgi et mariadb il y a le script Start_All.bat et pour les arrêter Stop_All.bat (légères modifs par rapport à whimp).
J'ai ajouté un fichier Reload_Conf.bat pour recharger la config de nginx parce que j'en ai eu besoin pour tester. Dans le lanceur de la webapps on aura besoin de recharger la conf de nginx.

Techniquement comment ça se passe ?
J'ai respecté la structure ci-dessus et mis en place/vérifié les points 2 et 3 sur ce que doit faire le lanceur.
Remarque sur les %var% :
Ce sont les variables dans le appinfo.ini ou définies dans le FWM actuel.
%DatabaseName%=wordpress
%Dir%=WordpressPortable
%ApplicationPath%=wordpress ; c'est pour avoir le nom de la webapp en minuscule.
%root_path_absolute%=K:/Apps/WordpressPortable ; peut être utilisé à la place des ../../../Apps/%Dir% si c'est plus fiable


Pour le point 2, il faut qu'il crée un fichier %DatabaseName%.sym dans le dossier WebappsManager/mariadb/data/ contenant
Code: Tout sélectionner
..\..\..\..\Apps\%Dir%\Data\mysql\
Il faut le supprimer en quittant.

Pour le point 3, il faut
  • Ajouter au fichier nginx/conf/nginx.conf avant
    Code: Tout sélectionner
       location / {
    une ligne
    Code: Tout sélectionner
       include webapps/%ApplicationPath%;
    (si elle n'y est pas déjà)
  • Créer/Écraser le fichier %ApplicationPath% dans le dossier nginx/conf/webapps contenant :
    Code: Tout sélectionner
    location /%ApplicationPath% {
          alias ../../../Apps/%Dir%/App/www;
       index index.php index.html index.htm;
       access_log  ../../../Apps/%Dir%/App/logs/access.log;
       error_log  ../../../Apps/%Dir%/App/logs/error.log;
       
       location ~ /%ApplicationPath%/(.*\.php)$ {
          try_files  $uri =404;
          fastcgi_param  SCRIPT_FILENAME  '%root_path_absolute%/App/www/$1';
          fastcgi_pass   127.0.0.1:9000;
          fastcgi_index  index.php;
          include fastcgi_params;
       }
    }
    Pour FastCGI, le %root_path_absolute% est indispensable.
  • Recharger la conf de nginx
En quittant on peut soit vider le fichier de conf de la webapp, soit supprimer la ligne dans nginx.conf (ou les 2). Puis recharger nginx.

Pour le reste, il faudrait un cobaye développeur qui accepterait de reprendre le code existant du FWM pour le remanier ;)
Je vais essayer de détailler l'algo...
JosephK

Avatar de l’utilisateur
Messages : 2221

Jeu 08 Août, 2013 12:17

Synthèse graphique :
Image
JosephK

Avatar de l’utilisateur
Messages : 2221

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit