DEV Community

loading...

Learn OpenStack by Example: Part 1 - Install DevStack

Will Siddall
Updated on ・10 min read

In my first post, I looked into what is OpenStack and how, if done right, can be quite a powerful ally in our cloud deployment strategies. In this post, I want to start looking at how we can create an application to learn the basics and components of the system.

To do this, we first need a development environment that we can access and push to. This is where DevStack

What is DevStack?

DevStack

The development environment for OpenStack provides a convenient way of setting up a minimal environment for you to test and integrate your application without building up a large build. Each component is itself a completely independent project maintained by the OpenStack team, and thus by installing OpenStack, you have to clone each project repository to your environment to use it.

By default, the environment doesn't contain all components that OpenStack provides. Instead, you're offered:

  • Keystone (Identity Service)
  • Glance (Image Service)
  • Nova (Compute Service)
  • Placement (Placement / HTTP API Service)
  • Cinder (Block Storage)
  • Neutron (Networking)
  • Horizon (Dashboard Service)

OpenStack also provides a wealth of other components that can be used to provide additional resources. Some for example that can be used for application development would include Trove (Database as a Service) and Zaqar (Messaging/AMQP Service). We'll get into how we can customize our environment later as this requires creating some configuration files.

Before we even start installing, it's best to figure out where you want to install it. I'm always a fan of setting up a Virtual Machine for these purposes as it's easy to remove the whole environment if things get messy and start fresh or revert to a snapshot of a previous step in my set up. That decision up to. If you are considering installing on your local machine, know the scripts will want to install the installation repository in your home directory under the devstack directory, and will try to install all components under the /opt/stack directory.

NOTE: If you're using Windows (especially a version that doesn't support WSL2), you will be required to us a Virtual Machine since most of the components are built and tested against Ubuntu and other major distributions.

For these exercises, I've set up a Ubuntu Virtual Machine that will host my components.

Setting up Virtual Machine (recommended)

To ensure all steps will complete with fewest possible failures, I will set up a QEMU Virtual Machine using Ubuntu 20.04. I won't go through the steps to do this as this is well documented everywhere. Some notes that I recommend to use though would be:

  • Memory: anything > 4GB (I used 8GB)
  • CPUs: I'd assign half of the available CPUs on your machine.
  • Disk: At least 50GB, but 100GB recommended. I originally started with 30GB and quickly ran out of space since you'll need to load disk images and VM volumes within this space.
  • Network: Use defaults, 1 interface. DevStack will take ownership of the network interface to map it onto a bridge.
  • User: stack
  • Password: something secure
  • Packages: OpenSSH Server (recommended). This will make interacting with the system more efficient, but can still do all necessary steps via the VM's console window.

Once you do get to a login prompt, you can follow these commands to make sure your environment is up to date:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo reboot
Enter fullscreen mode Exit fullscreen mode

Installing DevStack

With a terminal open to your user home directory, run the following commands to download and install the DevStack installation utilities.

One thing to know before hand, you must decide which version of OpenStack you want to use. At the time of writing, "Wallaby" is the stable release but many of the child components are still marked as Under Development for this version. In this case, you may want to use "Victoria". For the purpose of this exercise, I will use "Wallaby".

Download and Install the DevStack components

Setting up DevStack on your system only involves cloning the github repository for the specific version you want to use. The latest stable release is wallaby so I'll be using the branch stable/wallaby for this exercise.

The other thing to note is replace $MyPassword with the admin password you want to use and also recommended to create unique passwords for the other systems.

sudo -l    # Lists user permissions, should include "(ALL : ALL) ALL"
sudo apt-get install git
git clone https://github.com/openstack-dev/devstack -b stable/wallaby   # Here is where you specify which version to use
cd devstack
cat > local.conf << EOF
[[local|localrc]]
ADMIN_PASSWORD=$MyPassword
DATABASE_PASSWORD=\$ADMIN_PASSWORD
RABBIT_PASSWORD=\$ADMIN_PASSWORD
SERVICE_PASSWORD=\$ADMIN_PASSWORD

