1. Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Basic Tutorials [EN] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 The first stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1.1 Create a Stack from the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1.2 Create a Stack via the Horizon Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2 The first vm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2.1 Create a vm from the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Can you explain ... ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.1 Basic components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.2 Extensions to the OpenStack client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.3 The OpenStackClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Guided Tour: From the browser to an self written heat template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4.1 Step 1: The Horizon(Dashboard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.2 Step 2: Create an SSH-Key via the Horizon(Dashboard) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.3 Step 3: Spawn a new Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4.4 Step 4: Our way to the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.5 Step 5: An overview of the most important commands of the OpenStackClient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.4.6 Step 6: Create and use our own SSH-Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.4.7 Step 7: The first VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.8 Step 8: Delete the first VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.4.9 Step 9: A Security Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401.4.10 Step 10: Getting access to the Internet: Creating a network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431.4.11 Step 11: Prepare access to the internet: Add IPv6 to our network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481.4.12 Step 12: A usable VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531.4.13 Step 13: The structured way to create an instance (with stacks) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571.4.14 Step 14: Our first steps with HEAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591.4.15 Step 15: The first heat template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621.4.16 Step 16: Let's get to know HEAT better . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641.4.17 Step 17: The network in Heat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651.4.18 Step 18: Our vm will be reachable via IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721.4.19 Step 19: We will add IPv6 to our template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761.4.20 Step 20: Build multiple VMs via HEAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Documentation

Basic Tutorials [EN]

The first stack

Create a Stack from the console

Requirements

If you want to create a stack from the console, you will need to have the OpenStack client installed and you need to have an SSH keypair set up. 

Get the required credentials 

If we want to get access via the API, we need our credentials available in our console session. For this, navigate to the dashboard, login with your credentials and then navigate to upper right, click on your e-mail and then onHorizon  "OpenStack RC File v3"This file contains all needed credentials to authenticate via the API. 

We need to include this file via this command (IMPORTANT: You will need to be in the same folder as the downloaded file):

$ source EXAMPLE.sh

Now that we have access to the API, it's time to create our first stack. First we need a template, in this example we use SingleServer.yamlNow we can run the command that spawns the stack (Please replace EXAMPLEKEY with the name of your ssh key):

$ openstack stack create -t SingleServer.yaml --parameterkey_name=EXAMPLEKEY EXAMPLENAME+---------------------+-------------------------------------------------+| Field | Value |+---------------------+-------------------------------------------------+| id | 8c3fe51f-aa63-44b3-948a-b1f31483fe1a || stack_name | EXAMPLENAME || description | A simple template to deploy your first instance || creation_time | 2017-12-11T09:41:01Z || updated_time | None || stack_status | CREATE_IN_PROGRESS || stack_status_reason | Stack CREATE started |+---------------------+-------------------------------------------------+

When the stack has been successfully created, we can verify that every works. Let's try to connect to the new stack! To do this we need the floating IP (Also known as the public IP), which can be seen in the dashboard or we can use (this only works ifHorizonwe're using the aforementioned template to create our stack) SingleServer.yamlopenstack stack output show ID instance_fip and exchange ID with real ID of your stack like this:

$ openstack stack output show 8c3fe51f-aa63-44b3-948a-b1f31483fe1ainstance_fip+--------------+---------------------------------+| Field | Value |+--------------+---------------------------------+| description | External IP address of instance || output_key | instance_fip || output_value | 185.116.245.83 |+--------------+---------------------------------+

Now it's possible to connect to our first instance with ssh.

ssh ubuntu@185.116.245.83

 

Create a Stack via the Horizon Dashboard

Requirements

If we want to create a stack, we need to have an SSH keypair configured.

Launch a Stack

To create a new Stack, first we need a template that defines the stack..In this tutorial we will be using the template that can be found in our git repository, we recommend that you do the same.SingleServer.yaml

First we login to the dashboard, using your credentials.HorizonNow we can navigate to Stacks, which is located under Orchestration,  and click on "Launch Stack".

In the pop-up we choose "File" as the Template Source, then select the file SingleServer.yaml as the Template File, when that's done, we click"Next".

In the next screen, we need to supply some additional data.Input the following  and click "Launch" when done:

Stack Name: BeispielStackCreation Timeout: 60Password for User: Please use your own passwordavailability_zone: ix1flavor_name: m1.microkey_name: BeispielKey (Please enter your own keypair here.)machine_name: singleserverpublic_network_id: provider

The stack will be created and the interface should look like this:

We can check if the instance defined in the stack has been created successfully. Navigate to Compute -> Instances and the overview should look like this:

It's now possible to log in to your new instance via SSH!You can do so via this command (Note that you need to replace the IP with the IP your own instance has been given):

ssh ubuntu@185.116.245.106

The first vm

Create a vm from the console

Prerequisites

You can easily start a single vm from the console, to do this, we will need a properly installed OpenStack client.In a normal workflow, we would recommend doing this with a Heat stack, which is described , or, alternatively, to use . We alsohere Terraformrecommend having an configured and to have a set up.SSH keypair security group

Installation

If all the prerequisites have been met we can create a server from the console thusly:

openstack server create <server-name>

Running this command like this will return an error as we'll need to supply some information that OpenStack needs to create a new server.We need to supply a security group, a flavor and an SSH keypair.To properly start a VM we will need the aforementioned SSH keypair and security group.We will also need a network (see: Step 10: Prepare access to the Internet: Create a network), to connect to our vm.

A proper creation command would look like this:

openstack server create <server-name> --flavor m1.small --security-groupallow-ssh --key-name ExampleKEY --network ExampleNetwork --image "Ubuntu16.04 Xenial Xerus - Latest"

There are many more parameters you can supply to change settings on your new servers. to get a listing of them all you can type:

openstack server create --help

Can you explain ... ?

Basic components

Heat

Heat is the component that handles OpenStack orchestration, it allows us to maintain complex setups with the help of templates.An template is a structured text file and should be treated like normal code.Some basic examples of heat templates can be found in the guided tour Step 15: The first heat template.

Nova

Nova manages every single virtual machine (VM), including creation and deletion.

The service can be managed via the API, Heat or the Horizon dashboard.You can get acquainted with nova via the official OpenStack documentation: https://docs.openstack.org/developer/nova/how_to_get_involved.html

In our Guided Tour: From the browser to an self written heat template we use the OpenStackClient instead of Nova.

Horizon (Dashboard)

The Horizon dashboard is the graphical user interface, which can manage all needed openstack services.You can administrate certain things in the Horizon dashboard, for example, creating and deleting a vm.The Horizon dashboard is very useful for non-recurring tasks, but if you want to automate something, Heat is more efficient. 

Neutron

Neutron provides "network connectivity as a service", for example Nova uses the network connectivity it provides. 

It also associates interfaces with devices and maintains a connection between these interfaces.You can get acquainted with Neutron via the official OpenStack documentation: https://wiki.openstack.org/wiki/NeutronDevelopment

In our Guided Tour: From the browser to an self written heat template we use the OpenStackClient instead of Neutron.

 

 

Extensions to the OpenStack client

These are extensions to the OpenStack client, they will add functionality to the client but will also add clients that can be used instead.The installation is similar to the OpenStack client:

We need to activate our virtual environment again:

$ source ~/.virtualenvs/openstack/bin/activate

Now we can install the clients:

(openstack) $ pip install python-PROJECTclient

Some examples, which are also part of the official OpenStack website:

cinder - Block Storage API and extensionsglance - Image service APIheat - Orchestration APIneutron - Networking APInova - Compute API and extensionsswift - Object Storage API

 

The OpenStackClient

Preface

To make the administration of OpenStack as simple as possible, we recommend using the  . OpenStackClientFor simple, non-recurring tasks, it can be simpler to use the . Horizon dashboardAs soon as tasks begin to recur, or when we want to manage a complex stack, we prefer to use the OpenStack client and Heat. At the start this may seem a bit complicated but once we get used to it, managing stacks becomes fast and efficient.

The client will be helpful in our daily OpenStack work, it contains Nova, Glance, Cinder and Neutron. We will use the client heavily in our GuidedTour. We will walk you through installing it now.

Installation

To install the OpenStackClient, we need at least   and also  (which are included in MAC OS X).Python 2.7 Python SetuptoolsThere are a few ways to install the OpenStackClient, in our example, we use and we recommend you do the same.pip" " is easy to use and can also be used as update manager for  .pip pipIt's possible to install the client as root (the administrative user), but that can potentially cause some problems, so we will install it in a virtualenvironment.

Mac OS X

To install the OpenStackClient, we need to install . Start the console (Launchpad Console) and type this command:pip

$ easy_install pipSearching for pipBest match: pip 9.0.1Adding pip 9.0.1 to easy-install.pth fileInstalling pip script to /usr/local/binInstalling pip2.7 script to /usr/local/binInstalling pip2 script to /usr/local/bin

Using /usr/local/lib/python2.7/site-packagesProcessing dependencies for pipFinished processing dependencies for pip

Now we install virtualenv.

$ pip install virtualenvCollecting virtualenv Downloading virtualenv-15.1.0-py2.py3-none-any.whl (1.8MB) 100% |????????????????????????????????| 1.8MB 619kB/sInstalling collected packages: virtualenvSuccessfully installed virtualenv-15.1.0

Now that we have virtualenv installed, we can create the virtual environment.

$ virtualenv ~/.virtualenvs/openstackNew python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/pythonInstalling setuptools, pip, wheel...done.

Now that it's created we can activate the virtual environment.

$ source ~/.virtualenvs/openstack/bin/activate(openstack) $

Now that the virtual environment is activated, we can install the openstack client.

(openstack) $ pip install python-openstackclient

As we'll be using heat in our documentation, we'll install that as well.

(openstack) $ pip install python-heatclient

Now that we're done, we can deactivate our environment.

(openstack) $ deactivate

