TchouMerci roidelapluie, sympa le p'tit slide. J'ai juste pas compris un slide nommé "multiple VM", je comprends plus que tu as une VM avec un seul serveur httpd qui réponds sur deux ports. J'ai dû louper une étape.

Non dans ce cas la je crée deux VM au lieu d'une, avec un seul fichier de config.

Tchousi "Galette" est le galette de gestion des adhérents pour les assos, le php s'impose

Oui c'est de cette Galette que je parle.
Le lead-dèv utilise aujourd'hui Zend DB 2, Smarty et une autre petite tripoté de plugin (Analog, TCPDF, etc.) et propose de changer fondamentalement le truc avec Slim comme indiqué plus haut.
Et moi, benoîtement, je demande si c'est une bonne solution ou pas.
La principale idée sous-jacente est d'avoir des url :
monsite.fr/galette/adher…
au lieu de
monsite.fr/galette/view_…
Grosso merdo

Tiens, je te met son message directement si tu veux en savoir plus...

RoidelapluieDe l'autre coté l'idée de Docker c'est de générer à l'avance des "images" (containers) qui seront destinées à lancer UN et un seul processus. Il n'est pas question de faire comme LXC et compagnie. L'esprit de docker est vraiment d'avoir des images assez différenciées à la base, prêtes à l'usage, pour faire tourner un process.

Basiquement, un container docker EST une LXC, et peut exécuter autant processus qu'il veut (utilisation la plus classique : apache + sshd).
En revanche docker demande à ce container d'avoir un processus en avant plan. Si ce processus s'arrête, docker considère que le container ne joue plus son rôle et le stoppe.

RoidelapluieLa valeur de docker dans le monde réelle est assez limitée car tout le monde a des applications stateful là ou Docker est fait pour du stateless.

WTF ?
Au boulot, on se pose encore la question de docker en prod car notre hébergeur est en déploiement d'un cloud Apache Mesos et ne maitrise pas encore sa techno.

En revanche en dév, ça dockerise à tout va. Avec un outil "maison", on clone un projet et avec une ligne de commande on instancie tous les containers iso-prod nécessaire (BDD, ActiveMQ, etc...) au fonctionnement de l'application, déjà cablés entre eux en termes réseaux. On a un repository d'images de bases qui nous permettent de pas répliquer tout un tas de configuration communes entre les projets (base_bdd, base_web, etc...)

Les données "persistantes" (sources, databases) du container ne sont pas stockés au sein du container lui-même mais sur l'host, en utilisant le système de point de montage fourni par Docker (assez bien foutu).
C'est la principale différence avec l'utilisation de LXC "brutes", en effet.

RoidelapluieDe plus docker soulève pas mal de questions concernant la sécurité (comparé aux vms). Il y a encore quelques années de travail la autour également.

Il y a effectivement encore du boulot autour de docker, notamment en terme d'outillage (on a du développer les notre, peut être open sourçables un jour).
En revanche en terme de sécurité je n'ai pas de références, on a beaucoup utilisé chez nous des LXC sans que ce soit moins secure qu'un autre type de VM, un container Docker est une LXC.
Tu as des références sur cette question ? Elle m'intéresse beaucoup dans la mesure où on sait qu'on ira surement en prod avec docker, un jour ou l'autre.

PetitCalgonLa principale idée sous-jacente est d'avoir des url :
monsite.fr/galette/adher…
au lieu de
monsite.fr/galette/view_…

Si c'est que ça, une ligne d'url rewriting, et basta. Mais heureusement que tu as collé son message, car son projet est de bien mieux moderniser son truc, et notamment faire du vrai routing au niveau de l'app. Donc, en php, utiliser un framework qui puisse gérer le routing, donc aussi très vite faire du REST et se la pêter dans les diners mondains genre "han mais t'utilise pas les verbes http dans ton appli ? noob !".

Exemple basique en laravel :

Route::get('adherent/{user}', 'adherentController@view');

pour juste une vue de ton adhérent

edit : bien évidemment, les conseilleurs n'étant pas les payeurs, là je suis en train de pester sur un boulot à moi d'il y a 4-5 ans, c'était bien moins élégant ... et ça va rester crade pour le moment ! :D

TchouDonc, en php, utiliser un framework qui puisse gérer le routing, donc aussi très vite faire du REST et se la pêter dans les diners mondains genre "han mais t'utilise pas les verbes http dans ton appli ? noob !".

Pour ma culture:
- REST ?
- verbes http ?

Les deux notions sont équivalentes. Une appli REST, c'est une appli qui utilise les verbes http (get, post, delete, ...) pour ses URL, donc étant très simple à comprendre et interfacer :
/users/ en GET : je veux la liste des users
/users/ en POST : je créé un nouvel user
/users/12 : en GET : voir le 12
en POST ou en PUT : le mettre à jour
en DELETE : le détruire

C'est uniquement une manière d'accéder à ton CRUD de manière logique, avec des URL très simples et logiques. C'est plus élégant qu'un POST /admin/user.php?action=modify&id=12&mescouillessurtonfront=true mais c'est pas non plus ce qui rendra la vue à un aveugle.

Oui, mais ça te permet aussi d'interfacer plusieurs applications entre elles.

Faut que je me mette à Drupal 8 d'ailleurs, ça sera très REST.

Vu que vous avez l'air de toucher votre bille en PHP et toute ces belles technologies, j'aurai besoin de vous pour un problème:
J'ai actuellement une page d'import de données qui prend une plombe à charger, on envoie un fichier texte de 1000 lignes et ça prend longtemps à charger, côté base, y'a des index, je sais pas trop comment optimiser.
Mais là n'est pas la question. La question est la suivante: je voudrais pouvoir représenter le % d'avancement de l'import. Pour l'instant, je ne sais que faire des pages PHP qui prennent un input, traite les données, renvoie un résultat, et pas de traitement asynchrone qui pourrait dire, j'en suis à 10%, 20%, etc.
So!
Comment je peux faire ça? Comment ma page d'import peut dialoguer avec le traitement de l'import pour dire à l'utilisateur, j'ai réalisé x% de la tache?
Pour simplifier, si le traitement me renvoie un *bip* tous les 10% ça me suffit dans un premier temps.

C'est quoi la solution (les solutions)?
- s'abonner à un évènement ?
- côté JS découper le fichier en bloc de x lignes, l'envoyer au serveur et savoir quand la réponse est positive que ça fait x% ?

Lance un processus détaché dont l'état (la progression) est accessible. De là, tu peux te faire une page qui reload toutes les x secondes (ou dans laquelle t'as une requête JS qui va chercher l'état courant).

Je sais pas trop ce qu'on peut faire en PHP pour du "synchrone"... A vrai dire, je n'ai même aucune idée de ce que Django propose à ce niveau là également ^^

GuybrushLance un processus détaché dont l'état (la progression) est accessible. De là, tu peux te faire une page qui reload toutes les x secondes (ou dans laquelle t'as une requête JS qui va chercher l'état courant).

How ?

Sans réinventer la roue :

* Zend Framework Progress Bar
* La dépendance Composer, sur packagist