公司自己的 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 了
|