本篇文章是個經驗分享文,作者分享使用 Docker 作為開發環境時值得注意的 Best practices,透過這些經驗分享希望能夠讓開發者少走一些冤枉路。
原文提出了 15 個經驗談,這邊幫大家節錄幾個,有興趣的可以點選原文瞭解更多!
1. One thing at a time
2. Be ephemeral
3. Utilize .dockerignore
4. Less is more
5. Secrets should be secret
6. PID 1 is your birth right
7. Share and Care
8. Vulnerability Scan
9. Tag like you mean it
10. Permissions are costly
11. Source of Truth
12. Always official
13. Don’t include debug
14. Use entry point script smartly
15. Size does matter
One thing at a time
建置 Image 的時候專注做好一件事情,每個 Image 應該有一個專心要解決的問題,譬如一個應用程式,一個小工具等。對於 Nginx 這類型的 Image 來說,應該沒有人會期望於裡面看到有 Apache 的應用程式吧?
Be ephemeral
這個主要探討的是該 Image 本身建置時應該要以 stateless 的概念去處理,未來不論是透過 docker 或是 Kubernetes 來管理部署時,Contaienr 都很有機會被重啟,每次的重啟都意味該容器是重新啟動。所以千萬不要讓你的 Image 變成多次重啟會導致應用程式出問題的形式,任何的這類型資料應該都要透過外部取得,不要塞到你的 Image 內
Utilize .dockerignore
善用 .dockerignore 這個檔案來將不必要的檔案從 build 過程給排除,使用方法與 .gitignore 類似。透過這個檔案的設定可以避免 docker build 的時候不會把一些過大或是完全不需要的檔案都送給 docker daemon,不當浪費時間也浪費空間。
Less is more
避免安裝任何無關或是非必要的套件到你的 image 中,特別是那些 "nice to have" 的理由。
註: 我個人是滿討厭把 Image 弄得很乾淨的,除錯什麼工具都沒有,連 ash/sh/busybox/bash 都沒有的 image 更是我討厭中的排行榜冠軍
Secrets should be secret
任何機密資訊都應該要於運行期間動態載入,而不是建置期間塞入。請使用其他工具譬如 Vault 來管理這些機密資訊,並且執行期間讓 Container 能夠存取到正確的值。
PID 1 is your birth right
Linux 環境下會使用 SIGTERN, SIGKILL 等相關的 Singal 來戳你的應用程式,請確保你運行的應用程式要能夠攔截這些訊號來處理並完成有效的 Graceful shutdown.
Share and Care
如果環境中有多個 Image 彼此有共享相同的工具與功能,與其每個 Image 都單獨建置維護不如建置一個 Base Image,接者讓所有要使用的 image 去載入使用即可。
透過這種方式可以讓整體的維護性與管理性更為簡單,每個 image 可以減少重複的程式碼,同時要升級時只要針對 base Image 處理即可。
https://medium.com/pradpoddar/avoid-costly-mistakes-using-advanced-docker-development-best-practices-acd812784109
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
nginx apache同時 在 矽谷牛的耕田筆記 Facebook 的最佳解答
Service Mesh 這幾年的話題沒有停過,不論是 Linkerd, istio 或是其他解決方案都有各自的支持者。今天這篇文章是 Linkerd 官方文章,來跟大家解釋說明為什麼 Linkerd 沒有像其他解決方案一樣直接採用 Enovy 做為底層 proxy,而是要自行開發一個名為 Linkerd2-proxy 的取代方案
# 前提
1. Linkerd 是一個由工程團隊打造給工程團隊使用的產品,所有的決定都是基於工程方面的考量,而不是市場壓力
2. Envoy 很棒,但是對於 Linkerd 來說並沒有辦法透過 Envoy 打造一個簡單,輕量且安全的 Service Mesh 解決方案
3. 透過重新打造 Linkerd2-proxy,針對自己的需求重新設計才有機會讓 Linkerd 變得簡單且好用
# 想法
1. Linkerd2-proxy 是一個完全不考慮使用者面向的 Proxy 實作,跟 Envoy, Nginx 以及 Apache 這類型的實作是完全不同考慮。 Linkerd2-proxy 就是一個專門給 Linkerd 內部使用的
2. Envoy 超級彈性,同時是一個多用途的 Proxy,這種框架導致 Envoy 非常熱門,但帶來的就是其底層複雜。對於 Linked 來說需要的功能沒有這麼多。簡單來說就是殺雞焉用牛刀
3. 根據 Linkerd 內部的效能壓測,於 4,000 RPS(Request Per Second) 的前提下, Istio's Envoy 使用的 CPU 量相對於 Linkerd2-proxy 是 50% ~ 1000% 的增長,而 Memory 則是 1000%
4. Linkerd2-proxy 採用 Rust 開發,相對於 C++ 來說再安全性方面的開發會比較輕鬆一點,這個並不代表 Envoy 不安全,因為 Enovy 的社群龐大,CVE跟 bug 的修復也是很快。
# 其他
1. 相對於重新開發一個類似 Linkerd2-proxy 的專案,直接使用 Envoy 做為底層的 proxy 是非常簡單且省時的。並不是所有的 Service Mesh 解決方案都有足夠的能力與時間去開發屬於自己的 Proxy,因此整合 Enovy 並非錯誤
2. 目前使用 Linkerd 解決方案的使用者,其底層都是使用 Linkerd2-proxy
3. 其他的 Service Mesh 並不太能直接改採用 Linkerd2-proxy,畢竟其本身的設計就不是一個市場與使用者面向的專案。作者建議可以考慮使用 Rust 的 network library 來打造一個自己的方案
這篇文章並不是教你如何使用 Service Mesh,反而是分享更多一些設計上的哲學思考,個人覺得非常有趣,有興趣的可以點選下列連結觀看全文
https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/
nginx apache同時 在 企業號航行網誌 Facebook 的最佳解答
除咗 Easyengine 之外,仲有一個唔錯嘅 VPS Control Panel - VestaCP
雖然佢無 Easyengine 咁快,亦無 nginx redis cache 等
但係佢有 WebUI 嘅 CP,可以有 Apache - Nginx / Nginx - PHP-FPM 之間嘅選擇,對新手嚟講比較 user friendly
而且如果同時為幾個唔同嘅人 host 網站,呢個係設定上亦方便啲
最近佢做緊兩個收費 plugin 特價,一個係 Web File Management,另一個係 SFTP Chroot
lifetime 收費 30% off
有興趣可以睇下
coupon code - NY17TRNF
https://vestacp.com/