电玩捕鱼机有人管吗

書名： OpenStack Cloud Computing Cookbook（Third Edition）
作者名： Kevin Jackson Cody Bunch Egle Sigler
本章字數： 1376字
更新時間： 2021-07-16 20:39:13

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 admin endpoint 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 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.
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 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 remotely using the keystone client.

官术网_书友最值得收藏!

OpenStack Cloud Computing Cookbook（Third Edition）

Defining service endpoints

Getting ready

Tip

How to do it...

Tip

How it works...

Tip