阿里技术专家：持续交付与微服务背后的实践逻辑

前面我们提到了一种模式,即每次都新做出来一台机器,然后把这些Ansible(或者其它什么工具)脚本对着这些干净的机器运行一遍.最后再把特定版本的软件部署上去.也就是说每次部署都会把原来的虚拟机实例干掉,再重新生成一台.在实际场景中,同一个应用会存在多个实例,我们没有必要对每台机器都这么做,只需要把一台机器使用Ansible装好之后,再打个镜像,然后通过这个镜像启动多台实例.

这种模式能够带来的好处是显而易见的,不但保证了环境的一致性,且扩容非常容易,只需要把同一个镜像再多启动几个实例,然后挂接到相应的负载均衡中即可.而且永远不需要害怕线上机器crash掉.按照镜像再启动一个就可以了.但这种模式带来的问题也是显而易见的,首先打虚拟机镜像的时间是很长的.其次这种做法就要求服务器是没有状态的,也就是不能在硬盘上存文件,写log.还好现在的云服务提供商(AWS,阿里云等)都有相应的产品来解决这些问题.

对于上传的附件和图片等文件来说,有两种方式：

这两种方法能够在一定程度上解决问题,但终究不是本地磁盘,在读写速度和并发写的处理等方面都会多多少少存在一定问题.所以只能适用于对这些指标要求不高的场景.

对于log来说,也有两种方式：

使用上述的方式时,所有的代码,软件和配置的变更都需要走这么一个流程：各种各样的自动化测试、镜像构建,实例化镜像启动服务.所有的变更,不管再小,都会走这样的流程,而不会直接更改在实例机器上.所以实例机器就是不可变的了.这就是所谓“不可变服务器”的概念.

但这个过程是比较漫长的.所以对于紧急发布之类的场景,是很让人捉急的.而Docker技术的出现就很好的解决了这个问题.Docker基于Linux Container(LXC)技术,能够做到轻量级的虚拟化.

Docker采用了分层的文件系统,所以如果我在包含Java的镜像的基础上打一个包含Tomcat的镜像,只需要创建出一层只包含Tomcat的镜像,然后和原先的包含Java的镜像叠加在一起,就可以形成一个完整的可运行的镜像.

在这种分层的镜像机制下,如果每次只修改最上面一层镜像,则构建的速度是很快的.而最上面一层通常就是添加应用程序.以Java Web程序为例,包含Java和Tomcat的镜像可以作为一个 基础镜像.然后每次生成的WAR包通过Dockerfile(用于构建Docker镜像的描述文件)中的ADD指令添加到新的镜像层中即可.

举个例子：这里有一个Java的web应用,通过运行“./gradlew war”的命令会在本地目录下生成’build/libs/bookstore.war’.然后编写如上图的Dockerfile,它会把本地生成的war包ADD到Docker镜像中.运行’docker build . -t bookstore: <版本号>’就可以生成一个镜像.

通过Docker的history命令可以看到1.5和1.3两个版本的最上面一层是不同的,但它们的基础镜像层都是“25e98610c7d0”.最上面一层的大小是6.106M,也就是比一个war包稍微大了一点点.

（编辑：广西网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!