이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

이 페이지의 일반 화면으로 돌아가기.

Cloudforet 개발자 문서 - 손쉬운 멀티 클라우드 관리를 위한 안내서

Cloudforet 사용자와 오픈소스 개발자들을 위한 개발자 문서 및 상세 사용 가이드 페이지입니다.
cloudforet ecosystem

1 - 소개

Introducing Cloudforet Project

1.1 - Integrations

Supported Technologies

Overview

SpaceONE은 Plugin Architecture 기반으로 개발되어, 각각의 Core Service를 지원하는 수많은 Eco System을 가지고 있습니다. 아래의 리스트에 포함되지 않은 기술들이 플러그인으로서 지원되야 할 경우, 문의 주세요.

Inventory

Inventory.Collector Type의 Plugin은 SpaceONE의 Asset 관리 기능의 핵심 역할을 수행합니다. 다양한 리전에 숨어있는 여러 Provider의 Cloud Resource를 자동으로 탐색하여 체계적으로 분류하여 줍니다.

AWS Cloud Service Plugin

수백개 이상의 AWS 에서 주로 사용되는 Cloud Resource를 자동으로 탐색하여 분류 합니다.

MS Azure Cloud Service Plugin

Azure에서 주로 사용되는 Cloud Resource를 자동으로 탐색하여 분류 합니다.

Google Cloud Service Plugin

Google Cloud 에서 주로 사용되는 Cloud Resource를 자동으로 탐색하여 분류 합니다.

Oracle Cloud Service Plugin

Oracle Cloud 에서 주로 사용되는 Cloud Resource를 자동으로 탐색하여 분류 합니다.

Alibaba Cloud Service Plugin

Alibaba Cloud 에서 주로 사용되는 Cloud Resource를 자동으로 탐색하여 분류 합니다.

Identity

Identity.auth Type의 Plugin은 SpaceONE User의 인증 관리 역할을 수행합니다. Plugin을 통해 사용자의 회사 계정과 SSO를 유지할 수 있습니다.

Google oAuth Identity Plugin

KeyCloak Identity Plugin

Monitoring

DataSource

AWS CloudWatch DataSource Plugin

Azure Monitor DataSource Plugin

Google Cloud Monitor DataSource Plugin


Webhook

AWS Simple Notification Webhook Plugin

Zabbix Webhook Plugin

Grafana Webhook Plugin


Notification

API Direct Connect Protocol Plugin

AWS SNS Protocol Plugin

Slack Protocol Plugin

Telegram Protocol Plugin

Email Protocol Plugin

Billing

Megazone Hyperbilling Billing Service

Power Scheduler

AWS Power Controller Plugin

Google Power Controller Plugin

1.2 - Release Notes

SpaceONE Release Notes
DateVersionSee Details
2023-03-061.11.0Version 1.11.0-korean
2022-11-281.10.4Version 1.10.4-korean
2022-11-071.10.3Version 1.10.3-korean
2022-10-111.10.2Version 1.10.2-korean
2022-09-011.10.1Version 1.10.1-korean
2022-07-221.10.0Version 1.10.0-korean
2022-05-251.9.7Version 1.9.7-korean
2022-05-021.9.6Version 1.9.6-korean
2022-04-051.9.4Version 1.9.4-korean
2022-03-101.9.3Version 1.9.3-korean
2022-02-091.9.1Version 1.9.1-korean
2021-12-301.9.0Version 1.9.0-korean
2021-12-141.8.7Version 1.8.7-korean
2021-11-051.8.5Version 1.8.5-korean
2021-10-051.8.4Version 1.8.4-korean
2021-09-141.8.3Version 1.8.3-korean
2021-08-311.8.2Version 1.8.2-korean
2021-08-171.8.1Version 1.8.1-korean
2021-07-211.7.4Version 1.7.4-korean
2021-06-291.7.3Version 1.7.3-korean
2021-05-271.7.2Version 1.7.2-korean
2021-04-211.6.7Version 1.6.7-korean
2021-03-091.6.4Version 1.6.4-korean
2021-02-171.6.2Version 1.6.2-korean
2021-01-251.6.1Version 1.6.1-korean
2020-12-291.5.3Version 1.5.3-korean
2020-11-231.5.1Version 1.5.1-korean
2020-9-281.3.2Version 1.3.2-korean

2 - 주요 컨셉

About Cloudforet Project

2.1 - Identity

Overall explanation of identity service

2.1.1 - Role Based Access Control

이 페이지에서는 SpaceONE의 사용자 역할기반 접근관리(RBAC)의 기본 개념에 대해 살펴봅니다.

How RBAC Works

SpaceONE의 RBAC(Role Based Access Control)을 통해 누가(who), **어떠한 조직(project or domain)**에 어떠한(what) 접근을 할 수 있는지를 정의 합니다.

예를 들어, Project Admin Role은 지정된 Project 내의 모든 자원을 조회(Read) 몇 변경(Update/Delete)할 수 있습니다. Domain Viewer Role은 지정된 Domain 내의 모든 자원을 조회(Read)할 수 있습니다. 여기서 자원이란, SpaceONE 내에 생성한 사용자, Project/Project Group 및 개별 클라우드 리소스까지 모든것을 포함 합니다.

모든 사용자는 하나 이상의 역할을 가지고 있으며, 이것은 직접 역할을 부여하거나 프로젝트 내에서 상속될 수도 있습니다. 이를 통해 복잡한 프로젝트 관계 속에서 사용자의 역할관리를 손쉽게 관리할 수 있습니다.

Role은 Policy를 통해 대상이 지정된 자원에 대해 어떠한 Action을 할 수 있는지 정의 합니다. 또한 Role은 각각의 사용자에 바인딩 됩니다. 아래의 다이어그램은 RBAC를 구성하는 사용자와 Role 및 Project 간의 관계를 나타냅니다.

이러한 역할 관리 모델은 크게 3가지 구성 요소로 구분 됩니다.

  • Role. 각 사용자별 부여할 수 있는 접근권한 정책의 모음 입니다. 모든 Role은 하나의 Policy를 반드시 필요로 합니다. 더 상세한 설명은 Understanding Role를 참고해주세요

  • Project. 권한이 적용되는 프로젝트 혹은 프로젝트 그룹 입니다.

  • User. 사용자는 콘솔에 로그인하여 UI를 이용하는 사용자와 API 사용자, SYSTEM 사용자를 모두 포함 합니다. 각 사용자들은 RoleBinding 절차를 통해 복수의 Role과 연결 됩니다. 이를 통해 적절한 권한을 받아 SpaceONE의 다양한 자원들에 접근이 가능합니다.

Basic Concepts

사용자가 조직 내의 자원에 접근 하고자 할때, 관리자는 각 사용자에게 대상 프로젝트 혹은 도메인의 역할(Role)을 부여 합니다. SpaceONE Identity Service는 각 사용자에게 부여된 Role/Policy를 확인하여 각 사용자가 자원에 접근할 수 있도록 합니다.

Resource

만약 사용자가 특정한 SpaceONE 프로젝트 내의 자원에 접근 하고자 한다면, 해당 사용자에게 적합한 Role을 부여한 후 대상 프로젝트에 멤버로 추가하여 접근 가능할게 할 수 있습니다. 이러한 자원의 예는 Server, Project, Alert 입니다.

SpaceONE내에서 관리되는 자원들을 각 서비스별로 편리하게 이용할 수 있게 하기 위해, 사전에 정의된 Role/Policy를 게시하고 있습니다. 회사 내부적으로 자체 접근범위를 정의하고 싶을 경우 Custom Policy/Custom Role을 생성하여 내부 조직에 적용할 수도 있습니다.

이것에 대한 상세할 설명은 Understanding Role 를 참고 해 주세요.

Policy

정책은 permission의 모음 입니다. permission에는 스페이스원의 각 자원에 대해 허용되는 접근 범위가 정의 되어 있습니다. 정책은 Role을 통해, 각 사용자에게 부여될 수 있습니다. 정책은 Marketplace에 게시하여 다른사용자들이 사용할 수도 있고, 특정 도메인만을 위해 Private 하게 게시될 수도 있습니다.

이 Permission은 아래와 같은 형태로 표현됩니다. {service}.{resource}.{verb} 예를 들자면 inventory.Server.list 와 같은 형태 입니다.

Permission은 SpaceONE API Method에 대응 되기도 합니다. 이것은 각각의 SpaceONE내의 microservice 각각의 노출된 API method과 긴밀하게 연관 되어 있기 때문 입니다. 그러므로, API를 호출하는 사용자가 method를 호출시 대응하는 permission을 필요로 합니다.

예를 들어, Inventory 서비스의 Server 리스트를 보기 위해 inventory.Server.list를 호출 하고자 한다면 사용자는 대응되는 inventory.Server.list permission을 role에 포함하고 있어야 합니다.

Permission은 사용자에게 직접적으로 부여할 수 없습니다. 대신에 적절한 permission의 모음을 Policy로 정의하여, 사용자에게 Role을 통해 할당할 수 있습니다. 자세한 설명은 Understanding Policy를 참고 해주세요.

Roles

Role은 접근 대상과 Policy의 조합으로 구성되어 있습니다. 사용자에게 Permission을 직접 부여할 수는 없고, Role의 형태로 부여할 수 있습니다. 또한, SpaceONE 내의 모든 자원들은 모두 Project 에 소속 되어 있습니다. 각 사용자들의 자원 접근 대상을 DOMAIN, PROJECT 으로 구분해서 관리 할 수 있습니다.

예를 들어, Domain에 대한 전체 관리자를 위해 Domain Admin Role 를 제공하고, Alert Manager의 이벤트 관리를 위해 Alert Manager Operator Role 을 제공 합니다.

Members

SpaceONE 내에서 관리하는 클라우드 자원들은 모두 프로젝트 단위로 관리 됩니다. 그러므로, 각 사용자에게 역할을 부여하고 프로젝트 멤버로 추가하여, 자원에 접근 할 수 있도록 제어할 수 있습니다.

Role 타입에 따라 사용자는 도메인내의 전체 자원에 접근 하거나, 지정된 Project 내의 자원에 Access 할 수 있습니다.

  • Domain : 도메인내의 전체 자원에 접근 할 수 있습니다.
  • Project : 지정된 Project 내의 자원에 접근 할 수 있습니다.

Project 타입의 사용자는 특정 Project의 Member로 추가 됨으로서 해당 프로젝트 내의 자원에 접근이 가능 합니다.

Project Group의 Member로 추가하면, 하위 모든 프로젝트 자원에 접근할 수 있는 권한이 승계 됩니다.

Organization

SpaceONE내의 모든 자원들은 아래와 같은 조직 구조를 통한 계층적인 관리가 가능합니다.

모든 사용자는 조직에 연결(RoleBinding) 되는 방식으로 접근 대상을 지정 할 수 있습니다.

  • Domain : 가장 상위 레벨의 조직 입니다. 모든 프로젝트와 프로젝트 그룹을 포괄 합니다.
  • PROJECT GROUP : 복수의 Project를 통합하여 관리 할 수 있는 조직 입니다.
  • Projects : SpaceONE내의 가장 작은 조직 단위 입니다. 모든 클라우드의 자원들은 프로젝트에 소속 됩니다.

2.1.1.1 - Understanding Policy

이 페이지에서는 Policy에 대해 상세하게 살펴봅니다.

Policy

Policy는 SpaceONE 자원에 대해 특정한 동작을 수행할 수 있도록 정의된 permissions의 set 입니다. Permission은 Cloud Resource에 대해 관리할 수 있는 범위를 정의 합니다. 권한관리 체계에 대한 전반적인 설명은 Role Based Access Control을 참고 해주세요.

Policy Type

한번 정의된 Policy는 다른 도메인의 Role에서 사용할 수 있도록 공유 할 수 있습니다. 이것의 가능 여부에 따라 Policy는 두 가지 타입으로 구분 됩니다.

  • MANAGED : Repository 서비스에 Global하게 정의된 Policy로서, Policy를 전체 시스템 Admin이 직접 관리 하여 공유합니다. 대부분의 사용자들이 활용하기 편리한 공통 policy 입니다.
  • CUSTOM : 도메인별로 Permission을 자체 정의한 Policy를 사용할 수 있습니다. 각 도메인별로 세부적인 permission을 관리 하기에 유용합니다.

Policy는 Permission Scope에 따라 아래와 같이 구분 가능 합니다.

  • Basic : SpaceONE내의 모든 자원에 대해 전반적인 permission을 포함하고 있습니다.
  • Predefined : 특정한 서비스(alert manager, billing 등)에 대한 세분화된 permission을 포함 합니다.

Managed Policy

아래의 Policy는 SpaceONE 팀에 의해 관리되는 Managed Policy의 전체 리스트 입니다. 상세 Permission은 필요시 자동으로 업데이트 됩니다. Policy는 조직내의 주요 역할에 따라 분류하여 생성 하였습니다.

Policy TypePolicy NamePolicy IdPermission DescriptionReference
MANAGED-BasicDomain Admin Accesspolicy-managed-domain-admin
아래를 제외한 모든 권한을 가짐
Domain을 생성/삭제
api_type이 SYSTEM/NO_AUTH
DomainOwner를 관리(생성/변경/삭제)
플러그인 관리 identity.Auth Plugin 관리(변경)		policy-managed-domain-admin
MANAGED-BasicDomain Viewer Accesspolicy-managed-domain-viewerDomain Admin Access 권한중 읽기 권한policy-managed-domain-viewer
MANAGED-BasicProject Admin Accesspolicy-managed-project-adminDomain Admin Access Policy에서 아래 Permission 제외
Provider를 관리(생성/변경/조회/삭제)
Role/Policy를 관리(생성/변경/삭제)
플러그인 관리 inventory.Collector (생성/변경/삭제)
플러그인 관리 monitoring.DataSource (생성/변경/삭제)
플러그인 관리 notification.Protocol (생성/변경/삭제)		policy-managed-project-admin
MANAGED-BasicProject Viewer Accesspolicy-managed-project-viewerProject Admin Access Policy의 Permission중 읽기 권한policy-managed-project-viewer
MANAGED-PredefinedAlert Manager Full Accesspolicy-managed-alert-manager-full-accessAlert Manager에 대한 모든 접근 권한policy-managed-alert-manager-full-access

Custom Policy

도메인 자체적 으로 Policy를 관리 하고자 할 경우, Custom Policy 관리하기 문서를 참고 해 주세요.

2.1.1.2 - Understanding Role

이 페이지에서는 Role에 대해 상세하게 살펴봅니다.

Role structure

Role은 아래와 같이 자원에 대한 접근 범위를 지정하는 Role Type과 권한이 적용되는 조직(프로젝트 or 프로젝트 그룹)으로 구성 됩니다. 사용자는 RoleBinding을 통해 각 SpaceONE내에 접근할 수 있는 권한을 정의할 수 있습니다.

Role Example

Example: Alert Operator Role

---
results:
  - created_at: '2021-11-15T05:12:31.060Z'
    domain_id: domain-xxx
    name: Alert Manager Operator
    policies:
      - policy_id: policy-managed-alert-manager-operator
        policy_type: MANAGED
    role_id: role-f18c7d2a9398
    role_type: PROJECT
    tags: {}

Example : Domain Viewer Role

---
results:
- created_at: '2021-11-15T05:12:28.865Z'
  domain_id: domain-xxx
  name: Domain Viewer
  policies:
  - policy_id: policy-managed-domain-viewer
    policy_type: MANAGED
  role_id: role-242f9851eee7
  role_type: DOMAIN
  tags: {}

Role Type

Role Type은 도메인내의 접근 가능한 자원의 범위를 지정 합니다.

  • DOMAIN : Domain내의 모든 자원에 Access 가능 합니다.
  • PROJECT : Member로 추가된 Project내의 모든 자원에 Access 가능 합니다.

Project내의 Member로 추가하는 방법은 Project의 Member로 추가 를 참고 해 주세요.

Add Member

SpaceONE내의 모든 자원들은 아래와 같이 계층적으로 관리 됩니다. 도메인의 관리자는 각 Project에 Member를 추가하여 사용자를 프로젝트내의 자원에 Access 할 수 있도록 관리할 수 있습니다. 여러 Project에 대한 Access가 필요한 사용자의 경우는 상위 Project Group에 Member로 추가하여 하위 계층에 소속된 모든 Project에 대한 Access할 수 있습니다.
Project Group의 Member로 추가하는 방법은 Project Group의 Member로 추가를 참고 해주세요.

Role Hierarchy

사용자가 계층적인 Project 구조내에서 복합적인 Rolebinding을 가질 경우 Role은 아래와 같은 규칙으로 적용 됩니다.

예를 들어, 아래의 그림과 같이 stark@example.com 사용자가 상위 Project Group에 Project Admin Role로 Binding이 되어 있고, 하위 레벨의 프로젝트인 APAC 에 Project Viewer Role로 Binding되어 있는 경우 아래와 같은 방식으로 프로젝트별 Role이 적용 됩니다.

  • 직접 RoleBinding 하지 않은 하위 프로젝트/프로젝트 그룹에는 상위 프로젝트의 Role이 적용됨
  • 명시적으로 RoleBinding 한 하위 프로젝트에는 해당 Role이 적용됨(상위레벨의 Role을 Overwriting함)

Default Roles

모든 스페이스원 도메인은 생성시 Default Role 을 자동으로 포함합니다. 아래는 그 리스트 입니다.

NameRole TypeDescription
Domain AdminDOMAIN도메인 전체 Resource 를 조회/변경/삭제 할 수 있음
Domain ViewerDOMAIN도메인 전체 Resource를 조회할 수 있음
Project AdminPROJECT멤버로 추가된 프로젝트 전체 Resource 를 조회/변경/삭제 할 수 있음
Project ViewerPROJECT멤버로 추가된 프로젝트 전체 Resource 를 조회 할 수 있음
Alert Manager OperatorPROJECT멤버로 추가된 Project 전체 Resource 를 조회 할 수 있음, Alert Manager의 Alert 처리 권한을 가짐

Managing Roles

spacectl을 통해 도메인 자체적 으로 Role을 관리할 수 있습니다. Role 관리하기 문서를 참고 해 주세요.

3 - 설치 및 운영

Cloudforet System Administrator Guide

3.1 - Installation

This section describes how to install CloudForet.

3.1.1 - AWS

Cloudforet을 AWS에 설치하는 가이드 입니다.

Cloudforet Helm Charts

Cloudforet 1.12의 Helm Chart 입니다.

준비사항

  • Kubernetes 1.21+
  • Helm 3.2.0+
  • Service Domain & SSL Certificate (optional)
    • Console: console.example.com
    • REST API: *.api.example.com
    • gRPC API: *.grpc.example.com
    • Webhook: webhook.example.com
  • MongoDB 5.0+ (optional)

Cloudforet Architecture

Cloudforet Architecture

설치

아래의 단계들을 통해서 Cloudforet을 설치할 수 있습니다.

1) Helm Repository 추가

helm repo add cloudforet https://cloudforet-io.github.io/charts
helm repo update
helm search repo cloudforet

2) Namespaces 생성

kubectl create ns spaceone
kubectl create ns spaceone-plugin

만약 하나의 namespace만 사용하기를 원한다며, spaceone-plugin namespace는 생성하지 마세요.

3) Role and RoleBinding 생성

우선, rbac.yaml 파일을 다운로드 합니다.

wget https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/rbac.yaml -O rbac.yaml

그리고, 아래 명령어를 실행합니다.

kubectl apply -f rbac.yaml -n spaceone-plugin

or

kubectl apply -f https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/rbac.yaml -n spaceone-plugin

4) Cloudforet Chart로 설치하기

helm install cloudforet cloudforet/spaceone -n spaceone

아래 명령어를 실행한 뒤, pod의 상태를 체크하세요.

kubectl get pod -n spaceone

NAME                                       READY   STATUS             RESTARTS      AGE
board-64f468ccd6-v8wx4                     1/1     Running            0             4m16s
config-6748dc8cf9-4rbz7                    1/1     Running            0             4m14s
console-767d787489-wmhvp                   1/1     Running            0             4m15s
console-api-846867dc59-rst4k               2/2     Running            0             4m16s
console-api-v2-rest-79f8f6fb59-7zcb2       2/2     Running            0             4m16s
cost-analysis-5654566c95-rlpkz             1/1     Running            0             4m13s
cost-analysis-scheduler-69d77598f7-hh8qt   0/1     CrashLoopBackOff   3 (39s ago)   4m13s
cost-analysis-worker-68755f48bf-6vkfv      1/1     Running            0             4m15s
cost-analysis-worker-68755f48bf-7sj5j      1/1     Running            0             4m15s
cost-analysis-worker-68755f48bf-fd65m      1/1     Running            0             4m16s
cost-analysis-worker-68755f48bf-k6r99      1/1     Running            0             4m15s
dashboard-68f65776df-8s4lr                 1/1     Running            0             4m12s
file-manager-5555876d89-slqwg              1/1     Running            0             4m16s
identity-6455d6f4b7-bwgf7                  1/1     Running            0             4m14s
inventory-fc6585898-kjmwx                  1/1     Running            0             4m13s
inventory-scheduler-6dd9f6787f-k9sff       0/1     CrashLoopBackOff   4 (21s ago)   4m15s
inventory-worker-7f6d479d88-59lxs          1/1     Running            0             4m12s
mongodb-6b78c74d49-vjxsf                   1/1     Running            0             4m14s
monitoring-77d9bd8955-hv6vp                1/1     Running            0             4m15s
monitoring-rest-75cd56bc4f-wfh2m           2/2     Running            0             4m16s
monitoring-scheduler-858d876884-b67tc      0/1     Error              3 (33s ago)   4m12s
monitoring-worker-66b875cf75-9gkg9         1/1     Running            0             4m12s
notification-659c66cd4d-hxnwz              1/1     Running            0             4m13s
notification-scheduler-6c9696f96-m9vlr     1/1     Running            0             4m14s
notification-worker-77865457c9-b4dl5       1/1     Running            0             4m16s
plugin-558f9c7b9-r6zw7                     1/1     Running            0             4m13s
plugin-scheduler-695b869bc-d9zch           0/1     Error              4 (59s ago)   4m15s
plugin-worker-5f674c49df-qldw9             1/1     Running            0             4m16s
redis-566869f55-zznmt                      1/1     Running            0             4m16s
repository-8659578dfd-wsl97                1/1     Running            0             4m14s
secret-69985cfb7f-ds52j                    1/1     Running            0             4m12s
statistics-98fc4c955-9xtbp                 1/1     Running            0             4m16s
statistics-scheduler-5b6646d666-jwhdw      0/1     CrashLoopBackOff   3 (27s ago)   4m13s
statistics-worker-5f9994d85d-ftpwf         1/1     Running            0             4m12s
supervisor-scheduler-74c84646f5-rw4zf      2/2     Running            0             4m16s

Scheduler pod들은 CrashLoopBackOff 상태 이거나 Error상태 입니다. 아직 설정이 완료되지 않았기 때문입니다.

5) 구성 초기화

첫 번째로, initializer.yaml 파일을 다운로드 합니다.

wget https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/initializer.yaml -O initializer.yaml

그리고 아래 명령어로 실행합니다.

helm install cloudforet-initializer cloudforet/spaceone-initializer -n spaceone -f initializer.yaml

or

helm install cloudforet-initializer cloudforet/spaceone-initializer -n spaceone -f https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/initializer.yaml

Initializer에 대한 자세한 설명은, 다음을 참고하세요. spaceone-initializer

6) Helm Value값 들을 설정하고 Chart Upgrade 하기

초기화과 완료되면, initializer pod의 로그에서 시스템 token 값을 얻을 수 있습니다.

# check pod name
kubectl logs initialize-spaceone-xxxx-xxxxx -n spaceone

...
TASK [Print Admin API Key] *********************************************************************************************
"{TOKEN}"

FINISHED [ ok=23, skipped=0 ] ******************************************************************************************

FINISH SPACEONE INITIALIZE

일단 이 TOKEN 값을 복사고, values.yaml 파일을 만들어서 TOKEN에 붙여 넣습니다.

console:
  production_json:
    # If you don't have a service domain, you refer to the following 'No Domain & IP Access' example.
    CONSOLE_API:
      ENDPOINT: https://console.api.example.com       # Change the endpoint
    CONSOLE_API_V2:
      ENDPOINT: https://console-v2.api.example.com    # Change the endpoint

global:
  shared_conf:
    TOKEN: '{TOKEN}'                                    # Change the system token

더 많은 advanced 설정들은 아래 링크드를 참고하세요.

values.yaml파일을 수정하고 helm chart를 upgrade합니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

7) Pods 상태 확인

kubectl get pod -n spaceone

만약, 모든 pod들이 Running 상태이면 설정이 완료된 것입니다.

8) Ingress와 AWS Load Balancer

Kubernetes에서 Ingress는 cluster의 Services에 access할 수 있도록 부하가 분산된 외부 IP 주소를 제공하는 API 객체입니다. 계층 7 (HTTP/HTTPS) 리버스 프록시 역할을 하며 요청된 호스트 및 URL 경로를 기반으로 트래픽을 다른 서비스로 라우팅할 수 있습니다.

AWS EKS에서는 ingress를 생성할 때 애플리케이션 트래픽을 로드 밸런싱하는 AWS Application Load Balancer(ALB)가 프로비저닝 됩니다.
자세한 내용은 AWS에 Application Load Balancer란 무엇인가요? 및 Kubernetes 설명서의 ingress를 참조하세요.

선행작업

AWS Load Balancer Controller 설치
AWS Load Balancer Controller는 Kubernetes Cluster에서 ELB(Elastic Load Balancers)를 관리하는데 도움을 주는 컨트롤러입니다. Ingress resource는 Application Load Balancer로, Service resource는 Network Load Balancer로 Provisioning 합니다. 설치 방법은 환경에 따라 다를 수 있으니 아래 공식 가이드 문서를 참고하세요.

Cloudforet ingress 설정 방법

1) Ingress 종류
Cloudforet에서는 총 2개의 파일을 통해서 3개의 ingress를 프로비저닝 합니다.

  • Console : 도메인에 접속하기 위한 ingress
  • REST API : API 서비스를 위한 ingress
    • console-api
    • console-api-v2

2) Console ingress
Console에 접속하기 위한 ingress를 아래와 같이 설정합니다.

cat <<EOF> cloudforet-console-ingress.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-ingress
  namespace: spaceone
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-ingress # Caution!! Must be fewer than 32 characters.
spec:
  ingressClassName: alb
  defaultBackend:
    service:
      name: console
      port:
        number: 80
EOF

# Apply ingress
kubectl apply -f spaceone-console-ingress.yaml

해당 ingress를 apply하면 spaceone-console-ingress라는 이름으로 AWS Load Balancer에 프로비져닝 됩니다. HTTP(80 Port)를 사용하여 프로비져닝 된 DNS 이름을 통해서 접속 가능합니다.

3) REST API ingress
다음은 api 서비스를 위한 REST API ingress를 아래와 같이 설정합니다.

cat <<EOF> spaceone-rest-ingress.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-api-ingress
  namespace: spaceone
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-api-ingress # Caution!! Must be fewer than 32 characters.
spec:
  ingressClassName: alb
  defaultBackend:
    service:
      name: console-api
      port:
        number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-api-v2-ingress
  namespace: spaceone
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-api-v2-ingress
spec:
  ingressClassName: alb
  defaultBackend:
    service:
      name: console-api-v2-rest
      port:
        number: 80
EOF

# Apply ingress
kubectl apply -f spaceone-rest-ingress.yaml

REST API ingress는 2개의 ALB를 프로비저닝합니다. REST API의 DNS Name은 values.yaml파일에 console.CONSOLE_API.ENDPOINT, console.CONSOLE_API_V2.ENDPOINT로 각각 추가 되어야하기 때문에 반드시 저장해야 합니다.

4) DNS Name 확인
DNS 이름은 http://{ingress-name}-{random}.{region-code}.elb.amazoneaws.com 와 같이 생성됩니다. kubernetes에서 kucectl get ingress -n spaceone 명령를 통해서 확인 가능합니다.

kubectl get ingress -n spaceone

NAME                     CLASS   HOSTS   ADDRESS                                                                      PORTS   AGE
console-api-ingress      alb     *       spaceone-console-api-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com      80      15h
console-api-v2-ingress   alb     *       spaceone-console-api-v2-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com   80      15h
console-ingress          alb     *       spaceone-console-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com          80      15h

또는, AWS Console에서 확인 가능합니다. EC2 > Load balancer에서 아래 이미지와 같이 확인 할 수 있습니다.

spaceone-console-ingress-alb

5) DNS Name으로 접속
ingress가 모두 준비 되었다면 values.yaml 파일을 수정하고 pods를 재시작해서 console에 접속합니다.

console:
  production_json:
    # If you don't have a service domain, you refer to the following 'No Domain & IP Access' example.
    CONSOLE_API:
      ENDPOINT: http://spaceone-console-api-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com
    CONSOLE_API_V2:
      ENDPOINT: http://spaceone-console-api-v2-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com

준비된 values.yaml 파일을 적용 후 pods를 재시작 합니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

이제 spaceone-console-ingress 의 DNS Name으로 Cloudforet에 접속할 수 있습니다.

  • http://spaceone-console-ingress-xxxxxxxxxx.{region-code}.elb.amazonaws.com

Advanced ingress settings

SSL 인증서 등록 방법
SSL 통신을 위해서 ingress에 인증서를 등록하는 방법을 안내합니다. 인증서 등록을 위해한 2가지 방법이 있습니다. ACM(AWS Certificate Manager)를 이용하는 경우와 외부 인증서를 등록하는 방법입니다.

ACM 인증서를 ingress에 등록하는 방법
ACM을 통해서 인증서를 발급받은 경우라면 ingress에 간단히 acm arn을 등록하는 것으로 SSL 인증서 등록을 할 수 있습니다.

