wosuopu

5zTUySyUx7q1YazUfLLvqboq7Pb3saMPvsgLiwWL2hsn

@mightybruce 工具并不是越先进就越好，只有适合自己的才是最好的。
k3s 、nomad 之前也有调研体验过，使用这些方案不仅不能减轻我们的运维负担，反而还增加了我们的工作量。

我们想要的其实很简单，现在我们本地的开发环境是用的 docker-compose 来配置的，所以也希望线上的环境可以直接使用 docker-compose 的配置文件，简单、方便、好用；不需要其他花哨的功能。

目前 rancher v1 跟 docker swarm 都是可以直接使用 docker-compose 配置的，只是 docker swarm 没有管理界面，不太方便。

我们团队这些年对于各式各样的容器编排工具都体验过不少，我也来说说这些年的一些心得体会吧。

我们只是一个小作坊规模的团队，所有的技术人员总共才有几个人而已，既要负责前后端的开发工作，还要负责服务器的运维工作。
最开始使用 docker 容器来部署服务，图的就是方便。这个可以减少我们的运维工作量。

差不多是 2017 年的时候吧，我们开始尝试使用 rancher v1.x 来管理服务器，当时的 k8s 还没像这样流行起来。rancher v1 差不多就是把提供一个 web 的界面来管理 docker 容器，而且还能管理多台服务器集群，简单、方便；不像 k8s 那样需要理解一堆的概念。

过了两年，k8s 开始流行起来了，rancher 也从 v1 升级到了 v2 ；此时的 rancher v2 也全面切换到 k8s 了，一下了就变得复杂很多了。
我们生产环境的服务器总共都不到 3 台机器；如果使用 k8s 的话，结果你告诉我为了高可用，光是 master 结点就至少得 3 台机器，worker 结点机器另算，而且还需要运行一堆的相关服务。这样光服务器的成本就增加了一倍不止。
另外服务器运维还需要了解一堆 k8s 的概念，当时光是开发的任务时间都不够用，哪还有空来折腾这些。于是我们就选择不升级，继续使用 rancher v1 。

这些年也陆续出现过一些号称是可以简化 k8s 的管理工具，包括 Rainbond 在内，我们也体验也不少，结果都是不太满意。
对于规模较大的，有专门运维人员的团队来说，选择使用 k8s 也没什么问题。但是对于我们这样的小团队，简单、方便的工具要更加适合我们。

直到现在我们都还是用的 rancher v1 ，然而这个版本官方早已不再维护了。现在在新的机器上安装时，还得先把相关的依赖包降级为老的版本才行。最近我们也在寻找替代方案，以免哪天 rancher v1 不能用了吧。
目前看来官方的 docker swarm 还算不错，这个比较简单，都是一些 docker 的东西，没有其他额外的复杂概念；唯一不足的就是官方没有提供 web 管理界面，所有操作都需要命令来执行，这个有点不方便。

现在 k8s 简化工具不少，如果有人能做一个 docker swarm 的简化工具的话，那对我们这种小团队来说就是福音啊。

那要看你请求的路径是什么了。
有一个工具可以在线测试 nginx 的 location 匹配规则的，也许可以用这个试试。https://nginx.viraptor.info/

先收藏

我爱鼠标垫 ReactJS

又有新书了

哈哈哈哈