什么是 stack ?

在回答这个问题之前我们先回忆一下前面部署 WordPress 应用的过程:

  1. 首先创建 secret。

  2. 然后创建 MySQL service,这是 WordPress 依赖的服务。

  3. 最后创建 WordPress service。

也就是说,这个应用包含了两个 service:MySQL 和 WordPress,它们之间有明确的依赖关系,必须先启动 MySQL。

为了保证这个依赖关系,我们控制了 docker secret  docker service 命令的执行顺序,只不过这个过程是手工完成的。

假如我们需要频繁地在不同环境中部署 WordPress 应用,如果每次都手工执行效率就太低了,而且容易出错。这是自动化的一个好机会,首先我们能想到的就是把这个过程写成脚本,大概内容如下:

563.png

稍微复杂一点的是第三步,通过 if 判断 MySQL service 是否运行,如果是,则运行 WordPress service,否则通过 while 继续等待,直到 MySQL 运行。

这个脚本大体上能够工作,实现了自动化,但有两个缺点:

  1. 目前只有两个 service,还比较简单。现在的应用通常都包含多个 service,特别是采用 microservices 架构的应用,几十个 service 是很正常的。用 shell 脚本启动和管理如此多的 service 将是一件非常有挑战的任务。

  2.  while  if 维护 service 之间的依赖关系也是很有挑战的,容易出错。而且如何判断 service 正常运行也不是件容易的事,脚本中只简单检查了 service 是否存在,并没有考虑 service 的实际运行状态。

我们希望有一种更高效和可靠的方法来部署基于 service 的应用,这就是 stack。

stack 包含一系列 service,这些 service 组成了应用。stack 通过一个 YAML 文件定义每个 service,并描述 service 使用的资源和各种依赖。

WordPress 的 stack 版本

如果将前面 WordPress 用 stack 来定义,YAML 文件可以是这样:

562.png

YAML 是一种阅读性很强的文本格式,上面这个 stack 中定义了三种资源:service、secret 和 volume。

 services 定义了两个 service:db  wordpress

 secrets 定义了两个 secret:db_password  db_root_password,在 service db  wordpress 的定义中引用了这两个 secret。

 volumes 定义了一个 volume:db_data,service db 使用了此 volume。

 wordpress 通过 depends_on 指定自己依赖 db 这个 service。Docker 会保证当 db 正常运行后再启动 wordpress

可以在 YAML 中定义的元素远远不止这里看到的这几个,完整列表和使用方法可参考文档 

stack 的 YAML 有了,下一节我们学习 stack 的相关操作。 

书籍:

1.《每天5分钟玩转Docker容器技术》

2.《每天5分钟玩转OpenStack》