针对一套系统同时维护 k8s 和 docker compose 两种部署方案，有没有比较好的管理方式呢？
eephee · 2023-03-05 17:46:20 +08:00 · 3191 次点击这是一个创建于 638 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司自己的 saas 版本是部署在国内云厂商的公有云上面，对客户私有化部署的话，考虑到规模较小的客户的机器资源有限，仍然使用 k8s 的话，支持 k8s 本身就需要占用机器资源，所以针对小型客户准备采用 docker compose 的方式部署。
我最近在思考如何比较安全地维护这两种部署方式：期望是在维护过程中，针对配置文件的改动（更改环境变量等）能够同时应用到这两种部署类型的配置文件上（ k8s manifest & docker-compose.yaml ），我目前打算用 ansible ，然后自己分别写两种部署的配置模板，然后改动 ansible 的配置文件，自动生成 k8s yaml 和 docker compose yaml 配置文件，但是细节还没有完全实现。
所以在此之前，想问一下大家有没有更好的实践或者工具推荐呢
 |
1
eephee OP 我目前主要担心能否利用 ansible 做到 cover 所有 docker compose 和 k8s manifest 差异比较大的一些点，有些地方就比较容易（比如两者配置都有 docker image ，k8s 有 env/envFrom ，docker compose 有 enviroment/env_file ），其他地方可能不是能很好地缝合（比如一些 k8s 独有的特性，暂时想不到很具体的...）
|
 |
2
xabcstack 2023-03-05 19:19:59 +08:00
docker compose 本身和 k8s 没有多大区别，这不是一个好问题
|
|
3
xabcstack 2023-03-05 19:20:53 +08:00
一个服务，你需要维护镜像的更新， 一个 deployment.yml 和 一个 docker-compose.yml 解决你的问题
|
|
4
eephee OP 不是，有十几个微服务
|
|
5
xabcstack 2023-03-05 19:26:40 +08:00
一个 deployment.yml 可以写十几个容器
一个 docker-compose.yml 也可以十几个以此拉起 |
 |
6
defunct9 2023-03-05 20:01:48 +08:00
都用 k8s ，这才是正解。
|
 |
7
Kumo31 2023-03-05 20:21:31 +08:00
肯定只维护一套比较好，kompose 可以把 docker compose 的配置转化成 k8s 格式。或者反过来用可以兼容 k8s 配置的 podman 代替 docker
|
 |
8
cnbattle 2023-03-05 20:33:39 +08:00 via Android
第一时间想到的方式，一个 dapr ，一个 k3s
|
 |
9
seashell2000 2023-03-05 21:07:19 +08:00
ansible 完全没必要，不同的 yml 可以解决，关键是 yml 可能要根着 image 版本联动
还有就是 k8s 的某些配置太多选项，这就是为什么有了 helm |
 |
10
yso 2023-03-05 21:45:31 +08:00 via iPhone
podman play kube 你看看，我没用过，看有英文博客提： https://www.redhat.com/sysadmin/podman-play-kube-updates
|
 |
11
vus520 2023-03-05 21:50:23 +08:00
k3s 不就是为了这种需求而生吗？ 256M 的 k8s 开销，能差多少？
|
 |
12
sniperking1234 2023-03-05 22:45:32 +08:00
|
 |
13
wheeler 2023-03-05 22:47:42 +08:00 via iPhone
compose 和 k8s 表达能力差不少吧。维护两套费劲啊。
|
 |
14
zzl22100048 2023-03-06 09:13:51 +08:00
k8s 占用资源太多就用 k3s 呗
k3s 内存应该不超过 512M |
 |
16
guanzhangzhang 2023-03-06 10:08:36 +08:00
作为过来人表示，你这个我们内部就是，为了多台机器的 docker 的业务能够少改造的，也就是保留 svc 访问。
我们内部的业务很多调用其他业务组的 svc 都是默认的，不是 env 传入的。我把 k8s 的 svc 逻辑摸通后用 keepalived+ipset+iptables 搞出来了（可以看我博客） k8s 我们把 env 和 svc 的和 volume 的部分抽象成一个 yml 文件给各个业务组，部署业务的时候主模板+各个业务组的 values 文件渲染。docker 版本也用 ansible 服用了这个 yml 文件，然后写了个 docker-compose 模板，并且单独搞了个大 yaml ，覆盖业务里的某些 env 和挂载。 但是业务多了就麻烦了，还是推荐你先用 k3s ，或者 swarm 的 swarmkit 啥的 |
 |
17
mingwiki 2023-03-06 11:52:01 +08:00
没想到还有 kompose 这种工具 就是转换后文件太多了 维护有点懵 所以平时维护 compose 再用 kompose 转换 然后使用 k8s 这种方法可行吗？
|
|
18
eephee OP k3s 确实值得尝试一番，我先记到 todolist 里面。
我们优先是维护 k8s 配置，docker compose 的支持位于第二等，所以如果能从 k8s 的 yaml 生成 docker compose 是我的目标，kompose 好像只能单向转换（ docker compose --> k8s ），所以我应该用不到。 昨天了解了一下 k8s 和 docker compose 在配置文件上有些地方还是蛮像的(env/envFrom ==> environment/env_file ，service ==> network alias...)，所以一个简易的 ansible module 脚本可以搞定这个转换。 |
|
19
eephee OP @guanzhangzhang 感谢，我去拜读一下。
|
|
20
eephee OP 感谢大家的回复和帮助~
|
 |
21
salmon5 2023-03-06 15:18:13 +08:00
冒昧的问下，OP 岗位是开发还是运维，或者交付，
这块我想了解下是谁负责。 |
|
22
salmon5 2023-03-06 15:19:18 +08:00
在我看来，阿里云或者 AWS 这种公司，应该是开发负责。
|
|
23
eephee OP @salmon5 前段时间做开发，最近重心转到了运维上面，最近处理部署相关的事情。我怎么感觉这个应该就是由运维负责。
我们公司之前，虽然 saas 在公有云上面，但是给客户私有化部署是手工拿 jar 包部署的，今年 Q1 计划改成更加自动化的部署方式。 |
|
24
salmon5 2023-03-06 22:12:20 +08:00
@eephee #感觉这个开发或运维负责没有统一的界限，有 2 个维度：
1 ，谁受益最大谁负责，欲戴皇冠必承其重（现实中有时候有人摘果子：收益大不负责） 2 ，谁做更合适，偏业务型开发负责，偏 Infra 运维负责。（ k8s 是次要的，有些项目开发可能会用将近 10 年前的技术栈，完全无法容器化） |
|
25
eephee OP 最终还是用 k3s 了
|
Select Language