OpenStack Core Guide

The core of OpenStack:

The core is computing, networking, and storage, and everything revolves around the virtual machine as the main body.

OpenStack Modules:

Nova: Managing the lifecycle of a VM is the core service of OpenStack.

Neutron: Responsible for creating L2, L3 networks, providing virtual network and physical network connectivity to VMS, is the most difficult part of OpenStack.

Glance: Manages the VM boot image and is called by Nova.

Cinder: Provides storage services for VMs and provides volume for VMs.

Swift: Provides object storage services that overlap with cinder seemingly functionally.

Keystone: Provides authentication and rights management for all OpenStack services.

Ceilometer: Provides monitoring and metering services for OpenStack, providing data for alarms, statistics, or billing.

Horizon: Most of the above components are API calls, and Horizon provides OpenStack users with a Web self-service portal, which is the console of OpenStack.

OK, having done a Java development understanding of Spring Framework MicroServices is a great help in learning about OpenStack behind, because it has the same idea in terms of architecture design. Components are deployed separately and mated to each other, each logical component is called a node, just like Lego bricks need to be assembled, and important components need to consider high availability.

Each OpenStack component maintains its own data in the database:

OpenStack operations are divided into Web UI and command-line CLI two ways. The Web UI is horizon, and the command is the API to invoke the original service.

The advantage of the Web UI is that visual operations

The advantage of the CLI is that it is more functional and can be written to script.

General format of the command "module name Service Name parameter"

Module name is the above Nova, glance and other names;

Service name is the management of the object of the deletion and modification operations, generally divided into delete, list, show, create and update;

Parameters are not required, you typically need to enter an internal ID for the action object.

For example, the Image Management module glance Service API is:

Glance Image-create

Glance Image-delete

Glance Image-update

Glance Image-list

Glance Image-show

Keystone----------------------------------------------------------------------------------------------------------------- --

Keystone:

User: This is a good understanding for users using OpenStack.

Credentials: For the user authentication method, more diverse, have Username/password way, token way, API key and other ways.

Authentication:user took all of his credentials to access OpenStack, requiring authentication authentication.

Project: The entire OpenStack resource is quarantined as a non-pass project, and the user must be mounted on project to make sense. There are many-to-many between user and project.

Role: As with role in Linux, assigning 1 or more role to each user determines what permissions the user has.

Token: Like most HTTP services, token is an access credential that is acquired after a user's authentication with a valid duration, in lieu of the transmission of sensitive information such as a user's password on the network.

Various core components of Service:openstack (Nova, Cinder, Swift, Glance, neutron, etc.)

Endpoint:service is called by the outside world API, these open APIs are called EndPoint.

The above user, Credentials, authentication can be understood as common software development authentication system, role and project belong to the category of decentralized domain, token is the category of network security, Service and endpoint are protected access objects that can be understood as permission, and each service is configured with endpoint and role mappings.

PS: There is a configuration file to be aware of, each service has a/etc/{servicename}/policy.json, which is in JSON configuration of endpoint and role mapping

Keystone----------------------------------------------------------------------------------------------------------------- --

Glance-------------------------------------------------------------------------------------------------------------------

Glance: Management of the image, the management object is images.

Fortunately I am familiar with Docker, so the concept of mirroring here is not unfamiliar, and the image in Docker is the same function.

Services include:

1 snapshot The instance to generate a mirror image

2 providing storage services to image

3 restful ways to provide APIs for images related operations

The bottom of the glance is split into registry and backend, where registry with the metadata of the database management images, backend really stores images content (configured in/etc/glance/glance-api.conf).

Fault analysis of glance go and see the logs in/opt/stack/logs/.

Glance-------------------------------------------------------------------------------------------------------------------