云的基础架构已经开始成形，如何在 OpenStack 上为各种应用程序提供更好的调度环境？
澳大利亚悉尼当地时间11月6号上午9点，第16届OpenStack峰会在悉尼国际会议中心盛大开幕，来自全球52个国家2300余名与会者，将就以OpenStack为核心的开放基础架构相关技术和商业实践展开为期三天的讨论，本文为第二天的讨论内容之一。
在2017年4月的 OpenStack 使用者调查中，可以看见，OpenStack 除了被当作是基础设施服务外，也有许多使用于架构测试与持续集成、数据库、网络服务、大数据等。加上最近当红的边缘计算（Edge Computing）、物联网也有不少以 OpenStack 作为开发研究平台的。
图片源自 OpenStack 官方网站
在上次峰会，由正式增加一个 OpenStack 政策开始，告知 OpenStack 必须重视应用程序需求（https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html ），接着在悉尼峰会，各个讨论与需求在许多专案内开始发酵。我们继续在这应用程序之路上深入讨论。
架构变革
为达成应用程序需求，从上次峰会就开始进行 Application Credentials 的设计规划，让应用程序可以使用由Keystone （验证程序） 取得运行 OpenStack 服务的权限，应用程序能通过此权限操作 OpenStack 服务，但仅限于该权限允许的范畴。因此并不会破坏权限管理。
在Denver PTG 时，已经有过技术上的细节讨论（https://etherpad.openstack.org/p/queens-PTG-vmbm ），在峰会上 “ Application Credentials Feedback ” 技术议程主要报告目前所制订的规格，并收集回馈。
此功能能让应用程序使用部分 OpenStack 服务，而且不需要使用使用者信息作认证，直接将Application Credential 传给被调用服务就可以使用该服务，能使用的服务范围则是在Application Credential 创建时会被设定。
针对 PTG 时讨论的修改，回馈都是正面的，一般来说 Credential 不会被用来重新创建其他 Application Credential 。但针对像是编排专案需求（例如当自动扩容时， Heat 需要有权限创建新扩容资源，像是目前使用 trusts 机制一样 ）。
为什么笔者将此功能放在架构变革区块？其实上次峰会所做的报道也有提到，让人惊讶的，权限架构是目前社区认为最前哨的变革点，因为只有权限开通，才能让其他服务开始计划后续提供给应用程序的设计。
另一个变革，则属于 “ Cloud-Native Design/Refactoring Across OpenStack （Part II） ” 技术议程所带来的议题。
Cloud Native， 虽然词汇一直存在，但变成变革则算是在 CNCF （ Cloud Native Computing Foundation ） 与容器化开始兴起完善容器架构，而 OpenStack 成熟后带来的稳定的云架构。两者合并后才开始被重视。对于新开发的应用程序来说，直接让应用程序使用云框架与容器架构上的服务（例如自动扩容，监测，纪录，修复等）。
议程中检视 OpenStack 现有设计，讨论如何让 OpenStack 架构更具有云架构的优势。无疑对于应用程序来说，后续可行的设计并不会破坏现有程序的使用（ OpenStack 跨版本的相容性向来是一大优势）。
因此第一刀就落在状态监控，整个技术议程讨论的重点在于如何建立符合云架构的状态收集（https://etherpad.openstack.org/p/sydney-cloud-native-partii） 。
设计重点在于提供所有专案一个可以将本身资源状态上传的一个平台。通过计划在 OSLO.Middleware 内建立状态回报工具。让所有专案可以通过该工具将所有想丢到状态列表的资源送到统一的地点。
后续再由各个服务自行选择要如何判别这些状态。会有这样的设计是为了提供一个可以纵观整体 OpenStack 状态的平台，让资源状态不在零散，也不再需要各别服务独立开发资源状态监控的。相较效率与统一性会高很多。而这也就是此环节为第一刀的重点。目前还未有相关实践，但是后续一定看好此功能。此为实际针对资源监控大方向大问题进行改善的好的开发方针。
编排：应用程序的自动化之路
自动化是许多使用者的需求，需要一下环节互动而成：生成资源-》监控资源-》信号触发事件-》修复-》持续监控。只要能满足上面的环。就能达成自动化。最大的问题是各个环节应该用那些服务，服务间有无好的串连方式以达成最高效的自动化系统。
自动扩容 （ Auto-Scaling ） 在 OpenStack 环境并非新技术，操作成熟度也相当高。因此在峰会以使用者分享居多。而自动修复在峰会上是这次的一个小焦点之一，在技术议程 “ Self-healing and optimization SIG ” 里，第一次在峰会集合相关技术专家讨论目前的修复功能与如何优化。
目前在社群上 Heat 就有为自动修复做过深入调研，也提供方式供使用者参考
（https://github.com/openstack/heat-templates/tree/master/hot/autohealing）。
当然我们更希望我们能提供给使用者的自动化是更全方面的，因此这个 SIG 小组的任务才刚开始，相当多的人参加，也有很多自愿者愿意一起推动。
目前已经决议成立此小组。后续也会有专有的IRC 频道与会议，更重要的是，通过小组旗帜，号昭与收集更多使用者需求（https://etherpad.openstack.org/p/self-healing-rocky -forum）。
自动化流程也具有其他的标准协议像是IFTTT。值得一提，在实践修复环节时，建议可以考虑 Mistral 服务，套用 OpenStack 在自动化流程时 Mistral 提供 流程管理服务，让运行时可以按照实际状况流程行动。
考虑使用 Heat 作为资源管理，而 Mistral 作为管理时的运营时的流程管理，在许多实际使用案例来看是一个不错的架构。在议程 “Mistral - Project Update”内，Mistral PTL 介绍 Mistral 的现况与未来开发。
在上面的自动化流程与应用程序管理中，编排是简化使用者端操作复杂度的方式。往往应用程序都是数个服务所组成，在多数实际运营环境中，应用程序可能必须调度在上百台节点上。因此更需要统一管理的机制，增加管理强度，加快调度流程，减少失误。在峰会上笔者有幸负责编排专案的几个社区技术议程。
峰会第一天早上，即有编排专案的 Onboarding 技术议程。提供专案介绍、框架、脚本解说、调试方法与贡献方式。让开发者与操作者能够更紧密与社区接轨。为了协助应用程序接轨，内容使用自动修复与扩容脚本，与软件设定编排（ Software Config ）脚本作为解说方向。让撰写脚本的操作者能更快速为应用程序制定 Cloud Native 环境。
在专案更新部分介绍几个Pike 版本的新脚本功能（list_concat_unique， contains， make_url）与新资源（包含： OS：：Neutron：：Trunk， OS：：Neutron：：Segment， OS：：Zaqar：：Subscription， OS：：Zaqar：：MistralTrigger， OS：：Magnum：：Cluster， OS：：Magnum：：ClusterTemplate， OS：：Mistral：：ExternalResource， OS：：Zun：：Container）。其他提及功能包含，专案本身已支持python3，支持编排根据实况更新，新增 Heat-Agents 子专案，更完善的分布式服务。
其中可以观察到 Zaqar 资源的更新为了完善应用程序管理自动化中信号触发事件环节的串连。
另外 “ OS：：Mistral：：ExternalResource ” 可以允许使用 Mistral 的工作流程来分别定义资源的每个独立动作（例如创建，更新，删除等）。针对应用程序拥有非属于 OpenStack 的资源尝试使用 OpenStack 架构作为调度平台时，此资源可以大幅协助相关流程简化与编排托管。当然即使没有 Mistral 你一样可以通过新增 Python 源码或是注册新资源的方式将定制化的资源放入 Heat 脚本内。因此你可以根据应用程序需求来选择方式。
从峰会的议程来看不只是笔者所接触到的这几个议程，其他跟应用程序与应用程序编排相关的议程，在整体 OpenStack 议程来说不在少数。许多网络调度程序或是容器服务需求等应用实际案例分享也不再少数。 OpenStack 对于协助应用程序的力量与开发需求看来不在少数。服务的重点是贴近使用者需求，在峰会的第一天开始，就已经可见到社区的确是朝着这方向迈进。
至于使用者们是否也对于架构应用程序充满期待与信心呢？以下笔者给各位一个参考。
在议程 “ Future science on Future OpenStack ” 上要让大家知道 SKA 组织已经决定要跟 CERN 合作，计划创建世界最大的科学研究的云环境。
这堆庞大的应用程序当然是即将要建立在 OpenStack 之上。后来跟几位讲者私聊，他们相信在计划开始时，OpenStack 作为底层平台，对于应用程序的的支持度一定能达到极高可用性与可靠性。
这次峰会，OpenStack 对于应用程序的目标，更加专精。比起早期发散且众多的开发项目，现状的稳定，更容易让开发者们互相合作。其他社区的崛起，反而让 OpenStack 社区看到更多机会，的确能带着应用程序迈向成功之路。
