Introduction

xOpera project includes a set of tools for advanced orchestration with an orchestration tool xOpera orchestrator (or shorter opera).

opera aims to be a lightweight orchestrator compliant with OASIS TOSCA and the current compliance is with the TOSCA Simple Profile in YAML v1.3. opera is by following TOSCA primarily a (TOSCA) cloud orchestrator which enables orchestration of automated tasks within cloud applications for different cloud providers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), OpenFaaS, OpenStack and so on. Apart from that this tool can be used and integrated to other infrastructures in order to orchestrate services or applications and therefore reduce human factor.

xOpera orchestrator engine - called xOpera library - xOpera CLI and xOpera API are an open-source project which currently reside on GitHub inside xopera-opera and xopera-api repositories. As an orchestration tool xOpera uses Ansible automation tool to implement the the TOSCA standard and to run its interface operations via Ansible playbook actuators which again opens a lot of new possibilities.

Fig. 1 The xOpera components.

Currently a set of components is presented in figure Fig. 1. This documentation covers all the xOpera tools.

We can point out the following tools:

xOpera CLI (opera) is a command line interface to the xOpera library for deploying TOSCA templates and CSARs.
xOpera API API allows integration of xOpera library.
xOpera SaaS is a standalone service for application lifecycle management with xOpera orchestrator through GUI and API.
xOpera TPS (Template Library) or Template Publishing Service is a library of published TOSCA templates and CSARs.
IaC Scanner is a service that check your IaC for known vulnerabilities.

The xOpera project was also presented within the TOSCA Implementation Stories. The following video displays how users can benefit from xOpera project.

Background

xOpera is a TOSCA standard compliant orchestrator that is following the paradigm of having a minimal set of features and is currently focusing on Ansible. xOpera is following the traditional UNIX philosophy of having a tool that does one thing, and does it right. So, with a minimal set of features xOpera will do just the orchestration, and do it well.

xOpera is available on GitHub under Apache License 2.0.

TOSCA stands for the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) standard. It’s an industry-developed and supported standard, still lively and fast to adopt new technologies, approaches and paradigms. It’s however mostly backwards compatible, so staying within the realm of TOSCA is currently a sound and, from the longevity perspective, a wise decision.

Using the TOSCA as the system-defining language for the xOpera means that we have an overarching declarative way that manages the actual deployment. The Ansible playbooks are now in the role of the actuators, tools that concretise the declared system, its topology and contextualisation of the components and networking.

This design takes the best of both worlds. TOSCA service template is a system definition, written in proverbial stone, while the qualities of the individual Ansible playbooks are now shining. Within the playbooks, we can now entirely focus on particular elements of the overall system, such as provisioning virtual machines at the cloud provider, installing and configuring a service on a target node, etc. xOpera, in its capacity, takes care of all the untidy inter-playbook coordination, state of the deployment and so on.

Note

More about xOpera’s background, its origins and goals can be found here:

Parser

Note

TBD: This part of the documentation will be improved in the future.

xOpera orchestrator has its own YAML and TOSCA parser which is shown on the image below (Fig. 2.)

Fig. 2 xOpera parser and executor

Business value

Orchestrator xOpera is a tool that follows OASIS TOSCA standard and unlocks its benefits of providing multi-cloud orchestration support. According to this business value of this tool can be seen through different perspectives. Firstly, the aim is to have an orchestration tool which is easy to install and easy to use. Installation process is very simple and requires only python and possibly a virtual environment. Opera package is visible on PyPI so even older versions can be installed. Secondly, opera is a very dynamic tool which can be used for simple or complex orchestration of applications because one can prepare his own TOSCA templates that are unique and based on his use case. All of the templates can also be modified and reused with xOpera. And lastly, as opera is evolving, there are many different CLI commands that can be used with it. Besides deploying and undeploying a solution, opera can be used for TOSCA CSAR service template validation or for printing out outputs of the orchestration.

xOpera SaaS and Template Library overview

The xOpera ecosystem includes tools that target optimizing deployment processes and reducing the human factor along with a faster preparation of deployment scripts. The video points out the most crucial functionalities of xOpera SaaS and TPS:

Template Library Publishing Service (TPS) opens up a place for publishing, storing, managing, downloading and versioning of OASIS TOSCA modules and blueprints (i.e., TOSCA CSARs).
Similar templates can be grouped together to form a FaaS abstraction layer such as a bundle of ready to use templates for deployment to cloud providers (e.g., AWS, Azure, GCP, OpenFaaS, etc.).
Template groups in TPS can be used for connecting to corresponding groups of users and therefore enable working on different templates in a team and sharing them with other teams later.
TPS brings different modes of interaction such as REST API, CLI client, browser-based GUI and Eclipse Che/VS Code plugin.
Published deployment scripts in TPS can orchestrate the deployment with xOpera SaaS, which introduces a browser service for orchestration with a lightweight opera orchestrator compliant with OASIS TOSCA standard and powered by Ansible automation engine.
Users can choose the corresponding templates and create a new project, secrets and credentials for deployment. Then they can deploy the application and observe the progress and status of the deployment.
It is possible to organize multiple projects in multiple workspaces, manage provider credentials and assign them directly to workspaces. They can all run concurrently and users can even share the workspaces with other members.
Apart from standard validation, deployment and un-deployment, xOpera SaaS also offers more complex orchestration actions such as redeployment, discovering template differences or invoking TOSCA policy triggers to enable vertical or horizontal scaling.
The SaaS component is available through an API, GUI or Eclipse Che/VS Code plugin. The core part of the SaaS is the opera orchestrator, which is CLI and can be installed as a Python package from PyPI.

The following videos show how xOpera SaaS and Template Library work in action: