在 Viget，Docker 已經(jīng)成為本地開發(fā)不可或缺的工具。我們的團(tuán)隊(duì)構(gòu)建和維護(hù)著大量的應(yīng)用程序，運(yùn)行著不同的軟件棧和版本，并且能夠?qū)㈤_發(fā)環(huán)境打包，這讓不同項(xiàng)目的切換和開發(fā)人員快速上手新項(xiàng)目變得非常容易。這并不是說(shuō)在本地使用 Docker 開發(fā)就沒(méi)有缺點(diǎn)，但它帶來(lái)的便利遠(yuǎn)遠(yuǎn)超過(guò)了缺點(diǎn)。

隨著時(shí)間的推移，我們總結(jié)出了自己的一套最佳實(shí)踐，可以有效設(shè)置 Docker 開發(fā)環(huán)境。請(qǐng)注意最后一點(diǎn)（“本地開發(fā)”）——如果你是為了部署而創(chuàng)建鏡像，那么這些原則中的大多數(shù)都不適用。我們的開發(fā)環(huán)境一般包括（通過(guò) Docker Compose 編配）：

• 應(yīng)用程序（例如 Rails、Django 或 Phoenix）；
• JavaScript 監(jiān)視器 / 編譯器（例如 webpack-dev-server）；
• 數(shù)據(jù)庫(kù)（通常是 PostgreSQL）；
• 其他必要的基礎(chǔ)設(shè)施（如 Redis、ElasticSearch、Mailhog）；
• 有些應(yīng)用程序?qū)嵗紶栆矔?huì)做一些其他的事情，而不只是運(yùn)行開發(fā)服務(wù)器（比如后臺(tái)任務(wù)）。

基于這樣的架構(gòu)，以下是我們?cè)噲D進(jìn)行標(biāo)準(zhǔn)化的最佳實(shí)踐。

1. 不要將代碼或應(yīng)用級(jí)的依賴項(xiàng)放入鏡像中

你的主 Dockerfile 文件，也就是運(yùn)行應(yīng)用程序所需的文件，應(yīng)該包含運(yùn)行應(yīng)用程序所需的所有軟件，但不應(yīng)該包含應(yīng)用程序代碼本身——當(dāng) docker-compose run 命令開始執(zhí)行時(shí)，它們將被掛載到容器中，并在容器和本地機(jī)器之間進(jìn)行同步。

另外，區(qū)分系統(tǒng)級(jí)依賴項(xiàng)（如 ImageMagick）和應(yīng)用級(jí)依賴項(xiàng)（如 Rubygems 和 NPM 包）也很重要——前者應(yīng)該包含在 Dockerfile 中，后者不應(yīng)該。將應(yīng)用級(jí)依賴項(xiàng)放到鏡像中意味著每次有人添加新依賴項(xiàng)時(shí)都必須重新構(gòu)建鏡像，這既耗時(shí)又容易出錯(cuò)。相反，我們應(yīng)該將這些依賴項(xiàng)作為啟動(dòng)腳本的一部分。

2. 非必要不使用 Dockerfile

基于第一點(diǎn)，你可能會(huì)發(fā)現(xiàn)根本不需要編寫 Dockerfile 文件。如果你的應(yīng)用程序沒(méi)有任何特殊的依賴項(xiàng)，可以將 docker-compose.yml 的入口指向官方的 Docker 倉(cāng)庫(kù)（如 ruby:2.7.6）。這樣做并不常見(jiàn)——大多數(shù)應(yīng)用程序和框架都需要一定數(shù)量的鏡像基礎(chǔ)（例如，Rails 需要 Node），但如果你發(fā)現(xiàn)自己的 Dockerfile 只包含一個(gè) FROM 行，你就可以不使用這個(gè)文件。

3. 只在 docker-compose.yml 中引用一次 Dockerfile

如果你將同一個(gè)鏡像用于多個(gè)服務(wù)（你應(yīng)該這么做），只需要在一個(gè)服務(wù)的定義中提供構(gòu)建說(shuō)明，給它起一個(gè)名字，然后在其他服務(wù)中引用這個(gè)名字。舉個(gè)例子，假設(shè)有個(gè) Rails 應(yīng)用程序使用一個(gè)共享的鏡像來(lái)運(yùn)行開發(fā)服務(wù)器和 webpack-dev-server，那么配置可能像這樣：

services:
 rails:
   image: appname_rails
   build:
     context: .
     dockerfile: ./.docker-config/rails/Dockerfile
   command: ./bin/rails server -p 3000 -b '0.0.0.0'
 node:
   image: appname_rails
   command: ./bin/webpack-dev-server

這樣，當(dāng)我們?cè)跇?gòu)建服務(wù)（使用 docker-compose）時(shí)，鏡像就只構(gòu)建一次。如果我們省略 image: 指令同時(shí)復(fù)制 build:，就會(huì)構(gòu)建完全相同的鏡像兩次，這樣會(huì)浪費(fèi)磁盤空間和有限的時(shí)間。

