基于Kubernetes的新版小米应用引擎在小米生态云上线3个多月来,深受大家喜爱。为了让用户的云端应用管理更高效、更方便,今天从6个方面分享一些溜到飞起的小窍门。
明确指定镜像版本,管理更方便
为了让版本管理起来更方便,应用部署速度更快,在创建镜像的过程中, 建议工程师们 明确 指定包含版本或者其他辅助信息的tag 。
如果不指定镜像tag,默认会使用latest。每次启动应用实例时,都需要去镜像仓库检查镜像是否更新。这种方式不利于版本管理,对应用启动速度也有一定影响。
2种方法减小镜像体积
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等
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
Step2: Dockerfile 我们把应用的内容分成4个部分COPY到镜像里面:其中前面3个基本不变,第4个是经常变化的自有代码。最后一行是解压缩后,启动spring boot应用的方式。
其他类型的应用,比如Java WAR包,Nodejs的npm模块等,可以采取类似的方式。
避免使用进程管理程序,保证应用健康运行
在应用的某个实例崩溃或者非正常退出时,很多进程管理程序并不退出,导致平台无法检测到应用已经不可用,进而无法重启应用。所以要避免使用这类进程管理程序来启动镜像。
2种方法帮助Java应用运行调优
用以下两种方式可以让Java应用感知到容器的内存限制,避免内存溢出。
1、 使用新版本JavaSE 8 ( ≥ 8u131) ,启动命令加上如下参数,自适应容器内存限制(MaxRAMFraction这个参数需要根据实际情况调整,1并不是普适值)
2、 直接指定heap相关的参数。 这种方式缺乏灵活性,在确切知道内存限制大小的情况下可以使用。
2点要求保证数据和日志持久化存储
1、 避免使用本地存储。 应用镜像启动后,文件系统是临时的,崩溃后即被销毁。持久化数据,文件等需要存储到SDS,FDS等后端存储服务中
2、 应用日志不能写到本地文件 , 需要写到标准输出或者标准错误,平台负责收集、汇总和后续的各种处理。
希望以上几点建议能够帮助大家避免或解决实际使用中的问题,让新版应用引擎为更多用户的应用管理提供强有力的支撑。