8.8. 기능과 관련된 백엔드 사용자 정의 리소스
새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 백엔드, 해당 지표, 방법 및 매핑 규칙을 구성합니다. 백엔드 사용자 지정 리소스의 상태와 백엔드가 테넌트 계정에 연결하는 방법도 알아봅니다.
사전 요구 사항
일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항은 다음과 같습니다.
- 3scale 계정의 최소 필수 매개변수는 관리 포털 URL 주소와 액세스 토큰입니다.
8.8.1. 기능과 관련된 백엔드 사용자 정의 리소스 배포
새로 생성된 테넌트에서 Openshift Container Platform을 사용하면 새 백엔드를 구성합니다.
절차
- OpenShift 계정에서 Installed operators 로 이동합니다.
- 3scale Operator를 클릭합니다.
- 3scale 백엔드에서 인스턴스 생성을 클릭합니다.
- YAML 보기를 선택합니다.
특정 3scale 관리 URL 주소를 가리키는 3scale 백엔드를 생성합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: <your_backend_OpenShift_name> spec: name: "<your_backend_name>" privateBaseURL: "<your_admin_portal_URL>"
예를 들어 다음과 같습니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com"
- 변경 사항을 저장하려면 만들기를 클릭합니다.
3scale 계정에서 백엔드가 OpenShift에서 생성되도록 몇 초 동안 기다립니다. 그런 다음 다음 확인을 수행할 수 있습니다.
-
동기화된 조건이
True
로 표시되어 3scale 백엔드 개요 페이지를 확인하여 OpenShift에서 백엔드 가 생성되었는지 확인합니다. -
3scale 계정으로 이동하여 백엔드가 생성되었는지 확인합니다. 위의 예에서는
My Backend Name
이라는 새 백엔드가 표시됩니다.
-
동기화된 조건이
8.8.2. 백엔드 지표 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 백엔드 사용자 정의 리소스에서 원하는 백엔드 지표를 정의합니다.
이러한 관찰을 고려하십시오.
-
메트릭
맵 키 이름은system_name
으로 사용됩니다. 아래 예에서metric01
,metric02
가 에도달합니다
. -
지표
맵 키 이름은 모든 메트릭 및 방법 간에 고유해야 합니다. -
단위
및friendlyName
은 필수 필드입니다. -
hits
지표를 추가하지 않으면 Operator가 이 지표를 생성합니다.
절차
다음 예와 같이 새 3scale 백엔드에 백엔드 지표를 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" metrics: metric01: friendlyName: Metric01 unit: "1" metric02: friendlyName: Metric02 unit: "1" hits: description: Number of API hits friendlyName: Hits unit: "hit
8.8.3. 백엔드 메서드 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 백엔드 사용자 정의 리소스에서 원하는 백엔드 방법을 정의합니다.
이러한 관찰을 고려하십시오.
-
방법
맵 키 이름은system_name
으로 사용됩니다. 아래 예제에서는Method01
및Method02
. -
맵 키 이름은 모든 메트릭 및 방법 간에 고유해야 합니다.
-
FriendlyName
은 필수 필드입니다.
절차
다음 예와 같이 새 3scale 백엔드에 백엔드 메서드를 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" methods: method01: friendlyName: Method01 method02: friendlyName: Method02
8.8.4. 백엔드 매핑 규칙 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 백엔드 사용자 정의 리소스에서 원하는 백엔드 매핑 규칙을 정의합니다.
이러한 관찰을 고려하십시오.
-
httpMethod
,패턴
,increment
및metricMethodRef
는 필수 필드입니다. -
metricMethodRef
에는 기존 지표 또는 메서드 맵 키 이름system_name
에 대한 참조가 있습니다. 아래 예제에서 를누릅니다
.
절차
다음 예와 같이 새 3scale 백엔드에 백엔드 매핑 규칙을 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" mappingRules: - httpMethod: GET pattern: "/pets" increment: 1 metricMethodRef: hits - httpMethod: GET pattern: "/pets/id" increment: 1 metricMethodRef: hits metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit"
8.8.5. 백엔드 사용자 정의 리소스의 상태
status 필드는 최종 사용자에게 유용한 리소스 정보를 표시합니다. 수동으로 업데이트할 수 없으며 리소스의 모든 변경 사항에 동기화됩니다.
다음은 status 필드의 속성입니다.
-
backendId
: 3scale 백엔드의 내부 식별자입니다. conditions
:status.Conditions
Kubernetes 일반적인 패턴을 나타냅니다. 이러한 유형 또는 상태:-
invalid:
BackendSpec
의 구성 조합이 지원되지 않습니다. 이는 일시적인 오류가 아니지만 진행하기 전에 해결해야 하는 상태를 나타냅니다. - synced: 백엔드가 성공적으로 동기화되었습니다.
- 실패: 동기화 중 오류가 발생했습니다.
-
invalid:
-
observedGeneration
: 상태 정보가 최신 리소스 사양으로 업데이트되었는지 확인하는 도우미 필드입니다.
동기화된 리소스의 예:
status: backendId: 59978 conditions: - lastTransitionTime: "2020-06-22T10:50:33Z" status: "False" type: Failed - lastTransitionTime: "2020-06-22T10:50:33Z" status: "False" type: Invalid - lastTransitionTime: "2020-06-22T10:50:33Z" status: "True" type: Synced observedGeneration: 2
8.8.6. 테넌트 계정에 연결된 백엔드 사용자 정의 리소스
3scale Operator가 새 3scale 리소스를 찾으면 LookupProviderAccount 프로세스는 리소스를 소유한 테넌트를 식별하는 것으로 시작됩니다.
프로세스는 테넌트 자격 증명 소스를 확인합니다. 찾을 수 없는 경우 오류가 발생합니다.
다음 단계에서는 프로세스에서 테넌트 인증 정보 소스를 확인하는 방법을 설명합니다.
providerAccountRef 리소스 특성에서 자격 증명을 확인합니다. 이는 시크릿 로컬 참조입니다. 예를 들어 mytenant:
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" providerAccountRef: name: mytenant
mytenant 시크릿에는 테넌트 자격 증명으로 채워진 adminURL 및 토큰 필드가 있어야 합니다. 예를 들어 다음과 같습니다.
apiVersion: v1 kind: Secret metadata: name: mytenant type: Opaque stringData: adminURL: https://my3scale-admin.example.com:443 token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
기본 threescale-provider-account 시크릿을 확인합니다. 예:
adminURL=https://3scale-admin.example.com
및token=123456
:oc create secret generic threescale-provider-account --from-literal=adminURL=https://3scale-admin.example.com --from-literal=token=123456
- 3scale 배포의 동일한 네임스페이스에서 기본 공급자 계정을 확인합니다. 3scale 설치가 사용자 정의 리소스와 동일한 네임스페이스에 있는 경우 Operator는 기본 3scale 테넌트(공급 테넌트)에 필요한 인증 정보를 자동으로 수집합니다.
8.8.7. 백엔드 사용자 정의 리소스 삭제
이를 관리하는 백엔드 CR(사용자 정의 리소스)을 삭제
하여 백엔드 엔터티를 삭제할 수 있습니다. 백엔드
CR을 삭제하면 3scale Operator가 삭제된 백엔드를 참조하는 제품
CR을 업데이트합니다. 업데이트는 다음 속성에 있습니다.
-
backendUsages
-
applicationPlans
이러한 속성은 더 이상 삭제된 백엔드를 참조하지 않습니다.
백엔드 CR에 정의된 API 백엔드를 삭제하는 유일한 방법은 여기에 설명된 절차를 따르는 것입니다. 관리 포털이나 3scale API를 사용하여 사용자 정의 리소스로 배포된 백엔드를 삭제하지 마십시오.
사전 요구 사항
3scale 관리자 권한 또는 삭제하려는
백엔드
CR이 포함된 네임스페이스에서 삭제 권한이 있는 OpenShift 역할. 특정백엔드
사용자 정의 리소스를 삭제할 수 있는 사용자를 확인하려면oc policy who-can delete
명령을 실행합니다. 예를 들어 CR의 이름이mybackend
이면 다음 명령을 실행합니다.oc policy who-can delete product.capabilities.3scale.net/mybackend
-
백엔드
CR을 사용하여 유효한 테넌트에 대한 링크를 삭제합니다.
절차
oc delete
명령을 실행하여백엔드 사용자 정의 리소스
를 삭제합니다. 예를 들어mybackend.yaml
파일에 정의된 백엔드를 배포한 경우 다음 명령을 실행합니다.oc delete -f mybackend.yaml
또는
oc delete
명령을 실행하고 정의에 지정된 대로 백엔드의 이름을 지정할 수 있습니다. 예를 들어 다음과 같습니다.oc delete backend.capabilities.3scale.net/mybackend