Mirantis OpenStack Express — Running OpenStack from the Command Line

This is the eighth in a series of short tutorials showing how to perform common cloud operations tasks in Mirantis OpenStack Express 2.0 — Mirantis’ “Private Cloud as a Service”

In our last tutorial, we began exploring Mirantis OpenStack Express’s VPN-as-a-Service feature — an important capability for creating linked and hybrid clouds. Now, we’re going to start peeking under the hood, and learn how to find our way to the OpenStack command line for your Mirantis OpenStack Express cloud or project/tenant.

 

Basic Ops Tutorials

Mirantis OpenStack Express — Mirantis’ “Private Cloud as a Service” — is the fastest way to get your hands on a fully-functional, optimally-configured, private OpenStack cloud, running on hosted bare metal and able to scale on demand. This series of short tutorials shows how to perform common cloud operations tasks in MOX, and offers links to documentation and learning resources. Though aimed at Mirantis OpenStack Express, many of the techniques discussed here will also work on a private OpenStack cloud deployed using Mirantis OpenStack.

Tutorials:

 

Why the Command Line?

Why access your Mirantis OpenStack Express cloud from the command line? One reason is to exploit the hundreds of powerful commands not available through Horizon. (There are hundreds of commands in the complete OpenStack Command-Line Reference.)

Just as important, accessing OpenStack from the command line, and ultimately via its REST APIs, gives you the power to automate operations. This can save you time, and opens the door to applications like continuous-integration/continuous-delivery (CI/CD).

That’s why Mirantis OpenStack Express gives you full root access to your private OpenStack environments — something most cloud-as-a-services don’t do.

Step by Step

The fastest way to get to your cloud’s command line is by leapfrogging: SSH into your Fuel Master Node, then use its authentication to log directly into your controller node as root.

Three preparatory steps are required:

First, get the IP address of the Fuel server, plus credentials, from the Mirantis OpenStack Express Dashboard:

From your MOX dashboard, click the Credentials link. At the bottom of the popup, you’ll see an IP address for the Fuel Master Node, plus login details, for SSH’ing into your Fuel server.

You can SSH into your datacenter’s Fuel Master Node using the URL and credentials on your Mirantis OpenStack Express Dashboard.

Next, use Fuel to find the fully-qualified internal domain name (FQDN) of the controller node of the cloud you want to access:

  • On the same popup, right above the SSH IP, you’ll see a link to Fuel, along with login details. Click the link, and if necessary, supply the username and password.
  • At the Fuel homepage, click the icon corresponding to the cloud you want to access.
  • Under the Nodes tab, find the Controller node, and click the gear icon to the right. This pops up a summary dialog of this node’s characteristics.
  • Find the FQDN of the Controller node: on my cloud, this is ‘node-3.’
The FQDN of your controller node can be found in Fuel. From the Environments homepage, click on the cloud you want to access. Then under Nodes, click the gear icon of the Controller. The popup that appears will show the domain name of the Controller.

Finally, from Horizon, get the OpenStack remote control or RC script you’ll use to authenticate to the OpenStack API:

Get the script by going to our cloud’s Horizon interface, clicking Project, Access & Security, clicking the API Access tab, and clicking the button on the upper right, marked Download OpenStack RC File. The toplevel RC file is called admin-openrc.sh.

You can download an RC file to authenticate you to the OpenStack API by downloading it from the Access & Security menu’s API Access tab. Each Project (tenant) has its own.

Here’s what it looks like (see below). In fact, this step is optional, since an identical openrc script is automatically saved for you in the root directory of your Controller node by Fuel. But we’re going through the process anyway, so you can see how it works in other spins of OpenStack you may encounter, and later, if you want to authenticate in the context of tenant projects.

The RC file sets authentication parameters into your environment when you’re on the Controller node, so you don’t have to enter them for every command. We don’t actually need this file to administer our cloud from toplevel, because an identical file is saved in the root of the Controller by Fuel at deployment time, for your convenience. Knowing about obtaining and moving RC files, however, will help if you want to authenticate in the context of specific projects, as users other than Admin.

The next steps involve leapfrogging via SCP and SSH from your desktop to the Fuel server, and then from the Fuel server to your cloud’s Controller node, as root.

Using the IP address, login (fuel) and password we retrieved from the Credentials popup, we start by SCPing the RC file to the Fuel server’s current working directory.

Leapfrogging begins. Here, we SCP the admin-openrc.sh file to the Fuel Master node.

Note the addition of ‘:.’ to the end of the IP address to denote the CWD. You’ll need to provide the fuel account’s password.

Then we SSH to the same place, again supplying the fuel account’s password.

Next, we SSH to the Fuel Master Node, using the password to log in.

Now for our second leapfrog jump. First, we SCP the RC file to the CWD of the root account on the Controller server.

Our second leapfrog jump entails SCP’ing the admin-openrc.sh file to the root account of the Controller node. Here, we don’t need to supply a password, because Fuel is pre-authenticated.

Finally, SSH to the Controller server.

We SSH into the Controller node as root, completing the leapfrog access path.

And you’re there! Now we can authenticate to OpenStack by sourcing our RC file. We could also have sourced the openrc file already in place, and avoided all the scp file transfers.

We authenticate to the API by using source on the RC file we brought in. Then, to show that the default openrc file is also in place, we source to that.

Now we can issue a test command to see if we’re hooked up. The command keystone tenant-list will produce a list of tenants (projects) currently active in our cloud.

The command keystone tenant-list produces a list of projects (tenants) currently active in our cloud.
Now go on to our next post in this series and learn how to put your newfound OpenStack CLI skills to work by defining and launching a VM, and installing Apache on it automatically.

 

Resources:

Check out Express for yourself at https://express.mirantis.com.

Latest Tweets

Suggested Content

WEBINAR
Edge Computing: A Unified Infrastructure for All the Different Pieces