### ONBUILD 為他人做嫁衣裳
格式:`ONBUILD <其它指令>`。
`ONBUILD` 是一個特殊的指令,它后面跟的是其它指令,比如 `RUN`, `COPY` 等,而這些指令,在當前鏡像構建時并不會被執行。只有當以當前鏡像為基礎鏡像,去構建下一級鏡像的時候才會被執行。
`Dockerfile` 中的其它指令都是為了定制當前鏡像而準備的,唯有 `ONBUILD` 是為了幫助別人定制自己而準備的。
假設我們要制作 Node.js 所寫的應用的鏡像。我們都知道 Node.js 使用 `npm` 進行包管理,所有依賴、配置、啟動信息等會放到 `package.json` 文件里。在拿到程序代碼后,需要先進行 `npm install` 才可以獲得所有需要的依賴。然后就可以通過 `npm start` 來啟動應用。因此,一般來說會這樣寫 `Dockerfile`:
```Dockerfile
FROM node:slim
RUN mkdir /app
WORKDIR /app
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
CMD [ "npm", "start" ]
```
把這個 `Dockerfile` 放到 Node.js 項目的根目錄,構建好鏡像后,就可以直接拿來啟動容器運行。但是如果我們還有第二個 Node.js 項目也差不多呢?好吧,那就再把這個 `Dockerfile` 復制到第二個項目里。那如果有第三個項目呢?再復制么?文件的副本越多,版本控制就越困難,讓我們繼續看這樣的場景維護的問題。
如果第一個 Node.js 項目在開發過程中,發現這個 `Dockerfile` 里存在問題,比如敲錯字了、或者需要安裝額外的包,然后開發人員修復了這個 `Dockerfile`,再次構建,問題解決。第一個項目沒問題了,但是第二個項目呢?雖然最初 `Dockerfile` 是復制、粘貼自第一個項目的,但是并不會因為第一個項目修復了他們的 `Dockerfile`,而第二個項目的 `Dockerfile` 就會被自動修復。
那么我們可不可以做一個基礎鏡像,然后各個項目使用這個基礎鏡像呢?這樣基礎鏡像更新,各個項目不用同步 `Dockerfile` 的變化,重新構建后就繼承了基礎鏡像的更新?好吧,可以,讓我們看看這樣的結果。那么上面的這個 `Dockerfile` 就會變為:
```Dockerfile
FROM node:slim
RUN mkdir /app
WORKDIR /app
CMD [ "npm", "start" ]
```
這里我們把項目相關的構建指令拿出來,放到子項目里去。假設這個基礎鏡像的名字為 `my-node` 的話,各個項目內的自己的 `Dockerfile` 就變為:
```Dockerfile
FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
```
基礎鏡像變化后,各個項目都用這個 `Dockerfile` 重新構建鏡像,會繼承基礎鏡像的更新。
那么,問題解決了么?沒有。準確說,只解決了一半。如果這個 `Dockerfile` 里面有些東西需要調整呢?比如 `npm install` 都需要加一些參數,那怎么辦?這一行 `RUN` 是不可能放入基礎鏡像的,因為涉及到了當前項目的 `./package.json`,難道又要一個個修改么?所以說,這樣制作基礎鏡像,只解決了原來的 `Dockerfile` 的前4條指令的變化問題,而后面三條指令的變化則完全沒辦法處理。
`ONBUILD` 可以解決這個問題。讓我們用 `ONBUILD` 重新寫一下基礎鏡像的 `Dockerfile`:
```Dockerfile
FROM node:slim
RUN mkdir /app
WORKDIR /app
ONBUILD COPY ./package.json /app
ONBUILD RUN [ "npm", "install" ]
ONBUILD COPY . /app/
CMD [ "npm", "start" ]
```
這次我們回到原始的 `Dockerfile`,但是這次將項目相關的指令加上 `ONBUILD`,這樣在構建基礎鏡像的時候,這三行并不會被執行。然后各個項目的 `Dockerfile` 就變成了簡單地:
```Dockerfile
FROM my-node
```
是的,只有這么一行。當在各個項目目錄中,用這個只有一行的 `Dockerfile` 構建鏡像時,之前基礎鏡像的那三行 `ONBUILD` 就會開始執行,成功的將當前項目的代碼復制進鏡像、并且針對本項目執行 `npm install`,生成應用鏡像。
- 前言
- 修訂記錄
- 如何貢獻
- Docker 簡介
- 什么是 Docker
- 為什么要用 Docker
- 基本概念
- 鏡像
- 容器
- 倉庫
- 安裝 Docker
- Ubuntu
- Debian
- CentOS
- Raspberry Pi
- macOS
- Windows PC
- 鏡像加速器
- 使用鏡像
- 獲取鏡像
- 列出鏡像
- 刪除本地鏡像
- 利用 commit 理解鏡像構成
- 使用 Dockerfile 定制鏡像
- Dockerfile 指令詳解
- COPY 復制文件
- ADD 更高級的復制文件
- CMD 容器啟動命令
- ENTRYPOINT 入口點
- ENV 設置環境變量
- ARG 構建參數
- VOLUME 定義匿名卷
- EXPOSE 暴露端口
- WORKDIR 指定工作目錄
- USER 指定當前用戶
- HEALTHCHECK 健康檢查
- ONBUILD 為他人作嫁衣裳
- 參考文檔
- Dockerfile 多階段構建
- 其它制作鏡像的方式
- 實現原理
- 操作容器
- 啟動
- 守護態運行
- 終止
- 進入容器
- 導出和導入
- 刪除
- 訪問倉庫
- Docker Hub
- 私有倉庫
- 私有倉庫高級配置
- Nexus 3
- 數據管理
- 數據卷
- 掛載主機目錄
- 使用網絡
- 外部訪問容器
- 容器互聯
- 配置 DNS
- 高級網絡配置
- 快速配置指南
- 容器訪問控制
- 端口映射實現
- 配置 docker0 網橋
- 自定義網橋
- 工具和示例
- 編輯網絡配置文件
- 實例:創建一個點到點連接
- Docker 三劍客之 Compose 項目
- 簡介
- 安裝與卸載
- 使用
- 命令說明
- Compose 模板文件
- 實戰 Django
- 實戰 Rails
- 實戰 WordPress
- Docker 三劍客之 Machine 項目
- 安裝
- 使用
- Docker 三劍客之 Docker Swarm
- Swarm mode
- 基本概念
- 創建 Swarm 集群
- 部署服務
- 使用 compose 文件
- 管理敏感數據
- 管理配置信息
- 滾動升級
- 安全
- 內核命名空間
- 控制組
- 服務端防護
- 內核能力機制
- 其它安全特性
- 總結
- 底層實現
- 基本架構
- 命名空間
- 控制組
- 聯合文件系統
- 容器格式
- 網絡
- Etcd 項目
- 簡介
- 安裝
- 集群
- 使用 etcdctl
- CoreOS 項目
- 簡介
- 工具
- 快速搭建 CoreOS 集群
- Kubernetes 項目
- 簡介
- 快速上手
- 基本概念
- kubectl 使用
- 架構設計
- Mesos - 優秀的集群資源調度平臺
- Mesos 簡介
- 安裝與使用
- 原理與架構
- Mesos 配置項解析
- 日志與監控
- 常見應用框架
- 本章小結
- 容器與云計算
- 簡介
- 亞馬遜云
- 騰訊云
- 阿里云
- 小結
- 實戰案例-操作系統
- Busybox
- Alpine
- Debian Ubuntu
- CentOS Fedora
- 本章小結
- 實戰案例-CI/CD
- Drone
- Docker 開源項目
- LinuxKit
- 附錄
- 附錄一:常見問題總結
- 附錄二:熱門鏡像介紹
- Ubuntu
- CentOS
- MySQL
- MongoDB
- Redis
- Nginx
- WordPress
- Node.js
- 附錄三:Docker 命令查詢
- 附錄四:Dockerfile 最佳實踐
- 附錄五:資源鏈接
- 附錄六:Docker 中文資源