Cluster swarm à la maison

Salut :slight_smile:

J’envisage de devenir chatons dans un avenir plus ou moins proche. Comme expliqué dans la présentation de mon projet, j’ai déjà une infra existante que je suis en train refondre. Je migre d’un serveur proxmox sur une infra en cluster avec docker swarm. Les serveurs seront localisés chez moi, il me faut donc quelquechose de peu encombrant, silencieux, qui tien la route niveau spec, et pas trop energievore. J’avais pensais me tourner sur des cartes arm et notamment ce genre de cartes pour l’exécution de la stack. Pour le stockage et les sauvegardes plutôt sur celle-ci.

Qu’en pensez-vous ? Connaissez-vous d’autres solutions matérielles qui pourraient réunir mes prérequis ?

1 Like

Bonjour @draconis,

Ton choix de cartes est bon, disons que le plus sûr c’est de partir sur raspberrypi, mais clairement hardkernel a bonne réputation et est présent depuis longtemps. Il y a quelques utilisateurs Odroid dans la communauté Matrix, ils en sont content.

A contrario, j’ai une mauvaise nouvelle pour ton choix de Docker Swarm. Tu peux bien entendu l’utiliser, mais c’est un projet qui reste juste maintenu, il ne faut pas s’attendre à le voir évoluer. La raison c’est que Docker visait les entreprises avec ce produit, mais s’est fait couper l’herbe sous le pied par Kubernetes.

Tu peux éventuellement regarder ce dernier, il y a des gens qui s’en servent pour de l’auto-hébergement. Par contre ça va demander un peu de lecture/recherche et de temps de ta part. Tu feras tourner des conteneurs donc de ce côté là pas de changement.

Bonne chance !

1 Like

Ah mince, je savais que Kubernetes été préféré à swarm, mais il me semblait au cours de mes lectures qu’il été encore suivi par l’équipe Docker. Mon choix c’est porté sur swarm, pour sa simplicité et sa rapidité de mise en œuvre. J’ai vu plusieurs chatons utilisé swarm vous aussi vous migrerez sur kuber ou autre ?

J’ai procédé à quelques recherches rapides, y t-il des utilisateurs de k3s? Une sorte de kubernetes allégé et plus simple. J’avoue que la complexité de Kubernetes me refroidit totalement pour la petite structure que je souhaite mettra en place.

Je sais qu’il y a des trucs qui traînent chez ACIDES : https://forge.tedomum.net/acides/hepto

J’ai personnellement testé k3s il y a pas mal de temps, c’était moyen, je préfère une installation standard de k8s.

Tu peux essayer rke2 pour une solution clés-en-main (sinon il faut faire des choix sur la partie réseau (calico, flannel…), ingress (nginx, traefik…) et c’est technique). Si tu aimes ansible tu as kubespray en alternative.

Le reste, ce sont des « objets » à comprendre (deployment, pod, service, configmap…) mais c’est toujours du yaml, plus verbeux qu’un docker-compose certes.

J’ai essayé de te prévenir, il y a de l’énergie à y consacrer :sweat_smile:

Je préfère mettre de l’énergie dans quelque-chose de perenne. De ce j’ai lu Mirantis à racheté Docker et promet un support de swarm pour deux ans, c’était en 2020, cela me laisse encore un an et demi pour peaufiner, travailler mon infra. Cela colle parfaitement avec ce que je me suis fixé comme calendrier.

Je te remercie de m’avoir éclairé. Je trouve dommage que tu ai été mon seul interlocuteur, de pas avoir échangé avec d’autres. Utilisant swarm ou pas, ayant migré vers autre chose et pourquoi.

Surement que swarm n’est pas aussi intéressant qu’il n’y parait.

Perso je ne suis pas encore embarqué dans la küberhype. Concernant docker je vois plus les problèmes que ça pose que les problèmes que ça résout. Mais tout ça bouge vite et je n’y ait pas consacré que temps que ça exige.

Selon toi quels problèmes cause Docker ? Exactement cela bouge tellement vite qu’a certains moments il est urgent d’attendre :slight_smile: .

Beh par exemple je fais de l’hébergement mutualisé : Docker ne permet pas à ma connaissance de donner la possibilité à différents utilisateurs de déployer des images sur une machine donnée en conservant un bon niveau d’étanchéité entre les différents utilisateurs. (On me soufflera peut être que podman apporte une solution, mais 1) on parle de Docker et 2) podman c’était il y a peu encore trè frais et pas conseillé en prod.)