To finish it off, we'll make sure we can use the client outside of our virtual environment.

export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH"

Now we can check, if everything works and it should look like this:

$ type -a openstackopenstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack

Windows 

If Python is already installed, we need to navigate to where it's installed (standard installation folder C:\Python27\Scripts).To install "pip" we will use the command "easy_install pip":

Once pip is installed, we can install the OpenStack client:

Linux (in our example Ubuntu)

To start things off, we'll install pip.

$ sudo apt-get install python-pipReading package lists... DoneBuilding dependency treeReading state information... Done

Next, we'll install virtualenv, which we'll need to set up our virtual environment.

$ sudo apt install python-virtualenvReading package lists... DoneBuilding dependency treeReading state information... Done

Now we can create a virtual environment, in which we can install the OpenStack client.

$ virtualenv ~/.virtualenvs/openstackNew python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/pythonInstalling setuptools, pip, wheel...done.

Now we activate our freshly created environment.

$ source ~/.virtualenvs/openstack/bin/activate(openstack) $

Once activated, we can install the :OpenStackClient

(openstack) $ pip install python-openstackclient

As we'll use heat in our documentation, we'll also install the heat client.

(openstack) $ pip install python-heatclient

Once done, we can deactivate our virtual environment.

(openstack) $ deactivate

To finish up, we'll make sure that we can use our newly installed software.

export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH"

Now we can check, if everything works and it should look like this:

$ type -a openstackopenstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack

Credentials

For the OpenStack client to work, we'll need to supply it with credentials.We can download the credentials directly from the  dashboard, after we login, click on your mail Adress in the right corner and an then on Horizon"Download OpenStack RC File v3". The last thing to do is to source the credentials, which can be easily done with this command (IMPORTANT: The command can only be used in

 the folder where the RC file was downloaded): 

source EXAMPLE.sh

 ConclusionWe have a working OpenStack client with working credentials, we are now ready to follow the rest of the documentation.

Frequently asked questions

The command "openstack --help" shows the error "Could not load EntryPoint.parse" 

How can i use vrrp?It's possible to use ED25519 SSH keys? Why I have to pay for unused Floating IPs?

The command "openstack --help" shows the error "Could not load EntryPoint.parse" 

In this case some components of the OpenstackClient are outdated.You can use the command below, to get an overview of which components need to be updated:

openstack --debug --help

This will show you which components need to be updated, which you can do with the command below. (Replace PROJECT with the correctproject):

pip install python-PROJECTclient -U

 

How can i use  ?vrrp

In order to use VRRP, you will need to add a rule to a security group that's associated with an actual VM.You can only add this via the OpenStack client! An example of adding vrrp to a security group would be:

openstack security group rule create --remote-ip 10.0.0.0/24 --protocolvrrp --ethertype IPv4 --ingress default

 

It's possible to use ED25519 SSH keys? 

For now, it's not possible to use ED25519 SSH keys.There is a bug in OpenSSL that's needed for the TLS layer in OpenStack.You can track the progress of this bug in these two tickets: and https://github.com/openssl/openssl/issues/487 https://bugs.launchpad.net/nova/+bug/1555521

Why I have to pay for unused Floating IPs?

It's likely that you didn't delete the floating IPs after you removed the machines that were using them.To get an overview of your floating IPs, you can use the Horizon dashboard, where you can find the overview at:Project Network Floating-IPs

You can accomplish the same with the OpenStack client:

$ openstack floating ip list+--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+----------------------------------+| ID | Floating IP Address | Fixed IPAddress | Port | Floating Network | Project |+--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+----------------------------------+| 84eca713-9ac1-42c3-baf6-860ba920a23c | 185.116.245.222 | 192.0.2.7 | a3097883-21cc-49fa-a060-bccc1678ece7 |54258498-a513-47da-9369-1a644e4be692 | b15cde70d85749689e6568f973bb002 |+--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+----------------------------------+

Guided Tour: From the browser to an self written heat template

Step 1: The Horizon(Dashboard)

Preface

In this step by step tutorial, we will ease you into using OpenStack.We'll start with the Horizon dashboard, after that we'll switch to the console and then finish up with writing our own Heat template.

Login

After you have received your credentials, we can log in to the dashboard. : There is no automatic way to reset the password, if you need a new password, please write an e-mail to info@innovo-cloud.deIMPORTANT

The URL for the dashboard is https://dashboard.optimist.innovo.cloud/

You should see the login form, use  field and also use your username and password in the appropriate fields.default for the DomainTo log in, click .Connect

 

Change Password

For security reasons we recommend that you change your password after you received it from us. It's easily changed via clicking your Username(1) in right corner of the Horizon and then clicking (2).Settings

Now you will see the settings page, where you can change various settings.To change the password, click on  (1) in the left side-navigation and you need to enter your old one(2), enter the new one(3)Change Passwordand confirm the new one(4).

To save it, click (5).Change

Conclusion

You've taken your first steps in the dashboard and changed your password!

Step 2: Create an SSH-Key via the Horizon(Dashboard)

Start

To continue our guide, we will need a SSH keypair, If you already have keypair and you know how to use it, you can skip this step and go directlyto step 3.

Installation 

There are many ways to generate our SSH keypair, we will create a keypair manually later but we will create it from the dashboard in this step.To create the SSH keypair, we need to go to and click .Compute -> Key Pairs Create Key Pair

A dialog will appear where we can name the key, in this example we will use and click BeispielKey Create Keypair.

ConclusionWe've now created our SSH keypair and are ready for the rest of the tutorial!

Step 3: Spawn a new Stack

Introduction

In this step we will use the dashboard to spawn a stack that includes a VM. We will also use this step to get better acquainted with the dashboard.For this step we will need the SSH keypair created in Step 2.

StartTo spawn a new stack, we will need a template that starts a VM.In this tutorial we use the  from our git repository and recommend you do the same.SingleServer.yaml

Once we acquired the template, we need to login to the dashboad with the password that we changed in step 1. Now we can go to and click on Orchestration  Stacks Launch Stack:

In the dialog that pops up, we select as our  and use the downloaded as our , and click   File Template Source SingleServer.yaml Template File Next.

In the next page of the dialog, we supply the following data:

Stack Name: BeispielServerCreation Timeout: 60Password for User: Please use your own passwordavailability_zone: ix1flavor_name: m1.microkey_name: BeispielKeymachine_name: singleserverpublic_network_id: provider

After everything is filled in, we click to spawn the stack.Launch

The stack will spawn and it will look like this.

We can verify, if the stack has started the instance correctly. Navigate to -> and the overview should look like this:Compute Instances

So we have spawned the stack, now we want to delete it including the VM. It's also possible to delete only the instance, but this could be problematic if you want to delete the stack afterwards.To delete a stack, you will navigate  to and click on the behind the Example Stack, now we can choose Orchestration -> Stack down-arrow Del

.ete Stack

Conclusion

We have created our first stack.... and then deleted it!

Step 4: Our way to the console

Preface

To make the administration of OpenStack as simple as possible, we recommend using the  . OpenStackClientFor simple, non-recurring tasks, it can be simpler to use the . Horizon dashboardAs soon as tasks begin to recur, or when we want to manage a complex stack, we prefer to use the OpenStack client and Heat. At the start this may seem a bit complicated but once we get used to it, managing stacks becomes fast and efficient.

The client will be helpful in our daily OpenStack work, it contains Nova, Glance, Cinder and Neutron. We will use the client heavily in our GuidedTour. We will walk you through installing it now.

Installation

To install the OpenStackClient, we need at least   and also  (which are included in MAC OS X).Python 2.7 Python SetuptoolsThere are a few ways to install the OpenStackClient, in our example, we use and we recommend you do the same.pip" " is easy to use and can also be used as update manager for  .pip pipIt's possible to install the client as root (the administrative user), but that can potentially cause some problems, so we will install it in a virtualenvironment.

Mac OS X

To install the OpenStackClient, we need to install . Start the console (Launchpad Console) and type this command:pip

$ easy_install pipSearching for pipBest match: pip 9.0.1Adding pip 9.0.1 to easy-install.pth fileInstalling pip script to /usr/local/binInstalling pip2.7 script to /usr/local/binInstalling pip2 script to /usr/local/bin

Using /usr/local/lib/python2.7/site-packagesProcessing dependencies for pipFinished processing dependencies for pip

Now we install virtualenv.

$ pip install virtualenvCollecting virtualenv Downloading virtualenv-15.1.0-py2.py3-none-any.whl (1.8MB) 100% |????????????????????????????????| 1.8MB 619kB/sInstalling collected packages: virtualenvSuccessfully installed virtualenv-15.1.0

Now that we have virtualenv installed, we can create the virtual environment.

$ virtualenv ~/.virtualenvs/openstackNew python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/pythonInstalling setuptools, pip, wheel...done.

Now that it's created we can activate the virtual environment.

$ source ~/.virtualenvs/openstack/bin/activate(openstack) $

Now that the virtual environment is activated, we can install the openstack client.

(openstack) $ pip install python-openstackclient

As we'll be using heat in our documentation, we'll install that as well.

(openstack) $ pip install python-heatclient

Now that we're done, we can deactivate our environment.

(openstack) $ deactivate

To finish it off, we'll make sure we can use the client outside of our virtual environment.

export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH"

Now we can check, if everything works and it should look like this:

$ type -a openstackopenstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack

Windows 

If Python is already installed, we need to navigate to where it's installed (standard installation folder C:\Python27\Scripts).To install "pip" we will use the command "easy_install pip":

Once pip is installed, we can install the OpenStack client:

Linux (in our example Ubuntu)

To start things off, we'll install pip.

$ sudo apt-get install python-pipReading package lists... DoneBuilding dependency treeReading state information... Done

Next, we'll install virtualenv, which we'll need to set up our virtual environment.

