84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
後端的 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,我覺得你可以參考或直接使用 。