Baohua Yang
GitHub
commit
8d240b84bb
|
|
@ -1,36 +1,36 @@
|
|||
## 如何贡献项目
|
||||
|
||||
* 领取或创建新的 [Issue](https://github.com/yeasy/docker_practice/issues)，如 [issue 235](https://github.com/yeasy/docker_practice/issues/235)，添加自己为 `Assignee`。
|
||||
领取或创建新的 [Issue](https://github.com/yeasy/docker_practice/issues)，如 [issue 235](https://github.com/yeasy/docker_practice/issues/235)，添加自己为 `Assignee`。
|
||||
|
||||
* 在 [GitHub](https://github.com/yeasy/docker_practice/fork) 上 `fork` 到自己的仓库，如 `docker_user/docker_practice`，然后 `clone` 到本地，并设置用户信息。
|
||||
在 [GitHub](https://github.com/yeasy/docker_practice/fork) 上 `fork` 到自己的仓库，如 `docker_user/docker_practice`，然后 `clone` 到本地，并设置用户信息。
|
||||
|
||||
```bash
|
||||
$ git clone git@github.com:docker_user/docker_practice.git
|
||||
$ cd docker_practice
|
||||
$ git config user.name "yourname"
|
||||
$ git config user.email "your email"
|
||||
```
|
||||
```bash
|
||||
$ git clone git@github.com:docker_user/docker_practice.git
|
||||
$ cd docker_practice
|
||||
$ git config user.name "yourname"
|
||||
$ git config user.email "your email"
|
||||
```
|
||||
|
||||
* 修改代码后提交，并推送到自己的仓库，注意修改提交消息为对应 Issue 号和描述。
|
||||
修改代码后提交，并推送到自己的仓库，注意修改提交消息为对应 Issue 号和描述。
|
||||
|
||||
```bash
|
||||
$ # Update the content
|
||||
$ git commit -a -s
|
||||
$ # In commit msg dialog, add content like "Fix issue #235: describe ur change"
|
||||
$ git push
|
||||
```
|
||||
```bash
|
||||
# Update the content
|
||||
$ git commit -a -s
|
||||
# In commit msg dialog, add content like "Fix issue #235: describe ur change"
|
||||
$ git push
|
||||
```
|
||||
|
||||
* 在 [GitHub](https://github.com/yeasy/docker_practice/pulls) 上提交 `Pull Request`，添加标签，并邀请维护者进行 `Review`。
|
||||
在 [GitHub](https://github.com/yeasy/docker_practice/pulls) 上提交 `Pull Request`，添加标签，并邀请维护者进行 `Review`。
|
||||
|
||||
* 定期使用项目仓库内容更新自己仓库内容。
|
||||
定期使用项目仓库内容更新自己仓库内容。
|
||||
|
||||
```bash
|
||||
$ git remote add upstream https://github.com/yeasy/docker_practice
|
||||
$ git fetch upstream
|
||||
$ git checkout master
|
||||
$ git rebase upstream/master
|
||||
$ git push -f origin master
|
||||
```
|
||||
```bash
|
||||
$ git remote add upstream https://github.com/yeasy/docker_practice
|
||||
$ git fetch upstream
|
||||
$ git checkout master
|
||||
$ git rebase upstream/master
|
||||
$ git push -f origin master
|
||||
```
|
||||
|
||||
## 排版规范
|
||||
|
||||
|
|
|
|||
|
|
@ -12,8 +12,9 @@
|
|||
|
||||
本书既适用于具备基础 Linux 知识的 Docker 初学者，也希望可供理解原理和实现的高级用户参考。同时，书中给出的实践案例，可供在进行实际部署时借鉴。前六章为基础内容，供用户理解 Docker 的基本概念和操作；7 ~ 9 章介绍一些高级操作；第 10 章给出典型的应用场景和实践案例；11、12 章介绍关于 Docker 安全和实现技术等高级话题。后续章节则分别介绍一些相关的热门开源项目。
|
||||
|
||||
* 在线阅读：[GitBook](https://www.gitbook.io/book/yeasy/docker_practice) 或 [Github](https://github.com/yeasy/docker_practice/blob/master/SUMMARY.md)。
|
||||
* [离线阅读](https://github.com/yeasy/docker_practice/wiki/%E7%A6%BB%E7%BA%BF%E9%98%85%E8%AF%BB%E5%8A%9F%E8%83%BD%E8%AF%A6%E8%A7%A3)。
|
||||
* 在线阅读：[GitBook](https://www.gitbook.io/book/yeasy/docker_practice) 或 [Github](https://github.com/yeasy/docker_practice/blob/master/SUMMARY.md)
|
||||
* [国内镜像](https://github.com/yeasy/docker_practice/wiki/%E9%A1%B9%E7%9B%AE%E5%9B%BD%E5%86%85%E9%95%9C%E5%83%8F)
|
||||
* [离线阅读](https://github.com/yeasy/docker_practice/wiki/%E7%A6%BB%E7%BA%BF%E9%98%85%E8%AF%BB%E5%8A%9F%E8%83%BD%E8%AF%A6%E8%A7%A3)
|
||||
* pdf 版本 [下载](https://www.gitbook.com/download/pdf/book/yeasy/docker_practice)
|
||||
* epub 版本 [下载](https://www.gitbook.com/download/epub/book/yeasy/docker_practice)
|
||||
|
||||
|
|
|
|||
10
SUMMARY.md
10
SUMMARY.md
|
|
@ -83,8 +83,9 @@
|
|||
* [Swarm mode](swarm_mode/README.md)
|
||||
* [基本概念](swarm_mode/overview.md)
|
||||
* [创建 Swarm 集群](swarm_mode/create.md)
|
||||
* [在 Swarm 集群部署服务](swarm_mode/deploy.md)
|
||||
* [在 Swarm 集群中使用 compose 文件](swarm_mode/stack.md)
|
||||
* [部署服务](swarm_mode/deploy.md)
|
||||
* [使用 compose 文件](swarm_mode/stack.md)
|
||||
* [管理敏感数据](swarm_mode/secret.md)
|
||||
* [安全](security/README.md)
|
||||
* [内核命名空间](security/kernel_ns.md)
|
||||
* [控制组](security/control_group.md)
|
||||
|
|
@ -148,5 +149,6 @@
|
|||
* [WordPress](appendix/repo/wordpress.md)
|
||||
* [Node.js](appendix/repo/nodejs.md)
|
||||
* [附录三：Docker 命令查询](appendix/command/README.md)
|
||||
* [附录四：资源链接](appendix/resources/README.md)
|
||||
* [附录五：Docker 中文资源](appendix/resources/cn.md)
|
||||
* [附录四：Dockerfile 最佳实践](appendix/best_practices.md))
|
||||
* [附录五：资源链接](appendix/resources/README.md)
|
||||
* [附录六：Docker 中文资源](appendix/resources/cn.md)
|
||||
|
|
|
|||
|
|
@ -1 +1,2 @@
|
|||
theme: jekyll-theme-slate
|
||||
theme: jekyll-theme-slate
|
||||
include: [_images]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,344 @@
|
|||
# Dockerfile 最佳实践
|
||||
|
||||
本附录是笔者对 Docker 官方文档中 [Best practices for writing Dockerfiles](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/) 的理解与翻译。
|
||||
|
||||
## 一般性的指南和建议
|
||||
|
||||
### 容器应该是短暂的
|
||||
|
||||
通过 `Dockerfile` 构建的镜像所启动的容器应该尽可能短暂（生命周期短）。「短暂」意味着可以停止和销毁容器，并且创建一个新容器并部署好所需的设置和配置工作量应该是极小的。
|
||||
|
||||
### 使用 `.dockerignore` 文件
|
||||
|
||||
使用 `Dockerfile` 构建镜像时最好是将 `Dockerfile` 放置在一个新建的空目录下。然后将构建镜像所需要的文件添加到该目录中。为了提高构建镜像的效率，你可以在目录下新建一个 `.dockerignore` 文件来指定要忽略的文件和目录。`.dockerignore` 文件的排除模式语法和 Git 的 `.gitignore` 文件相似。
|
||||
|
||||
### 使用多阶段构建
|
||||
|
||||
在 `Docker 17.05` 以上版本中，你可以使用 [多阶段构建](../image/multistage-builds.md) 来减少所构建镜像的大小。
|
||||
|
||||
### 避免安装不必要的包
|
||||
|
||||
为了降低复杂性、减少依赖、减小文件大小、节约构建时间，你应该避免安装任何不必要的包。例如，不要在数据库镜像中包含一个文本编辑器。
|
||||
|
||||
### 一个容器只运行一个进程
|
||||
|
||||
应该保证在一个容器中只运行一个进程。将多个应用解耦到不同容器中，保证了容器的横向扩展和复用。例如 web 应用应该包含三个容器：web应用、数据库、缓存。
|
||||
|
||||
如果容器互相依赖，你可以使用 [Docker 自定义网络](../network/linking.md) 来把这些容器连接起来。
|
||||
|
||||
### 镜像层数尽可能少
|
||||
|
||||
你需要在 `Dockerfile` 可读性（也包括长期的可维护性）和减少层数之间做一个平衡。
|
||||
|
||||
### 将多行参数排序
|
||||
|
||||
将多行参数按字母顺序排序（比如要安装多个包时）。这可以帮助你避免重复包含同一个包，更新包列表时也更容易。也便于 `PRs` 阅读和审查。建议在反斜杠符号 `\` 之前添加一个空格，以增加可读性。
|
||||
|
||||
下面是来自 `buildpack-deps` 镜像的例子：
|
||||
|
||||
```docker
|
||||
RUN apt-get update && apt-get install -y \
|
||||
bzr \
|
||||
cvs \
|
||||
git \
|
||||
mercurial \
|
||||
subversion
|
||||
```
|
||||
|
||||
### 构建缓存
|
||||
|
||||
在镜像的构建过程中，Docker 会遍历 `Dockerfile` 文件中的指令，然后按顺序执行。在执行每条指令之前，Docker 都会在缓存中查找是否已经存在可重用的镜像，如果有就使用现存的镜像，不再重复创建。如果你不想在构建过程中使用缓存，你可以在 `docker build` 命令中使用 `--no-cache=true` 选项。
|
||||
|
||||
但是，如果你想在构建的过程中使用缓存，你得明白什么时候会，什么时候不会找到匹配的镜像，遵循的基本规则如下：
|
||||
|
||||
* 从一个基础镜像开始（`FROM` 指令指定），下一条指令将和该基础镜像的所有子镜像进行匹配，检查这些子镜像被创建时使用的指令是否和被检查的指令完全一样。如果不是，则缓存失效。
|
||||
* 在大多数情况下，只需要简单地对比 `Dockerfile` 中的指令和子镜像。然而，有些指令需要更多的检查和解释。
|
||||
* 对于 `ADD` 和 `COPY` 指令，镜像中对应文件的内容也会被检查，每个文件都会计算出一个校验和。文件的最后修改时间和最后访问时间不会纳入校验。在缓存的查找过程中，会将这些校验和和已存在镜像中的文件校验和进行对比。如果文件有任何改变，比如内容和元数据，则缓存失效。
|
||||
* 除了 `ADD` 和 `COPY` 指令，缓存匹配过程不会查看临时容器中的文件来决定缓存是否匹配。例如，当执行完 `RUN apt-get -y update` 指令后，容器中一些文件被更新，但 Docker 不会检查这些文件。这种情况下，只有指令字符串本身被用来匹配缓存。
|
||||
|
||||
一旦缓存失效，所有后续的 `Dockerfile` 指令都将产生新的镜像，缓存不会被使用。
|
||||
|
||||
## Dockerfile 指令
|
||||
|
||||
下面针对 `Dockerfile` 中各种指令的最佳编写方式给出建议。
|
||||
|
||||
### FROM
|
||||
|
||||
尽可能使用当前官方仓库作为你构建镜像的基础。推荐使用 [Debian](https://hub.docker.com/_/debian/) 镜像，因为它被严格控制并保持最小尺寸（目前小于 150 mb），但它仍然是一个完整的发行版。
|
||||
|
||||
### LABEL
|
||||
|
||||
你可以给镜像添加标签来帮助组织镜像、记录许可信息、辅助自动化构建等。每个标签一行，由 `LABEL` 开头加上一个或多个标签对。下面的示例展示了各种不同的可能格式。`#` 开头的行是注释内容。
|
||||
|
||||
>注意：如果你的字符串中包含空格，必须将字符串放入引号中或者对空格使用转义。如果字符串内容本身就包含引号，必须对引号使用转义。
|
||||
|
||||
```docker
|
||||
# Set one or more individual labels
|
||||
LABEL com.example.version="0.0.1-beta"
|
||||
|
||||
LABEL vendor="ACME Incorporated"
|
||||
|
||||
LABEL com.example.release-date="2015-02-12"
|
||||
|
||||
LABEL com.example.version.is-production=""
|
||||
```
|
||||
|
||||
一个镜像可以包含多个标签，但建议将多个标签放入到一个 `LABEL` 指令中。
|
||||
|
||||
```docker
|
||||
# Set multiple labels at once, using line-continuation characters to break long lines
|
||||
LABEL vendor=ACME\ Incorporated \
|
||||
com.example.is-beta= \
|
||||
com.example.is-production="" \
|
||||
com.example.version="0.0.1-beta" \
|
||||
com.example.release-date="2015-02-12"
|
||||
```
|
||||
|
||||
关于标签可以接受的键值对，参考 [Understanding object labels](https://docs.docker.com/engine/userguide/labels-custom-metadata/)。关于查询标签信息，参考 [Managing labels on objects](https://docs.docker.com/engine/userguide/labels-custom-metadata/#managing-labels-on-objects)。
|
||||
|
||||
### RUN
|
||||
|
||||
为了保持 `Dockerfile` 文件的可读性，可理解性，以及可维护性，建议将长的或复杂的 `RUN` 指令用反斜杠 `\` 分割成多行。
|
||||
|
||||
#### apt-get
|
||||
|
||||
`RUN` 指令最常见的用法是安装包用的 `apt-get`。因为 `RUN apt-get` 指令会安装包，所以有几个问题需要注意。
|
||||
|
||||
不要使用 `RUN apt-get upgrade` 或 `dist-upgrade`，因为许多基础镜像中的「必须」包不会在一个非特权容器中升级。如果基础镜像中的某个包过时了，你应该联系它的维护者。如果你确定某个特定的包，比如 `foo`，需要升级，使用 `apt-get install -y foo` 就行，该指令会自动升级 `foo` 包。
|
||||
|
||||
永远将 `RUN apt-get update` 和 `apt-get install` 组合成一条 `RUN` 声明，例如：
|
||||
|
||||
```docker
|
||||
RUN apt-get update && apt-get install -y \
|
||||
package-bar \
|
||||
package-baz \
|
||||
package-foo
|
||||
```
|
||||
|
||||
将 `apt-get update` 放在一条单独的 `RUN` 声明中会导致缓存问题以及后续的 `apt-get install` 失败。比如，假设你有一个 `Dockerfile` 文件：
|
||||
|
||||
```docker
|
||||
FROM ubuntu:14.04
|
||||
|
||||
RUN apt-get update
|
||||
|
||||
RUN apt-get install -y curl
|
||||
```
|
||||
|
||||
构建镜像后，所有的层都在 Docker 的缓存中。假设你后来又修改了其中的 `apt-get install` 添加了一个包：
|
||||
|
||||
```docker
|
||||
FROM ubuntu:14.04
|
||||
|
||||
RUN apt-get update
|
||||
|
||||
RUN apt-get install -y curl nginx
|
||||
```
|
||||
|
||||
Docker 发现修改后的 `RUN apt-get update` 指令和之前的完全一样。所以，`apt-get update` 不会执行，而是使用之前的缓存镜像。因为 `apt-get update` 没有运行，后面的 `apt-get install` 可能安装的是过时的 `curl` 和 `nginx` 版本。
|
||||
|
||||
使用 `RUN apt-get update && apt-get install -y` 可以确保你的 Dockerfiles 每次安装的都是包的最新的版本，而且这个过程不需要进一步的编码或额外干预。这项技术叫作 `cache busting`。你也可以显示指定一个包的版本号来达到 `cache-busting`，这就是所谓的固定版本，例如：
|
||||
|
||||
```docker
|
||||
RUN apt-get update && apt-get install -y \
|
||||
package-bar \
|
||||
package-baz \
|
||||
package-foo=1.3.*
|
||||
```
|
||||
|
||||
固定版本会迫使构建过程检索特定的版本，而不管缓存中有什么。这项技术也可以减少因所需包中未预料到的变化而导致的失败。
|
||||
|
||||
下面是一个 `RUN` 指令的示例模板，展示了所有关于 `apt-get` 的建议。
|
||||
|
||||
```docker
|
||||
RUN apt-get update && apt-get install -y \
|
||||
aufs-tools \
|
||||
automake \
|
||||
build-essential \
|
||||
curl \
|
||||
dpkg-sig \
|
||||
libcap-dev \
|
||||
libsqlite3-dev \
|
||||
mercurial \
|
||||
reprepro \
|
||||
ruby1.9.1 \
|
||||
ruby1.9.1-dev \
|
||||
s3cmd=1.1.* \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
```
|
||||
|
||||
其中 `s3cmd` 指令指定了一个版本号 `1.1.*`。如果之前的镜像使用的是更旧的版本，指定新的版本会导致 `apt-get udpate` 缓存失效并确保安装的是新版本。
|
||||
|
||||
另外，清理掉 apt 缓存 `var/lib/apt/lists` 可以减小镜像大小。因为 `RUN` 指令的开头为 `apt-get udpate`，包缓存总是会在 `apt-get install` 之前刷新。
|
||||
|
||||
> 注意：官方的 Debian 和 Ubuntu 镜像会自动运行 apt-get clean，所以不需要显式的调用 apt-get clean。
|
||||
|
||||
### CMD
|
||||
|
||||
`CMD` 指令用于执行目标镜像中包含的软件，可以包含参数。`CMD` 大多数情况下都应该以 `CMD ["executable", "param1", "param2"...]` 的形式使用。因此，如果创建镜像的目的是为了部署某个服务(比如 `Apache`)，你可能会执行类似于 `CMD ["apache2", "-DFOREGROUND"]` 形式的命令。我们建议任何服务镜像都使用这种形式的命令。
|
||||
|
||||
多数情况下，`CMD` 都需要一个交互式的 `shell` (bash, Python, perl 等)，例如 `CMD ["perl", "-de0"]`，或者 `CMD ["PHP", "-a"]`。使用这种形式意味着，当你执行类似 `docker run -it python` 时，你会进入一个准备好的 `shell` 中。`CMD` 应该在极少的情况下才能以 `CMD ["param", "param"]` 的形式与 `ENTRYPOINT` 协同使用，除非你和你的镜像使用者都对 `ENTRYPOINT` 的工作方式十分熟悉。
|
||||
|
||||
### EXPOSE
|
||||
|
||||
`EXPOSE` 指令用于指定容器将要监听的端口。因此，你应该为你的应用程序使用常见的端口。例如，提供 `Apache` web 服务的镜像应该使用 `EXPOSE 80`，而提供 `MongoDB` 服务的镜像使用 `EXPOSE 27017`。
|
||||
|
||||
对于外部访问，用户可以在执行 `docker run` 时使用一个标志来指示如何将指定的端口映射到所选择的端口。
|
||||
|
||||
### ENV
|
||||
|
||||
为了方便新程序运行，你可以使用 `ENV` 来为容器中安装的程序更新 `PATH` 环境变量。例如使用 `ENV PATH /usr/local/nginx/bin:$PATH` 来确保 `CMD ["nginx"]` 能正确运行。
|
||||
|
||||
`ENV` 指令也可用于为你想要容器化的服务提供必要的环境变量，比如 Postgres 需要的 `PGDATA`。
|
||||
|
||||
最后，`ENV` 也能用于设置常见的版本号，比如下面的示例：
|
||||
|
||||
```docker
|
||||
ENV PG_MAJOR 9.3
|
||||
|
||||
ENV PG_VERSION 9.3.4
|
||||
|
||||
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
|
||||
|
||||
ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH
|
||||
```
|
||||
|
||||
类似于程序中的常量，这种方法可以让你只需改变 `ENV` 指令来自动的改变容器中的软件版本。
|
||||
|
||||
### ADD 和 COPY
|
||||
|
||||
虽然 `ADD` 和 `COPY` 功能类似，但一般优先使用 `COPY`。因为它比 `ADD` 更透明。`COPY` 只支持简单将本地文件拷贝到容器中，而 `ADD` 有一些并不明显的功能（比如本地 tar 提取和远程 URL 支持）。因此，`ADD` 的最佳用例是将本地 tar 文件自动提取到镜像中，例如 `ADD rootfs.tar.xz`。
|
||||
|
||||
如果你的 `Dockerfile` 有多个步骤需要使用上下文中不同的文件。单独 `COPY` 每个文件，而不是一次性的 `COPY` 所有文件，这将保证每个步骤的构建缓存只在特定的文件变化时失效。例如：
|
||||
|
||||
```docker
|
||||
COPY requirements.txt /tmp/
|
||||
|
||||
RUN pip install --requirement /tmp/requirements.txt
|
||||
|
||||
COPY . /tmp/
|
||||
```
|
||||
|
||||
如果将 `COPY . /tmp/` 放置在 `RUN` 指令之前，只要 `.` 目录中任何一个文件变化，都会导致后续指令的缓存失效。
|
||||
|
||||
为了让镜像尽量小，最好不要使用 `ADD` 指令从远程 URL 获取包，而是使用 `curl` 和 `wget`。这样你可以在文件提取完之后删掉不再需要的文件来避免在镜像中额外添加一层。比如尽量避免下面的用法：
|
||||
|
||||
```docker
|
||||
ADD http://example.com/big.tar.xz /usr/src/things/
|
||||
|
||||
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
|
||||
|
||||
RUN make -C /usr/src/things all
|
||||
```
|
||||
|
||||
而是应该使用下面这种方法：
|
||||
|
||||
```docker
|
||||
RUN mkdir -p /usr/src/things \
|
||||
&& curl -SL http://example.com/big.tar.xz \
|
||||
| tar -xJC /usr/src/things \
|
||||
&& make -C /usr/src/things all
|
||||
```
|
||||
|
||||
上面使用的管道操作，所以没有中间文件需要删除。
|
||||
|
||||
对于其他不需要 `ADD` 的自动提取功能的文件或目录，你应该使用 `COPY`。
|
||||
|
||||
### ENTRYPOINT
|
||||
|
||||
`ENTRYPOINT` 的最佳用处是设置镜像的主命令，允许将镜像当成命令本身来运行（用 `CMD` 提供默认选项）。
|
||||
|
||||
例如，下面的示例镜像提供了命令行工具 `s3cmd`:
|
||||
|
||||
```docker
|
||||
ENTRYPOINT ["s3cmd"]
|
||||
|
||||
CMD ["--help"]
|
||||
```
|
||||
|
||||
现在直接运行该镜像创建的容器会显示命令帮助：
|
||||
|
||||
```bash
|
||||
$ docker run s3cmd
|
||||
```
|
||||
|
||||
或者提供正确的参数来执行某个命令：
|
||||
|
||||
```bash
|
||||
$ docker run s3cmd ls s3://mybucket
|
||||
```
|
||||
|
||||
这样镜像名可以当成命令行的参考。
|
||||
|
||||
`ENTRYPOINT` 指令也可以结合一个辅助脚本使用，和前面命令行风格类似，即使启动工具需要不止一个步骤。
|
||||
|
||||
例如，`Postgres` 官方镜像使用下面的脚本作为 `ENTRYPOINT`：
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
if [ "$1" = 'postgres' ]; then
|
||||
chown -R postgres "$PGDATA"
|
||||
|
||||
if [ -z "$(ls -A "$PGDATA")" ]; then
|
||||
gosu postgres initdb
|
||||
fi
|
||||
|
||||
exec gosu postgres "$@"
|
||||
fi
|
||||
|
||||
exec "$@"
|
||||
```
|
||||
|
||||
>注意：该脚本使用了 Bash 的内置命令 exec，所以最后运行的进程就是容器的 PID 为 1 的进程。这样，进程就可以接收到任何发送给容器的 Unix 信号了。
|
||||
|
||||
该辅助脚本被拷贝到容器，并在容器启动时通过 `ENTRYPOINT` 执行：
|
||||
|
||||
```docker
|
||||
COPY ./docker-entrypoint.sh /
|
||||
|
||||
ENTRYPOINT ["/docker-entrypoint.sh"]
|
||||
```
|
||||
|
||||
该脚本可以让用户用几种不同的方式和 `Postgres` 交互。
|
||||
|
||||
你可以很简单地启动 `Postgres`：
|
||||
|
||||
```bash
|
||||
$ docker run postgres
|
||||
```
|
||||
|
||||
也可以执行 `Postgres` 并传递参数：
|
||||
|
||||
```bash
|
||||
$ docker run postgres postgres --help
|
||||
```
|
||||
|
||||
最后，你还可以启动另外一个完全不同的工具，比如 `Bash`：
|
||||
|
||||
```bash
|
||||
$ docker run --rm -it postgres bash
|
||||
```
|
||||
|
||||
### VOLUME
|
||||
|
||||
`VOLUME` 指令用于暴露任何数据库存储文件，配置文件，或容器创建的文件和目录。强烈建议使用 `VOLUME` 来管理镜像中的可变部分和用户可以改变的部分。
|
||||
|
||||
### USER
|
||||
|
||||
如果某个服务不需要特权执行，建议使用 `USER` 指令切换到非 root 用户。先在 `Dockerfile` 中使用类似 `RUN groupadd -r postgres && useradd -r -g postgres postgres` 的指令创建用户和用户组。
|
||||
|
||||
>注意：在镜像中，用户和用户组每次被分配的 UID/GID 都是不确定的，下次重新构建镜像时被分配到的 UID/GID 可能会不一样。如果要依赖确定的 UID/GID，你应该显示的指定一个 UID/GID。
|
||||
|
||||
你应该避免使用 `sudo`，因为它不可预期的 TTY 和信号转发行为可能造成的问题比它能解决的问题还多。如果你真的需要和 `sudo` 类似的功能（例如，以 root 权限初始化某个守护进程，以非 root 权限执行它），你可以使用 [gosu](https://github.com/tianon/gosu)。
|
||||
|
||||
最后，为了减少层数和复杂度，避免频繁地使用 `USER` 来回切换用户。
|
||||
|
||||
### WORKDIR
|
||||
|
||||
为了清晰性和可靠性，你应该总是在 `WORKDIR` 中使用绝对路径。另外，你应该使用 `WORKDIR` 来替代类似于 `RUN cd ... && do-something` 的指令，后者难以阅读、排错和维护。
|
||||
|
||||
## 官方仓库示例
|
||||
|
||||
这些官方仓库的 Dockerfile 都是参考典范：https://github.com/docker-library/docs
|
||||
|
|
@ -3,5 +3,3 @@
|
|||
* [Docker 问答录（100 问）](https://blog.lab99.org/post/docker-2016-07-14-faq.html)
|
||||
|
||||
* [Docker CE 变更日志中文翻译](https://github.com/allencloud/docker-changelog-chinese)
|
||||
|
||||
* [Dockerfile 最佳实践中文翻译](http://blog.csdn.net/guyue35/article/details/53891862)
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /
|
|||
|
||||
但在某些情况下，如果我们真的是希望复制个压缩文件进去，而不解压缩，这时就不可以使用 `ADD` 命令了。
|
||||
|
||||
在 Docker 官方的 [最佳实践文档](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/) 中要求，尽可能的使用 `COPY`，因为 `COPY` 的语义很明确，就是复制文件而已，而 `ADD` 则包含了更复杂的功能，其行为也不一定很清晰。最适合使用 `ADD` 的场合，就是所提及的需要自动解压缩的场合。
|
||||
在 Docker 官方的 [Dockerfile 最佳实践文档](../../appendix/best_practices.md) 中要求，尽可能的使用 `COPY`，因为 `COPY` 的语义很明确，就是复制文件而已，而 `ADD` 则包含了更复杂的功能，其行为也不一定很清晰。最适合使用 `ADD` 的场合，就是所提及的需要自动解压缩的场合。
|
||||
|
||||
另外需要注意的是，`ADD` 指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ USER redis
|
|||
RUN [ "redis-server" ]
|
||||
```
|
||||
|
||||
如果以 `root` 执行的脚本，在执行期间希望改变身份，比如希望以某个已经建立好的用户来运行某个服务进程，不要使用 `su` 或者 `sudo`，这些都需要比较麻烦的配置，而且在 TTY 缺失的环境下经常出错。建议使用 `gosu`，可以从其项目网站看到进一步的信息：<https://github.com/tianon/gosu>
|
||||
如果以 `root` 执行的脚本，在执行期间希望改变身份，比如希望以某个已经建立好的用户来运行某个服务进程，不要使用 `su` 或者 `sudo`，这些都需要比较麻烦的配置，而且在 TTY 缺失的环境下经常出错。建议使用 [`gosu`](https://github.com/tianon/gosu)。
|
||||
|
||||
```Dockerfile
|
||||
# 建立 redis 用户，并使用 gosu 换另一个用户执行命令
|
||||
|
|
|
|||
|
|
@ -0,0 +1,83 @@
|
|||
## 在 Swarm 集群中管理敏感数据
|
||||
|
||||
在动态的、大规模的分布式集群上，管理和分发 `密码`、`证书` 等敏感信息是极其重要的工作。传统的密钥分发方式（如密钥放入镜像中，设置环境变量，volume 动态挂载等）都存在着潜在的巨大的安全风险。
|
||||
|
||||
Docker 目前已经提供了 `secrets` 管理功能，用户可以在 Swarm 集群中安全地管理密码、密钥证书等敏感数据，并允许在多个 Docker 容器实例之间共享访问指定的敏感数据。
|
||||
|
||||
我们可以用 `docker secret` 命令来管理敏感信息。接下来我们在上面章节中创建好的 Swarm 集群中介绍该命令的使用。
|
||||
|
||||
这里我们以在 Swarm 集群中部署 `mysql` 和 `wordpress` 服务为例。
|
||||
|
||||
### 创建 secret
|
||||
|
||||
我们使用 `docker secret create` 命令以管道符的形式创建 `secret`
|
||||
|
||||
```bash
|
||||
$ openssl rand -base64 20 | docker secret create mysql_password -
|
||||
|
||||
$ openssl rand -base64 20 | docker secret create mysql_root_password -
|
||||
```
|
||||
|
||||
### 查看 secret
|
||||
|
||||
使用 `docker secret ls` 命令来查看 `secret`
|
||||
|
||||
```bash
|
||||
$ docker secret ls
|
||||
|
||||
ID NAME CREATED UPDATED
|
||||
l1vinzevzhj4goakjap5ya409 mysql_password 41 seconds ago 41 seconds ago
|
||||
yvsczlx9votfw3l0nz5rlidig mysql_root_password 12 seconds ago 12 seconds ago
|
||||
```
|
||||
|
||||
### 创建 MySQL 服务
|
||||
|
||||
创建服务相关命令已经在前边章节进行了介绍，这里直接列出命令。
|
||||
|
||||
```bash
|
||||
$ docker network create -d overlay mysql_private
|
||||
|
||||
$ docker service create \
|
||||
--name mysql \
|
||||
--replicas 1 \
|
||||
--network mysql_private \
|
||||
--mount type=volume,source=mydata,destination=/var/lib/mysql \
|
||||
--secret source=mysql_root_password,target=mysql_root_password \
|
||||
--secret source=mysql_password,target=mysql_password \
|
||||
-e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/mysql_root_password" \
|
||||
-e MYSQL_PASSWORD_FILE="/run/secrets/mysql_password" \
|
||||
-e MYSQL_USER="wordpress" \
|
||||
-e MYSQL_DATABASE="wordpress" \
|
||||
mysql:latest
|
||||
```
|
||||
|
||||
如果你没有在 `target` 中显式的指定路径时，`secret` 默认通过 `tmpfs` 文件系统挂载到容器的 `/run/secrets` 目录中。
|
||||
|
||||
```bash
|
||||
$ docker service create \
|
||||
--name wordpress \
|
||||
--replicas 1 \
|
||||
--network mysql_private \
|
||||
--publish target=30000,port=80 \
|
||||
--mount type=volume,source=wpdata,destination=/var/www/html \
|
||||
--secret source=mysql_password,target=wp_db_password,mode=0400 \
|
||||
-e WORDPRESS_DB_USER="wordpress" \
|
||||
-e WORDPRESS_DB_PASSWORD_FILE="/run/secrets/wp_db_password" \
|
||||
-e WORDPRESS_DB_HOST="mysql:3306" \
|
||||
-e WORDPRESS_DB_NAME="wordpress" \
|
||||
wordpress:latest
|
||||
```
|
||||
|
||||
查看服务
|
||||
|
||||
```bash
|
||||
$ docker service ls
|
||||
|
||||
ID NAME MODE REPLICAS IMAGE
|
||||
wvnh0siktqr3 mysql replicated 1/1 mysql:latest
|
||||
nzt5xzae4n62 wordpress replicated 1/1 wordpress:latest
|
||||
```
|
||||
|
||||
现在浏览器访问 `IP:30000`，即可开始 `WordPress` 的安装与使用。
|
||||
|
||||
通过以上方法，我们没有像以前通过设置环境变量来设置 MySQL 密码， 而是采用 `docker secret` 来设置密码，防范了密码泄露的风险。
|
||||
Loading…
Reference in New Issue