Defining service endpoints
Each of the services in our cloud environment runs on a particular URL and port—these are the endpoint addresses for our services. When a client communicates with our OpenStack environment that runs the OpenStack Identity service, it is this service that returns the endpoint URLs that the user can use in an OpenStack environment. To enable this feature, we must define these endpoints. In a cloud environment, we can define multiple regions. Regions can be thought of as different datacenters, which would imply that they would have different URLs or IP addresses. Under the OpenStack Identity service, we can define these URL endpoints separately for each region. As we only have a single environment, we will reference this as RegionOne.
Getting ready
We will be using the keystone command line client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.
Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:
export OS_TENANT_NAME=cookbook export OS_USERNAME=admin export OS_PASSWORD=openstack export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/ export OS_NO_CACHE=1 export OS_KEY=/vagrant/cakey.pem export OS_CACERT=/vagrant/ca.pem
Tip
You can use the controller node if no other machines are available on your network, as this has the python-keystoneclient and has the relevant access to the OpenStack environment. If you are using the Vagrant environment, issue the following command to get access to the Controller:
vagrant ssh controller
How to do it...
Defining the services and their endpoints in the OpenStack Identity service involves running the keystone client command. Although we might not have all services currently running in our environment, we will be configuring them within the OpenStack Identity service for future use. To define endpoints for services in our OpenStack environment, carry out the following steps:
- We can now define the actual services that the OpenStack Identity service needs to know about in our environment:
# OpenStack Compute Nova API Endpoint keystone service-create \ --name nova \ --type compute \ --description 'OpenStack Compute Service' # OpenStack Compute EC2 API Endpoint keystone service-create \ --name ec2 \ --type ec2 \ --description 'EC2 Service' # Glance Image Service Endpoint keystone service-create \ --name glance \ --type image \ --description 'OpenStack Image Service' # Keystone Identity Service Endpoint keystone service-create \ --name keystone \ --type identity \ --description 'OpenStack Identity Service' # Neutron Networking Service Endpoint keystone service-create \ --name network \ --type network \ --description 'OpenStack Network Service' #Cinder Block Storage Endpoint keystone service-create \ --name volume \ --type volume \ --description 'Volume Service'
- After we have done this, we can add in the service endpoint URLs that these services run on. To do this, we need the ID that was returned for each of the service endpoints created in the previous step. The ID is then used as a parameter when specifying the endpoint URLS for that service.
Tip
The OpenStack Identity service can be configured to service requests on three URLs: a public facing URL (that the end users use), an administration URL (that users with administrative access can use that might have a different URL), and an internal URL (that is appropriate when presenting the services on either side of a firewall to the public URL).
- For the following services, we will configure separate public, admin, and internal service URLs to provide appropriate separation for our environment. The public endpoint in the accompanying lab environment will be the nominated public interface IP of our controller, which is 192.168.100.200. The internal endpoint will be 172.16.0.200. The
adminendpoint will also be the public IP of 192.168.100.200. To do this run the following commands:# OpenStack Compute Nova API NOVA_SERVICE_ID=$(keystone service-list \ | awk '/\ nova\ / {print $2}') PUBLIC_ENDPOINT=192.168.100.200 ADMIN_ENDPOINT=192.168.100.200 INT_ENDPOINT=172.16.0.200 PUBLIC="http://$PUBLIC_ENDPOINT:8774/v2/\$(tenant_id)s" ADMIN="http://$ADMIN_ENDPOINT:8774/v2/\$(tenant_id)s" INTERNAL="http://$INT_ENDPOINT:8774/v2/\$(tenant_id)s" keystone endpoint-create \ --region RegionOne \ --service_id $NOVA_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL
You will get output similar to what is shown below:
+-------------+------------------------------------------------+ | Property | Value | +-------------+------------------------------------------------+ | adminurl | http://192.168.100.200:8774/v2/$(tenant_id)s | | id | 87b59c5ce8314d8b9029bf1efd5044d7 | | internalurl | http://172.16.0.100:8774/v2/$(tenant_id)s | | publicurl | http://192.168.100.200:8774/v2/$(tenant_id)s | | region | RegionOne | | service_id | a3529dcbeab44d479d1f258ae6d202b4 | +-------------+------------------------------------------------+
- We continue to define the rest of our service endpoints, as shown in the following steps:
# OpenStack Compute EC2 API EC2_SERVICE_ID=$(keystone service-list \ | awk '/\ ec2\ / {print $2}') PUBLIC="http://$PUBLIC_ENDPOINT:8773/services/Cloud" ADMIN="http://$ADMIN_ENDPOINT:8773/services/Admin" INTERNAL="http://$INT_ENDPOINT:8773/services/Cloud" keystone endpoint-create \ --region RegionOne \ --service_id $EC2_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL # Glance Image Service GLANCE_SERVICE_ID=$(keystone service-list \ | awk '/\ glance\ / {print $2}') PUBLIC="http://$PUBLIC_ENDPOINT:9292/v1" ADMIN="http://$ADMIN_ENDPOINT:9292/v1" INTERNAL="http://$INT_ENDPOINT:9292/v1" keystone endpoint-create \ --region RegionOne \ --service_id $GLANCE_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL # Keystone OpenStack Identity Service # Note we're using SSL HTTPS here KEYSTONE_SERVICE_ID=$(keystone service-list \ | awk '/\ keystone\ / {print $2}') PUBLIC="https://$PUBLIC_ENDPOINT:5000/v2.0" ADMIN="https://$ADMIN_ENDPOINT:35357/v2.0" INTERNAL="https://$INT_ENDPOINT:5000/v2.0" keystone endpoint-create \ --region RegionOne \ --service_id $KEYSTONE_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL # Neutron Networking Service NEUTRON_SERVICE_ID=$(keystone service-list \ | awk '/\ network\ / {print $2}') PUBLIC="http://$PUBLIC_ENDPOINT:9696" ADMIN="http://$ADMIN_ENDPOINT:9696" INTERNAL="http://$INT_ENDPOINT:9696" keystone endpoint-create \ --region RegionOne \ --service_id $NEUTRON_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL #Cinder Block Storage Service CINDER_SERVICE_ID=$(keystone service-list \ | awk '/\ volume\ / {print $2}') PUBLIC="http://$PUBLIC_ENDPOINT:8776/v1/%(tenant_id)s" ADMIN=$PUBLIC INTERNAL=$PUBLIC keystone endpoint-create \ --region RegionOne \ --service_id $CINDER_SERVICE_ID \ --publicurl $PUBLIC \ --adminurl $ADMIN \ --internalurl $INTERNAL
How it works...
Configuring the services and endpoints within the OpenStack Identity service is done with the keystone client command.
We first add the service definitions using the keystone client and the service-create option with the following syntax:
keystone service-create \ --name service_name \ --type service_type \ --description 'description'
In the service_name is an arbitrary name or label defining our service of a particular type. We refer to the name when defining the endpoint to fetch the ID of the service.
The type option can be one of the following: compute, object-store, image-service, network, and identity-service. Note that we haven't configured the OpenStack Object Storage service (type object-store) at this stage, as this is covered in later recipes in the book.
The description field is again an arbitrary field describing the service.
Once we have added in our service definitions, we can tell OpenStack Identity service from where these services run by defining the endpoints using the keystone client and the endpoint-create option. The syntax is as follows:
keystone endpoint-create \ --region region_name \ --service_id service_id \ --publicurl public_url \ -–adminurl admin_url \ --internalurl internal_url
Here, service_id is the ID of the service when we created the service definitions in the first step. The list of our services and IDs can be obtained by running the following command:
keystone service-list
As OpenStack is designed for global deployments, a region defines a physical datacenter or a geographical area that comprises of multiple connected datacenters. For our purpose, we define just a single region—RegionOne. This is an arbitrary name that we can reference when specifying what runs in what datacenter/area and we carry the region name through to when we configure our client for use with these regions.
All of our services can be configured to run on three different URLs, as follows, depending on how we want to configure our OpenStack cloud environment:
public_url: This parameter is the URL that end users would connect on. In a public cloud environment, this would be a public URL that resolves to a public IP address.admin_url: This parameter is a restricted address for conducting administration. In a public deployment, you would keep this separate from thepublic_urlby presenting the service you are configuring on a different, restricted URL. Some services have a different URI for the admin service, so this is configured using this attribute.internal_url: This parameter would be the IP or URL that existed only within the private local area network. The reason for this is that you can connect to services from your cloud environment internally without connecting over a public IP address space, which could incur data charges for traversing the Internet. It is also potentially more secure and less complex to do so.Tip
Once the initial
keystonedatabase has been set up, after running the initialkeystone-manage db_synccommand on the OpenStack Identity service server, administration can be done remotely using thekeystoneclient.
