Uncloud - un outil pour déployer des applications conteneurisées entre serveurs sans la complexité de Kubernetes

• Uncloud est un outil open source qui permet de déployer et faire évoluer des applications web conteneurisées sur plusieurs serveurs sans Kubernetes
• Il conserve un workflow basé sur Docker Compose, tout en prenant en charge les déploiements sans interruption, le HTTPS automatique et la montée en charge entre serveurs
• Sans plan de contrôle centralisé, chaque machine est reliée via un réseau P2P basé sur WireGuard, ce qui permet au cluster de continuer à fonctionner même si certains serveurs sont hors ligne
• Inclut le HTTPS automatique via le reverse proxy Caddy, la découverte de services basée sur un DNS intégré et des fonctions d’équilibrage de charge
• Le déploiement est possible de la même manière dans des environnements hybrides cloud et on-premise, ce qui garantit le contrôle de l’infrastructure et une meilleure prévisibilité des coûts

---

Un workflow proche d’un PaaS

• Offre une expérience de déploiement simple comme Heroku ou Fly.io, tout en conservant un contrôle total sur les serveurs et les données
  • Structure de coûts prévisible, au lieu d’une facturation à la requête
  • Aucune dépendance à un fournisseur, débogage possible avec des outils SSH standard
• Architecture pensée pour Docker Compose, permettant d’exécuter build, push et déploiement en une seule commande
  • Aucun registre d’images nécessaire, avec prise en charge des déploiements progressifs sans interruption
  • Mise à l’échelle par réplication possible sur plusieurs machines

Une conception à faible maintenance

• Aucun plan de contrôle ni gestion de quorum nécessaires, pour réduire au minimum la complexité opérationnelle
• Prend en charge une communication sécurisée entre machines sans ouverture de ports
• Intègre la découverte automatique des services et l’émission automatique de HTTPS basée sur Let's Encrypt

Fonctionnement

• Repose sur un réseau simple de machines plutôt que sur un cluster complexe, afin de fournir une infrastructure stable sans lourde charge de maintenance
• Chaque machine rejoint un réseau mesh WireGuard pour découvrir automatiquement ses pairs et assurer la traversée de NAT
  • Les conteneurs reçoivent une IP unique, ce qui permet une communication directe entre serveurs
• Architecture entièrement distribuée : sans nœud de contrôle central, chaque machine synchronise l’état du cluster
  • Le cluster continue de fonctionner même si certaines machines sont hors ligne
• CLI de type Docker pour piloter l’ensemble de l’infrastructure
  • Un simple accès SSH à une seule machine suffit pour déployer, superviser et mettre à l’échelle

Principales fonctionnalités

• Déploiement possible partout : prise en charge de toutes les machines Linux, qu’il s’agisse de VM cloud, de serveurs dédiés ou d’on-premise
• HTTPS automatique : le reverse proxy Caddy intégré permet l’émission sans configuration de certificats TLS et l’activation du HTTPS
• Équilibrage de charge : répartition du trafic entre les réplicas de conteneurs distribués sur plusieurs machines
• Découverte de services : le DNS intégré suit automatiquement l’emplacement des services sur le réseau
• Infrastructure as Code : l’ensemble de la stack applicative peut être défini avec des fichiers Docker Compose existants
• Aucune dépendance fournisseur : possibilité de mélanger librement cloud et matériel propriétaire

[GN⁺]

Avis Hacker News

• Bonjour, c’est le créateur. Merci pour le partage.
  Uncloud est un orchestrateur de conteneurs sans control plane. En gros, c’est une forme de Docker Compose réparti sur plusieurs machines, avec en plus un mesh WireGuard automatique, la découverte de services et le HTTPS via Caddy. Chaque machine synchronise l’état du cluster en p2p avec Corrosion de Fly.io, ce qui évite d’avoir à maintenir un quorum.
  Après avoir exploité Kubernetes aussi bien dans des startups que dans des licornes, je me suis rendu compte que la plupart des équipes ont en réalité seulement besoin de bien faire tourner des conteneurs sur quelques machines, avec du réseau, des rollouts et du HTTPS. À côté de ça, la surcharge opérationnelle de K8s est trop importante.
  Les principales caractéristiques sont les suivantes :

  • utilisation de la spécification Docker Compose, familière, sans avoir à apprendre un nouveau DSL
  • build et push des images Docker directement sur les machines, sans registre externe (via mon autre projet, unregistry)
  • une CLI impérative plutôt qu’un modèle déclaratif, ce qui facilite le débogage
  • connexion possible de VM cloud, de bare metal, et même de Raspberry Pi derrière un NAT
  • moins de 150 Mo de mémoire utilisée
    Lien du projet : https://github.com/psviderski/uncloud
    • K8s sait déjà très bien faire tourner des conteneurs, même à petite échelle, donc je ne vois pas vraiment de raison d’utiliser autre chose. Avec des distributions légères comme k3s, le déploiement est devenu facile, donc je ne ressens pas le besoin d’une alternative.
    • L’idée est sympa, mais le fait que uc machine init exécute en interne un curl | bash avec les privilèges root me paraît dangereux du point de vue sécurité. J’ai bien envie de tester, mais je ne pense pas le lancer sur de vraies machines.
    • C’est vraiment intéressant. Je vais sans doute avoir l’occasion d’essayer bientôt. En revanche, même en lisant la documentation, ce n’est pas clair comment onboarder d’autres ingénieurs après la configuration du cluster, ni comment déployer depuis un runner CI/CD. Je serais curieux de connaître la procédure pour connecter une nouvelle machine à un cluster existant.
    • Je me demande quelles sont les différences avec Kamal.
    • Je me demande comment fonctionne une connexion sécurisée à des services externes comme AWS RDS à l’intérieur d’un réseau privé construit avec WireGuard. J’aimerais savoir si quelque chose comme l’approche de Tailscale pour AWS RDS est pris en charge.

