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 barmic 🦦 . Évalué à 4.
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…
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pod
Posté par aiolos . Évalué à 5.
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 Christie Poutrelle (site web personnel) . Évalué à 5.
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 aiolos . Évalué à 1.
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 Christie Poutrelle (site web personnel) . Évalué à 5.
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 aiolos . Évalué à 4.
Ah, d'accord. Effectivement, j'avais mal interprété. Merci.
[^] # Re: pod
Posté par Christie Poutrelle (site web personnel) . Évalué à 4.
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 aiolos . Évalué à 1.
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 kreako . Évalué à 4.
Voudrais-tu clarifier/sourcer ton affirmation ?
Je lis ça dans la doc (un post de blog) :
Et en suivant le lien de la doc de kubernetes :
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 ?
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 Anonyme . Évalué à 10. Dernière modification le 18 octobre 2020 à 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 -HUPsur 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 kreako . Évalué à 3.
Merci !
[^] # Re: pod
Posté par barmic 🦦 . Évalué à 7.
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 :
Tout fusionner va t'empêcher de :
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
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pod
Posté par kreako . Évalué à 4.
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 Anonyme . Évalué à 4. Dernière modification le 18 octobre 2020 à 02:39.
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 steph1978 . Évalué à 4.
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 devnewton 🍺 (site web personnel) . Évalué à 4.
Pourquoi il faut une base pour stocker le contenu?
Pourquoi pas un gestionnaire de version et un outil d'intégration / déploiement continue?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: CMS headless et baseless ?
Posté par xulops (site web personnel) . Évalué à 1.
Parce qu'il existe plusieurs solutions (comme il existe plusieurs façon de coder) en fonction du besoin, du contexte, des ressources, … Diversité ne nuit point et permet à chacun de trouver son bonheur.
[^] # Re: CMS headless et baseless ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Il ne reste plus qu'à faire un CMS headless, baseless et contentless, qui du coup serait virusless, foolproof et digital-ready for blockchain cloudiness IA-enabled.
[^] # Re: CMS headless et baseless ?
Posté par _kaos_ . Évalué à 4.
Salut,
Il manque des bouts.
Il serait pas awsome ce produit ? Genre revolutionary ?
;)
Matricule 23415
[^] # Re: CMS headless et baseless ?
Posté par kantien . Évalué à 1.
Je crois qu'il y a méprise : ce n'est pas revolutionary mais It’s gonna be legen… wait for it… dary ! Legendary! L'awesomeness c'est totalement Stinson-proof. Par contre cela risque de ne pas être très inclusive, ce qui est à la mode en ce moment. :-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: CMS headless et baseless ?
Posté par Thomas Douillard . Évalué à 3.
T’es dépassé, on est maintenant passé à l’awesomeless.
[^] # Re: CMS headless et baseless ?
Posté par _kaos_ . Évalué à 2.
Salut,
Je ne suis pas un dinosaure, je ne suis pas un dinosaure, je ne suis pas un dinosaure, je ne suis pas un dinosaure, je ne suis pas un dinosaure, je ne suis pas un dinosaure… me dis-je alors.
;)
Matricule 23415
[^] # Re: CMS headless et baseless ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ça fait quelques millions d'années que la Terre est dinosaurless !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: CMS headless et baseless ?
Posté par Anonyme . Évalué à 4.
Seulement les dinosaures non aviaires.
[^] # Re: CMS headless et baseless ?
Posté par _kaos_ . Évalué à 2.
Salut,
Ouf ! J'ai cru un instant qu'il s'agissait d'un monde sans queue ni tête.
Matricule 23415
[^] # Re: CMS headless et baseless ?
Posté par Thomas Douillard . Évalué à 2.
alors qu’il n’est que sans dents
[^] # Re: CMS headless et baseless ?
Posté par lolop (site web personnel) . Évalué à 4.
Oh, une licorne passe.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: CMS headless et baseless ?
Posté par steph1978 . Évalué à 3.
Si on joue sur les mots, une base de données étant un endroit où on stocke des données, il faut toujours une base de données… pour stocker des données, quelque soit sa forme : FS, VCS, RDBMS, NoSQL DB, etc.
Il est vrai que par abus de langage, une "base de données" est souvent associée à "base de données relationnelles".
[^] # Re: CMS headless et baseless ?
Posté par mathgl . Évalué à 4.
Je pense que l'idée derrière les CMS headless, c'est plus d'avoir un frontend en javascript qui utilise l'API pour consulter le contenu. Ça revient donc à faire un site dynamique et non statique. Même si les fichiers générés pour le frontend sont eux statiques. Dans ce contexte, c'est plus compliqué d'utiliser un gestionnaire de version comme source de données.
# plugins de génération de sites statiques + sécurité
Posté par cg . Évalué à 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 barmic 🦦 . Évalué à 4.
Et on perd une pars des fonctionnalités, non ? Les commentaires par exemple
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: plugins de génération de sites statiques + sécurité
Posté par Anonyme . Évalué à 2.
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 cg . Évalué à 1.
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 barmic 🦦 . Évalué à 2.
Ç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).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: plugins de génération de sites statiques + sécurité
Posté par Anonyme . Évalué à 2.
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à).
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.
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 barmic 🦦 . Évalué à 2.
Si un utilisateurs veut un flux avec les articles ayant les tags "linux" et "debian" par exemple.
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.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Container et tout et tout
Posté par AlexTérieur . Évalué à 4.
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 steph1978 . Évalué à 3.
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 AlexTérieur . Évalué à 1. Dernière modification le 21 octobre 2020 à 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 Atem18 (site web personnel) . Évalué à 3.
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 steph1978 . Évalué à 6.
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 Atem18 (site web personnel) . Évalué à 5.
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.
[^] # Re: Container et tout et tout
Posté par marty314 . Évalué à 0. Dernière modification le 16 novembre 2020 à 14:33.
Assez d'accord avec toi pour la partie compatibilité que je trouve vite limitée, j'utilise régulièrement docker / docker-compose / docker swarm, j'ai réussi à faire tourner quelques containers sous podman, mais à partir du moment où il faut monter un volume persistant sur le container c'est galère (en tout cas pas possible sous podman-compose).
Si ça avait marché j'aurais vite utilisé la solution pour mes serveurs mais du coup ça attendra…
A côté de ça, je te conseille vraiment de penser à la solution container, c'est maintenable, portable, ça isole bien chaque système & c'est pratique pour sauvegarder
# Gné?
Posté par Panhwein . Évalué à -8.
Rien compris.
Bise, Martine
# Autres qualités
Posté par faelar . Évalué à 1.
A titre personnel j'utilise régulièrement:
-
podman generate systemd, pratique pour gérer ses conteneurs comme des services.-
podman auto-updatepour mettre à jour les nouvelles versions des conteneurs.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.