du -s ./* | sort -rn | more

?docker ps -q | xargs docker inspect --format '{{.State.Pid}}, {{.Id}}, {{.Name}}, {{.GraphDriver.Data.WorkDir}}' | grep bff25099a59b0fc8addd06f9223872f2904256f0432b3c3c47b58faef167115f

// 查看docker版本信息
docker version

// 搜索可用的鏡像
docker search mysql

//拉取鏡像-默認(rèn)是拉取的最新版本
docker pull mysql

//拉取鏡像-特定版本拉取(版本號(hào)一定要是官方放出的版本號(hào)，否則是查找不到的)
docker pull mysql:8.0.22

// 列舉本機(jī)所有鏡像
docker images -a

// 列出鏡像結(jié)果，并且只包含鏡像ID和倉(cāng)庫(kù)名
docker images --format "{{.ID}}: {{.Repository}}"

// 刪除鏡像('xxx'可以為鏡像id或鏡像REPOSITORY)
docker rmi xxx

// 保存對(duì)容器的修改（如安裝了ping）
參見(jiàn)https://www.docker.org.cn/book/docker/docer-save-changes-10.html
查看被修改的容器 ：docker ps -l
提交指定容器保存為新的鏡像： docker commit <container id> <new image name>

// 查看容器詳細(xì)信息
docker inspect xxx

// 查看所有容器
docker ps -a  
[or]
docker container ls -a

// 查看運(yùn)行中的容器
docker ps

// 刪除指定容器（Docker 會(huì)發(fā)送 SIGKILL 信號(hào)給容器。 加-f是刪除處于運(yùn)行中的容器）
docker rm -f xxx

// 查看docker容器日志
docker logs xxx

// 新建并啟動(dòng)容器
docker run

// docker run命令實(shí)用參數(shù)舉例
-d 讓docker處于后臺(tái)運(yùn)行
-P 容器內(nèi)部端口隨機(jī)映射到主機(jī)的端口
-p 容器內(nèi)部端口綁定到主機(jī)指定的端口（使用：docker run -d -p <主機(jī)端口>:<容器端口> ...）
--name 給容器起別名（使用：docker run -d -P --name <容器別名> <鏡像>）
-it 進(jìn)入交互式終端（這是兩個(gè)參數(shù)，一個(gè)是 -i 交互式操作，一個(gè)是 -t 終端。通常還會(huì)在鏡像名后跟一個(gè)命令，如我們希望有個(gè)交互式 Shell，因此在鏡像后會(huì)跟一個(gè) bash）
--rm 這個(gè)參數(shù)是說(shuō)容器退出后隨之將其刪除。
-v 添加數(shù)據(jù)卷（-v /my/own/datadir:/var/lib/mysql /my/own/datadir是主機(jī)的數(shù)據(jù)庫(kù)路徑 /var/lib/mysql是容器中的數(shù)據(jù)庫(kù)路徑）


// 查看指定容器的啟動(dòng)命令
docker ps -a --no-trunc | grep xxx
[or]
在docker inspect的Path參數(shù)也可見(jiàn)

// 查看容器端口綁定情況
docker port xxx

// 查看docker網(wǎng)絡(luò)
docker network ls

// 創(chuàng)建網(wǎng)絡(luò)
docker network create -d bridge test-net
(說(shuō)明：-d用于指定docker網(wǎng)絡(luò)類(lèi)型，分為bridge、overlay)

// 連接容器(運(yùn)行一個(gè)容器并連接到新建的 test-net 網(wǎng)絡(luò))
docker run -itd --name test1 --network test-net ubuntu /bin/bash
docker run -itd --name test2 --network test-net ubuntu /bin/bash
(而后，test1、test2容器間便可以互相ping通了)


// 進(jìn)入容器后，若發(fā)現(xiàn)有的命令不支持，如：ping www.baidu.com，提示：`bash: ping: command not found`
// 這時(shí)就需要手動(dòng)安裝對(duì)應(yīng)命令了。但執(zhí)行apt-get install ping時(shí)，又提示：`E: Unable to locate package ping`
// 解決方式：先執(zhí)行apt-get update，再執(zhí)行apt-get install ping即可


// 構(gòu)建鏡像
docker build -t xxx .

** Q：docker優(yōu)勢(shì) **

1、更高效的利用系統(tǒng)資源
由于容器不需要進(jìn)行硬件虛擬以及運(yùn)行完整操作系統(tǒng)等額外開(kāi)銷(xiāo)，Docker 對(duì)系統(tǒng)資源的利用率更高。
無(wú)論是應(yīng)用執(zhí)行速度、內(nèi)存損耗或者文件存儲(chǔ)速度，都要比傳統(tǒng)虛擬機(jī)技術(shù)更高效。
因此，相比虛擬機(jī)技術(shù)，一個(gè)相同配置的主機(jī)，往往可以運(yùn)行更多數(shù)量的應(yīng)用。

2、更快速的啟動(dòng)時(shí)間
Docker容器應(yīng)用，由于直接運(yùn)行于宿主內(nèi)核，無(wú)需啟動(dòng)完整的操作系統(tǒng)，
因此可以做到秒級(jí)、甚至毫秒級(jí)的啟動(dòng)時(shí)間。大大的節(jié)約了開(kāi)發(fā)、測(cè)試、部署的時(shí)間。

3、一致的運(yùn)行環(huán)境
開(kāi)發(fā)過(guò)程中一個(gè)常見(jiàn)的問(wèn)題是環(huán)境一致性問(wèn)題。
由于開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、生產(chǎn)環(huán)境不一致，導(dǎo)致有些 bug 并未在開(kāi)發(fā)過(guò)程中被發(fā)現(xiàn)。
而 Docker 的鏡像提供了除內(nèi)核外完整的運(yùn)行時(shí)環(huán)境，確保了應(yīng)用運(yùn)行環(huán)境一致性，
從而不會(huì)再出現(xiàn) “這段代碼在我機(jī)器上沒(méi)問(wèn)題啊” 這類(lèi)問(wèn)題。

4、持續(xù)交付和部署
對(duì)開(kāi)發(fā)和運(yùn)維（DevOps）人員來(lái)說(shuō)，最希望的就是一次創(chuàng)建或配置，可以在任意地方正常運(yùn)行。
使用 Docker 可以通過(guò)定制應(yīng)用鏡像來(lái)實(shí)現(xiàn)持續(xù)集成、持續(xù)交付、部署。
開(kāi)發(fā)人員可以通過(guò) Dockerfile 來(lái)進(jìn)行鏡像構(gòu)建，并結(jié)合 持續(xù)集成(Continuous Integration) 系統(tǒng)進(jìn)行集成測(cè)試，
而運(yùn)維人員則可以直接在生產(chǎn)環(huán)境中快速部署該鏡像，甚至結(jié)合 持續(xù)部署(Continuous Delivery/Deployment) 系統(tǒng)進(jìn)行自動(dòng)部署。

5、更輕松的遷移
由于 Docker 確保了執(zhí)行環(huán)境的一致性，使得應(yīng)用的遷移更加容易。
因此用戶(hù)可以很輕易的將在一個(gè)平臺(tái)上運(yùn)行的應(yīng)用，遷移到另一個(gè)平臺(tái)上，而不用擔(dān)心運(yùn)行環(huán)境的變化導(dǎo)致應(yīng)用無(wú)法正常運(yùn)行的情況。

6、更輕松的擴(kuò)展和維護(hù)
Docker 使用的分層存儲(chǔ)以及鏡像的技術(shù)，使得應(yīng)用重復(fù)部分的復(fù)用更為容易，
也使得應(yīng)用的維護(hù)更新更加簡(jiǎn)單，基于基礎(chǔ)鏡像進(jìn)一步擴(kuò)展鏡像也變得非常簡(jiǎn)單。

// docker commit 的語(yǔ)法格式為：
docker commit [選項(xiàng)] <容器ID或容器名> [<倉(cāng)庫(kù)名>[:<標(biāo)簽>]]
// 舉例
$ docker commit \
    --author "Tao Wang <twang2218@gmail.com>" \
    --message "修改了默認(rèn)網(wǎng)頁(yè)" \
    webserver \
    nginx:v2
// 查看鏡像的歷史版本提交信息
docker history nginx:v2

docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14

docker build http://server/context.tar.gz

// Dockerfile指令詳解
- FROM 指定基礎(chǔ)鏡像
所謂定制鏡像，那一定是以一個(gè)鏡像為基礎(chǔ)，在其上進(jìn)行定制。而 FROM 就是指定基礎(chǔ)鏡像。
因此一個(gè) Dockerfile 中 FROM 是必備的指令，并且必須是第一條指令。
(Docker 還存在一個(gè)特殊的鏡像，名為 scratch。這個(gè)鏡像是虛擬的概念，并不實(shí)際存在，它表示一個(gè)空白的鏡像。因此直接 FROM scratch 會(huì)讓鏡像體積更加小巧。
如果以 scratch 為基礎(chǔ)鏡像的話(huà)，意味著你不以任何鏡像為基礎(chǔ)，接下來(lái)所寫(xiě)的指令將作為鏡像第一層開(kāi)始存在。)

- RUN 執(zhí)行命令
其格式有兩種：
    1. shell 格式：RUN <命令>
    2. exec 格式：RUN ["可執(zhí)行文件", "參數(shù)1", "參數(shù)2"]
每一個(gè) RUN 都是啟動(dòng)一個(gè)容器、執(zhí)行命令、然后提交存儲(chǔ)層文件變更。
對(duì)于有多個(gè)命令的情況，建議將命令間用‘&&'連接，避免多層構(gòu)建鏡像。正確示例：
    RUN buildDeps='gcc libc6-dev make' \
        && apt-get update \
        && apt-get install -y $buildDeps

- COPY 復(fù)制文件
格式：
    COPY <源路徑>... <目標(biāo)路徑>
    COPY ["<源路徑1>",... "<目標(biāo)路徑>"]
COPY 指令將從構(gòu)建上下文目錄中 <源路徑> 的文件/目錄復(fù)制到新的一層的鏡像內(nèi)的 <目標(biāo)路徑> 位置。
比如：
    COPY package.json /usr/src/app/
    COPY hom* /mydir/
<源路徑> 可以是多個(gè)，甚至可以是通配符
<目標(biāo)路徑> 可以是容器內(nèi)的絕對(duì)路徑，也可以是相對(duì)于工作目錄的相對(duì)路徑（工作目錄可以用 WORKDIR 指令來(lái)指定）。
    目標(biāo)路徑不需要事先創(chuàng)建，如果目錄不存在會(huì)在復(fù)制文件前先行創(chuàng)建缺失目錄。

- ADD 更高級(jí)的復(fù)制文件
ADD 指令和 COPY 的格式和性質(zhì)基本一致，但也有所不同。
比如 <源路徑> 可以是一個(gè) URL，這種情況下，Docker 引擎會(huì)試圖去下載這個(gè)鏈接的文件放到 <目標(biāo)路徑> 去。
    下載后的文件權(quán)限自動(dòng)設(shè)置為 600，如果這并不是想要的權(quán)限，那么還需要增加額外的一層 RUN 進(jìn)行權(quán)限調(diào)整；
    另外，如果下載的是個(gè)壓縮包，需要解壓縮，也一樣還需要額外的一層 RUN 指令進(jìn)行解壓縮。
    所以不如直接使用 RUN 指令，然后使用 wget 或者 curl 工具下載，處理權(quán)限、解壓縮、然后清理無(wú)用文件更合理。
    因此，這個(gè)功能其實(shí)并不實(shí)用，而且不推薦使用。
如果 <源路徑> 為一個(gè) tar 壓縮文件的話(huà)，壓縮格式為 gzip, bzip2 以及 xz 的情況下，ADD 指令將會(huì)自動(dòng)解壓縮這個(gè)壓縮文件到 <目標(biāo)路徑> 去。
在 Docker 官方的最佳實(shí)踐文檔中要求，盡可能的使用 COPY，因?yàn)?COPY 的語(yǔ)義很明確，就是復(fù)制文件而已，而 ADD 則包含了更復(fù)雜的功能，其行為也不一定很清晰。
另外需要注意的是，ADD 指令會(huì)令鏡像構(gòu)建緩存失效，從而可能會(huì)令鏡像構(gòu)建變得比較緩慢。

- CMD 容器啟動(dòng)命令
CMD 指令的格式和 RUN 相似，也是兩種格式：
    shell 格式：CMD <命令>
    exec 格式：CMD ["可執(zhí)行文件", "參數(shù)1", "參數(shù)2"...]
Docker不是虛擬機(jī)，容器就是進(jìn)程。既然是進(jìn)程，那么在啟動(dòng)容器的時(shí)候，需要指定所運(yùn)行的程序及參數(shù)。
CMD 指令就是用于指定默認(rèn)的容器主進(jìn)程的啟動(dòng)命令的。
在指令格式上，一般推薦使用 exec 格式，這類(lèi)格式在解析時(shí)會(huì)被解析為 JSON 數(shù)組，因此一定要使用雙引號(hào) "，而不要使用單引號(hào)。
如果使用 shell 格式的話(huà)，實(shí)際的命令會(huì)被包裝為 sh -c 的參數(shù)的形式進(jìn)行執(zhí)行。比如：
    CMD echo $HOME
    在實(shí)際執(zhí)行中，會(huì)將其變更為：
    CMD [ "sh", "-c", "echo $HOME" ]
提到 CMD 就不得不提容器中應(yīng)用在前臺(tái)執(zhí)行和后臺(tái)執(zhí)行的問(wèn)題。
容器中的應(yīng)用都應(yīng)該以前臺(tái)執(zhí)行，而不是像虛擬機(jī)、物理機(jī)里面那樣，用 upstart/systemd 去啟動(dòng)后臺(tái)服務(wù)，容器內(nèi)沒(méi)有后臺(tái)服務(wù)的概念。
對(duì)于容器而言，其啟動(dòng)程序就是容器應(yīng)用進(jìn)程，容器就是為了主進(jìn)程而存在的，主進(jìn)程退出，容器就失去了存在的意義，從而退出，其它輔助進(jìn)程不是它需要關(guān)心的東西。
舉例：
    CMD service nginx start
    使用 service nginx start 命令，是希望以后臺(tái)守護(hù)進(jìn)程形式啟動(dòng) nginx 服務(wù)。
    而剛才說(shuō)了 CMD service nginx start 會(huì)被理解為 CMD [ "sh", "-c", "service nginx start"]，因此主進(jìn)程實(shí)際上是 sh。
    那么當(dāng) service nginx start 命令結(jié)束后，sh 也就結(jié)束了，sh 作為主進(jìn)程退出了，自然就會(huì)令容器退出。
    正確的做法是直接執(zhí)行 nginx 可執(zhí)行文件，并且要求以前臺(tái)形式運(yùn)行。比如：
        CMD ["nginx", "-g", "daemon off;"]

- ENTRYPOINT 入口點(diǎn)
ENTRYPOINT 的目的和 CMD 一樣，都是在指定容器啟動(dòng)程序及參數(shù)。ENTRYPOINT 在運(yùn)行時(shí)也可以替代，不過(guò)比 CMD 要略顯繁瑣，需要通過(guò) docker run 的參數(shù) --entrypoint 來(lái)指定。
當(dāng)指定了 ENTRYPOINT 后，CMD 的含義就發(fā)生了改變，不再是直接的運(yùn)行其命令，而是將 CMD 的內(nèi)容作為參數(shù)傳給 ENTRYPOINT 指令，換句話(huà)說(shuō)實(shí)際執(zhí)行時(shí)，將變?yōu)椋?
<ENTRYPOINT> "<CMD>"
其使用場(chǎng)景及好處參見(jiàn)：https://docs.kilvn.com/docker_practice/image/dockerfile/entrypoint.html

- ENV 設(shè)置環(huán)境變量
格式有兩種：
    ENV <key> <value>
    ENV <key1>=<value1> <key2>=<value2>...
這個(gè)指令很簡(jiǎn)單，就是設(shè)置環(huán)境變量而已。
環(huán)境變量可以使用的地方很多，很強(qiáng)大。通過(guò)環(huán)境變量，我們可以讓一份 Dockerfile 制作更多的鏡像，只需使用不同的環(huán)境變量即可。

- VOLUME 定義匿名卷
格式為：
    VOLUME ["<路徑1>", "<路徑2>"...]
    VOLUME <路徑>
之前我們說(shuō)過(guò)，容器運(yùn)行時(shí)應(yīng)該盡量保持容器存儲(chǔ)層不發(fā)生寫(xiě)操作，對(duì)于數(shù)據(jù)庫(kù)類(lèi)需要保存動(dòng)態(tài)數(shù)據(jù)的應(yīng)用，其數(shù)據(jù)庫(kù)文件應(yīng)該保存于卷(volume)中。
為了防止運(yùn)行時(shí)用戶(hù)忘記將動(dòng)態(tài)文件所保存目錄掛載為卷，在 Dockerfile 中，我們可以事先指定某些目錄掛載為匿名卷，
這樣在運(yùn)行時(shí)如果用戶(hù)不指定掛載，其應(yīng)用也可以正常運(yùn)行，不會(huì)向容器存儲(chǔ)層寫(xiě)入大量數(shù)據(jù)。
VOLUME /data 這里的 /data 目錄就會(huì)在運(yùn)行時(shí)自動(dòng)掛載為匿名卷，任何向 /data 中寫(xiě)入的信息都不會(huì)記錄進(jìn)容器存儲(chǔ)層，
從而保證了容器存儲(chǔ)層的無(wú)狀態(tài)化。當(dāng)然，運(yùn)行時(shí)可以覆蓋這個(gè)掛載設(shè)置。比如：
    docker run -d -v mydata:/data xxxx
    在這行命令中，就使用了 mydata 這個(gè)命名卷掛載到了 /data 這個(gè)位置，替代了 Dockerfile 中定義的匿名卷的掛載配置。

- EXPOSE 聲明端口
格式為 EXPOSE <端口1> [<端口2>...]
指令是聲明運(yùn)行時(shí)容器提供服務(wù)端口，這只是一個(gè)聲明，在運(yùn)行時(shí)并不會(huì)因?yàn)檫@個(gè)聲明應(yīng)用就會(huì)開(kāi)啟這個(gè)端口的服務(wù)。
在 Dockerfile 中寫(xiě)入這樣的聲明有兩個(gè)好處:
    一個(gè)是幫助鏡像使用者理解這個(gè)鏡像服務(wù)的守護(hù)端口，以方便配置映射；
    另一個(gè)用處則是在運(yùn)行時(shí)使用隨機(jī)端口映射時(shí)，也就是 docker run -P 時(shí)，會(huì)自動(dòng)隨機(jī)映射 EXPOSE 的端口。

- WORKDIR 指定工作目錄
格式為 WORKDIR <工作目錄路徑>
使用 WORKDIR 指令可以來(lái)指定工作目錄（或者稱(chēng)為當(dāng)前目錄），以后各層的當(dāng)前目錄就被改為指定的目錄，如該目錄不存在，WORKDIR 會(huì)幫你建立目錄。

- USER 指定當(dāng)前用戶(hù)
格式：USER <用戶(hù)名>
USER 指令和 WORKDIR 相似，都是改變環(huán)境狀態(tài)并影響以后的層。
    WORKDIR 是改變工作目錄，
    USER 則是改變之后層的執(zhí)行 RUN, CMD 以及 ENTRYPOINT 這類(lèi)命令的身份。

- HEALTHCHECK 健康檢查
格式：
    HEALTHCHECK [選項(xiàng)] CMD <命令>：設(shè)置檢查容器健康狀況的命令
    HEALTHCHECK NONE：如果基礎(chǔ)鏡像有健康檢查指令，使用這行可以屏蔽掉其健康檢查指令
HEALTHCHECK 指令是告訴 Docker 應(yīng)該如何進(jìn)行判斷容器的狀態(tài)是否正常，這是 Docker 1.12 引入的新指令。
自 1.12 之后，Docker 提供了 HEALTHCHECK 指令，通過(guò)該指令指定一行命令，用這行命令來(lái)判斷容器主進(jìn)程的服務(wù)狀態(tài)是否還正常，從而比較真實(shí)的反應(yīng)容器實(shí)際狀態(tài)。
    背景：
        在沒(méi)有 HEALTHCHECK 指令前，Docker 引擎只可以通過(guò)容器內(nèi)主進(jìn)程是否退出來(lái)判斷容器是否狀態(tài)異常。
        很多情況下這沒(méi)問(wèn)題，但是如果程序進(jìn)入死鎖狀態(tài)，或者死循環(huán)狀態(tài)，應(yīng)用進(jìn)程并不退出，但是該容器已經(jīng)無(wú)法提供服務(wù)了。
        在 1.12 以前，Docker 不會(huì)檢測(cè)到容器的這種狀態(tài)，從而不會(huì)重新調(diào)度，導(dǎo)致可能會(huì)有部分容器已經(jīng)無(wú)法提供服務(wù)了卻還在接受用戶(hù)請(qǐng)求。
當(dāng)在一個(gè)鏡像指定了 HEALTHCHECK 指令后，用其啟動(dòng)容器，初始狀態(tài)會(huì)為 starting，在 HEALTHCHECK 指令檢查成功后變?yōu)?healthy，如果連續(xù)一定次數(shù)失敗，則會(huì)變?yōu)?unhealthy。
HEALTHCHECK 支持下列選項(xiàng)：
    --interval=<間隔>：兩次健康檢查的間隔，默認(rèn)為 30 秒；
    --timeout=<時(shí)長(zhǎng)>：健康檢查命令運(yùn)行超時(shí)時(shí)間，如果超過(guò)這個(gè)時(shí)間，本次健康檢查就被視為失敗，默認(rèn) 30 秒；
    --retries=<次數(shù)>：當(dāng)連續(xù)失敗指定次數(shù)后，則將容器狀態(tài)視為 unhealthy，默認(rèn) 3 次。
和 CMD, ENTRYPOINT 一樣，HEALTHCHECK 只可以出現(xiàn)一次，如果寫(xiě)了多個(gè)，只有最后一個(gè)生效。
在 HEALTHCHECK [選項(xiàng)] CMD 后面的命令，格式和 ENTRYPOINT 一樣，分為 shell 格式，和 exec 格式。
  命令的返回值決定了該次健康檢查的成功與否：0：成功；1：失敗
舉例：
    假設(shè)我們有個(gè)鏡像是個(gè)最簡(jiǎn)單的 Web 服務(wù)，我們希望增加健康檢查來(lái)判斷其 Web 服務(wù)是否在正常工作，我們可以用 curl 來(lái)幫助判斷，其 Dockerfile 的 HEALTHCHECK 可以這么寫(xiě)：
    FROM nginx
    RUN apt-get update \
        && apt-get install -y curl \
        && rm -rf /var/lib/apt/lists/*
    HEALTHCHECK --interval=5s --timeout=3s \
        CMD curl -fs http://localhost/ || exit 1
    這里我們?cè)O(shè)置了每 5 秒檢查一次（這里為了試驗(yàn)所以間隔非常短，實(shí)際應(yīng)該相對(duì)較長(zhǎng)）,
    如果健康檢查命令超過(guò) 3 秒沒(méi)響應(yīng)就視為失敗，并且使用 curl -fs http://localhost/ || exit 1 作為健康檢查命令。

- ONBUILD 為他人做嫁衣裳
參見(jiàn)：https://docs.kilvn.com/docker_practice/image/dockerfile/onbuild.html

docker save mynginx | gzip > mynginx-latest.tar.gz

docker load -i mynginx-latest.tar.gz

docker save <鏡像名> | bzip2 | pv | ssh <用戶(hù)名>@<主機(jī)名> 'cat | docker load'

docker export myubuntu > myubuntu.tar

cat myubuntu.tar | docker import - myubuntu:v1.0