这两天学习了Dockerfile感觉这个地方知识点挺多的，而且很重要，所以，今天添加一点小笔记。
官方Tomcat镜像
地址：https://hub.docker.com/_/tomcat/
镜像的Full Description中，我们可以得到许多信息，这里简单介绍几个：
1.Supported tags and respective Dockerfile links
支持的标签，以及对应的Dockerfile链接。一个Dockerfile可以对应多个标签，我们将以8.5.16-jre8版本的Dockerfile进行分析。
2.How to use this image
如何使用本镜像，包括了以不同方式运行容器的命令，以及一些主要环境变量。这里讲的不够详细，我们会详细讲解。
准备知识：APR、Tomcat Native、Tomcat的APR模式
APR是Apache Portable Runtime的简写，其实就是一组用C语言编写的动态链接库，提供统一的API接口，用于访问操作系统底层。详见：http://apr.apache.org/。
Tomcat Native的主要作用是为tomcat提供访问本地资源的功能。即利用APR库，访问网络、生成随机数等。Tomcat Native依赖于APR、OpenSSL、JDK。详见：http://tomcat.apache.org/native-doc/。
在配置好Tomcat Native后，可以在tomcat配置文件中开启APR模式。开启之后，Tomcat就会直接调用APR库访问网络，不用再通过jvm中转。
因为APR和Tomcat Native是和具体的操作系统紧密关联的，并不像java应用那样编译好后就可以跨平台使用。所以tomcat默认不安装这些功能，而是根据需要，以及具体操作系统，手工编译源码安装。从一些资料上来看，开启tomcat的APR模式后，对tomcat的性能并不一定会有很大的提升（在某些情况下甚至可能下降）。是否开启APR模式要看具体的情况。个人认为，一般情况下，真到了要挖掘Tomcat性能的时候，使用tomcat集群将会是一种更好的解决方案，这对系统的性能、稳定性、可靠性都有提升。
分析Dockerfile（tomcat:8.5.16-jre8）
地址：https://github.com/docker-library/tomcat/blob/master/8.5/jre8/Dockerfile
注意，这里以master分支的Dockerfile链接为例，和DockerHub上的Dockerfile链接可能会不一致，不过不影响我们接下来的分析。以下就是这个Dockerfile的内容，我加了注释加以说明：
-------------------------------------------------------
此Dockerfile的主要功能可归纳为：
1.以openjdk镜像为基础镜像进行构建。
2.安装Tomcat Native，及其依赖库（比如APR、OpenSSL等）。验证是否正确安装。
3.下载Tomcat，检查签名，解压、清除无用文件等。
4.暴露8080端口，配置入口命令。
总的来说，此Dockerfile的功能还是比较清晰的，如果要自己构建自己的Tomcat镜像，可以参考本Dockerfile。另外，Tomcat的Dockerfile应该是自动生成而非手工编写，因为第一，Tomcat的有很多版本的Dockerfile，手工维护工作量大；第二，存在一些我认为不是很很合理的地方（比如从key server上获取很多key）。所以大家在分析一些官方Dockerfile时，如果遇到一些感觉不是很合理的地方也别太纠结。
如何使用官方镜像
$ docker run -d --name tomcat-test -p 8888:8080 tomcat:8.5.16-jre8
以上指令将使用本镜像启动一个容器，你可以通过http://本机ip:8888访问到容器中的Tomcat。这种方式并没有部署应用，所以其实也没什么实际意义。
$ docker run -d --name tomcat-test -p 8888:8080 \
-v /home/myWebApp:/usr/local/tomcat/webapps/ROOT \
-v /home/myWebAppLogs:/usr/local/tomcat/logs \
tomcat:8.5.16-jre8
以上指令增加了两个volume，将/home/myWebApp挂载到容器中的/usr/local/tomcat/webapps/ROOT，将/home/myWebAppLogs挂载到容器中的/usr/local/tomcat/logs路径。容器启动后，tomcat的根应用将会是myWebApp（通过http://本机ip:8888访问），并且tomcat的日志将会输出到/home/myWebAppLogs路径下。
此后，如果容器被删除，应用和应用的日志也不会随容器一起删除。更新应用时，只需要更新/home/myWebApp路径，再重启容器即可。
如果不想把应用挂载到根目录下，可以更改volume配置，比如：-v /home/myWebApp:/usr/local/tomcat/webapps/myWebApp，再通过http://本机ip:8888/myWebApp访问。
注意：如果想把myWebApp内部的日志也输出到/home/myWebAppLogs路径下，请配置myWebApp的日志文件的输出路径为Tomcat日志路径（相对路径），例如：logs/myLog.log。这样，myWebApp的日志文件将会输出至/usr/local/tomcat/logs下（因为挂载了volume，其实是输出到/home/myWebAppLogs路径下）。
从规范的角度讲，其实��种应用部署方式并不值得推荐，因为部署还是出现了环境相关性。也就是说，必须先把应用目录、日志目录指定好，才能进行部署。而且如果要一台机上要部署两个相同的应用进行负载均衡也比较麻烦（要建两套应用和日志目录，并且修改容器启动命令），难以实现自动化部署。但话又说回来，我相信这种部署方式还是会受到大部分人欢迎的。目前我们公司在测试环境中也普遍使用这种模式，以便一台测试服务器部署多个应用（Tomcat），彼此之间完全没有关联和影响。
如果要做到完全环境无关性部署，可以考虑自己在官方Tomcat镜像的基础上，构建出一个新的镜像。在这个新镜像的Dockerfile中直接下载并部署myWebApp，并使用某些工具或框架，将Tomcat和myWebApp产生的日志，上传汇总到一个统一的日志服务中。这样，如果要再部署一个相同的应用，只要给我一台装有Docker环境的机器，我执行一条指令即可（同一Docker环境下注意端口冲突）。这种方式有利于自动化部署，在服务器数量较多的情况下比较合适。当然，这种方式也有比较麻烦的地方，就是每发布以一个应用版本，都要重新构建一个新的镜像。
关于自动化部署，还可以参考Docker Compose和Kubernetes，这里不做深入（主要是本人对这块的了解和应用也不够多）。
官方镜像的不足
在本镜像的实际使用过程中，还是遇到了一些问题：
1.为了照顾到全球的镜像使用者，官方的openjdk镜像和Tomcat镜像都没对时区进行定制化配置，默认为UTC时间（比北京时间早八小时）。如果应用内部也没有进行时区配置，那么应用获取到的系统时间也将会是UTC时间。
2.在某些机器（或虚拟机）上，jdk的随机数生成器初始化用时过长，导致Tomcat启动用时过长。我用过的阿里云ECS就是这种情况。
这些问题将会在之后我们自己构建的Tomcat镜像中解决。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
更多Docker相关教程见以下内容：