$ sudo apt install python-virtualenvReading package lists... DoneBuilding dependency treeReading state information... Done

Now we can create a virtual environment, in which we can install the OpenStack client.

$ virtualenv ~/.virtualenvs/openstackNew python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/pythonInstalling setuptools, pip, wheel...done.

Now we activate our freshly created environment.

$ source ~/.virtualenvs/openstack/bin/activate(openstack) $

Once activated, we can install the :OpenStackClient

(openstack) $ pip install python-openstackclient

As we'll use heat in our documentation, we'll also install the heat client.

(openstack) $ pip install python-heatclient

Once done, we can deactivate our virtual environment.

(openstack) $ deactivate

To finish up, we'll make sure that we can use our newly installed software.

export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH"

Now we can check, if everything works and it should look like this:

$ type -a openstackopenstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack

Credentials

For the OpenStack client to work, we'll need to supply it with credentials.We can download the credentials directly from the  dashboard, after we login, click on your mail Adress in the right corner and an then on Horizon"Download OpenStack RC File v3". The last thing to do is to source the credentials, which can be easily done with this command (IMPORTANT: The command can only be used in

 the folder where the RC file was downloaded): 

source EXAMPLE.sh

 ConclusionWe have a working OpenStack client with working credentials, we are now ready to follow the rest of the documentation.

Step 5: An overview of the most important commands of the OpenStackClient

Start

Now that we've installed the OpenStack client in step 4, we will learn some of the more important commands for it.To get more details about a specific subcommand, you can append the flag to it.--help

To list all commands, you can use without any other information:--help

openstack --help

 

ServerWith the command "openstack server" it's possible to create, administrate or delete a VM.Here is a list of some common commands:

openstack server addThis commands will add parameters (Fixed IP, Floating IP, Security group, Volume) to a VM.

openstack server createThis command creates a VM.openstack server delete This command deletes a VM.openstack sever list This command shows a list of all VMs.openstack server remove This command will remove parameters (Fixed IP, Floating IP, Security group, Volume) from a VM.openstack server show This command shows all important information about the specified VM.

StackWith the command "openstack stack" you are able to administrate complete stacks, like "openstack server" for instances.Here is a list for some common commands:

openstack stack create

This command creates a new stack.openstack stack list This command lists all stacks.openstack stack show This command shows all important information about the specified stack.openstack stack delete This command deletes the specified stack.

 

Security Group

Security Groups are used, to allow or deny incoming and outgoing network traffic based on ip-adresses and ports for VMs.You can also manage security groups in the OpenStackClient. Here are some common commands:

openstack security group createCreates a new security groupopenstack security group deleteDeletes a security groupopenstack security group listList of all security groupsopenstack security group showShows all important information about a security groupopenstack security group rule createAdds a rule for a security groupopenstack security group rule deleteDeletes a rule in a security group

Network

To create VMs, they need a network, here are some common network commands:

openstack network create Creates a new networkopenstack nerwork list List of all networksopenstack network show Shows all important information about a networkopenstack network delete Deletes a network

 

Router

For the VMs on your network to reach the internet, you need a router, here are some common router commands:

Here are some basic commands:

openstack router create Creates a new routeropenstack router delete Deletes a routeropenstack router add port Adds a port to a routeropenstack router add subnet Adds a subnet to a router

 

Subnet

To use a virtual router correctly, we will need a subnet, which can be administrated with "openstack subnet" and here are some commoncommands:

openstack subnet create Creates a new subnetopenstack subnet delete Deletes a subnetopenstack subnet show Shows all infomation about a subnet

 

Port

Ports connect your VMs to your network, here are some common commands:

openstack port create Create a new portopenstack port delete Deletes a portopenstack port show Shows all infomation about a port

 

Volume

Volumes are persistent storage locations, they will show up as a disk on your VM, here are some common commands:

openstack volume createCreates a new Volumeopenstack volume deleteDeletes a volumeopenstack volume showShows all infomation about a volume

 

Conclusion

Now we know some common openstack commands, and have a better overview of the system.

Step 6: Create and use our own SSH-Key

Start

In order to access our VMs via SSH we need to create an SSH keypair. If you already have a keypair, we don't need to create a new one. The only exception to this is if we the keypair we have is an ED25519 keypair,these are not usable because of a bug in OpenStack's OpenSSL.

Creation 

As mentioned in step 2, there are many ways to create an SSH keypair. In this step we will create one from the console with this command:

$ ssh-keygen -t rsa -f Beispiel.keyGenerating public/private rsa key pair.Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in Beispiel.key.Your public key has been saved in Beispiel.key.pub.The key fingerprint is:SHA256:UKSodmr6MFCO1fSqNYAoyM7uX8n/O5a43cPEV5vJXW8 The key's randomart image is:+---[RSA 2048]----+| . .o ||+. o o o ||=.+ o + ||+= o . . ..||oo+ = S . o B||o. =... o . =E||o.+ + . + . . ||.= . ...+.o ||.oo. o++o.. |+----[SHA256]-----+

The command above will generate two files, this is why we refer to it as a keypair. The two files generated are Beispiel.key (the private key) and Beispiel,key.pub (The public key).

Installation

To start using our new keypair, we need to add it to our OpenStack environment, which we'll do with the OpenStack client.

We will use the command below (in our example, the created keypair is stored in , if your keys are saved in a different location, you~/.ssh/need to copy the keypair to )~/.ssh/

$ openstack keypair create --public-key ~/.ssh/Beispiel.key.pub Beispiel+-------------+-------------------------------------------------+| Field | Value |+-------------+-------------------------------------------------+| fingerprint | ec:a6:75:f9:33:4b:e0:ba:e7:bb:b6:8a:a1:5d:48:ff || name | Beispiel || user_id | 9bf501f4c3d14b7eb0f1443efe80f656 |+-------------+-------------------------------------------------+

We can check if everything worked by listing the keys and seeing the one we just uploaded:

You should keep your private key to yourself, while we will distribute the public key to placeswhere we want access to.

$ openstack keypair list+----------+-------------------------------------------------+| Name | Fingerprint |+----------+-------------------------------------------------+| Beispiel | ec:a6:75:f9:33:4b:e0:ba:e7:bb:b6:8a:a1:5d:48:ff |+----------+-------------------------------------------------+

ConclusionNow that we have a keypair generated and uploaded the public key, we can use it to log in to our new VMs!

Step 7: The first VM

Start

In the previous steps, we've learnt everything needed to create a VM.On average, it's more useful to create VMs as part of a stack, and to create these stacks via Heat or other automation tools like Terraform.To make sure that we know the basics, this step is about creating a single VM manually.

Installation

The basic command to create a single VM is:

$ openstack server create test

If you execute this command as shown above, this error will be returned:

usage: openstack server create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--max-width <integer>] [--print-empty] [--noindent] [--prefixPREFIX] (--image <image> | --volume <volume>)--flavor <flavor> [--security-group <security-group-name>] [--key-name <key-name>] [--property <key=value>] [--file <dest-filename=source-filename>] [--user-data <user-data>] [--availability-zone <zone-name>] [--block-device-mapping <dev-name=mapping>] [--nic<net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none>] [--hint <key=value>] [--config-drive <config-drive-volume>|True] [--min <count>] [--max <count>] [--wait] <server-name>openstack server create: error: argument --flavor is required

It tells us that we have not specified what flavor our VM should be.To specify a flavor, we will need to add the flag --flavor with a flavor argument. Let's take a look at what flavours are available:

$ openstack flavor list+--------------------------------------+------------+-------+------+-----------+-------+-----------+| ID | Name | RAM | Disk |Ephemeral | VCPUs | Is Public |+--------------------------------------+------------+-------+------+-----------+-------+-----------+| 090bcc91-6207-465d-aff0-bfcc10a9e063 | m1.medium | 8192 | 20 | 0 | 4 | True || 4ade7a50-f829-4bf6-af15-266798ea8d6f | win.large | 32768 | 80 | 0 | 8 | True || 5dd72380-088e-48cd-9a18-112cb5a9cab5 | win.small | 8192 | 80 | 0 | 2 | True || 884d5b93-1467-4bc1-a445-ff7c74271cbd | m1.micro | 1024 | 20 | 0 | 1 | True || b7c4fa0b-7960-4311-a86b-507dbf58e8ac | m1.small | 4096 | 20 | 0 | 2 | True || d45e3029-8364-4e4c-beab-242e8b4622a3 | win.medium | 16384 | 80 | 0 | 4 | True || dfead62e-96a8-46e9-bdae-342ecce32d41 | win.micro | 2048 | 80 | 0 | 1 | True || ed18c320-324a-487f-88e1-3e9eb9244509 | m1.large | 16384 | 20 | 0 | 8 | True |+--------------------------------------+------------+-------+------+-----------+-------+-----------+

If we would add  to our command and execute it, it would still not work as OpenStack needs some more data before it has–flavor m1.microenough to start a new VM.Besides flavor, we need to supply the key to be installed (--key-name), the operating image to install (–image), what network the VM will run on(–network) and what security group needs to be applied to it (--security-group).

We already created a security group in a previous step, so we will need to acquire an image and a network to create our first VM.Let's take a look what images are already available:

$ openstack image list+--------------------------------------+---------------------------------------+--------+| ID | Name | Status |+--------------------------------------+---------------------------------------+--------+| fd8ad5aa-6b33-4198-a05d-8be42fc0f20e | CentOS 7 - Latest | active || 82242d21-d990-4fc2-92a5-c7bd7820e790 | Ubuntu 16.04 Xenial Xerus - Latest| active || 8e82fd42-3d6f-44a7-9f20-92f5661823cf | Windows Server 2012 R2 Std -Latest | active || 536c086c-d2a4-43dd-80ea-a9d05ee2b97f | Windows Server 2016 Std - Latest | active || c94ced87-a03e-4eec-89f7-48f2c0ec6cd2 |debian-9.1.5-20170910-openstack-amd64 | active || b1195ddf-9336-42a7-a134-4f2e7ea57710 | iNNOVO-OPNsense-17.7.8 | active || 9134b6ed-8c5a-4a9a-907e-733dc2b5f0ef | iNNOVO_pfSense 2.3.4 | active |+--------------------------------------+---------------------------------------+--------+

