Tools Apache ARIA TOSCA Lead image: Lead Image © alenavlad, 123RF.com

Interoperability across clouds

Conductors Wanted

ARIA TOSCA provides an environment for developing, testing, validating, and executing TOSCA templates and service descriptions, for the elimination of incompatibilities between cloud solutions and to increase interoperability. By Holger Reibold

The promises of cloud computing are well known: significant cost and agility benefits plus a scalable environment. So far, so good. In practice, however, standardized descriptions of the topology of applications, their interactions, and their dependencies with environment variables are still lacking. This obstacle rears its head when using an application in multiple clouds or when migrating between them; this is where ARIA TOSCA comes in.

TOSCA (Topology and Orchestration Specification for Cloud Applications) inevitably evokes associations with Puccini's opera of the same name, in which the celebrated opera diva Floria Tosca tragically plunges to her death from the parapet of Castel Sant'Angelo. In this case, TOSCA does not stand for a tragic end; instead, TOSCA is intended to eliminate incompatibilities between cloud solutions and increase interoperability.

Interoperability Ensured

When a company wants to change cloud providers, unexpected problems arise in the final stages. The OASIS project has addressed this problem by developing the TOSCA specification, which defines a meta model to describe cloud services. Put simply, TOSCA provides a framework in which cloud applications with all their aspects are written to a template that can theoretically be exchanged between providers. A template includes service definitions, structures, and other information. The declared goal of TOSCA is to prevent a dependency on individual cloud computing providers.

Thanks to its independence and interoperability, TOSCA offers a high degree of flexibility, paving the way for standardized cloud solutions. The standardized description of components, their relationships and dependencies, and their requirements and capabilities not only enable portability, but also enable automatic management between cloud computing providers, regardless of the underlying platform or architecture. As a positive side effect, the agility and accuracy of cloud services have reached a new level.

For customers, TOSCA increases the comparability and choice of cloud offerings while reducing costs. Cloud service developers also benefit, because they can develop for different platforms and choose the appropriate provider, regardless of incompatibilities. However, providers also benefit from standardization because adoption is simplified, and they can expand their own range of services and drive forward their own developments.

TOSCA comprises two parts: the topology, which describes the components and the relationships between the applications, and orchestration, especially the modeling management of the application.

ARIA TOSCA

To benefit from TOSCA, you need an environment in which the templates and service descriptions can be developed, tested, validated, and executed. This is where the Apache Incubator project ARIA TOSCA [1] comes in. It is a library and console tool for network function virtualization (NFV) and hybrid cloud orchestration. ARIA TOSCA is a manufacturer- and technology-independent TOSCA implementation. In addition to the command-line interface for template development, it includes an SDK for the development of TOSCA-compliant software. The Apache Software Foundation provides ARIA TOSCA to promote industry acceptance of TOSCA.

ARIA TOSCA is a framework designed to accelerate the implementation of orchestration software based on the open standard (Figure 1). ARIA provides a library and programming interface that can be used to connect to existing environments, the great advantage being that no changes need to be made to existing configurations.

Figure 1: ARIA TOSCA has a wealth of plugins that support connections to IaaS solutions, management environments, containers, and software-defined network environments.

The ARIA TOSCA DSL Parser plays an important role. It serves to interpret the TOSCA templates, generate a deployment diagram of the application, and validate the template with regard to its validity. TOSCA determines the blocks in question for template creation, and the parser can recognize relationships or possible relations. The template data is written in declarative YAML with normative TOSCA types. Additionally, technology-specific types can be introduced and integrated into the environment with ARIA plugins and without the need to modify the parser code. The current version of ARIA natively supports TOSCA Simple Profile in YAML v1.0 and TOSCA Simple Profile for NFV.

Another important element is ARIA workflows, which are automated process algorithms that allow for dynamic interaction with the graph described by the application topology template. What sounds abstract at first glance is simple in itself: The workflows determine which tasks are processed in which order. A task can be an operation or other action. Operations, especially complex operations, can optionally be implemented as plugins. Other actions combine the execution of user-defined scripts or code.

