作者:
小米生态云
为了让用户的云端应用管理更高效、更方便，今天从6个方面分享一些溜到飞起的Docker镜像优化小窍门。
一、明确指定镜像版本，管理更方便
为了让版本管理起来更方便，应用部署速度更快，在创建镜像的过程中，建议工程师们明确指定包含版本或者其他辅助信息的tag。
如果不指定镜像tag，默认会使用latest。每次启动应用实例时，都需要去镜像仓库检查镜像是否更新。这种方式不利于版本管理，对应用启动速度也有一定影响。
二、2种方法减小镜像体积
1、使用alpine版本的基础镜像，来减小镜像体积，以保证部署和扩容速度。
alpine是一个高度精简又包含了基本工具的轻量级Linux发行版，本身的Docker镜像只有4～5M大小。各开发语言和框架都有基于alpine制作的基础镜像，在开发自己应用的镜像时，选择这些镜像作为基础镜像，可以大大减小镜像的体积。
各种语言对应的基础镜像如下：
Java(Spring Boot): - openjdk:8-jdk-alpine,openjdk:8-jre-alpine等
Java(Tomcat) - tomcat:8.5-alpine等
Nodejs - node:9-alpine, node:8-alpine等
Python - python:3-alpine, python:2-alpine等
PHP - 基于php:7-fpm-alpine,php:5-fpm-alpine等镜像添加nginx，参考https://hub.docker.com/r/trafex/alpine-nginx-php7/
Ruby:ruby:2-alpine等
Go/可执行文件 - 直接基于alpine镜像，把编译后的可执行文件打入镜像。因为alpine不同于普通的Ubuntu/Centos等发行版，需要静态编译和链接应用代码，例如Go需要关闭cgo：CGO_ENABLED=0 go build ...
静态页面 - nginx:1-alpine等
2、保证Dockerfile中的清理命令在同一行，也可以减小镜像体积。
（上面的语句形式可以减小镜像体积。）
Dockerfile的每条指令都会产生一个文件层，组件的安装清理要放在一条命令里面。
三、利用分层机制，减小镜像传输大小
利用分层机制，可以减小镜像传输大小，加快镜像的推送和拉取速度Docker在build镜像的时候，如果某个命令相关的内容没有变化，会使用上一次缓存（cache）的文件层，在上传到镜像仓库时，这一层也就不需要上传了。利用这一点，在添加应用的时候可以分层添加，具体操作如下：（1）将不变或者变化很少的体积较大的依赖库和经常修改的自有代码分开
（2）因为cache缓存在运行Dockerbuild命令的本地机器上，建议固定使用某台机器来进行Docker build，以便利用cache（更多相关信息，可以参考 https://runnable.com/blog/distributing-docker-cache-across-hosts ） 举个例子：在构建Spring Boot应用镜像，我们可以通过以下操作来进行分层。
Step1：在Dockerfile所在目录，解压缩maven生成的jar包
unzip <path-to-app-jar>.jar -d app
其他类型的应用，比如Java WAR包，Nodejs的npm模块等，可以采取类似的方式。
四、避免使用进程管理程序，保证应用健康运行
在应用的某个实例崩溃或者非正常退出时，很多进程管理程序并不退出，导致平台无法检测到应用已经不可用，进而无法重启应用。所以要避免使用这类进程管理程序来启动镜像。
五、2种方法帮助Java应用运行调优
用以下两种方式可以让Java应用感知到容器的内存限制，避免内存溢出。1、使用新版本JavaSE 8 ( ≥ 8u131)，启动命令加上如下参数，自适应容器内存限制(MaxRAMFraction这个参数需要根据实际情况调整，1并不是普适值)2、直接指定heap相关的参数。这种方式缺乏灵活性，在确切知道内存限制大小的情况下可以使用。
六、2点要求保证数据和日志持久化存储
1、避免使用本地存储。应用镜像启动后，文件系统是临时的，崩溃后即被销毁。持久化数据，文件等需要存储到SDS，FDS等后端存储服务中
2、应用日志不能写到本地文件，需要写到标准输出或者标准错误，平台负责收集、汇总和后续的各种处理。
希望以上几点建议能够帮助大家避免或解决实际使用中的问题。
