After the theory, we will now move into practice.
You have already launched a server from the GUI.
As a reminder, here's a screenshot of the web form that collects all
the required server ingredients, Image, Flavor, Network, and so on.
I mentioned SSH keys and Security Groups, these are optional
parameters that can also be set in the Access and Security tab.
If you use the commandline to launch a server, you need more or less
the same ingredients. To launch a server, you need an image or
another provisioning source, a flavor and a network connection.
To find suitable candidates for images, flavors, and networks,
use the list commands shown on this slide.
Note that before you can use the commandline, you need to set the
OpenStack environment variables manually or by sourcing an RC file.
If you forgot how to do that, go back to the Identity and Commandline module.
Once you have the required details, you can launch the server.
The command is openstack server create, and the ingredients are
provided via commandline options, the image, the flavor,
and the network as a minimum, and of course the name of the server is also required.
You can also use the corresponding nova boot command.
The options are identical to the OpenStack client.
There is a lot about references on this slide.
What is a reference? You can use an object's name or its ID to
identify the object in commands. But what is an ID?
Almost every object in an OpenStack cloud has a UUID.
This stands for Universally Unique Identifier and is a standardized
16-byte string that is practically guaranteed to be unique for many
years to come. You can find a thorough description on Wikipedia.
Here are two examples, UUIDs for servers and for images.
Uniqueness is achieved by encoding time in the UUID and some sort of
node ID, for example, the MAC address. For the benefit of human
users, most objects can also be given a name.
Sometimes a name is even mandatory, but most object names are not
required to be unique, as is obvious from these two instances here on the slide.
Some object types don't have UUIDs, flavors are an example.
Their IDs are usually small numbers. I suppose this is okay,
because the number of flavors is small, and they usually don't change
much in a cloud. Flavors are very static resources.
Large servers may take minutes to launch, but the server create
command returns almost immediately. To see if the launch was really
successful, you can use the list and show command.
List displays a concise list of all the servers of a project,
and show displays detailed information about a given server.
You can stop a server, which shuts it down, and start it again.
You can also delete a server. When you do that, it disappears without
leaving a trace. In particular, the data stored on its disk is also gone.
You can, however, save the data on a server's disk by making a snapshot.
The command is openstack server image create.
This copies the disk to a new image. The corresponding GUI command is create snapshot.
In case your server breaks, you can then launch another one from that
snapshot image, or you can go back to an earlier state of the server's
data by launching a separate instance. You can also download the
image to a file and use that as a backup, or you can even port it to a different cloud.
It doesn't even have to be an OpenStack cloud.
To ensure that the snapshot data is consistent, it is recommended to
shut the server down before taking the snapshot, or at least to freeze all activity.