Abstract
| Goal | Identify and configure the additional resource types required to launch instances with public access, including networking and access security elements, for specific use cases. |
| Objectives |
|
| Sections |
|
| Lab |
Configuring Resources to Launch an Instance with Public Access |
After completing this section, you should be able to manage the provider and external network configuration and IP addressing needed to launch instances with public access.
Many cloud applications are public-facing services, or have at least one instance requiring public access. A domain operator ensures that existing data center networks are properly configured and available for use by cloud users. The domain operator can advise the cloud user when to choose between a tenant or provider network, and how to appropriately configure DNS and DHCP parameters.
To deploy an instance for public access there are two methods; use a provider network, or use a tenant network that has a routed connection to an external network.
Provider networks are the most common type of network used by OpenStack clients. Provider networks can only be created by a user with administrative privileges. After being created and shared, provider networks can be used by any cloud user or project. Provider networks can be of type local, flat, VLAN, GRE, VXLAN, or GENEVE.
To use this method, an instance must be deployed to a tenant network that is connected to a router with the gateway set to the external network. For external traffic to reach the instance, the cloud user must associate a floating IP address with the instance, and also create security group rules for each traffic type, such as SSH, ICMP, or HTTP.
When using tenant networks, you can choose any subnet range and any DHCP configuration without affecting any other cloud user or project. When using provider networks, however, you are constrained to working within the existing infrastructure configuration. For example, the network range to use in the associated subnet is determined by the network administrators. Configuring a network range that does not match will result in your network traffic being unroutable, and no communication to or from the instance will work.
The options to configure the provider network type are not arbitrary; they must be selected to align with the physical network design. Network administrators determine what is required and configure the physical network accordingly. The most common network types presented to OpenStack include flat and VLAN networks.
External, provider, and tenant networks can be created using the CLI, however you must have administrative privileges to create a provider network.
The --share option allows all projects to use the virtual network. The --external option specifies that the virtual network is external. Not all provider networks are external; the --internal option creates an internal provider network. The --provider-network-type and --provider-physical-network options connect the flat virtual network to the flat physical network.
[user@demo ~(admin)]$openstack network create \>--external \>--share \>--provider-network-type flat \>--provider-physical-network datacentre \>provider-demo+---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ ...output omitted... | mtu | 1500 | | name | provider-demo | | port_security_enabled | True | | project_id | e6b7f37fadf943e1aae06a5c2e55d646 | | provider:network_type |flat| | provider:physical_network |datacentre| | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 6 | | router:external |External| | segments | None | | shared | True | | status | ACTIVE | | subnets | | | tags | | | updated_at | 2020-07-17T13:44:28Z | +---------------------------+--------------------------------------+
Use the openstack subnet create command to create a subnet for the provider network. Specify the subnet range, DHCP setting, the gateway, the DNS name server, the allocation pool, the network and the subnet name.
[user@demo ~(admin)]$openstack subnet create \>--subnet-range 172.25.250.0/24 \>--no-dhcp \>--gateway 172.25.250.254 \>--dns-nameserver 172.25.250.254 \>--allocation-pool start=172.25.250.101,end=172.25.250.189 \>--network provider-demo \>provider-subnet-172.25.250+-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | allocation_pools |172.25.250.101-172.25.250.189| | cidr | 172.25.250.0/24 | | created_at | 2020-07-17T13:51:02Z | | description | | | dns_nameservers |172.25.250.254| | enable_dhcp |False| | gateway_ip |172.25.250.254| | host_routes | | | id | 1f5e3ad7-25b0-4e49-ad7e-d6673e2882c9 | | ip_version | 4 | | ipv6_address_mode | None | | ipv6_ra_mode | None | | name |provider-subnet-172.25.250| | network_id | 29840e5f-3c29-4937-b6f8-237b51c21899 | | project_id | e6b7f37fadf943e1aae06a5c2e55d646 | | revision_number | 0 | | segment_id | None | | service_types | | | subnetpool_id | None | | tags | | | updated_at | 2020-07-17T13:51:02Z | +-------------------+--------------------------------------+
On the tab, navigate to → .
Disable or enable DHCP and provide an allocation pool, for example 172.25.250.101,172.25.250.189. Enter a DNS name server, for example 172.25.250.254. Click .
For more information, refer to the Red Hat OpenStack Networking Guide at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/networking_guide/index