C'est fait ! Plusieurs années après sa première annonce, la voici enfin qui débarque.
Vendredi 28 février 2014 à 22:02
Lexpage : le how-to pour devenir un nerd
—
tuxfanch
Discussions
Lexpage v4 - Commentaires, remarques, bugs...
Cette discussion est en relation avec le billet suivant :
Est-ce qu'il y a quelques experts/habitués de Vagrant (et mieux : vagrant-lxe) ainsi que d'Ansible dans le coin ?
Avec les récents soucis du serveur, je me rends compte qu'il va m'être de plus en plus difficile de relancer le VPS s'il venait à lâcher, parce que tous les services tournent "à l'ancienne", et que le déploiement de ces services doit être fait un à un. Pour donner une idée, le VPS héberge pour l'instant :
- Un nginx qui sert de proxy web frontal;
- Une instance du Lexpage propulsée par Gunicorn;
- Une instance de pgsql nécessaire pour Lexpage;
- Une instance de redis nécessaire pour Lexpage;
- Une instance de Piwik (je ne me souviens jamais du nouveau nom de ce truc) en PHP;
- Une instance de mysql pour Piwik;
- Quelques sites web statiques (directement servis par nginx);
- Un "antispam" basique (mais où on retrouve mes credentials d'email en clair dans la config
)
- Tout ce qu'il faut pour Let's Encrypt au dessus de ça;
- Un logrotate périodique pour dumper la base de données du Lexpage;
- Une instance de Dropbox pour sync les backups
J'envisage de plus en plus de me faciliter la vie (et surtout le testing, parce que "cloner" cette configuration en local est une plaie) à base de conteneurs. Je n'aime pas Docker (oui, je sais....), donc Vagrant est une bonne alternative, surtout qu'y a un plugin pour des boxes en LXE (je peux pas partir sur une VM à cause des perfs du VPS). Des conteneurs, c'est bien, mais faut aussi provisionner ça, même si globalement, c'est juste quelques dizaines de lignes de commande à entrer et que Vagrant supporte ça "out of the box", mais peut-être que je peux m'en sortir facilement avec quelques playbooks Ansible "par défaut" (j'ai déjà utilisé Ansible, mais à chaque fois que je dois changer quelque chose, je passe autant de temps dans la documentation que si j'avais écrit le script moi-même
).
Avec les récents soucis du serveur, je me rends compte qu'il va m'être de plus en plus difficile de relancer le VPS s'il venait à lâcher, parce que tous les services tournent "à l'ancienne", et que le déploiement de ces services doit être fait un à un. Pour donner une idée, le VPS héberge pour l'instant :
- Un nginx qui sert de proxy web frontal;
- Une instance du Lexpage propulsée par Gunicorn;
- Une instance de pgsql nécessaire pour Lexpage;
- Une instance de redis nécessaire pour Lexpage;
- Une instance de Piwik (je ne me souviens jamais du nouveau nom de ce truc) en PHP;
- Une instance de mysql pour Piwik;
- Quelques sites web statiques (directement servis par nginx);
- Un "antispam" basique (mais où on retrouve mes credentials d'email en clair dans la config
)- Tout ce qu'il faut pour Let's Encrypt au dessus de ça;
- Un logrotate périodique pour dumper la base de données du Lexpage;
- Une instance de Dropbox pour sync les backups
J'envisage de plus en plus de me faciliter la vie (et surtout le testing, parce que "cloner" cette configuration en local est une plaie) à base de conteneurs. Je n'aime pas Docker (oui, je sais....), donc Vagrant est une bonne alternative, surtout qu'y a un plugin pour des boxes en LXE (je peux pas partir sur une VM à cause des perfs du VPS). Des conteneurs, c'est bien, mais faut aussi provisionner ça, même si globalement, c'est juste quelques dizaines de lignes de commande à entrer et que Vagrant supporte ça "out of the box", mais peut-être que je peux m'en sortir facilement avec quelques playbooks Ansible "par défaut" (j'ai déjà utilisé Ansible, mais à chaque fois que je dois changer quelque chose, je passe autant de temps dans la documentation que si j'avais écrit le script moi-même
).
Il y a essentiellement deux raisons pour tester les conteneurs :
- Faciliter la réplication locale de l'environnement distant. Je suis sur une vieille CentOS 6 sur le VPS, et j'ai au moins 3 ou 4 versions de pgsql qui sont installées, avec des fichiers de configuration un peu partout pour "basculer" de l'un à l'autre, etc. et ça devient un peu chiant de se souvenir qu'est-ce qui est utile ou pas
Avec des conteneurs, j'ai essentiellement besoin de Vagrant, Ansible et le reste devrait être "pratiquement automatique" pour tester localement et avoir localement le même environnement que l'environnement de prod.
- La seconde, c'est de faciliter la mise à jour des composants individuels. Par exemple, je suis toujours coincé avec Python 3.4 sur le serveur, ce qui m'empêche de migrer vers une version plus récente de Django. Sachant que les versions plus récentes de Django nécessitent aussi une version plus récente de Postgresql, je suis un peu "coincé" pour l'instant, et j'ai vraiment la flemme d'essayer d'upgrader "manuellement" tout ça, sans savoir si ça va encore marcher sans que j'y perde la moitié de la journée.
Si je peux répliquer localement l'environnement, les tests sont plus simples à effectuer, et essentiellement, je dois juste re-créer l'image distante "clone" de l'image locale, et le tour est "joué" (je suis sûr que ça ne marchera pas aussi bien, mais bon).
Après, il y a aussi le coté "fun" et aussi l'aspect professionnel : je milite depuis longtemps pour que la recherche scientifique soit "réplicable" quand elle fait appel à du code. Actuellement, vu que 99% de mon code est en Python, je fournis juste de quoi répliquer l'environnement logiciel Python. Mais de plus en plus, j'ai besoin de "petites choses" en dehors de Python, et ça faciliterait les choses si je pouvais juste fournir un Vagrantfile pour recréer l'environnement de réplication de mes analyses (accessoirement, il devrait m'être possible de faire l'un ou l'autre papier afin de présenter un workflow "garantissant" la réplication des analyses) !
La solution à base d'Ansible uniquement est pas mal pour le déploiement (et je peux "cloner" ce déploiement localement dans un conteneur ou un VM au besoin), mais y a toujours un moment où sur le serveur, tu lances une commande et tu oublies de la rajouter dans le provisionning Un autre aspect intéressant des conteneurs ici est que je peux quasiment installer "tout" dans des conteneurs individuels, sans me soucier de la configuration ou de la sécurité (par ex, pas besoin de préciser un password pour pgsql si le conteneur n'est accessible que localement). Je me trompe peut-être, n'ayant pas beaucoup de connaissances dans ce domaine :)
Enfin, pour la question à proposer d'Amazon RDS ou du cloud en général, je préfère éviter "d'externaliser" des services (surtout quand on peut les héberger soi-même, c'est pas comme si Lexpage et le reste était gourmand en ressources). Ca me permet aussi de maintenir une certaine "veille technologique" que je n'aurai pas forcément si j'externalise les services (mais le coup des conteneurs me permettrait de facilement switcher d'un service interne à un externe, ou inversément, je pense ?).
- Faciliter la réplication locale de l'environnement distant. Je suis sur une vieille CentOS 6 sur le VPS, et j'ai au moins 3 ou 4 versions de pgsql qui sont installées, avec des fichiers de configuration un peu partout pour "basculer" de l'un à l'autre, etc. et ça devient un peu chiant de se souvenir qu'est-ce qui est utile ou pas
Avec des conteneurs, j'ai essentiellement besoin de Vagrant, Ansible et le reste devrait être "pratiquement automatique" pour tester localement et avoir localement le même environnement que l'environnement de prod. - La seconde, c'est de faciliter la mise à jour des composants individuels. Par exemple, je suis toujours coincé avec Python 3.4 sur le serveur, ce qui m'empêche de migrer vers une version plus récente de Django. Sachant que les versions plus récentes de Django nécessitent aussi une version plus récente de Postgresql, je suis un peu "coincé" pour l'instant, et j'ai vraiment la flemme d'essayer d'upgrader "manuellement" tout ça, sans savoir si ça va encore marcher sans que j'y perde la moitié de la journée.
Si je peux répliquer localement l'environnement, les tests sont plus simples à effectuer, et essentiellement, je dois juste re-créer l'image distante "clone" de l'image locale, et le tour est "joué" (je suis sûr que ça ne marchera pas aussi bien, mais bon
). Après, il y a aussi le coté "fun" et aussi l'aspect professionnel : je milite depuis longtemps pour que la recherche scientifique soit "réplicable" quand elle fait appel à du code. Actuellement, vu que 99% de mon code est en Python, je fournis juste de quoi répliquer l'environnement logiciel Python. Mais de plus en plus, j'ai besoin de "petites choses" en dehors de Python, et ça faciliterait les choses si je pouvais juste fournir un Vagrantfile pour recréer l'environnement de réplication de mes analyses (accessoirement, il devrait m'être possible de faire l'un ou l'autre papier afin de présenter un workflow "garantissant" la réplication des analyses) !
La solution à base d'Ansible uniquement est pas mal pour le déploiement (et je peux "cloner" ce déploiement localement dans un conteneur ou un VM au besoin), mais y a toujours un moment où sur le serveur, tu lances une commande et tu oublies de la rajouter dans le provisionning
Un autre aspect intéressant des conteneurs ici est que je peux quasiment installer "tout" dans des conteneurs individuels, sans me soucier de la configuration ou de la sécurité (par ex, pas besoin de préciser un password pour pgsql si le conteneur n'est accessible que localement). Je me trompe peut-être, n'ayant pas beaucoup de connaissances dans ce domaine :)Enfin, pour la question à proposer d'Amazon RDS ou du cloud en général, je préfère éviter "d'externaliser" des services (surtout quand on peut les héberger soi-même, c'est pas comme si Lexpage et le reste était gourmand en ressources). Ca me permet aussi de maintenir une certaine "veille technologique" que je n'aurai pas forcément si j'externalise les services (mais le coup des conteneurs me permettrait de facilement switcher d'un service interne à un externe, ou inversément, je pense ?).