우선, ACM 인증서를 발급받는 방법은 AWS 공식 가이드 문서를 참고하세요.

발급받은 인증서를 등록하는 방법은 아래와 같습니다. 기존 ingress에서 SSL 통신을 위해 추가, 변경되는 옵션들을 확인합니다.

ingress에서 변경된 내용을 확인하세요.
ssl을 위한 다양한 설정이 추가, 변경됩니다. metadata.annotations 내용을 확인하세요.
그리고 spec.rules에서 ssl-redirect 및 spec.rules.host 등 추가된 내용들을 확인하세요.

  • spaceone-console-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-ingress
  namespace: spaceone
  annotations:
+   alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
+   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
-   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
+   alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:..."  # Change the certificate-arn
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-ingress # Caution!! Must be fewer than 32 characters.
spec:
  ingressClassName: alb
- defaultBackend:
-   service:
-     name: console
-     port:
-       number: 80
+ rules:
+   - http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: ssl-redirect
+               port:
+                 name: use-annotation
+   - host: "console.example.com"  # Change the hostname
+     http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: console 
+               port:
+                 number: 80
  • spaceone-rest-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-api-ingress
  namespace: spaceone
  annotations:
+   alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
+   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
-   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
+   alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:..."  # Change the certificate-arn
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-api-ingress # Caution!! Must be fewer than 32 characters.
spec:
  ingressClassName: alb
- defaultBackend:
-   service:
-     name: console-api
-     port:
-       number: 80
+ rules:
+   - http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: ssl-redirect
+               port:
+                 name: use-annotation
+   - host: "console.api.example.com"  # Change the hostname
+     http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: console-api
+               port:
+                 number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-api-v2-ingress
  namespace: spaceone
  annotations:
+   alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
+   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
-   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
+   alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:..."  # Change the certificate-arn
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-api-v2-ingress
spec:
  ingressClassName: alb
- defaultBackend:
-   service:
-     name: console-api-v2-rest
-     port:
-       number: 80
+ rules:
+   - http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: ssl-redirect
+               port:
+                 name: use-annotation
+   - host: "console-v2.api.example.com"  # Change the hostname
+     http:
+       paths:
+         - path: /*
+           pathType: ImplementationSpecific
+           backend:
+             service:
+               name: console-api-v2-rest
+               port:
+                 number: 80

변경된 내용을 kubectl 명령어를 통해서 반영하면 SSL 적용이 완료됩니다.

kubectl apply -f spaceone-console-ingress.yaml
kubectl apply -f spaceone-rest-ingress.yaml

SSL/TLS 인증서를 등록하는 방법
기존에 발급받은 외부 인증서가 있는 경우에도 인증서 등록이 가능합니다. 발급받은 인증서를 이용하여 Kubernetes secret 를 추가하고, 추가된 secret 이름을 ingress에 선언하는 것으로 등록이 가능합니다.

SSL/TLS 인증서를 Kubernetes secret으로 생성합니다. 방법은 2가지로 아래와 같습니다.

1. yaml file을 이용한 방법
아래 명령어를 통해서 yaml file로 secret을 추가할 수 있습니다.

kubectl apply -f <<EOF> tls-secret.yaml
apiVersion: v1
data:
  tls.crt: {your crt}   # crt
  tls.key: {your key}   # key
kind: Secret
metadata:
  name: tls-secret
  namespace: spaceone
type: kubernetes.io/tls
EOF

2. 파일이 있을 경우 명령어를 이용한 방법
crt와 key file이 있는 경우 다음의 명령어를 이용하여 secret을 생성할 수 있습니다.

kubectl create secret tls tlssecret --key tls.key --cert tls.crt

Ingress에 tls secret을 추가
등록된 secret 정보를 이용하여 ingress를 수정합니다.

ingress-nginx 설정
secret과 tls를 이용하는 방법에는 ingress-nginx를 활용한 설정 방법들이 필요할 수 있습니다. 자세한 내용은 다음 링크들를 참고하세요.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: console-ingress
  namespace: spaceone
  annotations:
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/load-balancer-name: spaceone-console-ingress # Caution!! Must be fewer than 32 characters.
spec:
  tls:
  - hosts:
      - console.example.com        # Change the hostname
    secretName: tlssecret          # Insert secret name
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: ssl-redirect
                port:
                  name: use-annotation
    - host: "console.example.com"  # Change the hostname
      http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: console 
                port:
                  number: 80

3.1.2 - On Premise

On Premise 환경에서 CloudForet를 설치하는 방법을 설명합니다.

on_premise

Prerequisites

Cloudforet 설치

Helm chart를 이용하여 Cloudforet을 설치하는 방법을 안내합니다. 관련 내용은 다음에서도 확인 가능합니다. https://github.com/cloudforet-io/charts

1. Add Helm Repository

helm repo add cloudforet https://cloudforet-io.github.io/charts 
helm repo update 
helm search repo

2. Create Namespaces

kubectl create ns spaceone 
kubectl create ns spaceone-plugin

namespace 생성 시 주의사항
하나의 namespace에서만 사용해야할 경우 spaceone-plugin namespace는 생성하지 않아도 됩니다.
Cloudforet의 namespace를 변경하는 경우 다음의 링크를 참고하시기 바랍니다. Change K8S Namespace

3. Create Role and RoleBinding

namespace를 합치지 않은 일반적이 상황에서는 supervisor가 spaceone namespace에서 spaceone-plugin namespace로 plugin을 배포하기 때문에, 아래와 같이 role, rolebinding이 필요합니다. 다음의 링크에서 내용을 확인하세요. https://github.com/cloudforet-io/charts/blob/master/examples/rbac.yaml

자세한 권한의 내용은 아래와 같습니다. 필요한 경우 해당 파일을 편집해서 권한을 지정하면 됩니다.

  • 파일 생성

    cat <<EOF> rbac.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: supervisor-plugin-control-role
  namespace: spaceone-plugin 
rules:
- apiGroups:
  - "*"
  resources:
  - replicaSets
  - pods
  - deployments
  - services
  - endpoints
  verbs:
  - get
  - list
  - watch
  - create
  - delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: supervisor-role-binding
  namespace: spaceone-plugin 
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: supervisor-plugin-control-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: spaceone
EOF

권한을 적용하려면 아래의 명령어로 반영하면 됩니다. namespace를 변경했을 경우 변경한 namespace를 입력합니다. (namespace에 주의합니다.)

kubectl apply -f rbac.yaml -n spaceone-plugin

4. Install

다음의 helm 명령어를 통해서 설치를 진행합니다.

helm install cloudforet cloudforet/spaceone -n spaceone

명령어를 입력하고 나면 spaceone namespace에서 아래와 같이 pod들이 올라오는 것을 확인 할 수 있습니다.

kubectl get pod -n spaceone

NAME                                       READY   STATUS             RESTARTS      AGE
board-64f468ccd6-v8wx4                     1/1     Running            0             4m16s
config-6748dc8cf9-4rbz7                    1/1     Running            0             4m14s
console-767d787489-wmhvp                   1/1     Running            0             4m15s
console-api-846867dc59-rst4k               2/2     Running            0             4m16s
console-api-v2-rest-79f8f6fb59-7zcb2       2/2     Running            0             4m16s
cost-analysis-5654566c95-rlpkz             1/1     Running            0             4m13s
cost-analysis-scheduler-69d77598f7-hh8qt   0/1     CrashLoopBackOff   3 (39s ago)   4m13s
cost-analysis-worker-68755f48bf-6vkfv      1/1     Running            0             4m15s
cost-analysis-worker-68755f48bf-7sj5j      1/1     Running            0             4m15s
cost-analysis-worker-68755f48bf-fd65m      1/1     Running            0             4m16s
cost-analysis-worker-68755f48bf-k6r99      1/1     Running            0             4m15s
dashboard-68f65776df-8s4lr                 1/1     Running            0             4m12s
file-manager-5555876d89-slqwg              1/1     Running            0             4m16s
identity-6455d6f4b7-bwgf7                  1/1     Running            0             4m14s
inventory-fc6585898-kjmwx                  1/1     Running            0             4m13s
inventory-scheduler-6dd9f6787f-k9sff       0/1     CrashLoopBackOff   4 (21s ago)   4m15s
inventory-worker-7f6d479d88-59lxs          1/1     Running            0             4m12s
mongodb-6b78c74d49-vjxsf                   1/1     Running            0             4m14s
monitoring-77d9bd8955-hv6vp                1/1     Running            0             4m15s
monitoring-rest-75cd56bc4f-wfh2m           2/2     Running            0             4m16s
monitoring-scheduler-858d876884-b67tc      0/1     Error              3 (33s ago)   4m12s
monitoring-worker-66b875cf75-9gkg9         1/1     Running            0             4m12s
notification-659c66cd4d-hxnwz              1/1     Running            0             4m13s
notification-scheduler-6c9696f96-m9vlr     1/1     Running            0             4m14s
notification-worker-77865457c9-b4dl5       1/1     Running            0             4m16s
plugin-558f9c7b9-r6zw7                     1/1     Running            0             4m13s
plugin-scheduler-695b869bc-d9zch           0/1     Error              4 (59s ago)   4m15s
plugin-worker-5f674c49df-qldw9             1/1     Running            0             4m16s
redis-566869f55-zznmt                      1/1     Running            0             4m16s
repository-8659578dfd-wsl97                1/1     Running            0             4m14s
secret-69985cfb7f-ds52j                    1/1     Running            0             4m12s
statistics-98fc4c955-9xtbp                 1/1     Running            0             4m16s
statistics-scheduler-5b6646d666-jwhdw      0/1     CrashLoopBackOff   3 (27s ago)   4m13s
statistics-worker-5f9994d85d-ftpwf         1/1     Running            0             4m12s
supervisor-scheduler-74c84646f5-rw4zf      2/2     Running            0             4m16s

몇몇의 scheduler pod에 문제가 있는 상태로 나머지 pod들이 올라왔다면 현재로서는 올바른 상태입니다. scheduler의 문제는 initializer를 통해 token을 발급받은 후 values.yaml 파일을 이용한 upgrade 작업이 필요합니다.

5. Initialize the configuration

Cloudforet의 domain 생성을 위한 작업입니다. initializer를 통해 root domain을 생성하고 root token를 발급합니다.

spaceone-initializer는 다음 cloudforet-io github 사이트에서 확인 가능합니다. https://github.com/cloudforet-io/spaceone-initializer

여기서 사용할 initializer.yaml 파일은 다음 링크에서 확인 가능합니다. https://github.com/cloudforet-io/charts/blob/master/examples/initializer.yaml

initializer.yaml 파일에서 domain name, domain_owner.id/password 등을 변경 할 수 있습니다.

  • 파일 생성

    cat <<EOF> filename.yaml
main:
import:
    - /root/spacectl/apply/root_domain.yaml
    - /root/spacectl/apply/create_managed_repository.yaml
    - /root/spacectl/apply/user_domain.yaml
    - /root/spacectl/apply/create_role.yaml
    - /root/spacectl/apply/add_statistics_schedule.yaml
    - /root/spacectl/apply/print_api_key.yaml
var:
    domain:
    root: root                      # 생성하는 root domain 이름 : root.example.com
    user: spaceone                  # 사용자를 위한 user domain 이름 : spaceone.example.com
    default_language: ko
    default_timezone: Asia/Seoul
    domain_owner:
    id: admin               # login user name
    password: Admin123!@#   # Change your password
    user:
    id: system_api_key
EOF

해당 파일의 편집이 끝나면 아래 명령어를 통해서 initializer를 실행 합니다.

helm install initializer cloudforet/spaceone-initializer -n spaceone -f initializer.yaml

실행 후에는 지정한 spaceone namespace에 initializer pod가 생성되며 domain 생성작업을 수행합니다. pod가 Completed 상태가 되면 완료된 것이며 log를 확인 할 수 있습니다.

6. Set the Helm Values and Upgrade the chart

기본 설치된 helm chart에 customizing을 하기 위해서는 values.yaml 파일이 필요합니다.

values.yaml 파일에 관한 일반적인 예시는 다음의 링크에서 확인 가능합니다. https://github.com/cloudforet-io/charts/blob/master/examples/values/all.yaml

scheduler의 문제를 해결하기 위해서 아래와 같이 Completed 상태의 pod log를 확인해서 admin token을 얻습니다.

kubectl logs initializer-5f5b7b5cdc-abcd1 -n spaceone

(omit)
TASK [Print Admin API Key] *********************************************************************************************
"{TOKEN}"

FINISHED [ ok=23, skipped=0 ] ******************************************************************************************

FINISH SPACEONE INITIALIZE

initializer pod log에서 얻은 token 값을 이용해서 values.yaml 파일을 생성합니다. 파일 내부에는 app 설정, namespace 변경, kubernetes 옵션 변경 등을 선언할 수 있습니다.

다음은 values.yaml 내부에 console 도메인 설정과 발급 받은 token을 전역 config로 사용 가능하도록 하는 설정입니다.

console:
  production_json:
    # If you don't have a service domain, you refer to the following 'No Domain & IP Access' example.
    CONSOLE_API:
      ENDPOINT: https://console.api.example.com       # Change the endpoint
    CONSOLE_API_V2:
      ENDPOINT: https://console-v2.api.example.com    # Change the endpoint

global:
  shared_conf:
    TOKEN: '{TOKEN}'                                  # Change the system token

위와같이 values.yaml 파일 설정이 끝났다면 아래의 명령어로 helm upgrade 작업을 수행합니다. upgrade가 끝나고 난 뒤에는 모든 pod가 재시작 되도록 cloudforet 관련 app instance들을 모두 삭제합니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

7. Check the status of the pods

다음의 명령어로 pod의 상태를 확인합니다. 모든 pod들이 Running 상태라면 설치 완료 입니다.

kubectl get pod -n spaceone

8. Configuration Ingress

Kubernetes Ingress는 Cluster내 Service와 외부의 연결을 관리해주는 리소스입니다. Cloudforet에서는 아래의 순서에 따라 생성된 인증서를 secret으로 등록하고 ingress를 추가하여 서비스 됩니다.

Nginx Ingress Controller 설치
On-premise 환경에서 ingress를 사용하기 위해서는 ingress controller가 필요합니다. 다음은 Kubernetes에서 지원하는 Nginx Ingress Controller의 설치 가이드 링크입니다.

Generate self-managed SSL

아래의 openssl 명령어를 이용해서 사설 ssl 인증서를 생성합니다. (이미 발급받은 인증서가 존재한다면, 발급받은 인증서를 이용하여 Secret을 만들 수 있습니다. 자세한 방법은 다음 링크를 참고하시기 바랍니다. 기존 인증서로 Secret 만들기)

  • console

    • *.{domain}
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout console_ssl.pem -out console_ssl.csr -subj "/CN=*.{domain}/O=spaceone" -addext "subjectAltName = DNS:*.{domain}"

  • api

    • *.api.{domain}
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout api_ssl.pem -out api_ssl.csr -subj "/CN=*.api.{domain}/O=spaceone" -addext "subjectAltName = DNS:*.api.{domain}"

Create secret for ssl

인증서가 준비 되었다면 해당 인증서 파일을 이용해서 secret을 생성합니다.

kubectl create secret tls console-ssl --key console_ssl.pem --cert console_ssl.csr

kubectl create secret tls api-ssl --key api_ssl.pem --cert api_ssl.csr

Create Ingress

아래 2개의 ingress 파일을 준비합니다. 해당 ingress 파일들은 다음의 링크에서 다운로드 가능합니다.

각각의 파일은 아래와 같습니다. 파일 내부에 hostname을 생성한 인증서의 도메인에 맞게 변경해줍니다.

  • console

    cat <<EOF> console_ingress.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: console-ingress
namespace: spaceone
spec:
ingressClassName: nginx
tls:
    - hosts:
        - "console.example.com"  # Change the hostname
    secretName: spaceone-tls
rules:
    - host: "console.example.com"  # Change the hostname
    http:
        paths:
        - path: /
            pathType: Prefix
            backend:
            service:
                name: console 
                port:
                number: 80
EOF

  • rest_api

    cat <<EOF> rest_api_ingress.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: console-api-ingress
namespace: spaceone
spec:
ingressClassName: nginx
tls:
    - hosts:
        - "*.api.example.com"  # Change the hostname
    secretName: spaceone-tls
rules:
    - host: "console.api.example.com"  # Change the hostname
    http:
        paths:
        - path: /
            pathType: Prefix
            backend:
            service:
                name: console-api
                port:
                number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: console-api-v2-ingress
namespace: spaceone
spec:
ingressClassName: nginx
tls:
    - hosts:
        - "*.api.example.com"  # Change the hostname
    secretName: spaceone-tls
rules:
    - host: "console-v2.api.example.com"  # Change the hostname
    http:
        paths:
        - path: /
            pathType: Prefix
            backend:
            service:
                name: console-api-v2-rest
                port:
                number: 80
EOF

준비된 ingress를 아래의 명령어를 통해서 spaceone namespace에 생성합니다.

kubectl apply -f console_ingress.yaml -n spaceone
kubectl apply -f rest_api_ingress.yaml -n spaceone

Connect to the Console

Cloudforet Console 서비스에 접속 합니다.

Advanced Configurations

다음과 같은 특이사항에 대해서는 추가적인 설정이 필요합니다. 다음은 상황에 따른 예시와 해결 방법을 위한 내용입니다.

NameDescription
Set Plugin Certificate사설 인증서를 사용하는 경우 plugin별 인증서를 설정하는 방법입니다.
Change K8S Namespace환경별로 Namespace 사용이 제한적이거나, 자신만의 Namespace 이름을 사용할 수 있습니다. 다음은 Cloudforet에서 Namespace를 변경하는 방법입니다.
Set K8S ImagePullSecretsPrivate Image Registry를 이용하는 경우 사용자 인증 설정이 되어 자격증명이 필요할 수 있습니다. Kubernetes에서는 secret을 이용하여 자격증명을 pod에 등록할 수 있습니다. 다음은 ImagePullSecrets를 설정하는 방법입니다.
Set HTTP Proxy인터넷 연결이 되지 않는 on-premise 환경인 경우 외부와 통신하기 위해서는 proxy 설정이 필요합니다. 다음은 HTTP Proxy를 설정하기 위한 방법입니다.
Support Private Image Registry조직의 보안 등의 이유로 외부와의 통신이 차단된 환경에서는 자체적인 Private Image Registry를 운용할 수 있습니다. 이런 경우 Container Image Sync 작업이 필요한데, Cloudforet에서는 dregsy tool을 이용한 방법을 제안합니다.

3.2 - 설정

설정에서는 Cloudforet을 사용하는데 필요한 설정들에 대해서 소개합니다.

3.2.1 - 플러그인 사설 인증서 설정

Cloudforet에서 사용 되는 플러그인에 사설 인증서를 설정하는 방법에 대해 설명합니다.

set_plugin_certificate

Cloudforet가 On-premise 환경에 구축될 경우 인터넷과 직접적인 통신이 되지 않고 Proxy 서버를 통해 접속이 될 수 있습니다.
이 때 Proxy 서버와의 통신 시 사설 인증서를 필요로 하게 됩니다.
먼저, 준비된 사설 인증서로 Secret으로 구성하고 이를 private-tls Volume에 Mount 합니다.
이후 supervisor의 KubernetesConnector에 인증서 설정에 필요한 여러 환경변수의 value가 private-tls volume의 tls.crt의 경로가 되도록 설정합니다.




준비된 사설 인증서를 Kubernetes Secret으로 등록

ParameterDescriptionDefault
apiVersionAPI version of resourcev1
kindKind of resourceSecret
metadataMetadata of resource{...}
metadata.nameName of resourceprivate-tls
metadata.namespaceNamespace of resourcespaceone
dataData of resourcetls.crt
typeType of resourcekubernetes.io/tls
kubectl apply -f create_tls_secret.yml

---
apiVersion: v1
kind: Secret
metadata:
  name: spaceone-tls
  namespace: spaceone
data:
  tls.crt: base64 encoded cert  # openssl base64 -in cert.pem -out cert.base64
type: kubernetes.io/tls



KubernetesConnector에 설정

ParameterDescriptionDefault
supervisor.application_schedulerConfiguration of supervisor scheduler{...}
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[]Environment variables for plugin[...]
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[].nameName of environment variableREQUESTS_CA_BUNDLE, AWS_CA_BUNDLE, CLOUDFORET_CA_BUNDLE
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[].valueValue of environment variable/opt/ssl/cert/tls.crt
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumes[]Volumes for plugin[...]
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumes[].nameName of volumesprivate-tls
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumes[].secret.secretNameSecret name of secret volumeprivate-tls
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumeMounts[]Volume mounts of plugins[...]
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumeMounts[].nameName of volume mountsprivate-tls
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumeMounts[].mountPathPath of volume mounts/opt/ssl/cert/tls.crt
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.volumeMounts[].readOnlyRead permission on the mounted volumetrue
supervisor:
  enabled: true
  image:
    name: spaceone/supervisor
    version: x.y.z

  imagePullSecrets:
    - name: my-credential

  application_scheduler:
    CONNECTORS:
      KubernetesConnector:
        env:
          - name: REQUESTS_CA_BUNDLE
            value: /opt/ssl/cert/tls.crt
          - name: AWS_CA_BUNDLE
            value: /opt/ssl/cert/tls.crt
          - name: CLOUDFORET_CA_BUNDLE
            value: /opt/ssl/cert/tls.crt
        volumes:
          - name: private-tls
            secret:
              secretName: private-tls
        volumeMounts:
          - name: private-tls
            mountPath: /opt/ssl/cert/tls.crt
            readOnly: true



변경내용 반영

helm upgrade 및 pod 삭제 명령을 통해서 반영 할 수 있습니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

3.2.2 - Change kubernetes namespace

사용자가 core 서비스나 plugin 서비스를 다른 이름의 namespace로 변경하는 방법에 대해 설명합니다.

K8S 환경에서 Cloudforet을 설치하게 되면 core 서비스는 spaceone, 확장 기능을 위한 plugin 서비스는 spaceone-plugin namespace에 설치됩니다. (v1.11.5 이하에서는 root-supervisor에 설치 됩니다.)

만약 사용자가 core 서비스나 plugin 서비스를 다른 이름의 namespace로 변경하고 싶거나, 단일 namespace에 설치하기를 희망한다면 옵션을 통해서 namespace를 변경해야 합니다.

namespace를 변경하기 위해서는 Cloudforet의 values.yaml에 변경 내용을 작성해야 합니다. 변경은 core서비스와 plugin 서비스를 각각 설정할 수 있습니다.

core 서비스의 namespace 변경

core 서비스의 namespace 변경을 위해서는 values.yaml 파일에서 global.namespace를 선언하여 spaceone-namespace 값을 추가합니다.

#console:
#  production_json:
#    CONSOLE_API:
#      ENDPOINT: https://console.api.example.com        # Change the endpoint
#    CONSOLE_API_V2:
#      ENDPOINT: https://console-v2.api.example.com     # Change the endpoint

global:
  namespace: spaceone-namespace                         # Change the namespace
  shared_conf:

plugin 서비스의 namespace 변경

core 서비스 뿐만 아니라, supervisor의 plugin 서비스의 namespace도 변경할 수 있습니다. plugin 서비스는 supervisor에 의해 life-cycle이 관리되며 plugin의 namespace 설정도 supervisor에 설정합니다.

아래는 values.yaml 파일에서 plugin 서비스의 namespace를 변경히가 위해 supervisor를 설정한 부분입니다. supervisor.application_scheduler.CONNECTORS.KubernetesConnector.namespace에 plugin-namespace 값을 추가합니다.

#console:
supervisor:
  application_scheduler:
    HOSTNAME: spaceone.svc.cluster.local                # Change the hostname
    CONNECTORS:
      KubernetesConnector:
        namespace: plugin-namespace                     # Change the namespace

변경내용 반영

helm upgrade 및 pod 삭제 명령을 통해서 반영 할 수 있습니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

3.2.3 - Kubernetes imagePullSecrets 설정

Cloudforet의 Pod들이 imagePullSecrets을 이용해 Private Container Image를 가져올 수 있도록 하는 방법에 대해 설명합니다.

사용자들은 때때로 조직의 상황에 따라 Private Image를 관리하기 위해 Private 전용 Image Registry를 구축하고 그것을 이용합니다.

Private Image Registry로부터 Container Image를 가져오기 위해서는 자격 증명이 필요하고, Kubernetes에서는 Secret을 이용해 그러한 자격 증명을 Pod 등록하여 Private Container Image를 가져올때 사용할 수 있도록 할 수 있습니다.

자세한 내용은 공식 문서를 참고하세요.

자격증명을 위한 Secret 생성

Kubernetes pod는 kubernetes.io/dockerconfigjson 타입의 Secret을 이용해 Private Container Image를 가져올 수 있습니다.

이를 위해 registry 인증정보를 기반으로 자격 증명을 위한 secret을 생성합니다.

kubectl create secret docker-registry my-credential --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

자격증명 Secret을 Pod에 적용

Cloudforet의 helm chart value에 imagePullSecrets 을 명시하여 pod들이 자격 증명을 위한 secret을 mount하도록 할 수 있습니다.

WARN: kubernetes secret은 namespace scope의 resource이므로, 같은 namespace에 존재해야합니다.

Core service를 위한 imagePullSecrets 설정

ParameterdescriptionDefault
[services].imagePullSecrets[]]imagePullSecrets configuration(* Each micro service section)[]
[services].imagePullSecrets[].nameName of secret type of kubernetes.io/dockerconfigjson""
console:
    enable: true
    image:
      name: spaceone/console
      version: x.y.z

    imagePullSecrets:
      - name: my-credential

console-api:
    enable: true
    image:
      name: spaceone/console-api
      version: x.y.z

    imagePullSecrets:
      - name: my-credential

(이하 동일)

Plugin를 위한 imagePullSecrets 설정

ParameterdescriptionDefault
supervisor.application_schedulerConfiguration of supervisor scheduler{...}
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.imagePullSecrets[]imagePullSecrets configuration for plugin[]
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.imagePullSecrets[].nameName of secret type of kubernetes.io/dockerconfigjson for plugin""
supervisor:
    enabled: true
    image:
      name: spaceone/supervisor
      version: x.y.z

    imagePullSecrets: 
      - name: my-credential

    application_scheduler:
      CONNECTORS:
          KubernetesConnector:
              imagePullSecrets: 
                - name: my-credential

변경내용 반영

helm upgrade 및 pod 삭제 명령을 통해서 반영 할 수 있습니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

3.2.4 - HTTP Proxy 설정

proxy 연결을 위한 kubernetes pod의 http_proxy 설정을 설명합니다.

set_proxy

http_proxy https_proxy 환경변수 선언을 통해 pod들이 프록시 서버를 통해 외부로 통신할 수 있도록 할 수 있습니다.
이러한 설정은 각 Container의 환경변수에 http_proxy https_proxy를 선언하는 것으로 이루어집니다.

no_proxy 환경변수는 proxy 통신을 적용하지 않는 목적지에 대한 설정입니다.

cloudforet의 경우 Micro service간 통신을 위해 cluster 내부의 service 도메인은 제외하도록 설정하는 것을 추천합니다.

예제

Core service를 위한 proxy 설정

ParameterdescriptionDefault
global.common_env[]Environment Variable for all micro services[]
global.common_env[].nameName of environment variable""
global.common_env[].valueValue of environment variable""
global:
  common_env:
    - name: HTTP_PROXY
      value: http://{proxy_server_address}:{proxy_port}
    - name: HTTPS_PROXY
      value: http://{proxy_server_address}:{proxy_port}
    - name: no_proxy
      value: .svc.cluster.local,localhost,{cluster_ip},board,config,console,console-api,console-api-v2,cost-analysis,dashboard,docs,file-manager,identity,inventory,marketplace-assets,monitoring,notification,plugin,repository,secret,statistics,supervisor

plugin을 위한 proxy 설정

ParameterdescriptionDefault
supervisor.application_schedulerConfiguration of supervisor schduler{...}
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[]Environment Variable for plugin[]
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[].nameName of environment variable""
supervisor.application_scheduler.CONNECTORS.KubernetesConnector.env[].valueName of environment variable""

WRAN:
설치 환경에 따라 default local domain이 다른 경우가 있으니,
.svc.cluster.local 등의 default local domain을 자신의 환경에 맞게 변경해야합니다.
아래의 command로 현재 cluster의 dns 설정을 확인할 수 있습니다.

kubectl run -it --rm busybox --image=busybox --restart=Never -- cat /etc/resolv.conf

supervisor:
    enabled: true
    image:
      name: spaceone/supervisor
      version: x.y.z

    imagePullSecrets: 
      - name: my-credential

    application_scheduler:
      CONNECTORS:
        KubernetesConnector:
          env:
            - name: HTTP_PROXY
              value: http://{proxy_server_address}:{proxy_port}
            - name: HTTPS_PROXY
              value: http://{proxy_server_address}:{proxy_port}
            - name: no_proxy
              value: .svc.cluster.local,localhost,{cluster_ip},board,config,console,console-api,console-api-v2,cost-analysis,dashboard,docs,file-manager,identity,inventory,marketplace-assets,monitoring,notification,plugin,repository,secret,statistics,supervisor

변경내용 반영

helm upgrade 및 pod 삭제 명령을 통해서 반영 할 수 있습니다.

helm upgrade cloudforet cloudforet/spaceone -n spaceone -f values.yaml
kubectl delete po -n spaceone -l app.kubernetes.io/instance=cloudforet

3.2.5 - 프라이빗 이미지 저장소 지원

Cloudforet은 자체 Private Container Registry에 Container Image를 동기화 하기위한 방법을 제안합니다.

On-premise 환경을 운영하는 조직의 경우 보안상의 문제로
Internal Network에 자체 Container registry를 구축하여 운영하는 경우가 있습니다.

이러한 환경에 Cloudforet을 설치할 경우 외부 네트워크로의 접근이 제한되어,
Dockerhub에서 이미지를 가져와 자체 Container registry에 준비해두어야 할 필요가 있습니다.

Cloudforet은 이러한 상황에서 Container Image 동기화 작업을 자동화하기 위해 dregsy 라는
Container Registry Sync tool을 이용해 주기적으로 Container Image를 동기화하는 방법을 제안합니다.

dregsy_for_image_sync

External Network와 Internal Network 사이에 위치한 환경에서 dregsy 를 실행합니다.
이것은 주기적으로 Dockerhub로부터 특정 Container Image를 가져와 자체 Container registry에 업로드합니다.

NOTE:
본 가이드에서 설명하고 있는 dregsy tool은 Container Image가 Destination Registry에
존재하는지의 여부와 관계없이 항상 Dockerhub로부터 Container image를 pull합니다.

Dockerhub의 rate limit은 아래와 같습니다. (Download rate limit)

  • 익명 유저 100pulls per 6 hours
  • 인증 유저 200pulls per 6 hours
  • 구독 유저 5000pulls per day

설치 및 설정

NOTE:
본 구성의 경우, Dockerhub와 통신이 필요하기 때문에 외부 인터넷과 통신이 가능한 환경에서 이루어져야합니다.
또한, 1.11.x 버전의 Cloudforet 설치를 기준으로 설명합니다.

Prerequisite

Installation

Docker를 이용해 도구를 실행시키기 때문에 별도의 설치 과정은 필요하지 않음,
skopeo(mirror tool)을 포함한 dregsy image를 pull하여 실행할 예정.

Configuration

  • 설정 파일 생성
touch /path/to/your/dregsy-spaceone-core.yaml
touch /path/to/your/dregsy-spaceone-plugin.yaml
  • 설정 추가 (dregsy-spaceone-core.yaml)

만약, username:password 구성으로 Registry 인증을 하는 경우,
아래와 같이 정보를 encode하여 auth에 설정합니다. (예시 - 설정 19,22번째 라인)
echo '{"username": "...", "password": "..."}' | base64

Harbor의 경우 Robot Token 인증은 지원이 어렵습니다. username:password를 encoding하여 인증해주세요.

relay: skopeo
watch: true

skopeo:
  binary: skopeo
  certs-dir: /etc/skopeo/certs.d

lister:
  maxItems: 100
  cacheDuration: 2h

tasks:
  - name: sync_spaceone_doc
    interval: 21600 # 6 hours
    verbose: true

    source:
      registry: registry.hub.docker.com
      auth: {Token}                 # replace to your dockerhub token
    target:
      registry: {registry_address}  # replace to your registry address
      auth: {Token}                 # replace to your registry token
      skip-tls-verify: true

    mappings:
      - from: spaceone/spacectl
        to: your_registry_project/spaceone/spacectl     # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/marketplace-assets
        to: your_registry_project/spaceone/marketplace-assets   # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/docs
        to: your_registry_project/spaceone/docs          # replace to your registry project & repository
        tags:
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: redis
        to: your_registry_project/spaceone/redis       # replace to your registry project & repository
        tags: 
          - 'latest'
      - from: mongo
        to: your_registry_project/spaceone/mongo       # replace to your registry project & repository
        tags: 
          - 'latest'

  - name: sync_spaceone_core
    interval: 21600 # 6 hours
    verbose: true

    source:
      registry: registry.hub.docker.com
      auth: {Token}
    target:
      registry: {registry_address}  # replace to your registry address
      auth: {Token}               # replace to your registry token
      skip-tls-verify: true

    mappings:
      - from: spaceone/console
        to: your_registry_project/spaceone/console     # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/inventory
        to: your_registry_project/spaceone/inventory       # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/console-api
        to: your_registry_project/spaceone/console-api     # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/cost-analysis
        to: your_registry_project/spaceone/cost-analysis       # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/statistics
        to: your_registry_project/spaceone/statistics      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/secret
        to: your_registry_project/spaceone/secret      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/file-manager
        to: your_registry_project/spaceone/file-manager        # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/monitoring
        to: your_registry_project/spaceone/monitoring      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/supervisor
        to: your_registry_project/spaceone/supervisor      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/identity
        to: your_registry_project/spaceone/identity        # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/notification
        to: your_registry_project/spaceone/notification        # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/repository
        to: your_registry_project/spaceone/repository      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/plugin
        to: your_registry_project/spaceone/plugin      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/config
        to: your_registry_project/spaceone/config      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/console-api-v2
        to: your_registry_project/spaceone/console-api-v2      # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/board
        to: your_registry_project/spaceone/board       # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
      - from: spaceone/dashboard
        to: your_registry_project/spaceone/dashboard       # replace to your registry project & repository
        tags: 
          - 'regex: 1\.11\.(?:[0-9]?[0-9]).*'
  • 설정 추가 (dregsy-spaceone-plugin.yaml)
relay: skopeo
watch: true

skopeo:
  binary: skopeo
  certs-dir: /etc/skopeo/certs.d

lister:
  maxItems: 100
  cacheDuration: 2h

tasks:
  - name: sync_spaceone_plugin
    interval: 21600 # 6 hours
    verbose: true

    source:
      registry: registry.hub.docker.com
      auth: {Token}                 # replace to your dockerhub token
    target:
      registry: {registry_address}  # replace to your registry address
      auth: {Token}                 # replace to your registry token
      skip-tls-verify: true

    mappings:
      - from: spaceone/plugin-google-cloud-inven-collector
        to: your_registry_project/spaceone/plugin-google-cloud-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-azure-inven-collector
        to: your_registry_project/spaceone/plugin-azure-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-cloudwatch-mon-datasource
        to: your_registry_project/spaceone/plugin-aws-cloudwatch-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-azure-activity-log-mon-datasource
        to: your_registry_project/spaceone/plugin-azure-activity-log-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-cloudtrail-mon-datasource
        to: your_registry_project/spaceone/plugin-aws-cloudtrail-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-ec2-inven-collector
        to: your_registry_project/spaceone/plugin-aws-ec2-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-sns-mon-webhook
        to: your_registry_project/spaceone/plugin-aws-sns-mon-webhook     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-trusted-advisor-inven-collector
        to: your_registry_project/spaceone/plugin-aws-trusted-advisor-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-azure-monitor-mon-datasource
        to: your_registry_project/spaceone/plugin-azure-monitor-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-email-noti-protocol
        to: your_registry_project/spaceone/plugin-email-noti-protocol     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-google-stackdriver-mon-datasource
        to: your_registry_project/spaceone/plugin-google-stackdriver-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-telegram-noti-protocol
        to: your_registry_project/spaceone/plugin-telegram-noti-protocol     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-keycloak-identity-auth
        to: your_registry_project/spaceone/plugin-keycloak-identity-auth     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-prometheus-mon-webhook
        to: your_registry_project/spaceone/plugin-prometheus-mon-webhook     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-slack-noti-protocol
        to: your_registry_project/spaceone/plugin-slack-noti-protocol     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-grafana-mon-webhook
        to: your_registry_project/spaceone/plugin-grafana-mon-webhook     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-cloud-service-inven-collector
        to: your_registry_project/spaceone/plugin-aws-cloud-service-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-phd-inven-collector
        to: your_registry_project/spaceone/plugin-aws-phd-inven-collector     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-api-direct-mon-webhook
        to: your_registry_project/spaceone/plugin-api-direct-mon-webhook     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-azure-cost-mgmt-cost-datasource
        to: your_registry_project/spaceone/plugin-azure-cost-mgmt-cost-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-aws-cost-explorer-cost-datasource
        to: your_registry_project/spaceone/plugin-aws-cost-explorer-cost-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-ms-teams-noti-protocol
        to: your_registry_project/spaceone/plugin-ms-teams-noti-protocol     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-google-monitoring-mon-webhook
        to: your_registry_project/spaceone/plugin-google-monitoring-mon-webhook     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-http-file-cost-datasource
        to: your_registry_project/spaceone/plugin-http-file-cost-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'
      - from: spaceone/plugin-google-cloud-log-mon-datasource
        to: your_registry_project/spaceone/plugin-google-cloud-log-mon-datasource     # replace to your registry project & repository
        tags: 
          - 'semver: >=1.0.0 <1.99.0'
          - 'keep: latest 2'

Run

Docker image를 별도로 download 받을 필요가 없습니다.
아래의 command가 docker image를 확인 후 없다면 가져옵니다.

docker run -d --rm --name dregsy_spaceone_core -v /path/to/your/dregsy-spaceone-core.yaml:/config.yaml xelalex/dregsy:0.5.0

docker run -d --rm --name dregsy_spaceone_plugin -v /path/to/your/dregsy-spaceone-plugin.yaml:/config.yaml xelalex/dregsy:0.5.0

Management

  • view log
docker logs -f {container_id|container_name}
  • delete docker container
docker rm {container_id|container_name} [-f]

3.2.6 - 기존 인증서로 Secret 만들기

공인 혹은 사설 인증서를 발급 받은 경우, 발급된 인증서를 이용한 secret 생성 및 적용 방법을 설명합니다.

공인 혹은 사설 인증서를 이미 발급받은 경우에는 기존 인증서를 통해서 Secret을 생성 할 수 있습니다. 다음은 certificate_secret.yaml 파일을 이용하여 Secret을 생성하는 방법입니다.

Create Secret from certificate_secret.yaml file

기존에 발급받은 인증서가 준비 되었다면 certificate_secert.yaml 파일을 편집합니다. 해당 파일은 다음의 링크에서 다운로드 할 수 있습니다. 또한 다운로드받은 내용을 아래와 같이 편집하여 사용 합니다. https://github.com/cloudforet-io/charts/blob/master/examples/ingress/on_premise/certificate_secret.yaml

cat <<EOF> certificate_secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: spaceone-tls
  namespace: spaceone           # Change the namespace
data:
  tls.crt: base64 encoded cert  # openssl base64 -in cert.pem -out cert.base64
  tls.key: base64 encoded key   # openssl base64 -in key.pem -out key.base64
type: kubernetes.io/tls
EOF

certificate_secret.yaml 파일을 다음 명령어를 통해서 spaceone namespace에 반영합니다.

kubectl apply -f certificate_secret.yaml -n spaceone

4 - 사용 가이드

Guide to use Cloudforet

4.1 - 시작하기

클라우드포레는 여러 클라우드 서비스 프로바이더에 분산된 리소스들을 통합하여 체계적으로 관리할 수 있는 서비스입니다.

가이드를 통해 클라우드포레에 대한 모든 것을 알아보세요.

주요 서비스를 이용하기 위해서는 다음 몇 가지 작업이 선행되어야 합니다.

  1. Admin 모드 진입
  2. 도메인 설정
  3. 워크스페이스 생성 & 사용자 초대
  4. 워크스페이스내 프로젝트 생성
  5. 서비스 사용 시작 시작하기

1. Admin 모드 진입

초기에 필요한 설정들은 대부분 Admin 모드에서 이루어집니다.
Admin 역할 타입을 가진 사용자만이 Admin 모드에 접근할 수 있습니다.



2. 도메인 설정

도메인 표시 명을 비롯해 로고, 파비곤(Favicon), 대표 이미지 등을 직접 설정할 수 있습니다.



3. 워크스페이스 생성 & 사용자 초대

데이터 연결, 프로젝트 관리를 위해서는 기본적으로 워크스페이스가 1개 이상 활성화되어 있어야 합니다.

(1) [관리 > 환경설정 > 워크스페이스]로 이동

(2) 우측 상단 [+생성] 버튼 클릭

(3) 워크스페이스 이름, 설명을 입력하여 쉽고 빠르게 생성 가능

(4) 워크스페이스 생성 직후 바로 사용자 초대 가능

  • 초대 시 해당 워크스페이스에 특정 역할(=권한)을 필수로 할당하게 됩니다.



4. 워크스페이스내 프로젝트 생성

(1) 특정 워크스페이스로 이동합니다.

  • 워크스페이스 이동 방법 1: [관리 > 환경설정 > 워크스페이스]에서 워크스페이스를 선택해서 이동할 수 있습니다.

  • 워크스페이스 이동 방법 2: 우측 상단 [Admin 모드]를 끄고, 특정 워크스페이스로 이동할 수 있습니다.
    • [Admin] 모드 끄기
    • 워크스페이스 이동하기

(2) (상단 메뉴)프로젝트로 이동

(3) 우측 상단 [+생성] 버튼 클릭하여 새 프로젝트 생성

프로젝트의 성향에 따라 '워크스페이스내 전체 사용자'가 접근 가능한 오픈된 프로젝트로,

또는 '초대된 사용자만' 접근 가능한 제한된 프로젝트로 생성할 수 있습니다.

이제, 서비스 사용을 위한 초기 기본 설정이 끝났습니다.


5. 서비스 사용 시작하기

위의 과정들을 완료한 뒤, 주요 서비스를 좀 더 편리하고 다양하게 이용하고 싶다면 다음 가이드를 참고해주세요.

4.2 - 권한 체계

조직의 구성과 목적에 맞게 사용자별 접근 권한을 부여 하고 체계적으로 관리 시스템을 운영할 수 있도록 역할(Role) 타입이라는 기본적인 권한 체계를 제공합니다.

역할 타입

총 세 개의 타입을 기준으로 역할이 구성됩니다.

  • Admin: 도메인 설정을 포함하여 모든 워크스페이스에 대한 접근 권한이 있으며, Admin 모드를 포함합니다.
  • Workspace Owner: 워크스페이스 내의 모든 프로젝트에 대한 접근 권한이 있습니다.
  • Workspace Member: 워크스페이스 내의 초대받은 프로젝트에만 접근 권한이 있습니다.

역할 타입별 기본 권한에 대해서는 아래 자세히 확인할 수 있습니다.



Admin 역할 타입


✓ 도메인 전체 사용자 관리 권한

  • 도메인, 전체 워크스페이스 내 사용자 초대 및 관리
  • Admin, Workspace Owner, Workspace Member 역할(Role) 부여
  • 역할(Role)별 서비스 세부 메뉴 접근 제한 설정
  • 사용자 계정에 대한 복구

✓ 워크스페이스 환경 관리 권한

  • 워크스페이스 생성 및 삭제
  • 전체 워크스페이스별 환경 접근

✓ 앱(Client Secret) 관리 권한

  • 도메인 전체 접근 전용 앱(Client Secret) 생성 및 삭제
  • Admin 역할(Role)별 앱(Client Secret) 부여

✓ 도메인 설정 권한

  • 도메인 표시, 아이콘 등의 화이트 라벨링 설정
  • 도메인 전체 타임존&언어 설정

✓ 이외 도메인 내 특정 서비스별 관리 권한

  • 데이터 수집기 또는 비용 예산 등을 Global 범위로 생성



Workspace Owner 역할 타입

✓ 특정 워크스페이스 사용자 관리 권한

  • 워크스페이스 내 사용자 초대 및 관리
  • Workspace Owner, Workspace Member 역할(Role) 부여

✓ 앱(Client Secret) 관리 권한

  • 워크스페이스 접근 전용 앱(Client Secret) 생성 및 삭제
  • Workspace Owner 역할(Role)별 앱(Client Secret) 부여

✓ 신규 프로젝트 생성 및 전체 프로젝트 접근 권한

✓ 이외 워크스페이스 내 각 서비스별 관리 권한



Workspace Member 역할 타입

✓ 특정 워크스페이스에 기본 서비스 접근 권한

✓ 접근 가능한 일부 프로젝트 관리 권한



Workspace Owner | Workspace Member 역할 타입 비교표



4.3 - 관리자 가이드

Admin의 역할(Role) 타입을 가진 사용자의 경우, 도메인 내에 최고 관리자 권한을 행사할 수 있습니다.

해당 사용자(들)은 도메인 설정을 포함하여 모든 워크스페이스에 접근하고, 세부 설정을 조정할 수 있는 권한을 가지고 있습니다.

역할(Role)에 대해 알아보기

Admin 모드로 전환하기

상단 맨 우측 'Admin' 토글을 클릭하여 Admin 모드로 전환할 수 있습니다.


4.3.1 - 사용자 관리

새로운 사용자를 초대할 수 있으며, 도메인 전체 사용자를 한눈에 확인하고 관리할 수 있습니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [관리 > 사용자 및 권한 관리 > 사용자]로 이동



사용자 초대하기

(1) 상단의 [+ 생성] 버튼 클릭

(2) 초대하고자 하는 사용자 계정 추가 및 워크스페이스 & 역할(Role) 할당

(2-1) 사용자 계정 추가

  • Local: E-mail 포멧으로 입력
  • 이외 Google, Keyloak 등의 SSO가 도메인에 추가 설정되어 있다면 해당 포멧에 맞춰 입력

(2-2) Admin 역할(Role) 여부 선택

  • Admin 역할(Role) ON: 도메인 전체에 접근이 가능하기 때문에 워크스페이스 선택 불필요
  • Admin 역할(Role) OFF: 하나 이상의 워크스페이스를 선택하고, 해당 워크스페이스(들)에서의 역할(Role) 선택이 필수

(2-3) [확인] 버튼을 누르고 사용자 초대 완료


(3) 초대된 사용자 목록에서 확인

특정 사용자 클릭 시 사용자 상세 정보를 비롯해 사용자가 속한 워크스페이스 목록 또한 확인이 가능합니다.



사용자 수정하기

(1) 특정 사용자를 클릭하고, [작업 > 수정] 버튼 클릭

(2) 사용자 정보 수정

  • 이름 변경: 관리자가 사용자 이름을 변경할 수 있습니다.
  • 알림 전용 이메일 변경: 관리자가 이메일 주소를 변경하고 임의로 인증을 처리할 수 있습니다.
  • 비밀번호 변경: 직접 비밀번호를 설정해서 사용자에게 전달해주거나, 이메일로 비밀번호 재설정 링크를 보낼 수 있습니다.

(3) 사용자 활성/비활성화

1개 이상의 사용자를 선택하고, [작업 > 활성화] 또는 [작업 > 비활성화] 버튼 클릭하여 활성 상태를 변경할 수 있습니다.

4.3.2 - 앱 관리

API/CLI 접근을 위한 Client Seret 발급용 앱 생성 및 관리가 가능합니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [관리 > 사용자 및 권한 관리 > 앱]으로 이동



앱 생성하기

클라우드포레가 제공하는 CLI 도구인 Spacectl을 사용하기 위해서는 접근 가능한 Client Secret이 필요합니다.

Admin 모드에서는 관리자 역할을 갖는 앱을 생성하고, 해당 앱의 Client Secret 키를 다른 사용자에게 부여할 수 있습니다.

(1) 우측 상단 [+ 생성] 버튼 클릭

(2) 정보 입력

  1. 이름 입력
  2. Admin 역할(Role) 선택: 역할에 대한 상세 내용은 이곳에서 자세히 확인할 수 있습니다.
  3. 태그 입력: '키:값' 방식으로 입력 합니다.
  4. [확인] 버튼을 클릭하여 앱 생성을 완료합니다.

(3) 필수 파일 다운 받기



Client Secret 재생성

(1) 특정 앱 선택

(2) 상단 [작업 > Client Secret 재생성] 클릭

  • 새로운 Secret으로 재생성이 되며, 설정 파일을 다시 다운받을 수 있습니다.

4.3.3 - 역할 관리

사용자 역할(Role) 타입, 페이지별 접근 여부 및 API 연결 등을 통해 세부적인 역할관리가 가능합니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [관리 > 사용자 및 권한 관리 > 역할]로 이동



Managed 역할

  • 역할에 대해 쉽게 확인하고 사용자에게 빠르게 할당할 수 있도록 Domain Admin, Workspace Owner, Workspace Member라는 'Managed' 역할을 기본적으로 제공합니다. ( Managed 역할의 경우 수정/삭제가 불가합니다. )
  • 페이지 접근관련 보다 세부적인 역할 관리가 필요할 경우, 커스텀 역할을 직접 생성할 수 있습니다.



역할 생성하기

(1) 상단의 [+ 생성] 버튼 클릭

(2) 역할 이름 입력

(3) 역할 타입 선택

(4) 페이지 접근 설정

  • Admin 역할 타입은 도메인 전체에 접근이 가능하여 별도의 페이지 접근 권한 설정이 없습니다.
  • Workspace Owner | Workspace Member는 각각에 맞는 페이지 접근 여부를 선택할 수 있습니다.

(5) [생성] 버튼 클릭하여 역할 생성 완료하기



역할 수정/삭제 하기

(1) 특정 역할 선택

(2) 상단 [작업 > 수정] 또는 [작업 > 삭제] 클릭

(3) '수정' 클릭 시, 아래와 같이 해당 역할 편집 페이지로 이동합니다.

4.3.4 - 워크스페이스 관리

조직의 규모와 구조에 맞게 분리된 워크스페이스 환경을 설계하여 관리하세요. 도메인 내 전체 워크스페이스 생성, 관리가 가능합니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [관리 > 환경설정 > 워크스페이스]로 이동



워크스페이스 생성 & 사용자 초대

워크스페이스 생성

(1) 상단의 [+ 생성] 버튼 클릭

(2) 기본 정보 입력 후 생성

  • 이름 입력
  • 설명 입력
  • 워크스페이스 메인 색상 선택
  • [확인] 버튼 클릭

워크스페이스 생성 완료 시, 바로 사용자를 초대할 수 있습니다.



신규 워크스페이스에 사용자 즉시 초대

(1) 사용자 계정 입력하여 목록에 추가

(2) 역할(Role) 선택

(3) [확인] 버튼 클릭하여 초대 완료하기

  • 생성된 워크스페이스 선택 시, 하단에 사용자 목록 확인이 가능합니다.



워크스페이스 수정/관리

특정 워크스페이스 선택 후 상단 [작업] 버튼 클릭 하여 다음과 같은 변경이 가능합니다.

  • 수정: 워크스페이스 이름, 설명 수정이 가능합니다.
  • 삭제: 워크스페이스 삭제가 가능합니다.
    • 삭제 시, 해당 워크스페이스에 속해 있던 사용자 모두 접근이 불가합니다.
  • 활성 or 비활성화: 워크스페이스 활성 상태를 변경할 수 있습니다.
    • 비활성화 시, 해당 워크스페이스에 속해 있던 사용자 모두 접근이 불가합니다.



워크스페이스로 전환하기

  • 특정 워크스페이스 명을 클릭하면 해당 워크스페이스 환경으로 전환됩니다.
  • 워크스페이스 환경으로 전환 시, Admin 모드는 해제됩니다.

4.3.5 - 도메인 설정

도메인 이름, 아이콘, 이미지와 같은 요소들을 직접 설정할 수 있는 화이트 라벨링 기능을 제공합니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [관리 > 환경설정 > 도메인 설정]으로 이동



기본 정보 설정하기



도메인 표시 명 입력 후 [변경 사항 저장] 시, 아래와 같이 브라우저 탭에 이름이 반영됩니다.



브랜드 에셋 설정하기

메인 아이콘, 로그인 페이지 이미지 등 시스템에 기본적인 브랜드 에셋을 반영할 수 있습니다.

각 에셋에 적합한 이미지 URL 입력 후 [변경 사항 저장] 시, 아래와 같이 반영됩니다.



타임존/언어 설정하기

도메인의 기본 타임존 & 언어를 설정할 수 있습니다.

4.3.6 - 공지사항 관리

시스템 공지 확인을 비롯해 도메인 내 직접 운영/관리 관련하여 공지글을 작성할 수 있습니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [정보 > 공지사항]으로 이동



새 공지사항 작성하기

(1) 상단의 [+ 새 공지사항 등록] 버튼 클릭

(2) 공지 글 작성하기

  • 작성자명, 제목, 본문 작성
  • 상단 고정, 팝업 노출 설정 가능
  • [확인] 버튼 클릭하여 공지 글 게시

4.3.7 - 서비스 어카운트 관리

클라우드 프로바이더별 최상위 조직 계정을 추가/관리하고, 자동으로 동기화할 수 있어 빠른 워크스페이스/프로젝트 생성이 가능합니다.

메뉴 진입하기

(1) Admin 모드로 전환하기

(2) [에셋 인벤토리 > 서비스 어카운트]로 이동



Trusted Account를 활용한 계정 관리

Admin 모드에서는 전체 워크스페이스에서 General Account와 연결 가능한 Global Trusted Account를 생성할 수 있습니다.

💡 Trusted Account는 다음과 같은 목적으로 사용됩니다.

1) 다른 어카운트 추가 생성 시, 주요 키 값 없이 연결하여 생성할 수 있는 상위 레벨 어카운트

  • 신규 General Account 생성 시, 암호화 키 입력 대신 Trusted Account를 참조하여 쉽게 생성할 수 있어 조직의 체계에 맞는 계정 보안을 유지할 수 있습니다.

2) 계정 자동 동기화

  • 개별 어카운트를 일일이 입력 하는 대신, Auto Sync(자동 동기화)기능을 활용하여 클라우드 프로바이더에서 구성한 조직 체계를 Cloudforet 시스템에 자동으로 연동할 수 있습니다. 계정 자동 동기화 설정은 아래에서 자세히 확인할 수 있습니다.



Trusted Account 자동 동기화 설정

[ 자동 동기화 기본 구조 ]

SpaceONE은 Workspace > Project Group > Project - Service Account의 관리 체계(구조)를 가지고 있습니다. 하나의 Cloud 자원을 수집했을 때 Project에 매핑되어 관리되어 목적에 맞게 Grouping 용도로 사용할 수 있습니다.

➊ Workspace

가장 상위 관리 체계로 작업 공간을 구분합니다. 이는 회사 별 또는 사내 조직별로 작업 공간을 구분할 수 있습니다.

➋ Project Group

세분화된 부서를 표현할 수 있는 체계에 해당합니다. 흔히 볼 수 있는 폴더 구조를 가지고 있습니다.

➌ Project

실제 Cloud 자원이 매핑되는 하위 관리 체계입니다. 프로젝트 단위를 의미하며 해당 프로젝트에 사용되는 한 개 또는 여러 개의 계정(Service Account)을 매핑할 수 있습니다.

  • Service Account: 실제 수집에 사용되는 계정을 의미하며 Project에 종속되어 있습니다.

[ 자동 동기화 등록 ]

1) 특정 클라우드 프로바이더 선택 후, [+ 생성] 버튼 클릭하여 생성 페이지로 이동

2) 기본정보 및 암호화 키 입력

3) 자동 동기화 세부 설정

  • 자동 동기화 켜기(ON)

  • 매핑 방식 선택

  • 시간 수집 스케줄 설정: 일일 계정 자동 동기화 시간대를 최대 2개 선택할 수 있습니다.


[ 클라우드 프로바이더별 자동 동기화 설정 ]



생성된 Trusted Account 상세 확인 및 수정/삭제

1) Admin Center의 [에셋 인벤토리 > 서비스 어카운트] 페이지 목록에서 생성된 Trusted Account 클릭

2) 기본 정보 확인 및 수정

3) 연결된 General Account 목록 확인

💡 자동 동기화가 설정된 경우,

  • 해당 CSP(클라우드 프로바이더)의 계층 구조가 자동으로 반영되어 있음을 확인할 수 있습니다.
  • 설정된 자동 동기화 스케줄 시간 외에도 [동기화] 버튼을 클릭하여 즉시 계정을 업데이트 할 수 있습니다.

4) 자동 동기화 설정 확인 및 수정

  • 자동 동기화 ON/OFF를 비롯해 동기화 스케줄등의 세부 설정이 가능합니다.

5) 서비스 어카운트 이름 수정 또는 삭제

  • 맨 상단 컬렉터 이름 옆 [✏️] 편집 버튼을 통해 컬렉터 이름 수정 가능
  • 맨 상단 컬렉터 이름 옆 [🗑️] 삭제 버튼을 통해 컬렉터 삭제 가능

4.3.8 - 전체 자원 관리

도메인 내 전체 워크스페이스의 자원을 확인하고 세부 기능을 이용할 수 있습니다.

메뉴 진입하기

(1) Admin 모드로 전환하기



컬렉터 생성 및 관리

➊ 컬렉터 생성

(1) Admin 모드 - [에셋인벤토리 > 컬렉터] 로 이동

(2) [+ 생성] 버튼 클릭

(3) 수집하고자 하는 데이터에 맞는 컬렉터를 선택

  • 컬렉터 플러그인에 대한 자세한 설명은 여기를 참고 하십시오.

(4) Step 1부터 4까지 진행

  • 생성 마지막 단계(Step 4)에서는 수집 스케줄 설정을 할 수 있으며, 생성 완료 후 '데이터 즉시 수집' 또한 가능합니다.


➋ 컬렉터 수정/삭제

(1) Admin 모드 - [에셋인벤토리 > 컬렉터] 로 이동

(2) 생성된 컬렉터 리스트 중 수정하고자 하는 컬렉터 선택

(3) 선택한 컬렉터의 상세페이지로 이동하여 영역별 [수정] 가능

  • 기본정보 / 스케줄 / 추가 옵션

(4) 컬렉터 이름 수정 또는 삭제

  • 맨 상단 컬렉터 이름 옆 [✏️] 편집 버튼을 통해 컬렉터 이름 수정 가능
  • 맨 상단 컬렉터 이름 옆 [🗑️] 삭제 버튼을 통해 컬렉터 삭제 가능


➌ 데이터 수집

(1) Admin 모드 - [에셋인벤토리 > 컬렉터] 로 이동

(2) 특정 컬렉터에 마우스 오버시 나타나는 [데이터 수집] 버튼을 통해 즉시 수집 가능

(3) 특정 컬렉터를 클릭하여 상세페이지로 이동 후 상단 [데이터 수집] 버튼을 통해 즉시 수집 가능



도메인 내 전체 자원 확인

Admin 모드에서는 도메인 내 전체 워크스페이스에서 수집된 자원을 한번에 확인할 수 있습니다.

(1) [에셋인벤토리 > 클라우드 서비스]: 클라우드 서비스의 자원 전체 현황

(2) [에셋인벤토리 > 서버]: 클라우드 서비스의 자원 중 서버 현황

(3) [에셋인벤토리 > 보안]: 생성한 보안 플러그인의 프레임워크별 보안 현황 및 체크 리스트

4.3.9 - 전체 비용 관리

도메인 내 전체 워크스페이스의 비용을 확인하고 세부 기능을 이용할 수 있습니다.

메뉴 진입하기

(1) Admin 모드로 전환하기



전체 비용 분석

전체 워크스페이스에서 발생한 비용을 한번에 확인할 수 있습니다.

(1) Admin 모드 - [비용 관리 > 비용 분석]으로 이동

(2) 그룹별 통계(Group-by) 에서 'Workspace' 탭 클릭 하여 워크스페이스별 비용 확인

(3) [필터] 설정을 통한 세부 분석

(4) 비용 분석 저장 가능

  • 기본 제공 분석 페이지(예: Monthly cost by workspace): [다른 이름으로 저장] 만 가능
  • 커스텀 비용 분석 페이지: 바로 [저장] 또는 [다른 이름으로 저장], [수정/삭제] 모두 가능



워크스페이스별 예산 설정/관리

전체 발생한 비용 대비 워크스페이스 기준의 예산 생성 및 관리가 가능합니다.

(1) Admin 모드 - [비용 관리 > 예산]으로 이동

[예산 설정 방법]

a. [+ 예산 생성] 버튼 클릭

b. 특정 워크스페이스와 빌링 데이터 소스에 맞는 예산 설정

  • 이름 입력
  • 워크스페이스 선택
  • 데이터 소스 선택
  • 예산 계획 선택 (총 예산 또는 월별 예산)
  • [확인] 버튼 클릭



비용 리포트 설정/관리

전체 워크스페이스에서 발생한 비용의 리포트를 한 번에 확인할 수 있도록 세부 설정을 진행할 수 있습니다.

(1) Admin 모드 - [비용 관리 > 비용 리포트]로 이동

(2) '다음 리포트' 위젯에서 [설정] 버튼 클릭하여 리포트 설정

  • 언어/통화/발행일 선택

(3) '리포트 수신처' 위젯에서 수선처 설정

  • 리포트 자동 발송을 위한 수신처 활성화

(4) 전체 리포트 확인

  • 비용 트렌드
  • 월별 총 비용 요약

(5) 특정 리포트 클릭하여 상세 확인

4.4 - 프로젝트

프로젝트를 생성하여, 워크스페이스별로 수집되는 클라우드 리소스 또는 비용 등을 체계적으로 관리할 수 있습니다.

아래와 같이 특정 워크스페이스 환경에 프로젝트 그룹 > 프로젝트 구조로 생성할 수 있습니다.

4.4.1 - 프로젝트

프로젝트는 특정 워크스페이스 내 리소스를 관리하기 위한 묶음 단위입니다.

특정 워크스페이스로 전환

  • 관리하고자 하는 워크스페이스를 선택하여 환경 전환
  • 프로젝트 메뉴로 이동



프로젝트 생성하기

(1) 우측 상단 [+ 생성] > [프로젝트] 버튼 클릭

(2) 프로젝트 이름 입력, 접근 방식 선택

프로젝트의 관리 목적에 따라 아래 두 가지 접근 방식 중 선택하여 생성할 수 있습니다.

  • 초대된 사용자만 접근 - 워크스페이스 내 Workspace Member 역할 타입의 사용자 접근 제한을 위해 선택
  • 워크스페이스 내 모든 사용자 접근

(3) [확인] 버튼 클릭하여 프로젝트 생성 완료

(4) (선택사항) 프로젝트 그룹 생성

  • [+ 생성] > [프로젝트 그룹] 버튼 클릭해서 그룹을 생성하고, 특정 프로젝트별로 묶음(카테고리)을 설정할 수도 있습니다.



프로젝트 설정 변경하기

(1) 특정 프로젝트 클릭 하여 상세 페이지로 이동 > 상단의 설정 버튼 클릭

(2) 프로젝트 이름, 접근 방식 변경 후 [확인] 버튼 클릭



프로젝트 위치 이동하기

(1) 특정 프로젝트 클릭 하여 상세 페이지로 이동 > 상단의 이동 버튼 클릭

(2) 이동할 위치(프로젝트 그룹) 선택 후 [확인] 버튼 클릭



프로젝트 삭제하기

(1) 특정 프로젝트 클릭 하여 상세 페이지로 이동 > 상단의 삭제 버튼 클릭



프로젝트에 데이터 연결하기



프로젝트 세부 관리하기

4.4.2 - 멤버

사용자는 접근 가능한 프로젝트에 연결된 리소스를 중심으로 서비스를 이용할 수 있으며,

프로젝트별로 접근 방식에 따라 멤버를 다르게 관리할 수 있습니다.

프로젝트 멤버 관리하기

(1) 특정 프로젝트 선택

(2) 해당 프로젝트의 [멤버] 탭 선택

  • 워크스페이스 내 전체 사용자가 접근 가능한 프로젝트의 경우, 해당 워크스페이스에 있는 전체 사용자가 멤버로 간주됩니다.

  • 초대된 사용자만 접근 가능한 프로젝트의 경우, 해당 워크스페이스에 있는 사용자 중에서 초대하여 접근 권한을 부여할 수 있습니다.

4.5 - 대시보드

빌링, 에셋과 같은 (멀티) 클라우드 데이터를 시각적으로 표현하여 복잡한 정보를 직관적으로 이해할 수 있도록 대시보드 서비스를 제공합니다. 다양한 구성의 차트, 그래픽 요소를 지원하기 때문에 중요 데이터의 핵심을 빠르게 파악할 수 있습니다.

사용자는 기본 제공의 대시보드 외에도 원하는 데이터를 한눈에 파악하기 위해 특정 위젯을 조합한 맞춤형 대시보드를 생성할 수 있습니다. 또한, 각 대시보드마다 Variable(변수), 날짜 범위 및 각 위젯의 세부 옵션을 정밀하게 설정할 수 있어, 조직의 요구사항에 맞춰 보다 정확하고 전문적인 대시보드를 구축하고 관리할 수 있습니다.

4.5.1 - 대시보드 템플릿

기본 템플릿을 활용하면 좀 더 쉽고, 빠르게 대시보드를 생성할 수 있습니다.

월별 비용 통계

클라우드 비용 발생 현황 및 예산 사용 상태를 다양한 그룹별 통계 기준으로 차트화한 대시보드입니다.

Cost(비용) 관련 위젯들로 구성이 되어 있으며, 대시보드 Variable(변수) 항목 중 Data Source가 필수적으로 1개 선택되어 있습니다.

dashboard-basic-page-01


CDN 및 트래픽 비용

CDN & Traffic 관련 특정 클라우드 프로덕트의 비용과 사용량을 파악할 수 있도록 현황을 차트화한 대시보드입니다. 대시보드 Variable(변수) 항목 중 Data Source가 필수적으로 1개 선택되어 있습니다.

dashboard-basic-page-02


컴플라이언스 상태 관리

Compliance 구성 검사 및 모니터링 결과를 차트화한 대시보드입니다. Compliance Framework가 필수적으로 1개 선택되어 있습니다.

dashboard-basic-page-03

4.5.2 - 대시보드 생성

기본으로 제공하는 대시보드 외에 데이터 중요도, 특성에 따라 다양한 위젯을 활용하여 커스텀 대시보드를 생성하고 관리할 수 있습니다.

특정 워크스페이스로 전환

  • 관리하고자 하는 워크스페이스를 선택하여 환경 전환


대시보드 생성하기

아래 순서에 따라 대시보드를 만들 수 있습니다.

(1) 상단 메뉴의 [대시보드 > 새 대시보드 생성] 클릭 또는 [대시보드] 서비스 내 좌측 메뉴 상단의 [+] 버튼 클릭하여 생성하기 페이지로 이동합니다.


(2) [대시보드 생성] 페이지에서 대시보드 범위와 공개 여부를 선택합니다.

  • 전체 워크스페이스 : 워크스페이스 내 전체 프로젝트에 대한 데이터로 구성 됩니다.
  • 개별 프로젝트 : 특정 프로젝트를 선택하여 범위 설정 시, 해당 프로젝트의 데이터로만 구성 됩니다.
  • 비공개 : 생성한 사용자만 볼 수 있는 대시보드입니다.

(3) 제공하는 기본 템플릿을 선택하거나, 기존 대시보드를 복제할 수 있습니다.

  • 원하는 옵션을 선택한 후 [계속하기] 버튼을 클릭합니다.

dashboard-create-04


(4) 대시보드 이름을 입력한 후, 기본 위젯을 활용하여 대시보드를 생성할 수 있습니다.

  • 편집 관련 상세 설명은 여기를 참고하십시오.

dashboard-create-05


(5) 생성 완료된 대시보드는 [모든 대시보드 보기] 페이지에서 [공개 여부], [범위]에 따라 구분하여 확인 가능합니다.

dashboard-create-06


생성된 대시보드 확인 및 빠른 설정은 여기을 참고하십시오.

4.5.3 - 대시보드 편집

대시보드 [편집] 모드에서 대시보드 이름, 레이아웃, 위젯 등을 수정할 수 있습니다.

대시보드 편집하기

편집 모드 이동하기

대시보드 페이지에서 오른쪽의 [편집] 버튼을 클릭하면 대시보드 편집 페이지로 이동합니다.

dashboard-edit-intro-01


이름 편집하기

대시보드 제목 옆의 [편집] 아이콘 버튼을 클릭해서 변경할 수 있습니다.

dashboard-edit-name-01


레이블 추가하기

상단 대시보드 이름 바로 하단에서 레이블을 추가/삭제 할 수 있습니다. 레이블은 대시보드 관련 카테고리, 특징 등을 구분하는데 이용되며, 이후 대시보드 검색시 유용하게 활용될 수 있습니다.

dashboard-edit-label-01


기간 적용하기

(1) [기간 적용 옵션]을 활성화할 경우, 해당 대시보드에 기간을 설정할 수 있는 드랍다운 버튼이 보여집니다.

dashboard-edit-duration-01

(2) 기간 드롭다운에서 특정 월을 선택하거나, [커스텀] 메뉴를 통해 최근 3개년 기간 중에 특정 월을 선택할 수 있습니다.

dashboard-edit-duration-02


데이터 새로고침 설정하기

대시보드 우측 상단의 [새로고침] 드롭다운에서 데이터 갱신 주기를 선택할 수 있습니다.

dashboard-edit-refresh-01


위젯 추가하기

(1) 오른쪽의 대시보드 편집 페이지의 [위젯 추가] 버튼을 클릭합니다.

dashboard-edit-add-widget-01


(2) 좌측 위젯 목록 중 특정 위젯을 선택하여 추가합니다.

dashboard-edit-add-widget-02

(2-2) 특정 위젯을 선택했다면, [이름] 입력 후 세부 옵션을 설정합니다.

dashboard-edit-add-widget-03

(2-3) 추가하고자 하는 옵션이 없을 경우, [+옵션 추가] 버튼을 클릭하여 추가할 수 있습니다.

dashboard-edit-add-widget-04

(2-4) 설정이 마무리되었다면, [확인] 버튼을 클릭하여 대시보드에 위젯 추가를 완료합니다.


위젯 순서 변경하기

우측 패널의 위젯 목록에서 위젯 이름 버튼을 드래그 & 드롭하여 순서를 변경할 수 있습니다.

dashboard-edit-change-widget-01


위젯 크기 조정하기

전체화면으로 보고 싶은 위젯 오른쪽 상단의 [전체화면] 아이콘 버튼을 클릭합니다.

dashboard-edit-full-screen-01

dashboard-edit-full-screen-02


위젯 편집하기

(1) 위젯 우측 상단에 있는 [편집] 아이콘 버튼을 클릭합니다.

dashboard-update-widget-01

(2) 위젯 이름 및 옵션을 수정하고, [확인] 버튼을 클릭하여 저장합니다. (단, [편집] 모드에서 대시보드 [저장]을 하지 않을 경우, 저장한 위젯은 최종 반영되지 않습니다.)

  • 위젯 옵션 설정 관련 내용은 여기를 참고하십시오.

dashboard-update-widget-02

4.5.4 - 대시보드 확인 및 빠른 설정

대시보드 [편집] 모드에서는 새로운 위젯 추가 및 상세 레이아웃 관리가 가능했다면, 대시보드 [보기] 모드에서는 데이터 확인뿐 아니라 이름, 레이블 수정 삭제 및 빠른 위젯 수정이 가능합니다.

대시보드 이름 편집/삭제/복제

이름 편집하기

(1) 대시보드 이름 옆의 [편집] 아이콘 버튼을 클릭합니다.

dashboard-setup-edit-name-01

(2) 대시보드의 이름을 변경한 뒤 [확인] 버튼을 클릭합니다.

dashboard-setup-edit-name-02

삭제하기

(1) 대시보드 이름 옆의 [휴지통] 아이콘 버튼을 클릭합니다.

dashboard-delete-02

(2) [대시보드 삭제] 모달의 [확인] 버튼을 클릭하여 대시보드를 삭제합니다.

dashboard-delete-03

복제하기

(1) 대시보드 이름 옆의 [복제] 버튼을 클릭합니다.

dashboard-setup-duplicate-01

(2) 대시보드를 복제 폼에서 다음 항목들을 설정할 수 있습니다.

dashboard-setup-duplicate-02

  • 대시보드 이름
  • 공개 여부: 비공개와 공개 중 하나를 선택합니다.

레이블 추가하기

여기 페이지에서와 동일하게 레이블 추가/삭제가 가능합니다.

dashboard-setup-label-01


필터 설정하기

필터를 설정하면 대시보드의 데이터를 원하는 조건으로 필터링하여 볼 수 있습니다.

(1) 대시보드 상단의 Variable(변수) 항목 중 원하는 항목의 세부 옵션을 선택합니다.

dashboard-setup-filter-01

(2) 앞전에 저장된 설정과 차이가 있을 경우, 우측에 [저장] 버튼이 활성화되며 이를 통해 빠르게 변경을 저장할 수 있습니다.

dashboard-setup-filter-02

(3) 옵션을 변경 중 최근에 저장된 값으로 되돌리고 싶을 경우, [초기화] 버튼을 클릭합니다.

dashboard-setup-filter-03

(4) [+ 추가] > [변수 관리] 버튼을 클릭하여, 변수 전체 항목에 대해 확인할 수 있으며, 커스텀 변수 추가 또한 가능합니다.

dashboard-setup-filter-04

(4-1) 커스텀 변수 추가가 필요할 경우, [변수 관리] 창의 우측 상단에 [+변수 추가] 버튼을 클릭합니다.

dashboard-setup-filter-05

(4-2) 추가 원하는 변수의 기본 정보를 입력한 후, [저장] 버튼을 클릭합니다.

dashboard-setup-filter-06


기간 설정하기

대시보드 우측 상단의 [기간] 드롭다운에서 특정 월을 선택하거나, [커스텀] 메뉴를 통해 최근 3개년 기간 중에 특정 월을 선택할 수 있습니다.

dashboard-setup-duration-01


데이터 새로고침 설정하기

대시보드 우측 상단의 [새로고침] 드롭다운에서 데이터 갱신 주기를 선택할 수 있습니다.

dashboard-setup-refresh-01


위젯 전체보기 및 설정 편집하기

(1) 특정 위젯의 우측 상단에 있는 [전체화면] 아이콘 버튼을 클릭합니다.

dashboard-setup-full-screen-01

(2) 전체화면에서는 상세한 위젯 데이터 확인이 가능합니다. 상단 필터 항목은 대시보드 Variable(변수)와 동일한 항목으로, 각 옵션들을 변경해보며, 해당 위젯의 데이터를 자세히 확인해 볼 수 있습니다.

dashboard-setup-full-screen-02

(3) 위젯의 세부 수정이 필요시, 우측 상단의 [옵션 편집] 버튼을 클릭합니다.

dashboard-setup-full-screen-03

(4) [편집] 모드에서와 동일하게, 위젯의 세부 항목을 수정하고 저장할 수 있습니다.

  • 위젯 옵션 설정 관련 내용은 이 곳을 참고하십시오.

dashboard-setup-full-screen-04

4.6 - 에셋 인벤토리

에셋 인벤토리에서는 사용자가 등록한 클라우드 서비스 계정을 기반으로 리소스를 수집하고, 그 수집된 리소스를 조회할 수 있습니다.

클라우드 프로바이더: AWS, Google Cloud, Azure 등 클라우드 서비스를 제공하는 클라우드 제공자를 말합니다.

클라우드 서비스: 프로바이더가 제공하는 클라우드 서비스로, 예를 들어 AWS의 EC2 Instance가 이에 해당합니다.

클라우드 리소스: 클라우드 서비스의 리소스들로, 예를 들어 AWS의 EC2 Instance의 서버들이 이에 해당합니다.

4.6.1 - Quick Start

에셋 인벤토리 서비스를 빠르게 사용하기 위한 과정을 소개합니다.

메뉴 진입하기

(1) 특정 워크스페이스 선택

(2) [에셋 인벤토리 > 서비스 어카운트]로 이동



서비스 계정 생성하기

(1) 추가할 클라우드 서비스(프로바이더)를 선택합니다.

(2) [추가] 버튼을 클릭합니다.

(3) 서비스 어카운트 생성 폼을 작성

(3-1) 기본 정보를 입력합니다.

service-account-add-base-info

(3-2) 해당 서비스 계정에 따른 리소스를 수집할 프로젝트를 지정합니다.

service-account-connect-project


(3-3) 암호화 키 정보를 입력합니다.

service-account-add-key



자원 수집하기

[에셋 인벤토리 > 컬렉터] 페이지에서는 해당 워크스페이스 내에 자원 수집을 수행할 수 있는 컬렉터 목록을 확인할 수 있습니다.

(1) 특정 컬렉터에 마우스 오버

Admin에 의해 관리됨 으로 표시되는 컬렉터의 경우,

Admin 모드에서 생성된 Global 범위의 컬렉터로 스케줄과 정보 수정은 불가하며, 데이터 수집만 가능합니다.



컬렉터 생성하기

[에셋 인벤토리 > 컬렉터] 페이지에서 리소스를 수집할 컬렉터를 생성합니다.

(1) [생성] 버튼을 클릭합니다.

collector-create-button

(2) 리소스 수집 시 사용할 플러그인을 선택합니다.

collector-plugin-list

(3) 컬렉터 생성 폼을 작성합니다. (3-1) 이름과 버전 등 기본 정보를 입력합니다.

collector-create-base-info

(3-2) 필요 시 태그를 추가합니다.

collector-create-tag

(4) 컬렉터 실행을 위한 스케줄을 생성합니다.

(4-1) [에셋 인벤토리 > 컬렉터] 페이지에서 테이블의 컬렉터 하나를 선택한 뒤, [스케줄] 탭에서 [추가] 버튼을 클릭합니다.

collector-single-select

(4-2) [스케줄 추가] 모달에서 컬렉터를 실행할 시간을 설정한 뒤 [확인] 버튼을 클릭합니다.

collector-schedule-modal

수집된 리소스 확인하기

[에셋 인벤토리 > 클라우드 서비스]에서 수집된 리소스를 조회할 수 있습니다.

collector-resource-inquiry

4.6.2 - 클라우드 서비스

컬렉터를 통해 수집된 여러 클라우드 리소스들을 통합적으로 조회하고 이용 현황을 파악할 수 있습니다.

클라우드 서비스 목록 조회하기

클라우드 서비스 페이지에서는 프로바이더별 클라우드 서비스 이용 현황을 보여줍니다.

고급 검색과 필터 설정을 통해 세밀한 조건으로 목록을 필터링할 수 있습니다.

프로바이더 선택

프로바이더를 선택하여 특정 프로바이더를 통해 제공되는 클라우드 서비스만을 조회합니다.

cloud-service-provider-menu

필터 설정

서비스 분류와 리전 필터를 설정하여 보다 세부적인 조건 검색이 가능합니다.

(1) [설정] 버튼을 클릭하면 [필터 설정] 모달이 열립니다.

cloud-service-filter-button

(2) 원하는 필터를 선택한 후 [확인] 버튼을 클릭해 적용합니다.

cloud-service-filter-modal

클라우드 서비스 살펴보기

클라우드 서비스 상세 페이지에서 특정 클라우드 서비스의 상세 정보를 확인할 수 있습니다.

클라우드 서비스 페이지에서 카드를 클릭하면 상세 페이지로 이동합니다.

cloud-service-select

왼쪽의 클라우드 서비스 목록에서 선택된 클라우드 서비스에 대한 상세 정보를 확인할 수 있습니다.

cloud-service-list-lnb

클라우드 서비스의 리소스 목록 조회하기

검색어를 입력하여 조건에 부합하는 클라우드 리소스 목록을 확인할 수 있습니다.

고급 검색에 대한 상세 설명은 여기를 참고 하십시오.

[엑셀] 아이콘 버튼을 클릭하여 리소스 목록을 엑셀 파일로 내보내기 하거나, [설정] 아이콘 버튼을 클릭하여 테이블 필드 개인화를 할 수 있습니다.

cloud-sevice-detail-full-page

클라우드 서비스 이용 현황 보기

선택한 클라우드 서비스에 대한 통계 정보를 확인할 수 있습니다.

cloud-service-single-select

더욱 자세한 내용을 확인하려면, 오른쪽의 [차트 보기] 버튼을 클릭하여 확인할 수 있습니다.

cloud-service-chart-modal

클라우드 리소스 콘솔 열기

때로는 클라우드 리소스의 프로바이더에서 제공하는 콘솔에서 작업을 해야 하는 경우가 있습니다.

(1) 콘솔을 연결하려는 클라우드 리소스를 선택합니다.

(2) [콘솔 연결] 버튼을 클릭합니다.

cloud-service-connect-console

(3) 버튼을 클릭하면 해당 클라우드 리소스에 대한 작업을 이어나갈 수 있는 프로바이더의 콘솔이 새 탭으로 열립니다.

아래는 AWS의 EC2 Instance의 콘솔이 열린 예시입니다.

cloud-service-console-opened

클라우드 서비스의 리소스 살펴보기

클라우드 리소스 목록에서 살펴보고자 하는 항목을 선택하면, 하단에서 해당 리소스에 대한 정보를 확인할 수 있습니다.

cloud-resource-single-select

클라우드 리소스 상세 정보 확인하기

선택한 리소스에 대한 자세한 정보를 보여줍니다.

여기에 표시되는 정보는 기본 탭과 추가 정보 탭으로 나뉩니다.

  • 기본 탭: 클라우드 리소스 상세 정보에 기본적으로 제공되는 것으로, [기본 정보], [원본 데이터] 탭이 이에 해당됩니다.
  • 추가 정보 탭: 기본 탭을 제외한 모든 탭들은 해당 리소스를 수집한 컬렉터의 플러그인에 의해 결정됩니다. 자세한 설명은 여기를 참고 하십시오.

cloud-resource-info-tab

위의 이미지는 클라우드 리소스 상세 정보 예시입니다.

[기본 정보] 탭과 [원본 데이터] 탭을 제외한 나머지 탭들(AMI, Permission, Tags)은 모두 컬렉터의 플러그인에 의해 추가된 정보입니다.

클라우드 리소스 태그 관리하기

클라우드 리소스에는 Managed , Custom 두가지 타입의 태그가 존재합니다. 개별 클라우드 리소스별로 해당 프로바이더로 부터 가져온 Managed 태그를 확인할 수 있으며, 별도로 Custom 태그를 추가하여 관리할 수 있습니다.

키: 값 의 형태로 구성된 각 태그는 리소스 검색시에 유용하게 이용할 수 있습니다.

cloud-resource-tag-tab

[ Managed 태그 조회 하기 ]

  • Managed 태그는 Cloudforet에서 직접 수정 및 삭제가 불가합니다.

cloud-resource-tag-tab

[ Custom 태그 조회 하기 ]

(1) [Custom 태그 수정] 버튼을 클릭합니다.

cloud-resource-tag-tab

(2) 커스텀 태그 수정 페이지에서 키: 값 형태로 태그를 입력 후 [저장] 버튼을 클릭하여 완료합니다.

cloud-resource-tag-tab

클라우드 리소스에 연관된 멤버 확인하기

[연관된 멤버] 탭에서는 아래의 조건에 해당되는 사용자 정보를 확인할 수 있습니다.

cloud-resource-member-tab

클라우드 리소스 변경 기록 확인하기

[변경 이력] 탭에서는 선택한 클라우드 리소스의 날짜/시간별로 변경사항을 빠르게 파악할 수 있습니다.

(1) 특정 날짜 선택 또는 검색을 통해 확인하고자 하는 세부 내역을 추려낼 수 있습니다.

cloud-resource-changes-tab

(2) 특정 키값 또는 특정 시간대 전체 클릭시, 해당하는 변경 이력 상세를 확인할 수 있습니다.

(2-1) 변경내역: 해당 리소스의 어떤 Key값들이 어떻게 업데이트 되었는지 상세 내역을 확인할 수 있습니다.

cloud-history-diff-tab

(2-2) 로그: AWS CloudTrail와 같은 Provider별 상세 로그를 지원하여, 선택한 시간내/외로 어떤 세부 이벤트가 발생했는지 확인할 수 있습니다. 이에 따라, 특정 리소스를 변경한 유저를 파악할 수 있는 큰 장점이 있습니다.

cloud-history-log-tab

확인하고자 하는 값의 키를 클릭하여 상세 로그를 확인할 수 있습니다.

cloud-history-log-modal

(2-3) 노트: 선택한 타임에 노트를 추가/관리 함으로써, 어떤 담당자와 해당 변경이 관련이 있는지, 어떤 프로세스로 해당 이슈를 해결할지 등 기업별 워크플로우를 자유롭게 관리할 수 있습니다.

cloud-history-note-tab

클라우드 리소스 모니터링 정보 확인하기

[모니터링] 탭에서는 클라우드 리소스에 대하여 다양한 메트릭을 보여줍니다.

cloud-resource-monitoring-tab

[시간 범위] 필터를 변경하거나, [통계] 드롭다운에서 다른 통계 방식을 선택하여 다른 기준에 대한 메트릭을 확인할 수도 있습니다.

상단의 클라우드 리소스 목록에서 왼쪽의 체크박스를 클릭하여 여러 개의 리소스를 선택하면, 다수의 리소스에 대한 메트릭 정보를 비교하여 살펴볼 수 있습니다.

cloud-resource-multi-monitoring

메트릭 정보는 모니터링 플러그인에 의해 수집되며, 자세한 내용은 여기를 참고 하십시오.

4.6.3 - 서버

컬렉터를 통해 수집되는 여러 클라우드 서비스의 리소스들 중 서버 리소스를 확인할 수 있습니다.

서버 리소스 목록 조회하기

[에셋 인벤토리 > 서버] 메뉴를 통해 서버 페이지에 진입하여 서버 리소스 목록을 확인할 수 있습니다.

고급 검색을 통해 세밀한 조건으로 목록을 필터링할 수 있습니다.

[엑셀] 아이콘 버튼을 클릭하여 리소스 목록을 엑셀 파일로 내보내기 하거나, [설정] 아이콘 버튼을 클릭하여 테이블 필드 개인화를 할 수 있습니다.

server-full-page

서버 리소스 콘솔 열기

때로는 서버 리소스의 프로바이더에서 제공하는 콘솔 사이트에서 작업을 해야 하는 경우가 있습니다.

(1) 콘솔을 연결하려는 서버 리소스를 선택합니다.

(2) [콘솔 연결] 버튼을 클릭합니다.

server-console-connect

(3) 버튼을 클릭하면 해당 서버 리소스에 대한 작업을 이어나갈 수 있는 프로바이더의 콘솔이 새 탭으로 열립니다.

아래는 AWS의 EC2 Instance의 콘솔이 열린 예시입니다.

server-console-opened

서버 리소스 살펴보기

서버 리소스 목록에서 살펴보고자 하는 항목을 선택하면, 하단에서 해당 리소스에 대한 정보를 확인할 수 있습니다.

[에셋 인벤토리 > 클라우드 서비스] 메뉴의 클라우드 서비스 리소스 살펴보기와 동일합니다.

4.6.4 - 컬렉터

클라우드포레는 컬렉터를 통해 클라우드 리소스들을 수집하며, 스케줄링을 통해 수집 시기를 결정할 수 있습니다.

개요

컬렉터로 데이터를 수집하기 위해서는 다음 두 가지 요소가 필요합니다.

1. 컬렉터 플러그인

클라우드 프로바이더로부터 어떤 리소스들을 수집할지, 수집한 데이터들을 어떻게 화면에 보여줄지에 대한 스펙이 정의된 요소입니다.

프로바이더 별로 가지고 있는 데이터의 구조와 내용이 상이하므로 컬렉터는 철저히 컬렉터 플러그인에 의존하여 리소스들을 수집합니다.

이에 대한 자세한 설명은 여기를 참고 하십시오.

2. 서비스 어카운트

리소스를 수집하기 위해서는 클라우드 프로바이더(ex. AWS, GCP, Azure)의 계정에 연결이 필요합니다.

서비스 어카운트는 프로바이더의 계정에 연결하기 위한 계정 정보입니다.

컬렉터는 기존에 프로바이더 별로 만들어져 있는 서비스 어카운트를 통해 프로바이더 계정에 접근합니다.

이에 대한 자세한 설명은 여기를 참고 하십시오.



컬렉터 생성하기

(1) 왼쪽 상단의 [+ 생성] 버튼을 클릭합니다.

collector-create-button

(2) [신규 컬렉터 생성‌] 페이지에서 아래 단계를 거칩니다.

(2-1) 플러그인 목록 페이지에서 원하는 컬렉터 플러그인을 찾아 [선택] 버튼을 클릭합니다.

collector-plugin-create

(2-2) 컬렉터의 이름 작성 및 버전을 선택한 후 [계속하기] 버튼을 클릭합니다.

(컬렉터에 따라 특정 클라우드 프로바이더 선택이 필요할 수도 있습니다.)

collector-plugin-create


(2-3) 컬렉터의 추가 옵션을 선택한 후 [계속하기] 버튼을 클릭합니다.

(2-3-1) 서비스 어카운트: 전체 또는 특정 서비스 어카운트를 선택합니다. 전체일 경우, 컬렉터와 관련 있는 프로바이더의 서비스 어카운트가 자동으로 선택되어 수집을 진행합니다.

(2-3-2) 추가 옵션: 컬렉터별 추가 옵션은 상이하기 때문에 경우에 따라 없을 수도 있습니다.

collector-plugin-create

(2-4) 매일 자동으로 데이터 수집을 진행할 수 있도록 스케줄링을 설정할 수 있습니다.(선택사항)
모든 단계를 거쳤다면, [신규 컬렉터 생성] 버튼을 클릭하여 컬렉터 생성을 완료합니다.

collector-plugin-create

(2-5) 컬렉터 생성이 완료되었다면, 즉시 데이터 수집을 시작할 수 있습니다.

collector-plugin-create


컬렉터 목록 조회하기

컬렉터 페이지에서 생성되어 있는 모든 컬렉터 목록을 조회할 수 있습니다.

고급 검색을 통해 세밀한 조건으로 목록을 필터링할 수 있습니다. 상세 설명은 여기를 참고 하십시오.

(1) 워크스페이스 내에 직접 생성한 컬렉터 목록

collector-list-inquiry

(2) Admin(관리자)가 생성한 컬렉터 목록

  • Admin 모드에서 생성된 Global 컬렉터의 경우 특정 워크스페이스 내에서는 스케줄 수정이 불가하며, 데이터 수집은 가능합니다.
  • Admin 역할을 가진 사용자만이 Admin 모드로 전환하여 Global 범위의 컬렉터를 생성하고 관리할 수 있습니다.


컬렉터 상세 정보 확인 및 수정/삭제하기

(1) 컬렉터 상세 정보 확인

(1-1) 컬렉터 목록에서 특정 컬렉터 카드 영역을 선택하여 상세 페이지로 이동합니다.

collector-list-select

(1-2) 기본 정보, 스케줄, 컬렉터 옵션 및 연결된 서비스 어카운트를 확인할 수 있습니다.

collector-detail-info-tab


(2) 컬렉터 수정/삭제하기

(2-1) 상단의 [편집] 아이콘을 클릭하여 컬렉터 이름을 수정할 수 있습니다.

collector-detail-edit

(2-2) 기본 정보, 스케줄, 컬렉터 옵션, 서비스 어카운트와 같은 세부 수정 필요시, 해당 영역의 [수정] 버튼을 클릭합니다.

collector-detail-edit

(2-3) 값을 변경한 후 [변경 저장] 버튼을 클릭하여 수정을 완료합니다.

collector-detail-edit

(2-4) 컬렉터 삭제하기 상단의 [삭제] 아이콘을 클릭하여 컬렉터를 삭제할 수 있습니다.

collector-detail-delete


자동 수집 설정하기

컬렉터 생성 후에도 각 컬렉터 별 자동 수집 스케줄을 변경할 수 있습니다.

(1) 컬렉터 목록 페이지의 각 컬렉터 카드 영역에 스케줄 토글 버튼을 통해 자동 수집 활성화/비활성화가 가능하며, [수정] 버튼을 클릭하여 빠르게 시간 주기를 설정하고 변경할 수 있습니다.

collector-edit-schedule

collector-edit-schedule

collector-edit-schedule

(2) 각 컬렉터의 상세 페이지로 이동해서 스케줄을 변경할 수도 있습니다.

collector-edit-schedule


일회성 데이터 수집하기

자동 수집 설정 없이 일회성으로 데이터를 수집할 수 있습니다.

이 기능을 사용하면 컬렉터에 자동 수집 스케줄이 없는 상태여도 데이터 수집이 이뤄집니다.

데이터 수집은 두 가지 방식으로 동작합니다.

연결된 전체 서비스 어카운트에 대하여 데이터 수집하기

컬렉터는 데이터 수집을 위해 프로바이더의 계정 정보를 필요로 하며, 이는 서비스 어카운트을 통해 등록됩니다.

(1) 데이터 수집

(컬렉터 목록 페이지) 데이터를 수집할 컬렉터 카드 영역에 마우스 오버 후, [데이터 수집] 버튼을 클릭합니다.

collector-collect-data

(컬렉터 상세 페이지) 상세 페이지 우측 상단에 [데이터 수집] 버튼을 클릭합니다.

collector-collect-data

collector-collect-data


(2) 데이터 수집 진행

해당 컬렉터에 연결된 서비스 어카운트들에 대하여 데이터 수집을 시작합니다. 데이터 수집을 완료했는지 여부는 컬렉터 히스토리에서 확인 가능합니다. 해당 컬렉터 카드 영역 아랫부분의 [컬렉터 히스토리 전체보기] 버튼 또는 페이지 우측 상단의 [컬렉터 히스토리] 버튼을 클릭하여 컬렉터 수집 기록 페이지로 이동할 수 있습니다.


하나의 서비스 어카운트에 대하여 데이터 수집하기

컬렉터로 데이터를 수집할 때에 특정한 클라우드 프로바이더 계정의 데이터만을 수집할 수도 있습니다.

(1) 컬렉터 목록에서 데이터를 수집할 컬렉터를 클릭하여 상세 페이지로 이동합니다.

(2) 페이지 하단의 [연결된 서비스 어카운트‌] 영역에서 데이터 수집 시 사용되는 서비스 어카운트 목록 확인이 가능합니다.

collector-service-account

(3) 데이터를 수집하고자 하는 서비스 어카운트 오른쪽 [데이터 수집] 버튼을 클릭하여 수집을 시작 합니다.


데이터 수집 내역 확인하기

컬렉터 히스토리 페이지에서 데이터 수집 내역을 확인할 수 있습니다.

컬렉터 페이지 상단의 [컬렉터 히스토리] 버튼을 클릭하여 컬렉터 히스토리 페이지로 이동할 수 있습니다.

collector-history-at-table

collector-history-at-table

데이터 수집 내역 상세 정보 확인하기

위의 데이터 수집 목록에서 수집 내역을 선택하면 수집 내역 상세 페이지로 이동합니다.

데이터 수집 상태와 기본 정보, 그리고 서비스 어카운트 별 수집 내역을 확인할 수 있습니다.

collector-history-detail-full-page

서비스 어카운트 별 수집 내역 확인하기

컬렉터를 실행하면 연결된 서비스 어카운트 별로 수집이 각각 이뤄집니다.

여기에서는 서비스 어카운트 별로 수집 작업이 어떻게 이뤄졌는지에 대한 정보 확인할 수 있습니다.

collector-history-detail-table

주요 필드 정보
  • Created Count: 새롭게 추가된 리소스의 개수
  • Updated Count: 가져온 리소스의 개수
  • Disconnected Count: 가져오지 못한 리소스의 개수
  • Deleted Count: 삭제된 리소스의 개수 (여러 번 가져오지 못하면 삭제된 것으로 간주됩니다.)

수집 에러 내용 확인하기

(1) 계정 별 수집 목록에서 에러 내용을 확인하고자 하는 항목을 선택합니다.

(2) 아래의 [에러 목록] 탭에서 오류에 대한 자세한 내역을 확인할 수 있습니다.

collector-history-error-list

4.6.5 - 서비스 어카운트

서비스 어카운트에서 각 클라우드 서비스의 계정들을 손쉽게 통합, 관리, 추적할 수 있습니다.

서비스 어카운트 생성하기

생성할 수 있는 어카운트 타입은 General Account, Trusted Account 두 가지로 나뉩니다.

General Account 생성하기

(1) [에셋 인벤토리 > 서비스 계정] 페이지에서 추가할 클라우드 서비스를 선택합니다.

service-account-provider-menu

(2) [추가] 버튼을 클릭합니다.

service-account-add-button

(3) 서비스 계정 생성 폼을 작성합니다.

(3-1) General Account를 선택합니다.

service-account-select-general-accout

(3-2) 기본 정보를 입력합니다.

service-account-add-base-info

(3-3) 해당 서비스 계정에 따른 리소스를 수집할 프로젝트를 지정합니다.

service-account-connect-project

(3-4) 암호화 키 정보를 입력합니다.

  • 암호화 키 입력 옵션 1) 개별 암호화 키를 통해 어카운트를 직접 등록할 수 있습니다. service-account-add-key-1-1

  • 암호화 키 입력 옵션 2) 존재하는 Trusted account의 암호화키를 연결하여 등록할 수 있습니다.

  • AWS의 경우, 기존에 Trusted Account가 있다면 이를 연결하여 Assume Role을 쉽게 생성할 수 있습니다. 특정 Trusted Account를 연결하게 되면 해당 어카운트에 입력된 키값들이 자동 적용되며, 그외 나머지 항목 입력이 필요합니다. service-account-add-key-1-2

  • 암호화 키 입력 옵션 3) 상황에 따라, 별도의 암호화 키 없이도 신규 어카운트를 생성할 수 있습니다. service-account-add-key-1-3

(4) [저장] 버튼을 클릭하여 완료합니다.

Trusted Account 생성하기

(1) [에셋 인벤토리 > 서비스 계정] 페이지에서 추가할 클라우드 서비스를 선택합니다.

service-account-provider-menu

(2) [추가] 버튼을 클릭합니다.

service-account-add-button

(3) 서비스 계정 생성 폼을 작성합니다.

(3-1) Trusted Account를 선택합니다.

service-account-select-trusted-accout

(3-2) 기본 정보를 입력합니다.

service-account-add-base-info-2-2

(3-3) 해당 서비스 계정에 따른 리소스를 수집할 프로젝트를 지정합니다.

service-account-connect-project

(3-4) 암호화 키 정보를 입력합니다.

service-account-add-key-2-2

(4) [저장] 버튼을 클릭하여 완료합니다.

서비스 어카운트 조회하기

생성된 서비스 어카운트 전체 목록을 조회 할 수 있으며, 특정 어카운트를 클릭시 상세페이지에 진입할 수 있습니다.

service-account-view-list

서비스 어카운트 편집하기

편집하고자 하는 서비스 어카운트 페이지에 진입합니다.

service-account-detail-page

항목별 내용 편집하기

각각의 항목별 [수정] 버튼을 눌러 해당 내용을 변경할 수 있습니다.

service-account-edit-btn service-account-edit

서비스 어카운트 삭제하기

삭제하고자 하는 서비스 어카운트 페이지에 진입합니다.

삭제 아이콘 버튼을 통해 해당 서비스 어카운트를 삭제할 수 있습니다.

service-account-delete-btn

만약, 해당 서비스 어카운트가 Trusted Account 타입 이고, 1개 이상의 다른 General Account가 이를 연결해둔 상태라면 삭제가 불가합니다.

service-account-cannot-delete

4.7 - 비용 관리

비용 관리는 클라우드포레에 등록된 서비스 계정으로부터 발생한 모든 비용을 추적합니다. 정제된 비용 데이터는 대시보드나 비용 분석에서 확인할 수 있습니다.

또한 사용자가 설정한 예산을 기준으로 기간별 사용량을 확인할 수 있으며, 예산 알림을 설정할 수도 있습니다.

4.7.1 - 비용 분석

비용 분석은 클라우드 제공자로부터 수신되는 비용 데이터를 상세하게 분석합니다.

다양한 조건으로 데이터를 그룹화 혹은 필터링하여, 원하는 비용 데이터를 한눈에 볼 수 있습니다.

비용 분석 확인하기

데이터 소스 선택하기

1개 이상의 빌링 데이터 소스가 연결된 경우, 각각의 데이터 소스 별 비용 상세 분석이 가능합니다. 데이터 소스는 좌측 메뉴 비용 분석’ 부분에서 드랍다운을 통해 선택할 수 있습니다.

cost-analysis-data-source

세부기준 선택하기

세부 기준은 데이터를 어떤 방식으로 보여줄 것인가에 대한 기준입니다. 세부 기준에 따라 제공되는 차트나 테이블의 형태가 달라집니다.

cost-analysis-granularity

  • 일별 데이터: 특정 월 기준으로 일별 누적 데이터를 확인할 수 있습니다.
  • 월별 데이터: 특정 기간(최대 12개월)동안의 월별 데이터를 확인할 수 있습니다.
  • 연도별 데이터: 최근 3개년동안의 연도별 데이터를 확인할 수 있습니다.

기간 설정하기

세부 기준에 따라 선택할 수 있는 기간 메뉴가 다르게 나타납니다. [기간] 드롭다운에서 메뉴를 선택하거나, [기간 선택] 메뉴를 통해 직접 설정합니다.

cost-analysis-period


그룹별 통계 설정하기

유저가 선택한 값을 기준으로 데이터를 그룹화합니다. 차트에서는 선택한 그룹 중 하나만 보여지며, 차트 바로 우측에 드랍다운에서 차트에 표시할 그룹을 변경할 수 있습니다. 하단 테이블에서는 선택한 그룹별 통계를 모두 볼 수 있습니다.

cost-analysis-groupby

cost-analysis-groupby


필터 설정

필터는 그룹별 통계와 마찬가지로 한 개 이상 선택 가능하며, 유저가 설정한 값을 and 조건으로 필터링합니다.

(1) 페이지 상단에 [필터] 버튼을 클릭합니다.

(2) [필터 세팅]창이 열리면 원하는 필터를 선택할 수 있으며, 선택시 바로 차트와 테이블에 반영됩니다.

cost-analysis-filter


커스텀 비용 분석 페이지 생성/관리 하기

커스텀 분석 페이지 생성하기

[비용 관리 > 비용 분석] 페이지에 진입할 때마다 세부 기준과 기간 등을 다시 설정해야 하는 번거로움을 해소하기 위해, 자주 사용하는 설정들을 분석 페이지로 저장할 수 있는 기능이 제공됩니다.

(1) 특정 비용 분석 페이지의 우측 상단 [다른 이름으로 저장] 버튼 클릭합니다.

cost-analysis-save_as

(2) 이름 입력후 [확인]버튼 클릭시, 새로운 분석 페이지가 생성됩니다.

cost-analysis-save_to

cost-analysis-saved

(3) 커스텀 비용 분석 페이지는 이름/필터/그룹별 통계등의 설정을 바로 [저장]할 수 있으며, 기본으로 제공되는 분석 페이지와 마찬가지로 [다른 이름으로 저장]을 통해 새로운 페이지로 생성할 수도 있습니다.

cost-analysis-save_saveas


커스텀 분석 페이지 이름 편집하기

페이지 상단 [편집] 버튼을 클릭하여 이름을 변경할 수 있습니다.

cost-analysis-edit

cost-analysis-edit_name


커스텀 분석 페이지 삭제하기

페이지 상단 [삭제] 버튼을 클릭하여 삭제할 수 있습니다.

cost-analysis-delete

4.7.2 - 예산

예산은 프로젝트 별로 비용 발생 기준을 설정해, 예산을 관리하는 서비스입니다.

예산 생성하기

(1) [비용 관리 > 예산] 페이지의 우측 상단에 있는 [예산 생성] 버튼을 클릭합니다.

budget-create-01

(2) 기본 정보 입력하기

budget-create-02

(2-1) 예산의 이름을 입력합니다.

(2-2) 빌링 데이터 소스를 선택합니다.

(2-3) 타겟 항목에서 예산 관리의 대상이 될 프로젝트를 선택합니다.

(2-4) 비용 발생 기준을 선택합니다. 비용 발생 기준을 모두로 선택할 경우, 해당 프로젝트와 관련된 모든 비용 데이터를 가져옵니다.

(3) 예산 계획 입력하기

budget-create-03

(3-1) 예산을 관리할 기간을 정합니다.

(3-2) 어떤 방식으로 예산을 관리할 것인지 선택합니다.

(3-3) 예산 금액을 설정합니다. 앞서 총 예산 설정을 선택했다면 총 예산 금액을 입력하고, 월별 예산 설정을 선택했다면 월별 예산 금액을 입력합니다.

설정된 예산 및 사용현황 확인

예산 페이지에서는 예산 데이터의 요약과 프로젝트 별 예산을 한눈에 볼 수 있습니다. 상단의 필터를 활용해 기간을 지정하거나 환율을 적용할 수 있으며, 고급 검색을 통해 특정 프로젝트나 이름 등을 검색할 수 있습니다.

budget-full-page-01

예산 상세 페이지

예산 상세 페이지에서, 생성된 예산의 구체적인 데이터를 볼 수 있습니다.

예산 요약

[예산 요약]에서는 월별 예산과 비용 추이를 차트와 테이블을 통해 확인할 수 있습니다.

budget-detail-01

예산 사용 알림 설정

[예산 사용 알림 설정]에서는 예산을 일정 기준 이상으로 사용했을 경우 알림을 받도록 설정할 수 있습니다. 예산 금액을 일정 비율 이상 사용했거나, 실 사용액이 일정 금액을 초과했을 경우 미리 등록해 둔 알림 채널로 알림을 받을 수 있습니다.

budget-alert-01

4.7.3 - 비용 리포트

비용 리포트는 월별 특정 일자 기준으로 워크스페이스 내 발생한 총비용을 발행해 주는 서비스입니다.

메뉴 진입하기

(1) 특정 워크스페이스 선택

(2) [비용 관리 > 비용 리포트]로 이동



비용 리포트 확인하기

(1) [전체 요약] 탭에서는 최근 12개월 또는 특정 연도별 전체 비용 트렌드 확인이 가능합니다.

(2) 월별 총 비용 요약 위젯에서는 최근 발행된 리포트를 포함하여 월별 비용을 빠르게 확인할 수 있습니다.

(3) 다음 리포트 위젯에서는 특정 기간동안 발생한 비용에 대해 어느 날짜에 리포트를 발행하는지 확인할 수 있습니다.

(4) 리포트 수신처 위젯에서는 매월 리포트 발행 시점에 자동으로 발송할 수신처를 확인할 수 있습니다.



비용 리포트 확인하기

발행된 리포트는 '리포트' 탭에서 전체 확인이 가능합니다.

  • 특정 리포트 선택하여 확인 및 다운로드 가능
  • 리포트 링크 [복사] 를 통해 공유 가능
  • 리포트 [재발송] 가능 (💡설정된 수신처 기준으로 재발송 됩니다.)

4.8 - 얼럿 매니저

클라우드포레의 얼럿 매니저는 다양한 모니터링 시스템에서 발생하는 여러 패턴의 이벤트를 통합 관리할 수 있는 서비스입니다.

4.8.1 - Quick Start

얼럿 매니저 서비스를 빠르게 사용하기 위한 과정을 소개합니다.

얼럿 생성하기

얼럿은 다음 두 가지 방법을 통해 생성할 수 있습니다.

  • 클라우드포레 콘솔에서 수동으로 얼럿 생성
  • 외부 모니터링 서비스 연동을 통한 얼럿 자동 생성

콘솔에서 수동으로 얼럿 생성하기

(1) [얼럿 매니저 > 얼럿] 페이지로 이동 후 [생성] 버튼을 클릭합니다.

create-alert-step-1

(2) [얼럿 생성] 모달이 열리면 입력 폼을 작성합니다.

create-alert-step-2

(2-1) [얼럿 제목]을 입력하고 [긴급도]를 선택합니다.

(2-2) 얼럿이 어떤 프로젝트에 대하여 발생한 것인지 지정해줍니다.

(2-3) 추가적인 설명이 필요하다면 [설명]을 작성합니다.

(3) [확인] 버튼을 클릭하여 얼럿 생성을 완료합니다.

외부 모니터링 서비스를 연결하여 얼럿 수신하기

외부 모니터링 서비스를 연결하면, 해당 서비스에서 발생하는 이벤트의 메시지가 얼럿으로 자동 생성됩니다.
외부 모니터링으로부터 발생된 얼럿을 수신하기 위해서는 웹훅 생성과 연동 설정이 필요합니다.


웹훅 생성하기

외부 모니터링 서비스로부터 발생하는 이벤트 메시지를 수신하려면 웹훅을 생성해야 합니다.
웹훅은 프로젝트 상세 페이지에서 생성 가능합니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭으로 이동 후, [웹훅] 탭을 선택합니다.

create-webhook-step-1

(2) [추가] 버튼을 클릭합니다.

(3) [웹훅 추가] 모달에서 이름을 작성하고, 연동할 외부 모니터링 서비스의 플러그인을 선택합니다.

create-webhook-step-3

(4) [확인] 버튼을 클릭하여 설정을 완료합니다.

에스컬레이션 정책 설정하기

웹훅을 통해 수신한 얼럿이 프로젝트의 멤버들에게 알림으로 전송될지 여부는 에스컬레이션 정책을 통해 결정됩니다.

(1) 프로젝트 상세 페이지에 [얼럿] 탭으로 이동 후, [설정] 탭을 선택합니다.

create-escalation-policy-step-1

(2) [에스컬레이션 정책] 영역에서 [변경] 버튼을 클릭합니다.

create-escalation-policy-step-2

(3) [새로운 정책 생성] 탭을 선택한 뒤, 에스컬레이션 정책을 생성하기 위한 설정들을 입력합니다.

create-escalation-policy-step-4

정책설명
종료 조건(상태)발생된 알람이 중지되는 조건을 정의 합니다.
범위에스컬레이션 정책을 사용할 수 있는 범위를 나타냅니다. 글로벌인 경우 도메인 내 모든 프로젝트에서 사용 가능하고, 프로젝트인 경우 지정된 프로젝트 내에서만 사용 가능합니다.
에스컬레이션 규칙전체 레벨 LV1 ~ LV5 까지 추가 가능합니다.
설정된 레벨에 속하는 알림 채널에 얼럿을 전달하며, 2단계 이상부터 단계 간 텀을 분단위로 부여할 수 있습니다.
반복 횟수Alert 알림을 몇 회 반복할 것인지 정의합니다. 최대 9회까지 반복 가능합니다.
프로젝트 (에스컬레이션 규칙 페이지에서 생성하는 경우)범위가 프로젝트인 경우 대상이 되는 프로젝트를 나타냅니다.

(4) 모든 설정이 완료되었다면 [확인] 버튼을 클릭해 에스컬레이션 정책을 생성합니다.

알림 설정하기

프로젝트 상세 페이지의 [알림] 탭에서는 알림 채널 생성 및 알림 채널 활성화 여부를 관리할 수 있습니다.
알림 채널은 알림 전송 방식과 레벨을 포함하여 체계적인 수신자 영역을 표현하는 단위입니다. 에스컬레이션 규칙에서 설정한 레벨에 맞춰 송신할 수 있도록 돕습니다.

(1) 프로젝트 상세 페이지에서 [알림] 탭을 선택한 뒤, 원하는 알림 채널의 [채널 추가] 버튼을 클릭합니다.

notification-step-1

(2) 알림 생성 페이지에서, 알림 채널을 생성하기 위한 설정들을 입력합니다.

(2-1) 필요한 채널 이름과 알림 레벨 등 생성하려는 알림 채널에 대한 기본적인 정보들을 입력합니다. [채널 이름]과 [알림 레벨]이 기본 설정 필드이며, 이후 나머지는 채널별로 입력받는 정보가 다릅니다.

notification-step-3-1

(2-2) 스케줄을 설정하여 특정 시간에말 알림을 수신할 수 있도록 설정할 수 있습니다.

notification-step-3-2

(2-3) 알림은 얼럿이 발생했을 때 혹은 예산 알림 기준에 도달했을 때에 수신할 수 있습니다. [토픽]에서는 어떤 경우에 알림을 수신할 것인지를 설정할 수 있습니다.

notification-step-3-3

(3) [저장] 버튼을 클릭해 알림 채널 생성을 완료합니다.

(4) 생성이 완료된 알림 채널들은 [알림] 탭 하단에서 확인할 수 있습니다.

notification-step-5

왼쪽 상단의 토글 버튼을 통해 해당 알림 채널의 활성여부를 조작할 수 있습니다. 에스컬레이션 정책에서 설정된 레벨이 있더라도 알림 채널이 활성화 되어있지 않다면 알림은 발생하지 않습니다.

4.8.2 - 대시보드

현재 로그인된 사용자에게 발생한 얼럿을 한눈에 조회 가능한 대시보드입니다.

크게 3가지의 파트 별로 얼럿들을 확인할 수 있으며 아래와 같습니다.

상태별 얼럿 확인하기

대시보드의 최상단에서는 얼럿을 상태별로 볼 수 있습니다.
각 항목을 클릭하면 얼럿 상세 페이지로 이동하여 상세 정보를 확인하거나 세부 설정을 할 수 있습니다.

view-alert-by-status

얼럿 히스토리

프로젝트에서 발생한 얼럿 히스토리를 보여줍니다.
차트에서 일별 데이터를 확인할 수 있으며, 카드에서는 전달 대비 얼럿의 증감량을 확인할 수 있습니다.

alert-history-1

프로젝트 상태 보드

[프로젝트 상태 보드]에서는 사용자와 관련된 각각의 프로젝트들의 얼럿 정보를 보여줍니다.

[Top 5 프로젝트 활동]의 경우, [오픈] 상태의 얼럿이 많은 순서대로 프로젝트를 보여줍니다.

project-board-1

검색 창 아래에는 얼럿이 발생한 프로젝트가 활동이 높은 순서대로 보여집니다.
이슈 상태인 프로젝트만 보이며, 모든 얼럿이 완료 상태가 되면 정상 상태의 프로젝트로 변경되어 대시보드에서 보이지 않습니다.

project-board-2

4.8.3 - 얼럿

얼럿은 서비스 운영 시 발생하는 모든 이슈를 정의한 것으로, 주로 관계자에게 알림을 발송하는 목적으로 생성됩니다.

상태

얼럿은 아래와 같은 상태들을 가지고 있습니다.

상태설명
확인얼럿에 담당자가 할당되어 처리중인 상태
생성얼럿이 최초 등록된 상태
완료장애, 점검 등 얼럿의 내용이 처리 완료된 상태
에러웹훅 연동을 통해 이벤트가 수신되었으나, 오류로 인해 얼럿이 정상적으로 등록되지 않은 상태

긴급도

클라우드포레에서 얼럿의 긴급도는 높음과 낮음 두 가지가 존재합니다.

얼럿 수동 생성의 경우에는 높음 과 낮음 두 가지로 생성되지만, 웹훅 연동을 통해 자동으로 생성되는 경우에는 심각도(Severity) 에 따라 긴급도(Urgency)가 측정됩니다.

얼럿 생성하기

얼럿은 다음 두 가지 방법을 통해 생성할 수 있습니다.

  • 수동 생성: 클라우드포레의 콘솔에서 얼럿을 수동으로 생성합니다.
  • 자동 생성: 웹훅을 생성해 웹훅과 연동된 외부 모니터링 서비스로부터 이벤트를 수신합니다. 그리고 수신한 이벤트 메시지를 정제하여 얼럿을 자동으로 생성합니다.

콘솔에서 수동으로 얼럿 생성하기

(1) [얼럿 매니저 > 얼럿] 페이지로 이동 후 [생성] 버튼을 클릭합니다.

create-alert-step-1

(2) [얼럿 생성] 모달이 열리면 입력 폼을 작성합니다.

create-alert-step-2

(2-1) [얼럿 제목]을 입력하고 [긴급도]를 선택합니다.

(2-2) 얼럿이 어떤 프로젝트에 대하여 발생한 것인지 지정해줍니다.

(2-3) 추가적인 설명이 필요하다면 [설명]을 작성합니다.

(3) [확인] 버튼을 클릭하여 얼럿 생성을 완료합니다.

외부 모니터링 서비스를 연결하여 얼럿 수신하기

외부 모니터링 서비스를 연결하면, 해당 서비스에서 발생하는 이벤트의 메시지가 얼럿으로 자동 생성됩니다.
외부 모니터링으로부터 발생된 얼럿을 수신하기 위해서는 웹훅 생성과 연동 설정이 필요합니다.


웹훅 생성하기

외부 모니터링 서비스로부터 발생하는 이벤트 메시지를 수신하려면 웹훅을 생성해야 합니다.
웹훅은 프로젝트 상세 페이지에서 생성 가능합니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭으로 이동 후, [웹훅] 탭을 선택합니다.

create-webhook-step-1

(2) [추가] 버튼을 클릭합니다.

(3) [웹훅 추가] 모달에서 이름을 작성하고, 연동할 외부 모니터링 서비스의 플러그인을 선택합니다.

create-webhook-step-3

(4) [확인] 버튼을 클릭하여 설정을 완료합니다.

얼럿 활용하기

클라우드포레의 얼럿을 활용한 여러가지 기능을 간단하게 살펴봅시다.

  • 알림 채널: 얼럿을 어떤 사용자에게 어떻게, 언제 전달할 것인지 등을 설정합니다.
  • 에스컬레이션 정책: 단계별 규칙을 적용하여, 수신된 얼럿을 프로젝트의 멤버들에게 효과적으로 전달합니다.
  • 이벤트 규칙: 웹훅을 통해 수신된 이벤트는 조건에 따라 얼럿으로 생성됩니다.
  • 유지 관리 기간: 정기, 비정기적인 시스템 작업 일정을 등록하여 작업을 안내하고, 작업간 발생하는 얼럿을 차단합니다.

얼럿 목록 조회하기

[얼럿 매니저 > 얼럿] 페이지에서 모든 프로젝트의 얼럿을 조회할 수 있습니다.
얼럿을 검색하거나 얼럿의 상태를 변경할 수 있습니다.

얼럿 검색하기

검색어를 입력하여 조건에 부합하는 얼럿 목록을 확인할 수 있으며, 원하는 얼럿의 제목을 클릭하여 얼럿 상세 페이지로 이동할 수 있습니다.

alert-search

또한 기본적으로 제공되는 필터링 기능을 통해 얼럿을 편리하게 필터링할 수 있습니다.

고급 검색에 대한 상세 설명은 여기를 참고 하십시오.

목록에서 얼럿 상태 변경하기

목록에서 바로 얼럿의 상태 수정이 가능합니다.

(1) 상태를 수정할 얼럿을 선택하고, 오른쪽 상단의 [확인], [완료], [삭제] 중 원하는 버튼을 클릭합니다.

update-alert-1

(1-1) [확인] 버튼을 클릭하여 확인 상태로 변경하기

확인 상태는 담당자가 할당되어 처리중인 상태입니다.
상태 변경과 동시에 선택한 얼럿의 담당자를 본인으로 설정할 수 있으며, [확인] 버튼을 클릭하여 완료합니다.

update-alert-1-1

(1-2) [완료] 버튼을 클릭하여 완료 상태로 변경하기

완료 상태는 얼럿을 발생시킨 이슈가 처리 완료된 상태입니다.
상태 변경과 동시에 노트를 작성할 수 있으며, [확인] 버튼을 클릭하여 완료합니다.

update-alert-1-2

(1-3) [삭제] 버튼을 클릭하여 얼럿 삭제하기

삭제할 얼럿 목록을 다시 한번 확인이 가능하며, [확인] 버튼을 클릭하여 삭제합니다.

update-alert-1-3

얼럿 살펴보기

얼럿 상세 페이지에서 얼럿에 대한 상세 정보와 히스토리를 조회하고, 관리할 수 있습니다.

alert-detail-page

상세항목설명
지속 시간얼럿이 지속된 시간
설명얼럿에 대한 설명으로, 사용자가 직접 작성한 내용 또는 외부 모니터링 서비스로부터 수신한 이벤트의 내용
규칙외부 모니터링 서비스에서 얼럿이 발생한 조건
심각도웹훅 이벤트의 데이터로부터 받은 심각도
에스컬레이션 정책적용된 에스컬레이션 정책
프로젝트얼럿이 발생된 프로젝트
생성얼럿을 전송한 모니터링 서비스
리소스 이름얼럿 발생 대상

이름 변경 및 삭제하기

[편집] 아이콘 버튼과 [삭제] 아이콘 버튼을 통해 얼럿의 이름 변경 및 얼럿 삭제가 가능합니다.

update-alert-name-or-delete-alert

상태 / 긴급도 변경하기

상태와 긴급도는 드롭다운을 통해 쉽게 수정할 수 있습니다.

update-state-urgency

담당자 변경하기

(1) [할당] 버튼을 클릭합니다.

update-assignee-1

(2) 담당자를 선택하고 [확인] 버튼을 눌러 담당자 할당을 완료합니다.

update-assignee-2

설명 수정하기

해당 얼럿에 대하여 관리 권한이 있는 사용자만 편집이 가능합니다.

(1) [편집] 버튼을 클릭합니다.

update-description-1

(2) 얼럿 설명란의 폼을 통해 변경사항을 작성하고 [변경사항 저장] 버튼을 클릭하여 수정을 완료합니다.

update-description-2

프로젝트 변경하기

얼럿과 연결된 프로젝트를 변경할 수 있습니다.

(1) 프로젝트 [변경] 버튼을 클릭합니다.

update-project-1

(2) [프로젝트 선택] 드롭다운에서 프로젝트를 선택한 뒤, [변경사항 저장] 버튼을 클릭하여 프로젝트 변경을 완료합니다.

update-project-2

새로운 상태로 업데이트하기

얼럿의 상태에 진행 상황 등을 기록하여, 빠르게 해당 얼럿의 상태를 파악할 수 있도록 합니다.
내용을 변경하면 이전의 상태 기록은 사라집니다.

(1) [새로운 업데이트] 버튼을 클릭합니다.

update-status-1

(2) [새로운 상태 업데이트] 모달에서 상태를 작성하고, [확인] 버튼을 클릭해 상태 업데이트를 완료합니다.

update-status-2

수신인 추가하기

얼럿은 에스컬레이션 정책을 통해 수신자에게 전파됩니다.

해당 얼럿에 대하여 추가 사용자에게 얼럿을 전파할 필요가 있다면, [추가 수신인]을 설정합니다.

add-additional-responder-1

검색 창을 클릭하여 수신 가능한 사용자 목록을 조회 및 검색할 수 있으며, 다중 선택이 가능합니다.

add-additional-responder-2

노트 추가하기

얼럿에 대해 구성원들이 코멘트를 남겨, 처리 중 문의사항과 이에 대한 답변을 등록하여 의사소통할 수 있습니다.

add-note

발생한 이벤트 살펴보기

한 얼럿에서 발생한 이벤트들을 로깅하여 히스토리를 볼 수 있습니다.

view-pushed-event

이벤트 목록 중 하나를 클릭하면, 이벤트의 상세 정보를 조회할 수 있습니다.

view-pushed-event-detail

알림 정책 설정하기

프로젝트에 발생한 얼럿의 긴급도가 긴급 인 경우에만 얼럿이 발생하도록 설정할 수 있습니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭 내부에서, [설정] 탭으로 이동합니다.

notification-policy-1

(2) 알림 정책 영역의 [편집] 아이콘 버튼을 클릭합니다.

notification-policy-2

(3) 원하는 알림 정책을 선택합니다.

notification-policy-3

(4) [확인] 버튼을 클릭해 정책 설정을 완료합니다.

자동 복구 설정하기

자동 복구 기능은 시스템 장애가 복구되면 얼럿을 자동으로 완료 상태로 전환합니다.

(1) 프로젝트 상세 페이지에 [얼럿] 탭 내부에서, [설정] 탭으로 이동합니다.

auto-recovery-1

(2) 자동 복구 영역의 [편집] 아이콘 버튼을 클릭합니다.

auto-recovery-2

(3) 원하는 자동 복구 설정을 선택합니다.

auto-recovery-3

(4) [확인] 버튼을 클릭해 자동 복구 설정을 완료합니다.

4.8.4 - 웹훅

웹훅을 통해 외부 모니터링 서비스에서 발생한 이벤트를 수신할 수 있습니다.

웹훅 생성하기

외부 모니터링 서비스로부터 발생하는 이벤트 메시지를 수신하려면 웹훅을 생성해야 합니다.
웹훅은 프로젝트 상세 페이지에서 생성 가능합니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭으로 이동 후, [웹훅] 탭을 선택합니다.

create-webhook-step-1

(2) [추가] 버튼을 클릭합니다.

(3) [웹훅 추가] 모달에서 이름을 작성하고, 연동할 외부 모니터링 서비스의 플러그인을 선택합니다.

create-webhook-step-3

(4) [확인] 버튼을 클릭하여 설정을 완료합니다.

웹훅 목록 조회하기

상세 검색

검색 창에 검색어를 입력하여 조건에 부합하는 웹훅 목록을 확인할 수 있습니다. 고급 검색에 대한 상세 설명은 여기를 참고 하십시오.

webhook-search

웹훅 수정 및 삭제하기

목록에서 조회한 웹훅을 선택하여 활성화, 비활성화, 변경, 삭제할 수 있습니다.

update-webhook

웹훅 활성화 / 비활성화 하기

웹훅을 활성화하면, 해당 웹훅에 연동된 외부 모니터링 서비로부터 수신된 이벤트를 얼럿으로 받을 수 있습니다.
반대로 웹훅을 비활성화하면, 수신되는 이벤트는 무시되어 얼럿을 발생시키지 않습니다.

(1) 활성화할 웹훅을 선택하고 [작업] 드롭다운에서 [활성화] 혹은 [비활성화] 메뉴를 선택합니다.

enable-webhook-1

(2) [웹훅 활성화/비활성화] 모달에서 내용을 확인하고 [확인] 버튼을 클릭합니다.

enable-webhook-2 disable-webhook-2

웹훅 이름 변경하기

(1) 웹훅 목록에서 변경할 웹훅을 선택하고, [작업] 드롭다운에서 [변경] 메뉴를 선택합니다.

update-webhook-name-1

(2) 변경할 이름을 작성하고 [확인] 버튼을 눌러 변경을 완료합니다.

update-webhook-name-2

웹훅 삭제하기

(1) 웹훅 목록에서 삭제할 웹훅을 선택하고, [작업] 드롭다운에서 [삭제] 메뉴를 선택합니다.

delete-webhook-1

(2) 선택한 웹훅의 이름을 정확히 입력한 뒤, [삭제] 버튼을 클릭하여 웹훅을 삭제합니다.

delete-webhook-2

4.8.5 - 이벤트 규칙

이벤트 규칙을 설정하면, 얼럿이 발생할 경우 지정된 작업이 자동으로 수행되어, 얼럿을 수작업으로 관리해야 하는 번거로움을 줄일 수 있습니다.

이벤트 규칙은 프로젝트에 종속되며, 프로젝트 상세 페이지에서 관리할 수 있습니다.

event-rule-full-page

이벤트 규칙 생성하기

(1) 프로젝트 상세 페이지의 [얼럿] 탭 내부의 [설정] 탭에서, 이벤트 규칙의 [편집] 아이콘 버튼을 클릭합니다.

create-event-rule-1

(2) [이벤트 규칙 추가] 버튼을 클릭합니다.

create-event-rule-2

(3) 이벤트 규칙 페이지에서 원하는 설정 값들을 입력합니다.

create-event-rule-3

(3-1) 수신한 얼럿에 대하여 추가적인 작업을 수행할 조건을 설정합니다.

조건은 반드시 한 개 이상 작성되어야 하며, 오른쪽의 [추가] 버튼을 클릭하여 조건을 추가하거나, [삭제] 아이콘 버튼을 클릭하여 삭제할 수 있습니다.

create-event-rule-3-1

(3-2) 위에서 정의한 조건에 맞는 얼럿에 대하여 수행될 작업을 지정합니다.

create-event-rule-3-2

이벤트 규칙 설정 목록

속성설명
알림 중지해당 조건의 얼럿에 대하여 알림을 발생시키지 않기
프로젝트 라우팅해당 조건의 얼럿을 현재의 프로젝트가 아닌 프로젝트 라우팅에 선택된 프로젝트가 수신함 (현재 프로젝트에는 얼럿이 생성되지 않음)
프로젝트 의존성해당 조건의 얼럿은 프로젝트 의존성에 등록된 프로젝트들이 참조할 수 있습니다.
긴급도해당 조건의 얼럿에 자동으로 긴급도 지정하기
높음, 낮음, 미설정을 지정할 수 있으며, 미설정의 경우 아래의 규칙에 따라 설정됨
• 외부 모니터링 얼럿: 개체의 긴급도
• 직접 생성: 높음(기본값)
담당자해당 조건의 얼럿에 자동으로 담당자 지정하기
추가 수신자해당 조건의 얼럿에 대하여 알림 발생 시, 지정한 사용자에게도 함께 알림 보내기
추가 정보해당 조건의 얼럿에 자동으로 정보 추가하기
이후 작업 실행하지 않기해당 이벤트 규칙이 실행되었을 경우, 이후의 이벤트 규칙은 무시함 (이벤트 규칙 동작 방식과 순서 참고)

이벤트 규칙 편집하기

(1) 이벤트 규칙 페이지에서 [편집] 버튼을 클릭합니다.

update-event-rule-1

(2) 이벤트 규칙에서 원하는 설정 값들을 입력합니다.

update-event-rule-2

(3) [저장] 버튼을 클릭하여 이벤트 규칙 편집을 완료합니다.

이벤트 규칙 삭제하기

(1) 이벤트 규칙 페이지에서 [삭제] 버튼을 클릭합니다.

delete-event-rule-1

(2) [이벤트 규칙 삭제] 모달에서 [확인] 버튼을 눌러 삭제를 완료합니다.

delete-event-rule-2

이벤트 규칙 동작 방식과 순서

얼럿이 발생했을 때 사용자가 설정한 이벤트 규칙이 있으면 순차적으로 실행됩니다.

event-working-system

위의 예시와 같이 이벤트 규칙들이 생성되어 있다면 가장 상위에 있는 이벤트 규칙부터 [#1], [#2] 순서대로 실행됩니다.
[↑], [↓] 아이콘 버튼을 클릭하여 이벤트 규칙의 순서를 쉽게 변경할 수 있습니다.

4.8.6 - 유지 관리 기간

정기, 비정기적인 시스템 작업 기간 내에 발생하는 얼럿에 대하여서는 알림 발송을 차단해야 할 필요가 있습니다.
유지 관리 기간을 설정하여 해당 기간 동안에는 알림이 일어나지 않도록 차단할 수 있습니다.

유지 관리 기간은 프로젝트에 종속되며, 프로젝트 상세 페이지에서 관리할 수 있습니다.

maintenance

유지 관리 기간 생성하기

(1) 프로젝트 상세 페이지의 우측 상단에 있는 [유지 관리 기간 생성] 버튼을 클릭합니다.

create-maintenance-window-1

(2) 유지 관리 기간의 [제목]을 입력하고, 얼럿 발생을 제한할 스케줄을 설정합니다.

create-maintenance-window-2-1

스케줄을 지정할 때 바로 시작하거나 예정된 시간에 시작하도록 할 수 있습니다.
바로 시작하기를 원한다면 [지금 시작하고 끝내기] 옵션을, 예정된 작업 일정을 등록하려면 [예정된 시간에 시작하기] 옵션을 선택하십시오.

create-maintenance-window-2-2

(3) [확인] 버튼을 클릭하면 생성이 완료됩니다.

유지 관리 기간 편집하기

아직 종료되지 않은 유지 관리 기간만 편집이 가능합니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭 아래의 [유지 관리 기간] 탭을 선택합니다.

(2) 편집하려는 대상을 선택하고 [편집] 버튼을 클릭합니다.

update-maintenance-window-1

(3) 원하는 항목을 변경한 후 [확인] 버튼을 클릭하여 완료합니다.

update-maintenance-window-2

유지 관리 기간 종료하기

(1) 프로젝트 상세 페이지의 [얼럿] 탭 아래의 [유지 관리 기간] 탭을 선택합니다.

(2) 편집하려는 대상을 선택하고 [종료] 버튼을 클릭하여 종료합니다.

delete-maintenance-window

4.8.7 - 알림

알림은 얼럿을 전달하기 위한 수단입니다.

알림 채널을 통해 얼럿을 어떤 사용자에게 어떻게, 언제 전달할 것인지 등을 설정합니다.

알림 채널은 프로젝트에 종속되며, 프로젝트 상세 페이지에서 관리할 수 있습니다.

notification-full-page

알림 채널 생성하기

프로젝트 상세 페이지의 [알림] 탭에서는 알림 채널 생성 및 알림 채널 활성화 여부를 관리할 수 있습니다.

알림 채널은 알림 전송 방식과 레벨을 포함하여 체계적인 수신자 영역을 표현하는 단위입니다. 에스컬레이션 규칙에서 설정한 레벨에 맞춰 송신할 수 있도록 돕습니다.

(1) 프로젝트 상세 페이지에서 [알림] 탭을 선택한 뒤, 원하는 알림 채널의 [채널 추가] 버튼을 클릭합니다.

notification-step-1

(2) 알림 생성 페이지에서, 알림 채널을 생성하기 위한 설정들을 입력합니다.

(2-1) 필요한 채널 이름과 알림 레벨 등 생성하려는 알림 채널에 대한 기본적인 정보들을 입력합니다. [채널 이름]과 [알림 레벨]이 기본 설정 필드이며, 이후 나머지는 채널별로 입력받는 정보가 다릅니다.

notification-step-2-1

(2-2) 스케줄을 설정하여 특정 시간에말 알림을 수신할 수 있도록 설정할 수 있습니다.

notification-step-2-2

(2-3) 알림은 얼럿이 발생했을 때 혹은 예산 알림 기준에 도달했을 때에 수신할 수 있습니다. 토픽을 설정하여 어떤 알림을 받을 것인지 선택할 수 있습니다.
[모든 알림 받기]를 선택하면 두 가지 알림 모두를, [선택한 토픽 알림 받기]를 선택하면 선택한 알림만을 받을 수 있습니다.

notification-step-2-3

(3) [저장] 버튼을 클릭해 알림 채널 생성을 완료합니다.

알림 채널 편집/삭제하기

알림 채널 편집하기

생성된 알림 채널들은 각 알림 채널 선택지 아래에서 확인할 수 있습니다.

update-notification-channel-1

왼쪽 상단 토글 버튼을 통해 활성/비활성 상태를 변경할 수 있으며, 각 알림 채널의 [편집] 버튼을 클릭해 각각의 항목을 편집할 수 있습니다.
작성이 완료되면 [변경사항 저장] 버튼을 클릭해 편집을 완료합니다.

update-notification-channel-2

알림 채널 삭제하기

우측 상단의 [삭제 아이콘] 버튼을 클릭시 알림 채널 삭제가 가능합니다.

delete-notification-channel

클라우드포레 사용자 채널

프로젝트에서 [알림 채널] 항목에는 [Cloudforet User 채널 추가] 버튼이 존재합니다.

cloud-foret-user-channel-1

클라우드포레 사용자 채널을 추가하면, 프로젝트 멤버들의 개인 채널로 얼럿이 전파됩니다. 이후 전파 받은 사용자의 클라우드포레 사용자 알림 채널을 통해 얼럿이 전달됩니다.

cloud-foret-user-channel-2

클라우드포레 사용자 알림 채널 생성하기

사용자 알림 채널은 [마이페이지 > 알림 채널]에서 생성할 수 있습니다.

create-user-channel

프로젝트 알림 채널 생성과 다르게 알림 레벨 설정이 없으며, 이 외에 생성 절차는 프로젝트 알림 채널 생성하기와 동일합니다.

4.8.8 - 에스컬레이션 정책

에스컬레이션 정책을 통해 얼럿에 단계별 규칙을 적용하여, 수신된 얼럿을 프로젝트의 멤버들에게 효과적으로 전달합니다.

각 규칙에는 설정된 레벨이 존재하고, 레벨마다 해당하는 알림 채널에 얼럿이 전파됩니다.

웹훅을 통해 수신한 얼럿이 프로젝트의 멤버들에게 알림으로 전송될지 여부는 에스컬레이션 정책을 통해 결정됩니다.
에스컬레이션 정책은 다음 두 곳에서 관리할 수 있습니다.

  • [얼럿 매니저 > 에스컬레이션 정책] 페이지: 글로벌과 프로젝트 범위의 에스컬레이션 정책 관리
  • [프로젝트] 상세 페이지: 프로젝트 범위의 에스컬레이션 정책 관리

에스컬레이션 정책 생성하기

[에스컬레이션 정책] 페이지에 대한 MANAGE 권한을 가진 사용자일 경우, 에스컬레이션 정책을 생성할 수 있습니다.

[에스컬레이션 정책] 페이지에서 생성하기

(1) [얼럿 매니저 > 에스컬레이션 정책] 페이지에서 [생성] 버튼을 클릭합니다.

escalation-policy-full-page

(2) 에스컬레이션 정책을 생성하기 위한 설정들을 입력합니다.

escalation-policy-create-modal

정책설명
종료 조건(상태)발생된 알람이 중지되는 조건을 정의합니다.
범위에스컬레이션 정책을 사용할 수 있는 범위를 나타냅니다. 글로벌인 경우 도메인내 모든 프로젝트에서 사용 가능하고, 프로젝트인 경우 지정된 프로젝트 내에서만 사용 가능합니다.
프로젝트범위가 프로젝트인 경우 대상이 되는 프로젝트를 나타냅니다.
에스컬레이션 규칙단계별 알림 송신을 위해 규칙을 정의합니다.
설정된 레벨에 속하는 알림 채널에 얼럿을 전달하며, 2단계 이상부터 단계 간 텀을 분 단위로 부여할 수 있습니다.
반복 횟수얼럿 알림을 몇회 반복할 것인지 정의합니다. 최대 9회까지 반복 가능합니다.

[프로젝트] 상세 페이지에서 생성하기

[프로젝트] 상세 페이지에서 에스컬레이션 정책을 생성하면, 자동으로 해당 프로젝트가 에스컬레이션 정책 대상으로 지정됩니다.

(1) 프로젝트 상세 페이지의 [얼럿] 탭 내부에서, [설정] 탭으로 이동합니다.

create-escalation-policy-1

(2) 에스컬레이션 정책 영역에서 [변경] 버튼을 클릭합니다.

create-escalation-policy-2

(3) [새로운 정책 생성] 탭을 클릭합니다.

create-escalation-policy-3

(4) 에스컬레이션 정책을 생성하기 위한 설정들을 입력합니다.

create-escalation-policy-4

레벨

레벨은 얼럿을 단계별로 전송할 때, 해당 단계에서 얼럿을 전송할 전송 범위입니다.

해당 프로젝트에 알림 채널을 설정할 수 있으며, 알림 채널은 각각 자신의 레벨을 가집니다.

escalation-policy-level

에스컬레이션 규칙을 정의할 때, [알림 레벨]을 설정하게 됩니다. 설정된 단계마다 해당하는 레벨의 알림 채널들로 얼럿을 전송하게 됩니다.

(5) 모든 설정이 완료되었다면 [확인] 버튼을 클릭해 에스컬레이션 정책을 생성합니다.

기본 정책으로 설정하기

에스컬레이션 정책 목록에서 하나를 선택한 뒤, [작업] 드롭다운에서 [기본으로 설정하기] 메뉴를 선택해 해당 정책을 기본으로 설정할 수 있습니다.

새로운 프로젝트가 생성되고 얼럿을 활성화하면, 해당 정책이 자동으로 적용됩니다.

set-as-default

에스컬레이션 수정 및 삭제하기

에스컬레이션 정책 목록에서 대상을 선택 후 [작업] 드롭다운에서 [수정] 및 [삭제]가 가능합니다.

escalation-policy-update-delete

수정하기

수정의 경우 [생성] 버튼 클릭 시 생성되는 모달과 같은 형태이며, 범위를 제외한 모든 항목을 수정할 수 있습니다.

update-escalation-policy

삭제하기

삭제의 경우 아래와 같은 확인 모달을 통해 삭제를 진행할 수 있습니다.

delete-escalation-policy

4.9 - 사용자 및 접근 관리

특정 워크스페이스 내에 사용자 초대/관리 및 앱 설정을 통한 API/CLI 접근 관리가 가능합니다.

4.9.1 - 사용자

워크스페이스 범위의 사용자 초대/관리가 가능합니다.

메뉴 진입하기

(1) 특정 워크스페이스 선택

(2) [사용자 및 접근 관리 > 사용자]로 이동



사용자 초대하기

(1) 상단의 [초대] 버튼 클릭

(2) 초대하고자 하는 사용자 계정 추가 및 워크스페이스 역할(Role) 할당

(2-1) 사용자 계정 추가

도메인 내에 이미 존재하는 사용자뿐만 아니라, 외부 사용자 또한 해당 워크스페이스로 초대가 가능합니다.

  • Local: E-mail 포멧으로 입력
  • 이외 Google, Keyloak 등의 SSO가 도메인에 추가 설정되어 있다면 해당 포멧에 맞춰 입력

(2-2) 워크스페이스 접근 역할(Role) 선택

(2-3) [확인] 버튼을 누르고 사용자 초대 완료


(3) 초대된 사용자 목록에서 확인

특정 사용자 클릭 시 사용자 상세 정보를 비롯해 사용자가 속한 프로젝트 목록 또한 확인이 가능합니다.



사용자 수정하기

Workspace Owner는 사용자의 역할(Role) 수정 및 제거만 가능하며, 사용자의 다른 정보 수정은 불가합니다.

(1) 역할 변경

  • 사용자의 Role 표시부분의 드롭다운 버튼 클릭하여 변경

(2) 사용자 제거

  • [제거]버튼 클릭하여 제거

4.9.2 - 앱 관리

워크스페이스 범위의 API/CLI 접근을 위한 Client Seret 발급용 앱 생성 및 관리가 가능합니다.

메뉴 진입하기

(1) 특정 워크스페이스 선택

(2) [사용자 및 접근 관리 > 앱]으로 이동



앱 생성하기

클라우드포레가 제공하는 CLI 도구인 Spacectl을 사용하기 위해서는 접근 가능한 Client Secret이 필요합니다.

특정 워크스페이스에서 Workspace Owner 역할을 갖는 앱을 생성하고, 해당 앱의 Client Secret 키를 다른 사용자에게 부여할 수 있습니다.

(1) 우측 상단 [+ 생성] 버튼 클릭

(2) 정보 입력

  1. 이름 입력
  2. Workspace Owner 역할(Role) 선택: 역할에 대한 상세 내용은 이곳에서 자세히 확인할 수 있습니다.
  3. 태그 입력: '키:값' 방식으로 입력 합니다.
  4. [확인] 버튼을 클릭하여 앱 생성을 완료합니다.

(3) 필수 파일 다운 받기



Client Secret 재생성

(1) 특정 앱 선택

(2) 상단 [작업 > Client Secret 재생성] 클릭

  • 새로운 Secret으로 재생성이 되며, 설정 파일을 다시 다운받을 수 있습니다.

4.10 - 마이페이지

마이페이지에서는 사용자 본인의 개인화된 데이터를 관리할 수 있습니다.

4.10.1 - 계정 & 프로필

계정 & 프로필은 사용자의 개인 정보를 확인하고 편집할 수 있는 페이지입니다.

[마이페이지]는 상단 메뉴의 가장 오른쪽의 아이콘을 클릭했을 시 나오는 하위 메뉴을 통해 진입할 수 있습니다.


설정 변경하기

[마이페이지 > 계정 & 프로필] 페이지에서 자신의 이름, 타임존, 언어 설정을 변경할 수 있습니다.

account-profile-02

알림 전용 이메일 인증하기

알림 전용 이메일을 직접 입력하고, 인증할 수 있습니다. 알림 전용 이메일이 인증되어 있지 않은 사용자의 경우, 시스템 주요 공지 또는 비밀번호 재설정 관련 내용 수신이 불가합니다.

account-profile-03


멀티 팩터 인증하기

멀티 팩터 인증(MFA)은 로그인 시 계정을 2회 이상의 단계로 인증하는 방식입니다.

다중 인증을 활성화하여 사용자 계정의 보안을 강화할 수 있습니다.

다중 인증 이메일 설정


비밀번호 변경하기

내부 사용자(아이디/비밀번호로 로그인 한 사용자)의 경우 이 페이지에서 자신의 비밀번호를 변경할 수 있습니다.

account-profile-04

4.10.2 - 알림 채널

알림 채널은 클라우드포레의 모니터링 시스템이나 예산 서비스에서 발생하는 여러 얼럿과 이벤트, 또는 클라우드포레 자체 알림 등을 받아볼 수 있는 서비스입니다.

알림 생성하기

[마이페이지 > 알림 채널] 페이지에는 각 프로토콜에 해당하는 [채널 추가] 버튼이 있습니다.

notification-channel-01

[채널 추가] 버튼을 클릭할 시 아래와 같은 페이지에 진입합니다. 기본 정보 입력 폼은 프로토콜마다 상이하며, 채널명과 알림 스케줄, 구독할 토픽 선택란은 모든 프로토콜이 동일합니다.

notification-channel-02

스케줄을 모든 시간으로 선택할 경우 모든 시간에 알림을 받아볼 수 있습니다. 시간 설정을 선택할 경우, 원하는 요일과 시간을 선택할 수 있습니다.

notification-channel-03

토픽 또한 모든 알림을 받기를 선택할 수도 있고, Alert과 Budget 중 선택한 토픽에 한해 알림을 받을 수 있습니다.

notification-channel-04

생성한 알림 채널 확인하기

모든 입력 폼을 채우고 알림 채널을 생성할 시, 다음과 같이 새롭게 생성된 채널을 확인할 수 있습니다.

notification-channel-created-01

알림 채널 편집하기

생성한 알림은 목록에서 바로 편집할 수 있습니다.

입력한 데이터를 편집할 수 있는 프로토콜의 경우(ex. SMS, Voice Call) 데이터와 채널명, 스케줄, 토픽을 모두 수정할 수 있습니다. 데이터를 편집할 수 없는 프로토콜(ex. Slack, Telegram)은 [편집] 버튼이 활성화되지 않습니다.

notification-channel-edit-01

4.11 - 정보

콘솔 사용 관련하여 최근 업데이트 또는 작업공지와 같은 주요 정보를 확인할 수 있습니다.

4.11.1 - 공지사항

클라우드포레 시스템 관리자 또는 이용중인 고객사의 관리자가 작성한 공지글을 확인할 수 있는 페이지입니다.

공지사항 확인하기

(1) 최근 공지사항 빠른 확인: 상단 메뉴의 알림 버튼 클릭 후 [공지사항] 탭 클릭시, 최근에 등록된 공지글을 확인할 수 있습니다.

gnb-notice-tab

(2) 전체 목록 확인: 상단 메뉴의 가장 오른쪽의 아이콘을 클릭했을 시 나오는 하위 메뉴를 통해 공지사항 전체 목록 페이지로 이동할 수 있습니다.

gnb-profile-menu

공지사항 등록하기

Role Type이 [Admin]인 역할(Role)을 가진 사용자의 경우, 해당 도메인내 공지사항을 직접 작성할 수 있는 권한을 가집니다.

(1) [공지사항] 페이지로 진입하여, [새 공지사항 등록] 버튼을 통해 새 글 작성이 가능합니다.

  • 작성된 공지글은 해당 도메인내 특정 역할(Role)을 할당 받은 전체 사용자에게 공개 됩니다

notice-list

create-notice

(2) 작성된 공지글은 이후에 [수정] 또는 [삭제] 할 수 있습니다.

4.12 - 고급 기능

고급 기능에서는 클라우드포레를 더욱 편리하게 사용할 수 있는 기능들을 설명합니다.

4.12.1 - 커스텀 테이블

커스텀 테이블 기능은 테이블의 필드가 많을 경우, 혹은 필드 순서를 조정하고 싶을 경우 유용한 기능입니다.

테이블의 [설정] 아이콘 버튼을 클릭할 경우, 테이블 필드를 직접 설정할 수 있습니다.

custom-table-01

필드 속성 검색하기

필드를 추천순/알파벳순으로 정렬하거나 필드 이름을 검색할 수 있습니다. 또한 태그 필드를 가지고 있는 경우에도 검색이 가능합니다.

custom-table-02

필드 선택/해제하기

필드 테이블에서 필드를 자유롭게 선택/해제할 수 있습니다. 원하는 필드를 선택한 뒤 [확인] 버튼을 클릭합니다.

custom-table-select-01

필드 정렬하기

자동 정렬

필드 테이블 상단의 [추천순] 혹은 [알파벳순] 버튼을 클릭하면 해당 조건으로 필드가 정렬됩니다. 해당 정렬은 선택한 필드에만 적용됩니다.

custom-table-sort-01

수동 정렬

선택된 필드 오른쪽에 있는 [순서 변경] 아이콘 버튼을 드래그 & 드롭하여 필드를 수동 정렬할 수 있습니다.

custom-table-sort-02

기본 설정으로 되돌리기

커스텀 필드를 기본 설정으로 되돌리고 싶을 경우, [기본 설정으로] 버튼을 클릭합니다.

custom-table-sort-03

4.12.2 - 액셀 내보내기

엑셀 내보내기를 통해 테이블 데이터를 엑셀로 다운로드 할 수 있습니다.

테이블의 [엑셀 내보내기] 아이콘 버튼을 클릭합니다.

excel-export-01

엑셀로 다운로드한 데이터는 다음과 같으며, 만약 커스텀 테이블로 일부 필드만 보이도록 설정했을 경우 해당 필드의 데이터만 볼 수 있습니다.

excel-export-02

4.12.3 - 검색

검색 기능을 활용하여 데이터를 손쉽게 정제하고 확인할 수 있습니다.

데이터 테이블에서 검색창을 사용하는 방법은 두 가지로, 고급 검색과 키워드 검색이 있습니다.

고급 검색

스페이스원에서 제공하는 검색 필드를 사용하면 데이터를 훨씬 편리하게 검색할 수 있습니다. 검색창에 마우스 커서를 올리면 검색할 수 있는 모든 필드명이 나타납니다.

search-query-01

필드 하나를 선택한 뒤, 해당 필드의 값을 직접 입력하거나 추천 목록에서 선택할 수 있습니다.

search-query-02

키워드 검색

특정 필드에 국한되지 않고 모든 필드를 대상으로 검색하고 싶다면 키워드 검색을 사용합니다. 검색창에 텍스트를 입력한 뒤 엔터키를 누르면, 해당 키워드가 포함된 데이터가 필터링되어 테이블에 나타납니다.

search-keyword-01

고급 검색과 키워드 검색은 함께 사용할 수 있으며, 복수 개의 검색이 가능합니다. 검색어는 데이터를 or 조건으로 필터링하여, 필드 값 중 하나라도 부합할 경우 테이블에 보여집니다.

search-keyword-02

4.13 - 플러그인

클라우드포레에서 사용하는 플러그인을 소개합니다.

4.13.1 - [비용 분석] 데이터 소스

클라우드포레는 클라우드 서비스에 대한 비용 데이터를 플러그인으로 수집합니다.

개요

클라우드포레는 클라우드 서비스에 대한 비용 데이터를 플러그인으로 수집합니다.
현재 클라우드포레에서 지원하는 플러그인 목록은 플러그인 지원 목록을 참조하세요.
적합한 플러그인이 없을 경우, 사용자 회사의 빌링 시스템에 적합한 플러그인을 개발 후
클라우드포레에서 활용 가능합니다.

플러그인 지원 목록

플러그인설정 가이드 링크
AWS cost expoloer cost datasourcehttps://github.com/cloudforet-io/plugin-aws-cost-explorer-cost-datasource/blob/master/docs/ko/GUIDE.md
AWS hyperbilling cost datasourcehttps://github.com/cloudforet-io/plugin-aws-hyperbilling-cost-datasource/blob/master/docs/ko/GUIDE.md
Azure cost management cost datasourcehttps://github.com/cloudforet-io/plugin-azure-cost-mgmt-cost-datasource/blob/master/docs/ko/GUIDE.md

4.13.2 - [IAM] 인증

클라우드포레는 사용자 인증를 위한 수단으로 타 서비스의 계정을 사용하는 인증방식을 플러그인으로 제공하고 있습니다.

개요

클라우드포레는 사용자 인증를 위한 수단으로 타 서비스의 계정을 사용하는 인증방식을 플러그인으로 제공하고 있습니다.
현재 클라우드포레에서 지원하는 인증 플러그인 목록은 플러그인 지원 목록을 참조하세요.

구글의 계정을 통해 사용자 인증을 받는 Google Oauth2 플러그인과
표준 프로토콜을 통한 SSO(Single Sign-On)을 지원하는 Keycloak 플러그인을 사용할 수 있습니다.
보다 자세한 설정은 아래 설정 가이드 링크를 참조하세요.

플러그인 지원 목록

플러그인설정 가이드 링크
Google Oauth2https://github.com/cloudforet-io/plugin-googleoauth2-identity-auth/blob/master/docs/ko/GUIDE.md
Keycloakhttps://github.com/cloudforet-io/plugin-keycloak-identity-auth/blob/master/docs/ko/GUIDE.md

4.13.3 - [얼럿 매니저] 알림

클라우드포레는 사용자에게 얼럿을 전달하기 위한 알림 수단으로 플러그인을 제공하고 있습니다.

개요

클라우드포레는 사용자에게 얼럿을 전달하기 위한 알림 수단으로 플러그인을 제공하고 있습니다.
현재 클라우드포레에서 지원하는 플러그인 목록은 플러그인 지원 목록을 참조하세요.
Telegram과 Slack 연동에 대한 보다 자세한 설명은 아래 링크를 참조해 주십시오.
반면, Email, SMS 그리고 Voice Call은 별도의 설정없이 사용 가능합니다.

플러그인 지원 목록

플러그인설정 가이드 링크
Telegramhttps://github.com/cloudforet-io/plugin-telegram-noti-protocol/blob/master/docs/ko/GUIDE.md
Slackhttps://github.com/cloudforet-io/plugin-slack-noti-protocol/blob/master/docs/ko/GUIDE.md
Email별도 설정 없이 사용가능
SMS별도 설정 없이 사용가능
Voice Call별도 설정 없이 사용가능

4.13.4 - [얼럿 매니저] 웹훅

클라우드포레는 다양한 모니터링 서비스로부터 발생하는 이벤트 메시지를 수신받기 위해 플러그인 형태의 웹훅을 지원하고 있습니다.

개요

클라우드포레는 다양한 모니터링 서비스로부터 발생하는 이벤트 메시지를 수신받기 위해 플러그인 형태의 웹훅을 지원하고 있습니다.
현재 클라우드포레에서 지원하는 웹훅 플러그인 목록은 플러그인 지원 목록을 참조하세요.

특히, AWS CloudWatch와 AWS PHD(PersonalHealthDashboard)에서 발생하는 이벤트 메세지는
AWS SNS(Simple Notification Service) Webhook을 통해 클라우드포레로 수집됩니다.

모니터링 서비스 별 설정 가이드는 아래 플러그인 지원목록의 설정 가이드 링크를 참고 하십시오.

플러그인 지원 목록

플러그인설정 가이드 링크
AWS SNShttps://github.com/cloudforet-io/plugin-aws-sns-mon-webhook/blob/master/docs/ko/GUIDE.md
Grafanahttps://github.com/cloudforet-io/plugin-grafana-mon-webhook/blob/master/docs/ko/GUIDE.md
Prometheushttps://github.com/cloudforet-io/plugin-prometheus-mon-webhook/blob/master/docs/ko/GUIDE.md
Zabbixhttps://github.com/cloudforet-io/plugin-zabbix-mon-webhook/blob/master/docs/ko/GUIDE.md

4.13.5 - [에셋 인벤토리] 컬렉터

클라우드포레는 컬렉터 플러그인을 사용해 각각의 클라우드 프로바이더에서 사용중인 클라우드 리소스를 수집할 수 있습니다.

개요

클라우드포레는 컬렉터 플러그인을 사용해 각각의 클라우드 프로바이더에서 사용중인 클라우드 리소스를 수집할 수 있습니다.
현재 클라우드포레에서 지원하는 컬렉터 목록은 아래 플러그인 지원목록을 참조하세요.

먼저, 컬렉터 플러그인을 사용하기 위해서 서비스 계정 등록을 선행합니다.
그러나 AWS, Google Cloud, Azure 등 각 클라우드 프로바이더별 서비스 계정 등록 방법이 상이하기 때문에
상세한 설정은 아래 플러그인 지원 목록의 설정 가이드 링크를 참고 하십시오.

플러그인 지원 목록

플러그인설정 가이드 링크
AWS Cloud Services collectorhttps://github.com/cloudforet-io/plugin-aws-cloud-service-inven-collector/blob/master/docs/ko/GUIDE.md
AWS EC2 Compute collectorhttps://github.com/cloudforet-io/plugin-aws-ec2-inven-collector/blob/master/docs/ko/GUIDE.md
AWS Personal Health Dashboard collectorhttps://github.com/cloudforet-io/plugin-aws-phd-inven-collector/blob/master/docs/ko/GUIDE.md
AWS Trusted Advisor collectorhttps://github.com/cloudforet-io/plugin-aws-trusted-advisor-inven-collector/blob/master/docs/ko/GUIDE.md
Azure Cloud collectorhttps://github.com/cloudforet-io/plugin-azure-inven-collector/blob/master/docs/ko/GUIDE.md
Google Cloud collectorhttps://github.com/cloudforet-io/plugin-google-cloud-inven-collector/blob/master/docs/ko/GUIDE.md
Monitoring Metric Collector of Collected Resourceshttps://github.com/cloudforet-io/plugin-monitoring-metric-inven-collector/blob/master/docs/ko/GUIDE.md

4.14 - 프로바이더별 계정 연동

CSP(클라우드 프로바이더)에 따라 Cloudforet 시스템과의 자동 동기화 방법을 확인할 수 있습니다.

4.14.1 - AWS 계정 자동 동기화

AWS Control Tower 계정 연동 가이드

SpaceONE(Cloudforet)이 제공하는 Account Auto Sync를 통해 AWS Control Tower를 기준으로 하위에 존재하는 관리 그룹의 계층을 SpaceONE에 동기화 할 수 있습니다.



계층 구조 동기화

SpaceONE의 Trusted Service Account를 통해 AWS의 Account 계층 구조를 자동으로 동기화할 수 있습니다.

각각의 구독을 기준으로 계층을 파악하여 동기화 되며 SpaceONE의 워크스페이스, 프로젝트 그룹, 프로젝트 그리고 서비스어카운트로 동기화가 이루어 집니다.


[자동 동기화 기준]

AWSSpaceONE(Cloudforet)
RootWorkspace
최상위 OUs(Organization Units)Workspaces, Project Groups
하위 OUs(Nested Organization Units)Project Groups
Resources, Member accountsProject and Service Account

[AWS 계층 구조 참고]



권한 부여

1) AWS Cloudformation을 이용하여 SpaceONE 전용 Role 생성하기

  • Sync 작업을 진행하기 전 먼저 SpaceONE이 이용할 수 있는 IAM Role를 하위 member account별로 생성합니다.
  • Role 자동생성을 위해 Management Account에 CloudFormation StackSet를 생성합니다.

[AWS CloudFormation StackSet을 생성하는 과정]

  • Template 선택: Stack Resource와 구성을 정의하는 CloudFormation 템플릿을 준비합니다.


  • StackSet 세부 정보 지정: StackSet의 이름, 설명, 필요한 파라미터를 입력합니다.


  • StackSet 옵션 구성: StackSet의 실행방식 등을 구성합니다.

  • 위의 화면을 참조하여
    • 태그는 Optional인 관계로 기호에 따라 추가해줍니다.
    • 실행 구성은 “비활성” 으로 선택합니다.

  • 배포 옵션 설정: StackSet을 적용할 대상 및 자동 배포 유무 등을 설정합니다.

  • 위의 화면들을 참조하여,
    • 스택 세트에 스택 추가는 “새 스택 배포”를 선택
    • 배포 대상은 “OU(조직 단위)에 배포” 선택
      • AWS OU ID는 AWS Control Tower의 Management Account의 root id를 입력합니다.
      • 계정 필터 유형은 “차집합” 선택
      • 계정 번호는 role 생성을 제외시킬 Security OU에 있는 Audit 과 Log Archive Account의 ”Account ID”를 입력합니다.
        • Ex. 386390908341, 942155983773
        • Audit과 Log Archive에 Role 생성을 하지 않을 뿐, Account Sync하는 과정에서 빠지진 않습니다.
    • 자동 배포 옵션은
      • 자동 배포 “활성화됨”
      • 계정 제거 동작은 “스택 삭제”
    • 리전 지정은 해당 Control Tower가 있는 리전을 지정합니다. (보통은 “아시아 태평양(서울)”)
    • 배포 옵션은 따로 변경하는 것 없이 진행합니다.

2) Management Account에 IAM User 생성하기

SpaceONE Console에 등록하려는 AWS account의 User는 아래의 permissions를 가져야 합니다.

(아래의 예시는 spaceone-test라는 이름의 User입니다.)

  • ReadOnlyAccess(AWS Managed Policy)
  • sts.AssumeRole Policy
    • 위 사진의 SpaceONEAssumeRolePolicy와 같이 사전에 Cloudformation StackSet으로 생성한 role에 대해 assume role권한을 허용하는 policy가 필요합니다.
    • (YOUR_SPACEONE_ROLE_NAME = IAM Role 생성에서 만든 Role Name을 넣어주세요.)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::*:role/YOUR_SPACEONE_ROLE_NAME"
            ]
        }
    ]
}



자동화 결과

SpaceONE의 Account Auto Sync 기능은 Trusted Account Scope에 따라 다르게 적용됩니다.


✔️ Domain Scope의 Trusted Account (Admin Mode에서 생성 가능)

Domain에서 생성된 Trusted Account의 경우, 아래 두 가지로 설정이 가능합니다.

방법1) Organization이 SpaceONE의 단일 Workspace가 되어 하위의 전체 프로젝트 및 계정 동기화가 적용될 수 있습니다.

AWSSpaceONE(Cloudforet)
RootWorkspace
OUs(Organization Units)Project Groups
Resources, Member accountsProject and Service Account

방법 2) 최상위 OUs(Organization Units)를 다중의 Workspace로 동기화할 수 있습니다. 이는 좀 더 관리 체계를 조직 단위로 구성함으로써 성능 및 관리에 최적화할 수 있습니다.

AWSSpaceONE(Cloudforet)
최상위 OUs(Organization Units)Workspaces
하위 OUs(Nested Organization Units)Project Groups
Resources, Member accountsProject and Service Account

✔️ Workspace Scope의 Trusted Account

Workspace에서 생성된 Trusted Account의 경우 Workspace 하위에 동기화가 적용됩니다.

AWSSpaceONE(Cloudforet)
OUs(Organization Units)Project Groups
Resources, Member accountsProject and Service Account

4.14.2 - Azure 계정 자동 동기화

Azure 구독 기준의 계정 연동 가이드

SpaceONE(Cloudforet)이 제공하는 Account Auto Sync를 통해 Azure 구독을 기준으로 Tenant 포함 하위에 존재하는 관리 그룹의 계층을 SpaceONE에 동기화 할 수 있습니다.



계층 구조 동기화

SpaceONE의 Trusted Service Account를 통해 Azure의 Resource 계층 구조를 자동으로 동기화할 수 있습니다.

각각의 구독을 기준으로 계층을 파악하여 동기화 되며 SpaceONE의 워크스페이스, 프로젝트 그룹, 프로젝트 그리고 서비스어카운트로 동기화가 이루어 집니다.


[자동 동기화 기준]

AzureSpaceONE(Cloudforet)
Azure AD TenantWorkspace, Project Group
Management GroupsProject Group
SubscriptionProject and Service Account

[Azure 계층 구조 참고]


Azure CSP 공급자가 관리하는 고객의 구독에 대한 동기화 과정은 아래와 같습니다.

  • 먼저 관리하는 고객(customer)의 리스트를 조회합니다.
  • 고객이 소유한 구독의 정보를 조회합니다.
  • 만약 App이 고객의 관리 그룹의 대한 조회 권한이 있을 경우 구독이 속한 Management Group의 계층 구조를 조회합니다.

권한 부여

SpaceONE에서 Service Account Auto Sync 기능을 사용하기 위해 Azure의 서비스 주체(Service Principal)에 권한을 올바르게 할당해야 합니다.


➊ Management Group

Azure의 공식 문서를 참고하여 관리그룹의 IAM에 생성한 앱을 등록해 주세요.

필요 권한은 관리 그룹 읽기 권한자 입니다.


➋ CSP

Azure의 공식 문서를 참고하여 비용 분석의 IAM에 생성한 앱을 등록해 주세요. CSP의 권한으로 고객의 테넌트와 구독 정보를 가져옵니다. 필요 권한은 비용 관리 읽기 권한자 입니다.


➌ EA (지원 예정)



자동화 결과

SpaceONE의 Account Auto Sync 기능은 Trusted Account Scope에 따라 다르게 적용됩니다.


✔️ Domain Scope의 Trusted Account (Admin Mode에서 생성 가능)

Domain에서 생성된 Trusted Account의 경우, Tenant가 SpaceONE의 (멀티 또는 단일)Workspace가 되어 동기화가 적용됩니다.

AzureSpaceONE(Cloudforet)
Azure AD TenantWorkspace
Management GroupsProject Group
SubscriptionProject and Service Account

✔️ Workspace Scope의 Trusted Account

Workspace에서 생성된 Trusted Account의 경우 Workspace 하위에 동기화가 적용됩니다.

AzureSpaceONE(Cloudforet)
Azure AD TenantProject Group
Management GroupsProject Group
SubscriptionProject and Service Account

4.14.3 - GCP 계정 자동 동기화

Google Cloud 관리 쳬계 기준의 계정 연동 가이드

SpaceONE(Cloudforet)이 제공하는 Account Auto Sync를 통해 Google Cloud 계정을 기준으로 하위에 존재하는 관리 그룹의 계층을 SpaceONE에 동기화 할 수 있습니다.



계층 구조 동기화

SpaceONE의 Trusted Service Account를 통해 GCP의 Organization 계층 구조를 자동으로 동기화할 수 있습니다.

각각의 구독을 기준으로 계층을 파악하여 동기화 되며 SpaceONE의 워크스페이스, 프로젝트 그룹, 프로젝트 그리고 서비스어카운트로 동기화가 이루어 집니다.


[자동 동기화 기준]

Google cloudSpaceONE(Cloudforet)
OrganizationWorkspace
FolderWorkspace, Project Group
ProjectProject
Service AccountService Account

[GCP 계층 구조 참고]

Google Cloud의 관리 체계는 Organization > Folder > Project 구조로, SpaceONE과 동일한 구조를 가지는 것을 확인해볼 수 있습니다. 마찬가지로 Google Cloud계정은 이름이 동일한 Service Account를 가지고 있습니다.


권한 부여

SpaceONE에서 Service Account Auto Sync 기능을 사용하기 위해 Organization에 사용 중인 Trusted Account 설정에 사용된 Service Account에 조직 뷰어(Organization Viewer), 폴더 뷰어(Folder Viewer)에 대한 롤을 추가해야 합니다.



자동화 결과

SpaceONE의 Account Auto Sync 기능은 Trusted Account Scope에 따라 다르게 적용됩니다.


✔️ Domain Scope의 Trusted Account (Admin Mode에서 생성 가능)

Domain에서 생성된 Trusted Account의 경우, 아래 두 가지로 설정이 가능합니다.

방법1) Organization이 SpaceONE의 단일 Workspace가 되어 하위의 전체 프로젝트 및 계정 동기화가 적용될 수 있습니다.

Google CloudSpaceONE(Cloudforet)
OrganizationWorkspace
FolderProject Group
ProjectProject
Service AccountService Account

방법 2) 최상위 Google Cloud Folder를 다중의 Workspace로 동기화할 수 있습니다. 이는 좀 더 관리 체계를 조직 단위로 구성함으로써 성능 및 관리에 최적화할 수 있습니다.

Google CloudSpaceONE(Cloudforet)
최상위 FolderWorkspace
하위 FolderProject Group
ProjectProject
Service AccountService Account

✔️ Workspace Scope의 Trusted Account

Workspace에서 생성된 Trusted Account의 경우 Workspace 하위에 동기화가 적용됩니다.

Google CloudSpaceONE(Cloudforet)
FolderProject Group
ProjectProject
Service AccountService Account

4.14.4 - Kubernetes 계정 연동

Kubernetes Cluster 계정 연동 가이드

쿠버네티스 서비스 어카운트 생성하기

(1) [에셋 인벤토리 > 서비스 계정] 페이지에서 쿠버네티스 서비스를 선택합니다.

(2) [+생성] 버튼을 클릭합니다.

(3) 서비스 계정 생성 폼을 작성합니다.

(3-1) SpaceONE에 생성하고자 하는 서비스 어카운트 이름을 입력합니다.

(3-2) 해당 서비스 계정에 연결할 프로젝트를 지정합니다.

(4) [추가] 버튼을 클릭하여 완료합니다.


쿠버네티스 클러스터 연결하기

(1) 연결하고자 하는 서비스 어카운트 페이지에서 [+클러스터 연결하기] 버튼을 클릭합니다.

(2) 클러스터 기본 정보를 작성합니다.

(2-1) 시스템에 설치되어 있는 클러스터 이름을 입력합니다.

(2-2) kube-state-metrics, prometheus-node-exporter 두 가지 항목이 클러스터에 설치되었는지 확인이 필요합니다.

만약, 하나의 항목이라도 설치되어 있지 않다면 SpaceONE 에이전트에서 대신 설치됩니다.

(3) 로컬 helm 저장소에 SpaceONE 에이전트 추가합니다.

(4) 클라우드 셀이나 터미널에 코드를 복사하여 SpaceONE 에이전트를 클러스터에 설치합니다.

(5) [완료] 버튼을 클릭하여 클러스터 연결을 완료합니다.


쿠버네티스 클러스터 연결하기

삭제하고자 하는 서비스 어카운트 페이지에 진입합니다.

삭제 아이콘 버튼을 통해 해당 서비스 어카운트를 삭제할 수 있습니다.

서비스 어카운트 삭제시 해당 어카운트로 수집된 모든 데이터가 유실됩니다.


연결된 쿠버네티스 클러스터 편집하기

편집하고자 하는 서비스 어카운트 페이지에 진입합니다.

연결된 쿠버네티스 클러스터 비활성화하기

[비활성화] 버튼을 눌러 클러스터 연결을 일시적으로 해제할 수 있습니다.

연결된 쿠버네티스 클러스터 재연결하기

[재연결] 버튼을 눌러 클러스터를 다시 연결할 수 있습니다.

연결된 쿠버네티스 클러스터 삭제하기

[삭제] 버튼을 클릭하여 연결된 클러스터 정보를 삭제할 수 있습니다.

5 - 개발 가이드

Cloudforet Development Guides

5.1 - Frontend

SpaceONE Development Guides

5.1.1 - Software Architecture

Software Architecture

Frontend S/W Architecture

5.1.1.1 - Frontend Error Handling

How To Handle Error

Error 구분에 따른 처리 (API)


다양한 API Error를 처리하기 위해 미리 에러 타입을 정의한다.

  • NotFoundError : 리소스를 찾을 수 없을 때 (status: 404)

  • BadRequestError : 잘못된 요청을 보낼 때 (status: 400)

  • AuthenticationError: 인증이 실패했을 때 (status: 401)

  • AuthorizationError: 권한 검증에 실패했을 때 (status: 403)

  • APIError: 이외의 모든 API Error 및 서버 에러 (status: 500 등)

이 에러들을 axios api client의 interceptor에서 받아 핸들링한다. 위에 명시된 에러 이외에 다른 에러 코드를 정의할 수도 있다.


이 에러들을 SpaceConnector(axios api client)의 interceptor에서 받아 핸들링한다.

axios의 interceptor에서 error가 왔을 때, 각 statusCode를 보고 판별하여 위에 미리 정의해둔 Error로 throw해준다.

Error Handler (Client)


Client 쪽에서 API client를 통해 넘어온 Error의 유형을 판단하여 다음과 같이 핸들링한다.

AuthenticationError의 경우

Token이 유효한 지 확인하고, 유효하지 않을 경우 Authentication Error Handler를 호출하여 에러를 처리한다.

Authentication Error Handler는 다음과 같은 동작을 한다.

  • Session 만료 모달을 보여줌

  • User의 Session을 만료시킴

AuthorizationError의 경우

Authorization Error Handler를 호출한다. 이 핸들러는 다음과 같은 동작을 한다.

상단에 권한이 없다는 경고창을 노출시킴

NoResourceError의 경우

No Resource라는 토스트를 보여주고, redirect url이 있을 시 해당 url로 이동시킨다.

APIError의 경우

콘솔창에 API Error라고 명시된 로그를 남긴다.

BadRequestError의 경우

페이지에서 넘겨준 Error Message가 적힌 toast 경고창을 띄운다.


Error를 추가하는 방법


  1. SpaceConnector(console-core-lib > space-connector/error.ts)에 새로운 에러를 정의한다.

  2. SpaceConnector의 Error Interceptor(console-core-lib > space-connector/api.ts)에 새로운 에러를 throw해주는 부분을 추가해준다.

  3. API의 error가 아니라 Client 자체에서 필요한 에러의 경우 Client(console > common/error.ts)에 새로운 에러를 정의하고, 에러가 발생할 시 해당 에러를 throw한다.

  4. Error Handler(console > common/composables/error/errorHandler.ts)에 새롭게 추가된 Error를 핸들링하는 코드를 추가한다.

Error를 사용하는 방법


에러 클래스를 작성하고, 그 에러 클래스를 이용해 만든 에러 핸들러를 실제 프로젝트에서는 아래와 같이 사용한다.


  • list 등 일반적인 작업
try {
    특정 동작
} catch (e) {
    ErrorHandler.handleError(e);
}
  • create/update 등 실패 시 toast message를 보여주어야 하는 작업
try {
    특정 동작
} catch (e) {
    ErrorHandler.handleRequestError(e, 번역을 위한 i18n key값 or string);
}

5.1.1.2 - Frontend Authentication

How To Authenticate SpaceONE User

인증 플로우


SpaceONE은 현재 도메인 설정에 따라 Google Oauth2, Keycloak, KB SSO 세 가지의 인증 중 하나를 선택하여 제공하고, 인증 플로우는 다음과 같습니다.
![](/docs/developers/frontend/software_design/authentication/authentication_img/authentication_uml.png)
1. 우선 해당 도메인에서 어떤 Sign-in 방식(ID/PW인지, 외부 인증을 제공하는 지, 제공한다면 어떤 인증방식인지)을 사용하는 지 체크합니다. 2. 그 후, 각각 다른 Sign-in 방식에 맞는 UI를 보여주고, 해당 템플릿에서 Authenticator를 상속받은 커스텀 인증 모듈의 메소드를 호출합니다. 3. 각각의 커스텀 Auth들은 각자 필요한 Sign-in 절차를 수행한 후, 상속받은 Authenticator의 기본 Sign-in 로직을 수행합니다.

이후 이루어지는 인증 플로우는 다음과 같습니다.

Authenticator


Authenticator는 다음과 같은 구조를 가집니다.


최상위 Authenticator는 아주 기본적인 signIn과 signOut 메서드만 가지는 추상 클래스입니다.

abstract class Authenticator {
	static async signIn(필요한 매개변수): Promise<void> {
    	// sign in 로직
    }

    static async signOut(): Promise<void> {
    	// sign out 로직
    }
}

export {
	Authenticator,
}

signIn을 위해 백엔드 인증 서버에 보낼 credentials라는 데이터가 필수적이고, userId와 userType(일반 User인지, 관리자인지, API만 사용하는 API user인지)을 부수적으로 받습니다. signOut에서는 vuex에 작성해놓은 signOut 메서드를 호출합니다.


## 커스텀 인증 구조
이제 기본적인 추상 클래스 작성이 끝났으니, 이 클래스를 상속받아 각 SSO에 맞는 Auth 클래스들을 작성합니다. 위의 구조도를 보면 알 수 있듯이, Auth를 구현하는 데에 필요한 것은 두 가지가 있습니다. 바로 폼 렌더링(SSO 버튼 등)을 위한 템플릿과, 메서드들을 구현한 module(.ts) 파일입니다.

커스텀 인증 클래스


각 커스텀 인증에 맞는 Sign In, Sign Out 로직과 추상 클래스 Authenticator의 인증(기본 인증)을 수행하는 로직이 필요합니다. Authenticator의 Sign In은 credentials라는 data를 필요로 하고, 이 credentials 안에 들어가는 데이터는 모든 커스텀 인증마다 상이합니다.
// custom-auth.ts

class CustomAuth extends Authenticator {
    const signIn = async () => {
        // 각 SSO, 커스텀 인증에 필요한 Sign in 로직
        const credentials = { // 각 커스텀 인증에서 생성된 credentials }
        super.signIn(credentials);
    }

    const signOut = async () => {
        // 각 SSO, 커스텀 인증에 필요한 Sign Out 로직
        super.signOut();
    }
}

결론적으로, 커스텀 Auth class 내부에 상속받은 Authenticator(=super)의 함수들을 호출하여 SpaceONE의 인증을 동시에 수행할 수 있도록 합니다.

커스텀 인증 클래스 loader


이제 어떤 인증 클래스를 부를 건지 결정하는 loader를 간단하게 만들어보도록 합니다.
export const loadAuth = (authType?) => {
    if (authType === 'CUSTOM_AUTH') return CustomAuth;
    return SpaceAuth;
};

SignIn은 개별 템플릿을 가지지만, SignOut은 어디에서든 호출될 수 있기 때문에 위와 같은 loader를 사용하여 현재 도메인의 인증 타입을 넣으면 알맞은 인증 로직을 수행할 수 있도록 작성합니다.

커스텀 인증 템플릿


위의 작업을 하고난 후 마지막 작업은 폼 렌더링입니다.
//Custom Auth의 template(external/custom/template/CUSTOM_AUTH.vue)

<template>
	<div>Custom 로그인을 위한 폼 버튼</div>
</template>

<script lang="ts">
 setup() {
 	//필요한 로직들
 	onMounted(async() => {
    		try {
            	await loadAuth('CUSTOM_AUTH').signIn(); //loader를 사용하여 customAuth 클래스의 signIn 함수 호출
            } catch (e) {
            	//에러 핸들링
            }
        }
    )
 }
</script>

각 커스텀 인증은 저마다의 폼 렌더링이 필요하기 때문에 위와 같이 해당 Auth에 맞는 커스텀 템플릿을 작성해줍니다.
그리고 마지막으로 커스텀 템플릿을 SignIn Page에서 보여줍니다. vue에는 라는 문법으로 다이나믹하게 컴포넌트를 불러올 수 있는 문법이 존재합니다.(https://kr.vuejs.org/v2/guide/components-dynamic-async.html) 해당 문법을 이용하여

//sign-in page
<component :is="component" class="sign-in-template"
	@sign-in="handleSignIn"
/>

이렇게 템플릿 부분에 작성해주고, 아래 스크립트 부분에서

//sign-in page
  const state = reactive({
  	...
	component: computed(() => {
                let component;
                const auth = state.authType;
                if (auth) {
                    try {
                        component = () => import(`./external/${auth}/template/${auth}.vue`);
                    } catch (e) {
                        //필요한 에러 핸들링.
                    }
                }
                return component;
            }),
  })

위와 같이 dynamic import 방식을 사용하여 컴포넌트를 렌더링합니다.

TL;DR

  1. 외부 인증 뿐만 아니라 자체 인증 또한 성공해야 하기 때문에 자체 인증만을 구현한 추상 클래스를 만듭니다.
  2. 해당 추상 클래스를 상속하여 구현한 커스텀 인증 클래스들을 만들어 해당 클래스 내부에서 커스텀 인증 로직을 처리하고, super class의 인증도 처리합니다.
  3. 해당 커스텀 클래스를 불러오기 위한 loader를 추가합니다.
  4. 커스텀 클래스의 폼을 렌더링하기 위한 template을 작성해줍니다.
  5. Sign In 페이지에서 다이나믹하게 해당 template을 불러서 렌더링합니다.

5.1.1.3 - Config Management

How To Manage Frontend Configuration

App에 필요한 구성 요소를 정의한다. 주로, 환경 별로 다른 값을 다룬다.

환경 별 우선순위

default.json이 우선적으로 적용된다.

development 환경일 경우, development.json의 값이 덮어 쓰여 적용된다.

환경 설정 방법

Dockerfile 수정

Dockerfile에서 npm run build 커맨드 전 NODE_ENV로 환경 설정 가능

...
ENV NODE_ENV development
...

Webstorm Configurations 수정

Run/Debug Configuration 설정 시 Environment 필드값 수정

Default Config 정보

NameDescription
CONSOLE_API콘솔에서 사용하는 API의 엔드포인트를 정의
GTAG_IDGoogle Analytics를 위해 사용
DOMAIN_NAME사이트 도메인 이름
DOMAIN_NAME_REF‘hostname’ 일 경우, 사이트 도메인 이름을 추출하여 Domain 정보 로드
ADMIN_DOMAIN
AMCHARTS_LICENSE차트 라이브러리인 amcharts의 라이센스 정보
MOCKMOCK API 사용 여부 및 MOCK API의 엔드포인트 정의
ASSET_PATHasset에 사용되는 엔드포인트 정보
DOMAIN_IMAGESignIn 페이지 및 GNB에 사용되는 이미지의 url 정의
DOCS관련 문서 링크를 만들기 위한 정보
- label, link 를 가진 객체 배열
- ejs template 문법을 지원
 - 제공 변수: lang (사용자 언어 코드. e.g. "en")
BILLING_ENABLEDbilling 서비스 이용 가능한 도메인 리스트 정의
CONTACT_LINKSignIn 페이지의 contact us 링크 정의
  • development.json 권장 예시
    {
    "VUE_APP_API": {
      "ENDPOINT": "https://sample.com"
    },
    "GTAG_ID": "DISABLED",
    "DOMAIN_NAME": "sample",
    "DOMAIN_NAME_REF": "config",
    "ASSETS_ENDPOINT": "https://sample-asset.com/assets/"
}

Config 파일 위치

  • Default: <SOURCE_ROOT>/public/config/default.json
  • Each Environment: <SOURCE_ROOT>/public/config/<NODE_ENV>.json

Config 사용 방법

import config from '@/lib/config'

config.get(); // All Values
config.get('VUE_APP_API.ENDPOINT'); // Value of specific key

5.1.2 - 시작하기

이 페이지는 SpaceOne Console 개발을 시작하기 위한 안내문서입니다.

개발 환경 세팅

Fork

현재 스페이스원의 콘솔은 오픈소스로 운영중에 있습니다.

개발에 기여하기위해 먼저 console 레포지토리를 개인 github 계정에 포크해 줍니다.

Clone

이후 포크해온 레포지토리를 로컬로 클론해 줍니다.

서브모듈로 assets과 번역 관련 레포지토리가 사용중이기 때문에 함께 초기화합니다.

git clone --recurse-submodules https://github.com/[github username]/console

cd console

Run Console

콘솔을 실행 실행시키기 위해 npm으로 의존성을 설치합니다.

npm install --no-save

이후 개발환경을 위한 config 파일을 public/config/development.json 작성합니다. (config 파일 작성은 여기를 참고 하십시오)


마지막으로 스크립트를 실행합니다.

npm run serve

Build

배포 가능한 zip을 생성하려면 아래의 스크립트를 실행하시면 됩니다.

npm run build

차트 라이선스

콘솔은 내부적으로 모든 차트에 대해 amCharts를 사용합니다.

콘솔을 사용하기 전에 amCharts의 라이선스를 확인하시고, 자신에게 맞는 amCharts 라이선스를 구매하여 콘솔에서 사용하려면 아래와 같이 진행해주십시오.


public/config/default.json에 라이센스 키 추가

{
    "AMCHARTS_LICENSE": {
    "CHARTS": "",
    "MAPS": "",
    "TIMELINE": ""
    }
}

스타일


스타일 정의에 있어 SpaceOne Console은 tailwind css와 postcss를 사용중에 있습니다.

SpaceOne의 color palette에 따라 tailwind 커스텀을 통해 적용되어 있습니다. (세부 정보는 storybook을 참고해주세요)

5.1.3 - Coding Convention

Frontend Coding Convention

프론트엔드 코딩 컨벤션에 대한 문서입니다. Console, Design System, Core Lib

Javascript - ECMAScript 2018(ES9)

ItemCategoryRuleExample
ClassPascalCaseclass myClass {}
FunctioncamelCaseconst myFunction = () => {}
VariableReadonly const
Enum		SCREAMING_SNAKE_CASEconst READONLY_CONST <br /> MY_ENUM {}
OtherscamelCasemyVariable

Typescript

ItemCategoryRuleExample
TypePascalCasetype MyType = type;
InterfacePascalCaseinterface MyInterface {}

File / Directory / URL

ItemRepoCategoryRuleExample
FilesConsoleVue ComponentsPascalCaseMyComponent.vue
PagesPascalCase
with suffix 'Page'		MyConsolePage.vue
Design SystemComponents
Related Files		PascalCase
with prefix 'P' (means 'Prime')
with its component name		PMyDSComponent.vue
PMyDSComponent.mdx
PMyDSComponent.stories
PMyDSComponent.scss
PMyDSComponent.pcss
Type Related Fileskebab-case
with suffix '-type'		type.ts
schema-type.ts
Other FilesCommonkebeb-casemy-config.ts
Directory
URL		Commonkebab-case/my-directory
/my-url/

Code

ItemRepoCategoryRuleExample
EventCommonNameVerb Root
If duplicated or needed -ed / -ing is allowed		update
update, updated
Two-way BindingIf the event needs two-way biding, emit 'update:xxx'$emit('update:code', code)
Arguments$event as the last argument$emit(foo, bar, $event)
CodeCommonHandler NameClear word with prefix 'handle'const handleOnClick = () => {}
Component NamePascalCase at script files
kebab-case at template		<my-component />
import MyComponent from @
Composition API1. Do not declare objects,variables inside return
2. The name of reactive variable should be state or xxxState (if needed)
3. Using variable inside setup() is recommended as reactive		1. const a = 1; return { a }
2,3. const state = reactive({})
ConsolePage script, style1. <script> lang should be 'ts'
2. <style> lang should be 'postcss' and 'scoped'		1. <script lang="ts">
2. <style lang="postcss" scoped>
Design SystemPage script, style1. <script> lang should be 'ts'
2. <style> lang should be 'postcss' BUT NO 'scoped'		1. <script lang="ts">
<style lang="postcss">
Storybook TitleDirectories + component name(PascalCase) with dash{ title: 'atoms/buttons/MyButton' ... }
Root Class NameComponent name should be written on root element's class with kebab-case<fragment class="p-my-button">
Core LibDescriptionDescription of each function should be written, by JS Doc/** @@function @name @description *@param descriptions **/