Next up is to select a nework, let's create a simple network with this command:

$ openstack network create BeispielNetzwerk+---------------------------+--------------------------------------+| Field | Value |+---------------------------+--------------------------------------+| admin_state_up | UP || availability_zone_hints | || availability_zones | || created_at | 2017-12-08T08:32:44Z || description | || dns_domain | None || id | a783d691-7efe-4f67-9226-99a014fa8926 || ipv4_address_scope | None || ipv6_address_scope | None || is_default | False || mtu | 1500 || name | BeispielNetzwerk || port_security_enabled | True || project_id | b15cde70d85749689e08106f973bb002 || provider:network_type | None || provider:physical_network | None || provider:segmentation_id | None || qos_policy_id | None || revision_number | 2 || router:external | Internal || segments | None || shared | False || status | ACTIVE || subnets | || updated_at | 2017-12-08T08:32:44Z |+---------------------------+--------------------------------------+

Beware that this network has no internet connection, and no additional configuration, it is not something we would use for a VM we plan toactually use. We will create a functional network in step 10.

Now to put everything together, and create an our VM. For this example, we will use the default security group, the Ubuntu 16.04 image (we'll usethe ID in the command line) and the previously created network and key:

$ openstack server create BeispielServer --flavor m1.small --key-nameBeispiel --image 82242d21-d990-4fc2-92a5-c7bd7820e790--network=BeispielNetzwerk --security-group default+-----------------------------+--------------------------------------------------------+| Field | Value |+-----------------------------+--------------------------------------------------------+| OS-DCF:diskConfig | MANUAL || OS-EXT-AZ:availability_zone | es1 || OS-EXT-STS:power_state | NOSTATE

|| OS-EXT-STS:task_state | scheduling || OS-EXT-STS:vm_state | building || OS-SRV-USG:launched_at | None || OS-SRV-USG:terminated_at | None || accessIPv4 | || accessIPv6 | || addresses | || config_drive | || created | 2017-12-06T14:15:02Z || flavor | m1.small(676d2587-b5aa-49eb-998d-d91c1bd6c056) || hostId | || id | 44ff2688-4ce5-417d-962b-3a80199bf1bc || image | cirros-tempest1(2fbe66ef-adc8-44d0-b2e2-03d95dc36936) || key_name | cg || name | BeispielServer || progress | 0 || project_id | 1e775e2cc71a461991be42d4fad8a5cb || properties | || security_groups | name='3265503b-ac24-4f60-a8d0-466b7c812916'|| status | BUILD || updated | 2017-12-06T14:15:02Z || user_id | b54fda3f4d1a484797b3ad4de9b3f4f9 || volumes_attached |

|+-----------------------------+--------------------------------------------------------+

To see all the possible parameters during the creation of a VM, we can use "–help":

$ openstack server create --helpusage: openstack server create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--max-width <integer>] [--print-empty] [--noindent] [--prefixPREFIX] (--image <image> | --volume <volume>)--flavor <flavor> [--security-group <security-group-name>] [--key-name <key-name>] [--property <key=value>] [--file <dest-filename=source-filename>] [--user-data <user-data>] [--availability-zone <zone-name>] [--block-device-mapping <dev-name=mapping>] [--nic<net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none>] [--hint <key=value>] [--config-drive <config-drive-volume>|True] [--min <count>] [--max <count>] [--wait] <server-name>

Create a new server

positional arguments: <server-name> New server name

optional arguments: -h, --help show this help message and exit --image <image> Create server boot disk from this image (name orID) --volume <volume> Create server using this volume as the boot disk(name or ID) --flavor <flavor> Create server with this flavor (name or ID) --security-group <security-group-name> Security group to assign to this server (name orID) (repeat option to set multiple groups) --key-name <key-name> Keypair to inject into this server (optional extension) --property <key=value>

Set a property on this server (repeat option to set multiple values) --file <dest-filename=source-filename> File to inject into image before boot (repeatoption to set multiple files) --user-data <user-data> User data file to serve from the metadata server --availability-zone <zone-name> Select an availability zone for the server --block-device-mapping <dev-name=mapping> Map block devices; map is <id>:<type>:<size(GB)>:<delete_on_terminate>(optional extension) --nic<net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none> Create a NIC on the server. Specify option multiple times to create multiple NICs. Either net-id orport- id must be provided, but not both. net-id: attachNIC to network with this UUID, port-id: attach NIC toport with this UUID, v4-fixed-ip: IPv4 fixed address for NIC (optional), v6-fixed-ip: IPv6 fixed address for NIC (optional), none: (v2.37+) no network isattached, auto: (v2.37+) the compute service willautomatically allocate a network. Specifying a --nic of auto ornone cannot be used with any other --nic value. --hint <key=value> Hints for the scheduler (optional extension) --config-drive <config-drive-volume>|True Use specified volume as the config drive, or 'True'to use an ephemeral drive --min <count> Minimum number of servers to launch (default=1) --max <count> Maximum number of servers to launch (default=1) --wait Wait for build to complete

output formatters: output formatter options

-f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} the output format, defaults to table -c COLUMN, --column COLUMN specify the column(s) to include, can be repeated

table formatter: --max-width <integer>

Maximum display width, <1 to disable. You can alsouse the CLIFF_MAX_TERM_WIDTH environment variable, butthe parameter takes precedence. --print-empty Print empty table if there is no data to show.

json formatter: --noindent whether to disable indenting the JSON

shell formatter:

a format a UNIX shell can parse (variable="value")

--prefix PREFIX add a prefix to all variable names

ConclusionWe have now created our first VM! Of course, it doesn't do anything and we can't even reach it but we'll get to that in later steps.

Step 8: Delete the first VM

Preface

Previously, we created a VM, in this step, we will delete it so that we can reuse its resources.

Start

First of all, we need to acquire the name or the ID of the VM.If we only have few VMs, we can use the name but as names aren't unique, it's strongly recommended that we use the ID.

Let's get a list of all our VMs:

$ openstack server list+--------------------------------------+--------------+--------+---------------------------------------------------+------------------------------------+| ID | Name | Status | Networks | Image Name |+--------------------------------------+--------------+--------+---------------------------------------------------+------------------------------------+| 801b3021-0c00-4566-881e-b50d47152e63 | singleserver | ACTIVE |single_internal_network=10.0.0.12, 185.116.245.39 | Ubuntu 16.04 XenialXerus - Latest |+--------------------------------------+--------------+--------+---------------------------------------------------+------------------------------------+

This returns a list of all our VMs, the ID is in the column "ID" and the name is in the column "Name".Now that we have this information, let's delete it:

$ openstack server delete 801b3021-0c00-4566-881e-b50d47152e63

If we ask for a new list of our VMs, it should return nothing at all:

$ openstack server list

$

ConclusionWe've now learnt how to delete VMs!

Step 9: A Security Group

Start

For security reasons, any incoming traffic to a VM is denied.To be able to access a VM, we need to assign it at least one security group.While it is possible to add all access rules into a single security group, it's advisable to use a separate security group per service.

How-to 

The base command for creating security groups is for example:openstack security group create

openstack security group create allow-ssh-from-anywhere --descriptionBeispiel+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+| Field | Value |+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+| created_at | 2017-12-08T12:01:42Z || description | Beispiel || id | 1cab4a62-0fda-40d9-bac8-fd73275b472d || name | allow-ssh-from-anywhere || project_id | b15cde70d85749689e08106f973bb002 || revision_number | 2 || rules | created_at='2017-12-08T12:01:42Z', direction='egress',ethertype='IPv6', id='5a852e4b-1d79-4fe9-b359-64ca54c98501', || | updated_at='2017-12-08T12:01:42Z' || | created_at='2017-12-08T12:01:42Z', direction='egress',ethertype='IPv4', id='fa90a1ee-d3b9-40d4-9bb5-89fdd5005c02', || | updated_at='2017-12-08T12:01:42Z' || updated_at | 2017-12-08T12:01:42Z |+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+

Now that we've created an empty security group, we're going to add some rules.Some commonly used options are:

--protocol: The protocol that this rule matches. (Example arguments: tcp, udp, icmp)--dst-port: Destination port range to give access to. (Example arguments: 22:22 for port 22 100:200 for ports 100 through 200).--remote-ip: Remote IP to allow access from. (Example arguments: 0.0.0.0/0 for all IP addresses, 1.2.3.0/24 for all IP addressesstarting with 1.2.3.).--ingress or ingress is incoming traffic and egress is outgoing traffic (No arguments possible)--egress:

We're going to use these options to create a rule for our new seurity group to actually allow SSH from anywhere:

$ openstack security group rule create allow-ssh-from-anywhere --protocoltcp --dst-port 22:22 --remote-ip 0.0.0.0/0+-------------------+--------------------------------------+| Field | Value |+-------------------+--------------------------------------+| created_at | 2017-12-08T12:02:15Z || description | || direction | ingress || ether_type | IPv4 || id | 694a0573-b4c3-423c-847d-550f79e83f2b || name | None || port_range_max | 22 || port_range_min | 22 || project_id | b15cde70d85749689e08106f973bb002 || protocol | tcp || remote_group_id | None || remote_ip_prefix | 0.0.0.0/0 || revision_number | 0 || security_group_id | 1cab4a62-0fda-40d9-bac8-fd73275b472d || updated_at | 2017-12-08T12:02:15Z |+-------------------+--------------------------------------+

Next, we verify if our security group was created correctly:

