-
Notifications
You must be signed in to change notification settings - Fork 1
Apache ARIA Service Proxy Plugin
The Apache ARIA project, is an OASIS TOSCA Simple YAML 1.0 reference implementation that includes a CLI and orchestration/execution engine. With it, TOSCA YAML service templates can be parsed and validated, instantiated, and have workflows run against them. Like Cloudify, the orchestration engine is extensible via plugins. This post is about the implementation and features of one such plugin which has a similar counterpart in Cloudify, the ARIA Service Proxy Plugin.
TOSCA concerns itself with defining service templates, which contain a model of a given deployment structure or stack. TOSCA also defines normative operations (e.g. create, configure, start..) for template components (nodes) which an orchestrator can call to produce desired effects (e.g. install, uninstall). TOSCA also define a form of template composition known as substitution mapping. Substitution mapping permits the construction of service templates that can expose a simple interface for reference by other service templates. For example, a database service template, including compute and networking configuration, can be consumed by another template as a single TOSCA node.
TOSCA provides no means for composing services with independent life cycles. In the substitution mapping discussion above, the inclusion of the database template in the consuming template means that when the consuming template is realized, the database will also be realized. Conversely, when the consuming template is unrealized, the database will be destroyed. It is desirable to have a convenient means of orchestrating services with independent lifecycles so, for example, stacks that are clients can be created, destroyed, scaled, and updated at will without impacting an associated running service. One obvious approach to this problem is to define custom TOSCA types for each target service. A more convenient approach is to exploit the outputs feature of template services.
Outputs are optionally exposed data that a service can provide (for example a public IP or URL).