Additional Rules

  1. Array 에서 변수명 지정은 복수형보다 List 접미사를 지향합니다.
const policies: Array<string>; (X)
const plicyList: Array<string>; (O)
  1. enum 혹은 Object.freeze() 대신 as const 를 사용합니다.
const NOTIFICATION_UNIT = {
  PERCENT: 'PERCENT',
  ACTUAL_COST: 'ACTUAL_COST',
} as const;
  1. API 응답 결과값에 대한 interface 명은 xxxModel 이라고 명명합니다.
interface CostQuerySetModel {};

  1. init 할 때 실행할 함수는 setup 함수 최하단에 위치시키는 것을 지향합니다.

    async 인 경우에는 즉시실행함수로 작성합니다.

(async () => {
	await listCostQuerySet();
})();

return { ...toRefs(), ... }

Test Code

console과 Design System 에서는 공통적으로 vue test utils 를 사용합니다.

파일명: __test__/<대상 파일 명>.test.ts

테스트코드 템플릿

import { mount, createLocalVue } from '@vue/test-utils';
import CompositionApi, { defineComponent } from '@vue/composition-api';

const localVue = createLocalVue();
localVue.use(CompositionApi);

describe('', () => {
    const mockComponent = defineComponent({
        template: `
            <div>
            </div>
        `,
        setup() {
            return {};
        },

    });

    const wrapper = mount(mockComponent, { localVue });

    it('', () => {
        expect(wrapper.exists()).toBe(true);
    });
});

