Wechat official account: Operation and maintenance development story, author: Wanger
OpenStack authentication service construction
Overview of the Keystone Service
OpenStack identity services provide a single point of integration for managing authentication, authorization, and service catalogs.
An identity service is usually the first service a user interacts with. Once authenticated, end users can use their identity to access other OpenStack services. Similarly, other OpenStack services leverage identity services to ensure that users are who they say they are and to discover the location of other services in deployment. The identity service can also be integrated with some external user management systems, such as LDAP.
Users and services can locate other services by using the service catalog managed by identity services. As the name suggests, a service catalog is a collection of services available in an OpenStack deployment. Each service can have one or more endpoints, and each endpoint can be one of three types: Admin, internal, or public. In a production environment, different types of end types may reside on separate networks exposed to different types of users for security reasons. For example, a public API network may be visible over the Internet so customers can manage their cloud. The management API network may be limited to carriers in organizations that manage cloud infrastructure. The internal API network may be limited to hosts that contain OpenStack services. Additionally, OpenStack supports scalability across multiple regions. RegionOne region. Regions created in identity services, services and endpoints together form a directory of deployed services. Each OpenStack service in the deployment requires a service entry and stores the corresponding endpoint in the Identity service. This can be done after the Identity Service is installed and configured.
The identity service contains the following components:
-
The server
-
Centralized servers use RESTful interfaces to provide authentication and authorization services.
-
The driver
-
The driver or service back end is integrated into the central server. They are used to access identity information in repositories outside OpenStack and may already exist in the infrastructure where OpenStack is deployed (such as SQL databases or LDAP servers).
-
The module
-
The middleware module runs in the address space of an OpenStack component that uses the Identity service. These modules intercept service requests, extract user credentials and send them to a central server for authorization. The integration between middleware modules and OpenStack components uses the Python Web server gateway interface.
1. Create and configure the Keystone database
Enter the Mariadb database
[root@controller /]# mysql -uroot -p
Creating the Keystone Database
MariaDB [mysql]> create database keystone;
Create the keystone database authorized user Keystone
MariaDB[mysql]> grant all privileges on keystone.* to ‘keystone’@’localhost’identified by ‘keystone’;
MariaDB[mysql]> grant all privileges on keystone.* to ‘keystone’@’%’ identified by’keystone’;
View authorized users
MariaDB [mysql]> select user,host from user\G;
2. Install and configure the Keystone service
[root@controller/]# yum install openstack-keystone httpd mod_wsgi
Edit/etc/keystone/keystone. The conf file and do the following:
In the [Database] section, configure database access:
[database]
Connection = mysql + pymysql: / / keystone: [email protected] / keystone
In this [Token] section, configure the Fernet token provider
[token]
provider =fernet
The complete configuration is as follows:
Initialize the authentication service database
[root@controller/]# su -s /bin/sh -c “keystone-manage db_sync” keystone
Note: The format of database in the configuration file must be correct; otherwise, an error or synchronization failure will occur
Initialize the Fernet keystore
[root@controller/]# keystone-manage fernet_setup –keystone-user keystone –keystone-groupkeystone
[root@controller/]# keystone-manage credential_setup –keystone-user keystone –keystone-groupkeystone
Create an identity service API endpoint
[root@controller/]# keystone-manage bootstrap –bootstrap-password admin –bootstrap-admin-urlhttp://controller:35357/v3/ –bootstrap-internal-url http://controller:5000/v3/–bootstrap-public-url http://controller.5500/v3/ –bootstrap-region-idRegionOne
3. Configure the Apache HTTP server
Edit the/etc/HTTPD/conf/HTTPD. Conf file and configure the ServerName options by reference node controller
echo ServerName controller >> /etc/httpd/conf/httpd.conf
Add the configuration file for the mod_WSgi module and create a soft link to /etc/httpd/conf.d/
ln -s/usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
4. Start the HTTPD service and set it to automatic startup
[root@controller/]# systemctl enable httpd
[root@controller/]# systemctl start httpd
5. Configure the management account
exportOS_USERNAME=admin
exportOS_PASSWORD=admin
exportOS_PROJECT_NAME=admin
exportOS_USER_DOMAIN_NAME=Default
exportOS_PROJECT_DOMAIN_NAME=Default
export OS_AUTH_URL=http://controller:35357/v3
exportOS_IDENTITY_API_VERSION=3
6. Create a domain, project, user, and role
Identity services provide authentication services for each OpenStack service. Authentication services use a combination of domains, projects, users, and roles.
Creating a service project
[root@controller~]# openstack project create –domain default –description “ServiceProject” service
Note: There may be an error “Missing value auth-URL required for auth pluginpassword”. After the error is reported, try to execute step 5 again and create successfully
Creating a Demo Project
[root@controller~]# openstack project create –domain default –description “DemoProject” demo
Creating demo Users
[root@controller~]# openstack user create –domain default –password-prompt demo
Creating a User role
[root@controller~]# openstack role create user
Add the user role to the Demo project and demo user
openstackrole add –project demo –user demo user
View the list of current projects
[root@controller ~]# openstack project list
View the current user list
[root@controller ~]# openstack user list
7. Verify the Keystone operation
The temporary ENVIRONMENT variables OS_AUTH_URL and OS_PASSWORD are deleted
[root@controller~]# unset OS_AUTH_URL OS_PASSWORD
As the admin user, request an authentication token
[root@controller~]# openstack –os-auth-url http://controller:35357/v3 \
> –os-project-domain-name Default–os-user-domain-name Default \
> –os-project-name admin –os-username admintoken issue
As a Demo user, request an authentication token
[root@controller~]# openstack –os-auth-url http://controller:5000/v3 \
> –os-project-domain-name Default–os-user-domain-name Default \
> –os-project-name demo –os-username demotoken issue
8. Create an OpenStack client environment script
Create client environment scripts admin and Demo projects and users
Create and edit the admin-Openrc file and add the following:
Create and edit the demon-OpenRC file and add the following:
9. Use scripts
To run the client as a specific project and user, simply load the relevant client environment scripts before running them. Such as:
Load the Admin-Openrc file to populate the environment variables with the location of the Identity service and the admin project and user credentials:
[root@controller~]# . admin-openrc
Request authentication token:
[root@controller~]# openstack token issue
The Keystone service of OpenStack is set up
OpenStack image service construction
Glance Service Overview
The Image service (Glance) enables users to discover, register, and retrieve VM images. It provides a REST API that allows you to query virtual machine image metadata and retrieve the actual image. You can store virtual machine images provided by the image service in a variety of locations, from simple file systems to object storage systems such as OpenStack object storage.
OpenStack Image service is the core of Infrastructure as a Service (IaaS). It accepts API requests for disk or server images as well as metadata definitions from end users or OpenStack Compute components. It also supports storage of disks or server images on various repository types, including OpenStack object Storage.
Many scheduled processes run on the OpenStack Image service to support caching. Replication services ensure consistency and availability through clustering. Other regular processes include auditors, renovators and reapers.
OpenStack Image service consists of the following components:
-
glance-api
Accepts image API calls for image discovery, retrieval, and storage.
-
glance-registry
Store, process, and retrieve metadata about images. Metadata includes items such as size and type.
-
The database
Store image metadata, and you can choose the database as you like. Most deployments use MySQL or SQLite.
-
A repository for image files
Supports a variety of repository types, including regular file systems (or any file system installed on a Glance-API controller node), Object Storage, RADOS block devices, VMware datastore, and HTTP. Note that some repositories support read-only usage only.
-
Metadata defines services
Common apis for vendors, administrators, services, and users to meaningfully define their own custom metadata. This metadata can be used for different types of resources, such as images, artifacts, volumes, flavors, and aggregates. Defines keywords including new attributes, descriptions, constraints, and resource types that it can be associated with.
1. Create the Glance database and authorize it
Accessing the database
[root@controller ~]# mysql -uroot -p
Creating the Glance Database
MariaDB [(none)]> create database glance;
Create an authorized user for the Glance database
MariaDB[(none)]> grant all privileges on glance.* to ‘glance’@’localhost’identified by ‘glance’;
MariaDB[(none)]> grant all privileges on glance.* to ‘glance’@’%’ identified by’glance’;
2. Create the Glance user and service
Loading environment variables
[root@controller ~]# . admin-openrc
Creating a Glance User
[root@controller~]# openstack
create–domain default –password-prompt glance
Add the admin role to the Glance user and service project
[root@controller ~]# openstack role add –project service –user glanceadmin
Create the Glance service entity
[root@controller ~]# openstack service create –name glance–description “OpenStack Image” image
3. Create the image service API endpoint
[root@controller~]# openstack endpoint create –region RegionOne image public http://controller:9292
[root@controller~]# openstack endpoint create –region RegionOne image internal http://controller:9292
[root@controller~]# openstack endpoint create –region RegionOne image admin http://controller:9292
Installing software Packages
[root@controller ~]# yum install openstack-glance
Edit the /etc/glance-glance-api. conf file and complete the following operations:
In the [Database] section, configure database access:
[database]
Connection = mysql + pymysql: / / glance: [email protected] / glance
In the [keystone_authToken] and [paste_deploy] sections, configure identity service access:
[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = glance
password = glance
[paste_deploy]
flavor = keystone
In this [glance_store] section, you configure the location of the local file system to store and image files
[glance_store]
stores = file,http
default_store = file
filesystem_store_datadir = /var/lib/glance/images/
The complete configuration is as follows:
Edit the /etc/glance-glance-registry. Conf file and complete the following operations:
In the [Database] section, configure database access:
[database]
connection = mysql+pymysql://glance:glance@controller/glance
In the [keystone_authToken] and [paste_deploy] sections, configure identity service access:
[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_nam = default
project_name= service
username = glance
password = glance
[paste_deploy]
flavor = keystone
The complete configuration is as follows:
5. Initialize the Glance database
[root@controller~]# su -s /bin/sh -c “glance-manage db_sync” glance // Ignore any output
Verify that the synchronization is successful
[root@controller ~]# mysql -uglance -pglance -e “use glance; showtables;” |wc -l
6. Start the image service and configure it to start at system boot
[root@controller~]# systemctl enable openstack-glance-api openstack-glance-registry
[root@controller~]# systemctl start openstack-glance-api openstack-glance-registry
7. Verify the Glance service
Use CirrOS images to verify that the mirror service is properly installed. CirrOS is a small Linux image that can be used to test your OpenStack environment.
Loading environment variables
[root@controller ~]# . admin-openrc
Downloading a Source Image
/ root @ controller ~ # wget download.cirros-cloud.net/0.3.4/cirro…
Upload the image file to the image service using QCOW2 disk format, bare container format, add public visibility options so that all projects can access the image
[root@controller ~]# openstack image create “cirros” –filecirros-0.3.4-x86_64-disk.img –disk-format qcow2 –container-format bare –public
Note: I have been reporting an internal error of 500HTTP. Later, I saw from Google that someone reported the same error as me. It turns out that there is an ‘L’ missing in the controller file of hosts.
Viewing the Mirror List
[root@controller~]# openstack image list
The Glance service is set up
Reference links: docs.openstack.org/keystone/pi…
Docs.openstack.org/glance/pike…
This article uses the article synchronization assistant to synchronize