3scale 운영
배포를 자동화하고 환경을 확장하며 문제를 해결하는 방법
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서 참조하십시오.
1장. 3scale 일반 구성 옵션
Red Hat 3scale 관리자는 설치 또는 계정에서 설정을 조정할 수 있는 일반 구성 옵션이 있습니다.
1.1. 유효한 로그인 세션 길이 구성
Red Hat 3scale 관리자는 관리 포털과 개발자 포털에 모두 유효한 로그인 세션 길이를 구성할 수 있으므로 최대 타임아웃 및 비활성 상태에 대한 제한이 있습니다.
유효한 로그인 세션 길이를 구현하려면 USER_SESSION_TTL
을 초로 설정해야 합니다. 예를 들어 7,200초는 2시간입니다. 값이 null
인 경우 즉 설정되지 않거나 빈 문자열로 설정되어 있으면 세션 길이는 2주입니다.
사전 요구 사항
- 관리자 권한이 있는 3scale 계정입니다.
절차
환경 변수를 필요한 시간(초)으로 업데이트합니다.
$ oc set env dc/system-app --overwrite USER_SESSION_TTL=7200
2장. 3scale 작업 및 스케일링
이 문서는 노트북 또는 유사한 최종 사용자 장비상의 로컬 설치를 위한 것이 아닙니다.
이 섹션에서는 Red Hat 3scale 2saas 설치의 운영 및 확장 작업에 대해 설명합니다.
사전 요구 사항
- 지원되는 OpenShift 버전에 설치 및 초기에 3scale 인스턴스를 구성되어 있습니다.
3scale 작업 및 확장 작업을 수행하려면 다음 섹션에 설명된 단계를 수행합니다.
2.1. APIcast 재배포
3scale 관리 포털을 통해 시스템 변경 사항을 테스트하고 승격할 수 있습니다.
사전 요구 사항
- 3scale 온프레미스로 배포된 인스턴스.
- APIcast 배포 방법을 선택했습니다.
기본적으로 OpenShift에 포함된 APIcast 배포는 3scale 관리 포털을 통해 스테이징 및 프로덕션 게이트웨이에 변경 사항을 게시할 수 있도록 구성되어 있습니다.
OpenShift에서 APIcast를 재배포하려면 다음을 수행합니다.
절차
- 시스템을 변경합니다.
- 관리 포털에서 을 스테이징 및 테스트로 배포합니다.
- 관리 포털에서 프로덕션으로 승격합니다.
기본적으로 APIcast는 5분마다 승격된 업데이트를 검색하고 게시합니다.
Docker 컨테이너 환경 또는 기본 설치에서 APIcast를 사용하는 경우 스테이징 및 프로덕션 게이트웨이를 구성하고 게이트웨이가 게시된 변경 사항을 검색하는 빈도를 표시합니다. APIcast 게이트웨이를 구성한 후에는 3scale 관리 포털을 통해 APIcast를 재배포할 수 있습니다.
Docker 컨테이너 환경 또는 기본 설치에서 APIcast를 재배포하려면 다음을 수행합니다.
절차
- APIcast 게이트웨이를 구성하고 3scale 온프레미스에 연결합니다.
- 시스템을 변경합니다.
- 관리 포털에서 을 스테이징 및 테스트로 배포합니다.
- 관리 포털에서 프로덕션으로 승격합니다.
APIcast는 구성된 빈도에서 승격된 업데이트를 검색하고 게시합니다.
2.2. 3scale 온프레미스 확장
APIcast 배포가 증가함에 따라 사용 가능한 스토리지의 양을 늘려야 할 수 있습니다. 스토리지를 확장하는 방법은 영구 스토리지에 사용하는 파일 시스템 유형에 따라 다릅니다.
NFS(네트워크 파일 시스템)를 사용하는 경우 다음 명령을 사용하여 PV(영구 볼륨)를 확장할 수 있습니다.
oc edit pv <pv_name>
다른 스토리지 방법을 사용하는 경우 다음 섹션에 나열된 방법 중 하나를 사용하여 영구 볼륨을 수동으로 확장해야 합니다.
2.2.1. 방법 1: 영구 볼륨 백업 및 스왑
절차
- 기존 영구 볼륨에 데이터를 백업합니다.
- 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
-
사전 바인딩 영구 볼륨 클레임을 생성하고 다음을 지정합니다. volume
Name 필드를 사용하는 새 PVC(PersistentVolumeClaim)의 크기 및 영구 볼륨
이름입니다. - 백업의 데이터를 새로 생성된 PV로 복원합니다.
새 PV의 이름으로 배포 구성을 수정합니다.
oc edit dc/system-app
- 새 PV가 올바르게 구성되고 작동하는지 확인합니다.
- 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.
2.2.2. 방법 2: 3scale 백업 및 재배포
절차
- 기존 영구 볼륨에 데이터를 백업합니다.
- 3scale Pod를 종료합니다.
- 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
- 백업의 데이터를 새로 생성된 PV로 복원합니다.
사전 바인딩 영구 볼륨 클레임을 만듭니다. 다음을 지정합니다.
- 새 PVC의 크기
-
volume
Name 필드를 사용하는 영구 볼륨
이름입니다.
- your amp.yml 을 배포합니다.
- 새 PV가 올바르게 구성되고 작동하는지 확인합니다.
- 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.
2.2.3. 성능 확장
성능 확장은 총 포드 수를 통해 수행됩니다. 하드웨어 리소스가 많을수록 더 많은 Pod를 배포합니다.
다음 명령을 사용하여 Pod 수를 통해 성능을 확장합니다.
oc scale dc dc-name --replicas=X
2.2.4. 3scale 온프레미스 배포 구성
3scale을 위해 스케일링할 주요 배포 구성은 다음과 같습니다.
- APIcast 프로덕션
- 백엔드 리스너
- 백엔드 작업자
2.2.4.1. OCP 명령줄 인터페이스를 통한 스케일링
OCP(OpenShift Container Platform) CLI(명령줄 인터페이스)를 통해 배포 구성을 위로 또는 축소할 수 있습니다.
특정 배포 구성을 확장하려면 다음을 사용합니다.
다음 명령을 사용하여 APIcast 프로덕션 배포 구성을 확장합니다.
oc scale dc apicast-production --replicas=X
다음 명령을 사용하여 백엔드 리스너 배포 구성을 확장합니다.
oc scale dc backend-listener --replicas=Y
다음 명령을 사용하여 백엔드 작업자 배포 구성을 확장합니다.
oc scale dc backend-worker --replicas=Z
2.2.4.2. 수직 및 수평 하드웨어 확장
리소스를 추가하여 OpenShift에서 3scale 배포의 성능을 향상시킬 수 있습니다. 수평 확장으로 OpenShift 클러스터에 포드로 더 많은 컴퓨팅 노드를 추가하거나, 수직 확장으로 기존 계산 노드에 더 많은 리소스를 할당할 수 있습니다.
수평 스케일링
OpenShift에 포드로 더 많은 컴퓨팅 노드를 추가할 수 있습니다. 추가 계산 노드가 클러스터의 기존 노드와 일치하는 경우 환경 변수를 재구성할 필요가 없습니다.
수직 스케일링
기존 계산 노드에 더 많은 리소스를 할당할 수 있습니다. 더 많은 리소스를 할당하는 경우 성능을 높이기 위해 Pod에 프로세스를 추가해야 합니다.
3scale 배포에서 서로 다른 사양 및 구성으로 컴퓨팅 노드를 사용하지 마십시오.
2.2.4.3. 라우터 확장
트래픽이 증가하면 Red Hat OCP 라우터에서 요청을 적절히 처리할 수 있는지 확인합니다. 라우터가 요청 처리량을 제한하는 경우 라우터 노드를 확장해야 합니다.
2.3. 운영 문제 해결
이 섹션에서는 OpenShift에 표시되도록 3scale 감사 로깅을 구성하는 방법과 OpenShift에서 3scale 로그 및 작업 대기열에 액세스하는 방법을 설명합니다.
2.3.1. OpenShift에서 3scale 감사 로깅 구성
이를 통해 모든 로그가 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴에서 쿼리할 수 있습니다. 이러한 툴을 사용하면 3scale 구성의 변경 사항과 이러한 변경 사항을 언제 변경했는지 파악할 수 있습니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등의 변경 사항이 포함됩니다.
사전 요구 사항
- 3scale 2saas 배포.
절차
모든 애플리케이션 로그를 표준 OpenShift 포드 로그로 전달하도록 stdout
에 감사 로깅을 구성합니다.
몇 가지 고려 사항:
-
3scale이 온프레미스로 배포되면 기본적으로
stdout
에 대한 감사 로깅이 비활성화됩니다. 이 기능이 완전히 작동하도록 구성해야 합니다. -
stdout
에 대한 감사 로깅은 3scale 호스팅에서 사용할 수 없습니다.
2.3.2. 감사 로깅 활성화
3scale은 features.yml
구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout
에 감사 로깅을 활성화하려면 ConfigMap
에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.yml
에 종속되는 OpenShift 포드는 system-app
및 system-sidekiq
입니다.
사전 요구 사항
- OpenShift에서 클러스터 관리자 액세스 권한이 있어야 합니다.
절차
다음 명령을 입력하여 감사 로깅을
stdout
에 활성화합니다.oc patch configmap system -p '{"data": {"features.yml": "features: &default\n logging:\n audits_to_stdout: true\n\nproduction:\n <<: *default\n"}}'
다음 환경 변수를 내보냅니다.
export PATCH_SYSTEM_VOLUMES='{"spec":{"template":{"spec":{"volumes":[{"emptyDir":{"medium":"Memory"},"name":"system-tmp"},{"configMap":{"items":[{"key":"zync.yml","path":"zync.yml"},{"key":"rolling_updates.yml","path":"rolling_updates.yml"},{"key":"service_discovery.yml","path":"service_discovery.yml"},{"key":"features.yml","path":"features.yml"}],"name":"system"},"name":"system-config"}]}}}}'
업데이트된 배포 구성을 관련 OpenShift 포드에 적용하려면 다음 명령을 입력합니다.
oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES
2.3.3. EFK 로깅 구성
3scale 애플리케이션 로그를 OpenShift로 전달하기 위해 stdout
에 감사 로깅을 활성화한 경우 EFK 로깅 툴을 사용하여 3scale 애플리케이션을 모니터링할 수 있습니다.
OpenShift에서 EFK 로깅을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
2.3.4. 로그 액세스
각 구성 요소의 배포 구성에는 액세스 및 예외에 대한 로그가 포함되어 있습니다. 배포에 문제가 발생하면 해당 로그에서 자세한 내용을 확인하십시오.
3scale의 로그에 액세스하려면 다음 단계를 따르십시오.
절차
로그를 수행할 Pod의 ID를 찾습니다.
oc get pods
oc logs
및 선택한 Pod의 ID를 입력합니다.oc logs <pod>
시스템 포드에는 각각 별도의 로그가 있는 두 개의 컨테이너가 있습니다. 컨테이너의 로그에 액세스하려면
system-provider 및
Pod를 사용하여system-
developer--container
매개변수를 지정합니다.oc logs <pod> --container=system-provider oc logs <pod> --container=system-developer
2.3.5. 작업 대기열 확인
작업 대기열에는 system-sidekiq
포드에서 전송된 정보의 로그가 포함되어 있습니다. 이 로그를 사용하여 클러스터가 데이터를 처리 중인지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다.
oc get jobs
oc logs <job>
2.3.6. 단일 성장 방지
monotonic 증가를 방지하기 위해 기본적으로 3scale 일정으로 다음 테이블을 자동으로 삭제합니다.
- user_sessions - clean up은 매주 한 번 트리거되고 2주가 지난 레코드를 삭제합니다.
- audits - clean up은 하루에 한 번 트리거되며 3개월이 지난 레코드를 삭제합니다.
- log_entries - 하루에 한 번 트리거되는 정리는 6개월이 지난 레코드를 삭제합니다.
- event_store_events - clean up은 매주 한 번 트리거되고 1주일 이상 레코드가 삭제됩니다.
위에 나열된 테이블을 제외하고 다음 테이블에는 데이터베이스 관리자가 수동으로 삭제해야 합니다.
- 경고
표 2.1. SQL 제거 명령
데이터베이스 유형 | SQL 명령 |
---|---|
MySQL |
DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL 14 DAY; |
PostgreSQL |
DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL '14 day'; |
Oracle |
DELETE FROM alerts WHERE timestamp <= TRUNC(SYSDATE) - 14; |
이 섹션에 지정되지 않은 다른 테이블의 경우 데이터베이스 관리자는 시스템이 자동으로 삭제되지 않는 테이블을 수동으로 정리해야 합니다.
추가 리소스
- OCP(Openshift Container Platform)에 대한 자세한 내용은 OCP 문서를 참조하십시오.
- 포드 자동 스케일링.
- 계산 노드 추가.
- 라우팅 최적화.
3장. 모니터링 3scale
Prometheus 는 기록 데이터를 저장하고 확장 가능한 대규모 시스템을 모니터링하기 위해 빌드된 컨테이너 네이티브 소프트웨어입니다. 현재 실행 중인 세션이 아닌, 장기간에 걸쳐 데이터를 수집합니다. Prometheus의 경고 규칙은 Alertmanager에서 관리합니다.
Grafana 와 같은 그래픽 도구를 사용하여 데이터에서 쿼리를 시각화하고 실행할 수 있도록 Prometheus 및 Alertmanager를 사용하여 3scale 데이터를 모니터링하고 저장합니다.
Prometheus는 오픈 소스 시스템 모니터링 툴킷이며 Grafana는 오픈 소스 대시보드 툴킷입니다. Prometheus 및 Grafana에 대한 Red Hat 지원은 Red Hat 제품 설명서에 제공된 구성 권장 사항으로 제한됩니다.
3scale 운영자를 사용하면 기존 Prometheus 및 Grafana 운영자 설치를 사용하여 3scale 사용 및 리소스를 모니터링할 수 있습니다.
3scale 운영자는 모니터링 리소스를 생성하지만 해당 리소스를 수정하지 않습니다.
사전 요구 사항
- 3scale Operator가 설치되어 있습니다.
Prometheus Operator 는 클러스터에 설치됩니다. Prometheus 운영자는 Prometheus 인스턴스를 생성하고 관리하는 운영자입니다. 3scale
모니터링에 필요한 Prometheus
사용자 정의 리소스 정의를 제공합니다.다음 Prometheus Operator 및 이미지 버전은 3scale로 테스트됩니다.
-
Prometheus Operator
v0.37.0
-
Prometheus 이미지:
quay.io/prometheus/prometheus:v2.16.0
-
Prometheus Operator
Grafana 운영자가 클러스터에 설치되어 있습니다. Grafana 운영자는 Grafana 인스턴스를 만들고 관리하는 운영자입니다. 3scale
모니터링에 필요한 GrafanaDashboard
사용자 정의 리소스 정의를 제공합니다.다음 Grafana Operator 및 이미지 버전은 3scale을 사용하여 테스트됩니다.
-
Grafana operator
v3.9.0
-
Grafana 이미지:
registry.hub.docker.com/grafana/grafana:7.1.1
-
Grafana operator
클러스터가 인터넷에 노출되면 Prometheus 및 Grafana 서비스를 보호해야 합니다.
이 섹션에서는 Grafana 대시보드를 볼 수 있도록 3scale 인스턴스를 모니터링하는 방법을 설명합니다.
3.1. 3scale 모니터링 활성화
3scale을 모니터링하려면 APIManager 사용자 지정 리소스를 설정하여 모니터링을 활성화해야 합니다.
절차
3scale 배포 YAML의
spec.monitoring.enabled
매개변수를true
로 설정하여 모니터링을 활성화하도록 3scale을 구성합니다. 예를 들면 다음과 같습니다.모니터링을 활성화하도록
3scale-monitoring.yml
이라는 APIManager 사용자 지정 리소스를 생성합니다.apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata: name: apimanager1 spec: wildcardDomain: example.com monitoring: enabled: true enablePrometheusRules: false 1
- 1
- 선택적으로
PrometheusRules
를 비활성화할 수 있으며, 그렇지 않으면 기본적으로 활성화됩니다.
OpenShift 클러스터에 로그인합니다. 3scale의 OpenShift 프로젝트에서 edit 클러스터 역할(예:
cluster-admin
)을 사용하여 사용자로 로그인해야 합니다.oc login
3scale 프로젝트로 전환합니다.
oc project <project_name>
사용자 정의 리소스를 배포합니다.
$ oc apply -f 3scale-monitoring.yml
추가 리소스
3.2. 3scale을 모니터링하도록 Prometheus 구성
3scale의 모니터링을 활성화하려면 Prometheus 사용자 정의 리소스를 사용하여 Prometheus
를 배포하고 구성해야 합니다.
Prometheus 설명서에 설명된 대로 권한이 올바르게 설정되었는지 확인합니다.
절차
클러스터의 모든 리소스를 모니터링할지 또는 3scale 리소스만 모니터링할지에 따라 Prometheus 사용자 정의 리소스를 다음과 같이 배포합니다.
클러스터의 모든 리소스를 모니터링하려면
spec.podMonitorSelector
특성을{}
로 설정하고spec.ruleSelector
특성을{}
로 설정합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: example spec: podMonitorSelector: {} ruleSelector: {}
3scale 및 Prometheus Operator를 동일한 OpenShift 프로젝트에 배포하고
APP_LABEL
값이 기본3scale-api-management
로 설정된 경우 다음 단계를 사용하여 3scale 리소스를 모니터링합니다.spec.podMonitorSelector
특성을 다음과 같이 설정합니다.podMonitorSelector: matchExpressions: - key: app operator: In values: - 3scale-api-management
spec.ruleSelector
특성을 다음과 같이 설정합니다.matchExpressions: - key: app operator: In values: - 3scale-api-management
예를 들어 다음 사용자 정의 리소스를 적용합니다.
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: example spec: podMonitorSelector: matchExpressions: - key: app operator: In values: - 3scale-api-management ruleSelector: matchExpressions: - key: app operator: In values: - 3scale-api-management
다른 OpenShift 프로젝트에 3scale 및 Prometheus Operator를 배포한 경우 다음 단계를 사용하여 3scale 리소스를 모니터링합니다.
-
MYLABELKEY=MYLABELVALUE
로 3scale이 배포되는 OpenShift 프로젝트에 레이블을 지정합니다. podMonitorNamespaceSelector
필터를 사용하여 3scale Pod를 선택합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: example spec: podMonitorSelector: {} ruleSelector: {} podMonitorNamespaceSelector: matchExpressions: - key: MYLABELKEY operator: In values: - MYLABELVALUE
-
대시보드 및 경고가 예상대로 작동하도록 하려면 다음 중 하나를 수행하여 Kubernetes 메트릭, 즉 kube-state-metrics 를 통합해야 합니다.
- Prometheus 인스턴스를 클러스터 기본 Prometheus 인스턴스와 연결합니다.
- kubelet, etcd 등으로부터 메트릭을 가져오도록 자체 스크랩 작업을 구성합니다.
추가 리소스
- Prometheus에 대한 자세한 내용은 Prometheus 설명서 를 참조하십시오.
3.3. 3scale을 모니터링하도록 Grafana 구성
3scale의 모니터링을 활성화하려면 Grafana를 구성해야 합니다.
절차
app=3scale-api-management
레이블을 덮어쓰고GrafanaDashboards
리소스를 모니터링하도록 Grafana 서비스가 구성되었는지 확인합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.apiVersion: integreatly.org/v1alpha1 kind: Grafana metadata: name: grafana spec: dashboardLabelSelector: - matchExpressions: - key: app operator: In values: - 3scale-api-management
3scale 연산자가 생성한 Grafana 대시보드는 다음과 같이 레이블이 지정됩니다.
app: 3scale-api-management monitoring-key: middleware
-
Grafana Operator가 3scale과 다른 네임스페이스에 설치된 경우
--namespaces 또는 --
scan-all
Operator 플래그를 사용하여 네임스페이스 외부의 리소스를 모니터링하도록 구성합니다. Operator 플래그에 대한 자세한 내용은 Grafana 설명서 를 참조하십시오. prometheus
유형의GrafanaDataSource
사용자 지정 리소스를 생성하여 Grafana에서 Prometheus 데이터를 사용할 수 있도록 합니다. 예를 들면 다음과 같습니다.apiVersion: integreatly.org/v1alpha1 kind: GrafanaDataSource metadata: name: prometheus spec: name: middleware datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus-operated:9090 isDefault: true version: 1 editable: true jsonData: timeInterval: "5s"
여기서
http://prometheus-operated:9090
는 Prometheus 경로입니다.- Grafana 설명서에 설명된 대로 권한이 올바르게 설정되었는지 확인합니다.
추가 리소스
- Grafana에 대한 자세한 내용은 Grafana 설명서 를 참조하십시오.
3.4. 3scale 메트릭 보기
3scale, Prometheus 및 Grafana를 구성한 후 이 섹션에 설명된 지표를 볼 수 있습니다.
절차
- Grafana 콘솔에 로그인합니다.
다음에 대한 메트릭을 볼 수 있는지 확인합니다.
- 3scale이 설치된 Pod 및 네임스페이스 수준에서 Kubernetes 리소스
- APIcast 준비
- APIcast 프로덕션
- 백엔드 작업자
- 백엔드 리스너
- 시스템
- zync
3.5. Prometheus에 노출된 3scale 시스템 지표
Prometheus 끝점과 함께 3scale 시스템 Pod를 사용하여 메트릭을 노출하도록 다음 포트를 구성할 수 있습니다.
표 3.1. 3scale 시스템 포트
system-app | 포트 |
---|---|
| 9394 |
| 9395 |
| 9396 |
system-sidekiq | 포트 |
---|---|
| 9394 |
엔드 포인트는 다음을 사용하여 내부적으로만 액세스할 수 있습니다.
http://${service}:${port}/metrics
예를 들면 다음과 같습니다.
http://system-developer:9394/metrics
추가 리소스
- APIcast 모니터링에 대한 자세한 내용은 Prometheus 가이드에 3scale APIcast 지표 노출 을 참조하십시오.
- Prometheus 보안에 대한 자세한 내용은 Prometheus 보안 문서를 참조하십시오.
- Grafana 보안에 대한 자세한 내용은 권한 및 보안 Grafana 문서를 참조하십시오.
4장. Webhook를 사용한 3scale 자동화
Webhook는 자동화를 용이하게 하는 기능이며 3scale에서 발생하는 이벤트를 기반으로 다른 시스템을 통합하는 데도 사용됩니다. 3scale 시스템 내에서 지정된 이벤트가 발생하면 애플리케이션에 Webhook 메시지가 표시됩니다. 예를 들어 Webhook를 구성하면 새 계정 등록의 데이터를 사용하여 개발자 포털을 채울 수 있습니다.
4.1. Webhook 개요
Webhook는 Webhook 구성 창에서 사용 가능한 이벤트에서 선택한 이벤트에 의해 트리거되는 사용자 정의 HTTP 콜백입니다. 이러한 이벤트 중 하나가 발생하면 3scale 시스템에서 Webhook 섹션에 지정된 URL 주소에 HTTP 또는 HTTPS 요청을 수행합니다. Webhook를 사용하면 이벤트 추적과 같은 원하는 동작을 호출하도록 리스너를 구성할 수 있습니다.
Webhook의 형식은 항상 동일합니다. 다음 구조의 XML 문서를 사용하여 끝점에 게시됩니다.
<?xml version="1.0" encoding="UTF-8"?> <event> <type>application</type> <action>updated</action> <object> THE APPLICATION OBJECT AS WOULD BE RETURNED BY A GET ON THE ACCOUNT MANAGEMENT API </object> </event>
각 요소는 정보를 제공합니다.
-
<type>
: 애플리케이션,계정 등과 같은 이벤트의 제목을 제공합니다. -
<action>
: 업데이트 된 ,생성,삭제 등의 값을 사용하여 수행된 작업을 지정합니다. -
<object>
: XML 개체 자체를 계정 관리 API에서 반환하는 형식과 동일한 형식으로 구성합니다. 이를 확인하려면 대화형 ActiveDocs를 사용할 수 있습니다.
3scale에서 Webhook를 발행한 것을 보장해야 하는 경우 HTTPS 웹 후크 URL을 노출하고 3scale에서 Webhook 선언에 사용자 정의 매개변수를 추가합니다. 예: https://your-webhook-endpoint?someSecretParameterName=someSecretParameterValue. 매개 변수 이름과 값을 결정합니다. 그런 다음 웹 후크 끝점 내부에서 이 매개변수 값이 있는지 확인합니다.
4.2. Webhook 구성
절차
- 계정 설정 > 통합 > Webhook로 이동 합니다. 계정 설정 은 창의 오른쪽 상단에 있는 기어 아이콘입니다.
Webhook의 동작을 나타냅니다. 두 가지 옵션이 있습니다.
- Webhook 활성화: 이 확인란을 선택하여 Webhook를 활성화하거나 비활성화합니다.
관리 포털의 작업도 Webhook를 트리거 합니다. 이벤트가 발생할 때 Webhook를 트리거하려면 이 확인란을 선택합니다. 다음을 고려하십시오.
- 트리거 이벤트로 구성된 내부 3scale API를 호출할 때 공급자 키가 아닌 액세스 토큰을 사용합니다.
- 이 확인란을 선택한 상태로 두면 개발자 포털의 작업만 Webhook를 트리거합니다.
- 트리거할 때 선택한 이벤트에 대한 알림에 대한 URL 주소를 지정합니다.
- 표시된 URL 주소로 콜백을 트리거할 이벤트를 선택합니다.
설정을 구성한 후 Webhook 설정 업데이트 를 클릭하여 변경 사항을 저장합니다.
4.3. Webhook 문제 해결
청취 끝점에 대한 중단이 발생하는 경우 실패한 전달을 복구할 수 있습니다. 끝점이 200
코드로 응답하는 경우 3scale은 전달된 웹 후크를 고려합니다. 그렇지 않으면 60 초 간격을 사용하여 5 번 다시 시도합니다. 중단 또는 주기적으로 복구한 후 검사를 실행하고 해당되는 경우 큐를 정리해야 합니다. 다음 방법에 대한 자세한 내용은 ActiveDocs에서 확인할 수 있습니다.
- Webhook list failed deliveries
- Webhook delete failed deliveries
5장. 3scale toolbox
3scale 툴박스 는 명령줄에서 3scale 제품을 관리할 수 있는 Ruby 클라이언트입니다.
3scale 설명서 내에는 3scale toolbox, 지원되는 toolbox 명령, 서비스, 계획, SSL 및 TLS 문제 해결에 대한 정보가 있습니다. 자세한 내용은 아래 섹션 중 하나를 참조하십시오.
5.1. toolbox 설치
3scale toolbox 설치에서 공식적으로 지원되는 방법은 3scale toolbox 컨테이너 이미지를 사용하는 것입니다.
5.1.1. toolbox 컨테이너 이미지 설치
이 섹션에서는 toolbox 컨테이너 이미지를 설치하는 방법을 설명합니다.
사전 요구 사항
- Red Hat Ecosystem Catalog에서 3scale toolbox 이미지를 참조하십시오.
- Red Hat 레지스트리 서비스 계정이 있어야 합니다.
- 이 주제의 예제에서는 Podman이 설치되어 있다고 가정합니다.
절차
Red Hat Ecosystem Catalog에 로그인합니다.
$ podman login registry.redhat.io Username: ${REGISTRY-SERVICE-ACCOUNT-USERNAME} Password: ${REGISTRY-SERVICE-ACCOUNT-PASSWORD} Login Succeeded!
toolbox 컨테이너 이미지를 가져옵니다.
$ podman pull registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13
설치를 확인합니다.
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale help
추가 리소스
- OpenShift, Podman 또는 Docker를 사용하여 toolbox 이미지를 설치하는 방법에 대한 자세한 내용은 Red Hat Ecosystem Catalog에서 이미지를 가져오는 방법에 대한 지침을 참조하십시오.
-
Kubernetes에 3scale toolbox를 설치하는 방법에 대한 지침 도 참조하십시오. OpenShift에서
kubectl
대신 올바른 이미지 이름과oc
명령을 사용해야 합니다.
5.2. 지원되는 toolbox 명령
3scale toolbox를 사용하여 CLI(명령줄 도구)에서 API를 관리합니다.
업데이트
명령이 제거되고 copy
명령으로 교체되었습니다.
다음 명령이 지원됩니다.
COMMANDS account account super command activedocs activedocs super command application application super command application-plan application-plan super command backend backend super command copy copy super command help print help import import super command method method super command metric metric super command policy-registry policy-registry super command product product super command proxy-config proxy-config super command remote remotes super command service services super command OPTIONS -c --config-file=<value> 3scale toolbox configuration file (default: $HOME/.3scalerc.yaml) -h --help show help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Prints the version of this command --verbose Verbose mode
5.3. 서비스 가져오기
아래에 지정된 순서로 다음 필드를 지정하여 CSV 파일에서 서비스를 가져옵니다. CSV 파일에 이러한 헤더를 포함합니다.
service_name,endpoint_name,endpoint_http_method,endpoint_path,auth_mode,endpoint_system_name,type
다음 정보가 필요합니다.
-
3scale admin 계정
{3SCALE_ADMIN}
3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}
- 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
-
계정의 액세스 키
{ACCESS_KEY}
. -
서비스의 CSV 파일(예: example
/import_example.csv
)
다음을 실행하여 서비스를 가져옵니다.
예제
$ podman run -v $PWD/examples/import_example.csv:/tmp/import_example.csv registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale import csv --destination=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --file=/tmp/import_example.csv
이 예에서는 Podman 볼륨을 사용하여 컨테이너에 리소스 파일을 마운트합니다. 현재 $PWD
폴더에서 파일을 사용할 수 있다고 가정합니다.
5.4. 서비스 복사
동일한 계정 또는 다른 계정에서 기존 서비스를 기반으로 새 서비스를 생성합니다. 서비스를 복사할 때 관련 ActiveDocs도 복사됩니다.
다음 정보가 필요합니다.
-
복사하려는 서비스 ID
{SERVICE_ID}
-
3scale admin 계정
{3SCALE_ADMIN}
3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}
- 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
-
계정의 액세스 키
{ACCESS_KEY}
. -
다른 계정으로 복사하는 경우 대상 계정의 액세스 키:
{DEST_KEY}
-
새 서비스의 이름
{NEW_NAME}
예제
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale copy service {SERVICE_ID} --source=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --destination=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --target_system_name={NEW_NAME}
복사할 서비스에 사용자 지정 정책이 있는 경우 서비스를 복사할 대상에 해당하는 사용자 지정 정책 정의가 이미 있는지 확인합니다. 사용자 지정 정책 정의 복사에 대한 자세한 내용은 정책 레지스트리 복사를참조하십시오.
5.5. 서비스 설정만 복사
서비스 및 프록시 설정, 지표, 방법, 애플리케이션 계획, 애플리케이션 계획 제한뿐만 아니라 서비스에서 다른 기존 서비스로 규칙을 매핑할 수 있습니다.
다음 정보가 필요합니다.
-
복사하려는 서비스 ID
{SERVICE_ID}
-
대상의 서비스 ID
{DEST_ID}
-
3scale admin 계정
{3SCALE_ADMIN}
3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}
- 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
-
계정의 액세스 키
{ACCESS_KEY}
. -
대상 계정의 액세스 키
{DEST_KEY}
.
또한 선택적 플래그를 사용할 수 있습니다.
-
복사하기 전에 기존 대상 서비스 매핑 규칙을 제거하는
-f
플래그입니다. -
대상 서비스에 규칙 매핑만 복사하기 위한
-r
플래그입니다.
업데이트
명령이 제거되고 copy
명령으로 교체되었습니다.
다음 예제 명령은 한 서비스에서 다른 기존 서비스로 대량 복사를 수행합니다.
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale copy [opts] service --source=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --destination=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} {SERVICE_ID} {DEST_ID}
5.6. OpenAPI 정의 가져오기
새 서비스를 생성하거나 기존 서비스를 업데이트하려면 로컬 파일 또는 URL에서 OpenAPI 정의를 가져올 수 있습니다. 가져오기의 기본 서비스 이름은 OpenAPI 정의의 info.title
에 의해 지정됩니다. 그러나 --target_system_name=<NEW NAME>
을 사용하여 이 서비스 이름을 재정의할 수 있습니다. 서비스 이름이 이미 있으면 업데이트되거나 없는 경우 새 서비스 이름이 생성됩니다.
가져오기 openapi
명령에는 다음과 같은 형식이 있습니다.
3scale import openapi [opts] -d=<destination> <specification>
OpenAPI <specification>
은 다음 중 하나일 수 있습니다.
-
/path/to/your/definition/file.[json|yaml|yml]
-
http[s]://domain/resource/path.[json|yaml|yml]
예제
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale import openapi [opts] -d=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} my-test-api.json
명령 옵션
가져오기 openapi
명령 옵션은 다음과 같습니다.
-d --destination=<value>
-
3scale 대상 인스턴스(http
[s]://<authentication>@3scale_domain
). -t --target_system_name=<value>
- 3scale 대상 시스템 이름.
--backend-api-secret-token=<value>
- API 게이트웨이에서 백엔드 API로 전송하는 사용자 지정 시크릿 토큰입니다.
--backend-api-host-header=<value>
- API 게이트웨이에서 백엔드 API로 전송하는 사용자 지정 호스트 헤더입니다.
자세한 옵션은 3scale import openapi --help
명령을 참조하십시오.
OpenAPI 가져오기 규칙
지원되는 보안 스키마는 OAuth 흐름 유형이 있는 apiKey
및 oauth2
입니다.
OpenAPI 사양은 다음 중 하나여야 합니다.
- 사용 가능한 경로의 파일 이름.
-
toolbox에서 콘텐츠를 다운로드할 수 있는 URL입니다. 지원되는 스키마는
http
및https
입니다. -
stdin
표준 입력 스트림에서 읽습니다. 이 설정은-
값을 설정하여 제어합니다.
다음 추가 규칙은 OpenAPI 정의를 가져올 때 적용됩니다.
- 정의는 OpenAPI 2.0 또는 OpenAPI 3.0으로 검증됩니다.
- OpenAPI 정의에서 모든 매핑 규칙을 가져옵니다. API > 통합 에서 볼 수 있습니다.
- 3scale 제품의 모든 매핑 규칙이 교체됩니다.
- OpenAPI 정의에 포함된 방법만 수정됩니다.
-
OpenAPI 정의에만 있는 모든 메서드는
Hits
지표에 연결됩니다. -
메서드를 교체하려면 정확한 패턴 일치를 사용하여 메서드 이름을 OpenAPI 정의
operation.operationId
에 정의된 방법과 동일해야 합니다.
사양에 보안 요구 사항이 없지만 서비스는 OpenAPI 로 간주됩니다. toolbox는 정책 체인에 없는 경우 anonymous_policy
라고도 하는 default_credentials
정책을 추가합니다. default_credentials
정책은 선택적 매개변수 --default-credentials-user key에 제공된 user key
로 구성됩니다.
OpenAPI 3.0 제한 사항
다음 제한 사항은 OpenAPI 3.0 정의를 가져올 때 적용됩니다.
-
servers
목록의 첫 번째server.url
요소만 프라이빗 URL로 구문 분석됩니다.server.url
요소의경로
구성 요소는 OpenAPI의basePath
속성으로 사용됩니다. - toolbox는 작업 오브젝트의 경로 항목과 서버에서 서버를 구문 분석하지 않습니다.
- 보안 체계 오브젝트의 여러 흐름이 지원되지 않습니다.
5.7. OpenAPI 정의에서 3scale 백엔드 가져오기
toolbox import
명령을 사용하여 OpenAPI 정의를 가져오고 3scale backend API를 생성할 수 있습니다. 명령줄 옵션 --backend
에서 이 기능을 활성화합니다. 3scale은 OpenAPI 정의를 사용하여 백엔드와 해당 프라이빗 기본 URL과 매핑 규칙 및 메서드를 생성 및 저장합니다.
사전 요구 사항
- 3scale 2saas On-Premises 인스턴스에 대한 관리자 권한이 있는 사용자 계정입니다.
- API를 정의하는 OAS 문서입니다.
절차
다음 형식을 사용하여
가져오기
명령을 실행하여 백엔드를 생성합니다.$ 3scale import openapi -d <remote> --backend <OAS>
-
&
lt;remote
>를 백엔드를 생성할 3scale 인스턴스의 URL로 바꿉니다. 이 형식 사용http[s]://<authentication>@3scale_domain
&
lt;OAS&
gt;를/path/to/your/oasdoc.yaml
로 바꿉니다.표 5.1. 추가 OpenAPI 정의 옵션
옵션 설명 -o --output=<value>
출력 형식입니다. JSON 또는 YAML일 수 있습니다.
--override-private-base-url=<value>
3scale은 OpenAPI 정의의
servers[0].url
필드에서 백엔드의 개인 엔드포인트를 읽습니다. 해당 필드의 설정을 재정의하려면 이 옵션을 지정하고 <value
>를 선택한 개인 기본 URL로 바꿉니다. OpenAPI 정의가servers[0].url
필드에 값을 지정하지 않고import
명령에 이 옵션을 지정하지 않으면 실행에 실패합니다.--prefix-matching
OpenAPI 작업에서 파생된 매핑 규칙에 대해 엄격한 일치 항목 대신 접두사 일치를 사용합니다.
--skip-openapi-validation
OpenAPI 스키마 검증을 건너뜁니다.
-t --target_system_name=<value>
대상 시스템 이름은 테넌트의 고유한 키입니다. OpenAPI 정의에서 시스템 이름을 유추할 수 있지만 이 매개 변수를 사용하여 고유한 이름으로 해당 이름을 재정의할 수 있습니다.
5.8. 원격 액세스 인증 정보 관리
원격 3scale 인스턴스 작업을 용이하게 하기 위해 3scale 툴박스를 사용하여 원격 URL 주소와 인증 세부 정보를 정의하여 구성 파일의 원격 인스턴스에 액세스할 수 있습니다. 그런 다음 toolbox 명령에서 짧은 이름을 사용하여 이러한 remotes를 참조할 수 있습니다.
구성 파일의 기본 위치는 $HOME/.3scalerc.yaml
입니다. 그러나 THREESCALE_CLI_CONFIG 환경 변수 또는
toolbox 옵션을 사용하여 다른 위치를 지정할 수 있습니다.
--config-file <config_
file>
원격 액세스 인증 정보를 추가할 때 access_token 또는
를 지정할 수 있습니다.
provider_
key
-
http[s]://<access_token>@<3scale-instance-domain>
-
http[s]://<provider_key>@<3scale-instance-domain>
5.8.1. 원격 액세스 인증 정보 추가
다음 예제 명령은 <url>에서 짧은 <name>
을 사용하여 원격 3scale 인스턴스를 추가합니다.
3scale remote add [--config-file <config_file>] <name> <url>
예제
$ podman run --name toolbox-container registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale remote add instance_a https://123456789@example_a.net $ podman commit toolbox-container toolbox
이 예제에서는 원격 인스턴스를 생성하고 컨테이너를 커밋하여 새 이미지를 생성합니다. 그런 다음 원격 정보가 포함된 새 이미지를 실행할 수 있습니다. 예를 들어 다음 명령은 새 이미지를 사용하여 새로 추가된 원격 을 표시합니다.
$ podman run toolbox 3scale remote list instance_a https://example_a.net 123456789
그런 다음 기타 toolbox 명령은 새로 생성된 이미지를 사용하여 추가된 원격에 액세스할 수 있습니다. 이 예에서는 registry.redhat.io/3scale-amp2/
라는 이미지를 사용합니다.
toolbox
-rhel8:3scale2.13 대신 toolbox
컨테이너에 toolbox의 시크릿을 저장하는 것은 잠재적인 보안 위험입니다(예: 컨테이너를 다른 사용자에게 시크릿으로 배포하거나 자동화를 위해 컨테이너를 사용하는 경우). OpenShift에서 Podman 또는 시크릿에서 보안 볼륨을 사용합니다.
추가 리소스
Podman 사용에 대한 자세한 내용은 다음을 참조하십시오.
5.8.2. 원격 액세스 자격 증명 나열
다음 예제 명령은 원격 액세스 자격 증명을 나열하는 방법을 보여줍니다.
3scale remote list [--config-file <config_file>]
이 명령은 추가된 원격 3scale 인스턴스 목록을 <name> <
URL>
; <authentication-key>
형식으로 표시합니다.
예제
$ podman run <toolbox_image_with_remotes_added> 3scale remote list instance_a https://example_a.net 123456789 instance_b https://example_b.net 987654321
5.8.3. 원격 액세스 인증 정보 제거
다음 예제 명령은 원격 액세스 자격 증명을 제거하는 방법을 보여줍니다.
3scale remote remove [--config-file <config_file>] <name>
이 명령은 짧은 <name>
:이 명령을 사용하여 원격 3scale 인스턴스를 제거합니다.
예제
$ podman run <toolbox_image_with_remote_added> 3scale remote remove instance_a
5.8.4. 원격 액세스 인증 정보 이름 변경
다음 예제 명령은 원격 액세스 자격 증명의 이름을 변경하는 방법을 보여줍니다.
3scale remote rename [--config-file <config_file>] <old_name> <new_name>
이 명령은 짧은 <old_name>을 사용하여 원격 3scale 인스턴스의 이름을
으로 변경합니다.
<
new_name>
예제
$ podman run <toolbox_image_with_remote_added> 3scale remote rename instance_a instance_b
5.9. 애플리케이션 계획 생성
3scale toolbox를 사용하여 개발자 포털에서 애플리케이션 계획을 생성, 업데이트, 나열, 삭제, 표시 또는 내보내기/가져오기/가져오기.
5.9.1. 새 애플리케이션 계획 생성
다음 단계를 사용하여 새 애플리케이션 계획을 생성합니다.
- 애플리케이션 계획 이름을 제공해야 합니다.
-
system-name
을 재정의하려면 선택적 매개 변수를 사용합니다. - 동일한 이름의 애플리케이션 계획이 이미 존재하는 경우 오류 메시지가 표시됩니다.
-
--default
플래그를 사용하여 애플리케이션 계획을기본값으로
설정합니다. --publish
플래그를 사용하여게시된
애플리케이션 계획을 생성합니다.-
기본적으로
숨겨집니다
.
-
기본적으로
--disabled
플래그를 사용하여비활성화된
애플리케이션 계획을 생성합니다.-
기본적으로
활성화되어
있습니다.
-
기본적으로
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령은 새 애플리케이션 계획을 생성합니다.
3scale application-plan create [opts] <remote> <service> <plan-name>
애플리케이션 계획을 생성하는 동안 다음 옵션을 사용합니다.
Options --approval-required=<value> The application requires approval: true or false --cost-per-month=<value> Cost per month --default Make the default application plan --disabled Disable all methods and metrics in the application plan -o --output=<value> Output format on stdout: one of json|yaml -p --published Publish the application plan --setup-fee=<value> Set-up fee -t --system-name=<value> Set application plan system name --trial-period-days=<value> The trial period in days Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.2. 애플리케이션 계획 생성 또는 업데이트
다음 단계를 사용하여 새 애플리케이션 계획이 없는 경우 애플리케이션을 생성하거나 기존 애플리케이션 계획을 업데이트합니다.
-
--default
플래그를 사용하여기본
애플리케이션 계획을 업데이트합니다. -
--publish
플래그를 사용하여게시된
애플리케이션 계획을 업데이트합니다. -
--hide
플래그를 사용하여숨겨진
애플리케이션 계획을 업데이트합니다. -
--disabled
플래그를 사용하여비활성화된
애플리케이션 계획을 업데이트합니다. -
enabled
애플리케이션 계획을 업데이트합니다.플래그
를 사용하여 활성화된
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
계획
위치 인수는 계획 참조이며 계획ID
또는system_name
계획 중 하나일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령은 애플리케이션 계획을 업데이트합니다.
3scale application-plan create [opts] <remote> <service> <plan>
애플리케이션 계획을 업데이트하는 동안 다음 옵션을 사용합니다.
Options --approval-required=<value> The application requires approval: true or false --cost-per-month=<value> Cost per month --default Make the default application plan --disabled Disable all methods and metrics in the application plan --enabled Enable the application plan --hide Hide the application plan -n --name=<value> Set the plan name -o --output=<value> Output format on stdout: one of json|yaml -p --publish Publish the application plan --setup-fee=<value> Set-up fee --trial-period-days=<value> The trial period in days Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.3. 애플리케이션 계획 나열
다음 명령은 애플리케이션 계획을 나열합니다.
3scale application-plan list [opts] <remote> <service>
애플리케이션 계획을 나열하는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.4. 애플리케이션 계획 표시
다음 명령은 애플리케이션 계획을 보여줍니다.
3scale application-plan show [opts] <remote> <service> <plan>
애플리케이션 계획을 보여주는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.5. 애플리케이션 계획 삭제
다음 명령은 애플리케이션 계획을 삭제합니다.
3scale application-plan delete [opts] <remote> <service> <plan>
애플리케이션 계획을 삭제하는 동안 다음 옵션을 사용합니다.
Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.6. 애플리케이션 계획 내보내기/가져오기
단일 애플리케이션 계획을 yaml
콘텐츠로 내보내거나 가져올 수 있습니다.
다음을 확인합니다.
- 애플리케이션 계획에 정의된 제한이 포함됩니다.
- 애플리케이션 계획에 정의된 가격 결정 규칙이 포함됩니다.
- 제한 및 가격 규칙에 따라 참조되는 지표/방법이 포함됩니다.
- 애플리케이션 계획에 정의된 기능이 포함됩니다.
-
서비스는
id
또는system_name
으로 참조할 수 있습니다. -
애플리케이션 계획은
id
또는system_name
으로 참조할 수 있습니다.
5.9.6.1. 파일로 애플리케이션 계획 내보내기
다음 명령은 애플리케이션 계획을 내보냅니다.
3scale application-plan export [opts] <remote> <service_system_name> <plan_system_name>
예제
$ podman run -u root -v $PWD:/tmp registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale application-plan export --file=/tmp/plan.yaml remote_name service_name plan_name
이 예제에서는 Podman 볼륨을 사용하여 현재 $PWD
폴더에 출력을 위해 컨테이너에 내보낸 파일을 마운트합니다.
export
명령과 관련이 있습니다.
- 원격 서비스 및 애플리케이션 계획에 대한 작업만 읽습니다.
명령 출력은
stdout
또는 file일 수 있습니다.-
f
옵션에
지정하지 않은 경우 기본적으로yaml
콘텐츠는stdout
에 작성됩니다.
-
f
애플리케이션 계획을 내보내는 동안 다음 옵션을 사용합니다.
Options -f --file=<value> Write to file instead of stdout Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.9.6.2. 파일에서 애플리케이션 계획 가져오기
다음 명령은 애플리케이션 계획을 가져옵니다.
3scale application-plan import [opts] <remote> <service_system_name>
예제
$ podman run -v $PWD/plan.yaml:/tmp/plan.yaml registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale application-plan import --file=/tmp/plan.yaml remote_name service_name
이 예에서는 Podman 볼륨을 사용하여 현재 $PWD
폴더에서 컨테이너에 가져온 파일을 마운트합니다.
5.9.6.3. URL에서 애플리케이션 계획 가져오기
3scale application-plan import -f http[s]://domain/resource/path.yaml remote_name service_name
명령과 관련된:
명령 입력 내용은
stdin
, 파일 또는 URL 형식일 수 있습니다.-
f
옵션에
지정하지 않은 경우 기본적으로yaml
콘텐츠는stdin
에서 읽습니다.
-
f
- 원격 서비스에서 애플리케이션 계획을 찾을 수 없는 경우 생성됩니다.
원격 대상 애플리케이션 계획
id
또는system_name
을 재정의하는 선택적 매개 변수-p
,--plan
.-
p
옵션에
지정하지 않은 경우 기본적으로 애플리케이션 계획은yaml
컨텐츠의 plan 특성system_name
에 의해 참조됩니다.
-
p
- 원격 서비스에서 찾을 수 없는 yaml 콘텐츠의 지표 또는 메서드가 생성됩니다.
애플리케이션 계획을 가져오는 동안 다음 옵션을 사용합니다.
Options -f --file=<value> Read from file or URL instead of stdin -p --plan=<value> Override application plan reference Options for application-plan -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.10. 메트릭 생성
3scale toolbox를 사용하여 개발자 포털에서 지표를 생성, 업데이트, 나열 및 삭제합니다.
다음 단계를 사용하여 메트릭을 생성합니다.
- 지표 이름을 제공해야 합니다.
-
system-name
을 재정의하려면 선택적 매개 변수를 사용합니다. - 동일한 이름의 지표가 이미 있는 경우 오류 메시지가 표시됩니다.
--disabled
플래그를 사용하여비활성화된
지표를 생성합니다.-
기본적으로
활성화되어
있습니다.
-
기본적으로
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령은 메트릭을 생성합니다.
3scale metric create [opts] <remote> <service> <metric-name>
메트릭을 생성하는 동안 다음 옵션을 사용합니다.
Options --description=<value> Set a metric description --disabled Disable this metric in all application plans -o --output=<value> Output format on stdout: one of json|yaml -t --system-name=<value> Set the application plan system name --unit=<value> Metric unit: default hit Options for metric -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.10.1. 메트릭 생성 또는 업데이트
다음 단계를 사용하여 새 메트릭이 없는 경우 해당 지표를 생성하거나 기존 지표를 업데이트합니다.
- 동일한 이름의 지표가 이미 있는 경우 오류 메시지가 표시됩니다.
-
--disabled
플래그를 사용하여비활성화된
지표를 업데이트합니다. -
--enabled
플래그를 사용하여 메트릭을활성화
하도록 업데이트합니다.
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
지표
위치 인수는 지표 참조이며 지표ID
또는system_name
중 하나일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령 목록은 메트릭을 업데이트합니다.
3scale metric apply [opts] <remote> <service> <metric>
메트릭을 업데이트하는 동안 다음 옵션을 사용합니다.
Options --description=<value> Set a metric description --disabled Disable this metric in all application plans --enabled Enable this metric in all application plans -n --name=<value> This will set the metric name --unit=<value> Metric unit: default hit -o --output=<value> Output format on stdout: one of json|yaml Options for metric -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.10.2. 메트릭 나열
다음 명령은 메트릭을 나열합니다.
3scale metric list [opts] <remote> <service>
메트릭을 나열하는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for metric -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.10.3. 메트릭 삭제
다음 명령은 메트릭을 삭제합니다.
3scale metric delete [opts] <remote> <service> <metric>
메트릭을 삭제하는 동안 다음 옵션을 사용합니다.
Options for metric -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.11. 방법 생성
3scale toolbox를 사용하여 개발자 포털에서 메서드를 생성, 적용, 나열 및 삭제합니다.
5.11.1. 방법 생성
방법을 생성하려면 다음 단계를 사용하십시오.
- 메서드 이름을 제공해야 합니다.
-
system-name
을 재정의하려면 선택적 매개 변수를 사용합니다. - 같은 이름의 메서드가 이미 존재하는 경우 오류 메시지가 표시됩니다.
--disabled
플래그를 사용하여비활성화된
메서드를 생성합니다.-
기본적으로
활성화되어
있습니다.
-
기본적으로
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령은 메서드를 생성합니다.
3scale method create [opts] <remote> <service> <method-name>
방법을 생성하는 동안 다음 옵션을 사용합니다.
Options --description=<value> Set a method description --disabled Disable this method in all application plans -o --output=<value> Output format on stdout: one of json|yaml -t --system-name=<value> Set the method system name Options for method -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.11.2. 생성 또는 업데이트 방법
새로운 메서드가 없는 경우 새 메서드를 생성하거나 기존 메서드를 업데이트하려면 아래 단계를 사용합니다.
- 같은 이름의 메서드가 이미 있으면 명령에서 오류 메시지를 반환합니다.
-
--disabled 플래그
를 사용하여disabled
메서드로 업데이트합니다. -
--enabled 플래그
를 사용하여enabled
메서드를 업데이트합니다.
서비스
위치 인수는 서비스 참조이며 서비스ID
또는 서비스system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
메서드
위치 인수는 메서드 참조이며 메서드id
또는 메서드system_name
일 수 있습니다.- toolbox는 둘 중 하나를 사용합니다.
다음 명령은 메서드를 업데이트합니다.
3scale method apply [opts] <remote> <service> <method>
방법을 업데이트하는 동안 다음 옵션을 사용합니다.
Options --description=<value> Set a method description --disabled Disable this method in all application plans --enabled Enable this method in all application plans -n --name=<value> Set the method name -o --output=<value> Output format on stdout: one of json|yaml Options for method -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.11.3. 방법 나열
다음 명령은 메서드를 나열합니다.
3scale method list [opts] <remote> <service>
방법을 나열하는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for method -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.11.4. 방법 삭제
다음 명령은 메서드를 삭제합니다.
3scale method delete [opts] <remote> <service> <metric>
방법을 삭제하는 동안 다음 옵션을 사용합니다.
Options for method -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.12. 서비스 생성
3scale toolbox를 사용하여 개발자 포털에서 서비스를 생성, 적용, 나열, 표시 또는 삭제합니다.
5.12.1. 새 서비스 생성
다음 명령은 새 서비스를 생성합니다.
3scale service create [options] <remote> <service-name>
서비스를 생성하는 동안 다음 옵션을 사용합니다.
Options -a --authentication-mode=<value> Specify authentication mode of the service: - '1' for API key - '2' for App Id/App Key - 'oauth' for OAuth mode - 'oidc' for OpenID Connect -d --deployment-mode=<value> Specify the deployment mode of the service --description=<value> Specify the description of the service -o --output=<value> Output format on stdout: one of json|yaml -s --system-name=<value> Specify the system-name of the service --support-email=<value> Specify the support email of the service Options for service -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.12.2. 서비스 생성 또는 업데이트
다음을 사용하여 새 서비스를 생성하거나 기존 서비스를 업데이트합니다.
service-id_or_system-name
위치 인수는 서비스 참조입니다.-
서비스 ID 또는 서비스
system
_name
일 수 있습니다. - 툴박스가 이 문제를 자동으로 해결합니다.
-
서비스 ID 또는 서비스
-
이 명령은
멱등
입니다.
다음 명령은 서비스를 업데이트합니다.
3scale service apply <remote> <service-id_or_system-name>
서비스를 업데이트하는 동안 다음 옵션을 사용합니다.
Options -a --authentication-mode=<value> Specify authentication mode of the service: - '1' for API key - '2' for App Id/App Key - 'oauth' for OAuth mode - 'oidc' for OpenID Connect -d --deployment-mode=<value> Specify the deployment mode of the service --description=<value> Specify the description of the service -n --name=<value> Specify the name of the metric --support-email=<value> Specify the support email of the service -o --output=<value> Output format on stdout: one of json|yaml Options for services -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.12.3. 서비스 나열
다음 명령은 서비스를 나열합니다.
3scale service list <remote>
서비스를 나열하는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for services -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.12.4. 서비스 표시
다음 명령은 서비스를 표시합니다.
3scale service show <remote> <service-id_or_system-name>
서비스를 보여주는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for services -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.12.5. 서비스 삭제
다음 명령은 서비스를 삭제합니다.
3scale service delete <remote> <service-id_or_system-name>
서비스를 삭제하는 동안 다음 옵션을 사용합니다.
Options for services -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.13. ActiveDocs 생성
3scale toolbox를 사용하여 개발자 포털에서 ActiveDocs를 생성, 업데이트, 나열 또는 삭제합니다.
5.13.1. 새 ActiveDocs 생성
OpenAPI 사양과 호환되는 API 정의에서 새 ActiveDocs를 생성하려면 다음을 수행합니다.
API 정의를 3scale에 추가하여 선택적으로 이름을 지정합니다.
3scale activedocs create <remote> <activedocs-name> <specification>
ActiveDocs에 대한 OpenAPI 사양이 필요하며 다음 값 중 하나여야 합니다.
- 사용 가능한 경로의 파일 이름.
-
toolbox에서 콘텐츠를 다운로드할 수 있는 URL입니다. 지원되는 스키마는
http
및https
입니다. stdin
표준 입력 스트림에서 읽습니다. 이 설정은-
값을 설정하여 제어합니다.ActiveDocs를 생성하는 동안 다음 옵션을 사용하십시오.
Options -d --description=<value> Specify the description of the ActiveDocs -i --service-id=<value> Specify the Service ID associated to the ActiveDocs -o --output=<value> Output format on stdout: one of json|yaml -p --published Specify to publish the ActiveDocs on the Developer Portal. Otherwise it is hidden. -s --system-name=<value> Specify the system-name of the ActiveDocs --skip-swagger-validations Specify to skip validation of the Swagger specification Options for ActiveDocs -c --config-file=<value> toolbox configuration file. Defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
- 개발자 포털에 정의를 게시합니다.
5.13.2. ActiveDocs 생성 또는 업데이트
다음 명령을 사용하여 새 ActiveDocs가 없는 경우 새로 생성하거나 기존 ActiveDocs를 새 API 정의로 업데이트합니다.
3scale activedocs apply <remote> <activedocs_id_or_system_name>
ActiveDocs를 업데이트하는 동안 다음 옵션을 사용하십시오.
Options -d --description=<value> Specify the description of the ActiveDocs --hide Specify to hide the ActiveDocs on the Developer Portal -i --service-id=<value> Specify the Service ID associated to the ActiveDocs -o --output=<value> Output format on stdout: one of json|yaml --openapi-spec=<value> Specify the Swagger specification. Can be a file, a URL or '-' to read from stdin. This is a mandatory option when applying the ActiveDoc for the first time. -p --publish Specify to publish the ActiveDocs on the Developer Portal. Otherwise it is hidden -s --name=<value> Specify the name of the ActiveDocs --skip-swagger-validations=<value> Specify whether to skip validation of the Swagger specification: true or false. Defaults to true. Options for ActiveDocs -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
activedocs 동작은 3scale 2.8에서 --skip-swagger-validations를 적용합니다
. activedocs apply를 사용하여 기존 스크립트를 업데이트해야 할 수도 있습니다
. 이전에는 각 activedocs apply
명령에 이 옵션을 지정하지 않은 경우 유효성 검사를 건너뛰지 않았습니다. 이제 기본적으로 --skip-swagger-validations
가 true
입니다.
5.13.3. ActiveDocs 나열
다음 명령을 사용하여 다음을 포함하여 개발자 포털의 모든 ActiveDocs에 대한 정보를 가져옵니다.
- id
- name
- 시스템 이름
- description
- 게시됨(즉, 개발자 포털에 표시될 수 있음)
- 생성 날짜
- 최신 업데이트 날짜
다음 명령은 정의된 모든 ActiveDocs를 나열합니다.
3scale activedocs list <remote>
ActiveDocs를 나열하는 동안 다음 옵션을 사용하십시오.
Options -o --output=<value> Output format on stdout: one of json|yaml -s --service-ref=<value> Filter the ActiveDocs by service reference Options for ActiveDocs -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.13.4. ActiveDocs 삭제
다음 명령은 ActiveDocs를 제거합니다.
3scale activedocs delete <remote> <activedocs-id_or-system-name>
ActiveDocs를 삭제하는 동안 다음 옵션을 사용하십시오.
Options for ActiveDocs -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.14. 프록시 구성 나열
3scale 툴박스를 사용하여 개발자 포털에서 정의된 모든 프록시 구성을 나열, 표시, 승격합니다.
다음 명령은 프록시 구성을 나열합니다.
3scale proxy-config list <remote> <service> <environment>
프록시 구성을 나열하는 동안 다음 옵션을 사용합니다.
Options -o --output=<value> Output format on stdout: one of json|yaml Options for proxy-config -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.14.1. 프록시 구성 표시
다음 명령은 프록시 구성을 표시합니다.
3scale proxy-config show <remote> <service> <environment>
프록시 구성을 표시하는 동안 다음 옵션을 사용합니다.
Options --config-version=<value> Specify the proxy configuration version. If not specified, defaults to latest -o --output=<value> Output format on stdout: one of json|yaml Options for proxy-config -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.14.2. 프록시 구성 승격
다음 명령은 최신 스테이징 프록시 구성을 프로덕션 환경으로 승격합니다.
3scale proxy-config promote <remote> <service>
최신 스테이징 프록시 구성을 프로덕션 환경으로 승격하는 동안 다음 옵션을 사용합니다.
Options for proxy-config -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.14.3. 프록시 구성 내보내기
예를 들어, 3scale 인스턴스에 연결되어 있지 않은 자체 관리 APIcast 게이트웨이가 있는 경우 proxy-config export
명령을 사용합니다. 이 시나리오에서는 수동으로 또는 API 배포 및 구성 옵션을 사용하여 3scale 구성을 삽입합니다. 두 경우 모두 3scale 구성을 제공해야 합니다.
다음 명령은 APIcast 게이트웨이에 삽입할 수 있는 구성을 내보냅니다.
3scale proxy-config export <remote>
3scale 구성 파일로 사용할 공급자 계정의 프록시 구성을 내보낼 때 다음 옵션을 지정할 수 있습니다.
Options for proxy-config --environment=<value> Gateway environment. Must be 'sandbox' or 'production' (default: sandbox) -o --output=<value> Output format. One of: json|yaml
5.14.4. 프록시 구성 배포
다음 배포
명령은 서비스 메시를 사용하는 경우 APIcast 구성을 3scale의 스테이징 환경 또는 프로덕션 환경으로 승격합니다.
3scale proxy deploy <remote> <service>
deploy
명령을 사용하여 APIcast 구성을 스테이징 환경으로 승격할 때 다음 옵션을 지정할 수 있습니다.
-o --output=<value> Output format. One of: json|yaml
5.14.5. 프록시 구성 업데이트
다음 update
명령은 APIcast 구성을 업데이트합니다.
3scale proxy update <remote> <service>
update
명령을 사용하여 APIcast 구성을 업데이트할 때 다음 옵션을 지정할 수 있습니다.
-o --output=<value> Output format. One of: json|yaml -p --param=<value> APIcast configuration parameters. Format: [--param key=value]. Multiple options allowed.
5.14.6. 프록시 구성 표시
다음 show
명령은 배포 취소된 APIcast 구성을 가져옵니다.
3scale proxy show <remote> <service>
show
명령을 사용하는 경우 다음 옵션을 지정하여 배포 취소된 APIcast 구성을 가져올 수 있습니다.
-o --output=<value> Output format. One of: json|yaml
5.14.7. 프록시 구성 배포(더 이상 사용되지 않음)
3scale 2.12에서는 proxy-config deploy
명령에 대한 지원이 더 이상 사용되지 않습니다.
다음 명령을 사용합니다.
-
프록시 배포
-
프록시 업데이트
-
프록시 표시
자세한 내용은 프록시 구성 배포를 참조하십시오.
다음 배포
명령은 서비스 메시를 사용하는 경우 APIcast 구성을 3scale의 스테이징 환경 또는 프로덕션 환경으로 승격합니다.
3scale proxy-config deploy <remote> <service>
deploy
명령을 사용하여 APIcast 구성을 스테이징 환경으로 승격할 때 다음 옵션을 지정할 수 있습니다.
-o --output=<value> Output format. One of: json|yaml
추가 리소스
5.15. 정책 레지스트리 복사
다음과 같은 경우 toolbox 명령을 사용하여 3scale 소스 계정의 정책 레지스트리를 대상 계정으로 복사합니다.
- 대상 계정에 누락된 사용자 지정 정책이 생성 중입니다.
- 대상 계정에서 일치하는 사용자 지정 정책이 업데이트됩니다.
- 이 복사 명령은 멱등입니다.
- 누락된 사용자 지정 정책은 소스 계정에 있고 계정 테넌트에 없는 사용자 지정 정책으로 정의됩니다.
- 일치하는 사용자 지정 정책은 소스 계정과 대상 계정에 모두 존재하는 사용자 지정 정책으로 정의됩니다.
다음 명령은 정책 레지스트리를 복사합니다.
3scale policy-registry copy [opts] <source_remote> <target_remote>
Option for policy-registry -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.16. 애플리케이션 나열
3scale toolbox를 사용하여 애플리케이션 개발자 포털을 나열, 생성, 표시, 적용 또는 삭제합니다.
다음 명령은 애플리케이션을 나열합니다.
3scale application list [opts] <remote>
애플리케이션을 나열하는 동안 다음 옵션을 사용합니다.
OPTIONS --account=<value> Filter by account -o --output=<value> Output format on stdout: one of json|yaml --plan=<value> Filter by application plan. Service option required. --service=<value> Filter by service OPTIONS FOR APPLICATION -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.16.1. 애플리케이션 생성
create 명령을 사용하여 지정된 3scale 계정 및 애플리케이션 계획에 연결된 하나의 애플리케이션을 만듭니다.
필요한 위치 매개 변수는 다음과 같습니다.
-
<service>
참조. 서비스 ID 또는 서비스system
_name
일 수 있습니다. <account>
참조 다음 중 하나일 수 있습니다.-
계정
ID
-
계정의 admin
사용자의 사용자
이름
,이메일
또는 user_id -
provider_key
-
계정
-
<애플리케이션 계획>
참조. 이 ID는 계획ID
이거나system_name
계획일 수 있습니다. -
<name>
애플리케이션 이름.
다음 명령은 애플리케이션을 생성합니다.
3scale application create [opts] <remote> <account> <service> <application-plan> <name>
애플리케이션을 생성하는 동안 다음 옵션을 사용합니다.
OPTIONS --application-id=<value> App ID or Client ID (for OAuth and OpenID Connect authentication modes) of the application to be created. --application-key=<value> App Key(s) or Client Secret (for OAuth and OpenID Connect authentication modes) of the application created. --description=<value> Application description -o --output=<value> Output format on stdout: one of json|yaml --redirect-url=<value> OpenID Connect redirect url --user-key=<value> User Key (API Key) of the application to be created. OPTIONS FOR APPLICATION -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.16.2. 애플리케이션 표시
다음 명령은 애플리케이션을 보여줍니다.
3scale application show [opts] <remote> <application>
애플리케이션 매개변수는 다음을 수행할 수 있습니다.
-
user_key
- API 키 -
app_id
- app_id/app_key 쌍 또는 OAuth 및 OIDC (OpenID Connect ) 인증 모드의 클라이언트 ID -
애플리케이션 내부
ID
OPTIONS -o --output=<value> Output format on stdout: one of json|yaml OPTIONS FOR APPLICATION -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Print help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode
5.16.3. 애플리케이션 생성 또는 업데이트
다음 명령을 사용하여 새 애플리케이션이 없는 경우 애플리케이션을 생성하거나 기존 애플리케이션을 업데이트합니다.
3scale application apply [opts] <remote> <application>
애플리케이션 매개변수는 다음을 수행할 수 있습니다.
-
user_key
- API 키 -
app_id
- app_id/app_key 쌍 또는 OAuth 및 OIDC 인증 모드의 클라이언트 ID 에서 -
애플리케이션 내부
ID
애플리케이션을 찾을 수 없는 경우
계정
선택적 인수가 필요하며 생성해야 합니다. 다음 중 하나일 수 있습니다.-
계정
ID
-
3scale 계정의 관리자
사용자의 사용자
이름
,이메일
또는 user_id -
provider_key
-
계정
-
애플리케이션
이름은
3scale에서 고유하지 않으므로 이름은 고유 식별자로 사용할 수 없습니다. -
--resume
플래그로 일시 중단된 애플리케이션을 다시 시작합니다. -
애플리케이션 일시 중단 -
--suspend
플래그에 의해 일시 중단된 상태로 변경합니다.
애플리케이션을 업데이트하는 동안 다음 옵션을 사용합니다.
OPTIONS --account=<value> Application's account. Required when creating --application-key=<value> App Key(s) or Client Secret (for OAuth and OpenID Connect authentication modes) of the application to be created. Only used when application does not exist. --description=<value> Application description --name=<value> Application name -o --output=<value> Output format on stdout: one of json|yaml --plan=<value> Application's plan. Required when creating. --redirect-url=<value> OpenID Connect redirect url --resume Resume a suspended application --service=<value> Application's service. Required when creating. --suspend Suspends an application (changes the state to suspended) --user-key=<value> User Key (API Key) of the application to be created. OPTIONS FOR APPLICATION -c --config-file=<value> 3scale toolbox configuration file: defaults to $HOME/.3scalerc.yaml -h --help Show help for this command -k --insecure Proceed and operate even for server connections otherwise considered insecure -v --version Print the version of this command --verbose Verbose mode.
5.16.4. 애플리케이션 삭제
다음 명령은 애플리케이션을 삭제합니다.
3scale application delete [opts] <remote> <application>
애플리케이션 매개변수는 다음을 수행할 수 있습니다.
-
user_key
- API 키 -
app_id
- app_id/app_key 쌍 또는 OAuth 및 OIDC 인증 모드의 클라이언트 ID 에서 -
애플리케이션 내부
ID
5.17. 제품 내보내기
소스 3scale 인스턴스와의 연결이 없는 3scale 인스턴스로 해당 제품을 가져올 수 있도록 3scale 제품 정의를 .yaml
형식으로 내보낼 수 있습니다. 3scale 제품을 설정해야 해당 제품을 내보낼 수 있습니다. API 호출을 테스트하기 위해 신제품 생성을 참조하십시오.
3scale 인스턴스에 네트워크 연결이 있는 경우 3scale 인스턴스 모두에서 동일한 3scale 제품을 사용하려면 toolbox 3scale copy
명령을 사용합니다.
설명
3scale 제품을 내보내면 toolbox는 제품 및 백엔드
CRD(사용자 정의 리소스 정의)를 준수하는 .yaml
형식으로 제품
정의를 직렬화합니다. output. yaml에는 제품의 기본 정보와 함께 다음이 포함됩니다.
- 제품에 연결된 백엔드입니다.
- 연결된 백엔드에 대한 지표, 메서드 및 매핑 규칙.
- 애플리케이션 계획에 정의된 제한 및 가격 결정 규칙.
- 제한 및 가격 규칙에 따라 참조되는 지표 및 방법.
제품 내보내기는 읽기 전용 작업입니다. 즉, 제품을 반복적으로 내보내는 것이 안전합니다. toolbox는 내보낼 제품을 변경하지 않습니다. 원하는 경우 .yaml
출력을 다른 3scale 인스턴스로 가져오기 전에 수정할 수 있습니다.
3scale 제품 내보내기는 다음과 같은 상황에 적합합니다.
-
소스와 대상 3scale 인스턴스 간에는 연결이 없습니다. 예를 들어 2개 이상의 3scale 인스턴스에서 동일한 제품을 사용하려는 경우 toolbox
3scale copy
명령을 실행하지 않는 심각한 네트워크 제한이 있을 수 있습니다. -
Git 또는 일부 기타 소스 제어 시스템을 사용하여 3scale 제품 정의를
.yaml
형식으로 유지 관리하려고 합니다.
3scale toolbox 내보내기
및 가져오기
명령은 제품 정의를 백업하고 복원하는 데에도 유용할 수 있습니다.
형식
export
명령을 실행하려면 이 형식을 사용하십시오.
3scale product export [-f output-file] <remote> <product>
export
명령은 출력을 stdout
또는 파일에 전송할 수 있습니다. 기본값은 stdout
입니다. 출력을 파일로 보내려면. yaml
파일 이름으로 -f
또는 --file
옵션을 지정합니다.
<remote>
를 제품을 내보낼 3scale 인스턴스와 연결된 3scale 공급자 계정 별칭 또는 URL로 바꿉니다. 이를 지정하는 방법에 대한 자세한 내용은 원격 액세스 자격 증명 관리를 참조하십시오.
<product>
를 시스템 이름 또는 내보낼 제품의 3scale ID로 바꿉니다. 이 제품은 지정한 3scale 공급자 계정과 연결되어야 합니다. 제품의 시스템 이름은 제품 개요 페이지의 3scale GUI에서 확인할 수 있습니다. 제품의 3scale ID를 얻으려면 toolbox 3scale services show
명령을 실행합니다.
예제
다음 명령은 my-3scale-1 공급자 계정과 연결된 3scale
인스턴스에서 petstore
제품을 내보내고 petstore-product.yaml
파일에 출력합니다.
3scale product export -f petstore-product.yaml my-3scale-1 petstore
다음은 Default API
제품에 대한 직렬화 예입니다.
apiVersion: v1 kind: List items: - apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: annotations: 3scale_toolbox_created_at: '2021-02-17T10:59:23Z' 3scale_toolbox_version: 0.17.1 name: api.xysnalcj spec: name: Default API systemName: api description: '' mappingRules: - httpMethod: GET pattern: "/v2" metricMethodRef: hits increment: 1 last: false metrics: hits: friendlyName: Hits unit: hit description: Number of API hits methods: servicemethod01: friendlyName: servicemethod01 description: '' policies: - name: apicast version: builtin configuration: {} enabled: true applicationPlans: basic: name: Basic appsRequireApproval: false trialPeriod: 0 setupFee: 0.0 custom: false state: published costMonth: 0.0 pricingRules: - from: 1 to: 1000 pricePerUnit: 1.0 metricMethodRef: systemName: hits limits: - period: hour value: 1222222 metricMethodRef: systemName: hits backend: backend_01 backendUsages: backend_01: path: "/v1/pets" backend_02: path: "/v1/cats" deployment: apicastSelfManaged: authentication: oidc: issuerType: rest issuerEndpoint: https://hello:test@example.com/auth/realms/3scale-api-consumers jwtClaimWithClientID: azp jwtClaimWithClientIDType: plain authenticationFlow: standardFlowEnabled: false implicitFlowEnabled: true serviceAccountsEnabled: false directAccessGrantsEnabled: true credentials: query security: hostHeader: '' secretToken: some_secret gatewayResponse: errorStatusAuthFailed: 403 errorHeadersAuthFailed: text/plain; charset=us-ascii errorAuthFailed: Authentication failed errorStatusAuthMissing: 403 errorHeadersAuthMissing: text/plain; charset=us-ascii errorAuthMissing: Authentication parameters missing errorStatusNoMatch: 404 errorHeadersNoMatch: text/plain; charset=us-ascii errorNoMatch: No Mapping Rule matched errorStatusLimitsExceeded: 429 errorHeadersLimitsExceeded: text/plain; charset=us-ascii errorLimitsExceeded: Usage limit exceeded stagingPublicBaseURL: http://staging.example.com:80 productionPublicBaseURL: http://example.com:80 - apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: annotations: 3scale_toolbox_created_at: '2021-02-17T10:59:34Z' 3scale_toolbox_version: 0.17.1 name: backend.01.pcjwxbdu spec: name: Backend 01 systemName: backend_01 privateBaseURL: https://b1.example.com:443 description: new desc mappingRules: - httpMethod: GET pattern: "/v1/pets" metricMethodRef: hits increment: 1 last: false metrics: hits: friendlyName: Hits unit: hit description: Number of API hits methods: mybackendmethod01: friendlyName: mybackendmethod01 description: '' - apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: annotations: 3scale_toolbox_created_at: '2021-02-17T10:59:34Z' 3scale_toolbox_version: 0.17.1 name: backend.02.tiedgjsk spec: name: Backend 02 systemName: backend_02 privateBaseURL: https://b2.example.com:443 description: '' mappingRules: - httpMethod: GET pattern: "/v1/cats" metricMethodRef: hits increment: 1 last: false metrics: hits: friendlyName: Hits unit: hit description: Number of API hits methods: backend02_method01: friendlyName: backend02_method01 description: ''
제품
CR 내보내기 및 파이핑
export
명령을 실행하면 출력을 파이프하여 제품 CR(사용자 정의 리소스) 을 생성할 수 있습니다. 이 CR이 포함된 3scale 인스턴스는 다음에 따라 다릅니다.
-
3scale-provider-account
시크릿이 정의된 경우 3scale 운영자는 해당 시크릿으로 식별된 3scale 인스턴스에 product CR을 생성합니다. -
3scale-provider-account
시크릿이 정의되지 않은 경우 새 제품 CR이 있는 네임스페이스에 3scale 인스턴스가 설치되면 3scale 운영자가 해당 네임스페이스에 제품 CR을 생성합니다. -
3scale-provider-account
시크릿이 정의되지 않고 새 제품 CR이 있는 네임스페이스에 3scale 인스턴스가 포함되지 않은 경우 3scale 운영자는 제품 CR을 실패 상태로 표시합니다.
3scale-provider-account
시크릿을 포함하는 네임스페이스에서 다음 명령을 실행하도록 가정합니다. toolbox는 petstore
CR을 threescale -provider-account 보안에서 식별된 3scale
인스턴스에 파이프합니다.
3scale product export my-3scale-1 petstore | oc apply -f -
자세한 내용은 3scale Operator가 사용자 지정 리소스가 연결되는 테넌트를 식별하는 방법을 참조하십시오.
5.18. 제품 가져오기 중
소스 및 대상 3scale 인스턴스에 네트워크 연결이 없는 경우 둘 이상의 3scale 인스턴스에서 동일한 3scale 제품을 사용하려면 3scale 인스턴스 1개에서 3scale 제품을 내보내고 다른 3scale 인스턴스로 가져옵니다. 제품을 가져오려면 toolbox 3scale product import
명령을 실행합니다.
3scale 인스턴스에 네트워크 연결이 있는 경우 3scale 인스턴스 모두에서 동일한 3scale 제품을 사용하려면 toolbox 3scale copy
명령을 사용합니다.
설명
3scale 제품을 가져올 때 toolbox에는 Product
및 Backend
CRD(사용자 정의 리소스 정의)를 준수하는 .yaml
형식으로 직렬화된 제품 정의가 필요합니다. toolbox 3scale product export
명령을 실행하거나 .yaml
형식의 제품 정의를 수동으로 생성하여 이 .yaml
콘텐츠를 가져올 수 있습니다.
제품을 내보낸 경우 가져온 정의에는 내보낸 항목이 포함되어 포함될 수 있습니다.
- 제품에 연결된 백엔드입니다.
- 연결된 백엔드에 대한 지표, 메서드 및 매핑 규칙.
- 애플리케이션 계획에 정의된 제한 및 가격 결정 규칙.
- 제한 및 가격 규칙에 따라 참조되는 지표 및 방법.
원하는 경우 exported .yaml
출력을 다른 3scale 인스턴스로 가져오기 전에 수정할 수 있습니다.
가져오기
명령은 멱등입니다. 여러 번 실행하여 동일한 제품을 가져올 수 있으며 결과적으로 3scale 구성은 동일합니다. 가져오기 프로세스 중에 오류가 있으면 명령을 다시 실행하는 것이 안전합니다. 가져오기
프로세스에서 3scale 인스턴스에서 제품을 찾을 수 없는 경우 제품을 생성합니다. 또한 .yaml
정의에 정의된 지표, 메서드 또는 백엔드를 생성하고 3scale 인스턴스에서 찾을 수 없습니다.
3scale 제품을 가져오는 것은 다음과 같은 상황에 적합합니다.
-
소스와 대상 3scale 인스턴스 간에는 연결이 없습니다. 예를 들어 2개 이상의 3scale 인스턴스에서 동일한 제품을 사용하려는 경우 toolbox
3scale copy
명령을 실행하지 않는 심각한 네트워크 제한이 있을 수 있습니다. -
Git 또는 일부 기타 소스 제어 시스템을 사용하여 3scale 제품 정의를
.yaml
형식으로 유지 관리하려고 합니다.
3scale toolbox 내보내기
및 가져오기
명령은 제품 정의를 백업하고 복원하는 데에도 유용할 수 있습니다.
형식
가져오기
명령을 실행하려면 다음 형식을 사용하십시오.
3scale product import [<options>] <remote>
import
명령은 stdin
또는 파일에서 .yaml
입력을 가져옵니다. 기본값은 stdin
입니다.
다음 옵션을 지정할 수 있습니다.
-
-f
또는--file
뒤에 파일 이름을 입력하면 지정한.yaml
파일에서 입력을 가져옵니다. 이 파일에는 3scale Product 및Backend
CRD를 준수하는 3scale제품
정의가 포함되어야 합니다. -
-o
또는--output
뒤에json
또는yaml
은 지정한 형식으로 가져온 항목을 나열하는 보고서를 출력합니다. 기본 출력 형식은json
입니다.
<remote>
를 제품을 가져올 3scale 공급자 계정 별칭 또는 3scale 인스턴스와 연결된 URL로 바꿉니다. 이를 지정하는 방법에 대한 자세한 내용은 원격 액세스 자격 증명 관리를 참조하십시오.
예제
다음 명령은 petstore-product.yaml
에 정의된 제품을 my-3scale-2 공급자 계정과 연결된 3scale
인스턴스로 가져옵니다. 기본적으로 가져온 보고서는 .json
형식으로 되어 있습니다.
3scale product import -f petstore-product.yaml my-3scale-2
import
명령은 가져온 항목을 나열하는 보고서를 출력합니다. 예를 들면 다음과 같습니다.
api: product_id: 2555417888846 backends: backend_01: backend_id: 73310 missing_metrics_created: 1 missing_methods_created: 1 missing_mapping_rules_created: 1 backend_02: backend_id: 73311 missing_metrics_created: 0 missing_methods_created: 2 missing_mapping_rules_created: 1 missing_methods_created: 1 missing_metrics_created: 1 missing_mapping_rules_created: 2 missing_application_plans_created: 2 application_plans: basic: application_plan_id: 2357356246461 missing_limits_created: 7 missing_pricing_rules_created: 7 unlimited: application_plan_id: 2357356246462 missing_limits_created: 1 missing_pricing_rules_created: 0
직렬화된 제품 정의의 예는 제품 내보내기의 끝에 있습니다.
5.19. 제품 정책 체인 내보내기 및 가져오기
제품의 정책 체인을 yaml 또는 json 콘텐츠로 내보내거나 가져올 수 있습니다. 명령줄에서 id
또는 system
값으로 제품을 참조합니다. 제품의 정책 체인을 내보내거나 가져올 수 있으려면 3scale 제품을 설정해야 합니다. 다음 내용을 참조하십시오. API 호출을 테스트하기 위한 신제품 생성.
export
명령의 기능
- 명령은 원격 제품에 대한 읽기 전용 작업입니다.
-
명령은 기본적으로 해당 출력을 표준 출력
stdout
에 씁니다. f플래그는
명령의 출력을 파일에 쓰는 데 사용할 수 있습니다. -
명령 출력 형식은
json
또는yaml
입니다. 기본 형식은yaml
입니다.
내보내기 제품 정책 체인에 대한 도움말 옵션
NAME export - export product policy chain USAGE 3scale policies export [opts] <remote> <product> DESCRIPTION export product policy chain OPTIONS -f --file=<value> Write to file instead of stdout -o --output=<value> Output format. One of: json|yaml
명령 형식
다음은 yaml 의 파일로 정책 체인을 내보내는 명령의 형식입니다.
$ 3scale policies export -f policies.yaml -o yaml remote_name product_name
import
명령의 기능:
-
명령은 표준 입력 또는
stdin
에서 입력을 읽습니다. fFILE
플래그가 설정되면 파일에서 입력을 읽습니다.u URL
플래그가 설정되면 URL에서 입력을 읽습니다. -
가져온 콘텐츠는
yaml
또는json
중 하나일 수 있습니다. toolbox에서 자동으로 해당 형식을 탐지하므로 형식을 지정할 필요가 없습니다. -
기존 정책 체인은 새로 가져온 정책 체인으로 덮어씁니다. 그러면
SET
의미 체계가 구현됩니다. - 모든 콘텐츠 검증은 3scale API에 위임됩니다.
가져오기 제품 정책 체인에 대한 도움말 옵션
NAME import - import product policy chain USAGE 3scale policies import [opts] <remote> <product> DESCRIPTION import product policy chain OPTIONS -f --file=<value> Read from file -u --url=<value> Read from url
명령 형식
다음은 파일에서 정책 체인을 가져오는 명령 형식입니다.
$ 3scale policies import -f plan.yaml remote_name product_name
다음은 URI에서 정책 체인을 가져오는 명령 형식입니다.
$ 3scale policies import -f http[s]://domain/resource/path.yaml remote_name product_name
5.20. API 백엔드 복사
지정된 3scale 시스템에 지정된 소스 API 백엔드의 복사본을 만듭니다. 기본적으로 대상 시스템은 소스 백엔드 시스템 이름으로 먼저 검색합니다.
- 선택한 시스템 이름의 백엔드를 찾을 수 없는 경우 생성됩니다.
- 선택한 시스템 이름을 가진 백엔드가 발견되면 교체됩니다. 매핑 규칙은 완전히 새 항목으로 교체되는 동안 누락된 지표와 메서드만 생성됩니다.
target _system_name
옵션을 사용하여 시스템 이름을 재정의할 수 있습니다.
복사된 구성 요소
다음 API 백엔드 구성 요소가 복사됩니다.
- 메트릭
- 방법
- 매핑 규칙: 복사 및 교체됩니다.
절차
다음 명령을 입력하여 API 백엔드를 복사합니다.
3scale backend copy [opts] -s <source_remote> -d <target_remote> <source_backend>
지정된 3scale 인스턴스는 원격 이름 또는 URL일 수 있습니다.
참고명령당 하나의 API 백엔드만 복사할 수 있습니다. 여러 명령을 사용하여 여러 백엔드를 복사할 수 있습니다. 다른
--target_system_name 이름을
지정하여 동일한 백엔드를 여러 번 복사할 수 있습니다.
API 백엔드를 복사할 때 다음 옵션을 사용합니다.
Options -d --destination=<value> 3scale target instance: URL or remote name (required). -s --source=<value> 3scale source instance: URL or remote name (required). -t --target_system_name=<value> Target system name: defaults to source system name.
다음 예제 명령은 --target_system_name
에 다른 값을 지정하여 API 백엔드를 여러 번 복사하는 방법을 보여줍니다.
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale backend copy [-t target_system_name] -s 3scale1 -d 3scale2 api_backend_01
5.21. API 제품 복사
대상 3scale 시스템에 지정된 소스 API 제품의 복사본을 만듭니다. 기본적으로 소스 API 제품 시스템 이름은 먼저 대상 시스템을 검색합니다.
-
선택한
system-name
을 가진 제품을 찾을 수 없는 경우 생성됩니다. -
선택한
시스템 이름의 제품이 있으면
업데이트됩니다. 매핑 규칙은 완전히 새 항목으로 교체되는 동안 누락된 지표와 메서드만 생성됩니다.
target _system_name
옵션을 사용하여 시스템 이름을 재정의할 수 있습니다.
복사된 구성 요소
다음 API 제품 구성 요소가 복사됩니다.
- 구성 및 설정
- 메트릭 및 방법
- 매핑 규칙: 복사 및 교체됩니다.
- 애플리케이션 계획, 가격 결정 규칙 및 제한 사항
- 애플리케이션 사용 규칙
- Policies
- 백엔드
- ActiveDocs
절차
다음 명령을 입력하여 API 제품을 복사합니다.
3scale product copy [opts] -s <source_remote> -d <target_remote> <source_product>
지정된 3scale 인스턴스는 원격 이름 또는 URL일 수 있습니다.
참고명령당 하나의 API 제품만 복사할 수 있습니다. 여러 명령을 사용하여 여러 제품을 복사할 수 있습니다. 다른
--target_system_name 이름을
지정하여 동일한 제품을 여러 번 복사할 수 있습니다.
API 제품을 복사할 때 다음 옵션을 사용합니다.
Options -d --destination=<value> 3scale target instance: URL or remote name (required). -s --source=<value> 3scale source instance: URL or remote name (required). -t --target_system_name=<value> Target system name: defaults to source system name.
다음 예제 명령은 --target_system_name
에 다른 값을 지정하여 API 제품을 여러 번 복사하는 방법을 보여줍니다.
$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.13 3scale product copy [-t target_system_name] -s 3scale1 -d 3scale2 my_api_product_01
5.22. SSL 및 TLS 관련 문제 해결
이 섹션에서는 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 관련 문제를 해결하는 방법을 설명합니다.
자체 서명 SSL 인증서와 관련된 문제가 발생하면 이 섹션에 설명된 대로 원격 호스트 인증서를 다운로드하여 사용할 수 있습니다. 예를 들어 일반적인 오류에는 SSL 인증서 문제, 즉 자체 서명된 인증서 또는 인증서
체인의 자체 서명 인증서가
포함됩니다.
절차
openssl을 사용하여 원격 호스트 인증서를 다운로드합니다
. 예를 들면 다음과 같습니다.$ echo | openssl s_client -showcerts -servername self-signed.badssl.com -connect self-signed.badssl.com:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > self-signed-cert.pem
curl
을 사용하여 인증서가 올바르게 작동하는지 확인합니다. 예를 들면 다음과 같습니다.$ SSL_CERT_FILE=self-signed-cert.pem curl -v https://self-signed.badssl.com
인증서가 올바르게 작동하는 경우 더 이상 SSL 오류가 표시되지 않습니다. 인증서가 올바르게 작동하지 않는 경우
-k
옵션(또는 긴 형식인--insecure
)을 사용하여curl
명령을 실행해 보십시오. 이는 비보안으로 간주되는 서버 연결에서도 진행하려고 함을 나타냅니다.SSL_CERT_FILE
환경 변수를3scale
명령에 추가합니다. 예를 들면 다음과 같습니다.$ podman run --env "SSL_CERT_FILE=/tmp/self-signed-cert.pem" -v $PWD/self-signed-cert.pem:/tmp/self-signed-cert.pem egistry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.13 3scale service list https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME}
이 예에서는 Podman 볼륨을 사용하여 컨테이너에 인증서 파일을 마운트합니다. 현재
$PWD
폴더에서 파일을 사용할 수 있다고 가정합니다.대체 방법은 3scale toolbox 이미지를 기본 이미지로 사용하여 자체 toolbox 이미지를 생성한 다음 고유한 신뢰할 수 있는 인증서 저장소를 설치하는 것입니다.
추가 리소스
- SSL 인증서에 대한 자세한 내용은 Red Hat Certificate System 설명서를 참조하십시오.
- Podman에 대한 자세한 내용은 Red Hat Enterprise Linux 8에서 Linux 컨테이너 빌드, 실행 및 관리를 참조하십시오.
6장. 3scale에서 API 환경 매핑
API 프로바이더는 3scale 관리 포털을 통해 관리되는 API에 대한 액세스를 제공합니다. 그런 다음 다양한 환경에서 API 백엔드를 배포합니다. API 백엔드 환경에는 다음이 포함됩니다.
- 개발, 품질 보증(QA), 스테이징 및 운영에 사용되는 다양한 환경.
- 자체 API 백엔드 세트를 관리하는 팀 또는 부서에 사용되는 다양한 환경입니다.
Red Hat 3scale 제품은 API의 단일 API 또는 하위 집합을 나타내지만 다양한 API 백엔드 환경을 매핑하고 관리하는 데에도 사용됩니다.
3scale 제품의 API 환경 매핑에 대한 자세한 내용은 다음 섹션을 참조하십시오.
6.1. 환경별 제품
이 방법은 각 API 백엔드 환경에 별도의 3scale 제품을 사용합니다. 게이트웨이 구성 변경 사항을 API 백엔드와 마찬가지로 안전하게 테스트하고 프로덕션 구성으로 승격할 수 있도록 제품마다 프로덕션 게이트웨이와 스테이징 게이트웨이를 구성합니다.
Production Product => Production Product APIcast gateway => Production Product API upstream Staging Product => Staging Product APIcast gateway => Staging Product API upstream
다음과 같이 API 백엔드 환경에 대한 제품을 구성합니다.
개발 환경
개발 백엔드 만들기
- 이름: Dev
- 개인 기본 URL: API 백엔드의 URL
Dev 제품 만들기
-
프로덕션 공개 기반 URL:
https://dev-api-backend.yourdomain.com
-
준비 공개 기본 URL:
https://dev-api-backend.yourdomain.com
- 백엔드 경로를 사용하여 Dev 백엔드 추가 /
-
프로덕션 공개 기반 URL:
QA 환경
QA 백엔드 만들기
- 이름: QA
- 개인 기본 URL: API 백엔드의 URL
QA 제품 만들기
-
프로덕션 공개 기반 URL:
https://qa-api-backend.yourdomain.com
-
준비 공개 기본 URL:
https://qa-api-backend.yourdomain.com
- 백엔드 경로를 사용하여 QA 백엔드 추가 /
-
프로덕션 공개 기반 URL:
프로덕션 환경
프로덕션 백엔드 만들기
- 이름: prod
- 개인 기본 URL: API 백엔드의 URL
Prod 제품 만들기
-
프로덕션 공개 기반 URL:
https://prod-api-backend.yourdomain.com
-
준비 공개 기본 URL:
https://prod-api-backend.yourdomain.com
- 백엔드 경로를 사용하여 프로덕션 백엔드 추가 /
-
프로덕션 공개 기반 URL:
추가 리소스
- 3scale 제품에 대한 자세한 내용은 3scale의 첫 번째 단계를 참조하십시오.
6.2. 3scale 온프레미스 인스턴스
3scale 온프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 여러 가지 방법이 있습니다.
- 각 API 백엔드 환경에 대해 별도의 3scale 인스턴스
- 멀티 테넌시 기능을 사용하는 단일 3scale 인스턴스
6.2.1. 환경당 3scale 인스턴스 분리
이 방법에서는 각 API 백엔드 환경에 별도의 3scale 인스턴스가 배포됩니다. 이 아키텍처의 이점은 각 환경이 서로 격리되므로 공유 데이터베이스 또는 기타 리소스가 없다는 것입니다. 예를 들어 한 환경에서 수행되는 모든 부하 테스트는 다른 환경의 리소스에 영향을 주지 않습니다.
이러한 설치 분리는 위에서 설명한 대로 이점이 있지만 더 많은 운영 리소스와 유지 관리가 필요합니다. 이러한 추가 리소스는 OpenShift 관리 계층에 필요하며 3scale 계층에는 필요하지 않습니다.
6.2.2. 환경당 3scale 테넌트 분리
이 방법에서는 단일 3scale 인스턴스가 사용되지만 멀티 테넌시 기능은 여러 API 백엔드를 지원하는 데 사용됩니다.
두 가지 옵션이 있습니다.
- 단일 테넌트 내에서 환경과 3scale 제품 간 1대-1 매핑을 만듭니다.
필요에 따라 테넌트당 하나 이상의 제품을 사용하여 환경과 테넌트 간의 1대-1 매핑을 만듭니다.
- API 백엔드 환경에 해당하는 테넌트 3개가 dev-tenant, qa-tenant, prod-tenant입니다. 이 접근 방식의 이점은 환경을 논리적으로 분리할 수 있지만 공유된 물리적 리소스를 사용한다는 것입니다.
공유 물리적 리소스는 API 환경을 여러 테넌트가 있는 단일 설치에 매핑하기 위한 최적의 전략을 분석할 때 고려해야 합니다.
6.3. 3scale 혼합 접근 방식
3scale 온프레미스 인스턴스에 설명된 접근 방식을 결합할 수 있습니다. 예를 들면 다음과 같습니다.
- 프로덕션용 별도의 3scale 인스턴스
- dev 및 qa의 프로덕션 이외의 환경에서 별도의 테넌트가 있는 별도의 3scale 인스턴스
6.4. APIcast 게이트웨이를 사용하는 3scale
3scale 온프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 두 가지 대안이 있습니다.
- 3scale 설치마다 스테이징 및 프로덕션을 위한 2개의 내장 APIcast 게이트웨이가 제공됩니다.
- 3scale이 실행 중인 OpenShift 클러스터에 추가 APIcast 게이트웨이를 배포합니다.
6.4.1. APIcast 기본 제공 기본 게이트웨이
APIcast 내장 게이트웨이를 사용하면 API cast 게이트웨이와 함께 3scale에 설명된 위의 방식으로 구성된 API 백엔드가 자동으로 처리됩니다. 3scale Master Admin에서 테넌트를 추가하면 프로덕션 및 기본 제공 APIcast 게이트웨이를 스테이징하는 테넌트에 대한 경로가 생성됩니다. 멀티 테넌시 하위 도메인 이해보기
-
<API_NAME>-<TENANT_NAME>-apicast.staging.<WILDCARD_DOMAIN>
-
<API_NAME>-<TENANT_NAME>-apicast.production.<WIDLCARD_DOMAIN>
따라서 다른 테넌트에 매핑되는 각 API 백엔드 환경에는 해당 경로가 할당됩니다. 예를 들면 다음과 같습니다.
-
Dev
<API_NAME>-dev-apicast.staging.<WILDCARD_DOMAIN>
-
QA
<API_NAME>-qa-apicast.staging.<WILDCARD_DOMAIN>
-
prod
<API_NAME>-prod-apicast.staging.<WILDCARD_DOMAIN>
6.4.2. 추가 APIcast 게이트웨이
추가 APIcast 게이트웨이는 3scale 인스턴스가 실행 중인 것과 다른 OpenShift 클러스터에 배포된 게이트웨이입니다. 추가 APIcast 게이트웨이를 설정하고 사용하는 방법은 여러 가지가 있습니다. APIcast를 시작할 때 사용되는 환경 변수 THREESCALE_PORTAL_ENDPOINT
의 값은 추가 APIcast 게이트웨이 설정 방법에 따라 달라집니다.
각 API 백엔드 환경에 별도의 APIcast 게이트웨이를 사용할 수 있습니다. 예를 들면 다음과 같습니다.
DEV_APICAST -> DEV_TENANT ; DEV_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for DEV_TENANT QA_APICAST -> QA_TENANT ; QA_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for QA_APICAST PROD_APICAST -> PROD_TENANT ; PROD_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for PROD_APICAST
THREESCALE_PORTAL_ENDPOINT
는 APIcast에서 구성을 다운로드하는 데 사용됩니다. API 백엔드 환경에 매핑되는 각 테넌트는 별도의 APIcast 게이트웨이를 사용합니다. THREESCALE_PORTAL_ENDPOINT
는 해당 API 백엔드 환경과 관련된 모든 제품 구성을 포함하는 테넌트의 관리 포털로 설정됩니다.
단일 APIcast 게이트웨이를 여러 API 백엔드 환경에서 사용할 수 있습니다. 이 경우 THREESCALE_PORTAL_ENDPOINT
가 Master Admin Portal 로 설정됩니다.
7장. 3scale toolbox로 API 라이프사이클 자동화
이 주제에서는 Red Hat 3scale을 통한 API 라이프사이클 개념에 대해 설명하고 3scale toolbox 명령을 사용하여 Jenkins 지속적 통합/지속적 배포(CI/CD) 파이프라인을 사용하여 API 프로바이더가 배포 단계를 자동화하는 방법을 보여줍니다. 샘플 Jenkins CI/CD 파이프라인을 배포하는 방법, 3scale 공유 라이브러리를 사용하여 사용자 정의 Jenkins 파이프라인 생성 방법 및 처음부터 사용자 정의 파이프라인 생성 방법을 설명합니다.
7.1. API 라이프사이클 단계 개요
API 라이프사이클은 더 이상 사용되지 않을 때까지 API가 생성될 때 까지 필요한 모든 활동을 설명합니다. 3scale을 사용하면 API 프로바이더가 전체 API 라이프사이클 관리를 수행할 수 있습니다. 이 섹션에서는 API 라이프사이클의 각 단계에 대해 설명하고 해당 목표와 예상 결과를 설명합니다.
다음 다이어그램에서는 왼쪽의 API 공급자 기반 단계와 오른쪽에 API 소비자 기반 단계를 보여줍니다.