SWIFT_HASH=$(echo $RANDOM | md5sum - | awk '{ print $1}')
SWIFT_REPLICAS=1
enable_service s-proxy s-object s-container s-account
EOF
./stack.sh
Enter fullscreen mode Exit fullscreen mode

Creating the local.conf is optional but invaluable as it provides customizations that you can apply to your system. There's a LOT of documentation that covers how to use it, but in summary: any variable needed or component configuration file created can have new values defined here specific to your system. This is not necessary for some cases but because I want to include the Swift Object Storage component (not installed by default), I had to include the enable_service line for the system services to install and enable.

The final command (./stack.sh) runs the setup scripts found in the cloned repository and the created configuration file to start the downloading of component repositories into the /opt/stack directory and set them up for your environment. If you don't include the password lines in local.conf, the script will prompt for passwords but we've included them so this will be skipped. This is not the OS user, so this can be something new.


NOTE
If you run into an issue during the installation process related to the MySQL connection denied (access denied for user 'root'@'localhost'), run the script again as it appears the script may have started the database processes before the database was ready


Needing to start over
If you do run into issues with your install and want to start from scratch, a quick way (if you're using a VM) is to have created a system snapshot before the initial install and revert back to it.

Another way is to run the DevStack clean commands to remove all components

./unstack.sh && ./clean.sh && sudo rm -rf /opt/stack
Enter fullscreen mode Exit fullscreen mode

The remaining of the installation WILL take some time, so maybe go get a snack or meal.

Once the installation is complete, you'll get an output at the end that provides the endpoints and credentials that will allow you to open a dashboard and look into the workings of your mini cloud.

Completed Output

Review DevStack Installation (Horizon Dashboard)

With the completed installation, you can use the address and credentials provided to open up the Horizon/Dashboard interface to your new cloud.

Horizon Dashboard

From the Dashboard, we can review some of the most important aspects of our new stack: Compute/Server Nodes, Storage Volumes, and Virtual Networks. Let's briefly review the areas of the stack and their functions starting from the bottom.

Object Store (Swift)

This is the component we told DevStack to install via our local.conf file. This is how we define the containers that will be used by our applications

Swift Dashboard

For this review, we won't do much as we'll configure this later.

Network (Neutron)

Network Dashboard

While for our first example, we won't be making many changes here, it's still a very important aspect to cover. The Networking component handles the virtual networks and traffic management within your applications. This is very important in cases where you want to set up multiple server nodes with the same process and have them load-balanced, or if you want to isolate some traffic while exposing others via another network. You can get into some really fancy configurations and the OpenStack Project Components page has some great examples of these.

Web Application Sample Configuration

All you need to know for now is the Networking component is further broken down into 4 sections:

  • Network Topology - Provides a visual reference of the available networks and how they relate to each other
  • Networks - Manage available networks and their definitions (via subnets)
  • Routers - Manage logical routers and define rules for their operations include port forwarding, and the networks and subnets they act on.
  • Security Groups - Can be thought of as a virtual firewall for servers and resources within a project.
  • Floating IPs - Allows specifying a static IP address to provide port-forwarding capabilities which resources can be assigned.

We will be covering Networking in a bit more detail in the next post.

Volumes (Cinder)

Volume Dashboard

This is your Block Storage component of the cloud. Any time you want to hold onto a disk image of your VM or want to spin up a disk resource for deploying applications, this is where you go. Block Storage is much simpler to understand than the other components but nothing would work without it.

The parts of this area include:

  • Volumes - These are the disk images that you can work with. They can be assigned to a server node or may be floating.
  • Snapshots - These are what you think they are, snapshots of any given volume at the moment the snapshot is taken. This is great for critical environments that would cause problems if the disk image became corrupt, you could restore the snapshot to re-start your server to recover what you can or prevent the issue from occurring.
  • Groups - This expands on the idea of Snapshots where you can define groups of Volumes that, when you specify or at scheduled intervals, can create snapshots for that moment in time. This area only defines the groups definitions themselves, while...
  • Group Snapshots - Contains the snapshots collected from the Groups definitions.

Compute (Nova)

Compute Dashboard

Servers created in the Compute component can easily be thought of as Virtual Machines/Servers and are the backbone of the whole operations. Any time you want to deploy an instance of an application, it will often be in one of these nodes. Want a self-built Web API Service, deployed here. Want a traffic proxy with authentication, deployed here. Want a PostgreSQL/MongoDB/Redis/other db, a commercial server-side backend service, they would all be deployed here. These servers are miniaturized servers that focus on one or few tasks for the larger application as a whole, much in the same way that Docker or Kubernetes would deploy any instance.

This is slightly different to other cloud platforms (like Google Cloud, Amazon, Azure, etc...) wherein they will spin up a "compute" node of just the code you want to run. What's actually happening in the background is they are still spinning up a new VM instance with dedicated memory and network presence for that bit of code. The difference here is you have full control of the image used and what it does.

As there's a bit more complexity to what can be done with these instances, there's also a bit more involved with the dashboard environment as well.

  • Overview - Performance dashboard of all nodes within your project. This also includes metrics from other components like Network and Volumes.
  • Instances - Heart and soul of this component. This is the configured server nodes created for your project.
  • Images - Much like Docker Hub images, or pre-built base ISO images, this is the base images that you can refer to for deploying new Instances.
  • Key Pairs - Can be a little confusing, but this manages Access keys. Instances can refer to one of these keys and (as long as the private key is installed on another machine), would provide access to the instance that has subscribed to it.
  • Server Groups - This section defines dynamic rules that groups servers automatically while also defining policies these servers will abide by. At this point, I won't get into policies as a brief look at the documentation had me starring down a rabbit hole I know would take me too long to get out of.

Start Your First Server Node

To finish off this post, let's create a blank image server which we can log and interact with it's command line. In the process, we'll use an existing Image to create a new Volume. Luckily, OpenStack does a great job at making this easy through the dashboard.

  1. From the dashboard, we'll go to the Compute section and select Instances.
  2. Select the "Launch Instance" button
  3. From here, we need to fill in multiple sections to get this running. Starting in the Details tab, set the Instance Name to test.
  4. Next in the Source tab, set the select the cirros- image. Cirros is the base image used by default for OpenStack, but we'll look at loading our own images later. To select the image, click on the up arrow next to the item to move it into the Allocated group.
  5. In the Flavor tab you will find the instance configuration that will provision your instance. Notice how many of these are similar to what you see on other popular cloud platforms. Choose the one you want, I'll go with m1.micro.
  6. Lastly, in the Networks tab, we need to specify which network this server will be connected. For this exercise, let's choose the shared network.

After selecting the network, click on Launch Instance. This will start a scheduled task to create the VM and create the disk volume using the Cirros image as it's base.

Instance Created

Connect to Instance Console

From here, you can connect to the new instance's console.

  1. Click on the new instance's name, test
  2. In the instance's detail window, select the Console tab to open the instance's remote terminal console.
  3. You should see the instance console pop up with the username and password you should use. Log in with those credentials

You should now have a console to a fully operating server.

Conclusion

We've covered a lot of topics here, but we now have a working VM hosted within our OpenStack deployment. In the process:

  • Took a brief look at the development environment of OpenStack, DevStack
  • Reviewed some of the components that normally comes with it
  • Toured around the dashboard component, Horizon, and
  • Reviewed the managed components from the Dashboard including Networking (Neutron), Block Storage (Cinder), and Compute Nodes (Nova).
  • Created our first instance.

As mentioned in my introductory post, this is as much a learning exercise for myself and try to make what I've learned accessible to anyone else. If you're familiar OpenStack and have some insights that could help this documentation, please feel free to reach out!

Thanks!

Discussion (0)