一种开源的部署解决方案-fleet

fleet是coreos的子项目之一，是一个分布式的container发布工具，用于进行cluster中任务的提交和管理；

那通过fleet来进行部署发布有何优势？需要具备什么样的条件？有什么需要考虑的问题？

一、fleet的整体架构

二、fleet的运行机制

1、定义systemd的unit描述文件，描述文件中指定要执行的命令（如启动的docker image或其它命令等），运行该job需要满足的一些依赖条件等;

2、将该描述文件commit到registry中， Engine检测到新任务创建一个joboffer；

3、所有线上机器通过fleet agent watch joboffer, 发现自身满足require描述，则要求执行该任务；

4、engine将该任务分配给某一agent;

5、agent启动任务，并把JOB状态反馈到registry中；

三、fleet的特色

从fleet的架构中可以看出，它采用了一个与中心化发布完全相反的思路，采用这种方法有什么优势或者哪些值得借鉴呢？

1、agent主动请求任务，而非控制端发布任务，弱化了部署前对主机和任务的对应关系的依赖，比较容易就可以进行job copies的控制；

2、天生具备针对任务的调度功能，在Engine上可以设置各种条件来进行任务的分配；

2、通过实现中心化的控制端进程远程管理（虽然暂时也用的ssh+信任关系），但这个功能对动态调度系统来讲可以说是非常必要的一个功能，即便不能提前知道任务实际会运行在哪里仍然要以轻松进行访问和管理；

四、使用fleet所需要的必要条件

1、systemd —— fleet使用systemd来作为JOB启停管理、状态查询；

2、docker —— systemd描述文件只描述JOB的启动命令，不包含实际文件，对复杂应用来说，只有封装到docker image中一种方式；

五、fleet在工业应用中还可能的不足

1、如果想要使fleet作为任务的分发部署管理系统，那么必然要依赖docker, 而 docker应用到工业化中仍然还有很多工作要开展，如果仅作为任务管理系统，那需要以fleet管理的思路构建一套部署分发系统，比如支持systemd的管理方式；

2、Engine似乎把任务分发之后MS就没有再管了，后续的事情都通过集中管理工具fleetctl来进行，也就是说这每一次动作的触发都是主动的。缺少一个自循环的状态感知机制，比如start了job, 主动停止，它会反馈回状态，但并不会再起一个新任务；如果异常中止，则没有状态反馈；

NoOps