Autocruise

Dockerfile 看似簡單，幾行 FROM、RUN、COPY 就能把應用打包成 image，但寫得好不好，直接牽動 build 速度、image 大小、安全性與日後的可維護性。本文整理幾個實務中最常用、卻也最常被忽略的 Dockerfile 撰寫訣竅。 （一）善用 layer cache　，　指令由　變動較少　排到　容易變化　（由上到下） Docker build 是逐層（layer）快取的,只要某一層的指令或內容改變,該層之後的所有 layer 都會失效重建。因此在Dockerfile內容中，指令順序（由上到下）應該從「變動頻率低」排到「變動頻率高」。最典型的例子，是先複製相依清單、安裝套件，最後才複製原始碼： # 先處理相依,讓 cache 命中率最大化 COPY package.json package-lock.json ./ RUN npm ci COPY . . 如此一來,只要原始碼變動、相依沒變, npm ci 這一層就能命中 cache,不必重跑。 （二）用 multi-stage build 縮小 image 把「編譯環境」與「執行環境」分開，只把最終產物帶進 runtime image，可大幅縮小體積，也降低受攻擊面（attack surface）: FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN go build -o server . FROM alpine:3.20 COPY --from=builder /app/server /server ENTRYPOINT ["/server"] runtime image 不再包含 compiler 與原始碼,從數百 MB 降到數十 MB 是常態。 （三）合併 RUN 並在同一層清理 cache 每一個 RUN 都是一層。把相關指令用 && 串接成一層,並在同一層清掉套件快取,避免多餘體積殘留在 image 裡: RUN apk add --no-cache curl \ && rm -rf /var/cache/apk/* Debian/Ubuntu 則常見 apt-get install 之後接 rm -rf /var/l...

這篇文章記錄關於 Windows container 運行時會出現的問題。是一個典型的  ASP.NET 應用程式，在編寫 Dockerfile 建置出 image 過程沒有問題。但是在用 docker run 運行此 image 的時候，出現如下圖內容 2 行 錯誤訊息， (註: quesry 應是錯字，正確拼法是 query) ERROR: Failed to stop or quesry status of service 'w3svc' error failed to resize tty, using default size 且 container 在系統上無法建立，應用程式無法運行， 這樣的錯誤並不是每次都發生，有時候會發生錯誤， 運行環境： Windows Server 2016 環境下， （10.0.14393） Docker engine  版本 18.09.8 (1) 關於錯誤訊息, “failed to resize tty, using default size ” 後來發現修改其 Dockerfile 內容中有關 COPY 指令的形式可以解決這部分。 原本是在 Dockerfile 用如下 COPY 形式 COPY ["<src>", "<dest>"] 改爲下列這種形式 COPY <src> <dest> 就不會有 “failed to resize tty ... ” 錯誤訊息。 (2) 關於錯誤訊息, "ERROR: Failed to stop or quesry status of service 'w3svc' error" 目前爲止尚未確定。目前看到的問題可能是由於重複建立使用同一個 container 名字所導致，可以在運行時嘗試建立用不同的 container 名字，並且定期用 docker container prune 清理未在運行狀態的 container。 [參考資料] https://docs.docker.com/engine/reference/builder/#copy

關於 Docker 環境下的 Proxy 配置，需要先根據問題具體情況分辨配置方法，有兩種：一個是 docker daemon 的配置，這主要是為了能讓 docker host 通過 proxy server 使用 docker pull/docker run 存取遠端 registry；另一個是 docker client 為了建置 image 或運行 container 的時候所需要的網路配置。 首先快速回顧一下 Linux 作業系統中命令行環境的 proxy 配置方法，以 CentOS 系統環境為例，假設一台 HTTPS proxy server 位在 192.168.1.34 而且 port 是 3128： # environment variables for https proxy # export https_proxy="https://192.168.1.34:3128/" 如果 Proxy server 需要輸入帳號密碼，則用下面這樣的形式 # Https proxy with authentication # export https_proxy="https://username:password@192.168.1.34:3128/" 之後 ping 8.8.8.8 看看Internet是否有連通，可以的話就可在 shell 環境下使用軟體包管理器像是 yum, apt-get 等等，安裝新的軟體，但是，同樣的作業系統環境變數設定對於 Docker 引擎不起作用。 Docker 環境下的 Proxy 配置，根據問題具體情況分為 docker daemon 以及 docker client 的配置，下面分別詳細說明。以下方法可適用在 Docker CE 或 Docker EE 17.06 以上的版本。 （一）Docker daemon 的 proxy 配置 如果 Docker host 處於 air-gapped 的環境下，需要先配置 proxy 才能連到 Internet，否則直接用 docker pull 或相關的命令從遠端 registry 來存取 docker images 會遭遇失敗。 以 CentOS，RedHat, Debian, Ub...