Cloudify：打通应用和基础架构自动化交付的“任督二脉”
http://chuansong.me/n/2543024
1. Cloudify概况
Cloudify是一个开源的云应用编排系统，可以让你的应用自动化在各种不同的云上方便地部署。
由GigaSpaces公司（一家总部位于纽约的以色列中间件技术公司）开源。GigaSpace也是Openstack的支持者，经常参与Openstack全球的技术峰会，个人感觉其在技术路线选择上也受到Openstack的影响。
具体来看，Cloudify的技术路线选择以3.0版本为分水岭，在3.0版本以前完全基于Java技术栈开发，主要使用Groovy脚本语言。从3.0开始，整个技术栈几乎完全转移到了Python上（除保留了一个Java开发的组件外）。
具体转换的原因不得而知，但从我粗略的分析看，随着Python技术生态的逐渐完善，以及Openstack等基于Python技术的云管平台的逐渐成熟，这些应该都对Cloudify的技术路线选择起到一定的推进作用。不管怎么说，从整体看，Cloudify技术栈是往更轻量级、灵活便捷的方向转移。
2.那么Cloudify究竟是干什么的？
我们先看官网给出的两段文字
From Blueprint to Production
With Cloudify you can deploy the same application in your own data center or on the cloud of your choice using your favorite automation and configuration management tools. This enables you to build a robust continuous delivery pipeline by standardizing deployment, orchestration and build processes to create smoother transitions between development and production environments.
第一段介绍，从一个蓝图（Blueprint）到生产环境。简单来说，就是允许运维和开发人员使用一种语言描述IT拓扑架构，并且部署到任意环境中，确保环境间的无差异。
Automation & Orchestration Through the Entire App Lifecycle
With built-in auto-everything rules - scaling, failover, or even your own custom metrics, you can rest assured that Cloudify has you covered. Cloudify’s post-deployment support even extends to effortless infrastructure upgrades and fine-tuning through our blueprint & custom command technology.
第二段介绍，主要强调了Cloudify专注在应用的全生命周期管理，并且内置实现弹性扩缩容、容错等机制。
我们回到Cloudify的业务和技术定位上。
从自动化运维的范畴去看，自动化分为：
基础架构自动化->中间件自动化->应用自动化->业务自动化四个层次
Cloudify重点关注应用自动化，承担了部分业务自动化的工作。
从云IaaS、PaaS、SaaS分层看，Cloudify是一个典型的面向应用编排自动化的PaaS平台。
3. Cloudify典型应用场景
从细化功能看，Cloudify主要提供了以下几个方面的功能和能力：
场景1：基础架构的创建、更新。
基础架构安装、更新（借助整合各类私有和公有IaaS平台，目前可直接集成的IaaS包括VMware、Openstack、Cloudstack、AWS、Softlaye等主流平台，另外也支持与Docker，Kubernetes的整合，同时在3.3版本正式推出与NVF的整合功能，实现网络组件的自动化交付）
目前3.3版本主要实现基于Openstack NVF和基于Vmware的NVF自动化交付从上述场景衍生出两个场景：
-
混合云环境下的应用拓扑部署，满足企业部分应用组件在私有云，部分业务组件在公有云的场景。
-
跨云迁移，实现跨云环境的整体应用迁移。
场景2：交付(Provision)。
通过Cloudify Blueprints定义IT组件间的关联关系，使得在功能上类似Docker Compose，在编排标准上更具备通用性。Cloudify采用了OASIS（XML标准制定者）的TOSCA编排规范。
场景2衍生的场景主要是应用的持续部署和持续发布场景，满足了Devops的需求。
场景3：IT自动化运维工作编排。
实现结果类似于腾讯蓝鲸系统，允许将IT内部的各项原子自动化运维工作编排在一起，形成更为复杂的复合自动化运维任务。
为了提升Cloudify整合的通用性，当前版本已经内置支持Puppet、Chef、Saltstack、Ansible等自动化运维和配置管理平台。同时支持SSH方式进行脚本的调用
其他场景
此外，Cloudify内部也是一个小生态系统。内置的监控、日志、流程引擎，同时基于Plugin架构可集成企业已有的各类监控平台（或其他平台），实现故障自动恢复、服务降级等运维场景。
4. Cloudify架构
以上是Cloudify的架构图，分为Client端、Cloudify Manager和Application VM端。
Client端分为：GUI端和CLI端，目前GUI端没有开源，只存在于商业版中，当然感兴趣的同学可以自行到官网下载体验。
Cloudify Manager是Cloudify的主体部分，也是管理端，目前已经推出基于Docker的Cloudify Manager，更便于部署。具体说明等会展开详述。
Application VM是被管环境，通过Cloudify Agent进行纳管。实际环境中，Application VM 可能是 VM 、 Docker或是物理机。
5 Cloudify核心组件
首先我们罗列一下Cloudify的技术栈。
Nginx：HTTP和 反向代理 服务器，接收来自GUI界面的请求，并转发给后端的RestAPI（Swagger）。
Elasticsearch：Blueprint、instance、metrics、log、events的全文检索。
Logstash：日志进行收集、分析。
RabbitMQ：metrics、events、task的异步执行。
Riemann：metrics stream processor（基于Java），一个规则引擎，可以基于metrics进行内存级的过滤、处理。
InfluxDB：分布式时序数据库InfluxDB，用于存储metrics。
Grafana：仪表盘图形化展示组件，用于展示influxDB的数据。
Flask：a microframework for Python，整合Swagger提供Restful API。
Gunicorn：Python WSGI UNIX的HTTP服务器。
Celery：Python Distributed Task engine，通过RabbitMQ实现异步分布式任务处理，用于实现Cloudify的工作流。
Fabric： SSH Library。
Diamond：Python监控组件，提供Monitoring Agent。
各技术栈的调用关系如下图：
各技术组件间的关系应该还是比较清晰的。
具体到Cloudify Manager内部，主要的调用关系如下图：
其中包括
-
部署和安装。
-
工作流执行（执行某个特定节点的自动化操作）。
-
监控和报表。
-
日志和事件。
四类调用场景
为了简化描述，我这边提供各类调用场景的组件调用图。
1）部署和安装
2）工作流执行
3）监控和报表
4）日志和事件
总结来看，Client通过Rest API调用后端组件，后端组件通过RabbitMQ实现任务的异步调用，并借助Agent（Monitoring Agent和Workflow Agent）进行Applicaitoon VM的纳管和数据采集。
以下是Cloudify 3.2版本的GUI界面，给大家做一个参考。
-
Blueprint部署，Cloudify提供图形化界面实时展示安装部署进度
-
某个组件安装完成后，会自动启动Monitorng Agent 进行 Metrics 采集，并进行图形展示
-
并进行日志和Event的收集
Cloudify也提供BlueprintComposer界面，允许IT人员通过图形化界面记录Blueprint的定义。
接下来我们进入最后一部分。
6. Cloudify和Docker、Openstack的整合
如前面架构介绍部分所说，Cloudify采用面向Plugin架构，系统的扩展都基于Plugin机制进行，系统已经自带了Docker Plugin和Openstack Plugin。
当然，前文提到的AWS、Softlayer、Puppet、Chef等也都以Plugin形式提供。
目前，Cloudify Openstack Plugin 支持的 OPenstack 版本唯 Kilo，实现了下面的四个组件：
Plugin：Nova client
Neutron client
Cinder client
Keystone client
Openstack的整合场景主要为“基于Blueprint部署可以被Openstack直接纳管的基础架构（计算、存储、网络）和应用系统”。
下面是一个例子：
当然我们可以描述更为复杂的Blueprint实现更复杂的拓扑部署，并直接被Openstack纳管。
以上功能类似于Openstack Heat完成的功能，目前暂时没有针对Openstack Heat的Plugin。但在功能上，Cloudify提供了一站式端到端Provision。
同时，3.2版本开始提供cloudify-murano-integration Plugin，实现了Openstack Murano（Application Catalog组件，形成应用集市，提升IT管控的标准化。介绍，前不久Openstack公众号提供了有关Murano的具体说明，感兴趣的同学可以自行参考）。
针对Openstack的整合主要就是以上内容。对于Docker而言，与Openstack类似，可以完整部署一套被Docker纳管的基础架构+应用系统。
除了部署一套被Docker纳管的环境外，还可以对Docker本身进行创建、启动、停止、删除等基本管理操作。
以上就是今天我要分享的所有内容。接下来看大家有什么具体问题，我们可以一起探讨。