Lead Image © stylephotographs, 123RF.com

Lead Image © stylephotographs, 123RF.com

Installing applications in OpenStack with Murano


Article from ADMIN 30/2015
Murano provides an interface for installing and managing applications in the OpenStack cloud.

Several projects now exist under the patronage of OpenStack or the OpenStack Foundation. What started out as quite a small project in 2010 with Nova and Swift has become an extensive collection of various as-a-service modules. Like OpenStack itself, requirements and expectations of OpenStack's users have also grown.

From a data center perspective, it might be sufficient to be able to provision servers, networks, and storage quickly and elegantly. Although it is possible for cloud providers to earn money this way, for most others, the infrastructure is only the beginning. Applications need to run on an OpenStack machine with a configuration appropriate to their actual business needs. Infrastructure alone is not enough. In contrast, the typical case is two-or three-tier applications with dependencies between the individual components and often additional requirements for the associated network.

Complete Collection

Suppose someone is looking for new clothes. That person might need a shirt, vest, jacket, and pants. In this analogy, OpenStack would be equivalent to a shopping mall. Buyers visit individual shops and choose what they want. In doing so, they need to make sure that the items match. Would it not be much easier to choose a pre-assembled outfit from a catalog?

The OpenStack Murano [1] project is a catalog of sorts – but for applications. Roughly speaking, the project provides interfaces for installing and managing a complete application environment in an OpenStack cloud. Murano does not exactly reinvent the wheel; instead, it draws on existing projects.

Heat and Mistral, for example, are used for orchestration and work processes. Murano sees itself as an integrator that merges the existing pieces of the puzzle into one image. Figure 1 shows an abstract view of the interaction between OpenStack components.

Figure 1: Murano interacting with other OpenStack components.

Murano has evolved since its launch in 2013 and is now much more than just a catalog. For example, it manages the entire lifecycle of an application, including jobs such as automatic scaling, high availability, or even just plain old backups. A look at the plans for the future [2] gives an idea that a lot more is still to come.

History: How It All Began

The beginnings of the Murano project date back to around February 2013. Interestingly, the project started off life on Windows and its directory service, Active Directory. The driving force behind the application catalog was Mirantis [3], one of the founding members of the OpenStack Foundation. A simple analysis of the software contributions to Murano shows that at least half of the approximately 80 developers come from this company. However, the project only really began to shine with the release of OpenStack Juno.

If you can't wait to take a look at the catalog at this point, you will find the necessary instructions and tips in the "First Steps" box.

Listing 1

Murano Installation

$ git clone https://git.openstack.org/openstack-dev/devstack
$ git clone https://git.openstack.org/openstack/murano
$ export DEVSTACK_DIR=`pwd`/devstack/
$ cd murano/contrib/devstack/
$ cp lib/murano ${DEVSTACK_DIR}/lib
$ cp lib/murano-dashboard ${DEVSTACK_DIR}/lib
$ cp extras.d/70-murano.sh ${DEVSTACK_DIR}/extras.d
$ vi local.conf
$ cat local.conf
enable_service heat h-api h-api-cfn h-api-cw h-eng
enable_service murano murano-api murano-engine
$ sudo ./tools/create-stack-user.sh
$ sudo cp -a /root/devstack /o pt/stack/
$ sudo chown -R stack:stack /opt/stack/
$ sudo su - stack
$ cd devstack
$ ./stack.sh

First Steps

To get started, it is a good idea to use Ubuntu as the base operating system and DevStack as the installation tool for OpenStack. However, I used one of the Red Hat derivatives. The older the better applies here because of the Django [4] software.

Until version 1.8, the Django formtools [5] were part of this project and all was well. However, a decision was then made to outsource this part. Although this doesn't necessarily have to be a problem, Fedora 22 no longer supplies the outsourced part. The Murano installation – and in particular its integration into the graphical interface, Horizon – really suffers from this situation. The problem is technically solvable but does take your attention away from the installation process.

The version number of the installed Python also deserves some attention. You are on the safe side with 2.7 or 3.4. The installation steps are pretty simple for Ubuntu (or Fedora 21) and are well documented [6]. Using the latest software version proved invaluable in the lab tests performed by the magazine's staff (Listing 1).

Ideally, users will be able to use an OpenStack environment, including Murano integration, after just a few hours. The easy route leads to the Marketplace mentioned in the main text for OpenStack applications. There, users can then download pre-built packages and integrate them into their own environment.

The choice is left completely up to users whether they want to do this via the Horizon graphical interface or the murano [7] command-line tool. Provided there is a connection to the Internet, of course, the necessary Glance images [8] also end up where they belong (Figure 2).

Figure 2: Applications in the Murano catalog of a private OpenStack installation.

Who's Talking to Whom and Why?

Figure 1 shows Murano's interactions with various OpenStack components. There are two processes active in the background: murano-api and murano-engine. The name implies that murano-api is the interface to the outside. A native Murano client (or other OpenStack components) establishes contact via this daemon. It passes on the information to the other process – the engine – which is responsible for the actual work.

The first step is then to generate an environment. Murano essentially summarizes the applications to be installed here with a few infrastructure details for the underlying virtual server. This can include details about the variant used for the guest, network, server name, or availability zone. In other words, the environment specifies the topology of the service to be installed. Each of these structures is given a name for referencing purposes.

The Murano machine analyzes the environment information and checks that all the necessary components are available and accessible. If users want to discover more about the environment, using the graphical interface is recommended because the command line is not particularly communicative here (Listing 2) – much in contrast to access via Horizon (Figure 3).

Figure 3: You can put together a complete environment in Murano with just a few mouse clicks – a complete web server with an underlying container infrastructure.

Listing 2

Output from the Command-Line Client

$ murano environment-list
| ID                               | Name       | Created             | Updated             |
| 1160f3d830cd4aaf8ea53bf42d4bd8f9 | DockerTest | 2015-09-01T05:20:20 | 2015-09-01T05:20:20 |
$ murano environment-show 1160f3d830cd4aaf8ea53bf42d4bd8f9
| Property   | Value                            |
| created    | 2015-09-01T05:20:20              |
| id         | 1160f3d830cd4aaf8ea53bf42d4bd8f9 |
| name       | DockerTest                       |
| networking | {}                               |
| services   | []                               |
| status     | pending                          |
| tenant_id  | 55273dedb2be476c812f0bc3f953f2cf |
| updated    | 2015-09-01T05:20:20              |
| version    | 0                                |

If everything is all right, Murano then contacts the necessary OpenStack modules to provide the corresponding components, such as Neutron for network components. The next step is for Murano to create an orchestration template – known as a Heat template in OpenStack-speak. The template serves as a framework for the subsequent steps.

You have two options here. The Murano approach would be to install agent software [9] [10] on the virtual server. This then takes care of other unfinished tasks. Glance images with these agents can be found online [11]. Alternatively, you can take the plain vanilla Heat route. The next steps are cued completely by the definitions within the OpenStack orchestration software.

One way or another, users have a fully installed and configured application available to them in the end. The last step involves sending feedback to the API daemon, which passes the success or failure message on to the outside.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus