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

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

• 應(yīng)用程序（例如 Rails、Django 或 Phoenix）；
• JavaScript 監(jiān)視器 / 編譯器（例如 webpack-dev-server）；
• 數(shù)據(jù)庫（通常是 PostgreSQL）；
• 其他必要的基礎(chǔ)設(shè)施（如 Redis、ElasticSearch、Mailhog）；
• 有些應(yīng)用程序?qū)嵗紶栆矔鲆恍┢渌氖虑椋恢皇沁\(yùn)行開發(fā)服務(wù)器（比如后臺任務(wù)）。

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

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

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

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

2. 非必要不使用 Dockerfile

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

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

如果你將同一個鏡像用于多個服務(wù)（你應(yīng)該這么做），只需要在一個服務(wù)的定義中提供構(gòu)建說明，給它起一個名字，然后在其他服務(wù)中引用這個名字。舉個例子，假設(shè)有個 Rails 應(yīng)用程序使用一個共享的鏡像來運(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)我們在構(gòu)建服務(wù)（使用 docker-compose）時，鏡像就只構(gòu)建一次。如果我們省略 image: 指令同時復(fù)制 build:，就會構(gòu)建完全相同的鏡像兩次，這樣會浪費(fèi)磁盤空間和有限的時間。

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

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

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)保存在已命名的卷中，以大幅縮短啟動時間。

5. 將臨時的東西放入命名卷中

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

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

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

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

我們的最佳實(shí)踐是在一個 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)行命令，你有兩個選項(xiàng)：run 和 exec。前者將啟動一個新容器來運(yùn)行命令，而后者將連接到一個已經(jīng)在運(yùn)行中的容器。

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

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

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

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