在自动化模式中应用运行MySQL

　自动化模式（Autopilot Pattern）是一种设计应用与基础架构的方式，旨在推动应用系统中的各个组件自动化。组成应用的每个容器都有自己的生命周期，我们将这些生命周期的行为封装到了应用的容器中，而没有依赖外部架构。
　　下文将讲述我们是如何借助这种模式，部署和运行其中一种常被认为难以在Docker容器中运行的复杂、有状态的应用：MySQL。
　　运行MySQL
　　我们从常见的MySQL部署开始：从主节点到副本节点执行异步复制。客户端查询副本节点，或对主节点执行写入操作。这个架构会引发一些关于服务发现和拓扑结构的问题：
　　副本节点如何知道在哪儿能找到主节点？主节点如何告知副本节点从哪儿开始执行复制？客户端如何知道在哪儿找到节点，哪些节点接受写入操作？
　　在执行部署后，我们还有一系列疑问：
　　我们怎样进行备份？如何主节点出现故障，如何对副本节点进行升级来进行替换？在故障转移期间，其他的副本节点怎样知道在哪儿能找到新的主节点？客户端如何知道我们执行了故障转移？
　　当然，其中一些问题已经有了现成的答案。配置管理工具经常会负责应用中架构的配置工作，但如果运行时应用拓扑出现变更，配置管理工具是无法回应的。数据库即服务（DBaaS）负责执行管理工作，不过如今大多的配置已不再控制范围内，成本也更为高昂。
　　对应用来说，还有一个选择就是执行自动化运行。在这种模式下，要对应用模式执行优化，代表着要让应用知道如何适应整个系统：启动、关闭、缩放、发现和恢复。最大限度地减少人为干涉，意味着错误更少，有更多的时间花在更重要的业务上。
　　很明显我们没打算重写MySQL，因此需要找出办法为现有的应用提供这个功能，而我们选择了Containerbuddy。
　　架构
　　我们需要利用这些组件部署MySQL：
　　MySQL：我们使用了MySQL5.6（Percona Server），使用XtraBackup运行热快照备份；
　　Consul：用来协调复制与故障转移工作；
　　Manta：Joyent的对象存储系统，为存储MySQL快照备份提供安全经久的服务；
　　Containerbuddy：包含在我们的MySQL容器中，负责编配bootstrap behavior，通过onStart、health、onChange处理器，调用Consul中存储的key和checks协调复制的工作。
　　triton-mysql.py：Containerbuddy在执行MySQL编配的繁重任务时会调用到的小型Python应用。
　　所有代码与配置都能在GitHub中找到。
　　
　　架构图
　　当开始新的MySQL节点时，Containerbuddy的onStart处理器会调用triton-mysql.py。Containerbuddy会fork Percona Server并等待，同时运行onStart、health、onChange处理器。结果就是类似这样在MySQL容器中的进程树：
　　root@993acf351cd9:/# ps axo uid，pid，ppid，stime，cmdUID PID PPID STIME CMD root 1019:02/bin/containerbuddy mysql 94119:02|_ mysqld --console --gtid-mode=ON.。.root 107119:04|_ python /bin/triton-mysql.py healthroot 109119:04| |_ /usr/bin/innobackupex --no-timestamp.。.root 120119:06|_ python /bin/triton-mysql.py healthroot 121119:06|_ mysql -u repl -p.。.
　　自组装
　　由于我们只用了几个Docker镜像，无需使用单独的调度器来管理发现与引导服务，简单地使用下面的命令就可以运行堆栈：
　　docker-composeup -d
　　出现的第一个节点会登录Consul发现服务，尝试并查找主节点。如果第一个节点发现主节点还不存在，则将自身作为主节点，并初始化数据库。使用Consul会话通过atomic锁写入密码，这样就会有一个且仅有一个节点成为主节点。