Par exemple j’aime pouvoir avoir confiance dans ce que je télécharge/exécute. L’écosystème docker repose énormément sur des images prêtes à l’emploi, mais je ne peux pas avoir dans ces ready mades le niveau de confiance que j’ai pour les packages de ma distribution. Ces derniers sont signés par des personnes appartenant communauté de co-optation (web of trust), dont le travail est suivi par des pairs.

Par exemple j’aime pouvoir dormir sur mes deux oreilles la nuit. Il est délicat sans enrobage important de s’assurer du suivi des mises à jours des logiciels embarqués. En comparaison, dans ma distro je fais apt upgrade && apt upgrade laisse faire unattended upgrades.

Plus généralement mon sentiment est que Docker est utile et fort pour accélérer les déploiements et/ou les tests d’applications ou d’ensembles d’applications complexes en aidant par ailleurs à faire des choses reproductibles, sauf que le cycle de vie d’un logiciel ne se réduit pas à ça. Perso ma problématique est souvent de trouver comment faire correctement vieillir un truc pendant plus de 10 ans en minimisant les pannes et en tenant compte d’un environnement mouvant, plutôt que trouver comment simplifier le déploiement.

J’entends les débats/arguments du genre pet vs cattle, mais personnellement je ne suis pas convaincu que l’approche « bétail » soit un progrès. Je reste un artisan avec des machines de compagnie qui ont un nom propre. :slight_smile:

Selon toi quels problèmes résout Docker ?

Salut @draconis,

Pour ma part je fais parti d’un hébergeur associatif et on a choisi Nomad comme orchestrateur plutôt que Kubernetes ou Swarm. Nomad a l’avantage d’être drastiquement plus simple à mettre en place et à gérer. En contrepartie il y a moins de fonctionnalités, et le scope est plus petit que Docker Swarm ou Kubernetes, par exemple il n’y a pas de gestion du réseau (ce que je considère comme un avantage).
Tu peux trouver notre repo ici avec tous nos services : https://git.deuxfleurs.fr/Deuxfleurs/infrastructure
Pour info, on construit la plupart de nos images depuis une base Debian directement ou from scratch.

Pour le projet ACIDES, il est entre autre poussé par TeDomum bien qu’on traine un peu dedans aussi :stuck_out_tongue:, je te conseille d’y aller faire un tour, ils sont très solides techniquement !

Enfin, tu vas te rendre compte qu’une fois ta techno de conteneur choisie, tu te rendras compte que c’était pas si important que ça ^^ Ce qui compte vraiment, c’est comment tu vas gérer les données dans ton cluster, que ce soit la BDD ou le stockage de blob (les images, vidéos, etc.)
Et là, pareil avec TeDomum on essaye de pas mal défricher :

  • Pour le stockage d’objet, TeDomum a déployé un minio, qui devrait faire l’affaire tant que (1) tu as peu de latence entre tes noeuds (2) tu ne prévois pas d’ajouter ou supprimer du stockage
  • Pour le stockage d’objet, on développe notre propre logiciel, garage, pour essayer de résoudre les 2 problèmes de Minio cités avant (latence et élasticité) tout en pouvant tourner sur des petites boards ARM, donc avec peu de puissance
  • Pour les bases de données, on tourne avec Stolon qui est un wrapper autour de PostgreSQL pour avoir un cluster configuré automatiquement avec Consul ou Kubernetes mais avec pas mal de limitations.
  • Pour les bases de données, ACIDES travaille sur un projet qui s’appelle Hicso pour combler les limitations de Stolon mais c’est encore à la phase de design.

Je lis que tu cherches quelque chose qui ne soit pas expérimental, bien installé dans le milieu.
Je ne suis pas sûr que ça existe en distribué.
Si tu veux faire quelque chose qui soit éprouvé, peut-être que le mieux c’est de rester à du docker/docker-compose.
Si vous vous inquiétez pour la sécurité de Docker, le mieux c’est de faire des VM ; les autres outils de conteneurisations ne seront pas mieux. C’est juste que le noyau Linux a été compartimenté après coup et c’est pas facile de rien oublier.

Avec TeDomum, nous on a décidé que bien qu’il n’existe rien de bien installé dans le distribué, c’est ce qu’on voulait faire. Je parle pour moi là, mais je trouve que, étant un projet collectif, il est important que l’hébergement soit collectif. Ça permet aussi de s’affranchir des datacenters tout en étant pas trop inquiet en cas de coupure. C’est l’objectif, on y est pas encore mais on progresse.