$ openstack security group show allow-ssh-from-anywhere+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+| Field | Value |+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+| created_at | 2017-12-08T12:01:42Z || description | Beispiel || id | 1cab4a62-0fda-40d9-bac8-fd73275b472d || name | allow-ssh-from-anywhere || project_id | b15cde70d85749689e08106f973bb002 || revision_number | 3 || rules | created_at='2017-12-08T12:01:42Z', direction='egress',ethertype='IPv6', id='5a852e4b-1d79-4fe9-b359-64ca54c98501', || | updated_at='2017-12-08T12:01:42Z' || | created_at='2017-12-08T12:02:15Z', direction='ingress',ethertype='IPv4', id='694a0573-b4c3-423c-847d-550f79e83f2b',port_range_max='22', || | port_range_min='22', protocol='tcp',remote_ip_prefix='0.0.0.0/0', updated_at='2017-12-08T12:02:15Z' || | created_at='2017-12-08T12:01:42Z', direction='egress',ethertype='IPv4', id='fa90a1ee-d3b9-40d4-9bb5-89fdd5005c02', || | updated_at='2017-12-08T12:01:42Z' || updated_at | 2017-12-08T12:02:15Z |+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+

Conclusion

We've now created a security group that allows SSH access from anywhere!

Step 10: Getting access to the Internet: Creating a network

Start

So far, we've created a VM and a security group.Our next step is to create a network.

The networkWe'll start with the network. As with previous commands, we have additional options that we can list with .--helpLet's create our network:

$ openstack network create BeispielNetzwerk+---------------------------+--------------------------------------+| Field | Value |+---------------------------+--------------------------------------+| admin_state_up | UP || availability_zone_hints | || availability_zones | || created_at | 2017-12-08T12:06:38Z || description | || dns_domain | None || id | ff6d8654-66d6-4881-9528-2686bddcb6dc || ipv4_address_scope | None || ipv6_address_scope | None || is_default | False || mtu | 1500 || name | BeispielNetzwerk || port_security_enabled | True || project_id | b15cde70d85749689e08106f973bb002 || provider:network_type | None || provider:physical_network | None || provider:segmentation_id | None || qos_policy_id | None || revision_number | 2 || router:external | Internal || segments | None || shared | False || status | ACTIVE || subnets | || updated_at | 2017-12-08T12:06:38Z |+---------------------------+--------------------------------------+

Subnet

Now that we have a network, we'll have to create a subnet for it. The subnet creation command also has a few options, in our example we'll use:

--network: Specifies in which network the subnet will be created-- -rangesubet : range for the subnet. In our example it will be  The CIDR 192.0.2.0/24

To create a subnet in our existing network we run:

$ openstack subnet create BeispielSubnet --network BeispielNetzwerk--subnet-range 192.0.2.0/24+-------------------------+--------------------------------------+| Field | Value |+-------------------------+--------------------------------------+| allocation_pools | 192.0.2.2-192.0.2.254 || cidr | 192.0.2.0/24 || created_at | 2017-12-08T12:09:07Z || description | || dns_nameservers | || enable_dhcp | True || gateway_ip | 192.0.2.1 || host_routes | || id | 984b24bf-db60-46a9-83c3-d68f6f1062e4 || ip_version | 4 || ipv6_address_mode | None || ipv6_ra_mode | None || name | BeispielSubnet || network_id | ff6d8654-66d6-4881-9528-2686bddcb6dc || project_id | b15cde70d85749689e08106f973bb002 || revision_number | 0 || segment_id | None || service_types | || subnetpool_id | None || updated_at | 2017-12-08T12:09:07Z || use_default_subnet_pool | None |+-------------------------+--------------------------------------+

RouterFor our virtual network to be able to reach the internet, we'll have to create a router:

$ openstack router create BeispielRouter+-------------------------+--------------------------------------+| Field | Value |+-------------------------+--------------------------------------+| admin_state_up | UP || availability_zone_hints | || availability_zones | || created_at | 2017-12-08T12:09:49Z || description | || distributed | False || external_gateway_info | None || flavor_id | None || ha | False || id | bfb91c7f-acca-450a-aae0-c519ab563d38 || name | BeispielRouter || project_id | b15cde70d85749689e08106f973bb002 || revision_number | None || routes | || status | ACTIVE || updated_at | 2017-12-08T12:09:49Z |+-------------------------+--------------------------------------+

We need to define the external gateway to be able to access the internet:

$ openstack router set BeispielRouter --external-gateway provider

Now we'll add the subnet to the router:

$ openstack router add subnet BeispielRouter BeispielSubnet

Port

Now that we have our subnet and router, we need to create a port for the network. We can associate the port using the  option:–network

$ openstack port create BeispielPort --network BeispielNetzwerk+-----------------------+--------------------------------------------------------------------------+| Field | Value |+-----------------------+--------------------------------------------------------------------------+| admin_state_up | UP || allowed_address_pairs | || binding_host_id | None |

| binding_profile | None || binding_vif_details | None || binding_vif_type | None || binding_vnic_type | normal || created_at | 2017-12-08T12:12:13Z || description | || device_id | || device_owner | || dns_assignment | None || dns_name | None || extra_dhcp_opts | || fixed_ips | ip_address='192.0.2.8',subnet_id='984b24bf-db60-46a9-83c3-d68f6f1062e4' || id | 31777c0a-a952-43ca-bb7f-11ad33926dae || ip_address | None || mac_address | fa:16:3e:09:88:c8 || name | BeispielPort || network_id | ff6d8654-66d6-4881-9528-2686bddcb6dc || option_name | None || option_value | None || port_security_enabled | True || project_id | b15cde70d85749689e08106f973bb002 || qos_policy_id | None || revision_number | 3 || security_group_ids | 3d3e3074-3087-4965-9a64-34a6d56193b9 || status | DOWN || subnet_id | None || updated_at | 2017-12-08T12:12:13Z

|+-----------------------+--------------------------------------------------------------------------+

ConclusionWe've now created our virtual network infrastructure!

Step 11: Prepare access to the internet: Add IPv6 to our network

Start

Now that we have our working network, we will enable IPv6 to our setup. We don't have to create a new router, as we'll be using our existing one.The cloud images we supply have a predefined primary network interface with with enabled and once we finished this step, IPv6 will workDHCPas well.

Subnet

We already have an IPv6 pool defined, we will use this to create a new subnet.Let's list all existing pools:

$ openstack subnet pool list+--------------------------------------+---------------+---------------------+| ID | Name | Prefixes |+--------------------------------------+---------------+---------------------+| f541f3b6-af22-435a-9cbb-b233d12e74f4 | customer-ipv6 |2a00:c320:1000::/48 |+--------------------------------------+---------------+---------------------+

We can now use the pool to generate a subnet, it will automatically force us to use a prefix length of 64 bits.You can use the subnet in the creation process, or you can accept the default from OpenStack.Let's create our subnet now:

$ openstack subnet create --network BeispielNetzwerk --ip-version 6--use-default-subnet-pool --ipv6-address-mode dhcpv6-stateful--ipv6-ra-mode dhcpv6-stateful BeispielSubnetIPv6+-------------------------+----------------------------------------------------------+| Field | Value |+-------------------------+----------------------------------------------------------+| allocation_pools |2a00:c320:1000:2::2-2a00:c320:1000:2:ffff:ffff:ffff:ffff || cidr | 2a00:c320:1000:2::/64 || created_at | 2017-12-08T12:41:42Z

|| description | || dns_nameservers | || enable_dhcp | True || gateway_ip | 2a00:c320:1000:2::1 || host_routes | || id | 0046c29b-a9b0-47c3-b5dd-704aa801704d || ip_version | 6 || ipv6_address_mode | dhcpv6-stateful || ipv6_ra_mode | dhcpv6-stateful || name | BeispielSubnetIPv6 || network_id | ff6d8654-66d6-4881-9528-2686bddcb6dc || project_id | b15cde70d85749689e08106f973bb002 || revision_number | 0 || segment_id | None || service_types | || subnetpool_id | f541f3b6-af22-435a-9cbb-b233d12e74f4 || updated_at | 2017-12-08T12:41:42Z || use_default_subnet_pool | True

|+-------------------------+----------------------------------------------------------+

Router

Now that the subnet has been created, we'll add it to the router.We'll do so by executing this command:

$ openstack router add subnet BeispielRouter BeispielSubnetIPv6

Security Group

The security group rules that we've created in step 9 were IPv4 rules, so now we'll have to add two more rules for IPv6.

First, we'll allow SSH access via IPv6 (::/0 is the equivalent of 0.0.0.0/0 but for IPv6):

$ openstack security group rule create --remote-ip "::/0" --protocol tcp--dst-port 22:22 --ethertype IPv6 --ingress allow-ssh-from-anywhere+-------------------+--------------------------------------+| Field | Value |+-------------------+--------------------------------------+| created_at | 2017-12-08T12:44:04Z || description | || direction | ingress || ether_type | IPv6 || id | 7d871e85-05fa-4620-b558-c6fc64076cde || name | None || port_range_max | 22 || port_range_min | 22 || project_id | b15cde70d85749689e08106f973bb002 || protocol | tcp || remote_group_id | None || remote_ip_prefix | ::/0 || revision_number | 0 || security_group_id | 1cab4a62-0fda-40d9-bac8-fd73275b472d || updated_at | 2017-12-08T12:44:04Z |+-------------------+--------------------------------------+

And, just for completion's sake, we'll allow ICMP access so that we can ping our VM via IPv6:

$ openstack security group rule create --remote-ip "::/0" --protocolipv6-icmp --ingress allow-ssh-from-anywhere+-------------------+--------------------------------------+| Field | Value |+-------------------+--------------------------------------+| created_at | 2017-12-08T12:44:44Z || description | || direction | ingress || ether_type | IPv6 || id | f63e4787-9965-4732-b9d2-20ce0fedc974 || name | None || port_range_max | None || port_range_min | None || project_id | b15cde70d85749689e08106f973bb002 || protocol | ipv6-icmp || remote_group_id | None || remote_ip_prefix | ::/0 || revision_number | 0 || security_group_id | 1cab4a62-0fda-40d9-bac8-fd73275b472d || updated_at | 2017-12-08T12:44:44Z |+-------------------+--------------------------------------+