4. 在命名卷中緩存依賴項(xiàng)

正如第一點(diǎn)所提到的，我們不會(huì)將代碼依賴項(xiàng)放到鏡像中，而是在啟動(dòng)時(shí)安裝它們?？梢韵胂蟮氖?，如果我們每次重啟服務(wù)時(shí)都從頭開始安裝 gem/pip/yarn 這樣的庫(kù)，速度會(huì)非常慢，所以我們使用 Docker 的命名卷來(lái)保持緩存。上面的配置可能會(huì)變成這樣：

volumes:
 gems:
 yarn:
services:
 rails:
   image: appname_rails
   build:
     context: .
     dockerfile: ./.docker-config/rails/Dockerfile
   command: ./bin/rails server -p 3000 -b '0.0.0.0'
   volumes:
     - .:/app
     - gems:/usr/local/bundle
     - yarn:/app/node_modules
 node:
   image: appname_rails
   command: ./bin/webpack-dev-server
   volumes:
     - .:/app
     - yarn:/app/node_modules

命名卷的掛載點(diǎn)可能因不同的軟件棧而異，但原則是差不多的：將編譯后的依賴項(xiàng)保存在已命名的卷中，以大幅縮短啟動(dòng)時(shí)間。

5. 將臨時(shí)的東西放入命名卷中

上一點(diǎn)提到使用命名卷來(lái)提高性能，這里有另一個(gè)有用的技巧：將保存只讀文件的目錄放入命名卷中，阻止它們被同步回本地機(jī)器（這會(huì)帶來(lái)很大的性能開銷），特別是 log 和 tmp 目錄，以及應(yīng)用程序存儲(chǔ)上傳文件的地方。

根據(jù)經(jīng)驗(yàn)，如果一個(gè)目錄出現(xiàn)在.gitignore 中，那么最好把它放入命名卷中。

6. 在 apt-get 更新后進(jìn)行清理

如果在 Dockerfiles 中引用了基于 Debian 的鏡像，你就必須運(yùn)行 apt-get update，然后才能通過(guò) apt-get install 安裝依賴項(xiàng)。如果不做一些處理，一堆額外的數(shù)據(jù)會(huì)被放到鏡像中，極大增加了鏡像的體積。

我們的最佳實(shí)踐是在一個(gè) RUN 命令中執(zhí)行更新、安裝和清理操作：

RUN apt-get update && \
 apt-get install -y libgirepository1.0-dev libpoppler-glib-dev && \
 rm -rf /var/lib/apt/lists/*
7 使用 exec 而不是 run

如果需要在容器中運(yùn)行命令，你有兩個(gè)選項(xiàng)：run 和 exec。前者將啟動(dòng)一個(gè)新容器來(lái)運(yùn)行命令，而后者將連接到一個(gè)已經(jīng)在運(yùn)行中的容器。

在大多數(shù)情況下，假設(shè)在開發(fā)應(yīng)用程序時(shí)總是有其他服務(wù)在運(yùn)行，那么 exec（特別是 docker-compose exec）就是你所需要的，因?yàn)樗\(yùn)行起來(lái)更快，而且不會(huì)留下任何奇怪的文件（如果你忘了在 run 中包含 --rm 標(biāo)志，就會(huì)發(fā)生這種情況）。

8. 使用 wait-for-it 協(xié)調(diào)服務(wù)

如果使用了之前提到的共享鏡像和依賴項(xiàng)命名卷，你可能會(huì)遇到這樣的問(wèn)題：一個(gè)服務(wù)會(huì)在另一個(gè)服務(wù)的入口點(diǎn)腳本執(zhí)行完畢之前啟動(dòng)，從而導(dǎo)致發(fā)生了錯(cuò)誤。當(dāng)出現(xiàn)這種情況時(shí)，我們可以引入 wait-for-it 腳本，它將向一個(gè) Web 地址發(fā)起請(qǐng)求，當(dāng)這個(gè)地址返回響應(yīng)時(shí)再執(zhí)行命令。

所以，我們把 docker-compose.yml 修改一下：

volumes:
 gems:
 yarn:
services:
 rails:
   image: appname_rails
   build:
     context: .
     dockerfile: ./.docker-config/rails/Dockerfile
   command: ./bin/rails server -p 3000 -b '0.0.0.0'
   volumes:
     - .:/app
     - gems:/usr/local/bundle
     - yarn:/app/node_modules
 node:
   image: appname_rails
   command: [
     "./.docker-config/wait-for-it.sh",
     "rails:3000",
     "--timeout=0",
     "--",
     "./bin/webpack-dev-server"
   ]
   volumes:
     - .:/app
     - yarn:/app/node_modules

這樣，在 Rails 開發(fā)服務(wù)器完全啟動(dòng)并運(yùn)行之前，webpack-dev-server 是不會(huì)啟動(dòng)的。

以上就是我們?cè)谶^(guò)去幾年中總結(jié)的一些 Docker 最佳實(shí)踐，我們也將努力保持更新這個(gè)清單。