Si tu veux discuter plus en avant de conteneurs et d’hébergement associatif, tu pourras avoir des gens qui ne sont pas là ici :

  • #acides:tedomum.net - Le salon du projet ACIDES, probablement un bon endroit pour parler de k3s en prod appelé hepto et pour le projet postgresql appelé hicso
  • #tech:tedomum.net - Le salon technique de TeDomum, probablement un bon endroit pour parler de comment ils font tourner leur stack avec docker-compose actuellement
  • #tech:deuxfleurs.fr - Si tu veux discuter de comment on gère notre cluster de conteneurs avec Nomad+Consul
  • #garage:deuxfleurs.fr - Si tu veux parler de Garage, notre solution de stockage d’objet

Et bien sûr, si tu as des questions sur certains points ici, je suis le forum et j’essaierai de répondre.

Idéalement, j’aimerais aussi qu’on puisse faire converger notre expérience/nos expériences avec le forum CHATONS mais je ne sais pas encore comment :wink:

3 Likes

Docker fait du rootless maintenant (mais on est d’accord ça n’est pas le mode « classique », podman est plus sexy sur ces aspects là, mais bon techniquement c’est envisageable).

Mouais, même problématique qu’avec des binaires ou des repos tiers. Pour du perso je reste sur les images officielles (généralement le namespace est détenu par le projet), pour le reste mieux vaut effectivement reconstruire soi-même.

Je fais du podman auto-update, il y a des solutions pour upgrader docker-compose (ou même à l’arrache avec un git pull et du down/up en cron, même si bon…)

:+1:

Mauvais débat (même si une grosse infra rend ta gestion artisanale caduque, je pense que dans le cadre des chatons c’est non pertinent). Le sujet c’est l’immuabilité :wink:

3 Likes

Merci pour vos réponses.

Pour répondre à PoluX :
Un des avantages avec docker, pour moi, est lorsque tu dois déployer plusieurs applications avec des technos différentes. Ainsi tu peux installer du laraval, ruby, node.js sans avoir à maitriser les subtilités de chacun. Tu crées ton Dockerfile et tu déploies, tu réduis ainsi les problèmes d’images de la communauté. Je travaille principalement avec les images officielles des applications que j’utilisent, lorsqu’elles n’éxistent pas je les crée. Mon but n’est pas forcément de monter une méga-structure, je veux rester à taille humaine, développer un lien avec chacun des utilisateurs. Et pourquoi pas organiser des réunions IRL. Swarm me paraît un bon compromi entre les deux, mais sera-t-il maintenu dans un an ?

Pour répondre à Quentin :
J’ai parcouru le site de nomad, je dois dire que cet orchestrateur au premier abords me plaît. Je vais mettre en place un petit labo de test pour apronfondir, mais cela colle pas mal avec ce que je veux faire. Simple, un fonctionnement proche de swarm, avec leader et follower. Que veux-tu dire par il ne gère pas le réseau ?

1 Like

Salutations !
Je bosse sur du Kubernetes / Openshift depuis 3 ans maintenant, hésitez pas si vous avez des questions ou besoin d’un coup de pouce.
Mais clairement la complexité fait qu’il faut un minimum de machines et de personnes pour le gérer proprement.
Jamais pu tester moi-même k3s par contre (hors contexte de démo), j’avais vu passer les quelques articles sur son installation sur Rpi par contre, si vous voulez tester facilement :slight_smile:

Et bien le rôle d’un orchestrateur est de décider sur quel nœud l’application doit tourner. Pire, il peut décider de changer cette application de nœud n’importe quand. Partant de là, tu n’as pas envie de changer ton DNS à la main chaque fois que l’application change de nœud ou de reconfigurer l’IP de ton service partout où il est utilisé par une autre application. Tu dois donc trouver une solution pour automatiser ça, et il y a plein de façons différentes d’approcher le problème.

Du plus bas niveau au plus haut niveau, sans être exhaustif, tu peux faire ça avec du routage, avec un réseau overlay, avec de la découverte de service, avec des proxys, avec une API gateway, etc.

Docker Swarm embarque son réseau overlay avec une fonctionnalité dite mesh routing qui semble se baser sur du VXLAN. Du coup, peu importe sur quel nœud de ton cluster arrive la connexion, si le service est ailleurs, le nœud de réception fera suivre la connexion au bon destinataire.

