Now that our server is running, let's see how we can access it.
In the GUI, you accessed the read only console log and the interactive console.
How can you do that with a commandline? Nova shows the server's
startup messages with the command openstack console log show.
For the interactive console, you either need a browser, or a VNC
client, or a SPICE client. The commandline tells you the URL through
which you access the console, just issue this command here,
openstack console url show. The URL that is issued here can be put
into a browser or a client, NVC or SPICE.
Usually servers are accessed over the network.
Now by default, OpenStack implements a very strict firewall around a
server, which blocks all TCP and UDP ports, and even ICMP.
We have to open the ports we need. In the case of SSH, it would be port 22.
So in a way, we punch a hole into the firewall to permit SSH access.
It's a common situation that many servers require the same port ranges
to be open. OpenStack groups them into so called security groups.
For example, let's say that you have these five servers, and three of
them are running web servers. Now web servers need TCP ports 80 and
443 to be open. You could define a security group named web,
open these two ports, and add the three servers to the security group.
Four of those five servers also require SSH access.
So you define a security group for SSH, which opens TCP port 22.
The description on the left is a bit simplified actually.
More accurately, at a launch time, a server will be in the project's
default security group. You can change this group's firewall rules,
but if you don't do it, it puts no limits on any traffic that leaves the server.
Traffic that enters the server is treated differently depending on its origin.
If it comes from a server in the same default security group,
which means in the same project in most cases, it is not blocked.
If it comes from anywhere else, such as a different security group or
even outside of the cloud, it will be blocked.
If you use the GUI, security groups are managed under the Access and Security section.
Since you have explored that already, let's move on to the commandline.
You have the option of modifying the default security group,
but since everybody expects it to have certain characteristics,
you may prefer to leave it alone. Instead, create a new security group.
After its creation, it will have a single rule, outgoing IPv4 traffic is allowed.
If the cloud also configures IPv6, it has the second rule for IPv6 as well.
Then you add your own rules. This example creates a rule for incoming TCP traffic.
That's the default. If you want a rule for outgoing traffic or for a
different protocol, that is UDP or ICMP, you have to add commandline options.
Here traffic destined to TCP port 12345 is accepted.
Once you have added all your rules, you can add servers to the
security group, or perhaps you add the security group to servers.
Even later, after the security group is associated with servers,
you can add and delete rules. The new rules will then take immediate
effect, and of course when you delete rules, that will also take effect immediately.
You can, of course, list the rules in a security group.
The output is not very useful, I recommend the --long option to
display more detail. The corresponding Nova client commands are not
as comfortable, if you are curious, please explore them on your own.
Although my server has an IP address and belongs to a security group
that accepts ICMP and SSH packets, we can't connect to it.
Why? Its IP address starts with 10 and is not routable.
The Packstack server doesn't have a route to the private network.
In order to access the instance from outside, it needs an IP address
that can be reached from outside. OpenStack names such an IP address
a floating IP, a term that was borrowed from Amazon.
Floating, because the IP address is first acquired by the project,
and then freely used to associate it with any server.
The server's IP address on the private network is then called its fixed IP.
The router will carry the new floating IP, the packet whose
destination address is the floating IP is delivered to the router,
which then rewrites the destination address to the fixed IP.
In other words, the router performs Destination Network Address
Translation, or DNAT. And the packet is then delivered to the server.
For the user, the workflow is as follows, check if any floating IP is
available, if not, acquire a floating IP from an external network.
Often, a cloud has only one external network, in the case of
Packstack, it's named public. And then finally you associate the
floating IP with the server.
You can use the GUI for managing floating IPs.
Go to the Access an Security page. You see that in the list,
no floating IPs are available, therefore obtain one from the public network.
You see the new floating IP in the list now, and at this point,
you are ready for step 3, and you can associate the IP with a server.
These are the commands to list, create, and associate floating IPs with servers.
You can then also remove a floating IP from a server if you don't need it anymore.
And when you don't need a floating IP anymore at all, you can give it
back with the floating IP delete command.
You should do that as a good citizen in a private cloud, or in a
public cloud, because you will probably be billed for it.