Journal Docker vs Podman sur fedora 32 et headless CMS

Posté par  . Licence CC By‑SA.
41
17
oct.
2020

Sommaire

Salut Narjoul,

La mode headless CMS

Aujourd'hui je vais te parler d'headless CMS.

Alors si tu ne suis pas la mode, headless CMS, qu'est-ce que ça veut dire ?

J'imagine que tu connais les CMS "standards" (comme wordpress par exemple), l'idée (à la hache) c'est :
- tu mets tes données dans une base de données (que tu peux éditer avec ton-wordpress.fr/admin)
- wordpress te présente une url (ton-wordress.fr/nouveau-post-lâche-ton-com) avec ton contenu mise en forme par un système de template

Avec un headless CMS (à la hache aussi) :
- tu mets tes données dans une base de données, que tu édites avec un outil dédié
- l'outil dédié met à disposition une API (REST ou graphql)
- Un autre outil consomme cette API pour produire un site statique
- Le site statique est reconstruit à la demande, ou souvent sur modification de la base de données à travers un mécanisme de "webhook" (en fait juste une requête POST)

Bref, ça permet d'avoir des sites publics "rapides" :
- composés que de fichiers statiques, déjà produits
- mais surtout, sans backend, donc répartissable sur un CDN

Les outils

Maintenant que tu es complètement subjugué par le concept et surtout que tu veux être à la mode, il est temps de regarder quelques outils disponibles libres et auto-hébergeables (sélection incomplète - lâche ton com si tu en aimes un autre) :
- directus. Codé en php. Fournit une API REST et une API graphql (rajouté après coup).
- Strapi. Codé en javascript. Fournit du REST et du graphql. Par une équipe française (si j'ai bien compris).
- Hasura. Codé en Haskell. Fournit du graphql au dessus d'une base PostgreSQL.

Et là, imagine que tu veux les lancer, les tester. Pas de problèmes ! Tout ce petit monde te propose un docker-compose.yaml que tu vas pouvoir utiliser pour lancer des containers avec docker.

Donc tu installes docker sur fedora (la dernière release - tu es à la mode, je te le rappelle), tu le lances et … Error response from daemon: cgroups: cgroup mountpoint does not exist.

Bon d'accord, fedora 32 utilise cgroup v2 et docker n'est compatible qu'avec cgroup v1.

Podman

Après avoir maudit la mode et la nouveauté. (C'était mieux avant…), tu découvres que tu peux utiliser podman.

C'est presqu'un remplaçant pour docker, tu peux alias docker=podman.

Ça vient avec quelques trucs qui sont de bonnes idées (= je trouve que ce sont de bonnes idées) :
- Pas de démons (genre dockerd)
- Tu peux lancer des containers sans être root (ton admin système va être content)
- Il existe un concept de "pod". Un pod, c'est (à la hache) un groupe de containers qui partage des namespaces. En pratique, si un container écoute sur un port, dans le même pod, ce port est directement accessible sur localhost:port par un autre container.

Un exemple

Il existe un projet podman-compose qui permet de réutiliser des docker-compose.yaml.

Mais toi, tu es un vrai. Tu veux le faire à la main pour impressionner (et aussi parce que sinon, le journal est fini).

On va prendre Hasura comme exemple. Il y a un docker-compose.yaml ici.

Quand tu l'auras lu à haute voix pour amuser tes compagnons de télétravail (ton chat !), tu sauras qu'il y a 2 containers. Un pour PostgreSQL et un pour hasura.

Alors créons un pod pour hasura :

podman pod create -p 8080:8080 --name hasura

La seule astuce, c'est de mapper à l'avance les ports que tu veux voir si l'hôte. Ici on veut le port 8080 (servi par hasura lui-même pour l'admin et l'api).

Un container pour PostgreSQL :

podman run -d --restart=always \
    --pod hasura \
    -e POSTGRES_PASSWORD="password" \
    -v ./data/:/var/lib/postgresql/data:z \
    --name hasura-db \
    postgres

Remarques en vrac :
- le container est dans le pod précédemment créé.
- Il y a un montage de volume entre ./data sur l'hôte et /var/lib/postgresql/data dans le container (c'est là où PostgreSQL stocke ses données). Il y a un ":z" parce que c'est comme ça. (Une sombre histoire de SELinux et de volumes que tu pourrais avoir envie d'utiliser - en RW - depuis l'hôte, le container et un autre container).
- Tu peux être fier de ton imagination pour le password de la BD.
- Le postgres, c'est juste le nom de l'image docker.

Et un container pour hasura :

podman run -d --restart=always \
    --pod hasura \
    -e HASURA_GRAPHQL_DATABASE_URL="postgres://postgres:password@127.0.0.1:5432/postgres" \
    -e HASURA_GRAPHQL_ENABLE_CONSOLE="true" \
    -e HASURA_GRAPHQL_DEV_MODE="true" \
    -e HASURA_GRAPHQL_ENABLED_LOG_TYPES="startup, http-log, webhook-log, websocket-log, query-log" \
    --name hasura-app \
    hasura/graphql-engine:v1.3.2

Et quelques remarques en vrac :
- le container est dans le pod précédemment créé.
- Ce qui permet de se connecter au container PostgreSQL à travers 127.0.0.1:5432. Sans que le port 5432 ne soit accessible depuis ton hôte.

Et maintenant, tu peux :

podman pod start hasura

ou même :

podman pod stop hasura

Et ça démarre/arrête automatiquement ce pod/groupe de containers. Et tout ça, sans être root.

Conclusion

Tu as appris :

  • Que la mode, ça a des fois du bon. Sinon on ferait des CMS over corba.
  • Que docker, c'est pas à la mode.
  • Que podman, c'est à la mode et que ça a quelques avantages par rapport à docker.
  • Qu'un site statique, sans backend, c'est tellement plus rapide, que tu peux en profiter pour mettre plein de JS dedans, pour que finalement, il soit plus lent.
  • Que c'était difficile de faire une conclusion à ce journal qui se disperse (un peu).
  • # pod

    Posté par  . Évalué à 4 (+2/-0).

    Les pods ne sont pas fait pour faire ce genre de groupement. Là tu ne peux pas avoir une base de données qui tourne sans ton service et tu ne peux pas partager ta base de données entre plusieurs instances de ton service…

    Sans que le port 5432 ne soit accessible depuis ton hôte.

    Ce n'est pas nécessaire d'être dans un même pod pour ça. Il y a plusieurs manière de le faire, mais docker (au sens runc et la stack qui va avec) permet d'avoir des réseaux virtuels distinct de l'hôte.


    Par contre j'ai pas bien compris l'intérêt des CMS headless par rapport aux sites statiques.

    • [^] # Re: pod

      Posté par  . Évalué à 5 (+6/-2).

      Par contre j'ai pas bien compris l'intérêt des CMS headless par rapport aux sites statiques.

      Si j'ai bien compris, c'est pareil sauf que tes données sont stockées dans une db au lieu de fichier markdown… Ça permet de faire une API et c'est à la mode les API.

      • [^] # Re: pod

        Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

        J'ai fait 10 ans de CMS, alors je peux me tromper, mais je pense que ta réponse est complètement fausse.

        L'idée d'avoir un CMS, c'est de fournir une joli ninterface de gestion qui modifie ton site en temps réel pour des gens qui ne savent pas parler la ligne de commande ou le markdown. Qu'il soit headless ou non ça sera toujours ça la différence avec un site statique qui comme son nom l'indique, ne se modifie pas en temps réel.

        Après, headless, ça veut juste dire que tu sépare le logiciel de gestion (celui qui remplit la base) du logiciel de présentation (celui qui affiche le contenu de la base). Peu importe après comment ça se passe, dans la mode d'aujourd'hui, on utilise du REST, et un logiciel de présentation en JavaScript, mais dans l'absolu on pourrait imaginer un CMS headless, à qui on parle avec du Corba, et dont le logiciel de présentation est un générateur de site statique !

        • [^] # Re: pod

          Posté par  . Évalué à 1 (+0/-0).

          En fait, j'ai essayé de faire une réponse courte en restant dans le ton du journal. Mais je peux détailler.

          En fait, de ce que j'en ai compris, le principe c'est de faire une génération statique d'un site, sauf qu'au lieu des pages définies par un tas de fichiers .md, ton générateur consomme une API ; au lieu des hooks de git, tu utilise un hook HTTP. Ça permet de décorréler le système de stockage de la génération, que ce soit un tas de fichiers yml, une DB relationnelle ou une instance elastic search, peu importe tant qu'il offre la bonne API. Ça ouvre sans la porte à pas mal de choses : des pages générées automatiquents, des interfaces de productions de contenue qui peuplent directement la DB, par une API, ou des commits gits, une jolie interface pour le producteur de contenu préssé, etc.

          • [^] # Re: pod

            Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

            En fait, de ce que j'en ai compris, le principe c'est de faire une génération statique d'un site.

            C'est exactement là que tu as faux. Headless ça veut juste dire que la partie présentation n'est pas intriquée avec le backend, c'est tout. Si tu te sers d'une API pour lire les données à la demande, ce n'est pas statique, mais pourtant ça reste headless.

            • [^] # Re: pod

              Posté par  . Évalué à 4 (+3/-0).

              Ah, d'accord. Effectivement, j'avais mal interprété. Merci.

              • [^] # Re: pod

                Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

                Oh et je suis désolé je me suis rendu compte que mon ton était un peu hautain, c'était pas le but ! Bien entendu c'était cordial et amical, même si ça ne transparaît pas à l'écrit.

                • [^] # Re: pod

                  Posté par  . Évalué à 1 (+0/-0).

                  T'inquiètes, je ne l'avais pas mal pris du tout, je n'ai pas considéré tes messages comme hautain ou quoi que ce soit.

    • [^] # Re: pod

      Posté par  . Évalué à 4 (+4/-0).

      Les pods ne sont pas fait pour faire ce genre de groupement.

      Voudrais-tu clarifier/sourcer ton affirmation ?

      Je lis ça dans la doc (un post de blog) :

      The Pod concept was introduced by Kubernetes. Podman pods are similar to the Kubernetes definition.

      Et en suivant le lien de la doc de kubernetes :

      A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage/network resources, and a specification for how to run the containers. […] Pods that run multiple containers that need to work together.

      Et il me semble que c'est compatible avec le cas qui m'intéresse :
      - ne pas rendre PostgreSQL accessible sur mon hôte
      - Tester/Développer avec (directus|strapi|hasura), donc lancer un couple PostgreSQL/Appli

      Est-ce que tu peux me faire voir la lumière ?

      Par contre j'ai pas bien compris l'intérêt des CMS headless par rapport aux sites statiques.

      Le plus grand intérêt, c'est que c'est la mode !

      Non mais sérieusement, il y aussi des cas où un fichier markdown avec un front-matter fait très bien le job.

      Et des fois où c'est bien plus confortable d'avoir un modèle de données un peu plus défini/strict (genre des tables dans du PostgreSQL).

      • [^] # Re: pod

        Posté par  (site Web personnel) . Évalué à 8 (+6/-0). Dernière modification le 18/10/20 à 03:07.

        Dans Kubernetes, la règle c’est un pod = un container.

        Quand il y a plusieurs containers, les containers « secondaires » sont d’ailleurs appelés des « sidecars » et leur rôle est plutôt d’accompagner le container principal.

        Par exemple, dans un pod tu pourrais avoir ton application et un exporter Prometheus.

        Autre exemple, dans mes pods prometheus et alertmanager, j’ai un sidecar « reloader » qui surveille les changement sur certains fichiers et fait l’équivalent d’un kill -HUP sur Prometheus ou Alertmanager.

        L’exemple le plus courant (mais plus compliqué à expliquer), c’est les « service mesh » et notamment istio, qui crées des sidecar automatiquement pour leurs propres besoins.

        Par contre, une application et sa base de données, c’est deux pods différents. Ça te permet de leur donner des droits différents, de limiter les ressources (CPU, RAM) différemment, d’avoir de l’autoscale sur le frontend, etc.

      • [^] # Re: pod

        Posté par  . Évalué à 7 (+5/-0).

        • ne pas rendre PostgreSQL accessible sur mon hôte
        • Tester/Développer avec (directus|strapi|hasura), donc lancer un couple PostgreSQL/Appli

        Est-ce que tu peux me faire voir la lumière ?

        Le premier point est le comportement par défaut. Tu as eu besoin de déclarer un mapping pour avoir accès au port de ton service.

        Tu gagne en souplesse à avoir toujours des pods séparés. On utilise plusieurs containers dans le même pod quand :

        • les interactions sont très fines (par exemple un containers écrit un fichier, un lit ce fichier sans passer par nfs et consort)
        • tu veux du 1:1 comme les sidecars, un sidecar n'a de sens que lorsqu'il est avec son container principal donc on garantit qu'il vit avec ce dernier

        Tout fusionner va t'empêcher de :

        • relancer le service sans toucher à la base de données
        • avoir plusieurs services pour la même base de données
        • faire de la haute disponibilité (je pense qu'il est assez joueur de faire tourner 2 instances pg sur le même dossier, donc tu es obligé d'arrêter ton pod avant de lancer le suivant)
        • de séparer ton application et ta base de données sur 2 machines séparée pour avoir des machines taillées différemment
        • tes containers partagent beaucoup de choses Yo quelqu'un arrive à faire exécuter quelque chose par le service il a accès à pas mal de choses

        Tu n'en a pas forcément besoin et tu fais bien ce que tu entend. Chacun son contexte et son besoin. C'est juste pour te montrer les implications. Je trouve au contraire très agréable cette façon de lancer tout en une seule commande. Pour une utilisation sur bureau c'est pratique.

        Note je connais kubernetes et je n'ai jamais utilisé podman, mais comme ils indiquent kubernetes comme référence pour leur pod, je présume que ça fonctionne de la même façon

        • [^] # Re: pod

          Posté par  . Évalué à 4 (+4/-0).

          J'en conclus qu'en production, ce n'est pas du tout une méthode adaptée.
          Tes arguments font sens. Merci !

    • [^] # Re: pod

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 18/10/20 à 02:39.

      Par contre j'ai pas bien compris l'intérêt des CMS headless par rapport aux sites statiques.

      En gros, si j’ai bien compris, c’est statique côté client, mais dynamique côté éditeur (et à chaque changement ça met à jour ton site statique).

    • [^] # Re: pod

      Posté par  . Évalué à 4 (+2/-0).

      Par contre j'ai pas bien compris l'intérêt des CMS headless par rapport aux sites statiques.

      Pour moi la différence, c'est qu'un générateur de site statique ne s'occupe pas de la partie "authoring" ("création de contenus" ?) et gestion de droits. Seulement de la partie publication.

      Pour un CMS, tu peux imaginer avoir une application web pour l'édition de contenu wysiwyg au dessus d'un git[lab] qui fera la gestion de droits et le stockage de contenu. À chaque commit, le contenu est transformé et poussé sur un CDN.

      Tu trouves le plus littérature chez jamstack.org et leurs sponsors comme Netlify.

  • # CMS headless et baseless ?

    Posté par  (site Web personnel) . Évalué à 4 (+2/-1).

    Pourquoi il faut une base pour stocker le contenu?

    Pourquoi pas un gestionnaire de version et un outil d'intégration / déploiement continue?

    Incubez l'excellence sur https://linuxfr.org/board/

  • # plugins de génération de sites statiques + sécurité

    Posté par  . Évalué à 1 (+2/-1).

    Hello,
    il existe des plugins de génération de sites statiques pour Wordpress (simplystatic par exemple). Ça fait en gros la même chose, mais en gardant l'écosystème qu'on a déjà. J'imagine que c'est dispo aussi pour les autres CMS courants.

    Outre l'énorme gain en performance, un autre intérêt majeur est que l'on s’affranchit des trous de sécurité des CMS et de PHP.

    • [^] # Re: plugins de génération de sites statiques + sécurité

      Posté par  . Évalué à 4 (+2/-0).

      Et on perd une pars des fonctionnalités, non ? Les commentaires par exemple

      • [^] # Re: plugins de génération de sites statiques + sécurité

        Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

        Pour ça tu as des options comme Disqus (ou les équivalents libres).

      • [^] # Re: plugins de génération de sites statiques + sécurité

        Posté par  . Évalué à 1 (+1/-0).

        Oui, complètement, et on perd aussi le moteur de recherche[1]. Ceci dit il existe énormément de sites vitrines faits avec des CMS, qui gagneraient à être exportés en statique, car bien souvent non maintenus une fois mis en ligne.


        [1] et c'est parfaitement possible de faire un moteur de recherche simple côté client avec Javascript et des mots clés dans les balises HTML.

        • [^] # Re: plugins de génération de sites statiques + sécurité

          Posté par  . Évalué à 2 (+1/-1).

          [1] et c'est parfaitement possible de faire un moteur de recherche simple côté client avec Javascript et des mots clés dans les balises HTML.

          Ça dépend. Si tu veux intégrer les commentaires, si ton index n'est pas trop gros, si tu ne cherche pas à prendre en compte la popularité des pages,…

          Tu perd aussi la gestion des droits utilisateurs (si tu gère des visibilité différentes), les configurations utilisateurs (un flux rss spécifique par exemple).

          • [^] # Re: plugins de génération de sites statiques + sécurité

            Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

            les configurations utilisateurs (un flux rss spécifique par exemple).

            Tu entends quoi par là ? Perso, chaque page « index » de mon site a un flux RSS pour les pages qu’elle contient (la liste des articles, la liste des tags, la liste des articles pour un tag donné, etc.).

            Pour les commentaires, en cherchant vite fait, j’ai l’impression que Disqus n’expose pas de flux RSS, mais je ne vois pas ce qui empêcherait de le développer dans une alternative libre (je sais pas si ça n’existe pas déjà).

            Ça dépend. Si tu veux intégrer les commentaires, si ton index n'est pas trop gros, si tu ne cherche pas à prendre en compte la popularité des pages,…

            Tu juges les sites statiques sur des critères biaisés là. Dans plein de cas (celui de mon site perso par exemple), j’ai pas envie d’avoir de commentaires, j’ai pas besoin de moteur de recherche, j’ai pas besoin de gestions d’accès 1.

            Je veux juste pouvoir écrire en Markdown ou en ReStructured Text dans mon éditeur préféré et publié en copiant des fichiers au bons endroits et je ne veux pas m’inquiéter d’éventuelles failles de sécurités parce que j’expose du PHP.


            1. D’ailleurs, je vois pas ce qui empercherait de gérer des accès via un mécanisme externe (Authentification basique, auth_request, oauth2-proxy, etc.) 

            • [^] # Re: plugins de génération de sites statiques + sécurité

              Posté par  . Évalué à 2 (+1/-1).

              Tu entends quoi par là ? Perso, chaque page « index » de mon site a un flux RSS pour les pages qu’elle contient (la liste des articles, la liste des tags, la liste des articles pour un tag donné, etc.).

              Si un utilisateurs veut un flux avec les articles ayant les tags "linux" et "debian" par exemple.

              Tu juges les sites statiques sur des critères biaisés là. Dans plein de cas (celui de mon site perso par exemple), j’ai pas envie d’avoir de commentaires, j’ai pas besoin de moteur de recherche, j’ai pas besoin de gestions d’accès.

              Où vois-tu un jugement ? J'utilise des sites statiques, je trouve ça très bien. J'ai un super opinel, dire qu'il n'est pas fait pour couper le roti. Ça n'est pas en faire un jugement.

              D’ailleurs, je vois pas ce qui empercherait de gérer des accès via un mécanisme externe (Authentification basique, auth_request, oauth2-proxy, etc.)

              Si tu déploie : un gestionnaire de commentaire, un serveur d'authentatication,… Il y a un moment où ça ne s'appelle plus vraiment un site statique, c'est juste que tu sert la partie statique par ton reverse proxy. C'est une logique qui s'applique aussi avec les CDN. Et ce n'est pas un mal ou critique. Globalement servir des fichiers statiques c'est une bonne idée donc certains passent du dynamique et tentent de maximiser progressivement leur part de données statiques et d'autres commencent en statique et ajoutent du dynamique progressivement.

  • # Container et tout et tout

    Posté par  . Évalué à 4 (+3/-0).

    Merci pour ce journal certes un peu vrac mais j'ai appris quelques trucs avec podman notamment.
    J'ai vraiment encore du mal à piger la logique des containers, surtout que je suis quasi obligé d'utiliser podman, étant sous Fedora (je ne juge pas, car j'ai compris ses qualités).
    Malgré la prétendue compatibilité entre podman et Docker, il ne suffit pas d'un "dnf install podman-compose" et des alias pour que tout marche du premier coup.

    • [^] # Re: Container et tout et tout

      Posté par  . Évalué à 3 (+1/-0).

      du mal à piger la logique des containers

      Le sujet est vaste. Qu'est ce qui passe pas ? l'intérêt que ça apporte ? les principes sous-jacents dans Linux ? la mise en œuvre par docker/podman ?

      • [^] # Re: Container et tout et tout

        Posté par  . Évalué à 1 (+0/-0). Dernière modification le 21/10/20 à 07:04.

        En fait je ne sais pas trop, c'est un tout. Gérer les images/containers, les ports de connexion etc. J'ai un peu peur du fouillis, notamment en cas de problème, retrouver qui est quoi dans le bazar…

        • [^] # Re: Container et tout et tout

          Posté par  (site Web personnel) . Évalué à 3 (+2/-1).

          Ce n'est pas plus different d'avant où tu dois aussi gérer tes applications, ton firewall, etc.

          C'est aussi pour cela que de nos jours, containers ou pas, on faire de l'infrastructure as code, comme avec Ansible par exemple.
          Tu écris comment doit être ton système à la fin, tu applique et c'est fait. Et en cas de besoin ou de nouvelles machines, tu deploy ton playbook ailleurs et ça marche.

        • [^] # Re: Container et tout et tout

          Posté par  . Évalué à 3 (+1/-0).

          C'est plus du ressenti alors.

          Moi je ressens exactement l'inverse avec les containers. J'aime savoir qu'un service c'est juste une image + un fichier de déploiement. Que j'ai la même chose qui tourne sur mon pc de dev et mon serveur de prod. Que je pourrais déménager un serice sans laisser de bazar sur mon serveur.

          Mais c'est vrai qu'il faut passer dans le mindset qu'un container ça se debug/répare pas, ça se détruit et remplace. Donc il faut être à l'aise avec la boucle dev/build/deploy/test.

          Ceci dit que celui qui n'a jamais fait un "docker exec bash" en prod jette la première pierre. Mais pour des services très simples, j'essaye de ne pas avoir de shell dans le container.

    • [^] # Re: Container et tout et tout

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      Les containers, c'est comme les jails sous BSD.

      L'idée est d'avoir un système stable ou en read-only et de déployer des boites avec l'app dedans.

      Cela permet de mettre à jour les apps sans casser le système, de rollback les apps sans casser le système, d'avoir plusieurs versions qui tournent, etc.

  • # Gné?

    Posté par  . Évalué à -5 (+0/-5).

    Rien compris.

    Bise, Martine

Envoyer un commentaire

Suivre le flux des commentaires

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