本篇文章是個經驗分享文,作者分享使用 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
重啟apache 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
本篇文章是個經驗分享系列文,作者探討 Kubernetes 內 15 種不被建議的部署策略與模式。
作者之前曾經撰寫過 Contianer 架構底下的部署模式探討,而本系列文(三篇)則是著重於如何將這些 containers 透過 Kubernetes 給部署到生產環境,總共會探討十五種不推薦的模式,接下來的三篇文章將會介紹各五種不好的模式。
Using containers with the latest tag in Kubernetes deployments
任何 container 的 image 都不應該使用 latest,因為 latest 本身沒有任何意義,這會使得維運人員沒有辦法掌握到底當前部署的版本是什麼,更嚴重的情況適當 latest 搭配 PullPolicy:Always 時會產生更為嚴重的問題。因為 Always 的策略導致每次 Pod 部署時都會重新抓取 image,所以一個 deployment 中,多個使用 latest tag 的 Pod 但是其實使用的 image hash 是不同的。
作者認為比較好的做法有
1. 所有 container image 都是不可修改的,一旦建立就禁止覆蓋,有任何改動就進版
2. 部署用的 image tag 使用有意義的版本名稱
補充: 實際上 pull image 也可以使用 sha256,譬如 "docker pull hwchiu/kubectl-tools@sha256:acfb56059e6d60bf4a57946663d16dda89e12bfb1f8d7556f277e2818680e4c8"
Baking the configuration inside container images
任何 contaienr image 建置的時候應該都要往通用的方向去設計,而不是參雜各種設定在裡面。著名的 12-factor app 裡面也有提到類似個概念,建置好的 image 應該要可以 build once, run everywhere,動態的方式傳入不同的設定檔案,而不是把任何跟環境有關的資訊都寫死
舉例來說,如果 image 內包含了下列設定(舉例,包含不限於)
1. 任何 IP 地址
2. 任何帳號密碼
3. 任何寫死的 URL
作者認為比較好的做法有
1. 透過動態載入的方式來設定運行時的設定,譬如Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper 等
2. 根據不同程式語言與框架甚至可以做到不需要重啟容器就可以載入新的設定
Coupling applications with Kubernetes features/services for no reason
作者認為除了很明確專門針對 Kubernetes 使用,或是用來控制 Kubernetes 的應用程式外,大部分的 應用程式包裝成 Container 時就不應該假設只能運行在 Kubernetes 內。作者列舉了幾個常見的使用範例,譬如
1. 從 K8s label/annotation 取得資訊
2. 查詢當前 Pod 運行的資訊
3. 呼叫其他 Kubernetes 服務(舉例,假設環境已經存在 Vault,因此直接呼叫 vault API 來取得資訊)
作者認為這類型的綁定都會使得該應用程式無法於沒有 Kubernetes 的環境運行,譬如就沒有辦法使用 Docker-compose 來進行本地開發與測試,這樣就沒有辦法滿足 12-factor 中的精神。
對於大部分的應用程式測試,除非其中有任何依賴性的服務是跟外部 Kubernetes 綁定,否則這些測試應該都要可以用 docker-compose 來叫起整個服務進行測試與處理。
服務需要使用的資訊應該是運行期間透過設定檔案,環境變數等塞入到 Container 內,這樣也呼應上述的不要將與環境有關的任何資訊都放入 image 內。
Mixing application deployment with infrastructure deployment (e.g. having
Terraform deploying apps with the Helm provider)
作者認為近年來伴隨者 IaC 概念的熱門,愈來愈多的團隊透過 Terraform/Pulumi 這類型的工具來部署架構,作者認為將部署架構與部署應用程式放到相同一個 Pipeline 則是一個非常不好的做法。
將基礎架構與應用程式同時放在相同 pipeline 可以降低彼此傳遞資訊的困難性,能夠一次部署就搞定全部,然而這種架構帶來的壞處有
1. 通常應用程式改動的頻率是遠大於基礎架構的改變,因此兩者綁在一起會浪費許多時間在架構上
假如部署基礎架構需要 25 分鐘而應用
https://codefresh.io/kubernete.../kubernetes-antipatterns-1/
重啟apache 在 2 * * * service httpd restart #每隔两小时重启apache 这条是有 ... 的推薦與評價
有一条是有问题的:* */2 * * * service httpd restart #每隔两小时重启apache 这条的效果是每分钟都会执行正确的应该是0 */2 * * * service httpd ... ... <看更多>