Defining OpenStack Identity Service EndPoint

  • (5.0)
  • | 1332 Ratings

Defining Service EndPoint

We must define the service endpoints so that the Identity Service can track which OpenStack services are installed and where they are located on the network. Once the identity service has been started its endpoint must be defined.

To gain in-depth knowledge and be on par with practical experience, then explore  OpenStack Training course.

For this, you must register each service in your OpenStack installation. To register a service, run these commands:

1. keystone service-create. Describes the service.
2. keystone endpoint-create. Associates api endpoints with the service.An endpoint in keystone is just a URL that can be used to access a service within OpenStack.  An endpoint is just like a point of contact for YOU (the user) to use an OpenStack service.
Each of the services in our cloud environment run on a particular URL and port— these are the service endpoint addresses for our services. When a client communicates with our OpenStack environment that runs an OpenStack Identity service, it is this service, that returns the endpoint URLs, which can be further used by the user in an OpenStack environment. To enable this feature, we must define these endpoints. In a cloud environment, we have the ability to 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 refer this as RegionOne.

Getting started

To begin with, ensure you’re logged into our OpenStack Controller host— where OpenStack Identity service has been installed— or an appropriate Ubuntu client that has access to OpenStack Identity service has been installed.
To log on to our OpenStack Controller host that was created using Vagrant, issue the following command:

vagrant ssh controller

If the keystone client tool isn’t available, this 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

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export ENDPOINT =
SERVICE_ENDPOINT = https:// ${ ENDPOINT}: 35357/v2.0

How to achieve 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 an OpenStack Identity service for future use. To define endpoints for services in our OpenStack environment, carry out the following steps:

1) We can now define the actual services that OpenStack Identity service needs to know about in our environment:

2) After finishing this, we can add in the service endpoint URLs that these services run on. To accomplish this, we need the ID that was returned for each of the service endpoints that were created in the previous step. This is then used as a parameter while specifying the endpoint URLS for that service.
OpenStack Identity service can be configured to service requests on three URLs:
1. a public facing URL (that the end users use),
2. an administrative URL (that user with administrative access can use with a completely different URL),
3. 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:

This will result in an output as shown below:

3) We continue to define the rest of our service endpoints as shown in the following steps:

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:

service-create option syntax

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, and identity-service. Note that we haven’t configured the OpenStack Object Storage service (type object-store) or Cinder, at this stage as these are covered in later recipes in the post.

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

endpoint-create option syntax

Here service_id is the ID of the service which has been created during the first step. The list of our services and IDs can be obtained by running the following command:

keystone service-list

Explore OpenStack Sample Resumes! Download & Edit, Get Noticed by Top Employers!  Download Now!

As OpenStack is designed for global deployments, a region defines a physical datacenter or a geographical area that comprises of multiple connected data centers. For our purpose, we just 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:

1. The public_url parameter is the URL that end users would connect to. In a public cloud environment, this would be a public URL that resolves to a public IP address.
2. 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 URL for the admin service, so this is configured using this attribute.
3. The internal_url parameter would be the IP or URL that exists 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_sync command on the OpenStack Identity service server, administration can be done even remotely using the keystone client.

Related Pages:

Openstack tutorial

Interview Questions:

Openstack interview questions

Subscribe For Free Demo

Free Demo for Corporate & Online Trainings. Protection Status