后端的 php nginx 服务都跑在 docker 上
现在我想把前端的构建工具也跑在 docker 上,例如 node gulp 等等
应该怎么处理这个工作流,单独新建一个容器吗?如果有多个项目,应该如何操作?
这个Case....一千个人眼中有一千个docker 环境。看你怎么组网,怎么配合应用了。
1,像我个人,习惯待docker如进程process, 那么我会竭力追求一个容器实例只挂起一个进程,因为个人认为如果n个应用都跑在一个容器里,那这个容器就不是进程级别,而是OS/机器级别了,那么建虚拟机镜像好了,干吗还要搞docker镜像?。那即使是php和nginx这样的配合,也会搞起两个容器,可以把它看成一个应用,然后其它语言,像你用nodejs实现的其它应用,我肯定会再跑个容器实例,然后再跑个nginx反代这两个。所以想问你的nginx+php的docker是一个容器吗?2,也有混多个进程在一个docker里,毕竟它还是基于From [OS] 一个操作系统的嘛。可以在docker里跑起个supervisor(python)这样的process monitor,将supervisor交给docker挂起,相同的应用不还有pm2(nodejs)?这样的dockerfile不好写反正。3, 混合,感觉最好的方式还是看具体的业务场景配合了,架构嘛,要用有限的资源配合去最大程度地完成业务。建议先去看看docker带来的优点吧,以及为此优点需要付出的代价,才能更好地作出决策,不然乱用还不如不用。
当然是新拉一个node的容器下来跑了,所谓容器,不就是看重了轻量,低耦的好处嘛,为了实现松耦合,一般数据库、和服务器都会分2个容器来跑,把端口映射做好,甚至一个个docker都可以看成是一个个nb的可以跑各种服务应用的进程,而并不会占用太多资源,这也是docker的意义所在,易移植,体积小,松耦合。
前端的话无非就是 node gulp webpack yarn sass 等
node
gulp
webpack
yarn
sass
这里有现成的,web-dev-docker,我觉得你可以参考或者直接使用 。
这个Case....
一千个人眼中有一千个docker 环境。
看你怎么组网,怎么配合应用了。
1,像我个人,习惯待docker如进程process, 那么我会竭力追求一个容器实例只挂起一个进程,因为个人认为如果n个应用都跑在一个容器里,那这个容器就不是进程级别,而是OS/机器级别了,那么建虚拟机镜像好了,干吗还要搞docker镜像?。那即使是php和nginx这样的配合,也会搞起两个容器,可以把它看成一个应用,然后其它语言,像你用nodejs实现的其它应用,我肯定会再跑个容器实例,然后再跑个nginx反代这两个。所以想问你的nginx+php的docker是一个容器吗?
2,也有混多个进程在一个docker里,毕竟它还是基于From [OS] 一个操作系统的嘛。可以在docker里跑起个supervisor(python)这样的process monitor,将supervisor交给docker挂起,相同的应用不还有pm2(nodejs)?
这样的dockerfile不好写反正。
3, 混合,感觉最好的方式还是看具体的业务场景配合了,架构嘛,要用有限的资源配合去最大程度地完成业务。
建议先去看看docker带来的优点吧,以及为此优点需要付出的代价,才能更好地作出决策,不然乱用还不如不用。
当然是新拉一个node的容器下来跑了,所谓容器,不就是看重了轻量,低耦的好处嘛,为了实现松耦合,一般数据库、和服务器都会分2个容器来跑,把端口映射做好,甚至一个个docker都可以看成是一个个nb的可以跑各种服务应用的进程,而并不会占用太多资源,这也是docker的意义所在,易移植,体积小,松耦合。
前端的话无非就是
node
gulp
webpack
yarn
sass
等这里有现成的,web-dev-docker,我觉得你可以参考或者直接使用 。