Red Hat은 현재 API 프로바이더 사이클 단계 및 API 소비자 사이클의 모든 단계를 설계, 구현, 배포, 보안 및 관리합니다.
7.1.1. API 공급자 사이클
API 프로바이더 사이클 단계는 API 지정, 개발 및 배포를 기반으로 합니다. 다음은 각 단계의 목표와 결과를 설명합니다.
표 7.1. API 공급자 라이프사이클 단계
Stage | 목적 | 결과 |
---|---|---|
1. 전략 | 목표, 리소스, 목표 시장, 기간을 비롯하여 API의 기업 전략을 결정하고 계획을 수립합니다. | 기업 전략은 목표 달성을 위한 명확한 계획으로 정의됩니다. |
2. 설계 | API 계약을 조기에 만들어 프로젝트 간 종속성을 해제하고 피드백을 수집하며, 위험과 출시 시간을 줄입니다(예: Apicurio Studio 사용). | 소비자 중심의 API 계약은 API와 교환할 수 있는 메시지를 정의합니다. API 소비자는 피드백을 제공했습니다. |
3. Mock | API 소비자가 구현을 시작하는 데 사용할 수 있는 실제 예제 및 페이로드를 사용하여 API 계약을 추가로 지정합니다. | mock API가 실시간이며 실제 예제를 반환합니다. API 계약이 예제로 완료되었습니다. |
4. 테스트 | 개발 API를 테스트하는 데 사용할 수 있는 비즈니스 기대 사항과 API 계약을 추가로 지정합니다. | 일련의 수락 테스트가 생성됩니다. API 설명서는 비즈니스의 기대에 부응합니다. |
5. 구현 | Red Hat Fuse와 같은 통합 프레임워크 또는 원하는 개발 언어를 사용하여 API를 구현합니다. 구현이 API 계약과 일치하는지 확인합니다. | API가 구현됩니다. 사용자 지정 API 관리 기능이 필요한 경우 3scale APIcast 정책도 개발됩니다. |
6. 배포 | 3scale toolbox와 함께 CI/CD 파이프라인을 사용하여 API 통합, 테스트, 배포 및 관리를 자동화합니다. | CI/CD 파이프라인은 자동화된 방식으로 프로덕션 환경에 API를 통합, 테스트, 배포 및 관리합니다. |
7. 보안 | API가 안전한지 확인합니다(예: 보안 개발 사례 및 자동화된 보안 테스트 사용). | 보안 지침, 프로세스 및 게이트가 마련되어 있습니다. |
8. 관리 | 환경, 버전 관리, 폐기, 규모에 따른 폐기 간의 API 승격 관리. | 프로세스 및 도구는 대규모 API를 관리하기 위한 것입니다(예: API의 변경 사항을 분리하지 않도록 의미 버전 지정). |
7.1.2. API 소비자 주기
API 소비자 사이클 단계는 사용을 위해 API를 승격, 배포 및 재설정하는 방법을 기반으로 합니다. 다음은 각 단계의 목표와 결과를 설명합니다.
표 7.2. API 소비자 라이프사이클 단계
Stage | 목적 | 결과 |
---|---|---|
9. 검색 | API를 타사 개발자, 파트너 및 내부 사용자에게 홍보합니다. | 개발자 포털은 실시간 및 최신 문서가 지속적으로 이 개발자 포털(예: 3scale ActiveDocs 사용)으로 푸시됩니다. |
10. 개발 | 타사 개발자, 파트너 및 내부 사용자를 안내하고 API를 기반으로 애플리케이션을 개발할 수 있도록 합니다. | 개발자 포털에는 모범 사례, 가이드 및 권장 사항이 포함되어 있습니다. API 개발자는 mock 및 테스트 엔드포인트에 액세스하여 소프트웨어를 개발할 수 있습니다. |
11. 사용 | 증가하는 API 사용을 처리하고 대규모의 API 소비자를 관리합니다. | 준비된 애플리케이션 계획은 소비가 가능하며 최신 가격 및 제한사항이 지속적으로 반영됩니다. API 소비자는 CI/CD 파이프라인에서 API 키 또는 클라이언트 ID/시크릿 생성을 통합할 수 있습니다. |
12. 모니터 | API 상태, 품질 및 개발자 참여에 대한 팩트 및 수량화된 피드백을 수집합니다(예: Time to first Hello World!). | 모니터링 시스템이 설치되어 있습니다. 대시보드에는 API에 대한 KPI(예: 가동 시간, 분당 요청, 대기 시간 등)가 표시됩니다. |
13. 수익화 | 규모에 따라 새 수입을 유도합니다(이 단계는 선택 사항임). | 예를 들어, 다수의 소규모 API 소비자를 대상으로 하는 경우 수익화가 활성화되고 소비자는 자동화된 방식으로 사용량에 따라 청구됩니다. |
7.2. 샘플 Jenkins CI/CD 파이프라인 배포
3scale toolbox를 사용한 API 라이프사이클 자동화에서는 API 라이프사이클의 배포 단계에 중점을 두고 CI/CD 파이프라인을 사용하여 API 관리 솔루션을 자동화할 수 있습니다. 이 주제에서는 3scale toolbox를 호출하는 샘플 Jenkins 파이프라인을 배포하는 방법에 대해 설명합니다.
- 7.2.1절. “Jenkins CI/CD 파이프라인 샘플”
- 7.2.2절. “3scale 호스팅 환경 설정”
- 7.2.3절. “3scale 온프레미스 환경 설정”
- 7.2.4절. “OpenID Connect용 Red Hat Single Sign-On 배포”
- 7.2.5절. “3scale toolbox 설치 및 액세스 활성화”
- 7.2.6절. “API 백엔드 배포”
- 7.2.7절. “자체 관리 APIcast 인스턴스 배포”
- 7.2.8절. “샘플 파이프라인 설치 및 배포”
- 7.2.9절. “3scale toolbox를 사용한 API 라이프사이클 자동화의 제한 사항”
7.2.1. Jenkins CI/CD 파이프라인 샘플
다음 샘플은 API 라이프사이클 자동화를 위해 Jenkins 파이프라인을 생성하고 배포하는 방법에 대한 예로 Red Hat 통합 리포지토리에 제공됩니다.
표 7.3. Jenkins 공유 라이브러리 파이프라인 샘플
샘플 파이프라인 | 대상 환경 | 보안 |
---|---|---|
3scale 호스팅 | API 키 | |
APIcast 자체 관리가 포함된 3scale 호스팅 및 3scale 온프레미스 | 없음 | |
APIcast 자체 관리가 포함된 3scale 호스팅 및 3scale 온프레미스 | OpenID Connect (OIDC) | |
3scale APIcast 자체 관리와 함께 개발, 테스트 및 프로덕션 호스팅 | API 키 | |
3scale APIcast 자체 관리와 함께 개발, 테스트 및 프로덕션 호스팅 | API 키, 없음, OIDC |
이러한 샘플은 3scale 툴박스를 호출하여 주요 API 관리 기능을 보여주는 3scale Jenkins 공유 라이브러리를 사용합니다. 이 항목에서 설정 단계를 수행한 후 Red Hat 통합 리포지토리의 각 샘플 사용 사례에 제공된 OpenShift 템플릿을 사용하여 파이프라인을 설치할 수 있습니다.
샘플 파이프라인 및 애플리케이션은 예제로만 제공됩니다. 샘플 파이프라인에서 활용하는 기본 API, CLI 및 기타 인터페이스는 Red Hat에서 완벽하게 지원합니다. 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다.
7.2.2. 3scale 호스팅 환경 설정
3scale 호스팅 환경 설정은 모든 샘플 Jenkins CI/CD 파이프라인에 필요합니다.
SaaS - API 키
,멀티 환경
및 의미 버전 지정
샘플 파이프라인은 3scale 호스팅만 사용합니다. 하이브리드 - 개방형
하이브리드 - OIDC
파이프라인은 또한 3scale 온프레미스를 사용합니다. 3scale 온프레미스 환경 설정 도 참조하십시오.
사전 요구 사항
- Linux 워크스테이션이 있어야 합니다.
- 3scale 호스팅 환경이 있어야 합니다.
OpenShift 3.11 클러스터가 있어야 합니다. OpenShift 4는 현재 지원되지 않습니다.
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale 지원 구성 페이지를 참조하십시오.
- OpenShift 설명서에 설명된 대로 와일드카드 경로가 OpenShift 라우터에서 활성화되었는지 확인합니다.
절차
- 3scale 호스팅 관리 포털 콘솔에 로그인합니다.
- 계정 관리 API에 대한 쓰기 액세스 권한이 있는 새 액세스 토큰을 생성합니다.
나중에 사용하기 위해 생성된 액세스 토큰을 저장합니다. 예를 들면 다음과 같습니다.
export SAAS_ACCESS_TOKEN=123...456
나중에 사용하기 위해 3scale 테넌트의 이름을 저장합니다. 관리 포털 URL에서
-admin.3scale.net
이전의 문자열입니다. 예를 들면 다음과 같습니다.export SAAS_TENANT=my_username
- 관리 포털의 대상 > ; 계정 > 목록으로 이동합니다.
- Developer (개발자)를 클릭합니다.
개발자 계정 ID 를 저장합니다.
/buyers/accounts/
뒤의 URL의 마지막 부분입니다. 예를 들면 다음과 같습니다.export SAAS_DEVELOPER_ACCOUNT_ID=123...456
7.2.3. 3scale 온프레미스 환경 설정
3scale 온프레미스 환경 설정은 하이브리드( 오픈 및
샘플 Jenkins CI/CD 파이프라인에만 필요합니다.
하이브리드) -
OIDC
이러한 하이브리드
샘플 파이프라인을 사용하려면 3scale 온프레미스 환경과 3scale 호스팅 환경을 설정해야 합니다. 3scale 호스팅 환경 설정을 참조하십시오.
사전 요구 사항
- Linux 워크스테이션이 있어야 합니다.
- 3scale 온프레미스 환경이 있어야 합니다. OpenShift에 템플릿을 사용하여 3scale 온프레미스를 설치하는 방법에 대한 자세한 내용은 3scale 설치 설명서를 참조하십시오.
OpenShift 3.11 클러스터가 있어야 합니다. OpenShift 4는 현재 지원되지 않습니다.
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
- OpenShift 설명서에 설명된 대로 와일드카드 경로가 OpenShift 라우터에서 활성화되었는지 확인합니다.
절차
- 3scale 사내 관리 포털 콘솔에 로그인합니다.
- 계정 관리 API에 대한 쓰기 액세스 권한이 있는 새 액세스 토큰을 생성합니다.
나중에 사용하기 위해 생성된 액세스 토큰을 저장합니다. 예를 들면 다음과 같습니다.
export SAAS_ACCESS_TOKEN=123...456
나중에 사용하기 위해 3scale 테넌트의 이름을 저장합니다.
export ONPREM_ADMIN_PORTAL_HOSTNAME="$(oc get route system-provider-admin -o jsonpath='{.spec.host}')"
와일드카드 경로를 정의합니다.
export OPENSHIFT_ROUTER_SUFFIX=app.openshift.test # Replace me! export APICAST_ONPREM_STAGING_WILDCARD_DOMAIN=onprem-staging.$OPENSHIFT_ROUTER_SUFFIX export APICAST_ONPREM_PRODUCTION_WILDCARD_DOMAIN=onprem-production.$OPENSHIFT_ROUTER_SUFFIX
참고OPENSHIFT_ROUTER_SUFFIX
값을 OpenShift 라우터의 접미사(예:app.openshift.test)로 설정해야 합니다.
기존 3scale 온프레미스 인스턴스에 와일드카드 경로를 추가합니다.
oc create route edge apicast-wildcard-staging --service=apicast-staging --hostname="wildcard.$APICAST_ONPREM_STAGING_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain oc create route edge apicast-wildcard-production --service=apicast-production --hostname="wildcard.$APICAST_ONPREM_PRODUCTION_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain
- 관리 포털의 대상 > ; 계정 > 목록으로 이동합니다.
- Developer (개발자)를 클릭합니다.
개발자 계정 ID 를 저장합니다.
/buyers/accounts/
:export ONPREM_DEVELOPER_ACCOUNT_ID=5
7.2.4. OpenID Connect용 Red Hat Single Sign-On 배포
Hybrid - OpenID Connect (OIDC)
또는 Semantic 버전 지정
샘플 파이프라인을 사용하는 경우 이 섹션의 단계를 수행하여 3scale로 RH-SSO(Red Hat Single Sign-On)를 배포합니다. 이는 두 샘플 모두에서 사용되는 OIDC 인증에 필요합니다.
절차
RH-SSO 7.3 설명서에 설명된 대로 RH-SSO 7.3을 배포합니다.
다음 예제 명령은 간단한 요약을 제공합니다.
oc replace -n openshift --force -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso73-dev/templates/sso73-image-stream.json oc replace -n openshift --force -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso73-dev/templates/sso73-x509-postgresql-persistent.json oc -n openshift import-image redhat-sso73-openshift:1.0 oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default oc new-app --template=sso73-x509-postgresql-persistent --name=sso -p DB_USERNAME=sso -p SSO_ADMIN_USERNAME=admin -p DB_DATABASE=sso
나중에 사용하기 위해 RH-SSO 설치의 호스트 이름을 저장합니다.
export SSO_HOSTNAME="$(oc get route sso -o jsonpath='{.spec.host}')"
- 3scale 개발자 포털 설명서에 설명된 대로 3scale 용 RH-SSO 구성.
나중에 사용하기 위해 영역 이름, 클라이언트 ID 및 클라이언트 시크릿을 저장합니다.
export REALM=3scale export CLIENT_ID=3scale-admin export CLIENT_SECRET=123...456
7.2.5. 3scale toolbox 설치 및 액세스 활성화
이 섹션에서는 toolbox를 설치하고, 원격 3scale 인스턴스를 생성하며, 관리 포털에 액세스하는 데 사용되는 시크릿을 프로비저닝하는 방법을 설명합니다.
절차
- 3scale toolbox에 설명된 대로 3scale toolbox 를 로컬로 설치합니다.
적절한 toolbox 명령을 실행하여 3scale 원격 인스턴스를 생성합니다.
3scale 호스팅
3scale remote add 3scale-saas "https://$SAAS_ACCESS_TOKEN@$SAAS_TENANT-admin.3scale.net/"
3scale 온프레미스
3scale remote add 3scale-onprem "https://$ONPREM_ACCESS_TOKEN@$ONPREM_ADMIN_PORTAL_HOSTNAME/"
다음 OpenShift 명령을 실행하여 3scale 관리 포털 및 액세스 토큰이 포함된 시크릿을 프로비저닝합니다.
oc create secret generic 3scale-toolbox -n "$TOOLBOX_NAMESPACE" --from-file="$HOME/.3scalerc.yaml"
7.2.6. API 백엔드 배포
이 섹션에서는 샘플 파이프라인과 함께 제공되는 예제 API 백엔드를 배포하는 방법을 보여줍니다. 자체 파이프라인을 생성 및 배포할 때 필요에 따라 자체 API 백엔드를 교체할 수 있습니다.
절차
다음 샘플과 함께 사용할 예제 Beer Catalog API 백엔드를 배포합니다.
-
SaaS - API 키
-
하이브리드 - 오픈
하이브리드 - OIDC
oc new-app -n "$TOOLBOX_NAMESPACE" -i openshift/redhat-openjdk18-openshift:1.4 https://github.com/microcks/api-lifecycle.git --context-dir=/beer-catalog-demo/api-implementation --name=beer-catalog oc expose -n "$TOOLBOX_NAMESPACE" svc/beer-catalog
-
나중에 사용하기 위해 Beer Catalog API 호스트 이름을 저장합니다.
export BEER_CATALOG_HOSTNAME="$(oc get route -n "$TOOLBOX_NAMESPACE" beer-catalog -o jsonpath='{.spec.host}')"
다음 샘플과 함께 사용할 Red Hat Event API 백엔드 예제를 배포합니다.
-
다중 환경
의미 체계 버전
oc new-app -n "$TOOLBOX_NAMESPACE" -i openshift/nodejs:10 'https://github.com/nmasse-itix/rhte-api.git#085b015' --name=event-api oc expose -n "$TOOLBOX_NAMESPACE" svc/event-api
-
나중에 사용하기 위해 이벤트 API 호스트 이름을 저장합니다.
export EVENT_API_HOSTNAME="$(oc get route -n "$TOOLBOX_NAMESPACE" event-api -o jsonpath='{.spec.host}')"
7.2.7. 자체 관리 APIcast 인스턴스 배포
이 섹션은 3scale 호스팅 환경에서 APIcast 자체 관리 인스턴스에 사용하기 위한 것입니다. SaaS - API 키를
제외한 모든 샘플 파이프라인에 적용됩니다.
절차
와일드카드 경로를 정의합니다.
export APICAST_SELF_MANAGED_STAGING_WILDCARD_DOMAIN=saas-staging.$OPENSHIFT_ROUTER_SUFFIX export APICAST_SELF_MANAGED_PRODUCTION_WILDCARD_DOMAIN=saas-production.$OPENSHIFT_ROUTER_SUFFIX
프로젝트에 APIcast 자체 관리 인스턴스를 배포합니다.
oc create secret generic 3scale-tenant --from-literal=password=https://$SAAS_ACCESS_TOKEN@$SAAS_TENANT-admin.3scale.net oc create -f https://raw.githubusercontent.com/3scale/apicast/v3.5.0/openshift/apicast-template.yml oc new-app --template=3scale-gateway --name=apicast-staging -p CONFIGURATION_URL_SECRET=3scale-tenant -p CONFIGURATION_CACHE=0 -p RESPONSE_CODES=true -p LOG_LEVEL=info -p CONFIGURATION_LOADER=lazy -p APICAST_NAME=apicast-staging -p DEPLOYMENT_ENVIRONMENT=sandbox -p IMAGE_NAME=registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.13 oc new-app --template=3scale-gateway --name=apicast-production -p CONFIGURATION_URL_SECRET=3scale-tenant -p CONFIGURATION_CACHE=60 -p RESPONSE_CODES=true -p LOG_LEVEL=info -p CONFIGURATION_LOADER=boot -p APICAST_NAME=apicast-production -p DEPLOYMENT_ENVIRONMENT=production -p IMAGE_NAME=registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.13 oc scale dc/apicast-staging --replicas=1 oc scale dc/apicast-production --replicas=1 oc create route edge apicast-staging --service=apicast-staging --hostname="wildcard.$APICAST_SELF_MANAGED_STAGING_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain oc create route edge apicast-production --service=apicast-production --hostname="wildcard.$APICAST_SELF_MANAGED_PRODUCTION_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain
7.2.8. 샘플 파이프라인 설치 및 배포
필수 환경을 설정한 후에는 Red Hat 통합 리포지토리의 각 샘플 사용 사례에 제공된 OpenShift 템플릿을 사용하여 샘플 파이프라인을 설치하고 배포할 수 있습니다. 예를 들어 이 섹션에는 SaaS - API Key
샘플만 표시됩니다.
절차
제공된 OpenShift 템플릿을 사용하여 Jenkins 파이프라인을 설치합니다.
oc process -f saas-usecase-apikey/setup.yaml \ -p DEVELOPER_ACCOUNT_ID="$SAAS_DEVELOPER_ACCOUNT_ID" \ -p PRIVATE_BASE_URL="http://$BEER_CATALOG_HOSTNAME" \ -p NAMESPACE="$TOOLBOX_NAMESPACE" |oc create -f -
다음과 같이 샘플을 배포합니다.
oc start-build saas-usecase-apikey
7.2.9. 3scale toolbox를 사용한 API 라이프사이클 자동화의 제한 사항
이 릴리스에서는 다음과 같은 제한 사항이 적용됩니다.
- OpenShift 지원
- 샘플 파이프라인은 OpenShift 3.11에서만 지원됩니다. OpenShift 4는 현재 지원되지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale 지원 구성 페이지를 참조하십시오.
- 애플리케이션 업데이트
-
3scale 애플리케이션 apply
toolbox 명령을 사용하여 애플리케이션을 생성하고 업데이트할 수 있습니다. 지원 명령 생성 계정, 계획, 서비스 및 애플리케이션 키. - 업데이트 명령은 계정, 계획 또는 서비스의 변경 사항을 지원하지 않습니다. 변경 사항이 전달되면 파이프라인이 트리거되고 오류가 표시되지 않지만 해당 필드는 업데이트되지 않습니다.
-
- 서비스 복사
-
3scale 복사 서비스
toolbox 명령을 사용하여 사용자 지정 정책으로 서비스를 복사하는 경우 사용자 지정 정책을 먼저 별도로 복사해야 합니다. - 제품로서의 API
- 3scale 툴박스는 모든 API를 제품(APIaaP) 기능으로 지원하지 않습니다. 자세한 내용은 3scale 릴리스 노트에서 알려진 문제를 참조하십시오.
7.3. 3scale Jenkins 공유 라이브러리를 사용하여 파이프라인 생성
이 섹션에서는 3scale toolbox를 사용하는 사용자 지정 Jenkins 파이프라인을 생성하는 모범 사례를 제공합니다. 3scale Jenkins 공유 라이브러리를 사용하여 예제 애플리케이션을 기반으로 toolbox를 호출하는 방법인 Groovy에서 Jenkins 파이프라인을 작성하는 방법을 설명합니다. 자세한 내용은 Jenkins 공유 라이브러리를 참조하십시오.
Red Hat은 Red Hat 통합 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.
이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 대해 생성한 사용자 지정 파이프라인은 지원되지 않습니다.
사전 요구 사항
- 샘플 Jenkins CI/CD 파이프라인 배포.
- API에 대한 OpenAPI 사양 파일이 있어야 합니다. 예를 들어 Apicurio Studio 를 사용하여 생성할 수 있습니다.
절차
Jenkins 파이프라인 시작 부분에 다음을 추가하여 파이프라인에서 3scale 공유 라이브러리를 참조합니다.
#!groovy library identifier: '3scale-toolbox-jenkins@master', retriever: modernSCM([$class: 'GitSCMSource', remote: 'https://github.com/rh-integration/3scale-toolbox-jenkins.git'])
3-
scaleService 오브젝트를 보유
하도록 글로벌 변수를 선언하여 파이프라인의 여러 단계에서 사용할 수 있습니다.def service = null
모든 관련 정보를 사용하여 three
scaleService
를 만듭니다.stage("Prepare") { service = toolbox.prepareThreescaleService( openapi: [ filename: "swagger.json" ], environment: [ baseSystemName: "my_service" ], toolbox: [ openshiftProject: "toolbox", destination: "3scale-tenant", secretName: "3scale-toolbox" ], service: [:], applications: [ [ name: "my-test-app", description: "This is used for tests", plan: "test", account: "<CHANGE_ME>" ] ], applicationPlans: [ [ systemName: "test", name: "Test", defaultPlan: true, published: true ], [ systemName: "silver", name: "Silver" ], [ artefactFile: "https://raw.githubusercontent.com/my_username/API-Lifecycle-Mockup/master/testcase-01/plan.yaml"], ] ) echo "toolbox version = " + service.toolbox.getToolboxVersion() }
-
OpenAPI.filename
은 OpenAPI 사양을 포함하는 파일의 경로입니다. -
environment.baseSystemName
은environment.environmentName 및 OpenAPI 사양
의 API 주 버전을 기반으로 최종info.
versionsystem_name
을 계산하는 데 사용됩니다. -
toolbox.openshiftProject
는 Kubernetes 작업이 생성될 OpenShift 프로젝트입니다. -
toolbox.secretName
은 3scale toolbox 설치 및 액세스를 활성화하는 데 표시된 대로 3scale toolbox 구성 파일이 포함된 Kubernetes 시크릿의 이름입니다. -
toolbox.destination
은 3scale toolbox 원격 인스턴스의 이름입니다. -
applicationPlans
는.yaml
파일을 사용하거나 애플리케이션 계획 속성 세부 정보를 제공하여 생성할 애플리케이션 계획 목록입니다.
-
3scale에서 서비스를 프로비저닝하는 파이프라인 단계를 추가합니다.
stage("Import OpenAPI") { service.importOpenAPI() echo "Service with system_name ${service.environment.targetSystemName} created !" }
애플리케이션 계획을 생성하는 단계를 추가합니다.
stage("Create an Application Plan") { service.applyApplicationPlans() }
글로벌 변수와 단계를 추가하여 테스트 애플리케이션을 생성합니다.
stage("Create an Application") { service.applyApplication() }
통합 테스트를 실행하는 단계를 추가합니다. APIcast 호스팅 인스턴스를 사용하는 경우 프록시 정의를 가져와 스테이징 공용 URL을 추출해야 합니다.
stage("Run integration tests") { def proxy = service.readProxy("sandbox") sh """set -e +x curl -f -w "ListBeers: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer -H 'api-key: ${service.applications[0].userkey}' curl -f -w "GetBeer: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer/Weissbier -H 'api-key: ${service.applications[0].userkey}' curl -f -w "FindBeersByStatus: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer/findByStatus/ available -H 'api-key: ${service.applications[0].userkey}' """ }
API를 프로덕션으로 승격하는 단계를 추가합니다.
stage("Promote to production") { service.promoteToProduction() }
7.4. Jenkinsfile을 사용하여 파이프라인 생성
이 섹션에서는 3scale 툴박스를 사용하는 Groovy에서 처음부터 사용자 지정 Jenkinsfile
을 작성하는 모범 사례를 제공합니다.
Red Hat은 Red Hat 통합 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.
이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 대해 생성한 사용자 지정 파이프라인은 지원되지 않습니다. 이 섹션은 참조용으로만 제공됩니다.
사전 요구 사항
- 샘플 Jenkins CI/CD 파이프라인 배포.
- API에 대한 OpenAPI 사양 파일이 있어야 합니다. 예를 들어 Apicurio Studio 를 사용하여 생성할 수 있습니다.
절차
3scale toolbox를 호출하는 유틸리티 함수를 작성합니다. 다음은 3scale toolbox를 실행하는 Kubernetes 작업을 생성합니다.
#!groovy def runToolbox(args) { def kubernetesJob = [ "apiVersion": "batch/v1", "kind": "Job", "metadata": [ "name": "toolbox" ], "spec": [ "backoffLimit": 0, "activeDeadlineSeconds": 300, "template": [ "spec": [ "restartPolicy": "Never", "containers": [ [ "name": "job", "image": "registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.13", "imagePullPolicy": "Always", "args": [ "3scale", "version" ], "env": [ [ "name": "HOME", "value": "/config" ] ], "volumeMounts": [ [ "mountPath": "/config", "name": "toolbox-config" ], [ "mountPath": "/artifacts", "name": "artifacts" ] ] ] ], "volumes": [ [ "name": "toolbox-config", "secret": [ "secretName": "3scale-toolbox" ] ], [ "name": "artifacts", "configMap": [ "name": "openapi" ] ] ] ] ] ] ] kubernetesJob.spec.template.spec.containers[0].args = args sh "rm -f -- job.yaml" writeYaml file: "job.yaml", data: kubernetesJob sh """set -e oc delete job toolbox --ignore-not-found sleep 2 oc create -f job.yaml sleep 20 # Adjust the sleep duration to your server velocity """ def logs = sh(script: "set -e; oc logs -f job/toolbox", returnStdout: true) echo logs return logs }
Kubernetes 오브젝트 템플릿
이 기능은 Kubernetes 오브젝트 템플릿을 사용하여 3scale toolbox를 실행하여 필요에 맞게 조정할 수 있습니다. 3scale toolbox CLI 인수를 설정하고 결과 Kubernetes 작업 정의를 YAML 파일에 쓰고, toolbox의 이전 실행을 정리하고, Kubernetes 작업을 생성하고, 대기합니다.
-
Created
와Running
상태 간에 포드를 전환해야 하는 시간과 일치하도록 서버 속도에 맞게 대기 기간을 조정할 수 있습니다. 폴링 루프를 사용하여 이 단계를 구체화할 수 있습니다. -
OpenAPI 사양 파일은
openapi라는
.ConfigMap
에서 가져옵니다 -
3scale 관리 포털 호스트 이름 및 액세스 토큰은
3scale-toolbox
설치 및 액세스 활성화에 표시된 대로 3scale-toolbox라는 시크릿에서 가져옵니다. -
ConfigMap
은 파이프라인에서 3단계에서 생성됩니다. 그러나 보안은 이미 파이프라인 외부에 프로비저닝되었으며 보안을 강화하기 위해 RBAC(역할 기반 액세스 제어)가 적용됩니다.
-
Jenkins 파이프라인 단계에서 3scale toolbox와 함께 사용할 글로벌 환경 변수를 정의합니다. 예를 들면 다음과 같습니다.
3scale 호스팅
def targetSystemName = "saas-apikey-usecase" def targetInstance = "3scale-saas" def privateBaseURL = "http://echo-api.3scale.net" def testUserKey = "abcdef1234567890" def developerAccountId = "john"
3scale 온프레미스
자체 관리 APIcast를 사용하거나 3scale의 온프레미스 설치를 사용하는 경우 다음 두 가지 변수를 선언해야 합니다.
def publicStagingBaseURL = "http://my-staging-api.example.test" def publicProductionBaseURL = "http://my-production-api.example.test"
변수는 다음과 같이 설명됩니다.
-
targetSystemName
: 생성할 서비스의 이름입니다. -
targetInstance
: 이는 3scale 툴박스 설치 및 액세스를 활성화하는 데 생성된 3scale 원격 인스턴스의 이름과 일치합니다. -
privateBaseURL
: API 백엔드의 엔드포인트 호스트입니다. -
testUserKey
: 통합 테스트를 실행하는 데 사용되는 사용자 API 키입니다. 표시된 대로 하드 코딩하거나 HMAC 함수에서 생성할 수 있습니다. -
developerAccountId
: 테스트 애플리케이션이 생성될 대상 계정의 ID입니다. -
publicStagingBaseURL
: 생성할 서비스의 공개 스테이징 기반 URL입니다. -
publicProductionBaseURL
: 생성할 서비스의 공개 프로덕션 기본 URL입니다.
-
파이프라인 단계를 추가하여 OpenAPI 사양 파일을 가져와 다음과 같이 OpenShift에서
ConfigMap
으로 프로비저닝합니다.node() { stage("Fetch OpenAPI") { sh """set -e curl -sfk -o swagger.json https://raw.githubusercontent.com/microcks/api-lifecycle/master/beer-catalog-demo/api-contracts/beer-catalog-api-swagger.json oc delete configmap openapi --ignore-not-found oc create configmap openapi --from-file="swagger.json" """ }
3scale 툴박스를 사용하여 API를 3scale로 가져오는 파이프라인 단계를 추가합니다.
3scale 호스팅
stage("Import OpenAPI") { runToolbox([ "3scale", "import", "openapi", "-d", targetInstance, "/artifacts/swagger.json", "--override-private-base-url=${privateBaseURL}", "-t", targetSystemName ]) }
3scale 온프레미스
자체 관리 APIcast를 사용하거나 3scale의 온프레미스 설치를 사용하는 경우 공용 스테이징 및 프로덕션 기반 URL에 대한 옵션도 지정해야 합니다.
stage("Import OpenAPI") { runToolbox([ "3scale", "import", "openapi", "-d", targetInstance, "/artifacts/swagger.json", "--override-private-base-url=${privateBaseURL}", "-t", targetSystemName, "--production-public-base-url=${publicProductionBaseURL}", "--staging-public-base-url=${publicStagingBaseURL}" ]) }
toolbox를 사용하여 3scale 애플리케이션 계획 및 애플리케이션을 생성하는 파이프라인 단계를 추가합니다.
stage("Create an Application Plan") { runToolbox([ "3scale", "application-plan", "apply", targetInstance, targetSystemName, "test", "-n", "Test Plan", "--default" ]) } stage("Create an Application") { runToolbox([ "3scale", "application", "apply", targetInstance, testUserKey, "--account=${developerAccountId}", "--name=Test Application", "--description=Created by Jenkins", "--plan=test", "--service=${targetSystemName}" ]) }
stage("Run integration tests") { def proxyDefinition = runToolbox([ "3scale", "proxy", "show", targetInstance, targetSystemName, "sandbox" ]) def proxy = readJSON text: proxyDefinition proxy = proxy.content.proxy sh """set -e echo "Public Staging Base URL is ${proxy.sandbox_endpoint}" echo "userkey is ${testUserKey}" curl -vfk ${proxy.sandbox_endpoint}/beer -H 'api-key: ${testUserKey}' curl -vfk ${proxy.sandbox_endpoint}/beer/Weissbier -H 'api-key: ${testUserKey}' curl -vfk ${proxy.sandbox_endpoint}/beer/findByStatus/available -H 'api-key: ${testUserKey}' """ }
toolbox를 사용하여 API를 프로덕션 환경으로 승격하는 단계를 추가합니다.
stage("Promote to production") { runToolbox([ "3scale", "proxy", "promote", targetInstance, targetSystemName ]) }
8장. 3scale 연산자를 사용하여 3scale 구성 및 프로비저닝
3scale 관리자는 3scale 연산자를 사용하여 3scale 서비스를 구성하고 3scale 리소스를 프로비저닝할 수 있습니다. OCP(OpenShift Container Platform) 사용자 인터페이스에서 Operator를 사용합니다. 운영자를 사용하는 것은 관리 포털에서 또는 3scale 내부 API를 사용하여 3scale을 구성하고 프로비저닝하는 대안입니다.
3scale 운영자를 사용하여 서비스를 구성하거나 리소스를 프로비저닝하는 경우 해당 서비스 또는 리소스를 업데이트하는 유일한 방법은 CR(사용자 정의 리소스)을 업데이트하는 것입니다. 관리 포털에 새 서비스와 리소스가 표시되는 경우 관리 포털에서 또는 내부 3scale API를 사용하여 서비스 또는 리소스를 업데이트할 수 없습니다. 를 시도하면 Operator가 업데이트를 되돌리고 CR은 그대로 유지됩니다.
기능을 위한 3scale 연산자는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
이 장에서는 운영자 애플리케이션 기능이 작동하는 방법과 사용자 정의 리소스를 배포하는 Operator를 사용하는 방법에 대해 자세히 설명합니다.
또한 3scale 연산자를 사용할 때의 기능 제한에 대한 정보가 있습니다.
8.1. 일반 사전 요구 사항
3scale 연산자를 사용하여 3scale을 구성하고 프로비저닝하는 데 필요한 요소는 다음과 같습니다.
OpenShift 클러스터에서 관리자 권한이 있는 사용자 계정이 있는 OpenShift Container Platform 4
- 참고: OCP 4에서는 운영자만 사용하는 3scale 배포를 지원합니다.
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale 지원 구성 페이지를 참조하십시오.
8.2. 3scale Operator를 통한 애플리케이션 기능
3scale Operator에는 다음과 같은 기능이 포함되어 있습니다.
- 기본 Red Hat 3scale 솔루션과 상호 작용 가능.
- OpenShift의 사용자 지정 리소스를 사용하여 3scale 애플리케이션을 선언적으로 관리합니다.
아래 다이어그램은 선언적 방식으로 OpenShift 사용자 지정 리소스를 사용하여 관리가 가능한 3scale 엔터티 및 관계를 보여줍니다. 제품에는 하나 이상의 백엔드가 포함됩니다. 제품 수준에서는 애플리케이션, 애플리케이션 계획 및 매핑 규칙을 구성할 수 있습니다. 백엔드 수준에서 각 백엔드에 대한 지표, 메서드 및 매핑 규칙을 설정할 수 있습니다.

3scale 연산자는 다음 다이어그램에 표시되는 사용자 지정 리소스 정의 및 관계를 제공합니다.

8.3. 첫 번째 3scale 제품 및 백엔드 배포
새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 필요한 최소 구성으로 첫 3scale 제품 및 백엔드를 배포합니다.
사전 요구 사항
일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항과 다음 사항을 고려합니다.
- 3scale 계정은 작동하는 OpenShift 네임스페이스 또는 원격 설치에서 로컬이 될 수 있습니다.
- 이 계정의 필수 매개 변수는 3scale 관리 URL 주소와 액세스 토큰입니다.
절차
3scale 관리 포털의 자격 증명을 사용하여 3scale 프로바이더 계정의 시크릿을 생성합니다. 예:
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
업스트림 API URL을 사용하여 3scale 백엔드를 구성합니다.
다음 콘텐츠를 사용하여 YAML 파일을 생성합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend1 spec: name: "Operated Backend 1" systemName: "backend1" privateBaseURL: "https://api.example.com"
- 파일을 만들고 나면 운영자가 해당 단계가 성공했는지 확인합니다.
- 백엔드 사용자 정의 리소스 및 가능한 값의 필드에 대한 자세한 내용은 백엔드 CRD 참조를 참조하십시오.
사용자 정의 리소스를 생성합니다.
oc create -f backend1.yaml
3scale 제품을 구성합니다.
이전에 생성한 백엔드에 적용된 모든 기본 설정으로 제품을 생성합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" systemName: "operatedproduct1" backendUsages: backend1: path: /
- 파일을 만들고 나면 운영자가 해당 단계가 성공했는지 확인합니다.
- Product 사용자 정의 리소스 및 가능한 값의 필드에 대한 자세한 내용은 Product CRD 참조를 참조하십시오.
사용자 정의 리소스를 생성합니다.
oc create -f product1.yaml
생성된 사용자 지정 리소스는 3scale 인스턴스를 채우는 데 몇 초가 걸립니다. 리소스가 동기화되는 경우 다음 대안 중 하나를 선택할 수 있습니다.
- 오브젝트의 status 필드를 확인합니다.
oc wait
명령을 사용합니다.oc wait --for=condition=Synced --timeout=-1s backend/backend1 oc wait --for=condition=Synced --timeout=-1s product/product1
8.4. 제품의 APIcast 구성 승격
3scale Operator를 사용하여 제품의 APIcast 구성을 스테이징 또는 프로덕션으로 승격할 수 있습니다. ProxyConfigPromote
사용자 정의 리소스(CR)는 최신 APIcast 구성을 스테이징 환경으로 승격합니다. 필요한 경우 production 환경으로 승격하도록 ProxyConfigPromote
CR을 구성할 수 있습니다.
ProxyConfigPromote
오브젝트는 생성 시에만 적용됩니다. 생성 후에는 해당 업데이트가 조정되지 않습니다.
사전 요구 사항
다음을 포함하여 일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항:
- 제품 CR 이 이미 생성되어 있어야 합니다.
절차
다음 콘텐츠를 사용하여 YAML 파일을 생성하고 저장합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: ProxyConfigPromote metadata: name: proxyconfigpromote-sample spec: productCRName: product1-sample
APIcast 구성을 프로덕션 환경으로 승격하려면 선택적 필드
spec.production
을true
로 설정합니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ProxyConfigPromote metadata: name: proxyconfigpromote-sample spec: productCRName: product1-sample production: true
승격 후
ProxyConfigPromote 오브젝트
를 삭제하려면 선택적 필드spec.deleteCR
을true
로 설정합니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ProxyConfigPromote metadata: name: proxyconfigpromote-sample spec: productCRName: product1-sample deleteCR: true
파일의 상태 조건을 확인하려면 다음 명령을 입력합니다.
oc get proxyconfigpromote proxyconfigpromote-sample -o yaml
satus가
Ready
임을 출력에 표시됩니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ProxyConfigPromote metadata: name: proxyconfigpromote-sample spec: productCRName: product1-sample status: conditions: - lastTransitionTime: "2022-10-28T11:35:19Z" status: "True" type: Ready
사용자 정의 리소스를 생성합니다.
oc create -f proxyconfigpromote-sample.yaml
주어진 예에서 출력은 다음과 같습니다.
proxyconfigpromote.capabilities.3scale.net/proxyconfigpromote-sample created
추가 리소스
8.5. 3scale Operator가 사용자 정의 리소스가 연결되는 테넌트를 식별하는 방법
3scale CR(사용자 정의 리소스)을 배포하여 다양한 3scale 오브젝트를 관리할 수 있습니다. 3scale CR은 정확히 하나의 테넌트에 연결됩니다.
3scale CR로 연결되는 테넌트를 식별하려면 다음 중 하나를 수행할 수 있습니다.
3scale CR이 포함된 네임스페이스에
threescale-provider-account
보안을 생성합니다. 3scale CR을 배포할 때 Operator는 이 시크릿을 읽고 CR이 연결되는 테넌트를 식별합니다. Operator가 이 시크릿을 사용하려면 다음 중 하나가 true여야 합니다.-
3scale CR은
spec.providerAccountRef
필드를 null로 지정합니다. 3scale CR은
spec.providerAccountRef
필드를 생략합니다.threescale-provider-account
시크릿은 CR이 연결되는 테넌트를 식별합니다. 시크릿에는 토큰 형태로 해당 3scale 인스턴스에서 테넌트에 액세스하기 위한 URL 및 인증 정보 형태로 3scale 인스턴스에 대한 참조가 포함되어야 합니다. 예를 들면 다음과 같습니다.oc create secret generic threescale-provider-account --from-literal=adminURL=https://3scale-admin.example.com --from-literal=token=123456
3scale-provider-account
시크릿은 HTTP 연결을 사용할 수 있는 한 3scale 인스턴스에서 테넌트를 식별할 수 있습니다. 즉, CR을 연결하는 테넌트가 다른 네임스페이스에 있거나 다른 OpenShift 클러스터에 있을 수 있는 테넌트가 포함된 3scale CR 및 3scale 인스턴스입니다.
-
3scale CR은
3scale CR에서
spec.providerAccountRef
를 지정하고 로컬 참조의 이름으로 테넌트를 식별하는 OpenShiftSecret
으로 설정합니다. 다음 3scaleDeveloperAccount
CR 예제에서mytenant
는 시크릿입니다.apiVersion: capabilities.3scale.net/v1beta1 kind: DeveloperAccount metadata: name: developeraccount-simple-sample spec: orgName: Ecorp providerAccountRef: name: mytenant
시크릿에서 다음을 수행합니다.
-
adminURL
은 네임스페이스에 있을 수 있는 3scale 인스턴스의 URL을 지정합니다. 토큰
은 해당 3scale 인스턴스에서 테넌트에 액세스할 수 있는 자격 증명을 지정합니다.예를 들면 다음과 같습니다.
apiVersion: v1 kind: Secret metadata: name: mytenant type: Opaque stringData: adminURL: https://my3scale-admin.example.com:443 token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-
3scale Operator가 CR 링크하는 테넌트를 식별할 수 없는 경우 Operator에서 오류 메시지를 생성합니다.
8.6. 3scale OpenAPI 사용자 정의 리소스 배포
OpenAPI
CR(사용자 정의 리소스)은 개발자 포털의 ActiveDocs에 사용할 수 있는 OAS(OpenAPI 사양) 문서를 가져오는 한 가지 방법입니다. OAS는 API에 특정 프로그래밍 언어를 사용하지 않는 표준입니다. 사용자와 컴퓨터는 소스 코드 액세스, 문서 또는 네트워크 트래픽 검사 없이 API 제품의 기능을 더 쉽게 이해할 수 있습니다.
사전 요구 사항
- 3scale 2saas On-Premises 인스턴스에 대한 관리자 권한이 있는 사용자 계정입니다.
- API를 정의하는 OAS 문서입니다.
-
OpenAPI
CR을 테넌트에 연결하는 방법에 대한 이해.
8.6.1. 시크릿에서 OAS 문서를 가져오는 3scale OpenAPI 사용자 정의 리소스 배포
3scale 백엔드 및 제품을 만들 수 있도록 OpenAPI
CR(사용자 정의 리소스)을 배포합니다.
운영자는 시크릿의 콘텐츠만 읽습니다. Operator는 시크릿에서 필드 이름을 읽지 않습니다.
사전 요구 사항
OpenAPI CRD를 포함할 네임스페이스에는
OpenAPI
CRD가연결되는
테넌트를 식별하는 보안이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
절차
OAS 문서가 포함된 시크릿을 정의합니다. 예를 들어 이 콘텐츠를 사용하여
myoasdoc1.yaml
을 생성할 수 있습니다.openapi: "3.0.2" info: title: "some title" description: "some description" version: "1.0.0" paths: /pet: get: operationId: "getPet" responses: 405: description: "invalid input"
시크릿을 생성합니다. 예를 들면 다음과 같습니다.
$ oc create secret generic myoasdoc1 --from-file myoasdoc1.yaml secret/myoasdoc1 created
OpenAPI
CR을 정의합니다. OAS 문서가 포함된 보안에 대한 참조를 지정해야 합니다. 예를 들어myopenapicr1.yaml 파일을 생성할 수 있습니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: OpenAPI metadata: name: myopenapicr1 spec: openapiRef: secretRef: name: myoasdoc1
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
$ oc create -f myopenapicr1.yaml
주어진 예에서 출력은 다음과 같습니다.
openapi.capabilities.3scale.net/myopenapicr1 created
8.6.2. 3scale OpenAPI 사용자 정의 리소스 정의의 기능
OpenAPI
CRD(사용자 정의 리소스 정의) 배포 기능에 대한 지식은 3scale 제품, 백엔드 및 후속 개발자 포털을 위한 ActiveDocs를 구성하는 데 도움이 됩니다.
OAS 문서는 다음에서 읽을 수 있습니다.
- Kubernetes 시크릿
- http 및 https 형식의 URL
-
OAS 문서의
info.title
설정은 215자를 초과해서는 안 됩니다. Operator는 이 설정을 사용하여 길이 제한이 있는 OpenShift 개체 이름을 생성합니다. -
서버 목록의 첫 번째
servers[0].url
요소만 프라이빗 URL로 구문 분석됩니다. OAS(OpenAPI Specification)는servers[0].url
요소의basePath
구성 요소를 사용합니다. -
OpenAPI
CRD는 단일 최상위 수준의 보안 요구 사항을 지원하지만 운영 수준 보안을 지원하지 않습니다. -
OpenAPI
CRD는apiKey
보안 스키마를 지원합니다.
8.6.3. OpenAPI 사용자 정의 리소스를 정의할 때 규칙 가져오기
가져오기 규칙은 3scale 배포에 대한 OpenAPI 문서를 설정할 때 OAS(OpenAPI Specification)가 3scale에서 작동하는 방식을 지정합니다.
제품 이름
기본 제품 시스템 이름은 OpenAPI 문서의 info.title
필드에서 가져옵니다. OpenAPI 문서의 제품 이름을 재정의하려면 OpenAPI CR(사용자 정의
리소스)에서 spec.productSystemName
필드를 지정합니다.
개인 기본 URL
개인 기본 URL은 OpenAPI
CR servers[0].url
필드에서 읽습니다. OpenAPI
CR의 spec.privateBaseURL
필드를 사용하여 이 작업을 덮어쓸 수 있습니다.
3scale 방법
가져온 OpenAPI 문서에 정의된 각 작업은 제품 수준에서 하나의 3scale 메서드로 변환됩니다. 메서드 이름은 작업 오브젝트의 operationId
필드에서 읽습니다.
3scale 매핑 규칙
가져온 OpenAPI 문서에 정의된 각 작업은 제품 수준에서 하나의 3scale 매핑 규칙으로 변환됩니다. 이전의 기존 매핑 규칙은 OpenAPI
CR로 가져온 규칙으로 대체되었습니다.
OpenAPI 문서에서 paths
오브젝트는 동사 및 패턴 속성에 대한 매핑 규칙을 제공합니다. 3scale 메서드는 이에 따라 operationId
에 연결됩니다.
delta 값은 1
로 하드 코딩됩니다.
기본적으로 Strict 일치하는 정책이 구성됩니다. OpenAPI
CRD의 spec.PrefixMatching
필드를 사용하여 일치 정책을 Prefix 일치 로 전환할 수 있습니다.
인증
최상위 수준의 보안 요구 사항이 하나만 지원됩니다. 운영 수준 보안 요구 사항은 지원되지 않습니다.
지원되는 보안 스키마는 apiKey
입니다.
apiKey
보안 스키마 유형:
-
자격 증명 위치는 보안 체계 오브젝트 필드의 OpenAPI
문서에서
읽습니다. -
인증 사용자 키는 보안 스키마 개체의 OpenAPI 문서
이름
필드에서 읽습니다.
다음은 apiKey
보안 요구 사항이 있는 OAS 3.0.2의 일부 예입니다.
openapi: "3.0.2" security: - petstore_api_key: [] components: securitySchemes: petstore_api_key: type: apiKey name: api_key in: header
OpenAPI 문서가 보안 요구 사항을 지정하지 않으면 다음 사항이 적용됩니다.
-
제품 인증은
apiKey
에 대해 구성됩니다. -
자격 증명 위치는
쿼리 매개 변수(GET) 또는 본문 매개 변수(POST/PUT/DELETE)
로 기본 설정됩니다. -
Auth 사용자 키의 기본값은 3scale 값
user_key
입니다.
3scale 인증 보안은 spec.privateAPIHostHeader
및 OpenAPI
CRD의 spec.privateAPISecretToken
필드를 사용하여 설정할 수 있습니다.
ActiveDocs
3scale ActiveDoc이 생성되지 않습니다.
3scale 제품 정책 체인
3scale 정책 체인은 3scale이 생성하는 기본 정책 체인입니다.
3scale 배포 모드
기본적으로 구성된 3scale 배포 모드는 APIcast 3scale이 관리됩니다. 그러나 spec.productionPublicBaseURL
또는 spec.stagingPublicBaseURL
또는 두 필드가 OpenAPI
CR에 있는 경우 제품의 배포 모드는 APIcast 자체 관리입니다.
사용자 정의 공개 기본 URL이 있는 OpenAPI
CR의 예:
apiVersion: capabilities.3scale.net/v1beta1 kind: OpenAPI metadata: name: openapi1 spec: openapiRef: url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml" productionPublicBaseURL: "https://production.my-gateway.example.com" stagingPublicBaseURL: "https://staging.my-gateway.example.com"
8.6.4. URL에서 OAS 문서를 가져오는 3scale OpenAPI 사용자 정의 리소스 배포
사용자가 지정한 URL에서 OAS 문서를 가져오는 OpenAPI
사용자 지정 리소스를 배포할 수 있습니다. 그런 다음 이 OAS 문서를 개발자 포털에서 API의 ActiveDocs의 기반으로 사용할 수 있습니다.
사전 요구 사항
OpenAPI CR을 포함할 네임스페이스에는
OpenAPI
CR이연결되는
테넌트를 식별하는 보안이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
절차
- OpenShift 계정에서 Operator > 설치된 운영자로 이동합니다.
- 3scale 연산자를 클릭합니다.
- YAML 탭을 선택합니다.
OpenAPI
사용자 지정 리소스를 만듭니다. 예를 들면 다음과 같습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: OpenAPI metadata: name: openapi1 spec: openapiRef: url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml" providerAccountRef: name: mytenant
-
저장을 클릭합니다. 3scale Operator가
OpenAPI
CR을 생성하는 데 몇 초가 걸립니다.
검증
-
OpenShift에서 3scale Product Overview (제품 개요) 페이지에서 Synced 조건이
True
로 표시되는지 확인합니다. - 3scale 계정으로 이동합니다.
-
OAS 문서가 있는지 확인합니다. 위의 예에서는
openapi1
이라는 새 OAS 문서가 표시됩니다.
8.6.5. 추가 리소스
8.7. 3scale ActiveDoc 사용자 정의 리소스 배포
Red Hat 3scale ActiveDocs는 OpenAPI 사양을 준수하는 RESTful 웹 서비스를 정의하는 API 정의 문서를 기반으로 합니다. CR( ActiveDoc
사용자 정의 리소스)은 개발자 포털의 ActiveDocs에 사용할 수 있는 OAS(OpenAPI Specification) 문서를 가져오는 한 가지 방법입니다. OAS는 API에 특정 프로그래밍 언어를 사용하지 않는 표준입니다. 사용자와 컴퓨터는 소스 코드 액세스, 문서 또는 네트워크 트래픽 검사 없이 API 제품의 기능을 더 쉽게 이해할 수 있습니다.
사전 요구 사항
- 3scale 2saas On-Premises 인스턴스에 대한 관리자 권한이 있는 사용자 계정입니다.
- API를 정의하는 OAS 문서입니다.
-
ActiveDoc
CR이 테넌트에 연결하는 방법에 대한 이해
8.7.1. 시크릿에서 OAS 문서를 가져오는 3scale ActiveDoc 사용자 정의 리소스 배포
3scale 백엔드 및 제품을 생성할 수 있도록 ActiveDoc
CR(사용자 정의 리소스)을 배포합니다.
운영자는 시크릿의 콘텐츠만 읽습니다. Operator는 시크릿에서 필드 이름을 읽지 않습니다. 예를 들어 데이터는 key: 값
쌍으로 구조화됩니다. 여기서 value
쌍은 파일의 내용을 나타내고 key
는 파일 이름입니다. 이 ActiveDoc CRD의 이 컨텍스트에서 Operator는 파일 이름을 무시합니다. Operator는 파일의 콘텐츠만 읽습니다.
사전 요구 사항
ActiveDoc
CRD를 포함할 네임스페이스에는ActiveDoc
CRD가 연결되는 테넌트를 식별하는 시크릿이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
OAS(OpenAPI 사양) 문서가 포함된 시크릿을 정의합니다. 예를 들어 이 콘텐츠를 사용하여
myoasdoc1.yaml
을 생성할 수 있습니다.openapi: "3.0.2" info: title: "some title" description: "some description" version: "1.0.0" paths: /pet: get: operationId: "getPet" responses: 405: description: "invalid input"
절차
시크릿을 생성합니다. 예를 들면 다음과 같습니다.
$ oc create secret generic myoasdoc1 --from-file myoasdoc1.yaml secret/myoasdoc1 created
ActiveDoc
CR을 정의합니다. OAS 문서가 포함된 보안에 대한 참조를 지정해야 합니다. 예를 들어myactivedoccr1.yaml
파일을 생성할 수 있습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ActiveDoc metadata: name: myactivedoccr1 spec: name: "Operated ActiveDoc From secret" activeDocOpenAPIRef: secretRef: name: myoasdoc1
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
$ oc create -f myactivedoccr1.yaml
주어진 예에서 출력은 다음과 같습니다.
activedoc.capabilities.3scale.net/myactivedoccr1 created
검증
- Red Hat OpenShift Container Platform (OCP) 관리자 계정에 로그인합니다.
- Operators > 설치된 Operators 로 이동합니다.
- Red Hat Integration - 3scale 을 클릭합니다.
- Active Doc 탭을 클릭합니다.
-
OAS 문서가 있는지 확인합니다. 위의 예제에서는
myactivedoccr1
이라는 새로운 OAS 문서가 표시됩니다.
8.7.2. 3scale ActiveDoc 사용자 정의 리소스 정의 기능
ActiveDoc
CRD(사용자 정의 리소스 정의)는 개발자를 위한 OpenAPI
문서 형식의 제품 문서에 관한 것입니다. ActiveDoc
CRD 배포 기능에 대한 지식이 있으면 개발자 포털용 ActiveDocs를 생성할 수 있습니다.
ActiveDoc
CR은 다음 중 하나에서 읽고 OpenAPI 문서를 사용할 수 있습니다.- Secret
-
http
또는https
형식의 URL
-
선택적으로
productSystemName
필드를 사용하여ActiveDoc
CR을 3scale 제품에 연결할 수 있습니다. 값은 3scale 제품 CR의system_name
이어야 합니다. -
게시된
필드를 사용하여 3scale에서ActiveDoc
문서를 게시하거나 숨길 수 있습니다. 기본적으로 이 값은숨겨
집니다. -
skipSwaggerValidations
필드를 사용하여 OpenAPI 3.0 검증을 건너뛸 수 있습니다. 기본적으로ActiveDoc
CR이 검증됩니다.
8.7.3. URL에서 OAS 문서를 가져오는 3scale ActiveDoc 사용자 정의 리소스 배포
지정하는 URL에서 OAS(OpenAPI Specification) 문서를 가져오는 ActiveDoc
CR(사용자 정의 리소스)을 배포할 수 있습니다. 그런 다음 이 OAS 문서를 개발자 포털에서 API의 ActiveDocs의 기반으로 사용할 수 있습니다.
사전 요구 사항
ActiveDoc
CR이 포함된 네임스페이스에는ActiveDoc
CR이 연결되는 테넌트를 식별하는 시크릿이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
절차
- OpenShift 계정에서 Operator > 설치된 운영자로 이동합니다.
- 3scale 연산자를 클릭합니다.
- Active Doc 탭을 클릭합니다.
ActiveDoc
CR을 생성합니다. 예를 들면 다음과 같습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ActiveDoc metadata: name: myactivedoccr1 spec: openapiRef: url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml" providerAccountRef: name: mytenant
선택 사항: 자체 관리형 APIcast의 경우
ActiveDoc
CR에서productionPublicBaseURL
및stagingPublicBaseURL
필드를 배포 URL로 설정합니다. 예를 들면 다음과 같습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: ActiveDoc metadata: name: myactivedoccr1 spec: openapiRef: url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml" productionPublicBaseURL: "https://production.my-gateway.example.com" stagingPublicBaseURL: "https://staging.my-gateway.example.com"
-
저장을 클릭합니다. 3scale Operator가
ActiveDoc
CR을 생성하는 데 몇 초가 걸립니다.
검증
- Red Hat OpenShift Container Platform (OCP) 관리자 계정에 로그인합니다.
- Operators > 설치된 Operators 로 이동합니다.
- Red Hat Integration 3scale 을 클릭합니다.
- Active Doc 탭을 클릭합니다.
-
OAS 문서가 있는지 확인합니다. 위의 예제에서는
myactivedoccr1
이라는 새로운 OAS 문서가 표시됩니다.
8.7.4. 추가 리소스
8.8. 기능과 관련된 백엔드 사용자 정의 리소스
새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 백엔드, 해당 메트릭, 메서드 및 매핑 규칙을 구성합니다. 또한 백엔드 사용자 지정 리소스의 상태와 백엔드가 테넌트 계정에 연결되는 방법에 대해서도 학습합니다.
사전 요구 사항
일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항 및 다음 사항을 고려합니다.
- 3scale 계정의 최소 필수 매개 변수는 관리 포털 URL 주소 및 액세스 토큰입니다.
8.8.1. 기능과 관련된 백엔드 사용자 정의 리소스 배포
새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 새 백엔드를 구성합니다.
절차
- OpenShift 계정에서 설치된 운영자 로 이동합니다.
- 3scale 연산자를 클릭합니다.
- 3scale 백엔드에서 인스턴스 생성을 클릭합니다.
- YAML View(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"
- 변경 사항을 저장하려면 Create(만들기 )를 클릭합니다.
3scale 계정과 OpenShift에서 둘 다 생성한 백엔드를 몇 초 동안 기다립니다. 그런 다음 다음 검증을 수행할 수 있습니다.
-
동기화 조건이
True
로 표시되는 3scale 백엔드 개요 페이지에서 확인하여 백엔드가 OpenShift에 생성되었는지 확인합니다. -
3scale 계정으로 이동하여 백엔드가 생성된 것을 확인할 수 있습니다. 위의 예에서
My 백엔드 이름
이라는 새 백엔드가 표시됩니다.
-
동기화 조건이
8.8.2. 백엔드 지표 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 백엔드 사용자 정의 리소스에서 원하는 백엔드 지표를 정의합니다.
다음 관찰을 고려하십시오.
-
지표
맵 키 이름은system_name
으로 사용됩니다. 아래 예제에서는metric01
,metric02
및hits
입니다. -
지표
맵의 키 이름은 모든 지표 및 방법에서 고유해야 합니다. -
단위
및friendlyName
은 필수 필드입니다. -
hits
지표를 추가하지 않으면 이 지표는 운영자가 생성합니다.
절차
다음 예와 같이 새로운 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
에 대한 참조가 있습니다. 아래 예에서,hits
.
절차
다음 예와 같이 새로운 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 백엔드의 내부 식별자입니다. 조건
:status.Conditions
Kubernetes 공통 패턴을 나타냅니다. 다음과 같은 유형이 있습니다.-
잘못된:
BackendSpec
의 구성 조합은 지원되지 않습니다. 이는 일시적인 오류는 아니지만 진행을 수행하기 전에 수정해야 하는 상태를 나타냅니다. - 동기화됨: 백엔드가 성공적으로 동기화되었습니다.
- 실패: 동기화하는 동안 오류가 발생했습니다.
-
잘못된:
-
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 및 token 필드가 있어야 합니다. 예를 들면 다음과 같습니다.
apiVersion: v1 kind: Secret metadata: name: mytenant type: Opaque stringData: adminURL: https://my3scale-admin.example.com:443 token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
기본 3scale-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
-
Backend
CR을 사용하여 유효한 테넌트에 대한 링크를 삭제합니다.
절차
oc delete
명령을 실행하여백엔드 사용자 정의
리소스를 삭제합니다. 예를 들어mybackend.yaml
파일에 정의된 백엔드를 배포한 경우 다음 명령을 실행합니다.oc delete -f mybackend.yaml
또는
oc delete
명령을 실행하고 정의에 지정된 대로 백엔드의 이름을 지정할 수 있습니다. 예를 들면 다음과 같습니다.oc delete backend.capabilities.3scale.net/mybackend
8.9. 기능과 관련된 사용자 정의 리소스
새로 생성된 테넌트에서 Openshift Container Platform을 사용하면 제품 및 해당 메트릭, 메서드, 애플리케이션 계획 및 매핑 규칙을 구성하고 제품 백엔드 사용량을 정의하고 제품을 테넌트 계정에 연결합니다.
사전 요구 사항
일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항 및 다음 사항을 고려합니다.
- 3scale 계정의 최소 필수 매개 변수는 제품 이름입니다.
8.9.1. 기능과 관련된 제품 사용자 정의 리소스 배포
새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 신제품을 구성합니다.
8.9.1.1. 기본 제품 사용자 정의 리소스 배포
절차
- OpenShift 계정에서 설치된 운영자 로 이동합니다.
- 3scale 연산자를 클릭합니다.
- 3scale Product (제품)에서 Create Instance (인스턴스 만들기)를 클릭합니다.
- YAML View(YAML 보기)를 선택합니다.
3scale 제품을 만듭니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: <your_product_OpenShift_name> spec: name: "<your_product_name>"
예를 들면 다음과 같습니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1"
- 변경 사항을 저장하려면 Create(만들기 )를 클릭합니다.
OpenShift 및 3scale 계정에서 둘 다 만든 제품이 생성될 때까지 몇 초 동안 기다립니다. 그런 다음 다음 검증을 수행할 수 있습니다.
-
동기화 조건이
True
로 표시되는 3scale Product Overview (제품 개요) 페이지에서 확인하여 제품이 OpenShift에 생성되었는지 확인합니다. -
3scale 계정으로 이동하여 제품이 생성된 것을 확인할 수 있습니다. 위의 예에서
OperatedProduct 1
이라는 신제품이 나타납니다.
-
동기화 조건이
생성하는 각 제품에 대해 APIcast 배포 모드를 지정할 수도 있습니다. 두 가지 대안이 있습니다.
8.9.1.2. 호스팅된 APIcast로 제품 배포
호스팅된 APIcast로 제품을 구성합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastHosted: {}
8.9.1.3. APIcast 자체 관리로 제품 배포
APIcast 셀프 관리로 제품 구성. 이 경우 stagingPublicBaseURL 및
을 지정합니다.
productionPublic
BaseURL
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastSelfManaged: stagingPublicBaseURL: "https://staging.api.example.com" productionPublicBaseURL: "https://production.api.example.com"
8.9.2. 제품 애플리케이션 계획 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 application Plans 오브젝트를 사용하여 제품 사용자 정의 리소스에 원하는 애플리케이션
계획을 정의합니다.
다음 관찰을 고려하십시오.
-
ApplicationPlans
맵핑 키 이름은system_name
으로 사용됩니다. 아래 예에서plan01
및plan02
.
SetupFee
및 costMonth
는 일반적인 3scale 개념입니다. 3scale 사용자 인터페이스에서 애플리케이션 계획을 생성할 때 이러한 세부 사항을 입력해야 합니다. 가격 규칙을 사용하여 애플리케이션 계획 구성을 참조하십시오.
절차
다음 예와 같이 새로운 3scale 제품에 애플리케이션 계획을 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" applicationPlans: plan01: name: "My Plan 01" setupFee: "14.56" plan02: name: "My Plan 02" trialPeriod: 3 costMonth: 3
8.9.3. 제품 애플리케이션 계획에 대한 제한 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 application Plans.limits 목록을 사용하여 제품 애플리케이션
계획에 필요한 제한을 정의합니다.
다음 관찰을 고려하십시오.
-
period
,value
및metricMethodRef
는 필수 필드입니다. -
metricMethodRef
참조는 제품 또는 백엔드 참조일 수 있습니다. 선택적backend
필드를 사용하여 백엔드 지표 소유자를 참조합니다.
절차
다음 예와 같이 3scale 제품의 애플리케이션 계획에 대한 제한을 정의합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" applicationPlans: plan01: name: "My Plan 01" limits: - period: month value: 300 metricMethodRef: systemName: hits backend: backendA - period: week value: 100 metricMethodRef: systemName: hits
8.9.4. 제품 애플리케이션 계획에 대한 가격 결정 규칙 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 application Plans.pricingRules 목록을 사용하여 제품 애플리케이션
계획에 필요한 가격 규칙을 정의합니다.
다음 관찰을 고려하십시오.
-
에서
pricePerUnit
및metricMethodRef
는 필수 필드입니다. -
에서
및에 대한
유효성을 검사합니다. 모든 규칙에 대해 의 값은~
동일한 지표의 겹치는 범위는 허용되지 않습니다.보다
작으며 -
metricMethodRef
참조는 제품 또는 백엔드 참조일 수 있습니다. 선택적backend
필드를 사용하여 백엔드 지표 소유자를 참조합니다.
절차
다음 예와 같이 3scale 제품의 애플리케이션 계획에 대한 가격 규칙을 정의합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" applicationPlans: plan01: name: "My Plan 01" pricingRules: - from: 1 to: 100 pricePerUnit: "15.45" metricMethodRef: systemName: hits - from: 1 to: 300 pricePerUnit: "15.45" metricMethodRef: systemName: hits backend: backendA
8.9.5. OpenID Connect를 사용하여 제품 인증 정의
OAuth 2.0 흐름에 대한 인증에 OIDC (OpenID Connect )를 사용하는 3scale 제품에 대한 제품
사용자 지정 리소스를 배포할 수 있습니다. 3scale은 OpenID Connect와 같은 타사 IdM(Identity Providers)과 통합되어 API 요청을 인증합니다. OpenID Connect에 대한 자세한 내용은 OpenID Connect 통합을 참조하십시오. 타사 IdP와 통합한 후 제품 사용자 정의 리소스에 포함할 두 가지 유형의 데이터를 보유하게 됩니다.
-
issuerType
: 타사 IdP와 통합할 때 Red Hat Single Sign-On(RH-SSO)과나머지
가치를 사용할 때keycloak
의 가치. -
issuerEndpoint
: 이 파일에 필요한 자격 증명이 있는 URL입니다.
사전 요구 사항
- RH-SSO를 구성해야 합니다. Red Hat Single Sign-On 구성을 참조하십시오.
- 타사 ID 프로바이더와 HTTP 통합을 구성해야 합니다.
issuerEndpoint
에 제공된 자격 증명 CLIENT_ID 및 CLIENT_CREDENTIALS 에는 영역에서 다른 클라이언트를 관리할 수 있는 충분한 권한이 있어야 합니다.
절차
OpenID 공급자의 위치를 정의하고 제품 사용자 정의 리소스에서 이 형식을 사용하는 끝점
issuerEndpoint
를 결정합니다.https://<client_id>:<client_secret>@<host>:<port_number>/auth/realms/<realm_name>`
OAuth 2.0 흐름에 대해 OIDC(OpenID Connect) 인증을 지정하는 3scale
제품
CR을 정의하거나 업데이트합니다. 예를 들면 다음과 같습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: <any>: authentication: oidc: issuerType: "keycloak" issuerEndpoint: "https://myclientid:myclientsecret@mykeycloack.example.com/auth/realms/myrealm" authenticationFlow: standardFlowEnabled: false implicitFlowEnabled: true serviceAccountsEnabled: true directAccessGrantsEnabled: true jwtClaimWithClientID: "azp" jwtClaimWithClientIDType: "plain"
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
oc create -f product1.yaml
주어진 예에서 출력은 다음과 같습니다.
product.capabilities.3scale.net/product1 created
추가 리소스
8.9.6. 제품 지표 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 지표 오브젝트를 사용하여 제품 사용자 정의 리소스에 원하는 지표를
정의합니다.
다음 관찰을 고려하십시오.
-
지표
맵 키 이름은system_name
으로 사용됩니다. 아래 예에서는metric01
및hits
입니다. -
지표
맵의 키 이름은 모든 지표 및 방법에서 고유해야 합니다. -
단위
및friendlyName
은 필수 필드입니다. -
hits
지표를 추가하지 않으면 운영자가 생성합니다.
절차
다음 예와 같이 새로운 3scale 백엔드에 제품 지표를 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: metric01: friendlyName: Metric01 unit: "1" hits: description: Number of API hits friendlyName: Hits unit: "hit"
8.9.7. 제품 방법 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 메서드
오브젝트를 사용하여 제품 사용자 정의 리소스에 원하는 방법을 정의합니다.
다음 관찰을 고려하십시오.
-
메서드
맵 키 이름은system_name
으로 사용됩니다. 아래 예제에서는 다음을 수행합니다.Method01
및Method02
. -
메서드
는 모든 지표 및 방법에서 키 이름을 매핑해야 합니다. -
friendlyName
은 필수 필드입니다.
절차
다음 예와 같이 새로운 3scale 제품에 메서드를 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" methods: method01: friendlyName: Method01 method02: friendlyName: Method02
8.9.8. 제품 매핑 규칙 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 mappingRules
오브젝트를 사용하여 제품 사용자 정의 리소스에 원하는 매핑 규칙을 정의합니다.
다음 관찰을 고려하십시오.
-
httpMethod
,패턴
,increment
및metricMethodRef
는 필수 필드입니다. -
metricMethodRef
에는 기존 지표 또는 메서드 맵 키 이름system_name
에 대한 참조가 있습니다. 아래 예에서,hits
.
절차
다음 예와 같이 새로운 3scale 백엔드에 제품 매핑 규칙을 추가합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" methods: method01: friendlyName: Method01 mappingRules: - httpMethod: GET pattern: "/pets" increment: 1 metricMethodRef: hits - httpMethod: GET pattern: "/cars" increment: 1 metricMethodRef: method01
8.9.9. 제품 백엔드 사용 정의
새로 생성된 3scale 테넌트와 함께 Openshift Container Platform을 사용하여 backendUsages
오브젝트를 적용하여 제품 선언적으로 원하는 백엔드를 정의합니다.
다음 관찰을 고려하십시오.
-
path
는 필수 필드입니다. -
backendUsages
맵 키 이름은 백엔드의system_name
에 대한 참조입니다. 아래 예제에서는backendA
및backendB
입니다.
절차
다음 예와 같이 제품에 백엔드를 추가하여 사용을 선언적으로 정의합니다.
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" backendUsages: backendA: path: /A backendB: path: /B
8.9.10. 3scale 제품 사용자 정의 리소스에서 게이트웨이 응답 구성
3scale 관리자는 제품
사용자 지정 리소스를 구성하여 해당 API 제품에 대해 노출된 API 요청에 대한 게이트웨이 응답을 지정할 수 있습니다. CR을 배포한 후 3scale은 사용자가 지정한 응답 및 오류 메시지를 반환하도록 합니다.
Product
CR에서 gatewayResponse
오브젝트에는 게이트웨이가 반환할 응답이 포함되어 있습니다.
절차
새 제품 또는 배포된
제품
CR에서gatewayResponse
오브젝트에서 하나 이상의 응답을 구성합니다. 다음 예제에서는userKey
라는 인증 모드를 사용하여 Apicast 호스팅 배포에 대한 응답 구성을 보여줍니다.apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastHosted: authentication: userkey: gatewayResponse: errorStatusAuthFailed: 500 errorHeadersAuthFailed: "text/plain; charset=mycharset" errorAuthFailed: "My custom reponse body" errorStatusAuthMissing: 500 errorHeadersAuthMissing: "text/plain; charset=mycharset" errorAuthMissing: "My custom reponse body" errorStatusNoMatch: 501 errorHeadersNoMatch: "text/plain; charset=mycharset" errorNoMatch: "My custom reponse body" errorStatusLimitsExceeded: 502 errorHeadersLimitsExceeded: "text/plain; charset=mycharset" errorLimitsExceeded: "My custom reponse body"
게이트웨이 응답이 포함된
Product
CR을 배포합니다. 예를 들어product1.yaml
파일을 업데이트한 경우 다음 명령을 실행합니다.oc create -f product1.yaml
주어진 예에서 출력은 다음과 같습니다.
product.capabilities.3scale.net/product1 created
8.9.11. 3scale 제품 사용자 정의 리소스에서 정책 체인 구성
3scale 관리자는 제품
사용자 지정 리소스를 구성하여 해당 API 제품에 적용할 정책 체인을 지정할 수 있습니다. CR을 배포한 후 3scale은 구성된 정책을 제품의 업스트림, 노출된 API에 적용합니다.
절차
신규 또는 배포된
제품
CR에서 정책 오브젝트에 하나 이상의정책을
구성합니다. 예를 들면 다음과 같습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" policies: - configuration: http_proxy: http://example.com https_proxy: https://example.com enabled: true name: camel version: builtin - configuration: {} enabled: true name: apicast version: builtin
각 정책에 대해 다음 필드를 지정합니다.
-
정책에 매개 변수가 없는 경우 구성은 빈 중괄호
쌍입니다
. 정책에 매개 변수가 있는 경우 여기에 지정합니다. 지정해야 하는 매개변수의 이름은 API 게이트웨이 관리, APIcast 표준 정책에서 관련 정책에 대한 설명서를 참조하십시오. -
enabled
는 정책을 켜거나 끌 수 있는 부울 스위치입니다. -
name
은 정책을 식별합니다.Product
사용자 지정 리소스가 연결되는 테넌트 범위의 고유한 이름입니다. 정책 이름을 식별하려면 API 게이트웨이, APIcast 표준 정책 관리의 관련 정책에 대한 설명서를 참조하십시오. 버전은
표준 정책 또는 사용자 지정 정책에 대한 사용자 정의 문자열에기본
제공됩니다. 예를 들어 사용자 지정 정책 버전을1.0
으로 설정할 수 있습니다.Product
CR에서apicast
정책을 지정하지 않으면 Operator가 이를 추가합니다.정책 체인이 관리 포털에 이미 정의된 경우 3scale toolbox
export
명령을 실행하여 정책 체인을.yaml
형식으로 내보낼 수 있습니다.내보내기
출력을Product
CR에 붙여넣을 수 있습니다. 예를 들어api-provider-account-one
이 3scale 공급자 계정의 이름이고my-api-product-one
이 내보내기하려는 정책 체인이 있는 제품의 이름인 경우 다음 명령을 실행합니다.
3scale policies export api-provider-account-one my-api-product-one
-
정책에 매개 변수가 없는 경우 구성은 빈 중괄호
정책 체인이 포함된
Product
CR을 배포합니다. 예를 들어product1.yaml
파일을 업데이트한 경우 다음 명령을 실행합니다.oc create -f product1.yaml
주어진 예에서 출력은 다음과 같습니다.
product.capabilities.3scale.net/product1 created
8.9.12. 제품 사용자 정의 리소스의 상태
status 필드에는 최종 사용자에게 유용한 리소스 정보가 표시됩니다. 수동으로 업데이트하려는 것은 아니며 리소스 변경 시 동기화됩니다.
다음은 status 필드의 속성입니다.
-
productId
: 3scale 제품의 내부 식별자입니다. 조건
:status.Conditions
Kubernetes 공통 패턴을 나타냅니다. 다음과 같은 유형이 있습니다.- 실패: 동기화하는 동안 오류가 발생했습니다. 이 작업은 다시 시도합니다.
- 동기화됨: 제품이 성공적으로 동기화되었습니다.
- 잘못된: 올바르지 않은 객체입니다. 일시적인 오류는 아니지만 잘못된 사양에 대해 보고하고 변경해야 합니다. Operator는 다시 시도하지 않습니다.
- 고아: 사양은 존재하지 않는 리소스를 참조합니다. Operator가 다시 시도합니다.
-
observedGeneration
: 최신 리소스 사양을 사용하여 상태 정보가 업데이트되었는지 확인합니다. -
state
: 3scale 제품 내부 상태는 3scale API에서 읽습니다. -
providerAccountHost
: 백엔드가 동기화되는 3scale 공급자 계정 URL입니다.
동기화된 리소스의 예:
status: conditions: - lastTransitionTime: "2020-10-21T18:07:01Z" status: "False" type: Failed - lastTransitionTime: "2020-10-21T18:06:54Z" status: "False" type: Invalid - lastTransitionTime: "2020-10-21T18:07:01Z" status: "False" type: Orphan - lastTransitionTime: "2020-10-21T18:07:01Z" status: "True" type: Synced observedGeneration: 1 productId: 2555417872138 providerAccountHost: https://3scale-admin.example.com state: incomplete
8.9.13. 테넌트 계정에 연결된 제품 사용자 정의 리소스
3scale Operator가 새로운 3scale 리소스를 찾으면 LookupProviderAccount 프로세스는 리소스를 소유한 테넌트를 식별하기 위한 목적으로 시작됩니다.
이 프로세스는 테넌트 자격 증명 소스를 확인합니다. 찾을 수 없는 경우 오류가 발생합니다.
다음 단계에서는 프로세스가 테넌트 자격 증명 소스를 확인하는 방법을 설명합니다.
providerAccountRef 리소스 속성에서 자격 증명을 확인합니다. 이는 보안 로컬 참조입니다. 예를 들어 mytenant:
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" providerAccountRef: name: mytenant
mytenant 시크릿에는 테넌트 자격 증명으로 채워진 adminURL 및 token 필드가 있어야 합니다. 예를 들면 다음과 같습니다.
apiVersion: v1 kind: Secret metadata: name: mytenant type: Opaque stringData: adminURL: https://my3scale-admin.example.com:443 token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
기본 3scale-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.9.14. 제품 사용자 정의 리소스 삭제
3scale 제품 엔터티를 관리하는 사용자 정의 리소스를 삭제하여 3scale 제품 엔터티를 삭제할 수 있습니다. 제품
사용자 정의 리소스를 삭제하면 3scale Operator는 삭제된 제품을 참조하는 오브젝트를 업데이트하지 않습니다.
제품 사용자 정의 리소스에서 정의한 API 제품
을 삭제하는 유일한 방법은 여기에 설명된 절차를 따르는 것입니다. 관리 포털이나 3scale API를 사용하여 사용자 정의 리소스로 배포된 제품을 삭제하지 마십시오.
사전 요구 사항
3scale 관리자 권한 또는 삭제하려는 사용자 정의 리소스가 포함된 네임스페이스에서 삭제 권한이 있는 OpenShift 역할. 특정
제품
사용자 정의 리소스를 삭제할 수 있는 사람을 식별하려면oc policy who-can delete
명령을 실행합니다. 예를 들어 CR의 이름이myproduct
인 경우 다음 명령을 실행합니다.oc policy who-can delete product.capabilities.3scale.net/myproduct
-
유효한 테넌트에 대한 링크를 삭제할
Product
CR입니다.
절차
oc delete
명령을 실행하여Product
사용자 정의 리소스를 삭제합니다. 예를 들어myproduct.yaml
파일에 정의된제품
을 배포한 경우 다음 명령을 실행합니다.oc delete -f myproduct.yaml
또는
oc delete
명령을 실행하고 정의에 지정된 대로 제품의 이름을 지정할 수 있습니다. 예를 들면 다음과 같습니다.oc delete product.capabilities.3scale.net/myproduct
8.10. 3scale CustomPolicyDefinition 사용자 정의 리소스 배포
CustomPolicyDefinition
CRD를 사용하여 관리 포털에서 3scale 제품에 사용자 정의 정책을 구성할 수 있습니다.
3scale Operator가 새 CustomPolicyDefinition
CR을 찾으면 3scale Operator가 사용자 정의 리소스 링크의 테넌트를 식별하는 방법에 설명된 대로 CR을 소유하는 테넌트를 식별합니다.
사전 요구 사항
- 3scale Operator가 설치되어 있습니다.
- 사용자 정의 정책 파일을 배포할 준비가 되었습니다.
- 이미 게이트웨이에 사용자 지정 정책을 삽입했습니다.
절차
CustomPolicyDefinition
사용자 정의 리소스를 정의하고my-apicast-custom-policy-definition.yaml
파일에 저장합니다.apiVersion: capabilities.3scale.net/v1beta1 kind: CustomPolicyDefinition metadata: name: custompolicydefinition-sample spec: version: "0.1" name: "APIcast Example Policy" schema: name: "APIcast Example Policy" version: "0.1" $schema: "http://apicast.io/policy-v1/schema#manifest#" summary: "This is just an example." configuration: type: object properties: {}
CustomPolicyDefinition
CR을 배포합니다.oc create -f my-apicast-custom-policy-definition.yaml
추가 리소스
8.11. 사용자 정의 리소스를 배포하여 3scale 개발자 관리
3scale 관리자는 CR(사용자 정의 리소스)을 사용하여 개별 개발자 사용자를 그룹화하는 개발자 계정을 배포할 수 있습니다. 이 계정을 사용하면 개발자 포털에서 3scale 관리 API에 대한 개발자 액세스를 구성하고 관리할 수 있습니다.
3scale SaaS의 테넌트는 원하는 수의 개발자 계정과 해당 테넌트에 대한 각 개발자 계정 링크를 포함할 수 있습니다. 개발자 계정은 원하는 수의 개발자 사용자와 정확히 하나의 개발자 계정에 대한 각 개발자 사용자 링크를 포함할 수 있습니다. 3scale 서비스 플랜은 생성할 수 있는 개발자 계정 수와 각 개발자 계정에 그룹화할 수 있는 개발자 사용자 수에 대한 제한을 결정합니다.
개발자 사용자 지정 리소스를 사용하려면 OpenShift에 3scale 운영자를 설치해야 합니다. 3scale Operator가 포함된 네임스페이스에만 개발자 사용자 지정 리소스를 배포할 수 있습니다. 개발자 사용자 지정 리소스 배포는 3scale 관리 포털, 3scale 툴박스 또는 3scale 내부 API를 사용하여 개발자 계정을 관리하는 대안입니다.
사용자 지정 리소스를 배포하여 개발자 계정 또는 개발자 사용자를 생성하는 경우 관리 포털 또는 내부 3scale API를 사용하여 해당 개발자 계정 또는 개발자 사용자를 업데이트할 수 없습니다. 개발자 CR을 배포한 후 관리 포털에 새 developer 계정 또는 새 developer 사용자를 해당 Accounts (계정) 페이지에 표시하므로 이 점을 인식하는 것이 중요합니다. 관리 포털 또는 API를 사용하여 CR을 사용하여 배포된 개발자 계정 또는 developer 사용자를 업데이트하려는 경우 3scale Operator는 변경 사항을 되돌리고 배포된 CR을 반영합니다. 이는 향후 릴리스에서 제거될 것으로 예상되는 제한 사항입니다. 그러나 관리 포털 또는 API를 사용하여 CR을 배포하여 생성한 개발자 계정 또는 developer 사용자를 삭제할 수 있습니다.
8.11.1. 사전 요구 사항
- 3scale 운영자는 OpenShift에 설치됩니다.
-
3scale에 대한 관리자 권한을 제공하는
Account Management
API 범위에서 읽기 및 쓰기 권한이 있는 토큰에 액세스합니다.
8.11.2. DeveloperAccount 사용자 정의 리소스를 배포하여 3scale 개발자 계정 관리
3scale Operator를 설치한 후 DeveloperAccount 및 Developer
User CR(사용자
정의 리소스)을 배포할 수 있습니다. 이러한 CR을 사용하면 개발자 포털에서 3scale-managed API에 액세스할 수 있도록 계정을 생성하고 업데이트할 수 있습니다.
새 DeveloperAccount
CR을 배포하려면 admin
역할이 있는 사용자에 대해 DeveloperUser
CR도 배포해야 합니다. 여기에서 제공되는 절차는 새 DeveloperAccount
CR을 배포하는 것입니다. DeveloperAccount
CR을 배포한 후 이를 업데이트하거나 삭제하는 절차는 다른 CR과 동일합니다.
3scale Operator가 포함된 네임스페이스에만 CR을 배포할 수 있습니다.
사전 요구 사항
- 3scale Operator가 사용자 지정 리소스가 연결되는 테넌트를 식별하는 방법에 대한 이해
DeveloperAccount CR을 포함할 네임스페이스에는
DeveloperAccount
CR이연결되는
테넌트를 식별하는 시크릿이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
-
새
DeveloperAccount
CR에admin
역할이 있는 developer 사용자를 위한 사용자 이름, 암호 및 이메일 주소가 있습니다.
절차
3scale 운영자가 포함된 네임스페이스에서 새 개발자 계정 리소스에
admin
역할이 있는 developer 사용자의 사용자 이름과 암호가 포함된 시크릿을 정의하는 리소스 파일을 만들고 저장합니다. 예를 들어myusername01.yaml
파일에는 다음이 포함될 수 있습니다.apiVersion: v1 kind: Secret metadata: name: myusername01 stringData: password: "123456"
시크릿을 생성합니다. 예를 들면 다음과 같습니다.
oc create -f myusername01.yaml
주어진 예에서 출력은 다음과 같습니다.
secret/myusername01 created
admin
역할이 있는 개발자의DeveloperUser
CR을 정의하는.yaml
파일을 생성하고 저장합니다. 3scale Operator가 새Developer
CR이 필요합니다. 예를 들어Account CR을 배포하는 데 이 Developer
Userdeveloperuser01.yaml
파일에는 다음이 포함될 수 있습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: DeveloperUser metadata: name: developeruser01 spec: username: myusername01 email: myusername01@example.com passwordCredentialsRef: name: myusername01 role: admin developerAccountRef: name: developeraccount1 providerAccountRef: name: mytenant
DeveloperUser
CR에서 다음을 수행합니다.-
developer 사용자 계정 이름, 사용자 이름 및 이메일은
DeveloperAccount
가 연결되는 테넌트에서 고유해야 합니다. -
여기에서 지정하는 개발자 계정 이름은 이 프로세스에서 배포하는
DeveloperAccount
CR의 이름과 일치해야 합니다. 이 DeveloperUser
CR을 생성하기전후에 DeveloperAccount
CR을 생성할지 여부는 중요하지 않습니다. -
DeveloperUser
CR을 연결하는 테넌트는 지정된DeveloperAccount
CR 링크와 동일한 테넌트여야 합니다.
-
developer 사용자 계정 이름, 사용자 이름 및 이메일은
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
oc create -f developeruser01.yaml
주어진 예에서 출력은 다음과 같습니다.
developeruser.capabilities.3scale.net/developeruser01 created
DeveloperAccount
CR을 정의하는.yaml
파일을 생성하고 저장합니다. 이.yaml
파일에서spec.OrgName
필드는 조직 이름을 지정해야 합니다. 예를 들어developeraccount01.yaml
파일에는 다음이 포함될 수 있습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: DeveloperAccount metadata: name: developeraccount01 spec: orgName: Ecorp providerAccountRef: name: mytenant
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
oc create -f developeraccount01.yaml
주어진 예에서 출력은 다음과 같습니다.
developeraccount.capabilities.3scale.net/developeraccount01 created
다음 단계
3scale Operator가 3scale 구성을 업데이트하여 새 사용자 지정 리소스를 반영하는 데 몇 초가 걸립니다. Operator가 사용자 정의 리소스 정보를 전파하는지 확인하려면 DeveloperAccount
사용자 정의 리소스 상태
필드를 확인하거나 oc wait
명령을 실행합니다. 예를 들면 다음과 같습니다.
oc wait --for=condition=Ready --timeout=30s developeraccount/developeraccount1
실패하는 경우 사용자 정의 리소스의 상태
필드는 오류가 일시적이거나 영구적일지 여부를 나타내며 문제를 해결하는 데 도움이 되는 오류 메시지를 제공합니다.
새 개발자 사용자에게 개발자 포털에 로그인할 수 있음을 알립니다. 또한 로그인 자격 증명을 전달해야 할 수도 있습니다.
다른 사용자 정의 리소스를 업데이트하는 것과 동일한 방식으로 배포된 DeveloperAccount
사용자 정의 리소스를 업데이트할 수 있습니다. 예를 들어 업데이트할 DeveloperAccount
CR을 보유한 테넌트가 포함된 OpenShift 프로젝트에서 다음 명령을 실행하여 devaccount1
CR을 업데이트합니다.
oc edit developeraccount devaccount1
8.11.3. DeveloperUser 사용자 정의 리소스를 배포하여 3scale 개발자 사용자 관리
3scale 운영자를 설치한 후에는 개발자 포털에서 3scale-managed API에 대한 개발자 액세스를 관리하기 위해 DeveloperUser
CR(사용자 정의 리소스)을 배포할 수 있습니다. 여기에서 제공되는 절차는 새 DeveloperUser
CR을 배포하는 것입니다. DeveloperUser
CR을 배포한 후 업데이트하거나 삭제하는 절차는 다른 CR과 동일합니다.
3scale Operator가 포함된 네임스페이스에만 CR을 배포할 수 있습니다.
사전 요구 사항
- 3scale Operator가 사용자 지정 리소스가 연결되는 테넌트를 식별하는 방법에 대한 이해
-
admin
역할이 있는 사용자에 대해 배포된Developer
사용자 정의 리소스가 하나 이상 있습니다.User CR이 하나 이상 포함된 Developer
Account DeveloperUser CR을 포함할 네임스페이스에는 DeveloperUser
가연결되는
테넌트를 식별하는 보안이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.-
threescale-provider-account
- 사용자 정의
이 시크릿에는 3scale SaaS의 URL과 해당 3scale SaaS의 테넌트에 액세스하기 위한 인증 정보가 포함된 토큰이 포함되어 있습니다.
-
-
새
DeveloperUser
사용자 지정 리소스의 경우 해당 개발자의 사용자 이름, 암호 및 이메일 주소가 있습니다.
절차
3scale 운영자가 포함된 네임스페이스에서 developer 사용자의 사용자 이름과 암호가 포함된 시크릿을 정의하는 리소스 파일을 만들고 저장합니다. 예를 들어
myusername02.yaml
파일에는 다음이 포함될 수 있습니다.apiVersion: v1 kind: Secret metadata: name: myusername02 stringData: password: "987654321"
시크릿을 생성합니다. 예를 들면 다음과 같습니다.
oc create -f myusername02.yaml
주어진 예에서 출력은 다음과 같습니다.
secret/myusername02 created
DeveloperUser
CR을 정의하는.yaml
파일을 생성하고 저장합니다.spec.role
필드에admin
또는member
를 지정합니다. 예를 들어developeruser02.yaml
파일에는 다음이 포함될 수 있습니다.apiVersion: capabilities.3scale.net/v1beta1 kind: DeveloperUser metadata: name: developeruser02 spec: username: myusername02 email: myusername02@example.com passwordCredentialsRef: name: myusername02 role: member developerAccountRef: name: developeraccount1 providerAccountRef: name: mytenant
DeveloperUser
CR에서 다음을 수행합니다.-
developer 사용자 이름(metadata
.name
필드에 지정됨), 사용자 이름 및 이메일은 포함된DeveloperAccount
링크가 포함된 테넌트에서 고유해야 합니다. -
developerAccountRef
필드는 배포된DeveloperAccount
CR의 이름을 지정해야 합니다. -
DeveloperUser
CR을 연결하는 테넌트는 지정된DeveloperAccount
CR 링크와 동일한 테넌트여야 합니다.
-
developer 사용자 이름(metadata
방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.
oc create -f developefuser02.yaml
주어진 예에서 출력은 다음과 같습니다.
developeruser.capabilities.3scale.net/developeruser02 created
다음 단계
3scale Operator가 3scale 구성을 업데이트하여 새 사용자 지정 리소스를 반영하는 데 몇 초가 걸립니다. Operator가 사용자 정의 리소스 정보를 전파하는지 확인하려면 DeveloperUser
사용자 정의 리소스 상태
필드를 확인하거나 oc wait
명령을 실행합니다. 예를 들면 다음과 같습니다.
oc wait --for=condition=Ready --timeout=30s developeruser/developeruser02
실패하는 경우 사용자 정의 리소스의 상태
필드는 오류가 일시적이거나 영구적일지 여부를 나타내며 문제를 해결하는 데 도움이 되는 오류 메시지를 제공합니다.
새 개발자 사용자에게 개발자 포털에 로그인할 수 있음을 알립니다. 또한 로그인 자격 증명을 전달해야 할 수도 있습니다.
다른 사용자 정의 리소스를 업데이트하는 것과 동일한 방식으로 배포된 DeveloperUser
사용자 정의 리소스를 업데이트할 수 있습니다.
8.11.4. DeveloperAccount 또는 DeveloperUser 사용자 정의 리소스 삭제
3scale 개발자 엔티티는 이를 관리하는 사용자 정의 리소스를 삭제하여 삭제할 수 있습니다.
사용자 정의 리소스를 삭제할 때 3scale Operator는 삭제된 DeveloperAccount CR에 연결된 모든 DeveloperAccount
DeveloperUser
CR도 삭제합니다.
사용자 지정 리소스에서 정의한 개발자 계정 또는 개발자 사용자를 삭제하는 유일한 방법은 여기에 설명된 절차를 따르는 것입니다. Admin Portal 또는 3scale API를 사용하여 사용자 정의 리소스로 배포된 개발자 엔터티를 삭제하지 마십시오.
사전 요구 사항
3scale 관리자 권한 또는 삭제하려는 사용자 정의 리소스가 포함된 네임스페이스에서 삭제 권한이 있는 OpenShift 역할. 특정 사용자 정의 리소스를 삭제할 수 있는지 확인하려면
oc auth can-i delete
명령을 실행합니다. 예를 들어DeveloperAccount
CR의 이름이devaccount1
인 경우 다음 명령을 실행합니다.oc auth can-i delete developeraccount.capabilities.3scale.net/devaccount1 -n my-namespace
-
유효한 테넌트에 대한 링크를 삭제할
DeveloperAccount
또는DeveloperUser
CR입니다.
절차
CR에서 연결하는 테넌트가 포함된 OpenShift 프로젝트에서
oc delete
명령을 실행하여DeveloperAccount
또는DeveloperUser
사용자 정의 리소스를 삭제합니다. 예를 들어devaccount1.yaml
파일에 정의된DeveloperAccount
CR을 배포한 경우 다음 명령을 실행합니다.oc delete -f devaccount1.yaml
또는
oc delete
명령을 실행하고 정의에 지정된 대로 CR 이름을 지정할 수 있습니다. 예를 들면 다음과 같습니다.oc delete developeraccount.capabilities.3scale.net/devaccount1
8.12. 3scale Operator 기능 제한
Red Hat 3scale 2saas에서 3scale operator에는 다음과 같은 제한 사항이 있습니다.
- 백엔드 CRD(사용자 정의 리소스 정의)는 조정되지 않습니다. 3scale의 기존 백엔드는 삭제되지 않습니다.
- 제품 CRD 삭제는 조정되지 않습니다. 3scale의 기존 제품은 삭제되지 않습니다.
- DeveloperAccount 또는 Developer User 사용자 정의 리소스 삭제는 조정되지 않습니다. Operator가 삭제 이벤트를 수신하는 동안 Operator는 이벤트에서 작동하지 않습니다. developer 계정 또는 developer 사용자는 그대로 유지됩니다. 삭제한 사용자 정의 리소스와 동일한 계정 이름, 사용자 이름 또는 이메일 주소를 사용하여 새 개발자 계정 또는 developer 사용자를 생성하려는 경우 계정이 이미 존재하는 오류가 표시됩니다. 계정을 생성하려면 다른 매개변수를 지정해야 합니다.
- 제품 CRD는 관리 및 개발자 포털에 SSO(Single Sign-On) 인증을 지원하지 않습니다.
- 제품 CRD는 OpenID Connect 인증을 지원하지 않습니다.
- ActiveDocs CRD는 현재 사용할 수 없습니다.
- 게이트웨이 정책 CRD는 현재 사용할 수 없습니다.
- 제품 CRD 게이트웨이가 응답 사용자 정의 코드 및 오류를 지원하지 않음
- 3scale Operator CRD OAS3이 포함된 3scale Operator CRD는 3scale 제품 구성의 신뢰 소스로 참조되지 않습니다.
8.13. 추가 리소스
자세한 내용은 다음 가이드를 참조하십시오.
9장. 3scale 백업 및 복원
이 장에서는 APIManager CR(사용자 정의 리소스)을 사용하여 배포된 Red Hat 3scale 설치의 백업 및 복원 기능에 대해 자세히 설명합니다. 이 컨텍스트에서 CRD는 3scale Operator에서 제공합니다.
운영자 기능의 사용자 지정 리소스는 3scale 설치의 일부가 아닙니다. 따라서 사용자 정의 리소스는 3scale 설치 백업 및 복원 기능의 일부로 포함되지 않습니다.
사전 요구 사항
- 3scale 설치
다음 섹션에는 운영자를 사용하여 3scale 백업 및 복원을 수행하는 절차가 포함되어 있습니다.
9.1. Operator를 사용하여 3scale 백업
다음 섹션에서는 APIManager CR(사용자 정의 리소스)에서 배포한 3scale 설치를 백업하는데 필요한 정보와 절차를 제공합니다.
9.1.1. 백업 호환 시나리오
백업할 수 있는 3scale 설치 구성을 보려면 다음 섹션을 참조하십시오.
사전 요구 사항
3scale 외부 데이터베이스를 백업합니다.
-
backend-redis
-
system-redis
-
system-database
- MySQL 또는 PostgreSQL -
zync
(선택 사항)
-
- PVC에 백업된 데이터를 포함할 충분한 공간을 프로비저닝합니다.
APIManager 를 사용하여 배포되는 3scale 배포는 시스템의 FileStorage로 S3을 사용하여 백업할 수 없습니다.
9.1.2. 백업 시나리오 범위
다음 데이터베이스가 외부에서 구성되면 백업 기능을 사용할 수 있습니다.
- 백엔드 Redis 데이터베이스
- 시스템 Redis 데이터베이스
- 시스템 데이터베이스 - MySQL 또는 PostgreSQL
- Zync 데이터베이스 (선택 사항)
9.1.3. 데이터 백업
다음 표는 백업된 데이터 목록을 보여줍니다.
표 9.1. 백업되는 데이터
개체 | 개체 유형 데이터 |
---|---|
보안 |
|
ConfigMaps |
|
APIManager | APIManager CR Kubernetes 오브젝트 정의 - json 스키마 정의 |
System FileStorage | System FileStorage의 위치가 PVC(PersistentVolumeClaim)에 있을 때 |
9.1.4. 3scale 백업
기존 APIManager 와 함께 배포된 3scale 설치를 백업하려면 다음 단계를 사용합니다.
절차
다음 Kubernetes 시크릿을 백업합니다.
-
backend-redis
-
system-redis
-
system-database
-
zync
(선택 사항)
-
APIManager 오브젝트에서 관리하는 3scale 설치가 배포되는 동일한 네임스페이스에
APIManagerBackup
CR을 생성합니다(예:).예시 1
apiVersion: apps.3scale.net/v1alpha1 kind: APIManagerBackup metadata: name: example-apimanagerbackup-pvc spec: backupDestination: persistentVolumeClaim: resources: requests: "10Gi"
예 2에서는 기존 PersistentVolume 이름을 제공합니다.
apiVersion: apps.3scale.net/v1alpha1 kind: APIManagerBackup metadata: name: example-apimanagerbackup-pvc spec: backupDestination: persistentVolumeClaim: # resources specification is required but ignored when providing a volumeName as per K8s PVCs requirements behavior resources: requests: "10Gi" volumeName: "my-preexisting-persistent-volume"
-
APIManagerBackup
이 완료될 때까지 기다립니다.APIManagerBackup
의 콘텐츠를 가져오고.status.completed
필드가 true로 설정될 때까지 대기하여 이를 확인합니다.
백업 내용은 Backed up data 에 자세히 설명되어 있습니다.
APIManagerBackup
의 status 섹션에 있는 다른 필드에는 구성된 백업 대상이 PVC일 때 데이터가 백업된 PVC 이름과 같은 백업 세부 정보가 표시됩니다.
향후 참조의 경우 status.backupPersistentVolumeClaimName
필드 값을 기록해 두십시오. APIManager Restore를 사용하여 APIManager
설치를 복원할 때 필요한 필드 중 하나는 PersistentVolumeClaimName
백업 소스입니다.
9.1.5. 3scale 사용자 정의 리소스 백업
OpenShift 관리자 계정 외부에 CR 사본이 없는 경우 다음 명령을 사용하여 3scale 프로젝트 CR의 백업을 생성합니다.
다음 명령을 입력하여 3scale 프로젝트에서 ActiveDocs CR을 내보냅니다.
oc get activedocs.capabilities.3scale.net -o yaml > activedocs.yaml
다음 명령을 입력하여 3scale 프로젝트에서 backend CR을 내보냅니다.
oc get backend.capabilities.3scale.net -o yaml > backend.yaml
다음 명령을 입력하여 3scale 프로젝트에서 CustomPolicyDefinition CR을 내보냅니다.
oc get custompolicydefinition.capabilities.3scale.net -o yaml > custompolicydefinition.yaml
다음 명령을 입력하여 3scale 프로젝트에서 DeveloperAccount CR을 내보냅니다.
oc get developeraccount.capabilities.3scale.net -o yaml > developeraccount.yaml
다음 명령을 입력하여 3scale 프로젝트에서 DeveloperUser CR을 내보냅니다.
oc get developeruser.capabilities.3scale.net -o yaml > developeruser.yaml
다음 명령을 입력하여 3scale 프로젝트에서 OpenAPI CR을 내보냅니다.
oc get openapi.capabilities.3scale.net -o yaml > openapi.yaml
다음 명령을 입력하여 3scale 프로젝트에서 제품 CR을 내보냅니다.
oc get product.capabilities.3scale.net -o yaml > product.yaml
다음 명령을 입력하여 3scale 프로젝트에서 테넌트 CR을 내보냅니다.
oc get tenant.capabilities.3scale.net -o yaml > tenant.yaml
9.2. Operator를 사용하여 3scale 복원
다음 섹션에서는 이전에 APIManager 사용자 지정 리소스에서 배포하고 APIManager
Backup 으로 백업한 3scale 설치를 복원하는 데 필요한 정보와 절차를 설명합니다.
9.2.1. 호환 가능한 복원 시나리오
복원할 수 있는 3scale 설치 구성을 보려면 다음 섹션을 참조하십시오.
사전 요구 사항
3scale 외부 데이터베이스를 복원합니다.
-
backend-redis
-
system-redis
-
system-database
- MySQL 또는 PostgreSQL -
zync
(선택 사항)
-
9.2.2. 복원 시나리오 범위
3scale 운영자의 복원 기능은 APIManagerBackup
사용자 정의 리소스에서 생성된 백업을 사용하여 사용할 수 있습니다.
백업할 수 있는 3scale 솔루션 시나리오 목록은 Backed up data for reference를 참조하십시오.
다음은 Operator의 복원 기능 범위에 있지 않습니다.
-
APIManagerBackup
사용자 정의 리소스를 사용하여 수행하지 않은 백업 데이터 복원. -
다양한 3scale 버전에서
APIManagerBackup
을 통해 제공되는 백업 데이터 복원.
9.2.3. 복원된 데이터
다음 표는 복원된 데이터 목록을 보여줍니다.
표 9.2. 복원된 데이터
개체 | 개체 유형 데이터 |
---|---|
보안 |
|
ConfigMaps |
|
APIManager | APIManager 사용자 정의 리소스 Kubernetes 오브젝트 정의 - json 스키마 정의 |
System FileStorage | System FileStorage의 위치가 PVC(PersistentVolumeClaim)에 있을 때 |
라우트 | 3scale 관련 OpenShift 경로(예: master 및 tenants) |
9.2.4. 3scale 복원
APIManager Backup
사용자 정의 리소스를 사용하여 백업한 APIManager 를 사용하여 이전에 배포한 3scale 설치를 복원하려면 다음 단계를 따르십시오.
- 복원을 수행하는 프로젝트에 APIManager 사용자 지정 리소스 및 해당 3scale 설치가 포함되어 있지 않은지 확인합니다.
다음 Kubernetes 시크릿을 복원합니다.
-
backend-redis
-
system-redis
-
system-database
-
zync
가 외부 데이터베이스인 경우zync
secret
-
APIManagerRestore
사용자 지정 리소스를 생성하고 이전에APIManagerBackup 사용자 정의 리소스에서 백업한 설치의
백업 데이터를 지정합니다.자세한 내용은 백업 시나리오 범위를 참조하십시오.
다음은
APIManagerRestore
사용자 정의 리소스의 예입니다.apiVersion: apps.3scale.net/v1alpha1 kind: APIManagerRestore metadata: name: example-apimanagerrestore-pvc spec: restoreSource: persistentVolumeClaim: claimSource: claimName: example-apimanagerbackup-pvc # Name of the PVC produced as the backup result of an `APIManagerBackup` readOnly: true
APIManagerRestore
가 완료될 때까지 기다립니다.APIManagerRestore
의 콘텐츠를 가져오고.status.completed
필드가 true로 설정될 때까지 대기하여 이를 확인합니다.새 APIManager 사용자 지정 리소스가 생성되었으며 3scale 설치가 배포되어야 합니다.
10장. 3scale의 reCAPTCHA 구성
이 문서에서는 스팸으로부터 보호하기 위해 Red Hat 3scale 사내에 대한 reCAPTCHA를 구성하는 방법을 설명합니다.
사전 요구 사항
- 지원되는 OpenShift 버전에 설치 및 구성된 3scale On-Premises 인스턴스입니다.
- reCAPTCHA v2에 대한 사이트 키 및 비밀 키를 가져옵니다. Register a new site web page를 참조하십시오.
- 도메인 이름 검증을 사용하려면 허용 목록에 개발자 포털 도메인을 추가합니다.
3scale에 대한 reCAPTCHA를 구성하려면 다음 절차에 설명된 단계를 수행합니다.
10.1. 3scale의 스팸 보호를 위해 reCAPTCHA 구성
스팸 보호를 위해 reCAPTCHA를 구성하려면 reCAPTCHA가 포함된 비밀 파일을 패치하는 두 가지 옵션이 있습니다. 이러한 옵션은 OCP(OpenShift Container Platform) 사용자 인터페이스 또는 CLI(명령줄 인터페이스)를 사용합니다.
절차
- OCP 4.x: 프로젝트 탐색: [your_project_name] > 워크로드 > 시크릿.
system-recaptcha
시크릿 파일을 편집합니다.reCAPTHCA 서비스의
PRIVATE
는 base64 형식 인코딩이어야 합니다. 키를 base64 인코딩으로 수동으로 변환합니다._KEY
및 PUBLIC_KEY
CLI reCAPTCHA 옵션에는 base64 형식 인코딩이 필요하지 않습니다.
CLI: 다음 명령을 입력합니다.
oc patch secret/system-recaptcha -p '{"stringData": {"PUBLIC_KEY": "public-key-from-service", "PRIVATE_KEY": "private-key-from-service"}}'
진행 후 단계
- 위의 옵션 중 하나를 완료한 후 시스템 포드를 다시 배포합니다.
3scale 관리 포털에서 서명되지 않은 사용자에 대해 스팸 보호를 설정합니다.
- 대상 > 개발자 포털 > 범위 보호로 이동합니다.
다음 옵션 중 하나를 선택합니다.
- always - 로그인하지 않은 사용자에게 양식이 표시되면 reCAPTCHA가 항상 표시됩니다.
- 의심스러운 전용 - reCAPTCHA는 자동 검사가 가능한 스패머를 탐지하는 경우에만 표시됩니다.
- Never - 범위 보호 해제.
system-app
을 재배포하면 개발자 포털에서 스팸 보호를 사용하는 페이지가 reCAPTCHA I'm a robot checkbox가 표시됩니다.

추가 리소스
- 자세한 내용은 ReCAPTCHA 홈페이지를 참조하십시오.
11장. API 인프라 문제 해결
이 가이드는 API 인프라 문제의 원인을 확인하고 수정하는 데 도움이 됩니다.
API 인프라는 길고 복잡한 주제입니다. 그러나 최소한 다음 세 가지 이동 부분은 인프라에서 보유하게 됩니다.
- API 게이트웨이
- 3scale
- API

이러한 세 가지 요소 중 하나에서 오류가 발생하면 API 소비자가 API에 액세스할 수 없습니다. 그러나 오류가 발생한 구성 요소를 찾는 것은 어렵습니다. 이 가이드에서는 문제를 식별하기 위한 몇 가지 팁을 제공합니다.
다음 섹션을 사용하여 발생할 수 있는 일반적인 문제를 식별하고 해결합니다.
11.1. 일반적인 통합 문제
3scale과의 통합과 관련하여 몇 가지 매우 일반적인 문제를 가리킬 수 있는 몇 가지 증거가 있습니다. 이는 API 프로젝트를 시작했는지, 인프라를 설정했는지 또는 이미 운영 중인 운영 환경에 따라 달라질 수 있습니다.
11.1.1. 통합 문제
다음 섹션에서는 3scale과의 통합 초기 단계에서 APIcast 오류 로그에 표시되는 몇 가지 일반적인 문제를 개략적으로 설명합니다. APIcast Hosted를 사용하기 시작할 때 자체 관리 APIcast를 실행하기 전에 라이브로 실행할 수 있습니다.
11.1.1.1. APIcast 호스팅
Service Integration(서비스 통합) 화면에서 먼저 API를 APIcast와 통합하려는 경우 페이지에 표시되거나 테스트 호출에서 반환하여 통합에 성공했는지 확인하는 몇 가지 오류가 발생할 수 있습니다.
테스트 요청 실패: 실행 만료
공용 인터넷에서 API에 연결할 수 있는지 확인합니다. APIcast Hosted는 프라이빗 API와 함께 사용할 수 없습니다. APIcast Hosted와 API를 공개적으로 통합할 수 있도록 하려면 APIcast Hosted와 API 간의 비공개 시크릿을 설정하여 API 게이트웨이에서 들어오는 모든 호출을 거부할 수 있습니다.
허용되는 형식은
protocol://address(:port)
입니다.API 개인 기본 URL 끝에 있는 경로를 제거합니다. "매핑 규칙" 패턴 또는 API 테스트 GET 요청의 시작 부분에 추가할 수 있습니다.
HTTP 코드 XXX로 테스트 요청이 실패했습니다
-
405
: 엔드포인트에서 GET 요청을 수락하는지 확인합니다. APIcast는 통합을 테스트하기 위해 GET 요청만 지원합니다. -
403: 인증 매개변수 누락
: API에 이미 일부 인증이 있는 경우 APIcast에서 테스트 요청을 할 수 없습니다. -
403: 인증 실패
: 3scale을 사용하여 만든 첫 번째 서비스가 아닌 경우 테스트 요청을 수행하기 위해 자격 증명을 사용하여 서비스 아래에 애플리케이션을 생성했는지 확인합니다. 통합 중인 첫 번째 서비스인 경우 가입 시 생성한 테스트 계정이나 애플리케이션을 삭제하지 않았는지 확인합니다.
-
11.1.1.2. APIcast 자체 관리
APIcast 자체 관리와의 통합을 성공적으로 테스트한 후 API 게이트웨이를 직접 호스팅할 수 있습니다. 다음은 자체 관리 게이트웨이를 처음 설치하고 이를 통해 API를 호출할 때 발생할 수 있는 몇 가지 오류입니다.
업스트림 시간 초과(110: 연결 시간이 초과되었습니다) 업스트림에 연결하는 동안
API 게이트웨이와 공용 인터넷 사이에 자체 관리 게이트웨이가 3scale에 도달하지 못하도록 하는 방화벽 또는 프록시가 없는지 확인합니다.
서비스 목록을 가져오지 못했습니다: 잘못된 상태: 403 (제외됨)
2018/06/04 08:04:49 [emerg] 14#14: [lua] configuration_loader.lua:134: init(): failed to load configuration, exiting (code 1) 2018/06/04 08:04:49 [warn] 22#22: *2 [lua] remote_v2.lua:163: call(): failed to get list of services: invalid status: 403 (Forbidden) url: https://example-admin.3scale.net/admin/api/services.json , context: ngx.timer ERROR: /opt/app-root/src/src/apicast/configuration_loader.lua:57: missing configuration
THREESCALE_PORTAL_ENDOINT
값에서 사용한 액세스 토큰이 올바른지 그리고 Account Management API 범위가 있는지 확인합니다.curl 명령으로 curl
-v "https://example-admin.3scale.net/admin/api/services.json?access_token=<YOUR_ACCESS_TOKEN>"
을/를 확인합니다.JSON 본문을 사용하여 200개의 응답을 반환해야 합니다. 오류 상태 코드가 반환되면 응답 본문에서 자세한 내용을 확인합니다.
호스트 apicast.example.com에 대한 서비스를 찾을 수 없습니다
2018/06/04 11:06:15 [warn] 23#23: *495 [lua] find_service.lua:24: find_service(): service not found for host apicast.example.com, client: 172.17.0.1, server: _, request: "GET / HTTP/1.1", host: "apicast.example.com"
이 오류는 Public Base URL이 제대로 구성되지 않았음을 나타냅니다. 구성된 Public Base URL이 자체 관리 APIcast 요청에 사용하는 것과 동일한지 확인해야 합니다. 올바른 공용 기본 URL을 구성한 후 다음을 수행합니다.
-
APIcast가 "production(프로덕션)"용으로 구성되었는지 확인합니다(
THREESCALE_DEPLOYMENT_ENV
변수로 재정의하지 않은 경우 독립 실행형 APIcast의 기본 구성). 구성을 프로덕션으로 승격하는지 확인합니다. -
APIcast를 재시작합니다. APICAST_CONFIGURATION_
CACHE 및
환경 변수를 사용하여 구성 자동 다시 로드를 구성하지 않은 경우.APICAST_CONFIGURATION_
LOADER
-
APIcast가 "production(프로덕션)"용으로 구성되었는지 확인합니다(
다음은 잘못된 APIcast 자체 관리 통합을 가리킬 수 있는 다른 몇 가지 증상입니다.
- 매핑 규칙이 일치하지 않습니다 / API 호출 수: API의 메서드와 실제 URL 엔드포인트 간의 매핑을 정의하는 방법에 따라 요청당 메서드가 일치하지 않거나 두 번 이상 증가하지 않는 경우도 있습니다. 이 문제를 해결하려면 3scale 디버그 헤더 를 사용하여 API에 대한 테스트 호출을 수행합니다. 그러면 API 호출과 일치하는 모든 메서드 목록이 반환됩니다.
- 인증 매개 변수를 찾을 수 없습니다: Service Integration(서비스 통합) 화면에 지정된 대로 매개 변수를 올바른 위치에 보내는지 확인합니다. 자격 증명을 헤더로 전송하지 않으면 다른 모든 HTTP 메서드에 대한 GET 요청 및 본문 매개 변수에 대한 쿼리 매개 변수로 자격 증명을 전송해야 합니다. 3scale 디버그 헤더를 사용하여 API 게이트웨이의 요청에서 읽은 자격 증명을 다시 확인합니다.
11.1.2. 프로덕션 문제
설정을 완전히 테스트하고 잠시 API와 함께 실행한 후 API 게이트웨이에 문제가 발생하는 것은 드뭅니다. 그러나 실시간 프로덕션 환경에서 발생할 수 있는 몇 가지 문제는 다음과 같습니다.
11.1.2.1. 가용성 문제
가용성 문제는 일반적으로 nginx error.log의 업스트림 시간 초과
오류로 구분됩니다. 예:
upstream timed out (110: Connection timed out) while connecting to upstream, client: X.X.X.X, server: api.example.com, request: "GET /RESOURCE?CREDENTIALS HTTP/1.1", upstream: "http://Y.Y.Y.Y:80/RESOURCE?CREDENTIALS", host: "api.example.com"
간헐적으로 3scale 가용성 문제가 발생하는 경우 다음과 같은 이유가 있을 수 있습니다.
더 이상 사용하지 않는 이전 3scale IP로 확인 중입니다.
최신 버전의 API 게이트웨이 구성 파일은 매번 IP 확인을 강제 적용하는 변수로 3scale을 정의합니다. 빠른 수정을 위해 NGINX 인스턴스를 다시 로드합니다. 장기적인 수정을 위해 업스트림 블록에서 3scale 백엔드를 정의하지 않고 각 서버 블록 내에서 변수로 정의합니다. 예:
server { # Enabling the Lua code cache is strongly encouraged for production use. Here it is enabled . . . set $threescale_backend "https://su1.3scale.net:443";
이를 참조할 때 다음을 수행합니다.
location = /threescale_authrep { internal; set $provider_key "YOUR_PROVIDER_KEY"; proxy_pass $threescale_backend/transactions/authrep.xml?provider_key=$provider_key&service_id=$service_id&$usage&$credentials&log%5Bcode%5D=$arg_code&log%5Brequest%5D=$arg_req&log%5Bresponse%5D=$arg_resp; }
화이트리스트에서 일부 3scale IP가 누락되었습니다. 다음은 3scale이 다음을 수행하는 현재 IP 목록입니다.
- 75.101.142.93
- 174.129.235.69
- 184.73.197.122
- 50.16.225.117
- 54.83.62.94
- 54.83.62.186
- 54.83.63.187
54.235.143.255
위의 문제는 3scale 가용성이 인식되는 문제를 나타냅니다. 그러나 API가 AWS ELB 뒤에 있는 경우 API 게이트웨이에서 API 가용성과 유사한 문제가 발생할 수 있습니다. 이는 기본적으로 NGINX가 시작 시 DNS 확인을 수행한 다음 IP 주소를 캐시하기 때문입니다. 그러나 ELB는 정적 IP 주소를 확인하지 않으며 자주 변경될 수 있습니다. ELB가 다른 IP로 변경될 때마다 NGINX에서 연결할 수 없습니다.
이에 대한 솔루션은 런타임 DNS 확인을 강제 적용하기 위한 위의 수정 사항과 유사합니다.
-
http
섹션 상단에 이 행을 추가하여 Google DNS와 같은 특정 DNS 확인자를 설정합니다.확인자 8.8.8.8 8.8.4.4;
. -
서버
섹션의 상단에서 API 기본 URL을 변수로 설정합니다. $api_base "http://api.example.com:80"를 설정합니다. -
위치 /
섹션에서 proxy_pass 행을 찾아 proxy
_pass $api_base;
로 바꿉니다.
-
11.1.3. 배포 후 문제
새 엔드포인트 추가와 같은 API를 변경하는 경우 API 게이트웨이에 사용할 새 구성 파일 세트를 다운로드하기 전에 새 메서드 및 URL 매핑을 추가해야 합니다.
3scale에서 다운로드한 구성을 수정한 경우 가장 일반적인 문제는 Lua에서 코드 오류가 발생하여 다음과 같은 500 - 내부 서버 오류가 발생합니다
.
curl -v -X GET "http://localhost/" * About to connect() to localhost port 80 (#0) * Trying 127.0.0.1... connected > GET / HTTP/1.1 > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 > Host: localhost > Accept: */* > < HTTP/1.1 500 Internal Server Error < Server: openresty/1.5.12.1 < Date: Thu, 04 Feb 2016 10:22:25 GMT < Content-Type: text/html < Content-Length: 199 < Connection: close < <head><title>500 Internal Server Error</title></head> <center><h1>500 Internal Server Error</h1></center> <hr><center>openresty/1.5.12.1</center> * Closing connection #0
다음과 같은 원인을 아는 nginx error.log를 볼 수 있습니다.
2016/02/04 11:22:25 [error] 8980#0: *1 lua entry thread aborted: runtime error: /home/pili/NGINX/troubleshooting/nginx.lua:66: bad argument #3 to '_newindex' (number expected, got nil) stack traceback: coroutine 0: [C]: in function '_newindex' /home/pili/NGINX/troubleshooting/nginx.lua:66: in function 'error_authorization_failed' /home/pili/NGINX/troubleshooting/nginx.lua:330: in function 'authrep' /home/pili/NGINX/troubleshooting/nginx.lua:283: in function 'authorize' /home/pili/NGINX/troubleshooting/nginx.lua:392: in function while sending to client, client: 127.0.0.1, server: api-2445581381726.staging.apicast.io, request: "GET / HTTP/1.1", host: "localhost"
access.log에서 다음과 같이 표시됩니다.
127.0.0.1 - - [04/Feb/2016:11:22:25 +0100] "GET / HTTP/1.1" 500 199 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
위의 섹션에서는 3scale 여행의 모든 단계에서 발생할 수 있는 가장 일반적인 잘 알려진 문제에 대한 개요를 제공합니다.
이러한 모든 사항이 확인되어 문제에 대한 원인과 해결 방법을 찾을 수 없는 경우 API 요청 문제 식별에 대한 자세한 섹션을 진행해야 합니다. API에서 시작하고 실패 지점을 식별하기 위해 클라이언트로 돌아가십시오.
11.2. API 인프라 문제 처리
서버에 연결할 때 API 게이트웨이, 3scale 또는 API에 관계없이 오류가 발생하면 다음 문제 해결 단계가 호출의 첫 번째 포트여야 합니다.
11.2.1. 연결할 수 있습니까?
telnet을 사용하여 기본 TCP/IP 연결 telnet api.example.com 443을 확인합니다.
- 성공
telnet echo-api.3scale.net 80 Trying 52.21.167.109... Connected to tf-lb-i2t5pgt2cfdnbdfh2c6qqoartm-829217110.us-east-1.elb.amazonaws.com. Escape character is '^]'. Connection closed by foreign host.
- 실패
telnet su1.3scale.net 443 Trying 174.129.235.69... telnet: Unable to connect to remote host: Connection timed out
11.2.2. 서버 연결 문제
다른 네트워크 위치, 장치 및 지침에서 동일한 서버에 연결을 시도합니다. 예를 들어 클라이언트가 API에 연결할 수 없는 경우 API 게이트웨이와 같이 액세스해야 하는 시스템에서 API에 연결해 봅니다.
시도한 커넥션 중 하나라도 성공적으로 수행되면 실제 서버의 문제를 배제하고 문제 해결을 위해 네트워크에 집중할 수 있습니다. 문제가 발생할 가능성이 가장 높기 때문입니다.
11.2.3. DNS 문제입니까?
telnet apis.io 80 대신 호스트 이름(예: telnet 94.125.104.17 80
) 대신 IP 주소를 사용하여 서버에 연결해 보십시오.
이렇게 하면 DNS에 문제가 없습니다.
예를 들어 3scale dig su1.3scale.net
의 경우 dig
를 사용하여 서버의 IP 주소를 가져오거나, 호스트가 확인할 수 있는 여러 개의 IP가 있다고 의심되는 경우 su1.3scale.net을 dig
로 분석할 수 있습니다.
NB: 일부 호스트는 'dig any'를 차단합니다.
11.2.4. SSL 문제가 있습니까?
OpenSSL을 사용하여 다음을 테스트할 수 있습니다.
쉘 프롬프트에서와 같은 호스트 또는 IP에 대한 보안 연결
openssl s_client -connect su1.3scale.net:443
출력:
CONNECTED(00000003) depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3 verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA --- Server certificate -----BEGIN CERTIFICATE----- MIIE8zCCA9ugAwIBAgIQcz2Y9JNxH7f2zpOT0DajUjANBgkqhkiG9w0BAQsFADBE ... TRUNCATED ... 3FZigX+OpWLVRjYsr0kZzX+HCerYMwc= -----END CERTIFICATE----- subject=/C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 --- Acceptable client certificate CA names /C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net /C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1:RSA+MD5 Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3281 bytes and written 499 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: A85EFD61D3BFD6C27A979E95E66DA3EC8F2E7B3007C0166A9BCBDA5DCA5477B8 Session-ID-ctx: Master-Key: F7E898F1D996B91D13090AE9D5624FF19DFE645D5DEEE2D595D1B6F79B1875CF935B3A4F6ECCA7A6D5EF852AE3D4108B Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - a8 8b 6c ac 9c 3c 60 78-2c 5c 8a de 22 88 06 15 ..l..<`x,\.."... 0010 - eb be 26 6c e6 7b 43 cc-ae 9b c0 27 6c b7 d9 13 ..&l.{C....'l... 0020 - 84 e4 0d d5 f1 ff 4c 08-7a 09 10 17 f3 00 45 2c ......L.z.....E, 0030 - 1b e7 47 0c de dc 32 eb-ca d7 e9 26 33 26 8b 8e ..G...2....&3&.. 0040 - 0a 86 ee f0 a9 f7 ad 8a-f7 b8 7b bc 8c c2 77 7b ..........{...w{ 0050 - ae b7 57 a8 40 1b 75 c8-25 4f eb df b0 2b f6 b7 ..W.@.u.%O...+.. 0060 - 8b 8e fc 93 e4 be d6 60-0f 0f 20 f1 0a f2 cf 46 .......`.. ....F 0070 - b0 e6 a1 e5 31 73 c2 f5-d4 2f 57 d1 b0 8e 51 cc ....1s.../W...Q. 0080 - ff dd 6e 4f 35 e4 2c 12-6c a2 34 26 84 b3 0c 19 ..nO5.,.l.4&.... 0090 - 8a eb 80 e0 4d 45 f8 4a-75 8e a2 06 70 84 de 10 ....ME.Ju...p... Start Time: 1454932598 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) ---
SSLv3 지원 (3scale에서 지원 없음)
openssl s_client -ssl3 -connect su.3scale.net:443
출력 결과
CONNECTED(00000003) 140735196860496:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1456:SSL alert number 40 140735196860496:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:644: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : SSLv3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1454932872 Timeout : 7200 (sec) Verify return code: 0 (ok) ---
자세한 내용은 OpenSSL 도움말 페이지를 참조하십시오.
11.3. API 요청 문제 확인
API 요청의 문제를 식별하려면 다음 검사를 수행합니다.
11.3.1. API
API가 시작되어 요청에 응답하는지 확인하려면 API 게이트웨이를 통과하지 않음) API에 직접 동일한 요청을 수행합니다. API 게이트웨이를 통과하는 요청과 동일한 매개변수 및 헤더를 보내야 합니다. 오류가 발생한 정확한 요청이 확실하지 않은 경우 API 게이트웨이와 API 간의 트래픽을 캡처합니다.
호출이 성공하면 API에 대한 문제를 제외할 수 있습니다. 그렇지 않으면 API를 추가로 해결해야 합니다.
11.3.2. API 게이트웨이 > API
API 게이트웨이와 API 간의 네트워크 문제를 방지하려면 API 게이트웨이 서버와 동일한 호출을 수행합니다.
호출이 성공하면 API 게이트웨이 자체의 문제 해결으로 이동할 수 있습니다.
11.3.3. API 게이트웨이
API 게이트웨이가 올바르게 작동하는지 확인하는 여러 단계가 있습니다.
11.3.3.1. API 게이트웨이가 실행 중입니까?
게이트웨이가 실행 중인 시스템에 로그인합니다. 실패하면 게이트웨이 서버가 다운될 수 있습니다.
로그인한 후 NGINX 프로세스가 실행 중인지 확인합니다. 이를 위해 ps ax | grep nginx
또는 htop
을 실행합니다.
목록에 nginx 마스터 프로세스 및
표시되면 NGINX가 실행 중입니다.
nginx 작업자 프로세스가
11.3.3.2. 게이트웨이 로그에 오류가 있습니까?
다음은 게이트웨이 로그에 표시되는 일반적인 오류입니다(예: error.log).
API 게이트웨이가 API에 연결할 수 없습니다
upstream timed out (110: Connection timed out) while connecting to upstream, client: X.X.X.X, server: api.example.com, request: "GET /RESOURCE?CREDENTIALS HTTP/1.1", upstream: "http://Y.Y.Y.Y:80/RESOURCE?CREDENTIALS", host: "api.example.com"
API 게이트웨이는 3scale에 연결할 수 없습니다.
2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"
11.3.4. API 게이트웨이 > 3scale
API 게이트웨이가 올바르게 실행되고 있는지 확인한 후 다음 단계는 API 게이트웨이와 3scale 간 연결 문제를 해결하는 것입니다.
11.3.4.1. API 게이트웨이가 3scale에 도달할 수 있습니까?
NGINX를 API 게이트웨이로 사용하는 경우 게이트웨이가 3scale에 연결할 수 없을 때 nginx 오류 로그에 다음 메시지가 표시됩니다.
2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"
여기에서 업스트림 값을 확인합니다. 이 IP는 3scale 제품이 분석하는 IP 중 하나에 해당합니다. 이는 3scale에 도달하는 데 문제가 있음을 의미합니다. 역방향 DNS 조회를 수행하여 nslookup
을 호출하여 IP의 도메인을 확인할 수 있습니다.
예를 들어 API 게이트웨이가 3scale에 도달할 수 없으므로 3scale이 다운되었음을 의미하지 않습니다. 가장 일반적인 이유 중 하나는 API 게이트웨이가 3scale에 연결되지 못하도록 하는 방화벽 규칙입니다.
게이트웨이와 3scale 사이에 네트워크 문제가 있을 수 있으며 이로 인해 연결이 시간 초과될 수 있습니다. 이 경우 일반적인 연결 문제를 해결하는 단계를 수행하여 문제가 있는 위치를 식별해야 합니다.
네트워킹 문제를 해결하려면 traceroute 또는 MTR을 사용하여 라우팅 및 패킷 전송을 확인합니다. 3scale 및 API 게이트웨이에 연결하고 출력을 비교할 수 있는 시스템에서 동일한 명령을 실행할 수도 있습니다.
또한 API 게이트웨이와 3scale 간에 전송되는 트래픽을 확인하려면 3scale 제품(su1.3scale.net)에 HTTP 끝점을 사용하여 일시적으로 전환하는 한 tcpdump를 사용할 수 있습니다.
11.3.4.2. API 게이트웨이가 3scale 주소를 올바르게 해결합니까?
resolver 지시문이 nginx.conf에 추가되었는지 확인합니다.
예를 들어 nginx.conf에서 다음을 수행합니다.
http { lua_shared_dict api_keys 10m; server_names_hash_bucket_size 128; lua_package_path ";;$prefix/?.lua;"; init_by_lua 'math.randomseed(ngx.time()) ; cjson = require("cjson")'; resolver 8.8.8.8 8.8.4.4;
Google DNS(8.8.8.8 및 8.8.4.4)를 선호하는 DNS로 대체할 수 있습니다.
API 게이트웨이에서 DNS 확인을 확인하려면 지정된 확인자 IP를 사용하여 nslookup을 호출합니다.
nslookup su1.3scale.net 8.8.8.8 ;; connection timed out; no servers could be reached
위 예에서는 Google DNS에 연결할 수 없는 경우 반환된 응답을 보여줍니다. 이 경우 확인자 IP를 업데이트해야 합니다. nginx error.log에도 다음 경고가 표시될 수 있습니다.
2016/05/09 14:15:15 [alert] 9391#0: send() failed (1: Operation not permitted) while resolving, resolver: 8.8.8.8:53
마지막으로, dig any su1.3scale.net
을 실행하여 현재 3scale 서비스 관리 API에 대한 IP 주소를 확인합니다. 이는 3scale에서 사용할 수 있는 전체 IP 주소 범위가 아닙니다. 용량상의 이유로 일부 객체가 인/아웃될 수 있습니다. 향후 3scale 서비스에 대한 도메인 이름을 추가할 수도 있습니다. 이 경우 항상 통합 중에 제공된 특정 주소에 대해 테스트해야 합니다(해당하는 경우).
11.3.4.3. API 게이트웨이가 3scale를 올바르게 호출합니까?
문제 해결을 위해 API 게이트웨이가 3scale에 수행하는 요청을 확인하려면 nginx.conf의 3scale authrep 위치(API Key 및 App\_id 인증 모드의 경우
/threescale_authrep
)에만 다음 스니펫을 추가할 수 있습니다.
body_filter_by_lua_block{ if ngx.req.get_headers()["X-3scale-debug"] == ngx.var.provider_key then local resp = "" ngx.ctx.buffered = (ngx.ctx.buffered or "") .. string.sub(ngx.arg[1], 1, 1000) if ngx.arg[2] then resp = ngx.ctx.buffered end ngx.log(0, ngx.req.raw_header()) ngx.log(0, resp) end }
이 코드 조각은 X-3scale-debug 헤더
가 전송되면 nginx error.log에 다음과 같은 추가 로깅을 추가합니다(예: curl -v -H 'X-3scale-debug): YOUR_PROVIDER_KEY' -X GET "https://726e3b99.ngrok.com/api/contacts.json?access_token=7c6f24f5"
이렇게 하면 다음 로그 항목이 생성됩니다.
2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7: GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1 Host: 726e3b99.ngrok.io User-Agent: curl/7.43.0 Accept: */* X-Forwarded-Proto: https X-Forwarded-For: 2.139.235.79 while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io" 2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8: <?xml version="1.0" encoding="UTF-8"?><error code="access_token_invalid">access_token "7c6f24f5" is invalid: expired or never defined</error> while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"
첫 번째 항목(2016/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:
)은 3scale로 전송된 요청 헤더를 출력합니다. Host, User-Agent, accept, X-Forwarded-Proto 및 X-Forwarded-Forwarded.
두 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:
)은 3scale의 응답을 출력합니다. 이 경우 <error code="access_token_invalid">access_token "7c6f24f is invalid: expired or never defined</error>
입니다.
둘 다 원래 요청 (GET /api/Contacts.json?access_token=7c6f5
) 및 하위 요청 위치 (/threescale_authrep
) 및 업스트림 요청 ( upstream: "hits=1&access_token=7c6f5"
.)을 출력합니다.) 이 마지막 값을 사용하면 3scale IP 중 어떤 것이 해결되었는지와 3scale의 정확한 요청도 확인할 수 있습니다.
11.3.5. 3scale
11.3.5.1. 3scale 사용 가능한가요?
3scale을 사용할 수 있는지 확인하려면 다음 옵션 중 하나를 선택하십시오.
- 3scale 상태 페이지 확인
- Twitter에서 @3scalestatus 팔로우하기.
11.3.5.2. 3scale이 오류를 반환합니까?
3scale을 사용할 수도 있지만 API로 호출되지 않도록 API 게이트웨이에 오류가 반환됩니다. 3scale에서 권한 부여 호출을 직접 시도하고 응답을 확인합니다. 오류가 발생하면 #troubleshooting-api-error-codes[Error code] 섹션을 확인하여 문제가 무엇인지 확인합니다.
11.3.5.3. 3scale 디버그 헤더 사용
X-3scale-debug 헤더를 사용하여 API를 호출하여 3scale
디버그 헤더를 활성화할 수도 있습니다. 예:
curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug: YOUR_SERVICE_TOKEN
그러면 API 응답과 함께 다음 헤더가 반환됩니다.
X-3scale-matched-rules: /, /api/contacts.json < X-3scale-credentials: access_token=TOKEN_VALUE < X-3scale-usage: usage[hits]=2 < X-3scale-hostname: HOSTNAME_VALUE
11.3.5.4. 통합 오류 확인
또한 관리 포털의 통합 오류를 확인하여 트래픽을 3scale으로 보고하는 문제를 확인할 수 있습니다. https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors 참조하십시오.
통합 오류의 이유 중 하나는 server 블록에서 활성화되지 않은 underscores_in_headers
지시문을 사용하여 헤더에 자격 증명을 보낼 수 있습니다.
11.3.6. 클라이언트 API 게이트웨이
11.3.6.1. 공용 인터넷에서 API 게이트웨이에 연결할 수 있습니까?
브라우저를 게이트웨이 서버의 IP 주소(또는 도메인 이름)로 전달해 보십시오. 실패하는 경우 관련 포트에서 방화벽을 열어야 합니다.
11.3.6.2. 클라이언트에서 API 게이트웨이에 연결할 수 있습니까?
가능한 경우 이전에 설명한 메서드(telnet, curl 등) 중 하나를 사용하여 클라이언트에서 API 게이트웨이에 연결을 시도합니다. 연결에 실패하면 이 둘 사이의 네트워크에 문제가 있습니다.
그렇지 않으면 클라이언트가 API에 대한 호출을 수행하는 문제 해결으로 이동해야 합니다.
11.3.7. 클라이언트
11.3.7.1. 다른 클라이언트를 사용하여 동일한 호출을 테스트합니다.
요청이 예상 결과를 반환하지 않으면 다른 HTTP 클라이언트로 테스트합니다. 예를 들어 Java HTTP 클라이언트를 사용하여 API를 호출하고 cURL을 사용하여 잘못된 항목이 표시되는 경우.
클라이언트와 게이트웨이 간에 프록시를 통해 API를 호출하여 클라이언트가 보내는 정확한 매개변수와 헤더를 캡처할 수도 있습니다.
11.3.7.2. 클라이언트에서 보낸 트래픽 검사
Wireshark와 같은 도구를 사용하여 클라이언트가 수행하는 요청을 확인합니다. 이렇게 하면 클라이언트가 API에 대한 호출을 수행하는지 여부와 요청 세부 정보를 확인할 수 있습니다.
11.4. ActiveDocs 문제
ActiveDocs를 통과하면 명령줄에서 API를 호출할 때 이 작업을 호출하는 경우가 있습니다.
ActiveDocs 호출이 작동하도록 하려면 프록시를 통해 전송합니다. 이 프록시는 그렇지 않은 경우 API에서 문제를 일으킬 수 있는 특정 헤더를 추가합니다. 이 경우 다음 단계를 수행하십시오.
11.4.1. use petstore.swagger.io
Swagger는 최신 버전의 swagger-ui를 통해 Swagger 사양 및 API를 테스트하는 데 사용할 수 있는 petstore.swagger.io에 호스팅된 swagger-ui를 제공합니다. swagger-ui와 ActiveDocs가 같은 방식으로 실패하는 경우 ActiveDocs 또는 ActiveDocs 프록시에 문제가 발생하지 않고 문제 해결에 중점을 둘 수 있습니다. 또는 swagger-ui의 현재 버전과 관련하여 알려진 문제가 있는지 swagger-ui GitHub 리포지토리를 확인할 수 있습니다.
11.4.2. 방화벽이 ActiveDocs 프록시의 연결을 허용하는지 확인합니다.
API를 사용하는 클라이언트의 IP 주소를 허용 목록에 지정하지 않는 것이 좋습니다. ActiveDocs 프록시는 고가용성을 위해 유동 IP 주소를 사용하며 현재 이러한 IP에 대한 변경 사항을 알리는 메커니즘은 없습니다.
11.4.3. 잘못된 인증 정보를 사용하여 API 호출
ActiveDocs 프록시가 올바르게 작동하는지 확인하는 한 가지 방법은 잘못된 인증 정보를 사용하여 API를 호출하는 것입니다. 이렇게 하면 ActiveDocs 프록시 및 API 게이트웨이 둘 다에 문제가 있는지 확인하거나 배제하는 데 도움이 됩니다.
API 호출에서 403 코드를 다시 가져오거나 잘못된 자격 증명을 위해 게이트웨이에 구성된 코드에서 가져온 경우 호출이 게이트웨이에 도달하므로 API에 문제가 있습니다.
11.4.4. 통화 비교
ActiveDocs 외부와 ActiveDocs 외부에서 수행된 호출 간 헤더와 매개 변수의 차이점을 식별하려면 온프레미스 또는 Runscope와 같은 서비스를 통해 호출을 실행합니다. 이렇게 하면 HTTP 호출을 검사하고 비교한 후 API로 보낼 수 있습니다. 그러면 문제가 발생할 수 있는 요청에서 잠재적인 헤더 및/또는 매개 변수를 식별할 수 있습니다.
11.5. NGINX로 로그인
이에 대한 포괄적인 가이드는 NGINX 로깅 및 모니터링 설명서를 참조하십시오.
11.5.1. 디버깅 로그 활성화
디버깅 로그 활성화에 대한 자세한 내용은 NGINX 디버깅 로그 설명서를 참조하십시오.
11.6. 3scale 오류 코드
3scale Service Management API 끝점에서 반환하는 오류 코드를 다시 확인하려면 다음 단계를 수행하여 3scale API 설명서 페이지를 참조하십시오.
- 관리 포털의 오른쪽 상단에 있는 물음표(?) 아이콘을 클릭합니다.
- 3scale API Docs 를 선택합니다.
다음은 3scale에서 반환한 HTTP 응답 코드와 반환되는 조건 목록입니다.
400: 잘못된 요청. 이는 다음과 같은 이유로 발생할 수 있습니다.
- 잘못된 인코딩
- 페이로드가 너무 큽니다
-
콘텐츠 유형이 올바르지 않습니다( POST 호출의 경우).
Content-Type
헤더에 유효한 값은application/x-www-form-urlencoded
,multipart/form-data
또는 빈 헤더입니다.
403:
- 인증 정보가 유효하지 않습니다.
- GET 요청을 위해 3scale에 본문 데이터 전송
- 404: 애플리케이션, 지표 등 참조된 존재하지 않는 엔터티.
409:
- 사용 제한 초과
- 애플리케이션이 활성화되어 있지 않습니다
-
애플리케이션 키가 잘못되었거나 누락되어 있습니다 (app
_id/app_key
인증 방법의 경우) - 참조가 허용되지 않거나 누락된 경우 (참조 필터가 활성화되어 필요한 경우)
- 422: 필수 매개 변수 누락
- 429: 너무 많은 요청 - 트래픽이 계약 제한을 초과할 때 전송됩니다.
이러한 오류 응답에는 대부분의 시스템에서 읽을 수 있는 오류 범주와 사람이 읽을 수 있는 설명이 있는 XML 본문이 포함됩니다.
표준 API 게이트웨이 구성을 사용하는 경우 3scale에서 제공하는 200과 다른 반환 코드가 있으면 다음 코드 중 하나를 사용하여 클라이언트에 응답할 수 있습니다.
- 403
- 404
- 429