A VMware User’s Guide to Repatriating Cloud Instances with OpenStack Written by: John S. Tonello Global Technical Marketing Manager, SUSE®

www.suse.com SUSE Guide

p. 2

Table of Contents

Table of Contents .................................................................................................................................................................. 2

Evolution of the Data Center ................................................................................................................................................. 3

What You’ll Need .................................................................................................................................................................. 3

More Than a Hypervisor ........................................................................................................................................................ 3

Instance Basics ..................................................................................................................................................................... 5

Deploy an Application ........................................................................................................................................................... 7

Deploy a Stack ...................................................................................................................................................................... 8

Conclusion .......................................................................................................................................................................... 12

p. 3

Evolution of the Data Center

So, you’ve decided to repatriate some of your AWS or Azure applications to the OpenStack cluster that you just spun up

in your data center, but you and your team are scratching your heads. After all, OpenStack doesn’t look a whole lot like

the VMware stuff you’re familiar with and it has only a passing similarity to public clouds.

Where to start?

This SUSE Guide walks you through a simple OpenStack deployment so you can get comfortable with the environment. It

will help you figure out how to deploy your own apps by focusing first on the infrastructure and how it differs from a VM

environment. Then, you’ll step through a software-defined implementation of an application. In the end, you’ll be better

able to wrap your head around building your own on-premises cloud and be on your way to bringing key cloud apps back

in-house.

What You’ll Need

To get the most out of this guide, you need access to an OpenStack deployment. If you already have one up and running,

great. If you don’t, you can get a free trial version of SUSE OpenStack Cloud: install Kolla-Ansible (the containerized

OpenStack project); grab one of the downloadable training labs made for Windows, Mac or Linux; use a public instance

via the OpenStack Public Cloud Passport or even deploy DevStack.

You need the following enabled in your stack:

Nova (compute)

Neutron (networking)

Glance (images)

Heat (for stack-building)

Horizon (dashboard)

Cinder block storage isn’t strictly required for this example, but it’s useful if you plan to scale beyond this sample project.

If you’re using the command line, you also need to have openstack-heat or the python-heatclient installed

because the “stack create” command is not a function of the openstack command. To install it, use pip:

$ sudo pip install python-heatclient

More Than a Hypervisor

If you’re used to working with VMware, it’s important to think beyond basic server virtualization. VMware and Hyper-V

provide hypervisors that make it easy to deploy virtual machines at scale. VMware and Hyper-V are pretty good at this

and offer a more robust tool than KVM and Xen, but public clouds and OpenStack move well beyond providing

hypervisors for VMs.

For example, instead of placing a particular VM or group of VMs on a particular ESXi host in a VMware cluster,

OpenStack pools the resources from all your physical hosts and abstracts the hardware, networking and storage. It

decides where to place each instance based on previously allocated resources and assigns CPU, RAM and network

resources based on what is available in the cluster. Instead of relying on VM templates derived from previously built VMs,

OpenStack uses code to define the components of each instance so they can be consistently—and quickly—launched

and replicated.

p. 4

This is much like how AWS Azure (or any cloud provider) enable rapid VM and application deployment. You choose your

OS and the flavor and size of the instance you want, and you quickly have a server. The underlying infrastructure—

including networking and storage—is abstracted.

In this way, OpenStack instances are more ephemeral than the VMware VMs you might be used to. Yes, not only can

OpenStack instances be modified or made to last as long as you want, but also they can be recreated at will with a simple

command or text file. As long as you maintain the core building blocks—images, instance flavors, networking and

storage—you can spawn new instances at will.

Contrast this with VMware, where resources are shared among the VMs on which you eventually place each specific host,

identified in vSphere as a node. In the VMware paradigm, VMs and their resources generally follow specific nodes.

Figure 1: In this VMware vSphere example, ESXi nodes organized by regions form the VMware cluster.

With OpenStack, the resources of each bare-metal server or node are pooled and instances share those resources, which

are managed by the Nova Compute service. Nova keeps track of resources and uses them to spawn new virtual

machines, known in OpenStack as instances.

p. 5

Figure 2: In this OpenStack example, resources from individual hosts are pooled and abstracted.

Instance Basics

To create a new instance, you must first have the building blocks in place. These are usually deployed with OpenStack

itself when you’re making decisions on networks, storage, CPU and RAM. For the basics, you need:

An image to boot: This is typically a Linux-based image, often in qcow2 format. Depending on the purpose, your

images might be barebones and pretty small or customized and fairly big. New images can be added at any time

by simply uploading new OS files, which, in their various forms, are generally small, pre-built VMs of your favorite

Linux distribution. The OpenStack Glance service keeps track of every image you add. The example we show

later in this guide uses the Fedora image, available for download, at

https://download.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64/images/Fedora-Cloud-Base-29-

1.2.x86_64.qcow2. You have many public OpenStack images from which to choose.

