Journal FsPages : un publicateur de pages statiques pour Gitlab

Posté par (page perso) . Licence CC by-sa
37
18
juin
2016

Bonjour 'Nal,

Github propose depuis un bout de temps les pages github : on pousse les fichiers kivonbien dans la branche kivabien, et un générateur de site statique crée des pages HTML qui sont publiées dans un sous-domaine de github.io.

On trouve de plus en plus de projets dont le site est hébergé par ce biais.

Gitlab, un projet libre qui propose une alternative à Github propose la même fonctionnalité, mais uniquement dans la version entreprise (pas dans la version libre donc).

Je travaille chez Framasoft, qui propose une instance de Gitlab librement utilisable, mais dans sa version communautaire (libre) : https://framagit.org

Nous ne pouvions donc proposer de pages. Trouvant cela fort dommage, j'ai codé (sur mon temps libre, pas en tant qu'employé de Framasoft, je le précise) FsPages, un système de publication automatique depuis un Gitlab.

J'avais d'abord intégré l'utilisation de générateurs de sites statiques (Pelican, Hugo, Lektor et Jekyll), mais j'ai laissé tombé devant la complexité de la sécurisation du processus (plugins, évolution des générateurs à surveiller, etc).

Basiquement, ça clone la branche fs-pages du dépôt, et ça en copie le contenu (ou juste un dossier) dans un dossier servi par Nginx. Simple et rapide, c'est Nginx qui se chargera de choisir le bon dossier quand on demandera https://user.example.org.

Et bien évidemment, c'est mis en place sur Framagit. Vous pouvez aller voir les instructions sur https://frama.io :-)

PS : FsPages est écrit en Perl. What else ? :P

