k8s学习笔记（三）：Docker镜像的构建

概述

从前文中可以大致了解到，Docker和k8s之间的爱恨纠葛。“镜像”应该算是Docker和k8s之间的一条纽带，Docker是提供和存储镜像的一方，而k8s则是基于镜像管理集群的一方。Docker仓库给我们提供了很多通用镜像，但是不同的开发场景下，对于镜像的需求必然是定制化的，因此，我们需要了解如何制作Docker镜像。

构建镜像

构建镜像的方式有两种：

• 基于已有镜像commit
• 基于Dockerfile文件build

其实无论是采用哪种方式，都是基于已有镜像进行下一步开发，是站在巨人的肩膀上，而不需要一切从零开始，这给我们构建镜像带来便捷。本文将基于ubuntu基础镜像，构建一个包含docker_test.txt文件的新镜像。

Docker commit

Docker commit其实是针对某个镜像进行内部变更形成新镜像的行为，它是基于一个基础镜像启动容器，在容器内部进行更新修改操作，再将修改后的容器保存为镜像的行为。可以模拟一下这个操作：

1. 基于ubuntu镜像创建容器并进入交互模式：

docker run -i -t ubuntu:15.10 /bin/bash

当前机器没有该镜像时会自动从远程仓库拉取，可以看到已经进入了这个容器内部，此时所有的命令行操作都只与该容器有关而和外部集群环境无关。
2. 在根目录下创建docker_test.txt文件：

3. 执行exit退出容器并查看容器信息，可以看到刚刚退出的容器id为e6555d33528c：

docker ps -a

4. 执行docker commit构建新镜像，冒号前的为仓库名，冒号后的为TAG：

docker commit e6555d33528c docker-test:v0.1

此时可以看到，本地仓库中已经有刚创建的镜像docker-test:v0.1了。
5. 本地仓库和远程仓库的镜像名称不一致，需要重新打tag再推送到远程仓库（此处的远程仓库名为elvisxliu/docker-test）：

docker tag docker-test:v0.1 elvisxliu/docker-test:v0.1
docker push elvisxliu/docker-test:v0.1

此时在远程仓库（本文使用的是https://hub.docker.com/）已经能够看到该镜像了，并且能够在右侧看到该镜像的存储层是进行了ADD file操作：

接下来我们基于该镜像构建容器看看，是否是我们制作出的容器。可以看出，该镜像的确制作成功了，新镜像中已经包含我们登陆容器所做的修改，根目录下已经有docker_commit.txt文件。

注意：这种方式意味着我们可以登录镜像进行任何变更，并将这些变更存储下来成为新的镜像。但是这种方式有一点弊端，想必大家也感觉到了，就是在容器内部的所有操作其实都是无记录的，其它人使用该镜像时并不知道你在这个镜像中做了什么操作，不利于镜像治理。最好的方式应该需要将镜像内的所有变更记录下来，使得其它开发者也可以基于新镜像进行再次构建，这就是另一种基于DockerFile的镜像构建方式。

Docker build

Docker build的方式是基于DockerFile进行镜像构建的，DockerFile文件语法在本文中暂不展开进行详细说明。目前只需要知道FROM xxx代表着基础镜像，RUN xxx代表着在容器内部执行shell命令，于是我们可以简单创建出如下DockerFile：

# Version: 0.0.2
FROM ubuntu:latest
RUN touch /docker_test2.txt

然后执行如下命令，会在当前目录下寻找DockerFile文件并基于此构建，-t参数指明了镜像仓库名和版本号：

docker build -t=“docker-test:v0.2” .

至此，该镜像就构建完成了，推送到远程仓库的方式和Docker commit一致。由于这种方式存在构建描述文件DockerFile，一般来说，会在工程中直接存储该文件，基于该文件就可以build出镜像，不一定需要推送到远程仓库。

接下来我们基于该镜像启动容器，可以看到目录下存在docker_test2.txt文件。

总结

本文介绍了两种镜像构建方式：基于容器构建和基于DockerFile构建。在工程上使用时，推荐通过DockerFile进行镜像构建，能够较好地对构建逻辑进行溯源，并且能够控制镜像的文件层级，使其存储层较少，镜像不至于过于臃肿。