• J’ai passé l’essentiel de ma carrière avec Kubernetes, et je me demande quel est l’avantage d’une architecture sans control plane. Pour moi, le control plane est justement la fonctionnalité centrale de K8s.
  Quelques centaines de nœuds et des dizaines de milliers de conteneurs ne représentent pas une grosse charge avec un cluster managé qui se met à jour automatiquement. Je me demande si ces alternatives viennent surtout de la douleur des gens qui essaient d’auto-héberger K8s.

  • « Quelques centaines de nœuds et dix mille conteneurs », ça ne me paraît pas petit. Moi je suis plutôt sur 2 à 5 nœuds et 10 à 30 conteneurs, et à cette échelle K8s est trop lourd. J’imagine qu’il existe beaucoup d’entreprises de cette taille.
  • Ce n’est pas une question impolie. L’avantage d’être sans control plane, c’est que tout est simplifié dans une architecture pair à pair où toutes les machines sont équivalentes. Il n’y a pas de « cerveau de cluster » centralisé, donc pas besoin de se soucier d’une configuration HA ni des problèmes de quorum etcd.
    Même en cas de partition réseau, chaque partition peut continuer à fonctionner indépendamment. C’est une sorte de retour à la simplicité de l’époque Chef ou Ansible, avec les leçons de K8s en plus.
  • Bien sûr que des gens essaient d’auto-héberger K8s. C’est comme les sauvegardes : si on ne s’y exerce pas à l’avance, on n’y arrive pas le jour où on en a besoin.
  • Pour une PME, dix mille conteneurs, ce n’est absolument pas petit. Moi j’en ai moins de 10, mais j’ai besoin de haute disponibilité (HA). Uncloud semble bien correspondre à mon cas.
  • « Dix mille conteneurs, petit ? Ce n’est pas plutôt des chiffres de jobs CI ? ;) »

• Très beau projet. J’ai bien l’intention de l’essayer plus tard.
  Si vous cherchez une alternative encore plus simple, Kamal est aussi intéressant. C’est un outil éprouvé en production, exploité directement par une entreprise qui a complètement quitté K8s et le cloud.

• Je me demande s’il existe une fonctionnalité qui applique automatiquement un durcissement de sécurité des serveurs (server hardening) quand on désigne des serveurs.

• J’utilise Docker Swarm. Uncloud est la première alternative qui me semble vraiment intéressante.
  Voici mes questions :

  • y a-t-il un projet de support des secrets ?
  • peut-on définir des règles de réécriture d’URL via des labels de conteneur, comme avec Swarm+Traefik ?
  • si l’on déploie deux stacks Compose, les conteneurs de stacks différentes peuvent-ils communiquer entre eux sur le réseau ?
  • le mapping entre domaine et port interne se définit dans le fichier Compose avec x-ports: app.example.com:8000/https.
    Ou bien il est possible de personnaliser la configuration Caddy avec x-caddy: Caddyfile. Voir la documentation officielle pour plus de détails.
    Pour l’instant, il n’y a pas d’isolation réseau entre les stacks. La discussion est en cours dans GitHub Discussion #94.
    Je serais curieux de savoir quel comportement tu attends.
  • La fonctionnalité secrets est suivie dans l’issue #75. L’injection via la config Compose est possible, mais il n’y a pas encore de stockage chiffré.
    Pour les questions 2 et 3, la réponse est « pas encore » et « actuellement oui ». Voir Discussion #94.
    En tant qu’utilisateur de Swarm, je serais curieux de savoir sur quels points Swarm t’a semblé limité ou peu pratique, et ce qu’Uncloud pourrait améliorer.

• Vraiment très beau projet. D’autres outils sur un thème similaire peuvent aussi valoir le détour :

  • Dokploy
  • Coolify
  • Kubero
    Si vous en connaissez d’autres, n’hésitez pas à en ajouter.
  • La liste des PaaS auto-hébergés est utile.
    J’ai essayé Coolify récemment, et ça m’a semblé un peu inachevé. En ce moment, j’utilise Dokku, mais j’aimerais une meilleure UI pour la gestion des bases de données.

• Je suis satisfait de k3s, mais je trouve positif de voir apparaître de nouvelles tentatives dans la zone intermédiaire entre Docker Compose et un K8s complet. L’intégration de WireGuard est particulièrement intéressante.

• Très bel outil. Merci pour le travail.
  Je me demande comment fonctionne la réplication d’état (state replication) en backend. Il est question de CRDT et de protocole gossip, mais l’implémentation concrète reste floue.

  • Actuellement, la réplication d’état repose sur Corrosion.

• Si ce n’est pas K8s, pourquoi pas Nomad ?

  • Nomad est bien aussi, mais il y a toujours un control plane.
  • Nomad a une courbe d’apprentissage assez marquée. À l’inverse, Uncloud est presque utilisable immédiatement pour quelqu’un qui connaît Docker et Compose.
  • La licence de HashiCorp interdit de proposer le logiciel modifié sous forme de SaaS.
    Autrement dit, en dehors de l’auto-hébergement, les usages sont limités, et il est en pratique impossible d’en faire librement un service. Voir le texte de la licence.

• Au passage, je partage deux composants p2p intéressants :

  • edgevpn
  • iroh.computer