Ce journal est sous licence CC-0.

  • # Perl

    Posté par . Évalué à 5.

    Salut !

    C'est super ! C'est très simple (de ce que j'ai rapidement vu sur le dépôt tu as un fichier de script pour pleins de fichiers/dossiers de packaging :) ).

    J'ai vu que tu utilise Mojolicius, au début je me suis dis que c'était dommage de faire ça juste pour exposer un webservice (j'aime beaucoup Dancer ^^). Puis j'ai vu que ça te permet aussi d'utiliser le plugin "minion" (que je ne connaissais pas). Je ne sais pas si c'est possible, mais ce serait pas mal de faire de la suppression des duplicats dans cette file (mais si vous n'avez pas de problème de charge tant mieux :) ).

    Bref super ! Merci beaucoup :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Perl

      Posté par (page perso) . Évalué à 2.

      Mojolicious vs Dancer : mon choix est vite fait. Ça fait 5 ans que je fais du Mojolicious, au début pour le taf, et puis pour le taf et le plaisir, maintenant surtout pour le plaisir. Donc entre un truc que je maîtrise plutôt pas mal, et un autre truc… :P

      Pour le duplicat, je ne sais pas si Minion permet de gérer ça, mais effectivement, ça serait intéressant.

      Bref super ! Merci beaucoup :)

      <3

      It's a fez. I wear a fez now. Fezes are cool !

  • # Génial. Pub ?

    Posté par . Évalué à 3.

    C'est vraiment génial, je l'ai vu ce matin depuis le fil de discussion de gitlab, c'est une belle avancée, bravo !

    Juste avant toi quelqu'un a montré sa solution, gitla-ce-pages: https://github.com/YuMS/gitlab-ce-pages Tu avais déjà commencé FSPages avant de voir celle-là ou tu ne voulais pas l'utiliser pour d'autres raisons ?

    Et vas-tu faire un peu plus de pub, par exemple sur reddit ?

    • [^] # Re: Génial. Pub ?

      Posté par (page perso) . Évalué à 6.

      Oui, j'avais vu d'autres projets du genre, mais disons que déployer du docker (que j'abhorre, car on est à la merci de ceux qui ont créé le container[1]) ou déployer un truc dont le code tient en une petite page que je peux modifier à loisir… je choisis la deuxième solution :-)

      Pour la pub sur Reddit… Je ne suis pas sur Reddit mais pourquoi pas :-)

      [1] je ne parle pas que de code malveillant, mais aussi de failles de sécu non patchées et de fichier de configuration moisis. Genre un container PHP-FPM avec seulement 5 threads de php5-fpm. Bah des fois, ça tient pas la charge, et comme tu connais pas la conf par défaut du container, tu te demandes où est le goulot d'étranglement. True story : ça nous est arrivé sur Framadrive.

      It's a fez. I wear a fez now. Fezes are cool !

  • # Question sur la génération de sites statiques

    Posté par (page perso) . Évalué à 3.

    J'avais d'abord intégré l'utilisation de générateurs de sites statiques (Pelican, Hugo, Lektor et Jekyll), mais j'ai laissé tombé devant la complexité de la sécurisation du processus (plugins, évolution des générateurs à surveiller, etc).

    Si je comprends bien, FsPages se contente de publier verbatim le contenu d'une branche sans phases de traitement comme ferait github pages ?

    D'ailleurs en parlant de Github pages, ceux-ci utilisent Jekyll et sont donc confrontés à la complexité de sécurisation dont tu parles. Sais-tu comment ils font ? (ils mettent plus de monde sur le projet, utilisent des machines virtuelles séparées pour chaque génération etc.)

    • [^] # Re: Question sur la génération de sites statiques

      Posté par . Évalué à 4.

      Si je comprends bien, FsPages se contente de publier verbatim le contenu d'une branche sans phases de traitement comme ferait github pages ?

      Précisément, le hook est appelé à chaque commit et fait un clone du projet en question dans un dossier servi par le serveur web.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Question sur la génération de sites statiques

        Posté par (page perso) . Évalué à 3.

        Précisément, le hook est appelé à chaque commit et fait un clone du projet en question dans un dossier servi par le serveur web.

        Pour être précis, fait un clone et copie le contenu du clone, ou juste d'un dossier du clone dans un dossier servi par le serveur web.

        D'ailleurs en parlant de Github pages, ceux-ci utilisent Jekyll et sont donc confrontés à la complexité de sécurisation dont tu parles. Sais-tu comment ils font ? (ils mettent plus de monde sur le projet, utilisent des machines virtuelles séparées pour chaque génération etc.)

        Ah bah c'est sûr qu'ils ont plus de gens sur le projet que moi et mes quelques soirées passées dessus :-) Et nul doute qu'ils ont un truc comme Gitlab qui exécute une VM/container docker pour générer le site statique.

        It's a fez. I wear a fez now. Fezes are cool !

  • # générateur de page

    Posté par . Évalué à 2.

    J'avais d'abord intégré l'utilisation de générateurs de sites statiques (Pelican, Hugo, Lektor et Jekyll), mais j'ai laissé tombé devant la complexité de la sécurisation du processus (plugins, évolution des générateurs à surveiller, etc).

    Je veux bien que cela ne soit pas simple mais je pense pourtant que c'est un incontournable.

    Peut être se limiter à un générateur, sans modules…

    • [^] # Re: générateur de page

      Posté par (page perso) . Évalué à 3.

      Je veux bien que cela ne soit pas simple mais je pense pourtant que c'est un incontournable.

      Je considère que je m'adresse à un public de développeurs. Donc ils sont capables d'installer un générateur comme des grands.

      De plus, utilisant un générateur, j'aime bien tester le rendu de ce que j'écris, donc j'ai un générateur sur mon ordi. Et en ne publiant que le rendu terminé, je suis assuré que ce qui sera publié aura la même tronche que ce que j'ai vu moi (on sait jamais, des fois que je n'ai pas le même n° de version par exemple).

      Peut être se limiter à un générateur, sans modules…

      Encore faut-il en trouver un sans module, vérifier à chaque version qu'il n'ait pas inclut un système de modules, qu'il n'y ait vraiment aucun risque (la config Pelican est un script python par exemple : ça c'est une potentielle faille de sécu qui n'a rien à voir avec les modules).

      Bref, je ne mettrais pas de génération du côté du serveur, mais comme c'est libre, y a qu'à forker :-)

      It's a fez. I wear a fez now. Fezes are cool !

      • [^] # Re: générateur de page

        Posté par . Évalué à 2.

        Si il faut mettre en place un générateur soi même ; et donc avoir un serveur qui tourne, autant trouver un hébergement web avec un domaine en propre et faire un push ftp.

        • [^] # Re: générateur de page

          Posté par . Évalué à 3.

          et donc avoir un serveur qui tourne,

          Pourquoi faire ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: générateur de page

            Posté par (page perso) . Évalué à 2.

            Tout à fait : je bidouille avec Hugo qui a un mode serveur pour les tests, mais qui n'est pas là pour servir en production. J'imagine que les autre générateurs ont aussi une fonctionnalité équivalente.

            It's a fez. I wear a fez now. Fezes are cool !

          • [^] # Re: générateur de page

            Posté par . Évalué à 1. Dernière modification le 22/06/16 à 00:11.

            Tu pousses du contenu à mettre en page sur le git.
            Il faut bien qu'un générateur de site tourne quelque part.
            Puis qu'il ne tourne pas sur framagit, il faut qu'il tourne ailleurs.
            Donc un serveur quelque part : un VM, une lambda fonction AWS, un bout de truc avec un CPU quoi.

            • [^] # Re: générateur de page

              Posté par . Évalué à 4.

              Ton ordinateur de bureau ? C'est à ça que ça sert les générateurs statistiques à la base, tu fais tout en local et le serveur fait le strict minimum. Oui on peut déployer des archi compliquées pour faire en sorte que ce boulot soit fait par un serveur mais ça n'est pas l'idée de base.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: générateur de page

                Posté par . Évalué à 4.

                architecture compliquée

                Si, comme tu le mentionne, ça s'installe sur un pc de bureau, ça doit pas être si compliqué que ça…

                Je vois deux problèmes de ne pas avoir le générateur sur la plateforme.

                D'abord, le générateur doit être installé sur toutes les machines qui peuvent créer du contenu. Sur un pc de développeur, pas trop de problème, il saura le faire. ça devient un peu plus difficile pour qqun qui ne ferai que de la rédaction de contenu ; et c'est impossible sur une tablette par exemple.

                En admettant que la cible ne soient que les développeurs, reste un souci. Le repository git va contenir des fichiers générés alors que son rôle est de contenir des sources. C'est un peu comme si on y stockait les .o ou les .class.

                Si la plateforme ne peut pas fournir le générateur, elle devrait simplement proposer un ftp. Les fichiers générés sur la machine du développeur seraient uploadé sur le FTP plutôt que pushées dans un git.

                • [^] # Re: générateur de page

                  Posté par . Évalué à 4.

                  1. C'est pour ça que ces logiciels sont conçu : ne rien faire côté serveur. Certains font à peut près tout en js après si tu veux ne pousser que les sources
                  2. C'est une forge logiciel donc oui ça s'adresse aux développeurs
                  3. Pourquoi ajouter un protocole alors que tu en as déjà un qui fait très bien le boulot et qui t'apporte en plus le versionnement et la possibilité de gestion concurrente (fork/merge)

                  Oui c'est mieux de n'avoir que les sources dans le DCVS, mais là l'auteur t'explique qu'il n'a pas trouvé de moyens à sa mesure pour le faire de manière sécurisée. Soit tu proposes quelque chose, soit tu fais la moulinette toi en posant un hook sur les commits de ton dépôt (et le code du journal est un bon début pour le faire)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: générateur de page

                    Posté par . Évalué à 2.

                    Le journal commence comme ça:

                    Github propose depuis un bout de temps les pages github

                    Si le but, tout à fait louable, est d'attirer les gens vers Framagit, il est préférable de proposer des fonctionnalités au moins au même niveau.

                    Soit tu proposes quelque chose

                    Je propose aux développeurs, de prendre un hébergement web et un nom de domaine et d'uploader en FTP le résultat de la génération de page dessus. Quitte à faire le travail de génération, autant avoir son domaine.

                    Je propose à l'auteur d'envisager de mettre à disposition au moins un générateur. Ils sont tous plus ou moins équivalents en terme de fonctionnalités et de fonctionnement (markdown + front matter + templating). Hugo est un binaire statiquement compilé. L'exécuté dans un container devrait protéger la plateforme.

                    • [^] # Re: générateur de page

                      Posté par (page perso) . Évalué à 3.

                      Si le but, tout à fait louable, est d'attirer les gens vers Framagit, il est préférable de proposer des fonctionnalités au moins au même niveau.

                      Ne vaut-il pas mieux une fonctionnalité un peu différente que rien du tout ?

                      Je propose aux développeurs, de prendre un hébergement web et un nom de domaine et d'uploader en FTP le résultat de la génération de page dessus. Quitte à faire le travail de génération, autant avoir son domaine.

                      Et il faudrait qu'ils payent. Mine de rien, y a plein de gens qui n'ont pas envie de payer pour mettre une petite page statique en ligne.

                      Je propose à l'auteur d'envisager de mettre à disposition au moins un générateur. Ils sont tous plus ou moins équivalents en terme de fonctionnalités et de fonctionnement (markdown + front matter + templating). Hugo est un binaire statiquement compilé. L'exécuté dans un container devrait protéger la plateforme.

                      Tu peux toujours proposer, c'est non. J'ai pas envie de me plonger dans la gestion d'un container, mon truc fonctionne, y a (a priori, je ne suis pas infaillible) pas de risques, j'ai plein d'autres choses à faire. J'ai déjà expliqué pourquoi je ne le ferais pas.

                      Propose une merge request, je l'examinerai. Mais en attendant, les yakafokon, ça me fatigue.

                      It's a fez. I wear a fez now. Fezes are cool !

                      • [^] # Re: générateur de page

                        Posté par . Évalué à 3.

                        Mais en attendant, les yakafokon, ça me fatigue.

                        Bon bah j'arrête de te prendre la tête alors.
                        Je ferai à ma sauce et les autres aussi.
                        Si ce que tu as mis en place satisfait des utilisateurs, c'est l'essentiel.

                  • [^] # Re: générateur de page

                    Posté par (page perso) . Évalué à 3.

                    Pourquoi ajouter un protocole alors que tu en as déjà un qui fait très bien le boulot et qui t'apporte en plus le versionnement et la possibilité de gestion concurrente (fork/merge)

                    Et accessoirement, il faudrait trouver un moyen de lier l'authentification du FTP aux comptes gitlab… Bon courage, moi je ne touche pas à ça.

                    It's a fez. I wear a fez now. Fezes are cool !

  • # attention détournement !

    Posté par . Évalué à 2.

    Salut framasky !

    Je profite de cette annonce concernant framagit pour t'amener à jeter un coup d'œil sur cette entrée du forum et plus particulièrement mon dernier commentaire concernant une fonctionnalité potentielle pour framagit.

    Pourrais tu m'y donner ton avis sur l'éventuelle faisabilité de cette fonctionnalité au sein de framagit ?

    merci

    • [^] # Re: attention détournement !

      Posté par (page perso) . Évalué à 3.

      Tu peux mirrorer ton framagit vers github de façon automatique (https://contact.framasoft.org/foire-aux-questions/#git_mirroring_github). Et du coup tu ferais :

      1. fork du dépôt sur github
      2. import sur gitlab
      3. mise en place du mirroring
      4. résolution, commit, push sur gitlab
      5. tu ouvres une PR sur github

      S'il y a désynchronisation upstream/gitlab, tu ajoutes le dépôt upstream comme nouveau remote sur ton dépôt local et tu fais un git pull --rebase upstream et tu pushes sur gitlab avant d'ouvrir la PR sur Github.

      Je ne vois vraiment que ça comme solution… et c'est comme ça que je fais.

      It's a fez. I wear a fez now. Fezes are cool !

  • # FsPages et restriction d'accès

    Posté par . Évalué à 0.

    Bonjour,

    Est-il possible de restreindre l'accès aux pages publiées, par exemple pour des pages en phase de test ?

    Merci pour tout le travail !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.