Lint

References

5.1.4 - Commit Convention

Frontend Commit Convention

프론트엔드 커밋 컨벤션에 대한 문서입니다. Console, Design System, Core Lib

커밋 메시지 구조

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

커밋 메시지 구조적 요소

TypeDescriptionRemark
fixBug Fix
API 변경 사항 없이 내부 수정		PATCH
feat기능 추가
API 변경 (하위 호환)		MINOR
perf성능 향상을 위한 코드 변경MAJOR
BREAKING CHANGEAPI 의 변경, 큰 변화MAJOR
refactor내부적인 리팩토링앵귤러 컨벤션
ciCI 변경 (workflow, etc)앵귤러 컨벤션
buildbuild 관련 변경 (webpack, dependencies, etc)앵귤러 컨벤션
docs문서 작성, 수정앵귤러 컨벤션
style코드 의미적으로는 변하지 않는 커밋 (css, formatting, missing semi-colons, etc)앵귤러 컨벤션
revert이전 커밋으로 revert앵귤러 컨벤션
chore그 외 자잘한 수정앵귤러 컨벤션

주의 사항

  1. 반드시 커밋 메시지 구조에 맞는 메시지를 작성하여야 합니다.
    1. 컨벤션과 다를 시, commitLint 에 의해 commit 이 fail 할 수 있습니다.
  2. 타입 뿐 아니라 적용 범위, 설명, 본문, 꼬리말 모두 영어로 작성하는 것을 지향합니다.

