开源项目地址
ladderx-swarm: 蜂巢集群管理平台 —— 基于docker swarm的中小型容器集群部署方案
项目背景
Docker于2013年正式发布，2016年集成了Swarm集群管理功能；同年，Rancher 1.0版本发布，采用Cattle引擎作为核心驱动。2018年，Rancher推出2.x系列版本，同时宣布停止维护Rancher 1.x版本，全面转向Kubernetes（以下简称k8s）生态。
我们团队使用Rancher 1.x至今，时长已接近10年。期间，我们尝试过其他各类运维管理工具，包括Rancher 2.x、Kubesphere、Portainer、1Panel、Rainbond、Dockge等，但始终未能找到完全契合我们需求的解决方案。
在试用各类工具的过程中，我们发现了明显的两极化问题：
一类工具过于简单，仅能支持单机Docker或Docker Compose的基础管理，对Swarm集群的支持严重不足，无法满足我们多节点运维的需求；另一类工具则过于复杂、庞大，均基于k8s架构构建，不仅上手难度极高，资源占用也非常大，对于我们的业务规模而言，完全是“杀鸡焉用牛刀”，得不偿失。
目前市面上已有的工具，我们认为满足了微型项目部署和中大型项目集群的需求，但对于中小型项目规模并不友好。
我们的项目服务器规模通常在1-50台之间，节点数量弹性极强——业务初期可能仅需1-2台服务器支撑，若业务发展顺利则需快速扩容至几十台；若业务调整，则需从几十台缩容至1-2台，对运维工具的灵活性要求极高。
同时，我们没有专业的运维团队，仅靠1-2名工作人员负责所有运维相关工作，工具的易用性和低维护成本就显得尤为重要。
具体来看，1Panel、Portainer、Dockge这类工具，虽操作相对简单，但对集群管理的支持不足，无法适配我们节点弹性变化的需求；而Kubesphere、Rancher 2.x、Rainbond这类基于k8s、k3s的工具，不仅架构复杂、维护难度大，对服务器资源的占用也居高不下，远超我们的实际需求，加重了运维负担。
也正因为如此，Rancher 1.6才得以陪伴我们多年，成为我们的核心运维工具。
直到近年来，Rancher 1.6的诸多缺点已难以忍受，我们才最终决定基于Swarm自研一套运维管理系统。作为一款已停止维护多年的工具，Rancher 1.6频繁出现各类莫名故障无处申诉，既无法满足我们对新功能的需求，也不支持新版本的Docker；而Docker版本的限制，又导致我们无法适配新版本的服务器操作系统，同时也不支持ARM架构，这些问题已严重影响业务正常推进，更换工具成为必然选择。
我们选择基于Swarm自研系统，核心考量如下：
集群的高可用主要依托Swarm自身的能力，管理工具即使出现单点故障，也不会影响核心业务的正常运行；从资源占用来看，管理工具仅需2核以上CPU、1-1.5G内存，再加上业务系统的部署需求，服务器最低配置达到2核4G内存、20G以上磁盘，即可稳定运行，完全适配我们的资源预算。
此外，Swarm与Docker原生集成，安装流程简单，上手难度低，无需专业运维知识也能快速操作。值得注意的是，虽然Swarm已于2023年停止主动更新，但还处于维护模式；即便未来完全停止维护，对于我们小团队而言，也可继续使用多年——就像Rancher 1.6停止更新后，我们依然稳定使用了多年一样。
综上，基于Swarm自研这套系统，不仅能完美解决我们当前面临的所有运维痛点，更能为我们团队解决未来5-10年的运维需求，为业务的稳定发展提供可靠支撑。
界面截图
登录
集群管理
应用服务
服务配置
负载均衡
容器日志
