雲計算與openstack學習（六）

理解 Keystone 核心概念 

作爲 OpenStack 的基礎支持服務，Keystone 做下面這幾件事情：

1. 管理用戶及其權限

2. 維護 OpenStack Services 的 Endpoint

3. Authentication（認證）和 Authorization（鑑權）

學習 Keystone，得理解下面這些概念：

User

User 指代任何使用 OpenStack 的實體，可以是真正的用戶，其他系統或者服務。

當 User 請求訪問 OpenStack 時，Keystone 會對其進行驗證。

Horizon 在 Identity->Users 管理 User

除了 admin 和 demo，OpenStack 也爲 nova、cinder、glance、neutron 服務創建了相應的 User。 admin 也可以管理這些 User。

Credentials

Credentials 是 User 用來證明自己身份的信息，可以是： 1. 用戶名/密碼 2. Token 3. API Key 4. 其他高級方式

Authentication

Authentication 是 Keystone 驗證 User 身份的過程。

User 訪問 OpenStack 時向 Keystone 提交用戶名和密碼形式的 Credentials，Keystone 驗證通過後會給 User 簽發一個 Token 作爲後續訪問的 Credential。

Token

Token 是由數字和字母組成的字符串，User 成功 Authentication 後由 Keystone 分配給 User。

1. Token 用做訪問 Service 的 Credential

2. Service 會通過 Keystone 驗證 Token 的有效性

3. Token 的有效期默認是 24 小時

Project

Project 用於將 OpenStack 的資源（計算、存儲和網絡）進行分組和隔離。 根據 OpenStack 服務的對象不同，Project 可以是一個客戶（公有云，也叫租戶）、部門或者項目組（私有云）。

這裏請注意：

1. 資源的所有權是屬於 Project 的，而不是 User。

2. 在 OpenStack 的界面和文檔中，Tenant / Project / Account 這幾個術語是通用的，但長期看會傾向使用 Project

3. 每個 User（包括 admin）必須掛在 Project 裏才能訪問該 Project 的資源。 一個User可以屬於多個 Project。

4. admin 相當於 root 用戶，具有最高權限

Horizon 在 Identity->Projects 中管理 Project

通過 Manage Members 將 User 添加到 Project 中

Service

OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。

每個 Service 都會提供若干個 Endpoint，User 通過 Endpoint 訪問資源和執行操作。

Endpoint

Endpoint 是一個網絡上可訪問的地址，通常是一個 URL。 Service 通過 Endpoint 暴露自己的 API。 Keystone 負責管理和維護每個 Service 的 Endpoint。

可以使用下面的命令來查看 Endpoint。

root@devstack-controller:~# source devstack/openrc admin admin 

root@devstack-controller:~# openstack catalog list

Role

安全包含兩部分：Authentication（認證）和 Authorization（鑑權） Authentication 解決的是“你是誰？”的問題 Authorization 解決的是“你能幹什麼？”的問題

Keystone 是藉助 Role 來實現 Authorization 的：

1. Keystone定義Role

2. 可以爲 User 分配一個或多個 Role Horizon 的菜單爲 Identity->Project->Manage Members

3. Service 決定每個 Role 能做什麼事情 Service 通過各自的 policy.json 文件對 Role 進行訪問控制。 下面是 Nova 服務 /etc/nova/policy.json 中的示例

6. 

上面配置的含義是：對於 create、attach_network 和 attach_volume 操作，任何Role的 User 都可以執行； 但只有 admin 這個 Role 的 User 才能執行 forced_host 操作。

OpenStack 默認配置只區分 admin 和非 admin Role。 如果需要對特定的 Role 進行授

通過例子學習 Keystone 

上一節介紹了 Keystone 的核心概念。
本節我們通過“查詢可用 p_w_picpath”這個實際操作讓大家對這些概念建立更加感性的認識。 

User admin 要查看 Project 中的 p_w_picpath 

第 1 步 登錄

當點擊時，OpenStack 內部發生了哪些事情？請看下面 

Token 中包含了 User 的 Role 信息 

第 2 步 顯示操作界面

請注意，頂部顯示 admin 可訪問的  Project 爲 “admin” 和 “demo”。 其實在此之前發生了一些事情： 

同時，admin 可以訪問 Intance, Volume, Image 等服務 

這是因爲 admin 已經從 Keystone 拿到了各 Service 的 Endpoints 

第 3 步 顯示 p_w_picpath 列表

點擊 “Images”，會顯示 p_w_picpath 列表 

背後發生了這些事： 

首先，admin 將請求發送到 Glance 的 Endpoint 

Glance 向 Keystone 詢問 admin 身份的有效性。 

接下來 Glance 會查看 /etc/glance/policy.json。 判斷 admin 是否有查看 p_w_picpath 的權限 

權限判定通過，Glance 將 p_w_picpath 列表發給 admin。 