References

5.2 - Plugins

SpaceONE Deep Dive

5.2.1 - Developer Guide

Developer Guide

Plugin 은 Protobuf 를 사용하는 어떤 언어로도 개발 가능하다.
Micro Service 와 Plugin 통신은 모두 Protobuf 를 기본으로 사용하기 때문이다. 기본적인 구조는 gRPC interface 를 사용한 서버 개발 과정과 동일한 방식이다.

Plugin 개발시 어떤 언어로든 (gRPC interface 가 사용 가능한 모든 언어) 개발이 가능하지만,
우리가 제공하는 Python Framework 를 사용한다면 더욱 손쉽게 개발 가능하다.
현재 기본적으로 제공되는 Plugin 들 모두 Python 기반의 자체 개발된 Framework 를 기반으로 개발되었다.

Framework 에 대한 기본적인 사용 방법에 대해서는 다음을 참고한다.

다음은, Plugin 개발시 기본적으로 확인해야 하는 개발 요건 사항이며, 각 페이지에서 단계별 상세 사항을 확인 가능하다.

5.2.1.1 - gRPC Interface 확인

먼저, 개발하고자 하는 Plugin 과 Core 서비스 간의 Interface 를 확인한다. interface 는 각각의 서비스 마다 구조가 다르다. 이에 대한 gRPC interface 정보는 API 문서에서 확인 가능하다. (SpaceONE API)

