Docker 是部署 Web 應用程式的絕佳工具,但前提是您按照預期方式使用它。搬石頭砸自己腳的可能性很高。因此,如果您想避免痛苦的除錯時間,請確保避免這些常見錯誤。
附註:如果您想讓您的生活更輕鬆一點,請查看sliplane.io 。這是一個簡單的 Docker 託管解決方案,可幫助您避免此處提到的一些陷阱。
如果您在一台伺服器上執行多容器設置,這一點尤其重要。貪婪的服務可以搶佔機器上的所有 CPU 或內存,使其他容器沒有資源可使用,或者更糟的情況:凍結整個伺服器。
使用--cpu-quota
和--memory
標誌來限制執行時容器的資源使用:
docker run --memory="512m" --cpu-quota=50000 your-image-name
您可以在有關資源限制的 Docker 官方文件中找到有關這些標誌的更多資訊。
如果可以,請避免在執行容器的相同伺服器上建置映像。建置可能會佔用大量 CPU 和內存,如果您不考慮這一點,您的伺服器崩潰的速度將比您說“請不要崩潰!😰”更快。
沒有人喜歡清理,但如果你不想被自己的💩淹沒,這是一項必要的任務。 Docker 映像可能很大——有時有千兆位元組大小。如果您部署了映像的新版本並且不再需要舊版本,則應該刪除它們。未使用的容器和磁碟區也是如此。它們加起來很快,您的部署很快就會失敗,您又花了 45 分鐘,直到您發現您的磁碟已滿...
使用以下命令刪除懸空(未標記、未使用)的 Docker 物件:
docker container prune
docker image prune
docker volume prune
docker system prune # this removes all dangling images, volumes and containers
透過新增-a
arg 刪除所有未使用的 Docker 物件(也包括標記的映像):
docker container prune -a
docker image prune -a
docker volume prune -a
docker system prune -a # this removes all unused images, volumes and containers
應用程式在建置時需要存取機密的情況並不罕見。人們沒有意識到的是,在建置時以秘密方式烘焙的圖像需要被視為秘密! Docker 映像不是保管庫。所有有權存取該圖像的人都可以讀取您放入其中的所有內容。 (除非你做一些瘋狂的事情並對其進行加密)。因此,如果您將秘密寫入其中,切勿在 Docker Hub 上發布映像!
如果可以,請避免在建置時傳遞機密,並依賴環境變數或使用機密管理器。如果根本不可能,請確保僅在受信任的環境中建立映像,將其保存在私有註冊表中,僅透過加密線路移動它,並在不再需要它時立即修剪它...
另請參閱這篇關於處理建置秘密的方法的部落格文章。
容器是隔離的、短暫的,這對於安全性和可移植性來說非常好,但對於監控來說並不理想。
每次要檢查日誌檔案時都必須在容器中執行docker exec
確實很痛苦,因此請務必提前做好準備。
首先,您可以做的最簡單的事情是安裝一個磁碟區來保存日誌文件,以便它們至少是持久的。但是,如果沒有日誌輪換,並且最好沒有某種方式來搜尋適當的日誌,這種設定很快就會達到極限。
為了獲得更多可見性,您可以透過將資料串流傳輸到外部系統來實現日誌監控,並設定資源監控工具來追蹤容器中的 CPU 和記憶體使用情況。
在專業環境中,監視器通常使用ELK Stack來完成。
如前所述,Docker 映像可能很大(高達幾 GB!)。我想在這裡提到的最後一個錯誤是沒有優化你的 Docker 映像。它不僅可以節省大量空間,還可以減少攻擊面並使您的部署速度更快。
以最小化 Nuxt 3 的 Docker 映像為例。作者Jonas Scholz設法將圖片大小從 1.4 GB 減小到僅 160 MB!只需執行幾個簡單的步驟,即可實現近 10 倍的改進:
使用盡可能小的基礎圖像
排除 .dockerignore 檔案中不必要的文件
從 CDN 提供靜態資產
使用多階段建置
常見的 Docker 部署錯誤包括:
跳過資源限制,
未能清理乾淨,
將敏感資料建置到您的圖像中,
忽視日誌記錄和監控
錯過了優化圖像的機會。
如果您想讓您的生活更輕鬆一點,請查看sliplane.io 。這是一個簡單的 Docker 託管解決方案,可幫助您避免此處提到的一些陷阱。
免責聲明:我共同創立了 Sliplane :-)