Petit ajout discret sur Lexpage : les utilisateurs ayant posté un message sur le forum ont maintenant la possibilité de supprimer ce message si le message est vieux de maximum 5 minutes (et qu'il n'a pas été modéré).

... et par la même occasion, mise à jour vers reCaptcha 2 pour l'inscription (donc une case à cocher, grosso-modo, plutôt qu'une image à lire). Le catcha devrait fonctionner en environnement de test également (le widget ne s'affichera toujours pas, car la clé d'accès n'est pas fournie, mais le test sera toujours accepté).

Il est maintenant possible de modifier son message sur le minichat. Je n'ai pas trouvé de moyen d'inclure ça "ergonomiquement parlant", mais vu l'usage limité, ce n'est pas un souci.

Pour faire une modification de son dernier message posté, il suffit d'écrire "s/ancien/nouveau", ce qui remplacera chaque occurrence de "ancien" par "nouveau".

N'en abusez pas pour modifier complètement un message, mais plutôt pour corriger un typo (et si abus, je limiterai la taille du pattern !).

Ah oui : ça ne gère pas les regex. Je garde ça simple.


[Edit : et j'ai enfin commencé à écrire des tests. Pour l'instant, ça ne concerne que deux aspects du minichat, mais j'en ajouterai au fur et à mesure que je retouche à certaines parties du site]

Si certains parmi vous suivent un peu mes péripéties sur le dépôt GitHub du Lexpage, vous avez pu voir qu'il était prévu une migration vers un environnement virtuel en production. En effet, jusqu'à présent, Lexpage tournait dans l'environnement par défaut, ce qui commençait à poser quelques soucis lors de certains tests (notamment pour vérifier la compatibilité avec des librairies et le serveur).

La mise en place d'un environnement virtuel est supposée être simple. D'ailleurs, en local, je ne travaille qu'avec ça, à juste titre. Cependant, cela s'est avéré plus problématique en ligne. A commencer par le fait que la version de certaines librairies sur le serveur est... plutôt datée, et surtout : uwsgi a refusé à plusieurs reprises de fonctionner correctement au sein de cet environnement virtuel.

Finalement, après quelques (nombreux) détours dans la documentation, la solution la plus simple a été de configurer uwsgi pour tenir compte spécifiquement de cet environnement. Au final, cela fonctionne, et ça a permis de mettre en évidence que l'intégration actuelle de PyMySQL (connecteur écrit en 100% Python) dans Lexpage était cassée, et que ça fonctionnait juste parce que la vieille librairie mysql-python (pas compatible Python 3, la prochaine étape du Lexpage) trainait dans le coin (ce qui n'était plus le cas dans l'environnement virtuel). J'ai monkey-patché l'usage de PyMySQL comme c'est conseillé dans la documentation, même si la documentation ne mentionnait pas certaines étapes que j'ai découvertes à coup d'erreurs 500

Évidemment, la seule chose qui n'est pas commune à l'environnement de test et l'environnement de prod (en dehors de l'environnement, bien que ça, c'est réglé), c'était le connecteur mysql (vu qu'en local, c'est du sqlite), et il a fallu que ça plante de ce coté

Enfin, c'est fait, c'est bon, et je vais arrêter de faire planter le site pour aujourd'hui.

Le passage vers Python 3.4 devait se faire sans trop de douleur. J'ai équipé le site avec une batterie de tests fonctionnels pour détecter les principales erreurs. Ca a aidé (notamment une erreur dans hashlib qui aurait empêché l'inscription sur le site, au cas où des fous voudraient encore s'y inscrire).

Par contre, une fois tout ça en prod, ça a été bien compliqué : Python 3.4 indisponible, les backports pas fonctionnels, l'environnement virtuel qui n'est pas pris en compte, uwsgi qui refuse de se lancer en Python 2 (version serveur) pour faire tourner une application Python 3 (version environnement virtuel). Il a fallu configurer supervisor pour lancer uwsgi dans l'environnement virtuel (non pris en charge par supervisor, difficilement accepté par uwsgi) pour que tout repasse correctement en ligne.

Désolé pour les perturbations !! Normalement, cela n'arrive plus :
1. Parce que y a pas encore de Python 4 qui justifie de "tout casser",
2. Parce que les scripts sont mis à jour pour s'occuper de gérer de telles situations à l'avenir,
3. Parce que je compte tôt ou tard passer à Gunicorn et utiliser un superviseur interne à Python pour éviter les soucis entre une version "système" et une version "environnement virtuel". Je pense aussi que je vais à l'occasion mettre un RedHat sur le serveur au lieu d'une vieille Debian. Mais ça, ce sera pour une autre fois (notamment parce que je vais en profiter pour supprimer mes projets qui tournent sous NodeJS, et parce qu'il faudrait que je passe de MariaDB à PostgreSQL pour Lexpage, ce qui ne va pas se faire sans douleur !).

Vu les soucis récents, je vais certainement passer sous CentOS 7 sur le serveur plutôt que Debian Wheezy (notamment parce que je suis tout autant à la recherche de nouveautés que de stabilité) pour tout refaire proprement.

J'hésite encore sur la manière de m'y prendre (en "brut" avec des environnements virtuels, sous Docker ou sous Vagrant). Des avis sur l'évolution de Docker lors des 12 derniers mois ? Je n'ai pas vraiment suivi ce qui s'est passé, est-ce que c'est finalement prêt pour être utilisé réellement en prod ?

Concernant Vagrant (que j'utiliserai de toute façon pour tester localement le serveur avant de déployer CentOS sur le VPS), est-ce que ça peut s'utiliser en production ou pas ? Je n'ai aucune idée de l'overhead d'une VM, mais j'imagine que ça ne doit pas forcément être conseillé ?

D'autres alternatives ?

GuybrushJe pense aussi que je vais à l'occasion mettre un RedHat sur le serveur au lieu d'une vieille Debian.

Il est où le bouton pour détruire son compte sur ce site de merde ?


Déjà, pour utiliser docker, tu peux faire un apt-get dist-upgrade pour passer à la debian 8. Cela dit, j'ai pas fait pour mes serveurs de prod, c'est dans ma todo list, mais j'avais déjà fait pas mal de passages 6->7 sans le moindre soucis (mais certes, ça passait pas du systemV à systemd). Le downtime sera très faible en comparaison d'une reinstall complète, et tu pourras utiliser docker donc préparer le passage à une RH avec un faible downtime également puisque tu auras déjà un dockerfile 100% fonctionnel .... ?

Oui, sauf que j'ai un peu salopé la Debian sur le VPS la dernière fois que j'ai voulu faire tourner Docker, essentiellement parce que la mise à jour n'a pas marché, à cause des noyaux imposés par OVH.

Là, j'hésite entre, grosso-modo, 3 approches :
- Une CentOS que je prépare tranquillement dans une VM, avec des scripts de déploiement automatique de MariaDB, Nginx et les différents projets qui tournent. Ces projets fonctionnent tous en Python et je peux donc virtualiser l'environnement très facilement, avec des outils que je connais (virtualenv).
- Une CentOS que je prépare tranquillement dans une VM, avec juste un Nginx frontal, et des conteneurs Docker pour chaque micro-service : un pour MariaDB, et un pour chaque projet.

Il y a des avantages et des inconvénients aux deux solutions. Je ne suis plus très à l'aise avec Docker, et surtout : il va me falloir faire communiquer les conteneurs entre eux, ce qui était loin d'être trivial quand j'avais essayé il y a un an environ.

Et vu que les projets hébergés ne sont pas critiques, je ne suis pas convaincu sur le gain que je peux avoir en m'encombrant avec Docker, même si la curiosité me pousse à essayer (mais j'ai toujours du mal avec le fait que ce fichu daemon tourne en root).

GuybrushVu les soucis récents, je vais certainement passer sous CentOS 7 sur le serveur plutôt que Debian Wheezy (notamment parce que je suis tout autant à la recherche de nouveautés que de stabilité) pour tout refaire proprement.

À ta place j'attendrais encore un peu, 7.2 sortira très bientôt avec beaucoup d'améliorations, notamment une version de systemd plus récente.

GuybrushJ'hésite encore sur la manière de m'y prendre (en "brut" avec des environnements virtuels, sous Docker ou sous Vagrant). Des avis sur l'évolution de Docker lors des 12 derniers mois ? Je n'ai pas vraiment suivi ce qui s'est passé, est-ce que c'est finalement prêt pour être utilisé réellement en prod ?

Je ne crois pas que tu aies un intérêt a utiliser des conteneurs docker. A la limite systemd-nspawn te suffira mais j'ai un doute sur l'utilité réelle.

Guybrush
Concernant Vagrant (que j'utiliserai de toute façon pour tester localement le serveur avant de déployer CentOS sur le VPS), est-ce que ça peut s'utiliser en production ou pas ? Je n'ai aucune idée de l'overhead d'une VM, mais j'imagine que ça ne doit pas forcément être conseillé ?

Vagrant n'est pas du tout destiné en prod. Par contre tu pourrais essayer son successeur: otto qui se veut etre ce dont tu as besoin, ça vaudrait vraiment la peine que tu passes une heure pour le tester.

GuybrushD'autres alternatives

rkt (rocket), développé par CoreOS, qui semble très intéressant. Un genre de docker sans daemon.

otto

systemd-run

systemd-nspawn

Des simples services systemd (tu peux faire des trucs vraiment cools de base et c'est super simple de faire un wrapper pour virtualenv, tu peux relancer le service quand il plante, ne le lancer que quand il est nécessaire (socket activation)...).

Je vais aller regarder tout ça. J'avais vu Otto quand je me suis intéressé à Vagrant, mais je n'avais pas eu l'impression que ça venait répondre à mes besoins. Je vais retourner lire ça en profondeur.

J'ai mis à jour Django en 1.8 sur le serveur. J'en ai profité pour faire quelques migrations dans la base de données (pour coller aux nouvelles features) et mis à jour aussi les dépendances du site. J'ai supprimé PIL/Pillow (gestion d'images) à cause de sa dépendance vers une librairie C (ce qui rend la création d'un environnement virtuel dépendant de l'environnement extérieur). La seule chose que ça apportait au site, c'était de valider la taille d'un avatar uploadée. Je mettrai autre chose à la place dès que j'ai du temps.

J'ai profité de toutes ces mises à jour pour me passer de uwsgi (dont l'usage dans un environnement virtuel et derrière supervisord était plutôt fastidieux). Gunicorn, tout aussi rapide, a pris le relai et s'avère bien plus simple à configurer et à utiliser. J'ai aussi droppé le support pour Docker (au moins temporairement) parce que je n'ai pas d'installation avec Docker sous la main, et que je ne pouvais pas garantir que le Dockerfile proposé sur GitHub était encore fonctionnel.

Une petite mise à jour du Lexpage aujourd'hui :

- Le rythme de publication des billets ne change pas (s'il y a 8 billets en stock, c'est 2 par jour, sinon 1 seul). Par contre le premier billet du jour sera toujours publié à minuit (alors qu'avant, c'était parfois à 12h), et les éventuels billets ajoutés/supprimés dans le courant de la journée sont pris en compte pour la publication automatique.

- Le bug qui rendait impossible l'upload d'avatar ces 3 derniers jours a été corrigé. Normalement, tout est fonctionnel, au moins pour les avatars en gif, png et jpeg.

- Un icône de login remplacera l'icône de menu lors de la navigation sur petit écran, si le surfeur n'est pas identifié comme utilisateur.

- Mise à jour de la librairie jquery-oembed (même si ça ne résoud pas ce dont on parlait sur le topic à propos de webm et gifv).

Le reste concerne des changements internes (notamment à propos de Markdown) ainsi que des tests supplémentaires (et une vraie configuration de coverage, qui retourne maintenant >80% de coverage au lieu de ~50% comme précédemment, quand il lurkait sur les librairies externes ).