예를 들어 Identity 의 인증 용 Auth Plugin 을 개발한다고 가정해보자. 이때, Auth Plugin 의 Interface 정보를 확인해 보면 아래와 같다. (SpaceONE API - Identity Auth)





Identity 의 Auth Plugin 개발을 위해서는 총 4개의 API interface 를 구현해야 한다.
이 중, init 과 verify 는 모든 Plugin 이 동일하게 필요로 하는 inteface 이며,
나머지는 각각의 Plugin 마다 특성에 따라 다르다.

이 중에서 공통으로 구현이 필요한 init 과 verify 를 자세히 살펴본다.

1. init

Plugin 초기화.
Identity 의 경우 Domain 을 생성 할 때, 어떤 인증을 사용할지를 결정해야 하며 관련된 Auth Plugin 을 배포하게 된다.
최초 Plugin 배포시 (또는 Plugin 버전 업데이트시) Plugin 컨테이너가 생성 완료된 후 Core 서비스는 Plugin 에 init API 를 호출하게 된다.
이때, Plugin 은 Core 서비스가 Plugin 과 통신시 필요로 하는 metadata 정보를 반환하게 된다.
metadata 에 대한 정보는 Core 서비스 별로 다르다.

아래는 Google oAuth2 plugin 의 init 구현에 대한 python 코드의 예시이다.
return 값으로 metadata 를 반환하는데, 이때 identity 에서 필요한 다양한 정보를 추가하여 반환한다.

    @transaction
    @check_required(['options'])
    def init(self, params):
        """ verify options
        Args:
            params
              - options
        Returns:
            - metadata
        Raises:
            ERROR_NOT_FOUND:
        """
        
        manager = self.locator.get_manager('AuthManager')
        options = params['options']
        options['auth_type'] = 'keycloak'
        endpoints = manager.get_endpoint(options)
        capability= endpoints
        return {'metadata': capability}

