目录[-]
一句话,现在的应用程序从源代码到运行阶段太复杂,没有标准的,通用的方式。
不论是Deis,Heroku,Flynn或者其他PaaS的目标,都是为了让2-4这3个阶段尽可能的简单。看了他们所设计的产品,简单到了什么程度?通过一个客户端命令行工具,实现了: 开发到构建: 用户通过git提交源代码,由PaaS自动构建镜像,并提供版本的管理——用户可以创建新版本(提交新代码或修改部署配置)、回滚老版本等。 部署到运行: 自动选择运行机器,为每个进程副本部署启动单独的容器,解决请求路由和负载均衡,并提供进程的管理——用户可以做扩缩容、查看日志、监控状态等、回滚历史的发布 为什么是这些功能?为什么这些功能不能分别由各种工具实现?在我看来,代码从发布到运行由两根轴组成。 纵轴: 源代码——发布包——可运行的镜像——进程这里的关系是一步接一步,顺序往下,不论你用什么工具什么平台,这4步都是流水式的向下。 横轴: 负载均衡、集群部署扩容缩容、健康检查、日志线上的应用,有以下几种情况
所以,上面这4项是一环扣一环,横向的互相关联,如果不在一个工具内同时提供这4项功能,就需要人工去填平这里面的信息交互,手动的整合这4个工具,从而带来复杂性。 约束及实现纵向编译:buildpackbuildpack填平的是从源代码到发布包的坑,就是一组编译脚本。 PaaS平台自己提供一些编译脚本,但也允许用户按照规范自己写编译脚本。 (脚本需要自己下载合适版本的编译器!) 如果使用Docker,用户提供的就是一个DockerFile或者Dockerimage地址,拿了直接就能跑起来的东西。 纵向运行:Procfilebuildpack让PaaS知道怎么编译程序,Procfile让PaaS知道怎么运行程序。 一个典型的Procfile就是像这样 cat ./Procfile web: bundle exec rails server -p $PORT 后面可以通过命令行来动态扩容程序 deis ps:scale web=4 纵向配置:环境变量运行的发布包在不同的环境下有不一样的配置,Deis的方式是通过环境变量。客户端的命令行工具上设置环境变量后,就直接发送给所有容器,重设这些环境变量,然后重启。 横向负载均衡:ngix横向日志:集中化的syslog获得日志横向部署:go写的小程序,用于部署Docker的Container |