3scale 작동
배포 자동화, 환경 확장 및 문제 해결 방법
초록
1장. 3scale 작업 및 스케일링 가이드
이 섹션에서는 Red Hat 3scale API Management 2.7 설치의 작업 및 확장 작업에 대해 설명합니다.
사전 요구 사항
- 지원되는 OpenShift 버전에 설치되어 처음 구성된 3scale 온-프레미스 인스턴스입니다.
이 문서는 랩탑 또는 유사한 최종 사용자 장비에 로컬 설치를 위한 것이 아닙니다.
3scale 작업 및 스케일링 작업을 수행하려면 다음 섹션에 설명된 단계를 수행합니다.
추가 리소스
1.1. APIcast 재배포
3scale 관리 포털을 통해 시스템 변경 사항을 테스트하고 승격할 수 있습니다.
사전 요구 사항
- 3scale 온-프레미스의 배포된 인스턴스입니다.
- APIcast 배포 방법을 선택했습니다.
기본적으로 포함된 OpenShift 클러스터와 다른 OpenShift 클러스터에 모두 APIcast 배포는 3scale 관리 포털을 통해 스테이징 및 프로덕션 게이트웨이에 변경 사항을 게시할 수 있도록 구성됩니다.
OpenShift에 APIcast를 재배포하려면 다음을 수행합니다.
절차
- 시스템을 변경합니다.
- 관리 포털에서 스테이징 및 테스트에 배포합니다.
- 관리 포털에서 프로덕션으로 승격합니다.
기본적으로 APIcast는 5분마다 한 번씩 승격된 업데이트를 검색하고 게시합니다.
Docker 컨테이너 환경 또는 네이티브 설치에서 APIcast를 사용하는 경우 스테이징 및 프로덕션 게이트웨이를 구성하고 게이트웨이에서 게시된 변경 사항을 검색하는 빈도를 나타냅니다. APIcast 게이트웨이를 구성한 후 3scale 관리 포털을 통해 APIcast를 재배포할 수 있습니다.
Docker 컨테이너 환경 또는 네이티브 설치에 APIcast를 재배포하려면 다음을 수행합니다.
절차
- APIcast 게이트웨이를 구성하고 3scale 온-프레미스에 연결합니다.
- 시스템을 변경합니다.
- 관리 포털에서 스테이징 및 테스트에 배포합니다.
- 관리 포털에서 프로덕션으로 승격합니다.
APIcast는 구성된 빈도로 승격된 업데이트를 검색하고 게시합니다.
1.2. 온프레미스 3scale 확장
APIcast 배포가 증가함에 따라 사용 가능한 스토리지 양을 늘려야 할 수 있습니다. 스토리지를 확장하는 방법은 영구 스토리지에 사용하는 파일 시스템의 유형에 따라 다릅니다.
1.2.1. 스토리지 확장
NFS(네트워크 파일 시스템)를 사용하는 경우 oc edit pv 명령을 사용하여 영구 볼륨을 확장할 수 있습니다.
oc edit pv <pv_name>
다른 스토리지 방법을 사용하는 경우 다음 섹션에 나열된 방법 중 하나를 사용하여 영구 볼륨을 수동으로 확장해야 합니다.
1.2.1.1. 방법 1: 영구 볼륨 백업 및 교체
절차
- 기존 영구 볼륨에서 데이터를 백업합니다.
- 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
-
사전 바인딩된 영구 볼륨 클레임을 생성하고
volumeName필드를 사용하여 새 PVC의 크기를 지정합니다. - 백업에서 새로 생성된 PV로 데이터를 복원합니다.
새 PV의 이름으로 배포 구성을 수정합니다.
oc edit dc/system-app
- 새 PV가 구성되어 올바르게 작동하는지 확인합니다.
- 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.
1.2.1.2. 방법 2: 3scale 백업 및 재배포
절차
- 기존 영구 볼륨에서 데이터를 백업합니다.
- 3scale Pod를 종료합니다.
- 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
- 백업에서 새로 생성된 PV로 데이터를 복원합니다.
사전 바인딩된 영구 볼륨 클레임을 생성합니다. 다음을 지정합니다.
- 새 PVC의 크기
-
volumeName필드를 사용하는 영구 볼륨 이름입니다.
- amp.yml 을 배포합니다.
- 새 PV가 구성되어 올바르게 작동하는지 확인합니다.
- 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.
1.2.2. 성능 확장
성능 확장은 총 Pod 수를 통해 수행됩니다. 하드웨어 리소스가 많을수록 더 많은 Pod를 배포할 수 있습니다.
다음 명령을 사용하여 Pod 수를 통해 성능을 확장합니다.
oc scale dc dc-name --replicas=X
1.2.3. 온프레미스 3scale 배포 구성
3scale에 맞게 스케일링할 주요 배포 구성은 다음과 같습니다.
- APIcast 프로덕션
- 백엔드 리스너
- 백엔드 작업자
1.2.4. 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
1.2.5. 수직 및 수평 하드웨어 확장
리소스를 추가하여 OpenShift에서 3scale 배포의 성능을 향상시킬 수 있습니다. 수평 확장으로 OpenShift 클러스터에 더 많은 컴퓨팅 노드를 Pod로 추가하거나 기존 컴퓨팅 노드에 리소스를 수직 확장으로 할당할 수 있습니다.
수평 스케일링
더 많은 컴퓨팅 노드를 OpenShift에 Pod로 추가할 수 있습니다. 추가 컴퓨팅 노드가 클러스터의 기존 노드와 일치하는 경우 환경 변수를 재구성할 필요가 없습니다.
수직 확장
기존 컴퓨팅 노드에 더 많은 리소스를 할당할 수 있습니다. 더 많은 리소스를 할당하는 경우 성능을 높이기 위해 Pod에 프로세스를 추가해야 합니다.
3scale 배포에서 다른 사양 및 구성이 있는 컴퓨팅 노드를 사용하지 마십시오.
1.2.6. 라우터 확장
트래픽이 증가함에 따라 Red Hat OCP 라우터에서 요청을 적절하게 처리할 수 있는지 확인합니다. 라우터에서 요청 처리량을 제한하는 경우 라우터 노드를 확장해야 합니다.
1.3. 작업 문제 해결
이 섹션에서는 OpenShift에 표시되도록 3scale 감사 로깅을 구성하는 방법과 OpenShift에서 3scale 로그 및 작업 큐에 액세스하는 방법을 설명합니다.
1.3.1. OpenShift에서 3scale 감사 로깅 구성
이를 통해 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴을 통해 모든 로그를 쿼리할 수 있습니다. 이러한 툴은 3scale 구성 변경 사항, 이러한 변경을 수행한 사용자 및 시기에 대한 가시성을 향상시킵니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등에 대한 변경 사항이 포함됩니다.
사전 요구 사항
- 3scale 2.7 배포
절차
모든 애플리케이션 로그를 표준 OpenShift 포드 로그로 전달하도록 감사 로깅을 stdout 로 구성합니다.
몇 가지 고려 사항:
-
3scale이 온-프레미스에 배포되면 기본적으로
stdout에 대한 감사 로깅이 비활성화됩니다. 이 기능을 완전히 작동하도록 구성해야 합니다. -
3scale 호스팅에서는
stdout에 대한 감사 로깅을 사용할 수 없습니다.
1.3.2. 감사 로깅 활성화
3scale은 features.xml 구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout 에 대한 감사 로깅을 활성화하려면 ConfigMap 에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.xml 을 사용하는 OpenShift pod는 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
1.3.3. EFK 로깅 구성
stdout에 감사 로깅을 활성화하여 3scale 애플리케이션 로그를 OpenShift로 전달하면 EFK 로깅 툴을 사용하여 3scale 애플리케이션을 모니터링할 수 있습니다.
OpenShift에서 EFK 로깅을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
1.3.4. 로그 액세스
각 구성 요소의 배포 구성에는 액세스 및 예외에 대한 로그가 포함되어 있습니다. 배포에 문제가 발생하면 해당 로그에서 자세한 내용을 확인하십시오.
다음 단계에 따라 3scale의 로그에 액세스합니다.
절차
로그를 원하는 Pod의 ID를 찾습니다.
oc get pods
oc logs및 선택한 Pod의 ID를 입력합니다.oc logs <pod>
시스템 포드에는 각각 별도의 로그가 있는 두 개의 컨테이너가 있습니다. 컨테이너 로그에 액세스하려면
system-provider및system-developerPod를 사용하여--container매개변수를 지정합니다.oc logs <pod> --container=system-provider oc logs <pod> --container=system-developer
1.3.5. 작업 대기열 확인
작업 큐에는 system-sidekiq Pod에서 보낸 정보 로그가 포함됩니다. 이러한 로그를 사용하여 클러스터가 데이터를 처리하고 있는지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다.
oc get jobs
oc logs <job>
1.3.6. 단조적 성장 방지
고정적 증가를 방지하기 위해 기본적으로 3scale 일정은 다음 테이블을 자동으로 제거합니다.
- user_sessions - 정리가 일주일에 한 번 트리거되고 2주 이상 오래된 레코드를 삭제합니다.
- 감사 - 정리는 하루에 한 번 트리거되고 3개월 이상 오래된 레코드를 삭제합니다.
- log_entries - 하루에 한 번 트리거하여 6개월 이상 오래된 레코드를 삭제합니다.
- event_store_events - 정리가 일주일에 한 번 트리거되고 1주일 이상 오래된 레코드를 삭제합니다.
위에 나열된 테이블을 제외하고 경고 테이블을 사용하려면 데이터베이스 관리자가 수동으로 제거해야 합니다.
| 데이터베이스 유형 | 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; |
이 섹션에 지정되지 않은 다른 테이블의 경우 데이터베이스 관리자는 시스템이 자동으로 제거되지 않는 테이블을 수동으로 정리해야 합니다.
2장. 3scale toolbox 사용
3scale toolbox 는 명령줄에서 3scale 제품을 관리할 수 있는 Ruby 클라이언트입니다.
3scale toolbox는 모든 API를 Product(APIaP) 기능을 지원하지 않습니다. 자세한 내용은 3scale 릴리스 노트의 알려진 문제를 참조하십시오.
2.1. toolbox 설치
공식적으로 지원되는 3scale toolbox 설치 방법은 3scale toolbox 컨테이너 이미지를 사용하는 것입니다.
2.1.1. toolbox 컨테이너 이미지 설치
사전 요구 사항
- Red Hat Container Catalog의 3scale toolbox 이미지를 참조하십시오.
- Red Hat 레지스트리 서비스 계정이 있어야 합니다.
- 이 항목의 예제에서는 Docker가 설치되어 있고 데몬이 실행 중인 것으로 가정합니다.
절차
Red Hat 컨테이너 레지스트리에 로그인합니다.
$ docker login registry.redhat.io Username: ${REGISTRY-SERVICE-ACCOUNT-USERNAME} Password: ${REGISTRY-SERVICE-ACCOUNT-PASSWORD} Login Succeeded!toolbox 컨테이너 이미지를 가져옵니다.
$ docker pull registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7
설치를 확인합니다.
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale help
추가 리소스
- OpenShift, Podman 또는 Docker를 사용하여 toolbox 이미지를 설치하는 방법에 대한 자세한 내용은 Red Hat Container Catalog의 이미지 가져오기 지침을 참조하십시오.
-
Kubernetes에 3scale toolbox를 설치하는 지침 도 참조하십시오. OpenShift에서
kubectl대신 올바른 이미지 이름과oc명령을 사용해야 합니다.
2.1.2. 지원되지 않는 toolbox 버전 설치
2.2. 지원되는 toolbox 명령 사용
3scale toolbox를 사용하여 CLI(명령줄 도구)에서 API를 관리합니다.
update 명령은 더 이상 사용되지 않으며 copy 명령으로 교체되었습니다. Red Hat은 더 이상 사용되지 않는 기능을 사용하지 않는 것이 좋습니다.
지원되는 명령은 다음과 같습니다.
COMMANDS
account account super command
activedocs activedocs super command
application application super command
application-plan application-plan super command
copy copy super command
help show help
import import super command
method method super command
metric metric super command
policy-registry policy-registry super command
proxy-config proxy-config super command
remote remotes super command
service services super command
update [DEPRECTATED] update 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 mode2.3. 서비스 가져오기
다음 필드를 순서대로 지정하여 CSV 파일에서 서비스를 가져옵니다(CSV 파일에 이러한 헤더도 포함해야 함).
service_name,endpoint_name,endpoint_http_method,endpoint_path,auth_mode,endpoint_system_name,type
다음 정보가 필요합니다.
-
3scale 관리자 계정:
{3SCALE_ADMIN} 3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}- 호스팅된 APICast를 사용하는 경우 3scale.net입니다.
-
계정의 액세스 키:
{ACCESS_KEY} -
서비스의 CSV 파일(예:
examples/import_example.csv)
다음을 실행하여 서비스를 가져옵니다.
예제
$ docker run -v $PWD/examples/import_example.csv:/tmp/import_example.csv registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale import csv --destination=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --file=/tmp/import_example.csv
이 예에서는 Docker 볼륨을 사용하여 컨테이너에 리소스 파일을 마운트합니다. 파일을 현재 $PWD 폴더에서 사용할 수 있다고 가정합니다.
2.4. 서비스 복사
동일한 계정 또는 다른 계정에서 기존 서비스를 기반으로 새 서비스를 생성합니다. 서비스를 복사하면 관련 ActiveDocs도 복사됩니다.
다음 정보가 필요합니다.
-
복사하려는 서비스 ID:
{SERVICE_ID} -
3scale 관리자 계정:
{3SCALE_ADMIN} 3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}- 호스팅된 APICast를 사용하는 경우 3scale.net입니다.
-
계정의 액세스 키:
{ACCESS_KEY} -
다른 계정에 복사하는 경우 대상 계정의 액세스 키:
{DEST_KEY} -
새 서비스의 이름:
{NEW_NAME}
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 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}
복사할 서비스에 사용자 지정 정책이 있는 경우 해당 사용자 지정 정책 정의가 서비스를 복사할 대상에 이미 있는지 확인합니다. 사용자 지정 정책 정의 복사에 대한 자세한 내용은 정책 레지스트리 복사를 참조하십시오.
2.5. 서비스 설정만 복사
서비스 및 프록시 설정, 메트릭, 방법, 애플리케이션 계획 제한, 서비스에서 기존 서비스로의 매핑 규칙을 대량 복사 및 업데이트할 수 있습니다.
다음 정보가 필요합니다.
-
복사하려는 서비스 ID:
{SERVICE_ID} -
대상의 서비스 ID:
{DEST_ID} -
3scale 관리자 계정:
{3SCALE_ADMIN} 3scale 인스턴스가 실행 중인 도메인:
{DOMAIN_NAME}- 호스팅된 APICast를 사용하는 경우 3scale.net입니다.
-
계정의 액세스 키:
{ACCESS_KEY} -
대상 계정의 액세스 키:
{DEST_KEY}
또한 선택적 플래그를 사용할 수 있습니다.
-
복사하기 전에 기존 대상 서비스 매핑 규칙을 제거하는
-f플래그입니다. -
대상 서비스에 매핑 규칙만 복사하는
-r플래그입니다.
update 명령은 더 이상 사용되지 않으며 copy 명령으로 교체되었습니다. 더 이상 사용되지 않는 명령 사용은 지원되지 않습니다.
다음 예제 명령은 한 서비스에서 다른 기존 서비스로 대규모 업데이트를 수행합니다.
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale update [opts] service --source=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --destination=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} {SERVICE_ID} {DEST_ID}
2.6. OpenAPI 정의 가져오기
새 서비스를 생성하거나 기존 서비스를 업데이트하려면 로컬 파일의 정의 또는 액세스 자격 증명을 사용하십시오. 해당 서비스 이름이 이미 있으면 업데이트됩니다. 반대로 서비스 이름이 없으면 생성됩니다.
가져오기의 기본 서비스 이름은 OpenAPI 정의의 info.title 에서 가져옵니다. --target_system_name=<NEW NAME> 을 사용하여 이 서비스 이름을 재정의할 수 있습니다. 해당 서비스 이름이 이미 있으면 업데이트됩니다. 반대로 서비스 이름이 없으면 생성됩니다.
다음 규칙은 모든 가져오기에 적용됩니다.
- 정의는 OpenAPI 2.0으로 검증됩니다.
- 3scale 제품의 모든 매핑 규칙이 삭제됩니다.
-
교체하려면 정확한 패턴 일치를 사용하여 모든 메서드 이름이 OpenAPI 정의(
operation.operationId)에 정의된 메서드와 동일해야 합니다. - OpenAPI 정의에 포함된 메서드만 수정됩니다.
-
OpenAPI 정의에서만 존재하는 모든 방법은
Hits메트릭에 연결됩니다. OpenAPI 정의의 모든 매핑 규칙을 가져옵니다.
- API > Integration 에서 이를 확인합니다.
swagger 사양에 보안 요구 사항은 없지만 서비스는 OpenAPI 로 간주됩니다. Toolbox는 정책 체인에 아직 없는 경우 anonymous_policy 라고도 하는 default_credentials 정책을 추가합니다. default_credentials 정책은 선택적 매개변수 --default-credentials- userkey 에 제공된 userkey를 사용하여 구성됩니다.
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale import openapi [opts] --destination=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME}
2.6.1. 선택적 플래그
-d --destination=<value>-
형식의 3scale 대상 인스턴스:
http[s]://<authentication>@3scale_domain. -t --target_system_name=<value>- 대상 시스템 이름입니다.
2.7. 원격 액세스 인증 정보 관리
원격 3scale 인스턴스를 쉽게 사용하려면 구성 파일에 해당 인스턴스에 액세스하는 데 사용할 인증과 함께 원격 웹 주소(URL)를 정의합니다. 3scale toolbox 명령에서 짧은 이름으로 해당 항목을 참조하십시오.
구성 파일의 기본 위치는 $HOME/.3scalerc.yaml 이지만 THREESCALE_CLI_CONFIG 환경 변수 또는 --config-file <config_file > 옵션을 사용하여 다른 위치를 지정할 수 있습니다.
access_token 또는 provider_key 를 사용하여 remote를 지정할 수 있습니다.
-
http[s]://<access_token>@<3scale-instance-domain> -
http[s]://<provider_key>@<3scale-instance-domain>
2.7.1. 원격 액세스 인증 정보 나열
3scale remote list [--config-file <config_file>]
기존 원격 목록(이름, URL 및 인증 키)을 표시합니다.
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale remote list instance_a https://example_a.net 123456789 instance_b https://example_b.net 987654321
2.7.2. 원격 액세스 인증 정보 추가
3scale remote add [--config-file <config_file>] <name> <url>
< url>에 짧은 이름 < 추가합니다.
name >이 있는 원격을
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale remote add instance_a https://123456789@example_a.net
2.7.3. 원격 액세스 인증 정보 제거
3scale remote remove [--config-file <config_file>] <name>
원격 woth 짧은 이름 <name& gt;을 제거합니다.
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale remote remove instance_a
2.7.4. 원격 액세스 인증 정보 이름 변경
3scale remote rename [--config-file <config_file>] <old_name> <new_name>
짧은 이름 < old_name>으로 remote의 이름을 < new_name >으로 변경합니다.
예제
$ docker run registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale remote rename instance_a instance_b
2.8. 애플리케이션 계획
3scale toolbox를 사용하여 개발자 포털에서 애플리케이션 계획을 생성, 업데이트, 나열, 삭제, 표시 또는 내보냅니다.
2.8.1. 새 애플리케이션 계획 생성
다음 단계를 사용하여 새 애플리케이션 계획을 생성합니다.
- 애플리케이션 계획 이름을 제공해야 합니다.
-
system-name을 재정의하려면 선택적 매개변수를 사용합니다. - 동일한 이름의 애플리케이션 계획이 이미 존재하는 경우 오류 메시지가 표시됩니다.
-
--플래그를 사용하여 애플리케이션 계획을 기본값으로 설정합니다.default --publish플래그를 사용하여게시된애플리케이션 계획을 생성합니다.-
기본적으로
숨겨집니다.
-
기본적으로
--플래그를 사용하여 비활성화된 애플리케이션 계획을 생성합니다.disabled-
기본적으로
활성화되어있습니다.
-
기본적으로
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령은 새 애플리케이션 계획을 생성합니다.
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
-d --default This will make the default application plan
--disabled This will disable all methods and metrics in
the application plan
--end-user-required=<value> End user required: true or false
-p --published This will publish the application plan
--setup-fee=<value> Set-up fee
-t --system-name=<value> This will 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
(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 This will print the version of this command
--verbose Verbose mode2.8.2. 애플리케이션 계획 생성 또는 업데이트
다음 단계를 사용하여 새 애플리케이션 계획을 생성하거나 기존 애플리케이션 계획을 업데이트합니다.
-
--플래그를 사용하여 기본 애플리케이션 계획을 업데이트합니다.default -
--publish플래그를 사용하여게시된애플리케이션 계획을 업데이트합니다. -
--hide플래그를 사용하여숨겨진애플리케이션 계획을 업데이트합니다. -
--플래그를 사용하여 비활성화된 애플리케이션 계획을 업데이트합니다.disabled -
--플래그를 사용하여 활성화된 애플리케이션 계획을 업데이트합니다.enabled
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
계획위치 인수는 계획 참조이며 계획 ID 또는 계획system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령은 애플리케이션 계획을 업데이트합니다.
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 This will make the default application plan
--disabled This will disable all methods and metrics in
the application plan
--enabled This will enable the application plan
--end-user-required=<value> End user required: true or false
--hide This will hide the application plan
-n --name=<value> This will set the plan name
-p --publish This will 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
(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 This will print the version of this command
--verbose Verbose mode2.8.3. 애플리케이션 계획 나열
다음 명령은 애플리케이션 계획을 나열합니다.
3scale application-plan list [opts] <remote> <service>
애플리케이션 계획을 나열하는 동안 다음 옵션을 사용합니다.
Options for application-plan
-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 This will print the version of this command
--verbose Verbose mode2.8.4. 애플리케이션 계획 표시
다음 명령은 애플리케이션 계획을 보여줍니다.
3scale application-plan show [opts] <remote> <service> <plan>
애플리케이션 계획을 표시하는 동안 다음 옵션을 사용합니다.
Options for application-plan
-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 This will print the version of this command
--verbose Verbose mode2.8.5. 애플리케이션 계획 삭제
다음 명령은 애플리케이션 계획을 삭제합니다.
3scale application-plan delete [opts] <remote> <service> <plan>
애플리케이션 계획을 삭제하는 동안 다음 옵션을 사용합니다.
Options for application-plan
-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 This will print the version of this command
--verbose Verbose mode2.8.6. 애플리케이션 계획 내보내기/가져오기
단일 애플리케이션 계획을 yaml 콘텐츠로 내보내거나 가져올 수 있습니다.
* 애플리케이션 계획에 정의된 제한 사항이 포함되어 있습니다. * 애플리케이션 계획에 정의된 가격 규칙이 포함됩니다. * 제한 및 가격 규칙에 의해 참조되는 메트릭/메서드가 포함되어 있습니다. * 애플리케이션 계획에 정의된 기능이 포함되어 있습니다. * 서비스는 id 또는 system_name 에서 참조할 수 있습니다. * 애플리케이션 계획은 id 또는 system_name 에서 참조할 수 있습니다.
2.8.6.1. 애플리케이션 계획을 파일로 내보내기
다음 명령은 애플리케이션 계획을 내보냅니다.
3scale application-plan export [opts] <remote> <service_system_name> <plan_system_name>
예제
$ docker run -u root -v $PWD:/tmp registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale application-plan export --file=/tmp/plan.yaml remote_name service_name plan_name
이 예에서는 Docker 볼륨을 사용하여 출력에 내보낸 파일을 현재 $PWD 폴더에 마운트합니다.
내보내기 명령과 관련이 있습니다.
- 원격 서비스 및 애플리케이션 계획에 대한 읽기 전용 작업.
명령 출력은
stdout또는 파일일 수 있습니다.-
-f옵션으로 지정하지 않으면 기본적으로yaml콘텐츠가stdout에 작성됩니다.
-
애플리케이션 계획을 내보내는 동안 다음 옵션을 사용합니다.
Options
-f --file=<value> Write to file instead of stdout
Options for application-plan
-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 mode2.8.6.2. 파일에서 애플리케이션 계획 가져오기
다음 명령은 애플리케이션 계획을 가져옵니다.
3scale application-plan import [opts] <remote> <service_system_name>
예제
$ docker run -v $PWD/plan.yaml:/tmp/plan.yaml registry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.7 3scale application-plan import --file=/tmp/plan.yaml remote_name service_name
이 예에서는 Docker 볼륨을 사용하여 현재 $PWD 폴더의 컨테이너에 가져온 파일을 마운트합니다.
2.8.6.3. URL에서 애플리케이션 계획 가져오기
3scale application-plan import -f http[s]://domain/resource/path.yaml remote_name service_name
가져오기 명령과 관련된 특정 명령:
명령 입력 콘텐츠는
stdin, file 또는 URL 형식일 수 있습니다.-
-f옵션으로 지정하지 않으면 기본적으로yaml콘텐츠를stdin에서 읽습니다.
-
- 원격 서비스에서 애플리케이션 계획을 찾을 수 없는 경우 생성됩니다.
선택적 param
-p,--plan원격 대상 애플리케이션 계획id또는system_name.-
-p옵션으로 지정하지 않으면 기본적으로yaml콘텐츠의 plan 속성system_name에서 애플리케이션 계획을 참조합니다.
-
- 원격 서비스에서 찾을 수 없는 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
(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 mode2.9. 메트릭
3scale toolbox를 사용하여 개발자 포털에서 메트릭을 생성, 업데이트, 나열 및 삭제합니다.
2.9.1. 메트릭 생성
메트릭을 생성하려면 다음 단계를 사용하십시오.
- 메트릭 이름을 제공해야 합니다.
-
system-name을 재정의하려면 선택적 매개변수를 사용합니다. - 동일한 이름의 메트릭이 이미 존재하는 경우 오류 메시지가 표시됩니다.
--플래그를 사용하여 비활성화된 지표를 생성합니다.disabled-
기본적으로
활성화되어있습니다.
-
기본적으로
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령은 메트릭을 생성합니다.
3scale metric create [opts] <remote> <service> <metric-name>
메트릭을 생성하는 동안 다음 옵션을 사용합니다.
Options
--description=<value> This will set a metric description
--disabled This will disable this metric in all application plans
-t --system-name=<value> This will set the application plan system name
--unit=<value> Metric unit: default hit
Option for metric
-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 This will print the version of this command
--verbose Verbose mode2.9.2. 메트릭 생성 또는 업데이트
다음 단계를 사용하여 새 메트릭을 생성하거나 기존 메트릭을 업데이트합니다.
- 동일한 이름의 메트릭이 이미 존재하는 경우 오류 메시지가 표시됩니다.
-
--플래그를 사용하여 비활성화된 지표를 업데이트합니다.disabled -
--플래그를 사용하여 활성화된 메트릭으로 업데이트합니다.enabled
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
지표위치 인수는 지표 참조이며 지표 ID 또는 지표system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령도 메트릭을 업데이트합니다.
3scale metric apply [opts] <remote> <service> <metric>
메트릭을 업데이트하는 동안 다음 옵션을 사용합니다.
Options
--description=<value> This will set a metric description
--disabled This will disable this metric in all application plans
--enabled This will enable this metric in all application plans
-n --name=<value> This will set the metric name
--unit=<value> Metric unit: default hit
Options for metric
-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 This will print the version of this command
--verbose Verbose mode2.9.3. 메트릭 나열
다음 명령은 메트릭을 나열합니다.
3scale metric list [opts] <remote> <service>
메트릭을 나열하는 동안 다음 옵션을 사용합니다.
Options for metric
-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 This will print the version of this command
--verbose Verbose mode2.9.4. 메트릭 삭제
다음 명령은 메트릭을 삭제합니다.
3scale metric delete [opts] <remote> <service> <metric>
메트릭을 삭제하는 동안 다음 옵션을 사용합니다.
Options for metric
-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 This will print the version of this command
--verbose Verbose mode2.10. 방법
3scale toolbox를 사용하여 개발자 포털에서 메서드를 생성, 적용, 나열 및 삭제합니다.
2.10.1. 방법 생성
- 메서드 이름을 제공해야 합니다.
-
system-name을 재정의하려면 선택적 매개변수를 사용합니다. - 동일한 이름의 메서드가 이미 존재하는 경우 오류 메시지가 표시됩니다.
--플래그로 비활성화된 방법을 생성합니다.disabled-
기본적으로
활성화되어있습니다.
-
기본적으로
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령은 메서드를 생성합니다.
3scale method create [opts] <remote> <service> <method-name>
방법을 생성하는 동안 다음 옵션을 사용합니다.
Option
--description=<value> This will set a method description
--disabled This will disable this method in all
application plans
-t --system-name=<value> This will set the method system name
Options for method
-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 This will print the version of this command
--verbose Verbose mode2.10.2. 방법 생성 또는 업데이트
새 메서드를 생성하지 않은 경우 새 방법을 생성하거나 기존 메서드를 업데이트하려면 다음 단계를 사용합니다.
- 동일한 이름의 메서드가 이미 있으면 명령이 실패합니다.
-
--메서드로 업데이트합니다.disabled플래그를 사용하여 disabled -
--메서드로 업데이트합니다.enabled플래그를 사용하여 활성화된
서비스위치 인수는 서비스 참조이며 서비스 ID 또는 서비스system_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
메서드위치 인수는 메서드 참조이며 메서드id또는 methodsystem_name일 수 있습니다.- 도구 상자는 둘 중 하나를 사용합니다.
다음 명령은 방법을 업데이트합니다.
3scale method apply [opts] <remote> <service> <method>
방법을 업데이트하는 동안 다음 옵션을 사용합니다.
Options
--description=<value> This will set a method description
--disabled This will disable this method in all
application plans
--enabled This will enable this method in all
application plans
-n --name=<value> This will set the method name
Options for method
-c --config-file=<value> 3scale toolbox configuration file
(default: $HOME/.3scalerc.yaml)
-h --help This will show help for this command
-k --insecure Proceed and operate even for server
connections otherwise considered insecure
-v --version This will print the version of this command
--verbose Verbose mode2.10.3. 메서드 나열
다음 명령은 방법을 나열합니다.
3scale method list [opts] <remote> <service>
메서드를 나열하는 동안 다음 옵션을 사용합니다.
Options for method
-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 This will print the version of this command
--verbose Verbose mode2.10.4. 방법 삭제
다음 명령은 방법을 삭제합니다.
3scale method delete [opts] <remote> <service> <metric>
방법을 삭제하는 동안 다음 옵션을 사용합니다.
Options for method
-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 This will print the version of this command
--verbose Verbose mode2.11. 서비스 생성
3scale toolbox를 사용하여 개발자 포털에서 서비스를 생성, 적용, 나열, 표시 또는 삭제합니다.
2.11.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
-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
(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 mode2.11.2. 서비스 생성 또는 업데이트
다음을 사용하여 새 서비스를 생성하거나 기존 서비스를 업데이트합니다.
service-id_or_system-name위치 인수는 서비스 참조입니다.-
서비스 ID 또는 서비스
일 수 있습니다.system_name - Toolbox는 자동으로 이를 파악합니다.
-
서비스 ID 또는 서비스
-
이 명령은
idempotent입니다.
다음 명령은 서비스를 업데이트합니다.
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
Options for services
-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 mode2.11.3. 서비스 나열
다음 명령은 서비스를 나열합니다.
3scale service list <remote>
서비스를 나열하는 동안 다음 옵션을 사용합니다.
Options for services
-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 mode2.11.4. 서비스 표시
다음 명령은 서비스를 보여줍니다.
3scale service show <remote> <service-id_or_system-name>
서비스를 표시하는 동안 다음 옵션을 사용합니다.
Options for services
-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 mode2.11.5. 서비스 삭제
다음 명령은 서비스를 삭제합니다.
3scale service delete <remote> <service-id_or_system-name>
서비스를 삭제하는 동안 다음 옵션을 사용합니다.
Options for services
-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 mode2.12. ActiveDocs
3scale toolbox를 사용하여 개발자 포털에서 ActiveDocs를 생성, 업데이트, 나열 또는 삭제합니다.
2.12.1. 새 ActiveDocs 생성
OpenAPI / Swagger 준수 API 정의에서 새 ActiveDocs를 생성하려면 다음을 수행합니다.
3scale에 API 정의를 추가하고 선택적으로 이름을 지정합니다.
3scale activedocs create <remote> <activedocs-name> <spec>
ActiveDocs를 생성하는 동안 다음 옵션을 사용합니다.
Options -d --description=<value> Specify the description of the ActiveDocs -i --service-id=<value> Specify the Service ID associated to the ActiveDocs -p --published Specify it to publish the ActiveDoc on the Developer Portal. Otherwise it will be hidden -s --system-name=<value> Specify the system-name of the ActiveDocs --skip-swagger-validations Specify it to skip validation of the Swagger specification Options for ActiveDocs -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- 개발자 포털에 정의를 게시합니다.
2.12.2. ActiveDocs 생성 또는 업데이트
다음 명령을 사용하여 새 ActiveDoc을 생성하거나 새 API 정의로 기존 ActiveDocs를 업데이트합니다.
3scale activedocs apply <remote> <activedocs_id_or_system_name>
ActiveDocs를 업데이트하는 동안 다음 옵션을 사용합니다.
Options
-d --description=<value> Specify the description of the
ActiveDocs
--hide Specify it to hide the ActiveDocs on
the Developer Portal
-i --service-id=<value> Specify the Service ID associated to
the ActiveDocs
--openapi-spec=<value> Specify the swagger spec. Can be a
file, an URL or '-' to read from
stdin. This option is mandatory when
applying the ActiveDoc for the first
time
-p --publish Specify it to publish the ActiveDocs
on the Developer Portal. Otherwise it
will be hidden
-s --name=<value> Specify the name of the ActiveDocs
--skip-swagger-validations Specify it to skip validation of the
Swagger specification
Options for ActiveDocs
-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 mode2.12.3. ActiveDocs 나열
다음 명령을 사용하여 다음을 포함하여 개발자 포털의 모든 ActiveDocs에 대한 정보를 가져옵니다.
- id
- name
- 시스템 이름
- description
- 게시됨(개발 포털에 표시될 수 있음)
- 생성 날짜
- 최신 업데이트 날짜
다음 명령은 정의된 모든 ActiveDocs를 나열합니다.
3scale activedocs list <remote>
ActiveDocs를 나열하는 동안 다음 옵션을 사용합니다.
Options for ActiveDocs
-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 mode2.12.4. ActiveDocs 삭제
다음 명령은 ActiveDocs를 제거합니다.
3scale activedocs delete <remote> <activedocs-id_or-system-name>
ActiveDocs를 삭제하는 동안 다음 옵션을 사용합니다.
Options for ActiveDocs
-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 mode2.13. 프록시 구성
3scale toolbox를 사용하여 개발자 포털에서 정의된 모든 프록시 구성을 나열, 표시, 승격합니다.
2.13.1. 프록시 설정 나열
다음 명령은 프록시 구성을 나열합니다.
3scale proxy-config list <remote> <service> <environment>
프록시 구성을 나열하는 동안 다음 옵션을 사용합니다.
Options for proxy-config
-c --config-file=<value> 3scale toolbox configuration file (default:
/home/msoriano/.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 mode2.13.2. 프록시 구성 표시
다음 명령은 프록시 구성을 보여줍니다.
3scale proxy-config show <remote> <service> <environment>
프록시 구성을 표시하는 동안 다음 옵션을 사용합니다.
Options for proxy-config
-c --config-file=<value> 3scale toolbox configuration file
(default: /home/msoriano/.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 mode2.13.3. 프록시 구성 승격
다음 명령은 최신 스테이징 프록시 구성을 프로덕션 환경으로 승격합니다.
3scale proxy-config promote <remote> <service>
최신 스테이징 프록시 구성을 프로덕션 환경으로 승격하는 동안 다음 옵션을 사용합니다.
Options for proxy-config
-c --config-file=<value> 3scale toolbox configuration file (default:
/home/msoriano/.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 mode2.14. 정책 레지스트리 복사(사용자 정의 정책)
다음과 같은 경우 toolbox 명령을 사용하여 3scale 소스 계정에서 대상 계정으로 정책 레지스트리를 복사합니다.
- 대상 계정에서 누락된 사용자 정의 정책이 생성됩니다.
- 대상 계정에서 일치하는 사용자 지정 정책이 업데이트됩니다.
- 이 복사 명령은 멱등입니다.
- 누락된 사용자 지정 정책은 소스 계정에 존재하고 계정 테넌트에 없는 사용자 지정 정책으로 정의됩니다.
- 일치하는 사용자 지정 정책은 소스 계정과 대상 계정 모두에 존재하는 사용자 지정 정책으로 정의됩니다.
다음 명령은 정책 레지스트리를 복사합니다.
3scale policy-registry copy [opts] <source_remote> <target_remote>
Option for policy-registry
-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 mode2.15. 애플리케이션
3scale toolbox를 사용하여 애플리케이션 개발자 포털을 나열, 생성, 표시, 적용 또는 삭제합니다.
2.15.1. 애플리케이션 나열
다음 명령은 애플리케이션을 나열합니다.
3scale application list [opts] <remote>
애플리케이션을 나열하는 동안 다음 옵션을 사용합니다.
OPTIONS
--account=<value> Filter by account
--plan=<value> Filter by application plan.
Service option required.
--service=<value> Filter by service2.15.2. 애플리케이션 생성
create 명령을 사용하여 지정된 3scale 계정 및 애플리케이션 계획에 연결된 하나의 애플리케이션을 생성합니다.
필요한 위치 매개 변수는 다음과 같습니다.
-
&
lt;service> 참조. 서비스 ID 또는 서비스일 수 있습니다.system_name &
lt;account> 참조 다음 중 하나일 수 있습니다.-
계정
ID -
계정의 admin 사용자의 사용자
이름,이메일또는user_id -
provider_key
-
계정
-
<application plan> 참조 계획 ID 중 하나이거나system_name을 계획할 수 있습니다. -
&
lt;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 to be
created.
--description=<value> Application description
--redirect-url=<value> OpenID Connect redirect url
--user-key=<value> User Key (API Key) of the application
to be created.2.15.3. 애플리케이션 표시
다음 명령은 애플리케이션을 보여줍니다.
3scale application show [opts] <remote> <application>
애플리케이션 매개변수는 다음을 허용합니다.
-
user_key- API 키 -
app_id- app_id/app_key 쌍 또는 OAuth 및 OpenID Connect (OIDC) 인증 모드의 클라이언트 ID -
애플리케이션 내부
ID
2.15.4. 애플리케이션 생성 또는 업데이트
다음 명령을 사용하여 새 애플리케이션을 생성하거나 기존 애플리케이션을 업데이트합니다.
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에서 고유하지 않으므로 name을 고유 식별자로 사용할 수 없습니다. -
--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
--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.2.15.5. 애플리케이션 삭제
다음 명령은 애플리케이션을 삭제합니다.
3scale application delete [opts] <remote> <application>
애플리케이션 매개변수는 다음을 허용합니다.
-
user_key- API 키 -
app_id- app_id/app_key 쌍 또는 OAuth 및 OIDC 인증 모드의 클라이언트 ID -
애플리케이션 내부
ID
2.16. SSL 문제 해결
이 섹션에서는 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 관련 문제를 해결하는 방법을 설명합니다.
2.16.1. 신뢰할 수 있는 인증서 설치
자체 서명된 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 오류가 발생하지 않습니다.
SSL_CERT_FILE환경 변수를3scale명령에 추가합니다. 예를 들면 다음과 같습니다.$ docker 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.7 3scale service list https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME}이 예에서는 Docker 볼륨을 사용하여 컨테이너에 인증서 파일을 마운트합니다. 파일을 현재
$PWD폴더에서 사용할 수 있다고 가정합니다.대체 방법은 3scale toolbox 이미지를 기본 이미지로 사용하여 자체 toolbox 이미지를 생성한 다음 고유한 신뢰할 수 있는 인증서 저장소를 설치하는 것입니다.
추가 리소스
- SSL 인증서에 대한 자세한 내용은 Red Hat Certificate System 설명서를 참조하십시오.
- 컨테이너 사용에 대한 자세한 내용은 Red Hat 을 참조하십시오.
- Docker 사용에 대한 자세한 내용은 https://docs.docker.com/ 을 참조하십시오.
3장. 3scale toolbox로 API 라이프사이클 자동화
이 주제에서는 Red Hat 3scale API Management를 사용한 API 라이프사이클의 개념에 대해 설명하고 API 공급자가 3scale toolbox 명령으로 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인을 사용하여 배포 단계를 자동화하는 방법을 보여줍니다. 샘플 Jenkins CI/CD 파이프라인을 배포하는 방법, 3scale 공유 라이브러리를 사용하여 사용자 정의 Jenkins 파이프라인을 생성하는 방법, 처음부터 사용자 정의 파이프라인을 생성하는 방법을 설명합니다.
3.1. API 라이프사이클 단계 개요
API 라이프사이클은 API가 더 이상 사용되지 않을 때까지 생성되는 경우의 모든 필수 활동을 설명합니다. 3scale을 사용하면 API 공급자가 전체 API 라이프사이클 관리를 수행할 수 있습니다. 이 섹션에서는 API 라이프사이클의 각 단계에 대해 설명하고 목표 및 예상 결과에 대해 설명합니다.
다음 다이어그램은 왼쪽의 API 공급자 기반 단계와 오른쪽에 API 소비자 기반 단계를 보여줍니다.

Red Hat은 현재 API 공급자 주기의 설계, 구현, 배포, 보안 및 관리 및 API 소비자 사이클의 모든 단계를 지원합니다.
3.1.1. API 공급자 사이클
API 공급자 주기 단계는 API를 지정, 개발 및 배포하는 단계를 기반으로 합니다. 다음은 각 단계의 목적과 결과를 설명합니다.
표 3.1. API 공급자 라이프사이클 단계
| Stage | 목표 | 결과 |
|---|---|---|
| 1. Strategy | 목표, 리소스, 대상 시장, 일정 기간 및 계획을 포함하여 API의 기업 전략을 결정합니다. | 기업 전략은 목표를 달성하기 위한 명확한 계획으로 정의됩니다. |
| 2. 설계 | 프로젝트 간의 종속성을 손상시키고 피드백을 수집하고 위험 및 출시 시간(예: Apicurio Studio 사용)을 줄이기 위해 API 계약을 조기에 생성합니다. | 소비자 중심 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. Deploy | 3scale toolbox의 CI/CD 파이프라인을 사용하여 API 통합, 테스트, 배포 및 관리를 자동화합니다. | CI/CD 파이프라인은 자동화된 방식으로 프로덕션 환경에 대한 API를 통합, 테스트, 배포 및 관리합니다. |
| 7. Secure | API가 안전한지 확인합니다(예: 보안 개발 관행 및 자동화된 보안 테스트 사용). | 보안 지침, 프로세스 및 게이트가 설치되어 있습니다. |
| 8. 관리 | 환경, 버전 관리, 사용 중단 및 대규모 폐기 간 API 승격을 관리합니다. | 프로세스 및 툴은 대규모 API(예: API 변경 중단을 방지하기 위해 의미 체계 버전 관리)를 관리하기 위한 것입니다. |
3.1.2. API 소비자 사이클
API 소비자 사이클 단계는 사용을 위해 API를 승격, 배포 및 조정하는 작업을 기반으로 합니다. 다음은 각 단계의 목적과 결과를 설명합니다.
표 3.2. API 소비자 라이프사이클 단계
| Stage | 목표 | 결과 |
|---|---|---|
| 9. Discover | API를 타사 개발자, 파트너 및 내부 사용자로 승격합니다. | 개발자 포털이 활성화되어 있고 최신 문서가 이 개발자 포털(예: 3scale ActiveDocs 사용)으로 지속적으로 푸시됩니다. |
| 10. 개발 | 타사 개발자, 파트너 및 내부 사용자를 안내하고 활성화하여 API를 기반으로 애플리케이션을 개발할 수 있습니다. | 개발자 포털에는 모범 사례, 가이드 및 권장 사항이 포함되어 있습니다. API 개발자는 mock 및 test 엔드포인트에 액세스하여 소프트웨어를 개발할 수 있습니다. |
| 11. Consume | 증가하는 API 사용을 처리하고 대규모로 API 소비자를 관리합니다. | 준비된 애플리케이션 계획은 소비에 사용할 수 있으며 최신 가격 및 제한이 지속적으로 제공됩니다. API 소비자는 CI/CD 파이프라인에서 API 키 또는 클라이언트 ID/시크릿 생성을 통합할 수 있습니다. |
| 12. Monitor | API 상태, 품질 및 개발자 참여에 대한 사실적이고 정량화된 피드백을 수집합니다(예: Time to first Hello World!). | 모니터링 시스템이 설치되어 있습니다. 대시보드에는 API에 대한 KPI(예: 가동 시간, 분당 요청, 대기 시간 등)가 표시됩니다. |
| 13. Monetize | 규모에 따라 새로운 소득을 유도합니다 (이 단계는 선택 사항입니다). | 예를 들어 많은 수의 소규모 API 소비자를 대상으로 하는 경우 수익화가 활성화되고 소비자는 자동화된 방식으로 사용량을 기반으로 청구됩니다. |
3.2. 샘플 Jenkins CI/CD 파이프라인 배포
3scale toolbox를 사용한 API 라이프사이클 자동화는 API 라이프사이클의 배포 단계에 중점을 두고 있으며 CI/CD 파이프라인을 사용하여 API 관리 솔루션을 자동화할 수 있습니다. 이 항목에서는 3scale toolbox를 호출하는 샘플 Jenkins 파이프라인을 배포하는 방법을 설명합니다.
- 3.2.1절. “Jenkins CI/CD 파이프라인 샘플”
- 3.2.2절. “3scale Hosted 환경 설정”
- 3.2.3절. “3scale 온-프레미스 환경 설정”
- 3.2.4절. “OpenID Connect용 Red Hat Single Sign-On 배포”
- 3.2.5절. “3scale toolbox 설치 및 액세스 활성화”
- 3.2.6절. “API 백엔드 배포”
- 3.2.7절. “자체 관리 APIcast 인스턴스 배포”
- 3.2.8절. “샘플 파이프라인 설치 및 배포”
- 3.2.9절. “3scale toolbox를 사용한 API 라이프사이클 자동화의 제한 사항”
3.2.1. Jenkins CI/CD 파이프라인 샘플
다음 샘플은 API 라이프사이클 자동화를 위해 Jenkins 파이프라인을 생성하고 배포하는 방법에 대한 예로 Red Hat Integration 리포지토리에 제공됩니다.
표 3.3. 샘플 Jenkins 공유 라이브러리 파이프라인
| 샘플 파이프라인 | 대상 환경 | 보안 |
|---|---|---|
| 3scale Hosted | API 키 | |
| APIcast 자체 관리가 포함된 3scale Hosted 및 3scale 온-프레미스 | 없음 | |
| APIcast 자체 관리가 포함된 3scale Hosted 및 3scale 온-프레미스 | OpenID Connect(OIDC) | |
| APIcast 자체 관리로 개발, 테스트 및 프로덕션에 3scale 호스팅 | API 키 | |
| APIcast 자체 관리로 개발, 테스트 및 프로덕션에 3scale 호스팅 | API 키, 없음, OIDC |
이러한 샘플은 3scale toolbox를 호출하는 3scale Jenkins 공유 라이브러리를 사용하여 주요 API 관리 기능을 보여줍니다. 이 주제에서 설정 단계를 수행한 후 Red Hat Integration 리포지토리의 각 샘플 사용 사례에 제공된 OpenShift 템플릿을 사용하여 파이프라인을 설치할 수 있습니다.
샘플 파이프라인 및 애플리케이션은 예제로만 제공됩니다. 샘플 파이프라인에서 활용하는 기본 API, CLI 및 기타 인터페이스는 Red Hat에서 완전히 지원됩니다. 파이프라인에 대한 모든 수정 사항은 Red Hat에서 직접 지원하지 않습니다.
3.2.2. 3scale Hosted 환경 설정
모든 샘플 Jenkins CI/CD 파이프라인에는 3scale Hosted 환경을 설정해야 합니다.
SaaS - API 키,다중 환경 및 Semantic 버전 관리 샘플 파이프라인은 3scale Hosted만 사용합니다. 하이브리드 - 개방형 및 하이브리드 - OIDC 파이프라인도 3scale 온-프레미스를 사용합니다. 3.2.3절. “3scale 온-프레미스 환경 설정” 을 참조하십시오.
사전 요구 사항
- Linux 워크스테이션이 있어야 합니다.
- 3scale Hosted 환경이 있어야 합니다.
OpenShift 3.11 클러스터가 있어야 합니다. OpenShift 4는 현재 지원되지 않습니다.
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
- OpenShift 설명서에 설명된 대로 OpenShift 라우터에서 와일드카드 경로가 활성화되어 있는지 확인합니다.
절차
- 3scale Hosted 관리 포털 콘솔에 로그인합니다.
- 계정 관리 API에 대한 쓰기 액세스 권한이 있는 새 액세스 토큰을 생성합니다.
나중에 사용할 수 있도록 생성된 액세스 토큰을 저장합니다. 예를 들면 다음과 같습니다.
export SAAS_ACCESS_TOKEN=123...456
나중에 사용할 수 있도록 3scale 테넌트의 이름을 저장합니다. 이는 관리 포털 URL에서
-admin.3scale.net앞의 문자열입니다. 예를 들면 다음과 같습니다.export SAAS_TENANT=my_username
- 관리 포털에서 Audience > Accounts > Listing 으로 이동합니다.
- Developer 를 클릭합니다.
개발자 계정 ID 를 저장합니다.
/buyers/accounts/이후 URL의 마지막 부분입니다. 예를 들면 다음과 같습니다.export SAAS_DEVELOPER_ACCOUNT_ID=123...456
3.2.3. 3scale 온-프레미스 환경 설정
하이브리드 - 개방형 및 프레미스 환경을 설정해야 합니다.
하이브리드 - OIDC 샘플 Jenkins CI/CD 파이프라인만 3scale 온-
이러한 하이브리드 샘플 파이프라인을 사용하려면 3scale 온-프레미스 환경과 3scale Hosted 환경을 설정해야 합니다. 3.2.2절. “3scale Hosted 환경 설정” 을 참조하십시오.
사전 요구 사항
- 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
- 관리 포털에서 Audience > Accounts > Listing 으로 이동합니다.
- Developer 를 클릭합니다.
개발자 계정 ID 를 저장합니다.
/buyers/accounts/: 이후 URL의 마지막 부분입니다.export ONPREM_DEVELOPER_ACCOUNT_ID=5
3.2.4. OpenID Connect용 Red Hat Single Sign-On 배포
Hybrid - OpenID Connect(OIDC) 또는 Semantic 버전 지정 샘플 파이프라인을 사용하는 경우 이 섹션의 단계를 수행하여 3scale과 함께 Red Hat Single Sign-On(RH-SSO)을 배포합니다. 이는 두 샘플 모두에서 사용되는 OIDC 인증에 필요합니다.
절차
RH-SSO 문서에 설명된 대로 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
3.2.5. 3scale toolbox 설치 및 액세스 활성화
이 섹션에서는 toolbox를 설치하고 원격 3scale 인스턴스를 생성하고 관리 포털에 액세스하는 데 사용되는 보안을 프로비저닝하는 방법을 설명합니다.
절차
- 2장. 3scale toolbox 사용 에 설명된 대로 3scale toolbox를 로컬로 설치합니다.
적절한 toolbox 명령을 실행하여 3scale 원격 인스턴스를 생성합니다.
3scale Hosted
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"
3.2.6. API 백엔드 배포
이 섹션에서는 샘플 파이프라인과 함께 제공되는 예제 API 백엔드를 배포하는 방법을 보여줍니다. 자체 파이프라인을 생성하고 배포할 때 필요에 따라 자체 API 백엔드를 대체할 수 있습니다.
절차
다음 샘플과 함께 사용할 수 있도록 Beer Catalog API 백엔드 예제를 배포합니다.
-
SaaS - API key -
하이브리드 - 오픈 하이브리드 - OIDCoc 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
-
나중에 사용할 수 있도록 Event API 호스트 이름을 저장합니다.
export EVENT_API_HOSTNAME="$(oc get route -n "$TOOLBOX_NAMESPACE" event-api -o jsonpath='{.spec.host}')"
3.2.7. 자체 관리 APIcast 인스턴스 배포
이 섹션은 3scale Hosted 환경의 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-rhel7:3scale2.7 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-rhel7:3scale2.7 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
3.2.8. 샘플 파이프라인 설치 및 배포
필수 환경을 설정한 후 Red Hat Integration 리포지토리의 각 샘플 사용 사례에 대해 제공된 OpenShift 템플릿을 사용하여 샘플 파이프라인을 설치하고 배포할 수 있습니다. 예를 들어 이 섹션에서는 SaaS - API 키 샘플만 보여줍니다.
절차
제공된 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
3.2.9. 3scale toolbox를 사용한 API 라이프사이클 자동화의 제한 사항
이 릴리스에는 다음과 같은 제한 사항이 적용됩니다.
- OpenShift 지원
- 샘플 파이프라인은 OpenShift 3.11에서만 지원됩니다. OpenShift 4는 현재 지원되지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
- 애플리케이션 업데이트
-
애플리케이션에
3scale application applytoolbox 명령을 사용하여 애플리케이션을 생성하고 업데이트할 수 있습니다. 계정, 계획, 서비스 및 애플리케이션 키를 지원하는 명령을 생성합니다. - 업데이트 명령은 계정, 계획 또는 서비스에 대한 변경 사항을 지원하지 않습니다. 변경 사항이 전달되면 파이프라인이 트리거되고 오류가 표시되지 않지만 해당 필드는 업데이트되지 않습니다.
-
애플리케이션에
- 서비스 복사
-
3scale copy servicetoolbox 명령을 사용하여 사용자 지정 정책으로 서비스를 복사하는 경우 사용자 정의 정책을 먼저 별도로 복사해야 합니다. - API as a Product
- 3scale toolbox는 모든 API를 Product(APIaP) 기능을 지원하지 않습니다. 자세한 내용은 3scale 릴리스 노트의 알려진 문제를 참조하십시오.
3.3. 3scale Jenkins 공유 라이브러리를 사용하여 파이프라인 생성
이 섹션에서는 3scale toolbox를 사용하는 사용자 정의 Jenkins 파이프라인을 생성하는 모범 사례를 제공합니다. 3scale Jenkins 공유 라이브러리를 사용하여 예제 애플리케이션을 기반으로 toolbox를 호출하는 Groovy에서 Jenkins 파이프라인을 작성하는 방법을 설명합니다. 자세한 내용은 Jenkins 공유 라이브러리 를 참조하십시오.
Red Hat은 Red Hat Integration 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.
이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 생성하는 사용자 정의 파이프라인은 지원되지 않습니다.
사전 요구 사항
- 3.2절. “샘플 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'])파이프라인의 다양한 단계에서 사용할 수 있도록
ThreescaleService오브젝트를 보유하도록 전역 변수를 선언합니다.def service = null
모든 관련 정보를 사용하여
ThreescaleService를 생성합니다.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() }-
Open
API.filename은 OpenAPI 사양이 포함된 파일의 경로입니다. -
environment.baseSystemName은environment.environmentName및 OpenAPI 사양info.version의 API 주요 버전을 기반으로 최종system_name을 계산하는 데 사용됩니다. -
Toolbox.openshiftProject는 Kubernetes 작업이 생성될 OpenShift 프로젝트입니다. -
Toolbox.secretName은 3.2.5절. “3scale toolbox 설치 및 액세스 활성화” 에 표시된 대로 3scale toolbox 구성 파일이 포함된 Kubernetes 시크릿의 이름입니다. -
Toolbox.destination은 3scale toolbox 원격 인스턴스의 이름입니다. -
applicationPlans는.yaml파일을 사용하거나 애플리케이션 계획 속성 세부 정보를 제공하여 생성할 애플리케이션 계획 목록입니다.
-
Open
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 Hosted 인스턴스를 사용하는 경우 프록시 정의를 가져와서 스테이징 공용 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() }
3.4. Jenkinsfile을 사용하여 파이프라인 생성
이 섹션에서는 3scale toolbox를 사용하는 Groovy에서 사용자 정의 Jenkinsfile 을 처음부터 작성하는 모범 사례를 제공합니다.
Red Hat은 Red Hat Integration 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.
이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 생성하는 사용자 정의 파이프라인은 지원되지 않습니다. 이 섹션은 참조용으로만 제공됩니다.
사전 요구 사항
- 3.2절. “샘플 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.7", "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 작업을 생성한 후 기다립니다.
-
Pod가
Created상태와Running상태 간에 전환해야 하는 시간과 일치하도록 대기 시간을 서버 속도로 조정할 수 있습니다. 폴링 루프를 사용하여 이 단계를 구체화할 수 있습니다. -
OpenAPI 사양 파일은
openapi라는ConfigMap에서 가져옵니다. -
3scale 관리 포털 호스트 이름 및 액세스 토큰은 3.2.5절. “3scale toolbox 설치 및 액세스 활성화” 와 같이
3scale-toolbox라는 시크릿에서 가져옵니다. -
ConfigMap은 3단계에서 파이프라인에 의해 생성됩니다. 그러나 시크릿은 파이프라인 외부에 이미 프로비저닝되었으며 보안을 강화하기 위해 RBAC(역할 기반 액세스 제어)가 적용됩니다.
-
Pod가
Jenkins 파이프라인 단계에서 3scale toolbox와 함께 사용할 글로벌 환경 변수를 정의합니다. 예를 들면 다음과 같습니다.
3scale Hosted
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: 3.2.5절. “3scale toolbox 설치 및 액세스 활성화” 에서 생성된 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 toolbox를 사용하여 API를 3scale로 가져오는 파이프라인 단계를 추가합니다.
3scale Hosted
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 ]) }
4장. 3scale에서 API 환경 매핑
API 공급자는 3scale 관리 포털을 통해 관리되는 API에 액세스할 수 있습니다. 그런 다음 많은 환경에서 API 백엔드를 배포합니다. API 백엔드 환경에는 다음이 포함됩니다.
- 개발, 품질 보증(QA), 스테이징 및 프로덕션에 사용되는 다양한 환경.
- 자체 API 백엔드 세트를 관리하는 팀 또는 부서에 다양한 환경이 사용됩니다.
Red Hat 3scale API Management 제품은 API의 단일 API 또는 서브 세트를 나타내지만 다른 API 백엔드 환경을 매핑하고 관리하는 데도 사용됩니다.
3scale 제품의 API 환경 매핑에 대한 자세한 내용은 다음 섹션을 참조하십시오.
4.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:
Cryostat 환경
Cryostat 백엔드 생성
- 이름: Cryo stat
- 프라이빗 기본 URL: API 백엔드의 URL
Cryostat 제품 생성
-
프로덕션 퍼블릭 기본 URL:
https://qa-api-backend.yourdomain.com -
스테이징 공개 기본 URL:
https://qa-api-backend.yourdomain.com - 백엔드 경로를 사용하여 Cryostat 백엔드 추가 /
-
프로덕션 퍼블릭 기본 URL:
프로덕션 환경
프로덕션 백엔드 생성
- 이름: Prod
- 프라이빗 기본 URL: API 백엔드의 URL
Prod 제품 생성
-
프로덕션 퍼블릭 기본 URL:
https://prod-api-backend.yourdomain.com -
스테이징 공개 기본 URL:
https://prod-api-backend.yourdomain.com - 백엔드 경로를 사용하여 프로덕션 백엔드 추가 /
-
프로덕션 퍼블릭 기본 URL:
추가 리소스
- 3scale 제품에 대한 자세한 내용은 3scale을 사용한 첫 번째 단계를 참조하십시오.
4.2. 3scale 온-프레미스 인스턴스
3scale 온-프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 여러 가지 방법이 있습니다.
- 각 API 백엔드 환경에 대해 별도의 3scale 인스턴스
- 멀티 테넌시 기능을 사용하는 단일 3scale 인스턴스
4.2.1. 환경당 3scale 인스턴스 분리
이 접근 방식에서는 각 API 백엔드 환경에 별도의 3scale 인스턴스가 배포됩니다. 이 아키텍처의 이점은 각 환경이 서로 격리되므로 공유 데이터베이스 또는 기타 리소스가 없다는 것입니다. 예를 들어 한 환경에서 수행되는 모든 로드 테스트는 다른 환경의 리소스에 영향을 미치지 않습니다.
이러한 설치 분리는 위에서 설명한 것처럼 이점이 있지만 더 많은 운영 리소스 및 유지 관리가 필요합니다. 이러한 추가 리소스는 OpenShift 관리 계층에 필요하며 3scale 계층에 반드시 필요한 것은 아닙니다.
4.2.2. 환경당 3scale 테넌트 분리
이 방법은 단일 3scale 인스턴스를 사용하지만 멀티 테넌시 기능은 여러 API 백엔드를 지원하는 데 사용됩니다.
두 가지 옵션이 있습니다.
- 단일 테넌트 내에서 환경과 3scale 제품 간에 1-to-1 매핑을 생성합니다.
필요에 따라 테넌트당 하나 이상의 제품이 있는 환경과 테넌트 간에 1-to-1 매핑을 만듭니다.
- API 백엔드 환경( dev-tenant, qa-tenant, prod-tenant)에 해당하는 테넌트 3개가 있습니다. 이 접근 방식의 이점은 환경을 논리적으로 분리할 수 있지만 공유 물리적 리소스를 사용한다는 것입니다.
API 환경을 여러 테넌트가 있는 단일 설치에 매핑하기 위한 최상의 전략을 분석할 때 공유 물리적 리소스를 고려해야 합니다.
4.3. 3scale 혼합 방식
3scale 온-프레미스 인스턴스에 설명된 접근 방식을 결합할 수 있습니다. 예를 들면 다음과 같습니다.
- 프로덕션을 위한 별도의 3scale 인스턴스입니다.
- 개발 및 Cryostat에서 비프로덕션 환경에 대해 별도의 테넌트가 있는 별도의 3scale 인스턴스입니다.
4.4. APIcast 게이트웨이가 있는 3scale
3scale 온-프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 두 가지 대안이 있습니다.
- 각 3scale 설치에는 스테이징 및 프로덕션을 위한 두 개의 임베디드 APIcast 게이트웨이가 포함되어 있습니다.
- 3scale이 실행 중인 OpenShift 클러스터에 추가 APIcast 게이트웨이를 외부에 배포합니다.
4.4.1. 임베디드 APIcast 기본 게이트웨이
내장된 APIcast 게이트웨이를 사용하면 APIcast 게이트웨이를 사용하여 3scale 에 설명된 위의 방법을 사용하여 구성된 API 백엔드가 자동으로 처리됩니다. 3scale 마스터 관리자가 테넌트를 추가하면 프로덕션 및 스테이징 임베디드 APIcast 게이트웨이에서 테넌트용 경로가 생성됩니다. 다중 테넌시 하위 도메인 이해를 참조하십시오.
-
<API_NAME>-<TENANT_NAME>-apicast.staging.<WILDCARD_DOMAIN> -
<API_NAME>-<TENANT_NAME>-apicast.production.<WIDLCARD_DOMAIN>
따라서 다른 테넌트에 매핑된 각 API 백엔드 환경에서는 고유한 경로를 가져옵니다. 예를 들면 다음과 같습니다.
-
개발자: <
API_NAME>-dev-apicast.staging.<WILDCARD_DOMAIN> -
QA:
<API_NAME>-qa-apicast.staging.<WILDCARD_DOMAIN> -
프로덕션: <
API_NAME>-prod-apicast.staging.<WILDCARD_DOMAIN>
4.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
APIcast는 구성을 다운로드하는 데 THREESCALE_PORTAL_ENDPOINT 를 사용합니다. API 백엔드 환경에 매핑되는 각 테넌트는 별도의 APIcast 게이트웨이를 사용합니다. THREESCALE_PORTAL_ENDPOINT 는 해당 API 백엔드 환경과 관련된 모든 제품 구성이 포함된 테넌트의 관리 포털로 설정됩니다.
여러 API 백엔드 환경에서 단일 APIcast 게이트웨이를 사용할 수 있습니다. 이 경우 THREESCALE_PORTAL_ENDPOINT 가 마스터 관리 포털 로 설정됩니다.
5장. 기능: Operator를 통한 3scale 서비스 및 구성 프로비저닝
이 문서에서는 OpenShift Container Platform 사용자 인터페이스를 통해 3scale Operator를 통해 3scale 제품 및 구성을 프로비저닝해야 하는 기능용 3scale Operator에 대한 정보를 설명합니다.
기능용 3scale Operator는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
5.1. 사전 요구 사항
- 3scale 2.7 온-Premises 인스턴스
- 3scale Operator가 설치되어 있어야 합니다.
OpenShift Container Platform 4.x
- OpenShift 클러스터에서 관리자 권한이 있는 사용자 계정입니다.
- 참고: OCP 4는 Operator를 사용하여 3scale 배포를 지원합니다.
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
3scale Operator를 사용하여 3scale에서 API 구성을 업데이트할 때 CRD(사용자 정의 리소스 정의)는 사실 소스입니다. Admin 사용자 인터페이스에서 변경 사항이 적용되면 유지되지 않고 결국 CRD의 정의로 재정의됩니다.
5.2. 기능 관련 사용자 정의 리소스 배포
새로 생성된 테넌트에서 Openshift Container Platform 을 사용하면 API,메트릭 및 매핑 규칙을 구성합니다.
5.2.1. API 생성
다음 절차에서는 api: api01 레이블이 있는 API를 생성합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- API 탭을 클릭합니다.
- API 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: API metadata: creationTimestamp: 2019-01-25T13:28:41Z generation: 1 labels: environment: testing name: api01 spec: planSelector: matchLabels: api: api01 description: api01 integrationMethod: apicastHosted: apiTestGetRequest: / authenticationSettings: credentials: apiKey: authParameterName: user-key credentialsLocation: headers errors: authenticationFailed: contentType: text/plain; charset=us-ascii responseBody: Authentication failed responseCode: 403 authenticationMissing: contentType: text/plain; charset=us-ascii responseBody: Authentication Missing responseCode: 403 hostHeader: "" secretToken: Shared_secret_sent_from_proxy_to_API_backend_9603f637ca51ccfe mappingRulesSelector: matchLabels: api: api01 privateBaseURL: https://echo-api.3scale.net:443 metricSelector: matchLabels: api: api01참고모든 선택기(지표,계획,mappingrules)는 특정 라벨
api: api01을 사용합니다. 레이블을 추가하고 복잡한 시나리오를 포함하도록 선택기를 구성하여 이를 변경할 수 있습니다.
5.2.2. 계획 추가
다음 절차에서는 api: api01 레이블이 있는 계획을 추가합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- 계획 탭을 클릭합니다.
- 계획 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: Plan metadata: labels: api: api01 name: plan01 spec: approvalRequired: false default: true costs: costMonth: 0 setupFee: 0 limitSelector: matchLabels: api: api01 trialPeriod: 0
5.2.3. 메트릭 추가
다음 절차에서는 metric01 이라는 지표를 추가합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- 메트릭 탭을 클릭합니다.
- 메트릭 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: Metric metadata: labels: api: api01 name: metric01 spec: description: metric01 unit: hit incrementHits: false
5.2.4. 제한 설정
다음 절차에서는 메트릭에 대해 하루에 10 번의 히트 제한이 있는 제한을 설정합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- 제한 탭을 클릭합니다.
- 제한 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: Limit metadata: labels: api: api01 name: plan01-metric01-day-10 spec: description: Limit for metric01 in plan01 maxValue: 10 metricRef: name: metric01 period: day
5.2.5. 매핑 규칙 추가
다음 절차에서는 metric01 증가에 MappingRule 을 추가합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- MappingRule 탭을 클릭합니다.
- 매핑 규칙 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: MappingRule metadata: labels: api: api01 name: metric01-get-path01 spec: increment: 1 method: GET metricRef: name: metric01 path: /path01
5.2.6. 바인딩 생성
바인딩 오브젝트를 사용하여 바인딩하려면 다음 절차를 사용하십시오.
Tenant Controller에서 생성한 인증 정보 사용
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- 바인딩 탭을 클릭합니다.
- 바인딩 생성을 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: Binding metadata: name: mytestingbinding spec: credentialsRef: name: ecorp-tenant-secret APISelector: matchLabels: environment: testing바인딩 오브젝트는
ecorp-tenant-secret을 참조하고environment: staging으로 레이블이 지정된 API 오브젝트를 만듭니다.새 3scale 테넌트로 이동하여 이전 단계에서 수행한 모든 작업이 생성되었는지 확인합니다.
참고자세한 내용은 참조 문서 Capabilities CRD 참조를 참조하십시오.
5.3. 선택적 테넌트 사용자 정의 리소스 배포
선택적으로 테넌트 사용자 지정 리소스 오브젝트를 배포하는 다른 테넌트 를 만들 수도 있습니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- Tenant 탭을 클릭합니다.
- Create Tenant 를 클릭합니다.
샘플 콘텐츠를 지우고 편집기에 다음 YAML 정의를 추가한 다음 생성 을 클릭합니다.
apiVersion: capabilities.3scale.net/v1alpha1 kind: Tenant metadata: name: ecorp-tenant spec: username: admin systemMasterUrl: https://master.<wildcardDomain> email: admin@ecorp.com organizationName: ECorp masterCredentialsRef: name: system-seed passwordCredentialsRef: name: ecorp-admin-secret tenantSecretRef: name: ecorp-tenant-secret namespace: operator-test테넌트 provider_key 및 admin 도메인 URL 은 시크릿에 저장됩니다.
tenantSecretRef테넌트 사양 키를 사용하여 시크릿 위치를 지정할 수 있습니다.참고Tenant Custom Resource 필드 및 가능한 값에 대한 자세한 내용은 Tenant CRD 참조 설명서를 참조하십시오.
5.4. 생성된 사용자 정의 리소스 삭제
다음 절차에서는 사용자 정의 리소스를 삭제하는 방법을 자세히 설명합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
삭제할 리소스의 탭을 클릭합니다.
- 이전에 생성된 리소스가 나열된 것을 확인할 수 있습니다.
- 이름을 클릭하여 개요를 확인합니다.
- 작업 > 삭제를 클릭합니다.
- 삭제 또는 취소 를 클릭하여 이전 화면으로 돌아가 삭제를 확인합니다.
또는 관련 역할 및 서비스 계정인 3scale Operator를 삭제하려면 다음을 수행합니다.
절차
메뉴 구조는 사용 중인 OpenShift 버전에 따라 다릅니다.
- OCP 4.1의 경우 카탈로그 > 설치된 Operator를 클릭합니다.
OCP 4.2의 경우 Operator > 설치된 Operator를 클릭합니다.
- 설치된 Operator 목록에서 3scale Operator를 클릭합니다.
- 작업 > 클러스터 서비스 버전 삭제를 클릭합니다.
- 삭제 또는 취소 를 클릭하여 이전 화면으로 돌아가 삭제를 확인합니다.
6장. 3scale 백업 및 복원
이 섹션에서는 Red Hat 3scale API Management 설치의 관리자가 다음을 수행하는 데 필요한 정보를 제공합니다.
- 영구 데이터에 대한 백업 절차 설정
- 영구 데이터 백업에서 복원 수행
하나 이상의 MySQL 데이터베이스로 오류가 발생하는 경우 3scale을 이전 작동 상태로 올바르게 복원할 수 있습니다.
6.1. 사전 요구 사항
- 3scale 2.7 인스턴스. 3scale 설치 방법에 대한 자세한 내용은 OpenShift에 3scale 설치를 참조하십시오.
OpenShift 클러스터에서 다음 역할 중 하나가 있는 OpenShift Container Platform 4 사용자 계정
- cluster-admin
- admin
- edit
- 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
3scale 설치 네임스페이스에 edit 클러스터 역할이 로컬로 바인딩된 사용자는 백업 및 복원 절차를 수행할 수 있습니다.
6.2. PV(영구 볼륨)
OpenShift의 3scale 배포에서 다음을 수행합니다.
- 기본 인프라에서 클러스터에 제공하는 PV(영구 볼륨)입니다.
- 클러스터 외부의 스토리지 서비스. 동일한 데이터 센터 또는 다른 곳에 있을 수 있습니다.
6.3. 고려 사항
영구 데이터의 백업 및 복원 절차는 사용 중인 스토리지 유형에 따라 다릅니다. 백업 및 복원을 위해 데이터 일관성을 유지하기 위해 데이터베이스의 기본 PV를 백업하는 것만으로는 충분하지 않습니다. 예를 들어 부분적인 쓰기와 부분 트랜잭션만 캡처하지 마십시오. 대신 데이터베이스의 백업 메커니즘을 사용합니다.
데이터의 일부는 서로 다른 구성 요소 간에 동기화됩니다. 하나의 사본은 데이터 세트에 대한 정보 소스로 간주됩니다. 다른 하나는 로컬로 수정되지는 않지만 신뢰할 수 있는 소스에서 동기화된 사본입니다. 이러한 경우 완료 시 정보 소스를 복원하고 해당 구성 요소에서 동기화된 다른 구성 요소의 복사본을 복사해야 합니다.
6.4. 데이터 세트 사용
이 섹션에서는 다양한 영구 저장소의 다양한 데이터 세트, 용도, 사용된 스토리지 유형 및 정보 소스인지에 대해 자세히 설명합니다.
3scale 배포의 전체 상태는 다음 DeploymentConfig 오브젝트 및 해당 PV에 저장됩니다.
| 이름 | 설명 |
|---|---|
|
MySQL 데이터베이스 ( | |
| 파일 볼륨 | |
|
Redis 데이터베이스( | |
|
Redis 데이터베이스( |
6.4.1. system-mysql정의
system-mysql 은 3scale 관리 콘솔에서 사용자, 계정, API, 계획 등에 대한 정보를 저장하는 관계형 데이터베이스입니다.
서비스와 관련된 이 정보의 하위 집합이 백엔드 구성 요소에 동기화되어 backend-redis 에 저장됩니다. system-mysql 은 이 정보를 위한 정보원입니다.
6.4.2. system-storage정의
여러 Pod 업로드 및 정적 파일을 읽고 수평으로 확장할 수 있으므로 RWX(ReadWriteMany) PersistentVolume 이 필요합니다.
system-storage 는 시스템 구성 요소에서 읽고 쓸 파일을 저장합니다.
두 가지 범주로 분류됩니다.
-
런타임 시
시스템구성 요소에서 읽은 구성 파일 - 정적 파일 (예: HTML, CSS, JS )은 개발자 포털을 생성하기 위해 CMS 기능으로 시스템에 업로드
6.4.3. backend-redis정의
backend-redis 에는 백엔드 구성 요소에서 사용하는 여러 데이터 세트가 포함되어 있습니다.
-
usage s:
백엔드에 의해 집계된 API 사용 정보입니다. 속도 제한 결정에백엔드및 시스템에서 UI 또는 API를통해 분석 정보를 표시하는 데 사용됩니다. -
config: 내부 API를 통해 시스템에서 동기화되는 서비스, rate-limits 등에 대한 구성 정보입니다.
이 정보 의 출처 는 아니지만System및system-mysql은 다음과 같습니다. - 대기열: 작업자 프로세스에서 실행할 백그라운드 작업의 대기열입니다. 이는 임시이며 처리된 후 삭제됩니다.
6.4.4. system-redis정의
system-redis 에는 백그라운드에서 작업을 처리할 수 있는 큐가 포함되어 있습니다. 이는 임시이며 처리된 후 삭제됩니다.
6.5. 백업 절차
다음 명령은 시스템 데이터베이스를 백업하고 보관하는 데 사용됩니다.
6.5.1. system-mysql백업
MySQL Backup 명령 실행:
oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysqldump --single-transaction -hsystem-mysql -uroot system' | gzip > system-mysql-backup.gz6.5.2. system-storage백업
system-storage 파일을 다른 스토리지에 보관합니다.
oc rsync $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system ./local/dir
6.5.3. backend-redis백업
redis에서 dump.rdb 파일을 백업합니다.
oc cp $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ./backend-redis-dump.rdb
6.5.4. system-redis백업
redis에서 dump.rdb 파일을 백업합니다.
oc cp $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb ./system-redis-dump.rdb
6.5.5. zync-database백업
zync_production 데이터베이스를 백업합니다.
oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'pg_dump zync_production' | gzip > zync-database-backup.gz
6.5.6. OpenShift 시크릿 및 ConfigMap 백업
다음은 OpenShift 시크릿 및 ConfigMap의 명령 목록입니다.
6.5.6.1. OpenShift 시크릿
oc get secrets system-smtp -o json > system-smtp.json oc get secrets system-seed -o json > system-seed.json oc get secrets system-database -o json > system-database.json oc get secrets backend-internal-api -o json > backend-internal-api.json oc get secrets system-events-hook -o json > system-events-hook.json oc get secrets system-app -o json > system-app.json oc get secrets system-recaptcha -o json > system-recaptcha.json oc get secrets system-redis -o json > system-redis.json oc get secrets zync -o json > zync.json oc get secrets system-master-apicast -o json > system-master-apicast.json
6.5.6.2. ConfigMaps
oc get configmaps system-environment -o json > system-environment.json oc get configmaps apicast-environment -o json > apicast-environment.json
6.6. 데이터베이스를 복원하는 절차
다음 명령을 사용하여 시스템 오류가 발생한 후 시스템 데이터베이스를 복원할 수 있습니다.
system-app 과 같은 Pod를 축소하거나 경로를 비활성화하여 레코드 생성을 방지합니다.
6.6.1. 템플릿 기반 배포 복원
다음 단계를 사용하여 템플릿 기반 배포를 복원합니다.
절차
템플릿을 배포하기 전에 ConfigMap을 복원합니다.
oc apply -f smtp.json
템플릿 매개변수는 복사된 보안 및 configmaps에서 읽습니다.
oc new-app --file /opt/amp/templates/amp.yml \ --param APP_LABEL=$(cat system-environment.json | jq -r '.metadata.labels.app') \ --param TENANT_NAME=$(cat system-seed.json | jq -r '.data.TENANT_NAME' | base64 -d) \ --param SYSTEM_DATABASE_USER=$(cat system-database.json | jq -r '.data.DB_USER' | base64 -d) \ --param SYSTEM_DATABASE_PASSWORD=$(cat system-database.json | jq -r '.data.DB_PASSWORD' | base64 -d) \ --param SYSTEM_DATABASE=$(cat system-database.json | jq -r '.data.URL' | base64 -d | cut -d '/' -f4) \ --param SYSTEM_DATABASE_ROOT_PASSWORD=$(cat system-database.json | jq -r '.data.URL' | base64 -d | awk -F '[:@]' '{print $3}') \ --param WILDCARD_DOMAIN=$(cat system-environment.json | jq -r '.data.THREESCALE_SUPERDOMAIN') \ --param SYSTEM_BACKEND_USERNAME=$(cat backend-internal-api.json | jq '.data.username' -r | base64 -d) \ --param SYSTEM_BACKEND_PASSWORD=$(cat backend-internal-api.json | jq '.data.password' -r | base64 -d) \ --param SYSTEM_BACKEND_SHARED_SECRET=$(cat system-events-hook.json | jq -r '.data.PASSWORD' | base64 -d) \ --param SYSTEM_APP_SECRET_KEY_BASE=$(cat system-app.json | jq -r '.data.SECRET_KEY_BASE' | base64 -d) \ --param ADMIN_PASSWORD=$(cat system-seed.json | jq -r '.data.ADMIN_PASSWORD' | base64 -d) \ --param ADMIN_USERNAME=$(cat system-seed.json | jq -r '.data.ADMIN_USER' | base64 -d) \ --param ADMIN_EMAIL=$(cat system-seed.json | jq -r '.data.ADMIN_EMAIL' | base64 -d) \ --param ADMIN_ACCESS_TOKEN=$(cat system-seed.json | jq -r '.data.ADMIN_ACCESS_TOKEN' | base64 -d) \ --param MASTER_NAME=$(cat system-seed.json | jq -r '.data.MASTER_DOMAIN' | base64 -d) \ --param MASTER_USER=$(cat system-seed.json | jq -r '.data.MASTER_USER' | base64 -d) \ --param MASTER_PASSWORD=$(cat system-seed.json | jq -r '.data.MASTER_PASSWORD' | base64 -d) \ --param MASTER_ACCESS_TOKEN=$(cat system-seed.json | jq -r '.data.MASTER_ACCESS_TOKEN' | base64 -d) \ --param RECAPTCHA_PUBLIC_KEY="$(cat system-recaptcha.json | jq -r '.data.PUBLIC_KEY' | base64 -d)" \ --param RECAPTCHA_PRIVATE_KEY="$(cat system-recaptcha.json | jq -r '.data.PRIVATE_KEY' | base64 -d)" \ --param SYSTEM_REDIS_URL=$(cat system-redis.json | jq -r '.data.URL' | base64 -d) \ --param SYSTEM_MESSAGE_BUS_REDIS_URL="$(cat system-redis.json | jq -r '.data.MESSAGE_BUS_URL' | base64 -d)" \ --param SYSTEM_REDIS_NAMESPACE="$(cat system-redis.json | jq -r '.data.NAMESPACE' | base64 -d)" \ --param SYSTEM_MESSAGE_BUS_REDIS_NAMESPACE="$(cat system-redis.json | jq -r '.data.MESSAGE_BUS_NAMESPACE' | base64 -d)" \ --param ZYNC_DATABASE_PASSWORD=$(cat zync.json | jq -r '.data.ZYNC_DATABASE_PASSWORD' | base64 -d) \ --param ZYNC_SECRET_KEY_BASE=$(cat zync.json | jq -r '.data.SECRET_KEY_BASE' | base64 -d) \ --param ZYNC_AUTHENTICATION_TOKEN=$(cat zync.json | jq -r '.data.ZYNC_AUTHENTICATION_TOKEN' | base64 -d) \ --param APICAST_ACCESS_TOKEN=$(cat system-master-apicast.json | jq -r '.data.ACCESS_TOKEN' | base64 -d) \ --param APICAST_MANAGEMENT_API=$(cat apicast-environment.json | jq -r '.data.APICAST_MANAGEMENT_API') \ --param APICAST_OPENSSL_VERIFY=$(cat apicast-environment.json | jq -r '.data.OPENSSL_VERIFY') \ --param APICAST_RESPONSE_CODES=$(cat apicast-environment.json | jq -r '.data.APICAST_RESPONSE_CODES') \ --param APICAST_REGISTRY_URL=$(cat system-environment.json | jq -r '.data.APICAST_REGISTRY_URL')
6.6.2. Operator 기반 배포 복원
다음 단계를 사용하여 Operator 기반 배포를 복원합니다.
절차
- OpenShift에 3scale Operator를 설치합니다.
APIManager 리소스를 생성하기 전에 보안을 복원합니다.
oc apply -f system-smtp.json oc apply -f system-seed.json oc apply -f system-database.json oc apply -f backend-internal-api.json oc apply -f system-events-hook.json oc apply -f system-app.json oc apply -f system-recaptcha.json oc apply -f system-redis.json oc apply -f zync.json oc apply -f system-master-apicast.json
APIManager 리소스를 생성하기 전에 ConfigMap을 복원합니다.
oc apply -f system-environment.json oc apply -f apicast-environment.json
- APIManager 사용자 정의 리소스 를 사용하여 Operator와 함께 3scale 을 배포합니다.
6.6.3. system-mysql복원
MySQL 덤프를 system-mysql pod에 복사합니다.
oc cp ./system-mysql-backup.gz $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq '.items[0].metadata.name' -r):/var/lib/mysql
백업 파일의 압축을 풉니다.
oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/system-mysql-backup.gz'MySQL DB Backup 파일을 복원합니다.
oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysql -hsystem-mysql -uroot system < ${HOME}/system-mysql-backup'
6.6.4. system-storage복원
백업 파일을 system-storage로 복원합니다.
oc rsync ./local/dir/system/ $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system
6.6.5. zync-database복원
zync-database 를 복원하는 지침은 3scale에 적용된 배포 유형에 따라 다릅니다.
템플릿 기반 배포
zync DeploymentConfig를 0 Pod로 축소합니다.
oc scale dc zync --replicas=0 oc scale dc zync-que --replicas=0
Zync 데이터베이스 덤프를
zync-databasePod에 복사합니다.oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/
백업 파일의 압축을 풉니다.
oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/zync-database-backup.gz'PostgreSQL DB 백업 파일을 복원합니다.
oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'psql -f ${HOME}/zync-database-backup'아래 명령에서
${ZYNC_REPLICAS}를 복제본 수로 교체하여 원래 복제본 수로 복원합니다.oc scale dc zync --replicas=${ZYNC_REPLICAS} oc scale dc zync-que --replicas=${ZYNC_REPLICAS}
Operator를 사용하여 3scale 배포 (특히 APIManager 사용자 정의 리소스 배포)의 지침에 따라 3scale 인스턴스를 재배포합니다.
${DEPLOYMENT_NAME}을 3scale 배포를 생성할 때 정의한 이름으로 교체하여 복제본 수를 저장합니다.ZYNC_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o json | jq -r '.spec.zync'`zync DeploymentConfig를 0 Pod로 축소합니다.
oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync": {"appSpec": {"replicas": 0}, "queSpec": {"replicas": 0}}}}'Zync 데이터베이스 덤프를
zync-databasePod에 복사합니다.oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/
백업 파일의 압축을 풉니다.
oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/zync-database-backup.gz'PostgreSQL DB 백업 파일을 복원합니다.
oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'psql -f ${HOME}/zync-database-backup'원래 복제본 수로 복원합니다.
oc patch APIManager ${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync":'"${ZYNC_SPEC}"'}}'
6.6.6. backend-redis 및 system-redis를 사용하여 3scale 옵션 복원
3scale을 복원하면 backend-redis 및 system-redis 를 복원합니다. 이러한 구성 요소에는 다음과 같은 기능이 있습니다.
*backend-redis: 3scale의 애플리케이션 인증 및 속도 제한을 지원하는 데이터베이스입니다. 또한 통계 스토리지 및 임시 작업 스토리지에 사용됩니다. *system-redis: 3scale의 백그라운드 작업에 대한 임시 스토리지를 제공하고 system-app pod의 Ruby 프로세스에 대한 메시지 버스로도 사용됩니다.
backend-redis 구성 요소
backend-redis 구성 요소에는 데이터 및 대기열 이라는 두 개의 데이터베이스가 있습니다. 기본 3scale 배포에서 데이터 및 큐 는 Redis 데이터베이스에 배포되지만 서로 다른 논리 데이터베이스 인덱스 /0 및 /1 에서 배포됩니다. 데이터 데이터베이스를 복원하면 문제 없이 실행되지만 큐 데이터베이스를 복원하면 중복 작업이 발생할 수 있습니다.
작업 복제와 관련하여 3scale에서 백엔드 작업자는 백그라운드 작업을 밀리초 단위로 처리합니다. backend-redis 가 마지막 데이터베이스 스냅샷 후 30초 후에 실패하고 복원하려고 하면 백엔드에 중복을 방지하기 위해 시스템이 없으므로 30초 동안 발생한 백그라운드 작업이 두 번 수행됩니다.
이 시나리오에서는 /0 데이터베이스 인덱스에 다른 위치에 저장되지 않은 데이터가 포함되어 있으므로 백업을 복원해야 합니다. /0 데이터베이스 인덱스를 복원하면 다른 인덱스 없이 저장할 수 없으므로 /1 데이터베이스 인덱스도 복원해야 합니다.
서로 다른 인덱스에서 하나의 데이터베이스가 아닌 다른 서버에서 데이터베이스를 분리하도록 선택하면 큐의 크기가 약 0이므로 백업을 복원하지 않고 몇 가지 백그라운드 작업이 손실되는 것이 좋습니다. 이는 3scale Hosted 설정의 경우 둘 다에 대해 다른 백업 및 복원 전략을 적용해야 합니다.
'system-redis' 구성 요소
3scale 시스템 백그라운드 작업의 대부분은 멱등입니다. 즉, 동일한 요청은 실행하는 횟수에 관계없이 동일한 결과를 반환합니다.
다음은 시스템의 백그라운드 작업에서 처리하는 이벤트 예제 목록입니다.
- 계획 시험 만료에 대한 알림 작업, 신용 카드 만료 정보, 활성화 알림, 계획 변경, 송장 상태 변경, PDF 보고서
- 인보이스 및 과금과 같은 청구.
- 복잡한 오브젝트 삭제.
- 백엔드 동기화 작업.
- 인덱스 작업(예: sphinx 사용).
- Sanitization 작업(예: 송장 ID)
- 감사 제거, 사용자 세션, 만료된 토큰, 로그 항목, 비활성 계정 일시 중단과 같은 janitorial 작업.
- 트래픽 업데이트.
- 프록시 구성 변경 모니터링 및 프록시 배포
- 배경 등록 작업,
- SSO(Single Sign-On) 동기화, 경로 생성과 같은 zync 작업.
위의 작업 목록을 복원하는 경우 3scale 시스템은 복원된 각 작업의 상태를 유지 관리합니다. 복원이 완료된 후 시스템의 무결성을 확인하는 것이 중요합니다.
6.6.7. 백엔드 와 시스템간의 정보 일관성 보장
backend-redis 를 복원한 후 시스템에서 구성 정보를 동기화해야 합니다. 백엔드 의 정보가 정보 소스인 시스템 내의 정보와 일치하도록 해야 합니다.
6.6.7.1. backend-redis의 배포 구성 관리
이러한 단계는 backend-redis 의 인스턴스를 실행하기 위한 것입니다.
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-configconfigmap에서appendonly를 no 로 설정합니다.appendonly no
backend-redis를 다시 배포하여 새 구성을 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
dump.rdb파일의 이름을 변경합니다.oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'appendonly.aof파일의 이름을 변경합니다.oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'백업 파일을 POD로 이동합니다.
oc cp ./backend-redis-dump.rdb $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb
backend-redis를 다시 배포하여 백업을 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
appendonly파일을 생성합니다.oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
잠시 후 AOF 재작성이 완료되었는지 확인합니다.
oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
-
aof_rewrite_in_progress = 1이지만 실행이 진행 중입니다. -
aof_rewrite_in_progress = 0까지 주기적으로 확인합니다. 0은 실행이 완료되었음을 나타냅니다.
-
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령 주석 처리를 해제합니다.save 900 1 save 300 10 save 60 10000
redis-configconfigmap에서appendonly를 yes 로 설정합니다.appendonly yes
backend-redis를 다시 배포하여 기본 구성을 다시 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
6.6.7.2. system-redis의 배포 구성 관리
이러한 단계는 system-redis 의 인스턴스를 실행하기 위한 것입니다.
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-configconfigmap에서appendonly를 no 로 설정합니다.appendonly no
system-redis를 다시 배포하여 새 구성을 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
dump.rdb파일의 이름을 변경합니다.oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'appendonly.aof파일의 이름을 변경합니다.oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'백업파일을 POD로 이동합니다.oc cp ./system-redis-dump.rdb $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb
백업을 로드하도록
system-redis를 재배포합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
appendonly파일을 생성합니다.oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
잠시 후 AOF 재작성이 완료되었는지 확인합니다.
oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
-
aof_rewrite_in_progress = 1이지만 실행이 진행 중입니다. -
aof_rewrite_in_progress = 0까지 주기적으로 확인합니다. 0은 실행이 완료되었음을 나타냅니다.
-
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령 주석 처리를 해제합니다.save 900 1 save 300 10 save 60 10000
redis-configconfigmap에서appendonly를 yes 로 설정합니다.appendonly yes
system-redis를 다시 배포하여 기본 구성을 다시 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
6.6.8. 백엔드 작업자복원
backend-worker의 최신 버전으로 복원 :oc rollout latest dc/backend-worker
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-worker
6.6.9. system-app복원
최신 버전의
system-app으로 복원 :oc rollout latest dc/system-app
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-app
6.6.10. system-sidekiq복원
최신 버전의
system-sidekiq로 복원하십시오.oc rollout latest dc/system-sidekiq
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sidekiq
6.6.11. system-sphinx복원
최신 버전의
system-sphinx로 복원 :oc rollout latest dc/system-sphinx
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sphinx
6.6.12. Zync에서 관리하는 OpenShift 경로 복원
Zync가 누락된 OpenShift 경로를 다시 생성하도록 강제 적용합니다.
oc rsh $(oc get pods -l 'deploymentConfig=system-sidekiq' -o json | jq '.items[0].metadata.name' -r) bash -c 'bundle exec rake zync:resync:domains'
7장. 문제 해결
이 가이드에서는 API 인프라의 문제를 식별하고 해결하는 데 도움이 되는 것을 목표로 합니다.
API 인프라는 길고 복잡한 주제입니다. 그러나 최소한 인프라에는 세 가지 이동 부분이 있습니다.
- API 게이트웨이
- 3scale
- API

이러한 세 가지 요소에 오류가 발생하면 클라이언트가 API에 액세스할 수 없습니다. 그러나 오류를 발생시킨 구성 요소를 찾기가 어렵습니다. 이 가이드에서는 문제를 식별하기 위해 인프라 문제를 해결할 수 있는 몇 가지 팁을 제공합니다.
7.1. 일반적인 문제
3scale과의 통합과 관련된 몇 가지 일반적인 문제를 가리킬 수 있는 몇 가지 증거가 있습니다. 이는 API 프로젝트 시작, 인프라 설정 또는 이미 프로덕션 단계에 있는지에 따라 달라집니다.
7.1.1. 통합 문제
다음 섹션에서는 3scale과의 통합 초기 단계에서 APIcast 오류 로그에 표시될 수 있는 몇 가지 일반적인 문제를 간략하게 설명합니다. 시작 시 APIcast Hosted를 사용하기 전에 자체 관리 APIcast를 실행합니다.
7.1.1.1. APIcast 호스팅
Service Integration 화면에서 API를 APIcast Hosted와 처음 통합할 때 페이지에 표시되는 다음 오류 중 일부가 표시되거나 테스트 호출에 반환되어 성공적인 통합을 확인할 수 있습니다.
테스트 요청에 실패했습니다: 실행이 만료됨공용 인터넷에서 API에 연결할 수 있는지 확인합니다. APIcast Hosted는 프라이빗 API와 함께 사용할 수 없습니다. API를 APIcast Hosted와 통합할 수 있도록 공개하지 않으려면 APIcast Hosted와 API 간에 개인 시크릿을 설정하여 API 게이트웨이에서 가져오지 않는 호출을 거부할 수 있습니다.
허용된 형식은 'protocol://address(:port)'입니다.
API 개인 기본 URL 끝에 있는 모든 경로를 제거합니다. "mapping rules" 패턴 또는 API 테스트 GET 요청의 시작 부분에 추가할 수 있습니다.
HTTP 코드 XXX로 테스트 요청에 실패했습니다.-
405: 끝점이 GET 요청을 수락하는지 확인합니다. APIcast는 통합을 테스트하기 위한 GET 요청만 지원합니다. -
403: 인증 매개변수가 누락됨: API에 이미 일부 인증이 있는 경우 APIcast는 테스트 요청을 수행할 수 없습니다. -
403: 인증에 실패했습니다. 3scale로 생성한 첫 번째 서비스가 아닌 경우 인증정보를 사용하여 애플리케이션을 생성했는지 확인하여 테스트 요청을 수행합니다. 통합할 첫 번째 서비스인 경우 등록 시 생성한 테스트 계정 또는 애플리케이션을 삭제하지 않았는지 확인하십시오.
-
7.1.1.2. APIcast 자체 관리
APIcast 자체 관리와의 통합을 성공적으로 테스트한 후 API 게이트웨이를 직접 호스팅할 수 있습니다. 다음은 자체 관리 게이트웨이를 처음 설치하고 이를 통해 API를 호출할 때 발생할 수 있는 몇 가지 오류입니다.
업스트림에 연결하는 동안 업스트림 시간 초과(연결 시간 초과)자체 관리 게이트웨이가 3scale에 도달하지 못하도록 API 게이트웨이와 공용 인터넷 사이에 방화벽 또는 프록시가 없는지 확인합니다.
서비스 목록을 가져올 수 없음: 잘못된 상태: 403 (Forbidden)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값에서 사용한 액세스 토큰이 올바르고 계정 관리 API 범위가 있는지 확인합니다.을 사용하여 확인합니다.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을 구성한 후 다음을 수행합니다.
-
"production"으로 APIcast가 구성되었는지 확인합니다(
THREESCALE_DEPLOYMENT_ENV변수로 재정의하지 않는 경우 독립 실행형 APIcast의 기본 구성). 구성을 프로덕션으로 승격해야 합니다. -
APICAST_CONFIGURATION_CACHE및APICAST_CONFIGURATION_LOADER환경 변수를 사용하여 구성 자동 로드를 구성하지 않은 경우 APIcast를 다시 시작합니다.
-
"production"으로 APIcast가 구성되었는지 확인합니다(
다음은 잘못된 APIcast 자체 관리 통합을 가리킬 수 있는 몇 가지 다른 증상입니다.
- API 호출이 일치하지 않는 매핑 규칙: API 에서 메서드와 실제 URL 끝점 간의 매핑을 정의한 방식에 따라 메서드가 일치하지 않거나 요청당 한 번 이상 증가되는 경우가 있음을 알 수 있습니다. 이 문제를 해결하려면 3scale 디버그 헤더 를 사용하여 API를 테스트하십시오. 그러면 API 호출과 일치하는 모든 메서드 목록이 반환됩니다.
- 인증 매개변수를 찾을 수 없음: 서비스 통합 화면에 지정된 대로 매개변수를 올바른 위치로 전송했는지 확인합니다. 자격 증명을 헤더로 보내지 않으면 인증 정보를 다른 모든 HTTP 메서드의 GET 요청 및 본문 매개변수에 대한 쿼리 매개변수로 보내야 합니다. 3scale 디버그 헤더를 사용하여 API 게이트웨이에서 요청에서 읽을 수 있는 인증 정보를 다시 확인합니다.
7.1.2. 프로덕션 문제
설정을 완전히 테스트한 후 잠시 동안 API 게이트웨이에서 발생하는 문제가 발생하지 않는 경우가 많습니다. 그러나 라이브 프로덕션 환경에서 발생할 수 있는 몇 가지 문제는 다음과 같습니다.
7.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 게이트웨이 구성 파일의 최신 버전은 3scale을 변수로 정의하여 매번 IP 확인을 강제 적용합니다. 빠른 수정을 위해 NGINX 인스턴스를 다시 로드합니다. 장기 수정의 경우 업스트림 블록에서 3scale 백엔드를 정의하는 대신 각 server 블록 내에서 변수로 정의합니다.
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 확인자를 설정합니다.resolver 8.8.8.8.8.4.4;. -
API 기본 URL을
server섹션 상단에 있는 변수로 설정합니다.set $api_base "http://api.example.com:80"; -
location /section에서proxy_pass행을 찾아서proxy_pass $api_base로 바꿉니다.
-
7.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 이동의 모든 단계에서 발생할 수 있는 가장 일반적인 잘 알려진 문제에 대한 개요를 제공합니다.
이러한 모든 항목이 확인되었으며 여전히 문제에 대한 원인 및 솔루션을 찾을 수 없는 경우 아래의 보다 자세한 [operational troubleshooting](#troubleshooting-checklists) 섹션으로 진행해야 합니다. API에서 시작하고 실패 지점을 식별할 수 있도록 클라이언트로 다시 작업합니다.
7.2. 문제 해결 101
이 API 게이트웨이, 3scale 또는 API인지 여부에 관계없이 서버에 연결할 때 오류가 발생하는 경우 다음 문제 해결 단계가 첫 번째 호출 포트여야 합니다.
7.2.1. 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
7.2.2. 2. 저입니까, 아니면 저입니까?
서로 다른 네트워크 위치, 장치 및 방향에서 동일한 서버에 연결을 시도합니다. 예를 들어 클라이언트가 API에 연결할 수 없는 경우 API 게이트웨이와 같은 액세스 권한이 있어야 하는 시스템에서 API에 연결을 시도합니다.
시도된 연결 중 하나라도 성공하면 실제 서버의 문제를 배제하고 네트워크 문제 해결에 집중하여 문제가 발생할 가능성이 큽니다.
7.2.3. 3. DNS 문제입니까?
호스트 이름 대신 IP 주소를 사용하여 서버에 연결을 시도합니다(예: telnet apis.io 80대신 telnet 94.125.104.17 80 ).
이렇게 하면 DNS의 문제가 배제됩니다.
호스트가 확인할 수 있는 여러 IP가 있다고 의심되는 경우 를 사용하여 서버의 IP 주소를 가져올 수 있습니다.
dig 3scale su1.3 scale.net과 같이 dig
Nb: 일부 호스트는 'dig any'를 차단합니다
7.2.4. 4. SSL 문제입니까?
OpenSSL을 사용하여 테스트할 수 있습니다.
쉘 프롬프트
openssl s_client -connect su1.3scale.net:443과 같은 호스트 또는 IP에 대한 보안 연결출력:
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 도움말 페이지를 참조하십시오.
7.3. 문제 해결 체크리스트
API에 대한 요청이 있을 수 있는 위치를 확인하려면 다음 검사를 수행합니다.
7.3.1. API
API가 up이고 요청에 응답하는지 확인하려면 API에 직접 동일한 요청을 수행합니다(API 게이트웨이를 통과하지 않음). API 게이트웨이를 통과하는 요청과 동일한 매개변수 및 헤더를 보내고 있는지 확인해야 합니다. 실패하는 정확한 요청이 확실하지 않은 경우 API 게이트웨이와 API 간 트래픽을 캡처합니다.
호출이 성공하면 API에 대한 문제를 제외할 수 있습니다. 그렇지 않으면 API의 문제를 추가로 해결해야 합니다.
7.3.2. API 게이트웨이 > API
API 게이트웨이와 API 간의 네트워크 문제를 제외하려면 API 게이트웨이 서버에서 앞에 있는 직접 API를 통해 직접 API 게이트웨이 서버와 동일한 호출을 수행합니다.
호출이 성공하면 API 게이트웨이 자체의 문제 해결으로 이동할 수 있습니다.
7.3.3. API 게이트웨이
API 게이트웨이가 올바르게 작동하는지 확인하는 여러 단계가 있습니다.
7.3.3.1. 1. API 게이트웨이가 실행 중입니까?
게이트웨이가 실행 중인 시스템에 로그인합니다. 이 오류가 발생하면 게이트웨이 서버가 다운되었을 수 있습니다.
로그인한 후 NGINX 프로세스가 실행 중인지 확인합니다. 이를 위해 ps ax | grep nginx 또는 htop 를 실행합니다.
목록에 nginx 마스터 프로세스 및 NGINX가 실행됩니다.
nginx 작업자 프로세스가 표시되면
7.3.3.2. 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"
7.3.4. API 게이트웨이 > 3scale
API 게이트웨이가 올바르게 실행 중인지 확인한 후 다음 단계는 API 게이트웨이와 3scale 간의 연결 문제를 해결하는 것입니다.
7.3.4.1. 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를 사용할 수 있습니다.
7.3.4.2. 2. 3scale 주소를 올바르게 확인하는 API 게이트웨이가 있습니까?
nginx.conf에 resolver 지시문이 추가되었는지 확인합니다.
예를 들어 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.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 Service Management API에서 현재 작업 중인 IP 주소를 확인합니다. 이는 3scale에서 사용할 수 있는 IP 주소의 전체 범위가 아닙니다. 일부 IP 주소는 용량상의 이유로 교체 및 해제될 수 있습니다. 또한 향후 3scale 서비스에 대한 도메인 이름을 추가할 수 있습니다. 이를 위해 통합 중에 제공된 특정 주소에 대해 항상 테스트해야 합니다(해당하는 경우).
7.3.4.3. 3. API 게이트웨이가 3scale을 올바르게 호출합니까?
문제 해결을 위해 API 게이트웨이가 3scale에 요청하는 경우 nginx.conf 의 3scale authrep 위치(API 키 및 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: Cryostat_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/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:)은 3scale로 전송된 요청 헤더를 출력합니다. 이 경우 Host, User-Agent, Accept, X-Forwarded-Proto 및 X-Forwarded-For.
두 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:: )은 3scale의 응답을 출력합니다. < error code="access_token_invalid">access_token "7c6f24f5"는 유효하지 않습니다.
둘 다 원래 요청(GET /api/contacts.access_token_token=7c6f24f5) 및 하위 요청 위치(/threescale_authrep)와 업스트림 요청(upstream: "https://54.83.62.94:443/transactions/threescale_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5".)을 출력합니다. 이 마지막 값을 사용하면 어떤 3scale IP가 해결되었는지와 3scale에 대한 정확한 요청을 확인할 수 있습니다.
7.3.5. 3scale
7.3.5.1. 1. 3scale을 사용할 수 있습니까?
Twitter에서 3scale 상태 페이지 또는 @3scalestatus 를 확인합니다.
7.3.5.2. 2. 3scale에서 오류를 반환합니까?
3scale을 사용할 수도 있지만 API 게이트웨이로 오류를 반환하여 API로 이동하는 호출을 방지할 수 있습니다. 3scale에서 직접 권한 부여 호출을 수행하고 응답을 확인합니다. 오류가 발생하면 #troubleshooting-api-error-codes[오류 코드] 섹션을 확인하여 문제가 무엇인지 확인합니다.
7.3.5.3. 3. 3scale 디버그 헤더 사용
X-3scale-debug 헤더를 사용하여 API를 호출하여 3scale 디버그 헤더를 켤 수도 있습니다.
curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug: Cryostat_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 < X-3scale-matched-rules: /aos/internal/gate_status/v1/flights/histories < X-3scale-credentials: user_key=b3ad95279b0600a2595165404fbae70c < X-3scale-usage: usage%5Bhits%5D=1 < X-3scale-hostname: apicast-staging-3-nkhnn < X-3scale-service-id: 2 < X-3scale-service-name: api
7.3.5.4. 4. 통합 오류 확인
3scale으로의 트래픽에 대한 문제가 있는지 확인하려면 https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors 에서 관리 포털의 통합 오류를 참조하십시오.
통합 오류의 이유 중 하나는 server 블록에서 사용할 수 없는 underscores_in_headers 지시문을 사용하여 헤더에서 인증 정보를 보내는 것입니다.
7.3.6. 클라이언트 API 게이트웨이
7.3.6.1. 1. 공용 인터넷에서 API 게이트웨이에 연결할 수 있습니까?
브라우저를 게이트웨이 서버의 IP 주소(또는 도메인 이름)로 전달해 보십시오. 이 작업이 실패하면 관련 포트에서 방화벽을 열 수 있는지 확인합니다.
7.3.6.2. 2. 클라이언트에서 API 게이트웨이에 연결할 수 있습니까?
가능한 경우 이전에 설명한 방법(telnet, curl 등) 중 하나를 사용하여 클라이언트에서 API 게이트웨이에 연결을 시도합니다. 연결에 실패하면 문제가 둘 사이의 네트워크에 있습니다.
그렇지 않으면 클라이언트의 문제 해결으로 API를 호출해야 합니다.
7.3.7. 클라이언트
7.3.7.1. 1. 다른 클라이언트를 사용하여 동일한 호출을 테스트합니다.
요청이 예상된 결과를 반환하지 않으면 다른 HTTP 클라이언트로 테스트합니다. 예를 들어 Java HTTP 클라이언트를 사용하여 API를 호출하고 cURL을 사용하여 잘못된 내용이 표시되는 경우입니다.
클라이언트와 게이트웨이 간에 프록시를 통해 API를 호출하여 클라이언트에서 보내는 정확한 매개변수와 헤더를 캡처할 수도 있습니다.
7.3.7.2. 2. 클라이언트에서 보낸 트래픽 검사
Wireshark와 같은 도구를 사용하여 클라이언트가 수행하는 요청을 확인합니다. 그러면 클라이언트가 API를 호출하는지 여부와 요청의 세부 정보를 확인할 수 있습니다.
7.4. 기타 문제
7.4.1. ActiveDocs 문제
ActiveDocs를 통과할 때 명령줄에서 API를 호출할 때 작동하는 경우가 있습니다.
ActiveDocs 호출이 작동하도록 하기 위해, 당사는 당사의 프록시를 통해 이러한 호출을 보냅니다. 이 프록시는 예상되지 않은 경우 API에 문제가 발생할 수 있는 특정 헤더를 추가합니다. 이 경우 다음 단계를 수행합니다.
7.4.1.1. 1. petstore.swagger.io 사용
swagger는 petstore.swagger.io에서 호스팅되는 swagger-ui를 제공하며 최신 버전의 swagger-ui를 통해 제공되는 Swagger 사양 및 API를 테스트할 수 있습니다. swagger-ui와 ActiveDocs가 모두 동일한 방식으로 실패하는 경우 ActiveDocs 또는 ActiveDocs 프록시의 문제를 배제하고 자체 사양에서 문제 해결에 중점을 둘 수 있습니다. 또는 swagger-ui 현재 버전의 swagger-ui와 관련된 알려진 문제에 대해 swagger-ui GitHub 리포지터리를 확인할 수 있습니다.
7.4.1.2. 2. 방화벽에서 ActiveDocs 프록시의 연결을 허용하는지 확인합니다.
API를 사용하는 클라이언트의 IP 주소를 허용 목록에 추가하지 않는 것이 좋습니다. ActiveDocs 프록시는 고가용성을 위해 유동 IP 주소를 사용하며 현재 이러한 IP 변경 사항을 알리는 메커니즘이 없습니다.
7.4.1.3. 3. 잘못된 인증 정보를 사용하여 API 호출
ActiveDocs 프록시가 올바르게 작동하는지 확인하는 한 가지 방법은 잘못된 인증 정보를 사용하여 API를 호출하는 것입니다. 이렇게 하면 ActiveDocs 프록시 및 API 게이트웨이 둘 다의 문제를 확인하거나 제외할 수 있습니다.
API 호출에서 403 코드를 다시 가져오는 경우(또는 잘못된 인증 정보에 대해 게이트웨이에서 구성한 코드에서) 호출이 게이트웨이에 도달했기 때문에 API에 문제가 발생합니다.
7.4.1.4. 4. 호출 비교
ActiveDocs와 ActiveDocs 외부에서 이루어진 호출 간 헤더와 매개변수의 차이점을 확인하려면 HTTP 호출을 검사 및 비교할 수 있는 일부 서비스(내부, 실행 범위 등)를 통해 호출을 실행하는 것이 도움이 될 수 있습니다. 이렇게 하면 문제가 발생할 수 있는 요청의 잠재적인 헤더 및/또는 매개변수를 식별할 수 있습니다.
7.5. 동일한 Zync 경로 생성
Zync의 동일한 경로 생성을 수행하려면 OpenShift가 Zync로 라우팅하는 모든 3scale API 및 테넌트를 다시 동기화합니다.
oc exec -t $(oc get pods -l 'deploymentConfig=system-sidekiq' -o json | jq '.items[0].metadata.name' -r) -- bash -c "bundle exec rake zync:resync:domains"
시스템에 대한 알림에 대한 정보가 포함된 다음 출력이 표시됩니다.
No valid API key has been set, notifications will not be sent
ActiveMerchant MODE set to 'production'
[Core] Using http://backend-listener:3000/internal/ as URL
OpenIdAuthentication.store is nil. Using in-memory store.
[EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 59a554f6-7b3f-4246-9c36-24da988ca800
[EventBroker] notifying subscribers of ZyncEvent caa8e941-b734-4192-acb0-0b12cbaab9ca
Enqueued ZyncWorker#d92db46bdba7a299f3e88f14 with args: ["caa8e941-b734-4192-acb0-0b12cbaab9ca", {:type=>"Provider", :id=>1, :parent_event_id=>"59a554f6-7b3f-4246-9c36-24da988ca800", :parent_event_type=>"Domains::ProviderDomainsChangedEvent", :tenant_id=>1}]
[EventBroker] notifying subscribers of Domains::ProviderDomainsChangedEvent 9010a199-2af1-4023-9b8d-297bd618096f
…Zync를 강제 평가한 후 기존 테넌트 및 서비스에 대해 새 경로가 생성됩니다. 서비스 및 테넌트 수에 따라 경로 생성에 몇 분이 걸릴 수 있습니다.
7.6. 부록
7.6.1. NGINX에 로그인
이에 대한 포괄적인 안내서는 NGINX 로깅 및 모니터링 문서를 참조하십시오.
7.6.1.1. 디버깅 로그 활성화
디버깅 로그 활성화에 대한 자세한 내용은 NGINX 디버깅 로그 설명서 를 참조하십시오.
7.6.2. 3scale 오류 코드
3scale Service Management API 끝점에서 반환된 오류 코드를 두 번 확인하려면 다음 단계를 수행하여 3scale API 문서 페이지를 참조하십시오.
- 관리 포털의 오른쪽 상단에 있는 물음표(?) 아이콘을 클릭합니다.
- 3scale API 문서 를 선택합니다.
다음은 3scale에서 반환된 목록 HTTP 응답 코드와 해당 코드가 반환되는 조건입니다.
400: 잘못된 요청입니다. 그 이유는 다음과 같습니다.
- 잘못된 인코딩
- 페이로드가 너무 큽니다
-
콘텐츠 유형이 잘못되었습니다(POST 호출의 경우).
Content-Type헤더의 유효한 값은application/x-www-form-urlencoded,multipart/form-data또는 empty header입니다.
403:
- 인증 정보가 유효하지 않음
- GET 요청에 대해 3scale로 본문 데이터 전송
- 404: 애플리케이션, 메트릭 등과 같이 참조되는 존재하지 않는 엔티티입니다.
409:
- 사용량 제한 초과
- 애플리케이션이 활성 상태가 아닙니다
-
애플리케이션 키가 유효하지 않거나 누락됨(
app_id/app_key인증 방법의 경우) - referrer가 허용되거나 누락되지 않습니다 (참조 필터가 활성화되고 필요한 경우)
- 422: 필수 매개변수가 누락됨
이러한 오류 응답의 대부분은 머신에서 읽을 수 있는 오류 카테고리와 사람이 읽을 수 있는 설명이 포함된 XML 본문도 포함됩니다.
표준 API 게이트웨이 구성을 사용하는 경우 3scale에서 제공하는 200과 다른 반환 코드는 다음 코드 중 하나를 사용하여 클라이언트에 대한 응답을 얻을 수 있습니다.
- 403
- 404