테넌트에 추가 VMware Cloud Director 기능을 제공하는 확장을 만들기 위해 서비스 제공자는 VMware Cloud Director API를 사용할 수 있습니다.
정의된 엔티티는 VMware Cloud Director가 관리할 수 있는 외부 리소스를 나타냅니다. 확장 및 UI 플러그인 개발자는 런타임 정의 엔티티를 만들고 확장 및 UI 플러그인을 사용하도록 설정하여 VMware Cloud Director에서 확장 관련 정보를 저장하고 조작할 수 있습니다. 확장을 만들고 외부 리소스에 대한 상태 또는 참조를 저장해야 하는 경우 확장은 로컬 데이터베이스 대신 런타임 정의 엔티티를 사용할 수 있습니다. 예를 들어 Kubernetes 확장은 런타임 정의 엔티티에서 해당 확장이 관리하는 Kubernetes 클러스터에 대한 정보를 저장할 수 있습니다. 그런 다음 확장은 런타임 정의 엔티티의 정보를 사용하여 이러한 클러스터를 관리하기 위한 확장 API를 제공할 수 있습니다.
런타임 정의 엔티티는 VMware Cloud Director API를 통해서만 액세스할 수 있습니다. 관리자 권한이 있는 사용자는 확장에서 만드는 정의된 엔티티의 상태를 확인하여 확장이 작동하는 방식을 추적하고 관찰할 수 있습니다. 정의된 엔티티의 상태는 확장 관련 문제를 해결하는 데 도움이 될 수도 있습니다.
정의된 엔티티 유형
런타임 시 정의된 엔티티를 사용하여 저장할 수 있는 정보의 스키마를 정의합니다. 스키마는 JSON 문서를 통해 엔티티 유형에 정의됩니다. 정의된 엔티티 유형을 만들 때 확장과 동작으로 관리할 수 있는 VM 및 vApp과 유사한 새로운 사용자 지정 VMware Cloud Director 유형을 만듭니다. 예를 들어 엔티티 유형 NativeContainerCluster를 고려하는 경우 이 유형의 각 인스턴스에는 특정 Kubernetes 클러스터에 대한 정보가 포함됩니다. 클러스터에 대한 정보를 가져오기 위해 VMware Cloud Director Container Service Extension은 VMware Cloud Director API를 통해 VMware Cloud Director와 통신하고 사용자에게 필요한 정보를 제공합니다.
정의된 엔티티 유형의 인스턴스를 만든 후에는 유형, 스키마 및 동작을 더 이상 변경할 수 없습니다. 엔티티 유형에 새 기능을 추가하려면 새 버전의 유형을 만들어야 합니다. 정의된 엔티티 인스턴스가 이전 버전의 엔티티 유형을 기반으로 하는 경우 엔티티의 유형 속성을 새 유형의 ID로 설정하여 최신 버전의 유형을 사용하도록 정의된 엔티티를 업그레이드할 수 있습니다. 정의된 엔티티를 만들 때 API 호출에서 엔티티 속성의 컨텐츠가 엔티티 유형에 지정된 JSON 스키마와 일치해야 합니다. 엔티티 유형에 대한 액세스 권한은 특정 사용자 및 조직에만 부여할 수 있습니다. 서로 다른 버전의 엔티티 유형에 대해 서로 다른 액세스 제한을 설정할 수 있습니다.
엔티티 유형의 스키마는 여러 컨텐츠 필드에 대한 액세스를 지정할 수 있습니다. 속성을 public, protected 또는 private으로 표시할 수 있습니다.
| 속성 상태 | 액세스 제어 |
|---|---|
| Public | 모든 사용자는 필드를 보고 수정할 수 있습니다. |
| Protected | 모든 사용자는 필드를 볼 수 있습니다. 모든 권한을 가진 사용자만 필드를 만들고 수정할 수 있습니다. 사용자에게 관리자 모든 권한: TYPE 권한이 있거나 모든 권한: TYPE 권한 및 모든 권한 ACL이 둘 다 있어야 합니다. |
| Private | 모든 권한을 가진 사용자만 필드를 보고 만들고 수정할 수 있습니다. 사용자에게 관리자 모든 권한: TYPE 권한이 있거나 모든 권한: TYPE 권한 및 모든 권한 ACL이 둘 다 있어야 합니다. |
clusterState에 대한 JSON 스키마는 다음과 같을 수 있습니다.
"clusterState" : {
"type" : "string",
"x-vcloud-restricted" : "protected"
}
인터페이스 및 동작
정의된 엔티티에는 동작을 정의하는 데 사용할 수 있는 인터페이스도 있습니다. Kubernetes 예제를 사용하는 경우 각 클러스터 엔티티 유형은 컨테이너 클러스터 인터페이스에 정의된 동작의 구현이 다릅니다. Tanzu Kubernetes 클러스터 유형 동작은 vSphere와 통신하여 필요한 작업을 수행하고 네이티브 컨테이너 클러스터 유형 동작은 VMware Cloud Director Container Service Extension과 통신합니다.
모든 사용자는 정의된 엔티티의 인터페이스를 볼 수 있습니다.
동작을 정의하는 방법에는 여러 가지가 있습니다.
- VMware Aria Automation Orchestrator 워크플로를 만들어 게시하고 워크플로를 호출하는 동작을 만들 수 있습니다.
- WebHook을 사용하여 모든 기능을 동작에 연결할 수 있습니다.
- MQTT 동작을 사용하면 확장에서 기능을 호출할 수 있습니다. MQTT를 사용하면 확장과 직접 통신할 수 있으며 확장에서 더 자세한 상태를 제공할 수 있습니다.
- 인터페이스 API ID는
urn:vcloud:interface:vendor_name:interface_name:version형식입니다. - 유형 API ID는
urn:vcloud:type:vendor_name:type_name:version형식입니다. - 동작 API ID는
urn:vcloud:behavior-interface:behavior_name:vendor_name:interface_name:version또는urn:vcloud:behavior-type:behavior_name:vendor_name:interface_name:version형식입니다.
런타임 정의 엔티티 만들기
정의된 엔티티를 만들려면 우선 외부 리소스를 구성하고 필요한 정보를 정의된 엔티티에 추가합니다. 이 프로세스에는 몇 번의 반복이 필요할 수 있습니다. 정의된 엔티티를 확인하려면 스키마의 컨텐츠에 필요한 모든 정보가 있는지 확인해야 합니다. 컨텐츠가 유형에 지정된 JSON 스키마와 일치하지 않으면 정의된 엔티티 상태가 Resolution_Error로 변경됩니다. 정보를 올바르게 입력하면 정의된 엔티티 상태가 Resolved로 변경되고 사용할 준비가 됩니다.
작업은 모든 장기 실행 런타임 정의 엔티티 작업을 추적하기 때문에 VMware Cloud Director UI를 사용하여 정의된 엔티티의 생성, 동작 호출 등을 모니터링할 수 있습니다. 정의된 엔티티의 상태가 Resolved로 변경되면 UI에서 해당 작업이 Succeeded로 표시됩니다.
한 테넌트 조직에서 정의된 엔티티를 만드는 경우 이 정의된 엔티티를 다른 조직의 테넌트와 공유할 수 없습니다. System 조직에서 정의된 엔티티를 만드는 경우 테넌트 사용자 또는 테넌트 조직과 공유할 수 있습니다.
정의된 엔티티를 만들기 위한 샘플 API 호출
이 예는 pksContainerCluster 유형의 새 엔티티를 만들기 위한 샘플 API 호출을 제공합니다.
POST https://host/cloudapi/1.0.0/entityTypes/urn:vcloud:type:vendorA:pksContainerCluster:1.0.0
{
"name": "testEntity",
"entity": {
"cluster": {
"name": "testCluster",
"nodes": ["node1"]
}
}
}
정의된 엔티티 인스턴스에 대한 액세스
두 가지 보조 메커니즘이 런타임 정의 엔티티에 대한 액세스를 제어합니다.
-
권한 - 런타임 정의 엔티티 유형을 만들 때 해당 유형에 대한 권한 번들을 만듭니다. 특정 작업에 대한 액세스를 제공하려면 이 번들의 권한을 다른 역할에 할당해야 합니다. 각 번들에는 다음과 같은 5가지의 유형별 권한이 있습니다. 보기: TYPE, 편집: TYPE, 모든 권한: TYPE, 관리자 보기: TYPE 및 관리자 모든 권한: TYPE.
보기: TYPE, 편집: TYPE 및 모든 권한: TYPE 권한은 ACL 항목과 함께만 작동합니다.
-
ACL(Access Control List) - ACL 테이블에는 시스템의 특정 엔티티에 대한 사용자 액세스를 정의하는 항목이 포함됩니다. 이는 엔티티에 대한 추가 제어 수준을 제공합니다. 예를 들어 편집: TYPE 권한은 사용자가 액세스 권한이 있는 엔티티를 수정할 수 있도록 지정합니다. ACL 테이블은 사용자가 액세스할 수 있는 엔티티를 정의합니다.
일반 ACL 보기 권한이 있는 시스템 관리자는
accessControlsAPI를 사용하여 정의된 특정 엔티티에 할당된 ACL을 볼 수 있습니다. VMware Cloud Director OpenAPI를 참조하십시오.일반 ACL 관리 권한이 있는 시스템 관리자는
accessControlsAPI를 사용하여 특정 ACL을 만들고, 수정하고, 제거할 수 있습니다.
| 엔티티 작업 | 옵션 | 설명 | |
|---|---|---|---|
| 읽기 | 관리자 보기: TYPE 권한 | 이 권한을 가진 사용자는 조직 내에서 이 유형의 모든 런타임 정의 엔티티를 볼 수 있습니다. | |
| 보기: TYPE 권한 및 ACL 항목 >= 보기 | 이 권한 및 읽기 수준 ACL이 있는 사용자는 이 유형의 런타임 정의 엔티티를 볼 수 있습니다. | ||
| 수정 | 관리자 모든 권한: TYPE 권한 | 이 권한을 가진 사용자는 모든 조직에서 이 유형의 런타임 정의 엔티티를 만들고, 보고, 수정하고, 삭제할 수 있습니다. | |
| 편집: TYPE 권한 및 ACL 항목 >= 변경 | 이 권한 및 수정 수준 ACL이 있는 사용자는 이 유형의 런타임 정의 엔티티를 만들고, 보고, 수정할 수 있습니다. | ||
| 삭제 | 관리자 모든 권한: TYPE 권한 | 이 권한을 가진 사용자는 모든 조직에서 이 유형의 런타임 정의 엔티티를 만들고, 보고, 수정하고, 삭제할 수 있습니다. | |
| 모든 권한: TYPE 권한 및 ACL 항목 = 모든 권한 | 이 권한 및 모든 권한 수준 ACL이 있는 사용자는 이 유형의 런타임 정의 엔티티를 만들고, 보고, 수정하고, 삭제할 수 있습니다. | ||
VMware Cloud Director API 또는 UI를 사용하여 이 유형의 엔티티를 관리하려는 조직에 권한 번들을 게시할 수 있습니다. 권한 번들을 게시한 후에는 번들의 권한을 조직 내의 역할에 할당할 수 있습니다.
VMware Cloud Director API를 사용하여 ACL 테이블을 편집할 수 있습니다.
정의된 엔티티 인터페이스 및 유형 작업에 대한 액세스
정의된 엔티티 인터페이스 및 유형 작업에는 특정 서비스 제공자가 가질 수 없는 특정 권한이 필요합니다. 작업을 수행하기 전에 필요한 권한이 있는지 확인합니다.
| 작업 | 요구 사항 |
|---|---|
| 인터페이스 보기 및 쿼리 | 모든 사용자에게 필요한 권한이 있습니다. |
| 인터페이스 생성 | 새 사용자 지정 엔티티 정의 만들기 권한이 있어야 합니다. |
| 인터페이스 편집 | 사용자 지정 엔티티 정의 편집 권한이 있어야 합니다. |
| 인터페이스 삭제 | 사용자 지정 엔티티 정의 삭제 권한이 있어야 합니다. |
| 유형 생성 | 새 사용자 지정 엔티티 정의 만들기 권한이 있어야 합니다. |
| 보기 유형 | 최소 요구 사항은 ReadOnly Type ACL입니다. |
| 유형 편집 및 삭제 | 사용자 지정 엔티티 정의 편집/삭제 권한 및 FullControl Type ACL이 있어야 합니다. |
런타임 정의 엔티티 사용
정의된 엔티티에서 동작을 호출하려면 Resolved 상태여야 합니다. 정의된 엔티티를 삭제하려면 Resolved 또는 Resolution_Error 상태여야 합니다.
엔티티 유형 및 인터페이스는 인스턴스가 없는 경우에만 수정할 수 있습니다. 참조된 엔티티 유형은 해당 버전을 변경해야만 수정할 수 있습니다.
정의된 엔티티에 대한 액세스 문제를 진단하려면 엔티티 ACL 쿼리 API를 사용하고 필요한 권한을 확인할 수 있습니다. 또한 엔티티 유형의 권한 번들을 사용하려는 테넌트에 해당 번들을 게시해야 합니다.