Figure 3: Images provide the base OS for OpenStack instances.

p. 6

A flavor: In OpenStack, as in public clouds, instances come in flavors, such as m1.tiny, m1.small and

m1.medium. These are arbitrary sizes that you can define. Each flavor has an amount of CPU, RAM, disk and

other features, so when you choose m1.small you know you’re choosing to create an instance that has 2Gb of

RAM, 1 CPU and a 20Gb disk.

A network: When first deploying OpenStack, you typically add a private network that traffic inside your

OpenStack cluster uses (something like 10.0.0.0/24). This enables instances to communicate with each other,

but not with the outside world. It’s common to add an external network from which you can draw floating IP

addresses that give the outside world access to your instances. Typically, OpenStack automatically assigns free

IP addresses from your various subnets to your instances and keeps track of them. Virtual routers manage the

traffic between your networks.

Figure 4: A simple, two-network topology. Here, demo-net is internal to OpenStack, public1 provides external connectivity and the

demo-router connects them.

Contrast that with VMware or KVM where, when launching VMs, you usually need to pre-determine the IP addresses and

hostnames you want to assign. OpenStack draws from pools automatically.

A key pair: Unlike stand-alone VMs, you don’t usually log into OpenStack instances with a username and

password. Instead, you use shared keys. OpenStack can generate keys for you (the private half of which you

need to download and keep safe) or you can upload an existing public key, such as ~/.ssh/id_rsa.pub.

These keys are identical to the types of shared keys you create on any Linux system with the ssh-keygen

command. You use these keys to log in to any instance:

$ ssh -i ~/.ssh/id_rsa centos@-a-public-address

Depending on the flavor of your image, you’ll use something like “centos” or “opensuse” or “ubuntu” as the

username to log in.

A security group: Most versions of OpenStack (Rocky included) create a default security group that allows

network traffic to access your instance. For example, port 22 for ssh is usually enabled. If you don’t associate a

security group with your instance and set network rules for that group, all network ports on your instance will be

p. 7

closed to incoming and outgoing network traffic—meaning, you won’t be able to interact with it. That is probably

not useful.

Figure 5: A Security Group includes a basic set of ingress and egress rules that can be applied to any OpenStack instance.

Compare these steps with creating a VM in VMware or KVM. For those, you need to provide an .iso for the operating

system you want, set the compute resources, select a network interface, choose where you want to store the resulting

VM, and boot and configure that OS. With VMware, you choose a node in the cluster on which to run that new VM. With

KVM, you choose a storage path. By providing resources up front, OpenStack abstracts, or pre-loads, most of those

decisions, and each OS image is pre-configured and ready to run. There is no need to pre-boot or otherwise provision

them ahead of deploying applications.

Deploy an Application

You can create instances as you would on a typical VM and launch, say, a SUSE Linux Enterprise Server, openSUSE,

CentOS or any other Linux operating system virtual machine. As soon as OpenStack finishes spawning the instance, it’s

up, running and accessible as a raw system. You can create one or hundreds, depending on your available resources.

Figure 6: Use OpenStack’s Horizon dashboard to create one or more instances and treat them like VMs.

One of the strengths of OpenStack is its ability to script the creation steps associated with an entire application, not just

the virtual machine on which it runs. For example, instead of launching a CentOS instance and then installing Apache,

MariaDB, PHP and WordPress, you can define the entire stack at once with a Heat script.

p. 8

Deploy a Stack

One of the examples that OpenStack uses to illustrate Heat scripts is a simple deployment of WordPress, the website

content management system. Let’s look at the underlying YAML of the Heat script so you can get a better understanding

of how stack-creation works.

Deploy WordPress

This OpenStack example uses a Fedora cloud image. It installs MariaDB, sets root MySQL credentials, creates a

“wordpress” database, installs WordPress and its credentials, starts the httpd.service, and assigns an IP address from the

default internal network. It does all that and more in just a couple of minutes. You can think of it as full-stack automation.

The script is deploying the “server” and everything you want to run on it.

When the deployment is finished, you can launch and configure Wordpress, at http://internal-ip-

address/wordpress or associate a floating IP address to access it from an external network, http://public-ip-

address/wordpress/. If you want to start over, you can just re-run the script.

The full script is available here:

http://git.openstack.org/cgit/openstack/heat-

templates/plain/hot/F20/WordPress_Native.yaml

This YAML file, which defines an instance called, “WordPress” and all its required moving parts, contains a resources

section that defines the instance (the underlying “server”) and the commands that set up MariaDB:

resources:

wordpress_instance:

type: OS::Nova::Server

properties:

image: { get_param: image_id }

flavor: { get_param: instance_type }

key_name: { get_param: key_name }

user_data:

str_replace:

template: |

#!/bin/bash -v

yum -y install mariadb mariadb-server httpd wordpress

