i*******e
发帖数: 27 | 1 要把几个项目从共享服务器移到虚拟服务器上, 我没用过DOCKER， 初步的想法就是每
个网站对应一个DOCKER， 也就是每个D里都自带个数据库， 后端， 前端。 不知这个
方案是不是很傻。
想知道有么比较推荐的方案 |
v***e
发帖数: 14 | |
d*******r
发帖数: 3299 | 3 persistent layer 不适合放到 docker 里面, 比如数据库不适合放进去.
一般是把一个(stateless)micro service打包成一个docker image,
然后这个docker image跑在docker managing框架里面(k8s, AWS ECS/Fargate)
docker的另外一个用途是做成开发环境dev env, 发布给组内开发者
最后说句个人观点: docker+k8s 这套东西其实是一套stupid&ugly的设计.
anyway, it works... 太流行了, 打工人捏着鼻子用就是 |
n******t
发帖数: 4406 | 4 是共享物理機到虛擬機？應該不需要用docker，只需要分別做vm image，把你那一堆東
西都帶上就行了。
docker本來就是爲了分離組件，which你反正也是放一起的，沒什麼point。
【在 i*******e 的大作中提到】
: 要把几个项目从共享服务器移到虚拟服务器上, 我没用过DOCKER， 初步的想法就是每
: 个网站对应一个DOCKER， 也就是每个D里都自带个数据库， 后端， 前端。 不知这个
: 方案是不是很傻。
: 想知道有么比较推荐的方案
|
n******g
发帖数: 2201 | 5 很有道理 关于docker 没有替代吧
【在 d*******r 的大作中提到】
: persistent layer 不适合放到 docker 里面, 比如数据库不适合放进去.
: 一般是把一个(stateless)micro service打包成一个docker image,
: 然后这个docker image跑在docker managing框架里面(k8s, AWS ECS/Fargate)
: docker的另外一个用途是做成开发环境dev env, 发布给组内开发者
: 最后说句个人观点: docker+k8s 这套东西其实是一套stupid&ugly的设计.
: anyway, it works... 太流行了, 打工人捏着鼻子用就是
|
d*******r
发帖数: 3299 | 6 打工的话, 如果公司里要求用, 就没有代替 -_-
【在 n******g 的大作中提到】
: 很有道理 关于docker 没有替代吧
|
s*********y
发帖数: 6151 | 7 分开的monolithic还是monolithic
你们什么公司 这么传统？ 既然都要docker了 干脆微服务不好吗 Toyota换个兰
博基尼的cupholder是什么意思？ |
c******n
发帖数: 16666 | 8 按docker本身理念的话 一个docker就做一个事情 https://docs.docker.com/develop
/develop-images/dockerfile_best-practices/#decouple-applications)
所以你这种应该是后端 数据库 都分开来 大家一人一个docker 最后用用docker
compose 或者fancy点 k8s
连接 就连前端 我看有k8s用户的论调也是分开来
现实中 还是考虑好项目具体情况 对将来的自己好一点
前端全都跑在一个host下面直接nginx或者traefik不香吗？这给ci/cd省好多事儿
如果数据库都一样 也不会出现后期某个数据库要装特殊插件这种需求的话 可以数据库
全都依靠一个 然后还可以多分点内存过去 此外数据备份 数据库升级也省心不少
我现在80%在跑的项目都是共享一个nginx做reverse proxy 一个postgres做数据库 然
后后端跑在docker compose上
剩下15%有特殊需求的（postgis啊 elk啊 各种花样）每个服务跑自己的docker 最后连
在docker compose。还有不少是跑几个月就要迁移到客户环境的，也单独分开来省得麻烦
最后5%是k8s 这玩意就是刷简历用的 妥妥一万年yagni
【在 i*******e 的大作中提到】
: 要把几个项目从共享服务器移到虚拟服务器上, 我没用过DOCKER， 初步的想法就是每
: 个网站对应一个DOCKER， 也就是每个D里都自带个数据库， 后端， 前端。 不知这个
: 方案是不是很傻。
: 想知道有么比较推荐的方案
|
s********i
发帖数: 17328 | 9 看你budget多少，花多少man-hour，理论上长远上讲当然是分开比较好，但如果没有人
力物力去做，那就只能从简了，丢在一个container里凑合完事儿。要做几个方案，做
effort estimate，优缺点总结一下，然后去和老板谈，让老板决定，这不仅仅是技术
问题。你要没做过，赶紧恶补一下基础知识和best practice，这东西不难，很多都是
common sense。像HumbleCoder说的，数据库尽量外置，自由度大得多，但你原来的产
品不支持，就要花功夫改。
简单的例子，你说每个container自带一个数据库？从技术角度，技术领导直接就给你
否了；你说我们从新设计一下，让container们共用一个数据库，但要花一年时间，销
售领导可能摇头不同意，一年后黄花菜都凉了。get things done right和get things
done fast要trade off。 |