2. verify

Plugin 정상 동작 확인. Plugin 이 배포된 후, init API 호출 이후에는 plugin 이 동작 실행 준비가 완료되었는지 확인 절차를 거치는데 이때 호출되는 API 가 verify 이다.
verify 단계에는 Plugin 이 정상적인 동작 수행 준비가 되었는지 확인하는 절차를 확인한다.

아래는 Google oAuth2 plugin 의 verify 구현에 대한 python 코드의 예시이다.
verify 행위는 Google oAuth2 동작시 필요한 값을 통해 실제 logic 이 수행하기 위한 준비단계가 정상 동작하기 위한 검증 수준의 코드를 필요로 한다.

    def verify(self, options):
        # This is connection check for Google Authorization Server
        # URL: https://www.googleapis.com/oauth2/v4/token
        # After connection without param.
        # It should return 404
        r = requests.get(self.auth_server)
        if r.status_code == 404:
            return "ACTIVE"
        else:
            raise ERROR_NOT_FOUND(key='auth_server', value=self.auth_server)

5.2.1.2 - Plugin Register

Plugin 개발이 완료되었다면, Plugin 배포를 준비해야 한다. SpaceONE 의 모든 Plugin 은 Container 로 배포되기 때문에, 개발이 완료된 Plugin 코드는 Container 배포를 위한 Image 로 빌드해야 한다. Container 빌드는 Dockerfile 을 활용해 docker build 를 수행 한 후, 결과물인 Image 는 Docker hub 와 같은 이미지 저장소에 업로드하도록 한다. 이때, 이미지 저장소는 SpaceONE 의 Microservice 인 Repository 서비스에서 관리하는 저장소에 업로드하도록 한다.


![](/ko/docs/developers/plugins/developer_guide/developer_guide_img/plugin_container_build.png)
이미지를 저장소에 업로드 하였다면, Microservice 중 Repository 서비스에 해당 이미지를 등록해야 한다. 등록 API 는 Repository.plugin.register 를 사용하도록 한다. ([SpaceONE API - (Repository) Plugin.Register](https://spaceone-dev.gitbook.io/spaceone-apis/repository/v1/plugin#register))

아래 예제는 Notification 의 Protocol Plugin 등록시 전달된 Parameter 내용이다. image 값에는 이전에 빌드된 이미지 주소를 넣어준다.

name: Slack Notification Protocol
service_type: notification.Protocol
image: pyengine/plugin-slack-notification-protocol_settings
capability:
  supported_schema:
  - slack_webhook
  data_type: SECRET
tags:
  description: Slack
  "spaceone:plugin_name": Slack
  icon: 'https://spaceone-custom-assets.s3.ap-northeast-2.amazonaws.com/console-assets/icons/slack.svg'
provider: slack
template: {}

이미지 등록의 경우, 아직 Web Console 에서 지원되지 않기 때문에 직접 gRPC API 를 사용하거나 spacectl 을 사용하도록 한다. 위와 같은 yaml 형태의 파일을 생성 후, 아래와 같이 spacectl 명령어로 이미지 등록이 가능하다.

> spacectl exec register repository.Plugin -f plugin_slack_notification_protocol.yml

이미지가 Repository 에 등록 완료되면 아래와 같이 확인 가능하다.

> spacectl list repository.Plugin -p repository_id=<REPOSITORY_ID>  -c plugin_id,name
plugin_id                              | name
----------------------------------------+------------------------------------------
 plugin-aws-sns-monitoring-webhook      | AWS SNS Webhook
 plugin-amorepacific-monitoring-webhook | Amore Pacific Webhook
 plugin-email-notification-protocol_settings     | Email Notification Protocol
 plugin-grafana-monitoring-webhook      | Grafana Webhook
 plugin-keycloak-oidc                   | Keycloak OIDC Auth Plugin
 plugin-sms-notification-protocol_settings       | SMS Notification Protocol
 plugin-voicecall-notification-protocol_settings | Voicecall Notification Protocol
 plugin-slack-notification-protocol_settings     | Slack Notification Protocol
 plugin-telegram-notification-protocol_settings  | Telegram Notification Protocol

 Count: 9 / 9

spacectl 의 자세한 사용 방법은 해당 페이지에서 확인 가능하다. Spacectl CLI Tool

5.2.1.3 - Plugin Deployment

등록된 Plugin 을 실제로 배포해서 사용하려면, Plugin 이미지를 바탕으로 Kubernetes 환경에 Pod 를 배포해야 한다.
이때, Plugin 배포는 해당 plugin 을 사용하고자 하는 서비스에서 자동으로 수행하게 된다.

예를 들어, Notification 의 경우 발생된 Alert 을 사용자에게 전달하기 위해 Protocol 이라는 객체를 사용하여 전달하게 되는데
이때, Notification 의 Protocol.create (Protocol.create) 명령을 수행시, Notification 이 자동으로 Plugin 을 배포하게 된다.

아래 예제는 Notification 에 Slack 으로 알람을 전송하기 위한 Slack Protocol 생성에 대한 Protocol.create 명령 파라미터 예시이다.

---
name: Slack Protocol
plugin_info:
  plugin_id: plugin-slack-notification-protocol_settings
  version: "1.0"
  options: {}
  schema: slack_webhook
tags:
  description: Slack Protocol

plugin_id 에는 Repository 에 등록한 plugin 의 ID 값을 넣고,
version 에는 Dockerhub 와 같은 이미지 저장소에 실제 이미지 업로드시 기입했던 이미지 tag 정보를 넣어준다.
만약 이미지 저장소에 여러 tag 를 가진 경우, 지정된 tag version 의 이미지로 plugin 배포를 수행한다.

위의 경우, version 을 "1.0" 으로 지정하였기 때문에 아래 tag 정보 중 "1.0" tag 이미지로 배포되기 된다.



해당 API 의 경우, Kubernetes 환경에 Service 와 Pod 를 생성해 배포하는 단계를 거치기 때문에 응답까지 약간의 시간이 걸린다.
실제 Kubernetes 환경에서 Pod 배포를 확인해 보면 아래와 같이 확인 가능하다.

> k get po
NAME                                                              READY   STATUS    RESTARTS   AGE
plugin-slack-notification-protocol_settings-zljrhvigwujiqfmn-bf6kgtqz   1/1     Running   0          1m

5.3 - Design System

클라우드포레 프로젝트의 디지털 경험을 통합하기 위한 오픈 소스 디자인 시스템입니다.

Overview

점점 더 많은 제품들이 더 나은 사용자 경험을 추구하기 시작했습니다. 이러한 상황에서 우리는 아래의 원칙을 기반으로 디자인 시스템을 구축했습니다.

디자인 시스템은 프로덕트 제작에 참여하는 모두가 디자인 문제를 더 빠르고 효율적으로 해결할 수 있도록 돕습니다. 또한 우리의 디자인 시스템은 여러 작업자가 모두 하나의 목소리로 이야기할 수 있도록 돕는 Single source of truth이며, 같은 방식으로 논의할 수 있도록 협의한 문법을 제공합니다.

Principle

사용자 중심

우리의 디자인은 제품의 최접점에서 고객과 커뮤니케이션 하는 언어로 사용자를 우선으로 합니다. 프로덕트를 개발하는 방식에서 포괄성, 접근성, 투명성을 중요하게 생각하며 개방적이고 접근하기 쉬운 디자인을 위해 노력합니다.

명확한 시각화

사용자는 멀티 클라우드의 복잡성 안에서 다양한 과업을 수행합니다. 어려운 문제를 간소화하고 복잡한것을 명확하게 표현해 사용자가 고민하지 않고 서비스를 사용할 수 있도록 도와주는것이 기본 원칙입니다. 필요할 때 필요한 것을 제공하는 디자인과 메시지로 고객의 목표 달성을 돕기 위해 노력합니다.

완벽 너머 지속성

언어는 상황과 환경을 반영해 계속해서 발전합니다. 우리의 디자인 시스템도 최선을 목표로 끊임없이 사용성을 검증 해 나가며 완벽 너머의 지속하는 힘을 지향합니다.

디자인 시스템의 발전에 기여하고 싶다면 아래의 리소스를 확인해주세요.

Resources

GitHub

디자인 시스템 저장소

Storybook

컴포넌트 라이브러리

Figma

공개 준비중

5.3.1 - 시작하기

이 페이지는 SpaceOne Design System 개발을 시작하기 위한 안내문서입니다.

개발 환경 세팅

Fork

현재 스페이스원의 콘솔은 오픈소스로 운영중에 있습니다.

개발에 기여하기위해 먼저 Design System 레포지토리를 개인 github 계정에 포크해 줍니다.

Clone

이후 포크해온 레포지토리를 로컬로 클론해 줍니다.

서브모듈로 assets과 번역 관련 레포지토리가 사용중이기 때문에 함께 초기화합니다.

git clone --recurse-submodules https://github.com/[github username]/spaceone-design-system

cd console

Run Storybook

콘솔을 실행 실행시키기 위해 npm으로 의존성을 설치하고, 스크립트를 실행해 줍니다.

npm install --no-save

npm run storybook

Build

배포 가능한 zip을 생성하려면 아래의 스크립트를 실행하시면 됩니다.

npm run build

스토리북


SpaceOne Design system은 Storybook을 제공하고 있습니다.

컴포넌트를 생성하면 해당 컴포넌트의 기능 정의를 Storybook을 통해 문서화합니다.

기본적으로 한 컴포넌트가 아래와 같은 구조로 구성되어 있습니다.

- component-name
    - [component-name].stories.mdx
    - [component-name].vue
    - story-helper.ts
    - type.ts

[component-name].stories.mdx 와 story-helper.ts

컴포넌트의 설명, 사용예시, Playground를 제공합니다.

mdx 포멧을 사용중이며 사용방법은 문서를 참고하십시오.

playground에 명시되는 props, slots, events와 같은 속성들은 가독성을 위해 story-helper를 통해 분리하여 작성하는 방식을 지향합니다.

차트 라이선스


SpaceONE 디자인 시스템은 내부적으로 amCharts for Dynamic Chart를 사용합니다.

디자인 시스템을 사용하기 전에 amCharts의 라이선스를 확인해주십시오.

자신에게 적합한 amCharts 라이선스를 구입하여 애플리케이션에서 사용하려면 라이선스 FAQ를 참조하십시오.

스타일


스타일 정의에 있어 SpaceOne Console은 tailwind css와 postcss를 사용중에 있습니다.

SpaceOne의 color palette에 따라 tailwind 커스텀을 통해 적용되어 있습니다. (세부 정보는 storybook을 참고해주세요)

5.4 - Contribute

SpaceONE Project Contribution Guide

5.4.1 - Content 가이드

이 페이지는 Content Guide 작성 방법을 설명합니다.

새로운 페이지 생성

페이지 생성 위치의 상위 페이지로 이동 합니다. 오른쪽 하단의 '하부 페이지 생성' 버튼을 클릭합니다.

또는:
The docs repository 에서 fork 한 후 페이지를 생성합니다.

제목 및 파일 이름 작성

제목에서 밑줄(_)로 구분된 단어를 사용하여 파일 이름을 생성합니다. 예를 들어, 제목이 Project Management인 파일 이름은 project_management.md입니다.

Front matter에 필드 추가

Front matter에 필드를 추가합니다. Front matter은 페이지 상단의 삼중 파선 사이에 있는 YAML 블록 영역입니다. 다음은 예입니다.

---
title: "Project Management"
linkTitle: "Project Management"
weight: 10
date: 2021-06-10
description: >
  View overall status of each project and Navigate to detailed cloud resources.  
---

Front matter 변수 설명

변수설명
title컨텐츠 제목
linkTitle왼쪽 사이드바 메뉴에 노출
weight왼쪽 사이드바 메뉴의 순서를 정렬하는데 사용되는 변수. 더 낮은 weight 일수록 우선순위가 높음. 즉, 낮은 weight 일수록 컨텐츠가 먼저 노출. weight가 0 이면, 설정되지 않은 값으로 해석하기 때문에 0이 아니어야 함.
date생성날짜
description페이지 설명

Front matter에 관한 더 자세한 사항은 Front matter 을 방문해 알 수 있습니다.

Document 작성

Table of Contents추가

Document에 ##을 추가 하면, Table of Contents 리스트에 자동적으로 추가됩니다.

이미지 추가

작성하는 document와 동일한 계층에 파일명_img 이름의 폴더를 생성합니다. 예를 들면, project_management.md에 사용되는 이미지를 위한 project_management_img 디렉토리를 생성합니다. 디렉토리에 이미지를 추가하여 사용합니다.

Style guide

Style guide를 참고해서 document를 작성해주세요.

Pull request 요청

새로운 branch에 커밋을 하고, pull request 요청합니다.

5.4.2 - Style 가이드 (shortcodes)

이 페이지에서는 SpaceONE Markdown에서 사용할 수 있는 사용자 지정 Hugo shortcodes를 중점으로 설명합니다.

Heading 태그

##, <h2>부터 순차적으로 사용하는 것을 권장합니다. 시맨틱 마크업뿐만 아니라 스타일을 위한 것입니다.

코드 :

{{< link-button background-color="navy400" url="/" text="Home" >}}
{{< link-button background-color="white" url="https://cloudforet.io/" text="cloudforet.io" >}}

결과 :
Home cloudforet.io

Video

코드 :

{{< video src="https://www.youtube.com/embed/zSoEg2v_JrE" title="SpaceONE Setup" >}}

결과:

Alert

코드 :

{{< alert title="Note Title" >}}
	Note Contents
{{< /alert >}}

결과:

Reference