Lead Image © Mechanik, Fotolia.com

Lead Image © Mechanik, Fotolia.com

Simple OpenStack deployment with Kickstack

Kick Start

Article from ADMIN 19/2014
Kickstack uses Puppet modules to automate the installation of OpenStack and facilitate maintenance.

If you have tried a manual OpenStack installation before, you will have noticed that some configuration steps are identical among the various OpenStack components; that is, you perform the same operations several times. If this makes you think of automation, you are right on track, and Kickstack provides an approach to solving this problem: Based on Puppet, it offers meaningful and efficient administration of OpenStack clouds.

Cloud computing installations in particular must be able to scale massively horizontally – the perfect use case for classic system automation. So, if you want to know how to set up your own OpenStack cloud within 20 minutes, you have come to the right place.

OpenStack Automation

Regular ADMIN readers might recall reading an article a few months ago that explained how OpenStack components work [1]. The article demonstrated one thing: Installing OpenStack is no trivial matter if you want to do it manually. Various services need to be distributed to their own servers if you do not want an all-in-one setup. The problem is compounded by the many commands in the scope of the OpenStack setup that are not very intuitive and make little sense at first glance. Those who have not worked with technologies such as Open vSwitch will find it difficult to understand many of the commands in the installation of OpenStack Neutron.

Kickstack is an additional layer that resides between the admin and OpenStack, using Puppet modules that have existed for some time for all core components of OpenStack, while Kickstack takes on the automation tasks. Although normal Puppet modules can also install the OpenStack services in an automated process, it requires painstaking configuration of various Puppet parameters, so time benefits are mostly non-existent, especially compared with a manual installation.

Kickstack tidies things up radically. It automatically takes care of creating data, such as Keystone users, ensures that all services of the OpenStack environment and communications with their databases use password protection, and ensures that the OpenStack services run on the hosts previously allocated by the admin. For a variety of parameters, from which the administrator can choose in the Puppet modules, Kickstack filters out the most important ones and then does the rest automatically.

A specially introduced role system assigns specific roles to the various machines in the OpenStack installation. To understand the motivation behind this, I'll review the components that make up OpenStack.

Service Components

OpenStack is not a massive program but a collection of components. This fact is of fundamental importance to understanding the way Kickstack or Packstack [3] work (see the "Kickstack vs. Packstack" box). Table 1 lists the nine core components of OpenStack.

Table 1

OpenStack Components

Component Function
Keystone The authentication service supports user login and mutual registration of services.
Horizon The dashboard makes sense only in combination with a web server.
Nova The computing component that takes care of starting, stopping, and controlling virtual machines.
Cinder The block storage service provides virtual machines within OpenStack with virtual, persistent block storage.
Glance The image service manages images of operating systems and can deliver them to hypervisor nodes whenever needed.
Neutron The network service handles all tasks related to software-defined networking (SDN) in OpenStack.
Ceilometer The metering component was introduced in the Havana release and supports detailed logging of data traffic.
Heat Orchestrates within an OpenStack cloud and takes much work off the admin's shoulders.
Swift The object store component offers a storage service comparable to Amazon S3 in OpenStack Clouds.

Kickstack vs. Packstack

Kickstack is not the only tool that enables automatic deployment of OpenStack using Puppet. For example, Red Hat offers the similar Packstack. Both tools rely on the same Puppet modules maintained by the same developers, so why two different tools for the same task?

The answer to this question is the classic open source answer: Different communities provide multiple solutions to the same problem. In the case of Packstack and Kickstack, significant functional differences exist, as well.

Packstack is tailored to work closely with Red Hat's own OpenStack distribution, RDO [2]. Kickstack, in turn, is more concerned with the classic Ubuntu environment running Ubuntu LTS version 12.04. Until one of the two tools is extended to support other distributions, admins will do well to select the right tool for the job.

The crux of the matter is that even the OpenStack components are not individual programs but, in turn, break down into several modules. Virtually every service in OpenStack has its own API that exposes a RESTful API and thus ensures that the service is controllable via the HTTP protocol. From a technical perspective, it can be quite useful to expose these APIs on the Internet, as it does for Rackspace in their own OpenStack cloud. However, this approach involves a setup in which the individual component modules are distributed across different systems, because the other components do not necessarily, or should not, run where the API components do.

Further atomization takes place when individual parts of an OpenStack component must be distributed across several systems. The cinder-volume service, for example, is the interface that connects VMs on hypervisor systems with the assigned persistent storage. The service therefore runs on hosts where space is available on disks. cinder-scheduler usually runs on a different host – the component coordinates access to multiple storage back ends, if they are configured. Then you have the services that need to be available multiple times within an OpenStack installation: nova-compute, which starts virtual machines on behalf of Nova, is a good example.

Roles Not Programs

To deploy OpenStack meaningfully, it is necessary to think in terms of roles and not individual components. Obviously, it would not make much sense to distribute the services that belong to OpenStack as separate groups on different computers.

Kickstack therefore uses a different approach and assumes that a variety of different roles can be defined within an OpenStack installation more or less as factory defaults. Each role is characterized by a specific combination of services. You need to understand the group schema before starting to work with Kickstack, because the role system is central to Kickstack. Kickstack uses the roles in Table 2 by default.

Table 2

Kickstack Roles

Role Function
Infrastructure Node This system provides support services for OpenStack: RabbitMQ and MySQL.
API Node API services for all components run centrally on this node.
Network Node The network node operates the Neutron components that are responsible for the DHCP and L3 connections and thus give VMs access to the outside world.
Auth Node This node operates Keystone, the ID service, which is something like the root service in OpenStack – without it, the other components cannot be used in a meaningful way.
Compute Node This node primarily includes nova-api and makes a host, to which this Puppet role is assigned, for a computing node the virtual machines can run.
Dashboard Node The Dashboard node runs Apache with a dashboard. It is isolated from the API services.
Metering Node This node operates services that belong to the metering application Cinder (except for the API).
Orchestration Node The role contains all the services required for OpenStack Heat, with the exception of the API.
Controller Node This role has the various services for internal OpenStack use, composed of parts of different services. It is usually located on the same host as the Infrastructure role.
Storage Node Contains the components necessary for a host to make its local storage available for use by Cinder: essentially, cinder-volume.
Client Node The peculiarity of this role is that it installs all the command-line clients for the various OpenStack services; that is, binaries such as glance and nova. OpenStack itself uses the Python libraries in the background. The Client role can be deployed on the node that also has the API role.

From the designated node roles, you can create a mixture of nodes in Kickstack; arbitrary role combinations are possible – even all-in-one installations. In this case, all roles would be assigned to a single node at the same time. That would not exactly be the typical production system, however. The trend is toward defining different node types in OpenStack, which then perform specific tasks.

Moreover, different roles can be assigned to more than one node at the same time; it would not make sense to have just a hypervisor node, for example. The Compute node can thus be assigned to an arbitrary number of nodes.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=