ARIA workflows can in turn be part of TOSCA templates and access graphs dynamically. The workflows are implemented in Python and use a dedicated API, which allows access to the graph and run-time context of an application. ARIA TOSCA is equipped with some basic workflows responsible for (1) installation, (2) uninstallation, (3) customization, and (4) repair of the installation. Even if these workflow configurations do not handle any cloud-specific functions, they are still useful as examples of application possibilities. User-defined workflows use the same APIs as these four standard processes.

ARIA plugins extend the normative TOSCA types, adding node and relationship types. Again, no modifications to the parser code are necessary. Like blueprints, these plugins can be extended to cover specific functional scopes and can even be combined with each other. For example, OpenStack Kilo and OpenStack Juno can be supported in one template along with a combination of various technologies (e.g., combining OpenStack nodes with VMware and Amazon, but also with routers, firewalls, a Kubernetes installation, etc.). Interaction with Infrastructure as a Service (IaaS) APIs, management environments, monitoring tools, and more is also possible with ARIA plugins. ARIA TOSCA natively supports the following plugins:

IaaS plugins for OpenStack, AWS, VMware, and Google Cloud Platform (GCP) Azure
CM plugins for Puppet, Chef, Ansible, and SaltStack
Container plugins for Kubernetes, Docker, Mesos, and Swarm
SDN plugins for OpenDaylight (ODL) and Open Network Operating System (ONOS)
Script plugins for Bash, Python, and others

Fortunately, the plugins are part of the template package and are loaded dynamically on demand. ARIA TOSCA comes with some standard plugins, so developers and administrators can gain some initial experience.

Commissioning ARIA TOSCA

The TOSCA implementation is based on Python and requires a Python 2.6 or 2.7 interpreter; version 3 is not currently supported. ARIA TOSCA is available for download from the Python project site [2]; the easiest way to install it is from the repository:

$ pip install --upgrade pip setuptools
$ pip install apache-ariatosca

Alternatively, you can install from the source code by downloading the sources from the PyPI website, extracting the archive, switching to the dir directory, and executing the commands:

$ pip install --upgrade pip setuptools
$ pip install

The source code contains the relevant examples and documentation. ARIA has several optional dependencies that appear when running operations via SSH. Please note that the necessary licenses might not be compatible with Apache license 2.0, which you should check on a case-by-case basis. In Debian-based environments, run the commands:

$ apt-get install -y python-dev gcc libffi-dev libssl-dev
$ pip install apache-ariatosca[ssh]

ARIA TOSCA provides the simplest of all examples, "Hello World," which can be found in the examples subfolder of the ARIA installation (see the box titled "Hello World with ARIA TOSCA"). To use it, load the sample template into ARIA and assign it a name of your choice (e.g., my_service_template), create a server based on the template, name it my_service, and execute an installation workflow on the service configuration:

$ aria service-templates store examples/hello-world/helloworld.yaml my_service_template
$ aria services create my_service -t my_service_template
$ aria executions start install -s my_service

Hello World with ARIA TOSCA

The TOSCA specification uses YAML. Here is an example of a simple script:

tosca_definitions_version: tosca_simple_yaml_1_0
node_types:
  WebServer:
     derived_from: tosca.nodes.Root
     capabilities:
      host:
       type: tosca.capabilities.Container
  WebApp:
     derived_from: tosca.nodes.WebApplication
     properties:
      port:
       type: integer
topology_template:
  node_templates:
     web_server:
      type: WebServer
     web_app:
      type: WebApp
      properties:
       port: 9090
      requirements:
       - host: web_server
      interfaces:
       Standard:
        configure: scripts/configure.sh
        start: scripts/start.sh
        stop: scripts/stop.sh
  outputs:
     port:
      type: integer
      value: { get_property: [ web_app, port ] }

This script writes its output to the corresponding HTML file. The template, service, and node names can be taken from the output:

<html>
  <header>
     <title>ARIA Hello World</title>
  </header>
</body>
  <h1>Hello, World!</h1>
  <p>
     blueprint_id = {{ ctx.service_template.name }}<br/>
     deployment_id = {{ ctx.service.name }}<br/>
     node_id = {{ ctx.node.name }}
  </p>
  <img src="aria-logo.png">
</body>
</html>

The ARIA TOSCA installation's examples directory has further use cases.

On the ARIA system, you can execute the template with a simple web server. To check the execution, open the URL http://localhost:9090.

