Red Hat OpenStack Administration I: Core Operations for Domain Operators
After completing this section, you should be able to select and manage relevant parameters for launching instances with public access, for common use cases.
An instance with public access is an instance that has access to the external network. Launching an instance with public access is very similar to launching a private instance in a project. Cloud users use the same openstack server create command to create the instance. Launching an instance with public access has security implications; consequently extra options are available for the openstack server create command.
You can use the --key-name option to include a key pair when you create the instance. The key pair must be created prior to, and specified during, the instance launch. A key pair cannot be associated with an instance after the instance has been created. It is important that the private SSH key is kept safe, because it is used later to log in to the instance without a password. The following example shows an instance being created using the key pair named keypair-namedemo.
[user@demo ~(user)]$openstack server create \>--flavor default \>--image rhel7 \>--key-name demo \>demo-server1
When the instance is running, the private SSH key can be used to connect to the instance. Normally, the cloud-user user is automatically created in the instance and is now allowed to log in using SSH. The following example shows an ssh command connecting to an instance using a floating IP address.
[user@demo ~(user)]$ ssh -i ~/.ssh/demo.pem cloud-user@172.25.250.30
[cloud-user@demo-server1 ~]$Note
It is a recommended practice to name the SSH private key using the same name as the OpenStack key pair. This makes it simpler to determine which SSH private key belongs to which OpenStack key pair. Otherwise, you must match the fingerprint of the associated public key with the key pair in OpenStack (using openstack keypair show keypair-name).
To determine which, if any, key pair is associated with an instance, use the openstack server show command. The key_name entry in the output shows the key pair used for the instance.
...output omitted... |key_name|demo| ...output omitted...
An SSH key that you create outside of Red Hat OpenStack Platform can also be used by OpenStack. When you use the openstack keypair create command to create an OpenStack key pair, you can provide your existing public key using the --public-key option. The following example shows the creation of a key pair named public-ssh-key-filedemo that uses the existing public key file named id_rsa.pub.
[user@demo ~(user)]$openstack keypair create \>--public-key ~/.ssh/id_rsa.pub demo+-------------+-----------------------------------+ | Field | Value | +-------------+-----------------------------------+ | fingerprint | 26:c8:27:45:...:2a:a2:3e:b8:64:5f | | name | demo | | user_id | c0a85a6918b14200884a276d92415872 | +-------------+-----------------------------------+
The --security-group option is used to associate a security group with an instance when it is created. All the rules in the security group apply to the instance. If a security group includes access to SSH (TCP/22) and HTTP (TCP/80), those ports are opened, regardless of whether the instance is running the services on those ports or not.
Unlike a key pair, a security group can be created and attached to an instance after the instance has been launched, and multiple security groups can be associated with an instance. To add a security group to a running instance, use the openstack server add security group command. The following example shows the security group named secgroup1 being added to a running instance named demo-server1.
[user@demo ~(user)]$openstack server add security group \>demo-server1 secgroup1
To determine which security groups are used by an instance, use the openstack server show command. The security_groups entry in the output shows the security group names used by the instance.
...output omitted... | security_groups | name='secgroup1' | ...output omitted...
Find the necessary resources to create the public instance. Necessary resources include an image, flavor, network, and key pair. The security group option can be specified at the creation of the instance or afterwards.
Launch the instance using the necessary resources. If the instance is launched on a tenant network, ensure it has a port on the router. Ensure that the external network exists and is set as the gateway for the router. Create a floating IP address, if there are none available, and associate it with the instance.
The procedure for verifying an instance with public access is very similar to verifying an external instance: inspect the network and any services that are running. Verifying a connected network includes verifying that DHCP is providing IP addresses, DNS is resolving names, and network packets are traversing the correct routes. This usually involves verifying the IP address assigned to the instance, confirming that DNS names work, and pinging out from the instance. If static routes were created for the instance, these should be verified as well.
After the instance has been assigned a floating IP address, one of the simplest networking tests is to ping the instance. The ping command sends an ICMP echo request, and expects an ICMP echo reply. If an echo reply is sent back from the instance, it indicates that the instance networking is functional. The following examples show an ICMP echo request being sent to an instance using a floating IP address.
[user@demo ~(user)]$ ping -c 3 -w 5 172.25.250.30
PING 172.25.250.30 (172.25.250.30) 56(84) bytes of data.
64 bytes from 172.25.250.30: icmp_seq=1 ttl=63 time=0.492 ms
64 bytes from 172.25.250.30: icmp_seq=2 ttl=63 time=0.492 ms
64 bytes from 172.25.250.30: icmp_seq=3 ttl=63 time=0.441 ms
--- 172.25.250.30 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.441/0.475/0.492/0.024 msYou can use SSH to connect to the instance. SSH provides a remote shell into the instance that allows a user to execute commands on the instance. The remote user account information on the instance must be known to the user accessing the shell. In some cases, that user account information is the user name and password contained in the image used to launch the instance. However, in most cases in the cloud, the user name is used with the SSH private key from the OpenStack key pair as credentials for the instance. The root account is usually prevented from logging in using SSH for security purposes.
In RHOSP, the default user account created by cloud-init is the cloud-user account. The key pair is injected into the instance by cloud-init. This account is configured to use the SSH key pair specified when the instance launches. The cloud-user account also has full sudo privileges. The following example shows an SSH connection to an instance using a private key stored in ~/.ssh/keypair1.pem.
[user@demo ~(user)]$ ssh -i ~/.ssh/keypair1.pem cloud-user@172.25.250.30
Last login: Thu Dec 21 11:44:00 2017 from demo.lab.example.com
[cloud-user@demo-server1 ~]$Use the cat command to confirm that cloud-init injected the SSH key into the instance at launch.
[cloud-user@demo-server1 ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2E
...output omitted...
Generated-by-NovaAfter logging in to the instance over SSH, ping another IP address from the instance to verify external network connectivity. This tests the network connection out and in, as well as testing DNS name resolution. The following example shows a ping command as well as some DNS lookup commands from the instance.
[cloud-user@demo-server1 ~]$ping -c 3 -w 5 redhat.comPING redhat.com (209.132.183.105) 56(84) bytes of data. 64 bytes from redirect.redhat.com (209.132.183.105): icmp_seq=1 ttl=232 time=109 ms 64 bytes from redirect.redhat.com (209.132.183.105): icmp_seq=2 ttl=232 time=98.5 ms 64 bytes from redirect.redhat.com (209.132.183.105): icmp_seq=3 ttl=232 time=96.4 ms --- redhat.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 96.401/101.476/109.480/5.738 ms [cloud-user@demo-server1 ~]$host redhat.comredhat.com has address 209.132.183.105 redhat.com mail is handled by 10 mx2.redhat.com. redhat.com mail is handled by 5 mx1.redhat.com. [cloud-user@demo-server1 ~]$dig redhat.com; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> redhat.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59309 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;redhat.com. IN A ;; ANSWER SECTION: redhat.com. 3400 IN A 209.132.183.105 ;; Query time: 0 msec ;; SERVER: 172.25.250.254#53(172.25.250.254) ;; WHEN: Tue Mar 28 09:29:21 EDT 2017 ;; MSG SIZE rcvd: 44
Note
The host and dig commands, and many other useful DNS tools, are provided by the bind-utils package. The image used by the instance may not include that package. If that is the case, install the bind-utils package to provide these utilities.
After checking the instance networking, other services can be tested. For example, if the instance is running a web server, test a connection to the web server. If the instance is running a database server, attempt to access data from the server. The following example shows a test for HTTP using the floating IP address of the instance.
[user@demo ~(user)]$ curl http://172.25.250.30
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/
DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the Apache HTTP Server on Red Hat Enterprise Linux</title>
...output omitted...If SSH access to the instance is not working, it is possible to gain access to the instance using the VNC console. Use the openstack console url show command with the instance name to find the VNC console URL. Open the URL in a browser. Assuming that you know the user name and password, log in to the instance.
[user@demo ~(user)]$ openstack console url show demo-server1
+-------+-------------------------------------------------+
| Field | Value |
+-------+-------------------------------------------------+
| type | novnc |
| url | http://172.25.250.50:6080/vnc_auto.html?path=...|
+-------+-------------------------------------------------+Software-defined networking in OpenStack is an added layer of complexity when it comes to troubleshooting. Software-defined networks lay on top of the physical network layer, and this layer may need some troubleshooting when dealing with instances.
Ensure that the instance was assigned the correct network. It is possible to create many private networks in OpenStack with the same name, and even using the same network range. Ensure that the correct network was used with the instance using the openstack server list command, which prints out the network names and IP addresses used by the instance.
Use SSH to log in to the instance. Use the ip a command to view the IP address for the instance. Ping the gateway from the instance. Find the DNS server and confirm it can be accessed from the instance.
[cloud-user@demo-server1 ~]$ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc fq_codel state UP group default qlen 1000 link/ether fa:16:3e:03:fa:1c brd ff:ff:ff:ff:ff:ff inet 192.168.1.81/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 42738sec preferred_lft 42738sec inet6 fe80::f816:3eff:fe03:fa1c/64 scope link valid_lft forever preferred_lft forever [cloud-user@demo-server1 ~]$ping -c3 192.168.1.1PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=14.6 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=0.377 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=254 time=0.353 ms --- 192.168.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 53ms rtt min/avg/max/mdev = 0.353/5.094/14.554/6.689 ms
[cloud-user@demo-server1 ~]$cat /etc/resolv.conf...output omitted... nameserver 172.25.250.254 [cloud-user@demo-server1 ~]$ping -c3 172.25.254.254PING 172.25.254.254 (172.25.254.254) 56(84) bytes of data. 64 bytes from 172.25.254.254: icmp_seq=1 ttl=62 time=0.867 ms 64 bytes from 172.25.254.254: icmp_seq=2 ttl=62 time=0.844 ms 64 bytes from 172.25.254.254: icmp_seq=3 ttl=62 time=0.536 ms --- 172.25.254.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 30ms rtt min/avg/max/mdev = 0.536/0.749/0.867/0.150 ms
Verify routing with the ip r command to ensure the correct routes are present. Confirm that the instance can ping the DHCP server.
[cloud-user@demo-server1 ~]$ip rdefault via 192.168.1.1 dev eth0 proto dhcp metric 100 169.254.169.254 via 192.168.1.2 dev eth0 proto dhcp metric 100 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.81 metric 100 [cloud-user@demo-server1 ~]$ping -c3 192.168.1.2PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.976 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.413 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.161 ms --- 192.168.1.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 58ms rtt min/avg/max/mdev = 0.161/0.516/0.976/0.341 ms
Verify that DNS is working properly by using host or dig to validate host names.
[cloud-user@demo-server1 ~]$ host materials.example.com
materials.example.com has address 172.25.254.254Log in to the Dashboard and navigate to → → .
Security groups can also be added after the instance has been created. However, a key pair must be selected when you create the instance; it cannot be added later. This behavior is the same in both the CLI and the Dashboard.
References
For more information, refer to the Virtual Machine Instances chapter in the Red Hat OpenStack Instances and Images Guide at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/instances_and_images_guide/index#ch-manage_instances
