虽然 DockerHub 提供了大量的镜像,但是由于企业环境的多样性,并不是每个应用都能在 DockerHub 找到对应的镜像来使用。那就要求企业的运维人员掌握制作 Docker 镜像的技能。在开始打包应用前,你首先要明白这两件事: 第一件事是选择适合你的方式来生成镜像: 1. 通过 Dockerfile 来自动编译生成镜像,实现构建镜像的需求。 2.通过容器内操作,并进行 Commit 来实现打包生成镜像。第一种思路多用于用户交互较少的时刻,比如软件部署时无需输入任何命令的应用。第二种思路用于用户交互较多、安装过程中配置较多的应用。 第二件事是你需要注意,如何拆分现有的应用,来实现打包。Docker 容器化的应用应当是功能最小化的应用。这里的拆分并不是指将每个软件拆分成为一个容器,而是强调实现功能最小化。拿最常见的 LAMP 架构来讨论。最小化的结构应当是 Apache 和 PHP 在一个容器内, MySQL 在一个容器内。而不是将 Apache 、 PHP 、 MySQL 各自拆分一个容器。 Apache 和 PHP 的有机结合使结构内的应用完整的实现了 PHP 解析和 Web 页面的功能,而 MySQL 独自承担了数据存储的功能。而各自拆分一个容器会导致架构极为复杂,在进行容器扩容时也容易受到影响。一般来说,你可以将应用拆分成为 2-3 个容器, 2 个容器的情况下,是数据存储和应用程序各自一个容器。对于部分应用,可能还有缓存系统,同样也要单独放置在一个容器内。这样的结构下,在你需要扩容时,就比较容易,根据你的需要,可以随时扩容缓存系统或应用程序。
明了了上面的两件事,接下来进入应用打包的环节。
首先,我们先看下 Docker 官方打包的 Tomcat 镜像的 Dockerfile.
我们可以看到,里面大量执行了 Linux 命令,来安装,部署软件,并且对于需要确认的命令都加入-f 来强制执行。确保没有交互,因为在编译镜像的过程中,无法进行交互操作,如果碰到交互操作,卡住就会导致镜像编译的失败,故而 DockerFile 不支持需要输入命令的安装脚本等
当然,对于 Dockerfile,我们同样也有一些最佳实践:
除了通过 Dockerfile 来打包生成镜像外,也可以通过 Docker Commit 来生成镜像。通过 Commit 打包的镜像多是由于应用本身在部署时有大量的交互内容,无法通过命令来指定。
在通过 Commit 打包镜像时,我们需要如下操作:
1.启动一个基础镜像容器,并进入 console
docker run -i – t centos:6.7
上面的命令创建了一个基于 CentOS 6.7 的容器,并进入到容器内
2.执行配置环境的命令 登陆容器后,可以执行各种 Linux 下的命令。
等配置完环境后,打开一个新的控制台
执行命令docker ps
,可以看到正在运行的容器
比如我的容器的 ID 就是 35f1c2ae1f7e
3.将容器打包成镜像
执行命令 docker commit 35f1c2ae1f7e mynewimage
就将容器35f1c2ae1f7e打包为新的镜像mynewimage了
可以执行docker images
查看镜像
另外,蜂巢的保存为镜像的功能,就是基于此功能制作的,通过云端容器 Console 的操作,并打包成为镜像,大大降低了上云的难度。无需在本地部署 Docker 环境,即可实现应用的容器化;同时云端打包镜像比本地打包速度也要更快些,大大提升了上云的速度。
PS.其实官方推荐:单个镜像单个进程。这样的情况下,有利有弊利在于,单进程容器更加适合纵向扩展和复用。但是,在较大的产品框架下,可能容器之间的关联会非常复杂。创建一个应用可能会需要创建非常多的容器。所以,在我看来如何划分,还是应该看使用场景和技术路线,量身定制.