ARIA in Practical Use

Admins work with ARIA TOSCA at the command line; the most important actions are therefore console commands. The default working directory is ~/.aria, which you can change by editing the ARIA_WORKDIR environmental variable. The generic syntax is

aria <options> <commands> <arguments>

As usual, you can discover the program version with the --version option. If you want to reset the environment after various modifications, simply use the aria reset command, which removes all installed plugins, service templates, logfiles, and so on from the working directory.

The plugin command executes all plugin-specific commands, in particular for installation and verification. A valid plugin uses Wagon [3] and is saved as a Wagon or ZIP file. To install a plugin, enter:

aria plugins <options> <plugin path>

You can retrieve the list of installed extensions with aria plugins list. Before using a plugin, you should check its validity with the validate command (e.g., aria plugins validate).

Another important task is managing templates. You can create your own cloud service archive (CSAR) files from the template sources. To output details of the templates and then validate a loaded template, use

$ aria service_templates show <template-name>
$ aria service_templates validate <template-name>

You can control the execution of ARIA with the executions command; for example, to start a workflow, enter:

$ aria executions start <workflow-name>

You can manage logfiles with the aria logs command. Targeted logfile output for specific processes is also possible, but first you need to output the IDs of the actions and then query specific information:

aria logs list
aria logs list <ID>

OpenStack Interaction

ARIA TOSCA, in conjunction with Cloudify [4], the most advanced TOSCA implementation to date, can automate and manage heterogeneous cloud environments (Figure 2). OpenStack installations can also be controlled with a special adapter.

Figure 2: Cloudify shows ARIA TOSCA how to do it: Its Blueprint Composer supports the dynamic creation of YAML files by drag and drop.

ARIA supports IaaS integration through the Cloudify context adapter, which allows the execution of arbitrary Cloudify plugins with ARIA TOSCA. Install the adapter with:

$ git clone https://github.com/cloudify-cosmo/aria-extension-cloudify
$ pip install -r aria-extension-cloudify/requirements.txt
$ pip install aria-extension-cloudify

The next step is to install the OpenStack plugin [5]. ARIA supports the installation of extensions in WGN format. The installation of the plugin on the ARIA side is simple:

$ aria plugins install <Wagon_file_path>

Everything is then ready for a first sample file. Here, too, the execution of the Hello World example [6] is a good idea. However, the sample file requires some input: Create a file named inputs.yaml:

external_network_name: extern
webserver_port: 8080
private_key_path: <local path>
image: <image_name>
flavor: <flavor_name>

Then, create a service template, and execute a workflow:

$ aria service-templates store <Example_Root>/openstack-helloworld.yaml <template_name>
$ aria executions start install -s <service_name>

OpenTOSCA Alternative

The Stuttgart Institute of Architecture of Application Systems has been working on TOSCA and a model implementation since 2012. In the form of OpenTOSCA [7], they developed a free system for the TOSCA standard that comprises three parts:

OpenTOSCA Container, a TOSCA run-time environment
Winery, a graphical modeling tool for TOSCA
Vinothek, a portal for applications

OpenTOSCA is already available in version 2.0.0 and can be installed on Debian with:

$ wget -qO- http://install.opentosca.org/install | sh

After installation and startup, which can take up to 10 minutes, an OpenTOSCA instance is available at http://host: 8080. Access to the Winery components is through the web interface.

Working with OpenTOSCA follows a fixed procedure:

1. Outline the topology and orchestration.

2. Select the NodeTypes.

3. Create a new template in Winery and model the desired topology on the basis of the NodeTypes.

4. Enter the necessary parameters for NodeTemplates.

5. Model and import the plan, including the specification of various service information.

6. Export the service template to a CSAR file.

The developers show which existing application areas are made available by OpenTOSCA through two sample applications that describe IoT services [8] and typical application scenarios in Industry 4.0 [9].

Conclusions

ARIA TOSCA is a reference implementation of the TOSCA specification. The environment runs on the console and can be linked to existing cloud computing environments through APIs. However, TOSCA is not particularly user-friendly. For example, it has no web-based admin interface, and TOSCA editors and modeling tools are missing. Thus, the approach in its current form falls short of its potential.