A. dockerfile是什么类型文件
Dockerfile是由一系列命令和参数构成的脚本，这些命令应用于基础镜像并最终创建一个新的镜像。它们简化了从头到尾的流程并极大的简化了部署工作。Dockerfile从FROM命令开始，紧接着跟随者各种方法，命令和参数。其产出为一个新的可以用于创建容器的镜像。
#
#VERSION2-EDITION1
#Author:docker_user
#Commandformat:Instruction[arguments/command]..
#1、第一行必须指定基础镜像信息
FROMubuntu
#2、维护者信息
[email protected]
#3、镜像操作指令
RUNecho"debhttp://archive.ubuntu.com/ubuntu/raringmainuniverse">>/etc/apt/sources.list
RUNapt-getupdate&&apt-getinstall-ynginx
RUNecho" daemonoff;">>/etc/nginx/nginx.conf
#4、容器启动执行指令
CMD/usr/sbin/nginx
Dockerfile 分为四部分：基础镜像信息、维护者信息、镜像操作指令、容器启动执行指令。
一开始必须要指明所基于的镜像名称，接下来一般会说明维护者信息。
后面则是镜像操作指令，例如 RUN 指令。RUN 指令将对镜像执行跟随的指令。每执行一条RUN 指令，镜像添加新的一层，并提交
最后是 CMD 指令，来指明运行容器时的操作命令。
FROM 指令：格式： FROM <images> 或者 FROM<image>:<tag>。第一条指令必须是 FROM 指令。并且，如果在同一个Dockerfile中创建多个镜像时，可以使用多个 FROM 指令。
MAINTAINER 指令：指定维护者信息。
RUN 指令：格式：RUN <command> 或者 RUN ["executable","param1","param2"]
另外通过直接下载程序镜像(Nginx)也可以创建一个容器，并将容器运行起来。
(1) 从中央仓库下载镜像：docker pull nginx:1.9
(2) docker run 命令启动容器，docker run -d -p 8080:80 nginx:1.9，把容器内的nginx的80端口，映射到当前服务器(Centos系统的ip地址)的8080端口，我当前服务器的ip是192.168.1.10，这样在浏览器输入192.168.1.10:8080/，发现nginx已启动。
(3) 再启动多一个容器，docker run -d -p 8085:80 nginx:1.9，浏览器输入http:/192.168.1.10:8085/，就可以看到另外一个nginx已启动。
B. 如何配置一个 Docker 化持续集成的 PHP 开发环境
首先，我们得知道什么才是好的开发环境， 对于我而言，一个好的开发环境需要具备以下几个特点：
可随意使用。我必须可以随意删除和创建新的环境。
快速启动。我想要用它工作时候，它立马就能用。
易于更新。在我们行业中，事物发展变化非常快，必须能让我很容易将我的开发环境更新到新的软件版本。
而Docker都支持以上这些特点，甚至更多。你几乎可以即时销毁和重建容器，而更新环境只需要重建你当前使用的镜像即可。
什么是PHP开发环境
目前Web应用错综复杂，PHP开发环境需要很多的东西，为了保证环境的简单性，需要做各种各样的限制。
我们这次使用Nginx、PHP5-FPM、Mysql来运行Synmfony项目。由于在容器中运行命令行会更复杂，所以这方面的内容我会放到下一篇博客中再说。
Pet 与 Cattle
另一个我们要讨论的重点是：我们要把开发环境部署在多容器还是单容器中。 两种方式各有优点：
单容器易于分发、维护。因为它们是独立的，所有的东西都运行在同一个容器中，这点就像是一个虚拟机。但这也意味着，当你要升级其中的某样东西（比如PHP新版本）的时候， 需要重新构建整个容器。
多容器可以在添加组件时提供更好的模块化。因为每个容器包含了堆栈的一部分：Web、PHP、MySQL等，这样可以单独扩展每个服务或者添加服务，并且不需要重建所有的东西。
因为我比较懒，加上我需要在我的笔记本上放点别的内容，所以，这里我们只介绍单个容器的方法。
初始化工程
首先要做的是初始化一个新的Symfony工程. 推荐的方法是用composer的create-project命令。本来可以在工作站上安装composer，但是那样太简单了。这次我们通过Docker来使用它。
我之前发过一篇关于Docker命令的文章：make docker commands（好吧，我说谎了，我本来把它写在这篇文章中了，然后觉得把它独立出来会比较好）。
不管怎么样，你可以读一下。接下来如果还没有composer命令的话，你可以创建一个属于自己的composer 别名。
$ alias composer="docker run -i -t -v \$PWD:/srv ubermuda/composer"
现在你可以初始化Symfony工程了：
$ composer create-project symfony/framwork-standard-edition SomeProject
帅呆了！下面来点实在的工作。(省略了博主自娱自乐的一堆balabla....原文:Awesome. Give yourself a high-five， get a cup of coffee or whatever is your liquid drug of choice， and get ready for the real work.)
容器
构建一个运行标准Symfony项目且自给自足的容器相当容易，只需要安装好常用的Nginx、PHP5-FPM和MySQL-Server即可，然后把预先准备好的Nginx的虚拟主机配置文件扔进去，再复制一些配置文件进去就完事了。
本容器的源代码在GitHub上的 ubermuda/docker-symfony仓库中可以找到。 Dockerfile 是Docker构建镜像要用到的配置文件，我们来看一下:
FROM debian:wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update -y
RUN apt-get install -y nginx php5-fpm php5-mysqlnd php5-cli mysql-server supervisor
RUN sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf
RUN sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf
RUN sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
ADD vhost.conf /etc/nginx/sites-available/default
ADD supervisor.conf /etc/supervisor/conf.d/supervisor.conf
ADD init.sh /init.sh
EXPOSE 80 3306
VOLUME ["/srv"]
WORKDIR /srv
CMD ["/usr/bin/supervisord"]
我们通过扩展 debian:wheezy 这个基础镜像开始，然后通过一系列的sed命令来配置Nginx和PHP5-FPM。
RUN sed -e 's/;daemonize = yes/daemonize = no/' -i /etc/php5/fpm/php-fpm.conf
RUN sed -e 's/;listen\.owner/listen.owner/' -i /etc/php5/fpm/pool.d/www.conf
RUN sed -e 's/;listen\.group/listen.group/' -i /etc/php5/fpm/pool.d/www.conf
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
这里我们要做两件事。 首先配置PHP5-FPM和Nginx让他们在前台运行以便supervisord可以追踪到他们。
然后，配置PHP5-FPM以指定的用户运行Web-Server，并处理好文件权限。
接下来需要安装一组配置文件，首先是Nginx的虚拟主机配置文件vhost.conf:
server {
listen 80;
server_name _;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
root /srv/web;
index app_dev.php;
location / {
try_files $uri $uri/ /app_dev.php?$query_string;
}
location ~ [^/]\.php(/|$) {
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}
}
因为我们不需要域名，所以把server_name设成了_（有点像perl的$_占位符变量）， 并配置根目录（document root）为/svr/web， 我们会把应用程序部署在/srv下，剩下的就是标准的Mginx + PHP5-FPM配置.
因为一个容器每次只能运行一个程序， 我们需要supervisord（或者任何别的进程管理器，不过我比较中意supervisord）。幸运的是， 这个进程管理器会产生我们需要的所有进程！下面是一小段supervisord的配置：
[supervisord]
nodaemon=true
[program:nginx]
command=/usr/sbin/nginx
[program:php5-fpm]
command=/usr/sbin/php5-fpm
[program:mysql]
command=/usr/bin/mysqld_safe
[program:init]
command=/init.sh
autorestart=false
redirect_stderr=true
redirect_stdout=/srv/app/logs/init.log
这里我们需要做的是定义所有的服务， 加上一个特殊的program:init进程，它不是一个实际的服务，而是一个独创的运行启动脚本的方式。
这个启动脚本的问题在于，它通常需要先启动某些服务。比如，你可能要初始化一些数据库表，但前提是你得先把MySQL跑起来，一个可能的解决办法是，在启动脚本中启动MySQL，然后初始化表，然后为了防止影响到supervisord的进程管理，需要停掉MySQL，最后再启动supervisord。
这样的脚本看起来类似下面这样：
/etc/init.d/mysql start
app/console doctrine:schema:update --force
/etc/init.d/mysql stop
exec /usr/bin/supervisord
看起来丑爆了有木有，咱换种方式，让supervisor来运行它并且永不重启。
实际的init.sh脚本如下：
#!/bin/bash
RET=1
while [[ RET -ne 0 ]]; do
sleep 1;
mysql -e 'exit' > /dev/null 2>&1; RET=$?
done
DB_NAME=${DB_NAME:-symfony}
mysqladmin -u root create $DB_NAME
if [ -n "$INIT" ]; then
/srv/$INIT
fi
脚本先等待MySQL启动，然后根据环境变量DB_NAME创建DB，默认为symfony， 然后在INIT环境变量中查找要运行的脚本，并尝试运行它。本文的结尾有说明如何使用这些环境变量。
构建并运行镜像
万事俱备只欠东风。我们还要构建Symfony Docker镜像， 使用docker build命令:
$ cd docker-symfony
$ docker build -t symfony .
现在，可以使用它来运行你的Symfony工程了:
$ cd SomeProject
$ docker run -i -t -P -v $PWD:/srv symfony
我们来看看这一连串的选项分别是干嘛的:
-i 启动交互（interactive）模式， 也就是说，STDIO（标准输入输出）连接到了你当前的终端上。当你要接收日志或者给进程发送信号时，它很有用。
-t 为容器创建一个虚拟TTY， 它跟-i是好基友，通常一起使用。
-P 告诉Docker守护进程发布所有指定的端口， 本例中为80端口。
-v $PWD:/srv 把当前目录挂载到容器的/srv目录。挂载一个目录使得目录内容对目标挂载点可用。
现在你还记得之前提到的DB_NAME和INIT环境变量了吧，干嘛用的呢：用于自定义你的环境。 基本上你可以通过 docker run的-e选项在容器中设置环境变量，启动脚本会拿到环境变量，因此，如果你的DB名为some_project_dev， 你就可以这么运行容器：
$ docker run -i -t -P -v $PWD:/srv -e DB_NAME=some_project_dev symfony
INIT 环境变量就更强大了，它允许你启动时运行指定的脚本。比如， 你有一个bin/setup脚本运行composer install命令并且设置数据库schema:
#!/bin/bash
composer install
app/console doctrine:schema:update --force
用-e来运行它：
$ docker run -i -t -P \
-v $PWD:/srv \
-e DB_NAME=some_project_dev \
-e INIT=bin/setup
注意，-e选项可以在docer run中多次使用，看起来相当酷。另外，你的启动脚本需要可执行权限（chmod +x）。
现在我们通过curl发送请求到容器，来检查一下是否所有的东西都像预期一样工作。首先，我们需要取到Docker映射到容器的80端口的公共端口，用docker port命令:
$ docker port $(docker ps -aql 1) 80
0.0.0.0:49153
docker ps -aql 1 是个好用的命令，可以方便的检索到最后一个容器的id， 在我们的例子中，Docker 把容器的80端口映射到了49153端口。我们 curl 一下看看。
$ curl http://localhost:49153
You are not allowed to access this file. Check app_dev.php for more information.
当我们不从localhost（译者注：容器的localhost）访问dev controller时，得到了Symfony的默认错误消息，这再正常不过了， 因为我们不是从容器内部发送 curl 请求的， 所以，可以安全的从前端控制器web/app_dev.php中移除这些行。
// This check prevents access to debug front controllers that are deployed by accident to proction servers.
// Feel free to remove this， extend it， or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
|| isset($_SERVER['HTTP_X_FORWARDED_FOR'])
|| !(in_array(@$_SERVER['REMOTE_ADDR']， array('127.0.0.1'， 'fe80::1'， '::1')) || php_sapi_name() === 'cli-server')
) {
header('HTTP/1.0 403 Forbidden');
exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}
这些行阻止了任何从localhost以外的地方访问dev controller。
现在再curl的时候就可以正常工作了，或者用浏览器访问 http://localhost:49153/：
很容易吧！ 现在我们可以快速的启动、更新环境了，但还是有很多地方需要改进。
C. 启动mysql的docker镜像，怎么自动执行初始化sql脚本
在docker中有一个mysql服务，其数据文件是挂在在主机外面的文件，在docker中的root有访问该数据文件的权限，但是docker中mysql访问数据文件的时候提示权限不足，于是只有以root用户来启动mysql了。
数据初始化：
mysql_install_db --user=root --explicit_defaults_for_timestamp=111
初始化后以root用户启动
mysqld --user=root --explicit_defaults_for_timestamp=111
mysql启动正常。
启动方式主要有以下三种：
1、使用systemctl 启动 systemctl start mysqld
2、使用脚本启动 /etc/inint.d/mysqld start
3、使用safe_mysqld或mysqld --user=mysql启动
关闭方式也有以下三种：
1、使用systemctl 关闭 systemctl stop mysqld
2、使用脚本关闭 /etc/inint.d/mysqld stop
3、mysqladmin shutdown
注意：使用safe_mysqld或mysqld --user=mysql启动的服务，只能通过mysqladmin shutdown关闭，不能通过systemctl 或脚本关闭。
mysqladmin shutdown可关闭以上三种服务。脚本可关闭systemctl开启的服务，同样systemctl也可关闭脚本开
D. 如何用Dockerfile创建镜像
Dockerfile的指令是忽略大小写的，建议使用大写，使用 # 作为注释，每一行只支持一条指令，每条指令可以携带多个参数。
Dockerfile的指令根据作用可以分为两种，构建指令和设置指令。构建指令用于构建image，其指定的操作不会在运行image的容器上执行；设置指令用于设置image的属性，其指定的操作将在运行image的容器中执行。
（1）FROM（指定基础image）
构建指令，必须指定且需要在Dockerfile其他指令的前面。后续的指令都依赖于该指令指定的image。FROM指令指定的基础image可以是官方远程仓库中的，也可以位于本地仓库。
该指令有两种格式：
[plain] view plain
FROM <image>
指定基础image为该image的最后修改的版本。或者：
[plain] view plain
FROM <image>:<tag>
指定基础image为该image的一个tag版本。
（2）MAINTAINER（用来指定镜像创建者信息）
构建指令，用于将image的制作者相关的信息写入到image中。当我们对该image执行docker inspect命令时，输出中有相应的字段记录该信息。
格式：
[plain] view plain
MAINTAINER <name>
（3）RUN（安装软件用）
构建指令，RUN可以运行任何被基础image支持的命令。如基础image选择了ubuntu，那么软件管理部分只能使用ubuntu的命令。
该指令有两种格式：
[plain] view plain
RUN <command> (the command is run in a shell - `/bin/sh -c`)
RUN ["executable", "param1", "param2" ... ] (exec form)
（4）CMD（设置container启动时执行的操作）
设置指令，用于container启动时指定的操作。该操作可以是执行自定义脚本，也可以是执行系统命令。该指令只能在文件中存在一次，如果有多个，则只执行最后一条。
该指令有三种格式：
[plain] view plain
CMD ["executable","param1","param2"] (like an exec, this is the preferred form)
CMD command param1 param2 (as a shell)
当Dockerfile指定了ENTRYPOINT，那么使用下面的格式：
[plain] view plain
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
ENTRYPOINT指定的是一个可执行的脚本或者程序的路径，该指定的脚本或者程序将会以param1和param2作为参数执行。所以如果CMD指令使用上面的形式，那么Dockerfile中必须要有配套的ENTRYPOINT。
（5）ENTRYPOINT（设置container启动时执行的操作）
设置指令，指定容器启动时执行的命令，可以多次设置，但是只有最后一个有效。
两种格式:
[plain] view plain
ENTRYPOINT ["executable", "param1", "param2"] (like an exec, the preferred form)
ENTRYPOINT command param1 param2 (as a shell)
该指令的使用分为两种情况，一种是独自使用，另一种和CMD指令配合使用。
当独自使用时，如果你还使用了CMD命令且CMD是一个完整的可执行的命令，那么CMD指令和ENTRYPOINT会互相覆盖只有最后一个CMD或者ENTRYPOINT有效。
[plain] view plain
# CMD指令将不会被执行，只有ENTRYPOINT指令被执行
CMD echo “Hello, World!”
ENTRYPOINT ls -l
另一种用法和CMD指令配合使用来指定ENTRYPOINT的默认参数，这时CMD指令不是一个完整的可执行命令，仅仅是参数部分；ENTRYPOINT指令只能使用JSON方式指定执行命令，而不能指定参数。
E. 如何写docker自动创建容器脚本
dockerfile 和docker-compose file
F. 如何调用docker里面的脚本
在使用weave之前，你需要在所有宿主机上安装Docker环境，参考这些教程，在Ubuntu或CentOS/Fedora发行版中安装Docker。Docker环境部署完成后，使用下面的命令安装weave：$wget/zettio/weave/releases/download/latest_release/weave$chmoda+xweave$sudocpweave/usr/local/bin注意你的PATH环境变量要包含/usr/local/bin这个路径，请在/etc/profile文件中加入一行（LCTT译注：要使环境变量生效，你需要执行这个命令：source/etc/profile）：exportPATH="$PATH:/usr/local/bin"在每台宿主机上重复上面的操作。Weave在TCP和UDP上都使用6783端口，如果你的系统开启了防火墙，请确保这两个端口不会被防火墙挡住。在每台宿主机上启动Weave路由器当你想要让处于在不同宿主机上的容器能够互相通信，第一步要做的就是在每台宿主机上启动weave路由器。第一台宿主机，运行下面的命令，就会创建并开启一个weave路由器容器（LCTT译注：前面说过了，weave路由器也是一个容器）：$sudoweavelaunch第一次运行这个命令的时候，它会下载一个weave镜像，这会花一些时间。下载完成后就会自动运行这个镜像。成功启动后，终端会输出这个weave路由器的ID号。下面的命令用于查看路由器状态：$sudoweavestatus第一个weave路由器就绪了，目前为止整个peer对等网络中只有一个peer成员。你也可以使用docker的命令来查看weave路由器的状态：$dockerps第二台宿主机部署步骤稍微有点不同，我们需要为这台宿主机的weave路由器指定第一台宿主机的IP地址，命令如下：$sudoweavelaunch当你查看路由器状态，你会看到两个peer成员：当前宿主机和第一个宿主机。当你开启路由器，这个peer成员列表会更长。当你新开一个路由器时，要指定前一个宿主机的IP地址，请注意不是第一个宿主机的IP地址（LCTT译注：链状结构）。现在你已经有了一个weave网络了，它由位于不同宿主机的weave路由器组成。把不同宿主机上的容器互联起来接下来要做的就是在不同宿主机上开启Docker容器，并使用虚拟网络将它们互联起来。假设我们创建一个私有网络10.0.0.0/24来互联Docker容器，并为这些容器随机分配IP地址。如果你想新建一个能加入weave网络的容器，你就需要使用weave命令来创建，而不是docker命令。原因是weave命令内部会调用docker命令来新建容器然后为它设置网络。下面的命令是在宿主机hostA上建立一个Ubuntu容器，然后将它放到10.0.0.0/24网络中，分配的IP地址为10.0.0.1：hostA:~$sudoweaverun10.0.0.1/24-t-iubuntu成功运行后，终端会显示出容器的ID号。你可以使用这个ID来访问这个容器：hostA:~$dockerattach在宿主机hostB上，也创建一个Ubuntu容器，IP地址为10.0.0.2：hostB:~$sudoweaverun10.0.0.2/24-t-iubuntu访问下这个容器的控制台：hostB:~$dockerattach这两个容器能够互相ping通，你可以通过容器的控制台检查一下。如果你检查一下每个容器的网络配置，你会发现有一块名为“ethwe”的网卡，你分配给容器的IP地址出现在它们那里（比如这里分别是10.0.0.1和10.0.0.2）。Weave的其他高级用法weave提供了一些非常巧妙的特性，我在这里作下简单的介绍。应用分离使用weave，你可以创建多个虚拟网络，并为每个网络设置不同的应用。比如你可以为一群容器创建10.0.0.0/24网络，为另一群容器创建10.10.0.0/24网络，weave会自动帮你维护这些网络，并将这两个网络互相隔离。另外，你可以灵活地将一个容器从一个网络移到另一个网络而不需要重启容器。举个例子：首先开启一个容器，运行在10.0.0.0/24网络上：$sudoweaverun10.0.0.2/24-t-iubuntu然后让它脱离这个网络：$sudoweavedetach10.0.0.2/24最后将它加入到10.10.0.0/24网络中：$sudoweaveattach10.10.0.2/24现在这个容器可以与10.10.0.0/24网络上的其它容器进行通信了。这在当你创建一个容器而网络信息还不确定时就很有帮助了。将weave网络与宿主机网络整合起来有时候你想让虚拟网络中的容器能访问物理主机的网络。或者相反，宿主机需要访问容器。为满足这个功能，weave允许虚拟网络与宿主机网络整合。举个例子，在宿主机hostA上一个容器运行在10.0.0.0/24中，运行使用下面的命令：hostA:~$sudoweaveexpose10.0.0.100/24这个命令把IP地址10.0.0.100分配给宿主机hostA，这样一来宿主机hostA也连到了10.0.0.0/24网络上了。显然，你在为宿主机选择IP地址的时候，需要选一个没有被其他容器使用的地址。现在hostA就可以访问10.0.0.0/24上的所有容器了，不管这些容器是否位于hostA上。好巧妙的设定啊，32个赞！
G. DockerHub里的镜像太多了，怎么选择
目前系统或基础语言的镜像选官方的就可以了，多数情况下以他们为 base image 做自己的镜像。问题就是这些镜像大多是国外的源下载依赖会很费劲，最好from 之后换一下源。
应用相关的镜像，很多其实都不能很好满足需求，都需要自己改，这方面也没啥太好的办法，看自己需求了，一般是看他们的 dockerfile 然后把启动脚本改一下。
official 的镜像很多并不好用，可以参考一下 tutum 或者 Sameer 感觉他们做的要实用一些
H. 如何避免Docker容器启动脚本运行后自动退出
1.安装Docker在开始前，我们首先得确保在Linux主机中已经安装了Docker。这里，我运行的是CentOS7主机，我们将运行yum管理器和下面的命令来安装Docker。#yuminstalldocker#systemctlrestartdocker.service2.创建Dockerfile现在
I. 如何使用Docker构建运行时间较长的脚本
问题
让我们从这个我试图解决的问题开始。我开发了一个会运行很长时间的构建脚本，这个脚本中包含了很多的步骤。
这个脚本会运行1-2个小时。
它会从网络下载比较大的文件（超过300M）。
后面的构建步骤依赖前期构建的库。
但最最烦人的是，运行这个脚本真的需要花很长的时间。
文件系统是固有状态
我们一般是通过一种有状态的方式与文件系统进行交互的。我们可以添加、删除或移动文件。我们可以修改文件的 权限或者它的访问时间。大部分独立的操作都可以撤销，例如将文件移动到其它地方后，你可以将文件恢复到原来的位置。但我们不会通过快照的方式来将它恢复到 原始状态。这篇文章我将会介绍如何在耗时较长的脚本中充分利用快照这一特性。
使用联合文件系统的快照
Docker使用的是联合文件系统叫做AUFS（译者注：简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统）。联合文件系统实现了Union mount。顾名思义，也就是说不同的文件系统的文件和目录可以分层叠加在单个连贯文件系统之上。这是通过分层的方式完成的。如果一个文件出现在两个文件系统，那最高层级的文件才会显示（该文件其它版本也是存在于层级中的，不会改变，只是看不到的）。
在Docker中，每一个在Union mount转哦给你的文件系统都被称为layers（层）。使用这种技术可以轻松实现快照，每个快照都是所有层的一个Union mount。
生成脚本的快照
使用快照可以帮助构建一个长时运行的脚本。总的想法是，将一个大的脚本分解为许多小的脚本（我喜欢称之为 scriptlets），并单独运行这些小的脚本，脚本运行后为其文件系统打一个快照 （Docker会自动执行此操作）。如果你发现一个scriptlet运行失败，你可以快速回退到上次的快照，然后再试一次。一旦你完成脚本的构建，并且 可以保证脚本能正常工作，那你就可以将它分配给其它主机。
回过头来再对比下，如果你没有使用快照功能了？当你辛辛苦苦等待了一个半小时后，脚本却构建失败了，我想除了少部分有耐心的人外，很多人是不想再来一次了，当然，你也会尽最大努力把系统恢复到失败前的状态，比如可以删除一个目录或运行make clean。
但是，我们可能没有真正地理解我们正在构建的组件。它可能有复杂的Makefile，它会把把文件放到文件系统中我们不知道的地方，唯一真正确定的途径是恢复到快照。
使用快照构建脚本的Docker
在本节中，我将介绍我是如何使用Docker实现GHC7.8.3 ARM交叉编译器的构建脚本。Docker非常适合做这件事，但并非完美。我做了很多看起来没用的或者不雅的事情，但都是必要的，这都是为了保证将开发脚本的总时间降到最低限度。构建脚本可以在这里找到。
用Dockerfile构建
Docker通过读取Dockerfile来构建镜像。Dockerfile会通过一些命令来具体指定应该执行哪些动作。具体使用说明可以参考这篇文章。在我的脚本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因为它可以让你在运行之前将外部文件添加到当前Docker镜像中然后转换成镜像的文件系统。你可以在这里看到很多scriptlets构成的构建脚本。
设计
1. 在RUN之前ADD scriptlets
如果你很早就将所有的scriptletsADD在Dockerfile，您可能会遇到以下问题：如果你的脚本构建失败，你回去修改scriptlet并再次运行docker build。但是你发现，Docker开始在首次加入scriptlets的地方构建！这样做会浪费了大量的时间并且违背了使用快照的目的。
出现这种情况的原因是由于Docker处理它的中间镜像（快照）的方式。当Docker通过Dockerfile构建镜像时，它会与中间镜像比较当前命令是否一致。然而，在ADD命令的情况下被装进镜像的文件里的内容也会被检查。如果相对于现有的中间镜像，文件已经改变，那么Docker也别无选择，只能从这点开始建立一个新的镜像。因为Docker不知道这些变化会不会影响到构建。
此外，使用RUN命令要注意，每次运行时它都会导致文件系统有不同的更改。在这种情况下，Docker会发现中间镜像并使用它，但是这将是错误的。RUN命令每次运行时会造成文件系统相同的改变。举个例子，我确保在我的scriptlets我总是下载了一个已知版本的文件与一个特定MD5校验。
对Docker 构建缓存更详细的解释可以在这里找到。
2.不要使用ENV命令来设置环境变量，请使用scriptlet。
它似乎看起来很有诱惑力：使用ENV命令来设置所有构建脚本需要的环境变量。但是，它不支持变量替换的方式，例如 ENV BASE=$HOME/base 将设置BASE的值为$HOME/base着很可能不是你想要的。
相反，我用ADD命令添加一个名为set-env.sh文件。此文件会包含在后续的scriptlet中：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env-1.sh
如果你没有在第一时间获取set-env.sh会怎么样呢？它很早就被加入Dockerfile并不意味着修改它将会使随后的快照无效？
是的，这会有问题。在开发脚本时，我发现，我已经错过了在set-env.sh添加一个有用的环境变量。解决方案是创建一个新的文件set-env-1.sh包含：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env.sh
if ! [ -e "$CONFIG_SUB_SRC/config.sub" ] ; then
CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
fi
然后，在所有后续的scriptlets文件中包含了此文件。现在，我已经完成了构建脚本，我可以回去解决这个问题了，但是，在某种意义上，它会破坏最初的目标。我将不得不从头开始运行构建脚本看看这种变化是否能成功。
缺点
一个主要缺点是这种方法是，所构建的镜像尺寸是大于它实际需求的尺寸。在我的情况下尤其如此，因为我在最后删除了大量文件的。然而，这些文件都仍然存在于联合挂载文件系统的底层文件系统内，所以整个镜像是大于它实际需要的大小至少多余的是删除文件的大小。
然而，有一个变通。我没有公布此镜像到Docker Hub Registry。相反，我：
使用docker export导出内容为tar文件。
创建一个新的Dockerfile简单地添加了这个tar文件的内容。
产生尺寸尽可能小的镜像。
结论
这种方法的优点是双重的：
它使开发时间降至最低，不再做那些已经构建成功的子组件。你可以专注于那些失败的组件。
这非常便于维护构建脚本。构建可能会失败，但只要你搞定Dockerfiel，至少你不必再从头开始。
此外，正如我前面提到的Docker不仅使写这些构建脚本更加容易，有了合适的工具同样可以在任何提供快照的文件系统实现。