Troubleshoot

OpenStack 排查問題的方法主要是通過日誌。 每個 Service 都有自己的日誌文件。 

Keystone 主要有兩個日誌： keystone.log 和 keystone_access.log 保存在 /var/log/apache2/ 目錄裏。 

devstack 的 screen 窗口已經幫我們打開了這兩個日誌。 可以直接查看： 

如果需要得到最詳細的日誌信息，可以在 /etc/keystone/keystone.conf 中打開 debug 選項 

在非 devstack 安裝中，日誌可能在 /var/log/keystone/ 目錄裏。

理解 Glance 

OpenStack 由 Glance 提供 Image 服務。

理解 Image

要理解 Image Service 先得搞清楚什麼是 Image 以及爲什麼要用 Image？ 

在傳統 IT 環境下，安裝一個系統是要麼從安裝 CD 從頭安裝，要麼用 Ghost 等克隆工具恢復。這兩種方式有如下幾個問題： 

1. 如果要安裝的系統多了效率就很低

2. 時間長，工作量大

3. 安裝完還要進行手工配置，比如安裝其他的軟件，設置 IP 等

4. 備份和恢復系統不靈活

雲環境下需要更高效的解決方案，這就是 Image。 Image 是一個模板，裏面包含了基本的操作系統和其他的軟件。 

舉例來說，有家公司需要爲每位員工配置一套辦公用的系統，一般需要一個 Win7 系統再加 MS office 軟件。 OpenStack 是這麼玩的： 

1. 先手工安裝好這麼一個虛機

2. 然後對虛機執行 snapshot，這樣就得到了一個 p_w_picpath

3. 當有新員工入職需要辦公環境時，立馬啓動一個或多個該 p_w_picpath 的 instance（虛機）就可以了

在這個過程中，第 1 步跟傳統方式類似，需要手工操作和一定時間。
但第 2、3 步非常快，全自動化，一般都是秒級別。 

而且 2、3 步可以循環做。 比如公司新上了一套 OA 系統，每個員工的 PC 上都得有客戶端軟件。 那麼可以在某個員工的虛機中手工安裝好 OA 客戶端，然後執行 snapshot ，得到新的 p_w_picpath，以後就直接使用新 p_w_picpath 創建虛機就可以了。 

另外，snapshot 還有備份的作用，能夠非常方便的恢復系統。 

理解 Image Service

Image Service 的功能是管理 Image，讓用戶能夠發現、獲取和保存 Image。 

在 OpenStack 中，提供 Image Service 的是 Glance，其具體功能如下： 

1. 提供 REST API 讓用戶能夠查詢和獲取 p_w_picpath 的元數據和 p_w_picpath 本身

2. 支持多種方式存儲 p_w_picpath，包括普通的文件系統、Swift、Amazon S3 等

3. 對 Instance 執行 Snapshot 創建新的 p_w_picpath

Glance 架構

上面是 Glance 的架構圖 

glance-api

glance-api 是系統後臺運行的服務進程。 對外提供 REST API，響應 p_w_picpath 查詢、獲取和存儲的調用。 

glance-api 不會真正處理請求。 如果是與 p_w_picpath metadata（元數據）相關的操作，glance-api 會把請求轉發給 glance-registry； 如果是與 p_w_picpath 自身存取相關的操作，glance-api 會把請求轉發給該 p_w_picpath 的 store backend。 

在控制節點上可以查看 glance-api 進程 

glance-registry

glance-registry 是系統後臺運行的服務進程。 負責處理和存取 p_w_picpath 的 metadata，例如 p_w_picpath 的大小和類型。 

在控制節點上可以查看 glance-registry 進程 

Glance 支持多種格式的 p_w_picpath，包括 

Database

Image 的 metadata 會保持到 database 中，默認是 MySQL。 在控制節點上可以查看 glance 的 database 信息 

Store backend

Glance 自己並不存儲 p_w_picpath。 真正的 p_w_picpath 是存放在 backend 中的。 Glance 支持多種 backend，包括 

1. A directory on a local file system（這是默認配置）

2. GridFS

3.  Ceph RBD

4. Amazon S3

5. Sheepdog

6. OpenStack Block Storage (Cinder)

7. OpenStack Object Storage (Swift)

8. VMware ESX

具體使用哪種 backend，是在 /etc/glance/glance-api.conf 中配置的在我們的 devstack 環境中，p_w_picpath 存放在控制節點本地目錄 /opt/stack/data/glance/p_w_picpaths/ 中 

其他 backend 的配置可參考http://docs.openstack.org/liberty/config-reference/content/configuring-p_w_picpath-service-backends.html 

查看目前已經存在的 p_w_picpath 

查看保存目錄 

每個 p_w_picpath 在目錄下都對應有一個文件，文件以 p_w_picpath 的 ID 命名。