Defining service endpoints

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 OpenStack Identity Service, it is this service that returns the endpoint URLs, which the user can then use in an OpenStack environment. To enable this feature, we must define these endpoints. In a cloud environment, though, 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 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

To begin with, ensure you're logged in to our OpenStack Compute host—where OpenStack Identity Service has been installed—or an appropriate Ubuntu client that has access to where OpenStack Identity Service is installed.

If the keystone client tool isn't available, it can be installed on an Ubuntu client to manage our OpenStack Identity Service, by issuing the following commands:

sudo apt-get update sudo apt-get -y install python-keystoneclient

How to do it...

Defining the services and service endpoints in OpenStack Identity Service involves running the keystone client command to specify the different services and the URLs that they run from. Although we might not have all services currently running in our environment, we will be configuring them within OpenStack Identity Service for future use.

To manage our OpenStack Identity Service, we have to authenticate with the service itself. Without any users configured though, we make use of an admin token to send directly back to the admin port of OpenStack Identity Service. These are also known as a service token and service port. These details are configured directly in/etc/keystone/keystone.conf, as follows:

admin_port = 35357
admin_token = ADMIN

To define endpoints for services in our OpenStack environment, carry out the following steps:

1. First, we set the service token and service endpoint, which point to the service port of our OpenStack Identity Service.

   export ENDPOINT=172.16.0.1 export SERVICE_TOKEN=ADMIN export SERVICE_ENDPOINT=http://${ENDPOINT}:35357/v2.0

2. We can now define the actual services that 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' 
   # Nova Volume Endpoint 
   keystone service-create --name volume --type volume --description 'Volume Service'

3. 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. This is then used as a parameter when specifying the endpoint URLS for that service.

   Note that 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 the public and internal service URLs to be the same, which is appropriate for our environment.

# OpenStack Compute Nova API
ID=$(keystone service-list | awk '/\ nova\ / {print $2}')

PUBLIC="http://$ENDPOINT:8774/v2/\$(tenant_id)s"
ADMIN=$PUBLIC
INTERNAL=$PUBLIC

keystone endpoint-create --region RegionOne --service_id $ID --publicurl $PUBLIC --adminurl $ADMIN --internalurl $INTERNAL


# OpenStack Compute EC2 API
ID=$(keystone service-list | awk '/\ ec2\ / {print $2}')

PUBLIC="http://$ENDPOINT:8773/services/Cloud"
ADMIN="http://$ENDPOINT:8773/services/Admin"
INTERNAL=$PUBLIC

keystone endpoint-create --region RegionOne --service_id $ID --publicurl $PUBLIC --adminurl $ADMIN --internalurl $INTERNAL


# Glance Image Service
ID=$(keystone service-list | awk '/\ glance\ / {print $2}')

PUBLIC="http://$ENDPOINT:9292/v1"
ADMIN=$PUBLIC
INTERNAL=$PUBLIC

keystone endpoint-create --region RegionOne --service_id $ID --publicurl $PUBLIC --adminurl $ADMIN --internalurl $INTERNAL


# Keystone OpenStack Identity Service
ID=$(keystone service-list | awk '/\ keystone\ / {print $2}')

PUBLIC="http://$ENDPOINT:5000/v2.0"
ADMIN="http://$ENDPOINT:35357/v2.0"
INTERNAL=$PUBLIC

keystone endpoint-create --region RegionOne --service_id $ID --publicurl $PUBLIC --adminurl $ADMIN --internalurl $INTERNAL


# Nova Volume
ID=$(keystone service-list | awk '/\ volume\ / {print $2}')

PUBLIC="http://$ENDPOINT:8776/v1/%(tenant_id)s"
ADMIN=$PUBLIC
INTERNAL=$PUBLIC

keystone endpoint-create --region RegionOne --service_id $ID --publicurl $PUBLIC --adminurl 
$ADMIN --internalurl $INTERNAL

How it works...

Configuring the services and endpoints within OpenStack Identity Service is done with the keystone client command.

We first add the service definitions, by using the keystone client and the service-create option with the following syntax:

keystone service-create --name service_name --type service_type --description 'description'

service_name is an arbitrary name or label defining a 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, and identity-service. Note that we haven't configured the OpenStack Storage service (type object-store) at this stage.

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 where those services run from, by defining the endpoints using the keystone client and the endpoint-create option, with the following syntax:

keystone endpoint-create --region region_name --service_id service_id --publicurl public_url --adminurl admin_url --internalurl internal_url

Where 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 this 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:

• The public_url 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.
• The admin_url parameter is a restricted address for conducting administration. In a public deployment, you would keep this separate from the public_URL by 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.
• The internal_url parameter would be the IP or URL that existed only within the private local area network. The reason for this is that you are able to 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.

  Once the initial keystone database has been set up, after running the initial keystone-manage db_synccommand on the OpenStack Identity Service server, administration can be done remotely using the keystoneclient.