Suport technique et veille technologique

LinuxFr.org : les journaux  -  Docker vs Podman sur fedora 32 et headless CMS

 -  Octobre 2020 - 

Sommaire

• • La mode headless CMS
  • Les outils
  • Podman
  • Un exemple
  • Conclusion

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).

Commentaires : voir le flux Atom ouvrir dans le navigateur

par kreako