Adjustments to the operating system

Any new VM based on our images will now have both IPv4 and IPv6 configured, and our provided heat templates will also enable IPv6.Many standard vendor images will not have IPv6 configured, this means that they'll only have IPv4 enabled by default.If we want to enable IPv6 on a VM where it's not enabled, we can follow the instructions below.

Ubuntu 16.04

To properly enable IPv6, we'll have to create the following files with the specified content.

/etc/dhcp/dhclient6.conf

timeout 30;

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

network: {config: disabled}

/etc/network/interfaces.d/lo.cfg

auto loiface lo inet loopback

/etc/network/interfaces.d/ens3.cfg

iface ens3 inet6 auto up sleep 5 up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf/var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true

Now that we've created the files, we'll reenable the interface:

sudo ifdown ens3 && sudo ifup ens3

Once this is completed, we'll have working IPv4 and IPv6 addresses.

If we want to automate the actions above, we can add this to the part of our heat template (We'll go over cloud-init in step 19):cloud-init

#cloud-configwrite_files: - path: /etc/dhcp/dhclient6.conf content: "timeout 30;" - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg content: "network: {config: disabled}" - path: /etc/network/interfaces.d/lo.cfg content: | auto lo iface lo inet loopback - path: /etc/network/interfaces.d/ens3.cfg content: | iface ens3 inet6 auto up sleep 5 up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf/var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true

runcmd: - [ ifdown, ens3] - [ ifup, ens3]

CentOS 7

To properly enable IPv6, we'll have to create the following files with the specified content.

/etc/sysconfig/network

NETWORKING_IPV6=yes

/etc/sysconfig/network-scripts/ifcfg-eth0

IPV6INIT=yesDHCPV6C=yes

Now that we've created the files, we'll reenable the interface:

sudo ifdown eth0 && sudo ifup eth0

Once this is completed, we'll have working IPv4 and IPv6 addresses.

If we want to automate the actions above, we can add this to the part of our heat template (We'll go over cloud-init in step 19):cloud-init

#cloud-configwrite_files: - path: /etc/sysconfig/network owner: root:root permissions: '0644' content: | NETWORKING=yes NOZEROCONF=yes NETWORKING_IPV6=yes - path: /etc/sysconfig/network-scripts/ifcfg-eth0 owner: root:root permissions: '0644' content: | DEVICE="eth0" BOOTPROTO="dhcp" ONBOOT="yes" TYPE="Ethernet" USERCTL="yes" PEERDNS="yes" PERSISTENT_DHCLIENT="1" IPV6INIT=yes DHCPV6C=yesruncmd: - [ ifdown, eth0] - [ ifup, eth0]

External access

Important: Now that we've enabled IPv6 on the VM, it's reachable from the rest of the world on its IPv6 address on the ports that we've allowed inthe security group.Unlike IPv4, we don't need to assign a floating IP address to be able to reach the VM.If we want to be able to reach the VM via IPv4, we'll have to assign a floating IP address. 

If you want to test the IPv6 reachability but don't have access to a machine with IPv6, you can use some web based tools like https://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php

Conlusion

Now we've enabled IPv6 next to IPv4!

Step 12: A usable VM

Start

Even though we already created a VM in step 7, that VM was not usable as it wasn't connected to a network, let alone the internet. Let's createone that we can actually log i to.

Installation 

To create this VM, we'll add some parameters to the command we used in step 7:

$ openstack server create BeispielInstanz --flavor m1.small --key-nameBeispiel --image "Ubuntu 16.04 Xenial Xerus - Latest" --security-groupallow-ssh-from-anywhere --network=BeispielNetzwerk+-----------------------------+---------------------------------------------------------------------------+| Field | Value |+-----------------------------+---------------------------------------------------------------------------+| OS-DCF:diskConfig | MANUAL || OS-EXT-AZ:availability_zone | es1 || OS-EXT-STS:power_state | NOSTATE || OS-EXT-STS:task_state | scheduling || OS-EXT-STS:vm_state | building || OS-SRV-USG:launched_at | None || OS-SRV-USG:terminated_at | None || accessIPv4 | || accessIPv6 | || addresses | || config_drive | || created | 2017-12-08T12:52:37Z || flavor | m1.small(b7c4fa0b-7960-4311-a86b-507dbf58e8ac) || hostId | || id | 1de98aa4-7d2b-4427-a8a5-d369ea8bdaf5 || image | Ubuntu 16.04 Xenial Xerus - Latest(82242d21-d990-4fc2-92a5-c7bd7820e790) || key_name | Beispiel |

| name | BeispielInstanz || progress | 0 || project_id | b15cde70d85749689e08106f973bb002 || properties | || security_groups | name='allow-ssh-from-anywhere' || status | BUILD || updated | 2017-12-08T12:52:37Z || user_id | 9bf501f4c3d14b7eb0f1443efe80f656 || volumes_attached |

|+-----------------------------+---------------------------------------------------------------------------+

These parameters are included:

--flavor: The flavor of the the VM. You can get all available flavors with " "openstack flavor list--key-name: The key to install on the VM.--image: The operating system image to install on the VM. You can get all available images with " "openstack image list--security-group: Specifies the security group.--network: Specify the network to attach the VM to.

If we want to reach our VM from the internet, we'll nee a floating IP address. Let's create one: 

$ openstack floating ip create provider+---------------------+--------------------------------------+| Field | Value |+---------------------+--------------------------------------+| created_at | 2017-12-08T12:53:37Z || description | || fixed_ip_address | None || floating_ip_address | 185.116.245.65 || floating_network_id | 54258498-a513-47da-9369-1a644e4be692 || id | 84eca140-9ac1-42c3-baf6-860ba920a23c || name | None || port_id | None || project_id | b15cde70d85749689e08106f973bb002 || revision_number | 0 || router_id | None || status | DOWN || updated_at | 2017-12-08T12:53:37Z |+---------------------+--------------------------------------+

The created IP must be associated with our vm: 

$ openstack server add floating ip BeispielInstanz 185.116.245.145

UsageWe now should have a reachable VM. To see if all worked correctly, let's try to log in to our VM via SSH.

: We can only log in if the specified ssh key exists and is accessible. (If this doesn't work, follow the guide in step 6)IMPORTANT

$ ssh ubuntu@185.116.245.145The authenticity of host '185.116.245.145 (185.116.245.145)' can't beestablished.ECDSA key fingerprint is SHA256:kbSkm8eJA0748911RkbWK2/pBVQOjJBASD1oOOXalk.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '185.116.245.145' (ECDSA) to the list of knownhosts.Enter passphrase for key '/Users/ubuntu/.ssh/id_rsa':

Clean-Up

If we want to delete all the parts we just created, we'll have to delete them in a logical order.If we don't delete them in the order, we will not be allowed to delete components that other components depend on.

Instanceopenstack server delete BeispielInstanz

Floating-IPopenstack floating ip delete 185.116.245.145

Router Portopenstack port delete BeispielPort

Router openstack router delete BeispielRouter

Subnetopenstack subnet delete BeispielSubnet

Networkopenstack network delete BeispielNetzwerk

Conclusion

We have now created a VM based on all the parts we created before, it's reachable from the internet and we've logged in via SSH!

Step 13: The structured way to create an instance (with stacks)

Start

Previously, we reated a VM, a security group and a virtual network separately.Now we will demonstrate a way to create all these in an integrated way so that we can create an entire setup at once. This requires python-heatcli

to be installed, which we've already done in step 4.ent

Installation 

Instead of creating a VM separately, we can create one and all its dependencies via a stack. This makes it easy to compose an entire set up, which we can then easily create and delete at will.In this step, we will use a pre-made heat template and we'll learn how to write one for ourselves in the next few steps.

All the things that we created in step 9 through 11 are easily expressed in a single template.But let's start with an example template.

This template will create a stack that includes a vm, two security groups, a virtual network (including router, port and subnet) and a floating-IP.

When we create the stack, it's important that we're in the same directory as the template:

$ openstack stack create -t SingleServer.yaml --parameter key_name=BeispielSingleServer --wait2017-12-08 13:13:43Z [SingleServer]: CREATE_IN_PROGRESS Stack CREATEstarted2017-12-08 13:13:44Z [SingleServer.router]: CREATE_IN_PROGRESS statechanged2017-12-08 13:13:45Z [SingleServer.enable_traffic]: CREATE_IN_PROGRESS state changed2017-12-08 13:13:45Z [SingleServer.enable_traffic]: CREATE_COMPLETE statechanged2017-12-08 13:13:46Z [SingleServer.internal_network_id]: CREATE_IN_PROGRESSstate changed2017-12-08 13:13:46Z [SingleServer.router]: CREATE_COMPLETE state changed2017-12-08 13:13:46Z [SingleServer.internal_network_id]: CREATE_COMPLETE state changed2017-12-08 13:13:47Z [SingleServer.enable_ssh]: CREATE_IN_PROGRESS statechanged2017-12-08 13:13:47Z [SingleServer.subnet]: CREATE_IN_PROGRESS statechanged2017-12-08 13:13:47Z [SingleServer.enable_ssh]: CREATE_COMPLETE statechanged2017-12-08 13:13:48Z [SingleServer.start-config]: CREATE_IN_PROGRESS statechanged2017-12-08 13:13:48Z [SingleServer.subnet]: CREATE_COMPLETE state changed2017-12-08 13:13:49Z [SingleServer.router_subnet_bridge]:CREATE_IN_PROGRESS state changed2017-12-08 13:13:49Z [SingleServer.port]: CREATE_IN_PROGRESS state changed2017-12-08 13:13:50Z [SingleServer.start-config]: CREATE_COMPLETE statechanged2017-12-08 13:13:50Z [SingleServer.port]: CREATE_COMPLETE state changed2017-12-08 13:13:50Z [SingleServer.host]: CREATE_IN_PROGRESS state changed2017-12-08 13:13:52Z [SingleServer.router_subnet_bridge]: CREATE_COMPLETE state changed2017-12-08 13:13:53Z [SingleServer.floating_ip]: CREATE_IN_PROGRESS statechanged2017-12-08 13:13:55Z [SingleServer.floating_ip]: CREATE_COMPLETE statechanged2017-12-08 13:14:05Z [SingleServer.host]: CREATE_COMPLETE state changed2017-12-08 13:14:06Z [SingleServer]: CREATE_COMPLETE Stack CREATEcompleted successfully+---------------------+-------------------------------------------------+| Field | Value |+---------------------+-------------------------------------------------+| id | 0f5cdf0e-24cc-4292-a0bc-adf2e9f8618a || stack_name | SingleServer || description | A simple template to deploy your first instance || creation_time | 2017-12-08T13:13:42Z || updated_time | None || stack_status | CREATE_COMPLETE || stack_status_reason | Stack CREATE completed successfully |+---------------------+-------------------------------------------------+

Here's a short explanation of the command we just executed:

openstack stack create will create the stack, according to the template defined with -t SingleServer.yaml

We set the parameter key_name with  to fill the  parameter with BEISPIEL. In this template that will–parameter key_name=BEISPIEL key_nameinstall our BEISPIEL key into our VM. We also name our stack .SingleServerFinally, we use the option to wait and see the creation process, if we didn't add this option, the command would complete immediately while--waitthe creation process would continue in the background.

Once the command has completed, we should be able to connect to our VM. First, we acquire the floating IP of the VM:

$ openstack stack output show 0f5cdf0e-24cc-4292-a0bc-adf2e9f8618ainstance_fip+--------------+---------------------------------+| Field | Value |+--------------+---------------------------------+| description | External IP address of instance || output_key | instance_fip || output_value | 185.116.245.70 |+--------------+---------------------------------+

Now we can log in to our VM:

$ ssh ubuntu@185.116.245.70The authenticity of host '185.116.245.70 (185.116.245.70)' can't beestablished.ECDSA key fingerprint is SHA256:kbSkm8eJA0748911RkbWK2/pBVQOjJBASD1oOOXalk.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '185.116.245.70' (ECDSA) to the list of knownhosts.Enter passphrase for key '/Users/ubuntu/.ssh/id_rsa':

Conclusion

Using a heat stack, we've recreated steps 9 through 12 in a single command!

Step 14: Our first steps with HEAT

Start

Previously, we used a pre-made heat template, now we'll take a look at how a heat template works.

The templateEvery heat template follows this structure:

heat_template_version:  description: # The template description parameter_groups: # Group definitions and their order parameters: # Parameter definitions resources: # Resource definitions  outputs: # Definitions of possible outputs conditions: # Definitions of conditions

Heat Template Version

The template version follows a strict pattern and defines what commands are available to use. We can use these versions, although it's recommended to use the latest one:

2013-05-232014-10-162015-04-302015-10-152016-04-082016-10-142017-02-24

Description

The description is an optional section that describes the stack. You can put anything you want here.We recommend adding a description with how to use the template, what it's meant to create and anything else that's not obvious. This makes iteasier to share with others and could even remind you what the template does in case you've not used it for a while. You can also add comments by starting them with the character, this can be used to temporarily disable lines or to add more documentation to#the template.

Parameter GroupsIn this section you can specify the parameters, how they should group and the order of them.The groups are divided into a list, which contains single parameters.Every parameter should only have one group because of possible errors later and the structure looks like this:

parameter_groups: - label: <name of the group> description: <description of the group> parameters: - <name of the parameter> - <name of the parameter>

label: name of the groupdescription: Gives us the possibility to describe the groupparameter: A list of all parameters in this groupname of the parameter: the name of the parameter which we had defined in the parameter section

Parameter

In this section we can specify parameters which our template requires.Parameters are usually used to make it easy to change certain parts of the template. (Like what SSH key is used.)

Each parameter will be seperately defined, starting with the name, with the attributes defined underneath:

 parameters: <Parameter Name>: type: <string | number | json | comma_delimited_list | boolean> label: <Name of the parameter> description: <description of the parameter> default: <default of the parameter> hidden: <true | false> constraints: <constraints for the parameter> immutable: <true | false>

Parameter Name: Name of the parametertype: The type of the parameter (string, number, json, comma_delimited_list, boolean)label: Name of the parameter (optional)description: The description of ther parameter (optional)default: Default value of the parameter. Will be used, if the parameter isn't defined (optional)hidden:  If the parameter should be hidden in the creation process, you can set hidden: true as parameter (Optional and set to byfalse default)constraints: You can set a list of constraints. If these aren't fulfilled, the stack creation will fail. immutable: If this parameter is set to true, the parameter can't be changed with a stack update. (This will raise an error if attempted)

Resources

This block specifies the resources that will be created, with every resource in its own sub block:

resources: <ID of the resource>: type: <resource type> properties: <name of the property>: <value of the property> metadata: <specific metatdata> depends_on: <Resource ID or a list of resources> update_policy: <update rule> deletion_policy: <deletion rule> external_id: <external resource id> condition: <condition name>

ID of the resource: Must be uniquetype: type of a resource, for example: OS::NEUTRON::SecurityGroup (for a security group) (required)properties: A list of properties for resources (optional) metadata: Metadata belonging to the resource  (optional)depends_on: resources that the resource depends on (optional)update_policy: We can specify rules for updates, if needed and possible (optional)

deletion_policy: Specifies rules for the deletion. The options are Delete, Retain and Snapshot. With heat_template_version 2016-10-14You can also write these in lower case.external_id: We can use external IDs if needed.condition: We can set specific conditions for this resource to be created. (Optional)

Output

With the output block, we can specify which parameters should be shown after creation.Examples of these could be the IP address of a VM or the URL of a deployed web application.Outputs are specified in sub blocks like this:

outputs: <name of the output>: description: <description> value: <value of the output> condition: <name of the condition>

name of the output: Must be uniquedescription: If needed, you can describe the output (optional)value: Value of the output (needed)condition: possible conditions (optional)

Condition

Like other sections, conditions can also be specified in a block. You can set conditions, and if they aren't fulfilled, the stack creation will fail.

conditions: <name of condition 1>: {term1} <name of condition 2>: {term2}

name of condition: must be uniqueterm: true or false are expected as a result

Conclusion 

We have learned the basic structure of a heat template and can now start creating our own!

Step 15: The first heat template

Start

In the previous step, we've learnt the basic layout of a heat template, now we're going to put that knowledge to use.

The first template

As we've mentioned earlier, our templates needs to start with a version definition.In this example, we'll use as our version. We mentioned other versions in the previous step. 2016-10-14Our template now contains this:

heat_template_version: 2016-10-14

 Even though it's optional, it's best practice to add a description to our templates.

heat_template_version: 2016-10-14 description: A simple template to deploy a vm

Next up, we're going to add the resource "Instanz".Be sure to pay close attention to the structure of our template and to indent the " " under .Instanz resourcesTo indent, use 4 spaces and take care not to use tab, if you use tabs or an inconsistent amount of spaces, it will cause hard to find errors.The state of our template should look like this:

heat_template_version: 2016-10-14

description: A simple template to deploy a vm

resources: Instanz:

Next, we'll define the type of the resource.A detailed list of all types can be found in the  .official OpenStack documentationIn our example, we'll define as a VM:Instanz

heat_template_version: 2016-10-14 description: A simple template to deploy a vm

resources: Instanz: type: OS::Nova::Server

Now that we've defined the type, we'll define its properties.Let's define the key,  image and the flavor:

heat_template_version: 2016-10-14

description: A simple template to deploy a vm

resources: Instanz: type: OS::Nova::Server properties: key_name: BeispielKey image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small

Conclusion

We've now defined a template that creates a single VM instance, if you want, you could run it like we did previously.

Step 16: Let's get to know HEAT better

Start

At first glance, it might look like that creating a VM via a heat template and directly via the OpenStack client take the same time, while this is true ifyou only want to create the VM once, this is true but the real advantage to heat is in reusing templates.Now that we have our simple template, we'll get to know heat a bit better by adding a variable parameter to our template.

Parameter

In this example, we'll add a parameter for the SSH key. The advantage of this is that we can use a VM with different keys without changing ourtemplate.We need to define the parameter and also define its type, the proper type for what we want to accomplish is " ":string

heat_template_version: 2014-10-16 parameters: key_name: type: string

 

Now that we've defined our first parameter, we'll add the same resource to our template like this:

heat_template_version: 2014-10-16

parameters: key_name: type: string

resources: Instanz: type: OS::Nova::Server properties: key_name: Beispiel image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small

Now we'll actually use our parameter, we'll replace with our parameter.BeispielThis is done with the get_param syntax (for getting the parameter). The template is now ready to use and we can define the key_name from the command line like in our previous command line:

heat_template_version: 2014-10-16

parameters: key_name: type: string

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small

Conclusion

We've now added a variable parameter to our template!

Step 17: The network in Heat

Preface

Now that we have a simple template with a parameter, we'll add the network .

The template

We'll continue using the template we previously created.First, we'll add a new parameter, the id of the external network and name it we'll also define a default :public_network_id, provider

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small

Network

Next, we'll add the network.Like the Vm, the network is a resource, so we'll add it to that block. The type for network resources is OS::Neutron::Net

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk

The portNow that we've defined a network we can add the port, which is a resource with type .OS::Neutron::PortTo make sure that sure that this port is used by our VM, we add the property to it and define a property that then uses the networks port get_reso

function to link it to the .urce PortFurthermore, we want to link the port to the network by adding a  property that also uses the function to link it to the network get_resource Netzwer.k

By now, our template will look like this:

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk  Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk }

The router

Our network will need a router, so now we'll add a resource, with the type Router . OS::Neutron::RouterWe will use our parameter to define the external network it will use:

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk

Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk }  Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param: public_network_id } name: BeispielRouter

