Stein 오픈스택 클라우드 분석(1) - 대시보드 구성 및 사용자, 프로젝트 생성
blog post
이번 포스트부터 기존에 구축한 오픈스택 서비스를 활용하고 분석하는 과정에 집중하고자 합니다. 그 첫번째 포스팅으로 이번 포스트에서는 대시보드 기본 구성에 대해 알아보고 간단하게 사용자, 프로젝트 등을 생성해 보도록 하겠습니다. 또 실제로 오픈스택 호스트 시스템에는 어떻게 기록되는지도 살펴보도록 하겠습니다.
오픈스택 대시보드에서 메뉴 영역은 아래와 같이 크게 3 부분으로 나누어 볼 수 있습니다.
![](https://blog.kakaocdn.net/dn/de0qCf/btqBWrgnfJ3/Cime4dGm9IqyoLh9EXPPQK/img.png)
1. 주요 메뉴: 크게 "프로젝트", "관리", "인증" 메뉴로 구성되어 있습니다. 사용자 역할에 따라 해당 메뉴 세부 구성은 조금씩 다릅니다. 특히 "관리" 메뉴의 경우, 관리자 권한이 있는 사용자에 한하여 접근이 허용됩니다.
2. 도메인 메뉴: 도메인 혹은 프로젝트를 변경할 수 있습니다.
3. 설정 메뉴: 사용자 별 설정 혹은 다른 계정으로 변경 등을 수행할 수 있습니다.
오픈스택 클라우드 서버를 구축하는 과정에서 Keystone 인증 서비스가 사용자, 프로젝트, 엔드포인트 등을 관리한다고 했습니다. 대시보드를 사용하면 이와 관련하여 일부 기능을 다룰 수 있습니다. 물론 인증 서비스이기 때문에 새로 생성하거나 수정하는 작업의 경우 대부분 admin 계정으로 진행합니다.
admin 계정으로 로그인 후 메뉴-> 인증-> 프로젝트 에 보면 Keyston 인증 서비스 구축 과정에서 생성한 2개의 프로젝트를 볼 수 있습니다.
![](https://blog.kakaocdn.net/dn/bZjBqK/btqBWDHBKaG/mLYFiQ6g81ajUU4Rb7dhR0/img.png)
다음과 같이 하나의 프로젝트를 생성해 보겠습니다. 현재 프로젝트 그룹이 없고 멤버도 오픈스택 기본 서비스를 제외하면 실제 최종 사용자는 아직 없는 상태이므로 이름만 작성하고 생성해 봅니다.
![](https://blog.kakaocdn.net/dn/bFQIz7/btqBWDAQsfX/jjSGniCku15omPnZUWF0zk/img.png)
생성된 프로젝트에 컴퓨팅에 필요한 자원 할당량을 조절하여 할당할 수 있습니다(물론 VM, 가상네트워크 등이 생성되기 전까지 실제 물리 자원이 사용되지는 않습니다) 프로젝트를 생성하면 기본적으로 자원이 할당됩니다. 메모리, CPU, 디스크는 물론, 네트워크, 서브넷, 심지어 인스턴스의 수 까지 조절할 수 있습니다.
생성된 프로젝트에서 "멤버 관리" 버튼 옆 화살표 버튼을 클릭하면 아래와 같이 할당량을 편집할 수 있습니다.
![](https://blog.kakaocdn.net/dn/2QhON/btqBS5lvs5N/5ovEw2KSdyYxyzf1lRavVk/img.png)
이번 포스팅에서 자원 할당량은 별도로 편집하지 않겠습니다.
다음으로 사용자도 생성해 보도록 하겠습니다.
메뉴-> 인증-> 사용자로 이동 후 사용자 생성을 클릭하여 아래와 같이 새로운 사용자에 대한 정보를 입력합니다. 이 때 아래 항목에서 최초 프로젝트는 방금 생성한 프로젝트로, 역할은 member로 지정해 줍니다.
![](https://blog.kakaocdn.net/dn/bj1lMA/btqBUz0LTgr/fMG82Aukrpk6ufDtlLIxD0/img.png)
새로운 사용자가 추가된 것을 볼 수 있습니다.
이제 오른쪽 상단 사용자 설정 메뉴를 통해 로그아웃 하고 방금 생성한 사용자로 로그인 해 보도록 하겠습니다. (물론 도메인은 별도로 생성하지 않았으므로 default 로 동일합니다)
앞서 말씀드린 것과 같이 방금 생성한 사용자의 경우, 역할이 admin이 아닌 단순 member이기 때문에 메뉴에서 일부 기능을 사용할 수 없는 것을 볼 수 있습니다.
물론 앞서 대시보드에서 진행한 과정은 전부 CLI로 직접 생성할 수도 있습니다. 본 포스팅에서는 생성하는 과정은 생략하고 오픈스택 내부에서 어떻게 정보가 관리되는지 확인해 보겠습니다.
우선 앞서 진행한 대로 Project 리스트 명령을 통해 새로운 프로젝트가 생성되었음을 확인할 수 있습니다. 도메인 정보가 함께 저장되는 것을 확인할 수 있습니다.
[root@Controller ~]# openstack project list
+----------------------------------+-------------+
| ID | Name |
+----------------------------------+-------------+
| 8d3e3541755f454f84dafacd37b4303c | service |
| 9626ec30dfd74a1488e67b23aa19fa01 | admin |
| e725a918191b4b649023644c006376b1 | New_Project |
+----------------------------------+-------------+
[root@Controller ~]# openstack project show New_Project
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | default |
| enabled | True |
| id | e725a918191b4b649023644c006376b1 |
| is_domain | False |
| name | New_Project |
| parent_id | default |
| tags | [] |
+-------------+----------------------------------+
다음으로 방금 생성한 user1에 대한 정보도 보겠습니다.
[root@Controller ~]# openstack user list
+----------------------------------+-----------+
| ID | Name |
+----------------------------------+-----------+
| 4250b123569f460d84061fd3c7ae476e | neutron |
| 5320950663e34daf8d22fa2e5b7e696f | user1 |
| 90688075098e4e04930667c66d606cc1 | glance |
| 9a1b638e82254589984bfe54ab5d60fd | cinder |
| c738d0412121495eaf80bece7a859a3d | admin |
| c7957aec30f04e199d2073fed5865a55 | nova |
| f544d0d1e5e947ea984960f3c5e924b1 | placement |
+----------------------------------+-----------+
[root@Controller ~]# openstack user show user1
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| default_project_id | e725a918191b4b649023644c006376b1 |
| description | user1 |
| domain_id | default |
| enabled | True |
| id | 5320950663e34daf8d22fa2e5b7e696f |
| name | user1 |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
보시는 것과 같이 default_project_id 필드에 프로젝트 id (e725...)가 함께 저장된 것을 볼 수 있습니다.
그런데 분명히 user1을 생성할 때 role 정보를 함께 지정했는데, 보이질 않습니다.
role 정보는 role 명령을 통해서 확인할 수 있습니다.
[root@Controller ~]# openstack role assignment list -c Role -c User -c Project
+----------------------------------+----------------------------------+----------------------------------+
| Role | User | Project |
+----------------------------------+----------------------------------+----------------------------------+
| bf43c07517c1485bb21257bf3d5fb649 | 4250b123569f460d84061fd3c7ae476e | 8d3e3541755f454f84dafacd37b4303c |
| 05472005df1740b684bd8d3632c8f878 | 5320950663e34daf8d22fa2e5b7e696f | e725a918191b4b649023644c006376b1 |
| bf43c07517c1485bb21257bf3d5fb649 | 90688075098e4e04930667c66d606cc1 | 8d3e3541755f454f84dafacd37b4303c |
| bf43c07517c1485bb21257bf3d5fb649 | 9a1b638e82254589984bfe54ab5d60fd | 8d3e3541755f454f84dafacd37b4303c |
| bf43c07517c1485bb21257bf3d5fb649 | c738d0412121495eaf80bece7a859a3d | 9626ec30dfd74a1488e67b23aa19fa01 |
| bf43c07517c1485bb21257bf3d5fb649 | c7957aec30f04e199d2073fed5865a55 | 8d3e3541755f454f84dafacd37b4303c |
| bf43c07517c1485bb21257bf3d5fb649 | f544d0d1e5e947ea984960f3c5e924b1 | 8d3e3541755f454f84dafacd37b4303c |
| bf43c07517c1485bb21257bf3d5fb649 | c738d0412121495eaf80bece7a859a3d | |
+----------------------------------+----------------------------------+----------------------------------+
[root@Controller ~]# openstack user show 5320950663e34daf8d22fa2e5b7e696f
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| default_project_id | e725a918191b4b649023644c006376b1 |
| description | user1 |
| domain_id | default |
| enabled | True |
| id | 5320950663e34daf8d22fa2e5b7e696f |
| name | user1 |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
위와 같이 오픈스택 role 테이블 정보를 확인하면 Proejct 필드에 우리가 방금 생성한 New_Project의 id (e725...)가 보입니다. 해당 프로젝트에 속한 User ID를 통해 사용자를 확인해본 결과, 해당 유저가 user1임을 확인할 수 있습니다.
특정 사용자가 어떤 역할을 가진 사용자인지 확인할 때 이런식으로 접근하면 됩니다.
여기까지 간단하게 프로젝트와 사용자를 생성하고 CLI를 통해 정보를 찾는 방법을 살펴보았습니다. 앞으로도 이런식으로 오픈스택 대시보드와 CLI를 연계하여 활용하는 방법을 계속 공유해 가도록 하겠습니다.
'Cloud > Private Cloud Analysis' 카테고리의 다른 글
Stein 오픈스택 클라우드 분석(7) - 가상머신의 이더넷 인터페이스, mac & ip 주소 할당 과정 (0) | 2020.02.18 |
---|---|
Stein 오픈스택 클라우드 분석(6) - 오픈스택 시스템 내부에서 이미지와 가상머신을 생성하고 관리하는 방법 (0) | 2020.02.14 |
Stein 오픈스택 클라우드 분석(5) - 가상머신 이미지 업로드부터 인스턴스 생성까지 (0) | 2020.02.14 |
Stein 오픈스택 클라우드 분석(4) - 호스트 시스템에서의 가상 네트워크 구조 분석 (0) | 2020.02.13 |
Stein 오픈스택 클라우드 분석(3) - 외부&내부 네트워크, 서브넷, 라우터 생성 (0) | 2020.02.12 |
Stein 오픈스택 클라우드 분석(2) - 호스트 네트워크 인터페이스 아키텍처 (0) | 2020.02.12 |
[오픈스택 클라우드 개념] 컴퓨트 서비스(Nova) (0) | 2020.01.31 |
[오픈스택 클라우드 개념] 이미지 서비스(Glance)와 지원 이미지 포맷 (0) | 2020.01.29 |
[오픈스택 클라우드 개념] 인증 서비스(Keystone) (0) | 2020.01.28 |
[neutron] cli로 맥주소, ip가 지정된 포트 생성, 수정, 제거 (0) | 2017.02.28 |