touch /var/log/mariadb/mariadb.log

chown mysql.mysql /var/log/mariadb/mariadb.log

systemctl start mariadb.service

# Setup MySQL root password and create a user

mysqladmin -u root password db_rootpassword

cat << EOF | mysql -u root --password=db_rootpassword

CREATE DATABASE db_name;

GRANT ALL PRIVILEGES ON db_name.* TO "db_user"@"localhost"

IDENTIFIED BY "db_password";

FLUSH PRIVILEGES;

EXIT

EOF

sed -i "/Deny from All/d" /etc/httpd/conf.d/wordpress.conf

p. 9

sed -i "s/Require local/Require all granted/"

/etc/httpd/conf.d/wordpress.conf

sed -i s/database_name_here/db_name/ /etc/wordpress/wp-config.php

sed -i s/username_here/db_user/ /etc/wordpress/wp-config.php

sed -i s/password_here/db_password/ /etc/wordpress/wp-config.php

systemctl start httpd.service

params:

db_rootpassword: { get_param: db_root_password }

db_name: { get_param: db_name }

db_user: { get_param: db_username }

db_password: { get_param: db_password }

This section of the Heat script includes a number of yum commands, some sed commands that place custom values into

the database, WordPress configuration files and other commands. These customizations are either entered in an

environment file, as parameters or manually.

When you launch a new stack in the Horizon dashboard using this YAML file, you’ll be prompted to add all the items

outlined in the parameters section, including key_name, instance_type, image_id, db_name and other elements that tell

OpenStack just how to construct the stack.

Using the Horizon dashboard, you can create this stack by clicking “+ Launch Stack” under Project -> Orchestration ->

Stacks. Set the template source to “URL” and enter the URL into the WordPress_Native.yaml file:

http://git.openstack.org/cgit/openstack/heat-

templates/plain/hot/F20/WordPress_Native.yaml.

Figure 7: Launch a stack using the Horizon dashboard and a Heat script available via URL.

p. 10

Skip the environment source file for now and choose “Next.” OpenStack will download the remote YAML file and pre-

populate the parameters referenced in the Heat script. Then add the following: a Stack Name, the name you gave your

Fedora image (fedora in the above example) and the name of your ssh keypair. In the example, all database usernames

and passwords are preset to “admin”. Click “Launch” to deploy.

Figure 8: Enter the various parameters to match your OpenStack environment.

If you want to try this same Heat script with a different OS image, such as openSUSE or Ubuntu, you’ll need to download

a copy of the file and edit it. For example, Fedora uses the yum package manager to install MariaDB. If you use

openSUSE, you would need to update those portions in order to use zypper commands. For Ubuntu, you would change

them to use apt.

In addition to using Horizon, you can use the command line to build a stack. You would use the same script and make

sure you have python-heat installed. You would also need to source your openrc file in order to give yourself authority

to run the stack creation process.

You can get your unique openrc file right from OpenStack. Click on your username in the top right of the Horizon console.

Figure 9: Download your unique openrc file from the OpenStack dashboard.

p. 11

After you download the openrc file, you need to source it and enter your OpenStack password when prompted. If you’re

using an admin account, your openrc file will use your admin credentials:

$ source username-openrc.sh

Now you can run the Heat script using the -- parameter flag for each parameter, giving it a name (shown here as

“teststack”):

$ openstack stack create -t http://git.openstack.org/cgit/openstack/heat-

templates/plain/hot/F20/WordPress_Native.yaml \

--parameter key_name=kingdel \

--parameter image_id=fedora \

--parameter instance_type=m1.small \

Teststack

Once deployed, you can view the various aspects of the stack.

Figure 10: Details of the deployed application instance, in this case WordPress running in m1.small.

p. 12

Conclusion

As with any software-defined infrastructure, OpenStack works hard to abstract away the resources required to build

applications and the virtual machines on which the applications live. It starts with pools of storage, CPU and RAM, and

whole subnets from which OpenStack can autonomously draw and assign resources and IP addresses. The result is a

cloud infrastructure that offers the agility of public clouds, greater flexibility and automation than VMware alone and

includes features that will save you and your team time and money.

With SUSE OpenStack Cloud, you can build a private cloud infrastructure with the operational agility, speed, scalability

and control to take full advantage of new business opportunities and rapidly evolving technology trends, such as DevOps

and containers. SUSE OpenStack Cloud is backed by the widest industry and open source community support, so it’s

ideal for developing new, innovative business workloads and DevOps environments, as well as for transforming traditional

data centers. It provides a feature-rich private cloud that you can trust to future-proof your investment.

Learn more, at suse.com/products/suse-openstack-cloud/.

235-001079-001 | 05/19 | © 2019 SUSE LLC. All rights reserved. SUSE and the SUSE logo are registered trademarks of SUSE LLC in

the United States and other countries. All third-party trademarks are the property of their respective owners.