引言
因為Docker技術的火熱，因此在工作中我們經常會以容器的方式來運行一個應用。每當容器無法成功運行或者想要對容器中的應用參數、應用配置以及應用啟動進行深入研究時，當然希望能夠像在宿主機上調試程序一樣在容器中調試應用。容器的本質包括應用與應用運行所依賴的環境， 因此首先需要創建一個空殼容器（沒有運行應用的應用容器），然后進入容器中調試應用。此處的空殼容器提供了應用運行所需的環境，進而可方便的在其中調試應用。實踐環境：Centos7.2+Docker1.12.6。
容器啟動命令介紹
比較規范的鏡像的Dockerfile中通常會有ENTRYPOINT與CMD的定義（Docker官方推薦這樣做）。因此容器的啟動命令則為ENTRYPOINT所對應的腳本或可執行程序加上CMD中定義的內容。比如elasticsearch的Dockerfile定義的ENTRYPOINT與CMD分別為：ENTRYPOINT ["/docker-entrypoint.sh"] CMD ["elasticsearch"]，則創建的容器的啟動命令為：/docker-entrypoint.sh elasticsearch；mysql的Dockerfile：ENTRYPOINT ["docker-entrypoint.sh"] CMD ["mysqld"]，則創建的容器的啟動命令為：/docker-entrypoint.sh mysqld。所以想要知道一個容器的啟動命令需要首先了解其鏡像的Dockerfile中ENTRYPOINT與CMD的定義。如何查看一個鏡像的ENTRYPONT與CMD的值呢？一般采用如下兩種方式：
-
查看鏡像的Dockerfile
比如查看zookeeper的Dockerfile，先在Docker倉庫中找到zookeeper鏡像，然后找到特定版本的Dockerfile
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["zkServer.sh", "start-foreground"]
-
通過 docker history 或 docker inspect 命令查看
比如查看prom/prometheus:v1.8.0鏡像的ENTRYPOINT與CMD信息
docker history --no-trunc prom/prometheus:v1.8.0(--no-trunc表示完整輸出)
上圖僅展示一部分內容，可知prom/prometheus:v1.8.0鏡像的ENTRYPOINT為：/bin/prometheus，CMD為：
"-config.file=/etc/prometheus/prometheus.yml"
"-storage.local.path=/prometheus"
"-web.console.libraries=/usr/share/prometheus/console_libraries"
"-web.console.templates=/usr/share/prometheus/consoles"docker inspect prom/prometheus:v1.8.0
上圖僅展示一部分內容，也可知prom/prometheus:v1.8.0鏡像的ENTRYPOINT為：/bin/prometheus，
CMD為："-config.file=/etc/prometheus/prometheus.yml",
"-storage.local.path=/prometheus",
"-web.console.libraries=/usr/share/prometheus/console_libraries",
"-web.console.templates=/usr/share/prometheus/consoles"
上述第一種方式適用于比較規范的鏡像，這類鏡像通常會提供清晰、具體的Dockerfile。第二種方式適用于各種鏡像，盡管是不規范的鏡像。通過history、inspect兩個命令的任一個均可快速、方便的查看鏡像的ENTRYPOINT與CMD的值。
不同類型鏡像的調試舉例
如果不作額外的設置，容器的啟動命令則是鏡像的ENTRYPOINT+CMD的方式。比如：
若要調試容器中的應用程序，則需額外的設置實現。docker run命令提供的--entrypoint參數能夠覆蓋Dockerfile中默認定義的ENTRYPOINT；docker run [OPTIONS] IMAGE [COMMAND] [ARG...]的COMMAND能夠替換Dockerfile中定義的CMD。通過上面的示例可以發現，有的鏡像的Dockerfile中ENTRYPOINT值為:/docker-entrypoint.sh，CMD為應用的可執行程序；有的鏡像的Dockerfile中ENTRYPOINT值為應用的可執行程序，CMD為可執行程序的參數。因此針對不同的鏡像想要創建空殼容器其方式是不同的。
-
Dockerfile的ENTRYPOINT為/docker-entrypoint.sh，CMD為應用的可執行程序
通常比較正式的官方鏡像均會提供docker-entrypoint.sh腳本作為ENTRYPOINT，docker-entrypoint.sh腳本一般能夠接收類似bash、sh的參數，因此對于這類鏡像可以指定容器的COMMAND覆蓋應用的二進制程序創建空殼容器。這里以elasticsearch:5.0.2鏡像為例創建空殼容器es：
查看空殼容器es中運行的進程：
docker run -itd --name es --network host elasticsearch:5.0.2 bash(alpine系統指定sh，非alpine系統可以指定bash or sh)可見，es容器中運行的進程變為bash，并不是elasticsearch應用；此時es就為空殼容器，進入es容器調試elasticsearch應用就像在宿主機上調試程序
進入es容器：es容器中調試elasticsearch應用程序：運行elasticsearch應用程序： -
Dockerfile的ENTRYPOINT為應用的可執行程序，CMD為可執行程序的參數
這類鏡像不能再簡單的通過覆蓋鏡像的CMD來創建空殼容器了，因為docker run 的COMMAND是作為ENTRYPOINT指定的二進制程序的參數傳入的，所以簡單的指定COMMAND為bash或sh多數情況下是不行的，最好的方式是通過docker run的--entrypoint參數來覆蓋鏡像中指定的二進制可執行程序，使得創建的容器其內部的進程為entrypoint參數指定的bash or sh。這里以google/cadvisor:v0.27.2鏡像（ENTRYPOINT: /usr/bin/cadvisor -logtostderr, CMD: null）為例創建空殼容器cadvisor：
查看cadvisor容器的進程：
docker run -itd --name cadvisor --network host --entrypoint sh -v /var/lib/docker:/var/lib/docker:ro google/cadvisor:v0.27.2進入cadvisor容器內調試應用：運行cadvisor應用程序：通過指定docker run的COMMAND為sh看能否成功創建空殼容器：可見，這種方式不能成功創建空殼容器
上面是對兩種類型的ENTRYPOINT創建空殼容器的舉例說明，其實也可以對ENTRYPOINT不加以區分，即均通過docker run 的--entrypoint參數覆蓋鏡像中的ENTRYPOINT創建空殼容器。比如示例1中的elasticsearch:5.0.2鏡像，指定--entrypoint bash創建空殼容器：
總結
容器其實是應用與應用運行所依賴的環境，創建空殼容器即提供了應用所需要的環境，進入此環境中可以調試應用，可以驗證應用的各個參數，同樣更可以像在宿主機中運行程序一樣在此環境中運行應用，區別僅是容器與宿主機的兩個環境。上面是對如何在容器中調試應用程序做的一些記錄，希望與大家一起討論、交流，一起學習。
