Flynn初步：基于Docker的PaaS台

Flynn它是一个开源PaaS台，无论要部署的应用程序，你可以建立自己的主动性Docker容器集群的实现，能特性与组件设计大量參考了传统的PaaS平台Heroku。本文旨在从使用动机、基本对象、层次架构、功能组件、基本工作流这几个方面对Flynn做整体的介绍。

为什么须要Flynn

为了便于理解Flynn的作用与功能，让我们先来看看应用程序从开发到构建再到部署再到执行分别须要经历的几个实体状态：

AppPhases

更详细一点。以一个Java程序为例来描写叙述：

源码：包含*.java、log4j.properties、pom.xml等文件。
公布包：源码被编译打包后生成一个JAR包，这个就是公布包。
部署配置：比方每一个进程的启动命令、环境变量、系统属性等。
通常。这些配置会写在一个启动脚本里面。
进程：执行Java程序的实体。一个Java程序能够起多个进程，每一个进程启动不同的主类(实现了main()方法的类，一个JAR包能够包括多个主类）。

引入Docker后，公布包变成封装了JAR包与JDK环境的镜像，进程变成在相互隔离的容器里执行。可是，从源码到镜像、从镜像到执行容器这两步转换过程须要用户人工的操作。

尤其是后者的转换，涉及到集群资源调度、自己主动部署、配置管理、容器管控等一系列的复杂流程。

更进一步。在执行阶段还涉及扩缩容、日志查看、错误处理、执行监控等运维需求，假设所有人工操作将耗费巨大的工作量。

这时候类似Flynn这种PaaS出场了，基于Docker之上进一步封装了整个构建、部署、执行工作流，使得用户仅仅需简单地提交代码就可以完毕开发到执行的高速转换：

开发到构建：用户通过git提交源码，由Flynn自己主动构建镜像，并提供版本号的管理——用户能够创建新版本号(提交新代码或改动部署配置)、回滚老版本号等。
部署到执行：Flynn自己主动选择执行机器，为每一个进程副本部署启动单独的容器，并提供进程的管理——用户能够做扩缩容、查看日志、监控状态等。

Flynn的基本对象

以下我们来看看公布包、部署配置、进程这三个实体在Flynn中是怎样抽象的。例如以下图所看到的是其基本对象的关系描写叙述：

FlynnObjects

App：表示一个应用，全部其它对象都是环绕App而展开。
Artifact：表示应用的公布包，实际上相应一个Docker镜像。
Process：表示应用的进程。通过一个镜像能够启动多个不同的进程，每一个进程执行在自己单独的容器里。
Release：是应用公布态的抽象表示。
它在Artifact的基础上添加了一些不可变(immutable)的静态配置，比方每一个进程的启动命令行、环境变量、绑定port、等。要改动这些配置，须要生成一个新Release。
Release这样的不可变性是为了方便做Rollback。即应用随时能够回退到之前的Release。
Formation: 是应用执行态的抽象表示。它在Release的基础上添加了可变(mutable)的动态配置。即每一个进程的副本(replica)个数。
Job: 是进程副本的抽象表示，每一个Job相应一个执行容器。因此，在后文中能够看到。Job是资源调度的基本单元。

Flynn的层次架构

例如以下图所看到的。Flynn的架构自下而上分为两个层级——Layer 0和Layer 1。简单地理解，能够觉得Layer 1负责接受用户请求，封装成应用的执行指令。再由Layer 0解决在哪里执行、以什么方式执行的问题。详细一点讲，Layer 0面向的对象是Formation，负责将底层的集群资源封装成可执行Formation的一台主机；Layer 1面向的对象是App。负责将App从源码构建成Artifact。进而封装成Formation提交给Layer 0去运行。

这样的分工明白的层次划分，使整个系统很灵活。相互松耦合。便于随意组件的替换(比方。甚至能够把Layer 0替换成不用容器去运行Formation)。

FlynnComponents

Flynn的功能组件

以下总结一下组成两个层级的各个组件及其功能(全部组件自身都能够执行在容器里)：

Layer 0

Scheduler: 资源调度器，定期从Layer 1获取Formation的更新。再依据每一个Formation的部署配置生成一个个的Job，最后从集群中选择合适的机器去执行这些Job。
Host Service: 执行在集群每台机器上的agent，负责管控执行在本机的容器，并收集执行状态信息。
Host Leader：一个特殊的Host Service，做为"cluster leader"，负责维护整个集群的状态信息(比方有哪些机器、每台机器上执行的Job等)。并提供给Scheduler用于资源调度。
Discoverd：基于etcd的服务发现模块，提供容器间的发现机制。实际上。Flynn自身的组件间通讯也是通过Discoverd来相互发现的。

Layer 1

CLI：提供给用户使用的命令行工具。
Controller：为Flynn系统的入口，封装了核心对象(比方app/artifact/release/job)的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。
它维护的REST对象将持久化到postgre数据库。
Layer 0的Scheduler就是通过Controller的接口来获取Formation更新的。
GitReceiver：接受用户git push源码的SSHserver。接受到git push后将触发Receiver。
Receiver：基于buildpack机制。利用SlugBuilder从源码包构建slug包。
buildpack和slug都是从Heroku借鉴过来的概念。简单地理解。buildpack是一组用于构建源码的脚本，buildpack能够多种多样，每一个buildpack可构建某种类型的源码，这样的类型能够是不同的语言(比方Java、PHP)、不同的构建方式(比方maven、gradle)；而slug则是buildpack构建生成的部署包。包括了编译输出文件、依赖库文件等执行环境。
BlobStore: HTTP文件server，用于上传/下载slug包。
SlugBuilder：接受源码包，基于某种buildpack构建生成slug包。选择哪一种buildpack能够显式地指定，也能够由SlugBuilder依据源文件自己主动匹配。
SlugRunner：执行slug包，会从BlobStore下载应用的slug包。

Flynn的工作流

以下通过一个样例来展示Flynn各个组件的工作流。使用Flynn来构建部署应用最主要的流程是以下三步：

用户创建app：

flynn create myapp

FlynnCreateApp

用户提交app代码：

git push flynn master

FlynnGitPush

用户扩容app的进程：

flynn scale web=2

FlynnScaleApp

对照Kubernetes

Kubernetes是Google开源的Docker容器集群管理系统，为容器化的应用提供资源调度、部署执行、服务发现、扩容缩容等整一套功能，更具体地介绍请參考作者的还有一篇文章《Kubernetes初探：原理及实践应用》。

在应用的抽象上，Flynn与Kubernetes有本质的差别：Flynn的应用管理单元是App，仅仅相应一个Docker镜像，但能够由这个镜像来启动多个进程，而且每一个进程能够单独扩缩容；而Kubernetes的应用管理单元是Pod，可相应多个不同的Docker镜像，而且Pod内的各个容器保证会执行在同样的机器上，整个Pod作为扩缩容的基本单位。

另外一个根本的差别是Kubernetes不提供镜像构建与版本号管理的功能。因此，Kubernetes仅仅能看成是面向容器而不是面向应用的系统。

当然，我们能够在Kubernetes之上扩充这些功能。

对照Deis

与Flynn类似，Deis也是受到Heroku的启示，基于Docker之上构建的PaaS平台。因此，从功能特性到应用抽象，两者是大同小异。

至于两者的差异，了解不是非常多，这里提三点：第一，Deis是用Python开发的，而Flynn是Go；第二。Deis依赖于CoreOS。而Flynn由于全部组件都可执行在容器里，没有OS的依赖；第三。Deis在构建阶段，除了buildpack方式构建外。还支持Dockerfile直接以两种方式镜像上传。较Flynn更灵活。