The subnet

Now we want to define a subnet for our network, this is the resource with type Subnet OS::Neutron::Subnet.It's in the subnet that we'll define IP information like nameserver(s), the IP version, the IP range and other IP related settings:

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk

Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk }

Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param: public_network_id } name: BeispielRouter  Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 }

Subnet bridge

Finally, we'll define a subnet bridge with the type , this will associate the subnet and the router so that VMsOS::Neutron::RouterInterfacein that subnet will use the router.We wil also define the property, which makes sure that the subnet bridge will only be created if is available:depends_on Subnet

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk

Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk }

Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param: public_network_id } name: BeispielRouter

Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 }  Router_Subnet_Bridge:

type: OS::Neutron::RouterInterface depends_on: Subnet

properties: router: { get_resource: Router } subnet: { get_resource: Subnet }

Conclusion

We have now defined the full network, if this stack is now created, it will create a VM and all the components needed to give it connectivity.

Step 18: Our vm will be reachable via IPv4

Start

Now that our template defines the full network and can reach the internet, we'll have to make it possible to reach the VM from the internet.

Floating-IP 

We'll define a floating public IPv4 address, which is a resource with type OS::Neutron::FloatingIPPlease note that it's important to define the external network that this IP will be assigned from and the port that this IP will lead to:

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk } Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param:

public_network_id } name: BeispielRouter Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 } Router_Subnet_Bridge: type: OS::Neutron::RouterInterface depends_on: Subnet properties: router: { get_resource: Router } subnet: { get_resource: Subnet }  Floating_IP: type: OS::Neutron::FloatingIP

properties: floating_network: { get_param: public_network_id } port_id: { get_resource: Port }

Security-groups

If we would create a stack as defined above, the Vm would start but it wouldn't be reachable. As we've mentioned before, VMs will not receivetraffic without a security group explicitly allowing it.So, of course, the logical next step is to create a resource with type . OS::Neutron::SecurityGroupWe'll have to define the security group to use on the and in the resource itself, we'll specify the rules themselves. These rules will consist ofPortthe direction, port range, remote IP prefix and protool that these rules want to allow.

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port } Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk } security_groups: { get_resource: Sec_SSH } Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param:public_network_id } name: BeispielRouter Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet

dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 } Router_Subnet_Bridge: type: OS::Neutron::RouterInterface depends_on: Subnet properties: router: { get_resource: Router } subnet: { get_resource: Subnet }

Floating_IP: type: OS::Neutron::FloatingIP properties: floating_network: { get_param: public_network_id } port_id: { get_resource: Port }  Sec_SSH: type: OS::Neutron:SecurityGroup properties: description: Diese Security Group erlaubt den eingehenden SSH-Trafficüber Port22 und ICMP name: Ermöglicht SSH (Port22) und ICMP rules: - { direction: ingress, remote_ip_prefix: 0.0.0.0/0, port_range_min:

22, port_range_max: 22, protocol:tcp } - { direction: ingress, remote_ip_prefix: 0.0.0.0/0,protocol: icmp }

Conclusion

We can now create a stack that contains a reachable single VM.

Step 19: We will add IPv6 to our template

Start

So far, we have a VM that's reachable via IPv4, we're now going to add IPv6 support.

CloudConfig,

Cloud config is a resource with type .OS::HEAT::CloudConfigCloud config can do many things, but in this case we will use it to configure IPv6.We will continue using the template that we've been working on in the previous steps.We'll use it to write the files we mentioned earlier.

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider

resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port }  Instanz-Config: type: OS::Heat::CloudConfig properties: cloud_config: write_files: - path: /etc/dhcp/dhclient6.conf content: "timeout 30;" - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg content: "network: {config: disabled}" - path: /etc/network/interfaces.d/lo.cfg content: | auto lo

iface lo inet loopback - path: /etc/network/interfaces.d/ens3.cfg content: | iface ens3 inet6 auto up sleep 5 up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf/var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true

Netzwerk: type: OS::Neutron::Net properties: name: BeispielNetzwerk Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk } security_groups: { get_resource: Sec_SSH } Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param:public_network_id } name: BeispielRouter Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet dns_nameservers: - 8.8.8.8 - #MussNochEingetragenWerden network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 } Router_Subnet_Bridge: type: OS::Neutron::RouterInterface depends_on: Subnet properties: router: { get_resource: Router } subnet: { get_resource: Subnet } Floating_IP: type: OS::Neutron::FloatingIP properties: floating_network: { get_param: public_network_id } port_id: { get_resource: Port }

Sec_SSH: type: OS::Neutron:SecurityGroup properties: description: Diese Security Group erlaubt den eingehendenSSH-Traffic über Port22 und ICMP name: Ermöglicht SSH (Port22) und ICMP rules: - { direction: ingress, remote_ip_prefix: 0.0.0.0/0,

port_range_min: 22, port_range_max: 22, protocol:tcp } - { direction: ingress, remote_ip_prefix: 0.0.0.0/0,protocol: icmp }

 

We need to restart the interface after we've written all the files.

heat_template_version: 2014-10-16 parameters: key_name: type: string public_network_id: type: string default: provider resources: Instanz: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: Ubuntu 16.04 Xenial Xerus - Latest flavor: m1.small networks: - port: {get_resource: Port }

Instanz-Config: type: OS::Heat::CloudConfig properties: cloud_config: write_files: - path: /etc/dhcp/dhclient6.conf content: "timeout 30;" - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg content: "network: {config: disabled}" - path: /etc/network/interfaces.d/lo.cfg content: | auto lo iface lo inet loopback - path: /etc/network/interfaces.d/ens3.cfg content: | iface ens3 inet6 auto up sleep 5 up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf/var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true runcmd: - [ ifdown, ens3] - [ ifup, ens3] Netzwerk: type: OS::Neutron::Net

properties: name: BeispielNetzwerk Port: type: OS::Neutron::Port properties: network: { get_resource: Netzwerk } security_groups: { get_resource: Sec_SSH } Router: type: OS::Neutron::Router properties: external_gateway_info: { "network": { get_param:public_network_id } name: BeispielRouter Subnet: type: OS::Neutron::Subnet properties: name: BeispielSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: { get_resource: Netzwerk } ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - { start: 10.0.0.10, end: 10.0.0.250 } Router_Subnet_Bridge: type: OS::Neutron::RouterInterface depends_on: Subnet properties: router: { get_resource: Router } subnet: { get_resource: Subnet } Floating_IP: type: OS::Neutron::FloatingIP properties: floating_network: { get_param: public_network_id } port_id: { get_resource: Port } Sec_SSH: type: OS::Neutron:SecurityGroup properties: description: Diese Security Group erlaubt den eingehendenSSH-Traffic über Port22 und ICMP name: Ermöglicht SSH (Port22) und ICMP rules: - { direction: ingress, remote_ip_prefix: 0.0.0.0/0,

port_range_min: 22, port_range_max: 22, protocol:tcp } - { direction: ingress, remote_ip_prefix: 0.0.0.0/0,protocol: icmp }

ConclusionNow we have configured IPv6 on the machine.

Step 20: Build multiple VMs via HEAT

Start

Previously, we've only created a single VM, now we're going to create multiple VMs at the same time.

First StepsTo begin with, we'll spit the template into two parts. We're not doing this for any reason except to show that it's possible.It's best practice to break big setups up into multiple files.First, we'll start with a simple template containing only the network and the port.

heat_template_version: 2014-10-16

description: A simple template which deploys 3 VMs

resources:

ExampleNet: type: OS::Neutron::Net properties: name: ExampleNet

ExampleSubnet: type: OS::Neutron::Subnet properties: name: ExampleSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: {get_resource: ExampleNet} ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - {start: 10.0.0.10, end: 10.0.0.250}

This is the basic structure for our stack, we'll save it as .groups.yamlNow we'll create a template called we'll define the VM here.Now we will create a new template andexampleserver.yaml, exampleserver.yamlwe will describe the vm here. Make sure that name and network_id are not defined.

heat_template_version: 2014-10-16

description: a single server description

parameters: network_id: type: string server_name: type: string

resources: VM: type: OS::Nova::Server properties: user_data_format: RAW image: Ubuntu 16.04 LTS flavor: m1.small name: { get_param: server_name } networks: - port: { get_resource: ExamplePort }

ExamplePort: type: OS::Neutron::Port properties: network: { get_param: network_id }

We'll now change our and add a resource group where we'll add the VMs with the required arguments.groups.yaml

heat_template_version: 2014-10-16

description: A simple template which deploys 3 VMs

resources:  ExampleVM: type: OS::Heat::ResourceGroup depends_on: ExampleSubnet properties: count: 3 resource_def: type: exampleserver.yaml properties: network_id: { get_resource: ExampleNet} server_name: ExampleVM_%index%

ExampleNet: type: OS::Neutron::Net properties: name: ExampleNet

ExampleSubnet: type: OS::Neutron::Subnet properties: name: ExampleSubnet dns_nameservers: - 8.8.8.8 - 8.8.4.4 network: {get_resource: ExampleNet} ip_version: 4 cidr: 10.0.0.0/24 allocation_pools: - {start: 10.0.0.10, end: 10.0.0.250}

Now that we've supplied all the data we can create our stack:

openstack stack create -t groups.yaml <Name of the stack>

Conclusion

Congratulations, we went from creating a single VM via the web interface all the way to creating full stacks with the OpenStack client!