Kubernetes n’embarque pas de module réseau out of the box mais propose un framework pour que des plugins puissent venir se connecter, toutes les combinaisons possibles sont imaginables.

Par défaut, Nomad ne fait rien de tout ça, c’est en dehors de son scope. Hashicorp propose une solution basée sur Consul nommée Consul Connect basée sur le modèle side-car. Mais sinon de base, Consul Services se comporte comme un outil de découverte de services.

Pour notre part, on est pas trop fan de Consul Connect. Par contre on utilise Consul Services pour les services en interne. Pour ce qui est de l’externe, aucun outil n’a été conçu pour gérer une box avec un NAT à configurer, du coup on a commencé à développer notre propre logiciel, diplonat, qui parle UPNP IGD. Idéalement, c’est lui qui reconfigurera notre DNS quand notre cluster sera plus grand et sera exposée avec plus que une seule IPv4 !

Je suis venu lire pour poser la question sur swarn mais vous aviez déjà répondu:

Sans faire de devin, je pense que hashicorp abandonnera nomad aussi.
Tous les orchestrateurs se meurent sauf kubernetes (mesos, swarm et le prochain nomad :slight_smile: ).
Je ne serais meme pas surpris que les hadoop et autre cassandra se meurent aussi.

Kubernetes est simplement la nouvelle cloud API, la nouvelle VM. En 2021 faire une nouvelle infra container distribué sans k8s me parait un paris audacieux :slight_smile:

(Après si vous aimez pas les containers linux vous avez surement de bonnes raisons, restez sur vos VMs, et si vous ne voulez pas faire du distribué, faites du docker-compose c’est très bien, notre server compose a un meilleur uptime que nos app k8s :upside_down_face: )

On a fait un cours gratuit ici

Et il faudrait qu’on fasse un livestream sur nos dernières reflexions et Q&A ce serait cool. On va essayé de plannifier ça pour le mois de Mai ou Juin!

Voila, du coup, je te recommande compose :slight_smile: si tu débutes avec Docker, tu auras déjà bien assez à faire sans te soucier du stockage et du network (sds et sdn )
Bon courage :slight_smile:
On utilises toujours libre sh v1 par ici si tu veux:

Pas tout est forcément bien documenté, mais on réponds au questions sur notre chat :slight_smile:

1 Like

On observe un consensus autour de k8s. Si vous souhaitez améliorez vos compétences sur ce sujet, je vous conseille Aurélie Vache. Aurélie est notamment une duchess, Elle est également une médiatrice numériques sans chichi. Ses webinaires sont excellents. (Nous avions participé à un projet cofinancé par érasmus.)
Certaines membres des duchess avaient été interviewées sur radio cause commune, la radio de l’april :upside_down_face:

Comme ça, ça permettra à @pierre de proposer ipv6 par défaut même à indie.host.

1 Like

@pierre
J’avoue que réaliser un projet perso et en partager les ressources avec quelques utilisateurs utiliser K8s ne m’emballe pas du tout. J’ai l’impression de sortir la grosse artillerie pour pas grand chose. Je me trompe peut-être, mais c’est vraiment l’impression que j’ai lors mes lectures sur le sujet.

@quentin Merci pour tes précisions. J’ai deux raspberry pi 2 qui trainent dans un tiroir ça peut-être suffisant pour faire un petit labo de test ? En attendant que je commande mes cartes odroid.

Encore Merci à tous pour vos témoignages. Je me sens moins seul :smiley:

1 Like

Idéalement 3 c’est mieux ! C’est pour aller plus loin avec tous les logiciels qui ont besoin d’un quorum - comme etcd et donc kubernetes, comme consul ou nomad, etc (dès qu’on te parle de paxos ou raft). Pour supporter la perte de n noeuds, il t’en faut 2n + 1. Donc pour tester ton comportement en cas de 1 crash, il te faut 3 nœuds au départ :slight_smile: Après rien ne t’empêche de mettre le 3ème dans une VM sur ton PC ou de faire des conteneurs LXC sur tes raspberry pi et de mettre deux conteneurs sur une raspberry.

Pourquoi pas un « cluster swarm » entre nos maisons ?

C’est ce qui me semblait, je vais attendre les cartes Odroid pour monter mon labo et construire petit à petit mon infra de production.