3scale 운영

Red Hat 3scale API Management 2.11

배포를 자동화하고 환경을 확장하며 문제를 해결하는 방법

Red Hat Customer Content Services

초록

이 가이드에서는 Red Hat 3scale API Management 2.11을 사용한 개발 운영에 대해 설명합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서 참조하십시오.

1장. 3scale 일반 구성 옵션

Red Hat 3scale API Management 관리자는 설치 또는 설정을 조정할 수 있는 일반 구성 옵션을 사용할 수 있습니다.

1.1. 유효한 로그인 세션 길이 구성

Red Hat 3scale API Management 관리자는 관리자 포털과 개발자 포털에 모두 유효한 로그인 세션 길이를 구성할 수 있으므로 최대 시간 제한 및 비활성 제한이 있습니다.

유효한 로그인 세션 길이를 구현하려면 USER_SESSION_TTL 을 초로 설정해야 합니다. 예를 들어 7,200초는 2시간입니다. 값이 null 인 경우 이 값을 설정하지 않거나 빈 문자열로 설정하면 세션 길이는 2주입니다.

사전 요구 사항

  • 관리자 권한이 있는 3scale 계정입니다.

절차

  • 필요한 시간(초)으로 환경 변수를 업데이트합니다.

    $ oc set env dc/system-app --overwrite USER_SESSION_TTL=7200

2장. 3scale 작업 및 스케일링

참고

이 문서는 노트북 또는 유사한 최종 사용자 장비상의 로컬 설치를 위한 것이 아닙니다.

이 섹션에서는 Red Hat 3scale API Management 2.11 설치의 작업 및 확장 작업에 대해 설명합니다.

사전 요구 사항

3scale 작업 및 확장 작업을 수행하려면 다음 섹션에 설명된 단계를 수행합니다.

2.1. APIcast 재배포

3scale 관리 포털을 통해 시스템 변경 사항을 테스트하고 승격할 수 있습니다.

사전 요구 사항

  • 3scale 온프레미스로 배포된 인스턴스.
  • APIcast 배포 방법을 선택했습니다.

기본적으로 OpenShift에 포함된 APIcast 배포는 3scale 관리 포털을 통해 스테이징 및 프로덕션 게이트웨이에 변경 사항을 게시할 수 있도록 구성되어 있습니다.

OpenShift에서 APIcast를 재배포하려면 다음을 수행합니다.

절차

  1. 시스템을 변경합니다.
  2. 관리 포털에서 을 스테이징 및 테스트로 배포합니다.
  3. 관리 포털에서 프로덕션으로 승격합니다.

기본적으로 APIcast는 5분마다 승격된 업데이트를 검색하고 게시합니다.

Docker 컨테이너 환경 또는 기본 설치에서 APIcast를 사용하는 경우 스테이징 및 프로덕션 게이트웨이를 구성하고 게이트웨이가 게시된 변경 사항을 검색하는 빈도를 표시합니다. APIcast 게이트웨이를 구성한 후에는 3scale 관리 포털을 통해 APIcast를 재배포할 수 있습니다.

Docker 컨테이너 환경 또는 기본 설치에서 APIcast를 재배포하려면 다음을 수행합니다.

절차

  1. APIcast 게이트웨이를 구성하고 3scale 온프레미스에 연결합니다.
  2. 시스템을 변경합니다.
  3. 관리 포털에서 을 스테이징 및 테스트로 배포합니다.
  4. 관리 포털에서 프로덕션으로 승격합니다.

APIcast는 구성된 빈도에서 승격된 업데이트를 검색하고 게시합니다.

2.2. 3scale 온프레미스 확장

APIcast 배포가 증가함에 따라 사용 가능한 스토리지의 양을 늘려야 할 수 있습니다. 스토리지를 확장하는 방법은 영구 스토리지에 사용하는 파일 시스템 유형에 따라 다릅니다.

NFS(네트워크 파일 시스템)를 사용하는 경우 다음 명령을 사용하여 PV(영구 볼륨)를 확장할 수 있습니다.

oc edit pv <pv_name>

다른 스토리지 방법을 사용하는 경우 다음 섹션에 나열된 방법 중 하나를 사용하여 영구 볼륨을 수동으로 확장해야 합니다.

2.2.1. 방법 1: 영구 볼륨 백업 및 스왑

절차

  1. 기존 영구 볼륨에 데이터를 백업합니다.
  2. 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
  3. 사전 바인딩 영구 볼륨 클레임을 생성하고 다음을 지정합니다. volume Name 필드를 사용하는 새 PVC(PersistentVolumeClaim)의 크기 및 영구 볼륨 이름입니다.
  4. 백업의 데이터를 새로 생성된 PV로 복원합니다.
  5. 새 PV의 이름으로 배포 구성을 수정합니다.

    oc edit dc/system-app
  6. 새 PV가 올바르게 구성되고 작동하는지 확인합니다.
  7. 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.

2.2.2. 방법 2: 3scale 백업 및 재배포

절차

  1. 기존 영구 볼륨에 데이터를 백업합니다.
  2. 3scale Pod를 종료합니다.
  3. 새 크기 요구 사항에 맞게 확장된 대상 영구 볼륨을 생성하고 연결합니다.
  4. 백업의 데이터를 새로 생성된 PV로 복원합니다.
  5. 사전 바인딩 영구 볼륨 클레임을 만듭니다. 다음을 지정합니다.

    1. 새 PVC의 크기
    2. volume Name 필드를 사용하는 영구 볼륨 이름입니다.
  6. your amp.yml 을 배포합니다.
  7. 새 PV가 올바르게 구성되고 작동하는지 확인합니다.
  8. 이전 PVC를 삭제하여 클레임된 리소스를 해제합니다.

2.2.3. 성능 확장

성능 확장은 총 포드 수를 통해 수행됩니다. 하드웨어 리소스가 많을수록 더 많은 Pod를 배포합니다.

다음 명령을 사용하여 Pod 수를 통해 성능을 확장합니다.

oc scale dc dc-name --replicas=X

2.2.4. 3scale 온프레미스 배포 구성

3scale을 위해 스케일링할 주요 배포 구성은 다음과 같습니다.

  • APIcast 프로덕션
  • 백엔드 리스너
  • 백엔드 작업자

2.2.4.1. OCP 명령줄 인터페이스를 통한 스케일링

OCP(OpenShift Container Platform) CLI(명령줄 인터페이스)를 통해 배포 구성을 위로 또는 축소할 수 있습니다.

특정 배포 구성을 확장하려면 다음을 사용합니다.

  • 다음 명령을 사용하여 APIcast 프로덕션 배포 구성을 확장합니다.

    oc scale dc apicast-production --replicas=X
  • 다음 명령을 사용하여 백엔드 리스너 배포 구성을 확장합니다.

    oc scale dc backend-listener --replicas=Y
  • 다음 명령을 사용하여 백엔드 작업자 배포 구성을 확장합니다.

    oc scale dc  backend-worker --replicas=Z

2.2.4.2. 수직 및 수평 하드웨어 확장

리소스를 추가하여 OpenShift에서 3scale 배포의 성능을 향상시킬 수 있습니다. 수평 확장으로 OpenShift 클러스터에 포드로 더 많은 컴퓨팅 노드를 추가하거나, 수직 확장으로 기존 계산 노드에 더 많은 리소스를 할당할 수 있습니다.

수평 스케일링

OpenShift에 포드로 더 많은 컴퓨팅 노드를 추가할 수 있습니다. 추가 계산 노드가 클러스터의 기존 노드와 일치하는 경우 환경 변수를 재구성할 필요가 없습니다.

수직 스케일링

기존 계산 노드에 더 많은 리소스를 할당할 수 있습니다. 더 많은 리소스를 할당하는 경우 성능을 높이기 위해 Pod에 프로세스를 추가해야 합니다.

참고

3scale 배포에서 서로 다른 사양 및 구성으로 컴퓨팅 노드를 사용하지 마십시오.

2.2.4.3. 라우터 확장

트래픽이 증가하면 Red Hat OCP 라우터에서 요청을 적절히 처리할 수 있는지 확인합니다. 라우터가 요청 처리량을 제한하는 경우 라우터 노드를 확장해야 합니다.

2.3. 운영 문제 해결

이 섹션에서는 OpenShift에 표시되도록 3scale 감사 로깅을 구성하는 방법과 OpenShift에서 3scale 로그 및 작업 대기열에 액세스하는 방법을 설명합니다.

2.3.1. OpenShift에서 3scale 감사 로깅 구성

이를 통해 모든 로그가 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴에서 쿼리할 수 있습니다. 이러한 툴을 사용하면 3scale 구성의 변경 사항과 이러한 변경 사항을 언제 변경했는지 파악할 수 있습니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등의 변경 사항이 포함됩니다.

사전 요구 사항

  • 3scale 2.11 배포.

절차

모든 애플리케이션 로그를 표준 OpenShift 포드 로그로 전달하도록 stdout 에 감사 로깅을 구성합니다.

몇 가지 고려 사항:

  • 3scale이 온프레미스로 배포되면 기본적으로 stdout 에 대한 감사 로깅이 비활성화됩니다. 이 기능이 완전히 작동하도록 구성해야 합니다.
  • stdout 에 대한 감사 로깅은 3scale 호스팅에서 사용할 수 없습니다.

2.3.2. 감사 로깅 활성화

3scale은 features.yml 구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout 에 감사 로깅을 활성화하려면 ConfigMap 에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.yml 에 의존하는 OpenShift 포드는 system-appsystem-sidekiq 입니다.

사전 요구 사항

  • OpenShift에서 클러스터 관리자 액세스 권한이 있어야 합니다.

절차

  1. 다음 명령을 입력하여 감사 로깅을 stdout 에 활성화합니다.

    oc patch configmap system -p '{"data": {"features.yml": "features: &default\n  logging:\n    audits_to_stdout: true\n\nproduction:\n  <<: *default\n"}}'
  2. 다음 환경 변수를 내보냅니다.

    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"}]}}}}'
  3. 업데이트된 배포 구성을 관련 OpenShift 포드에 적용하려면 다음 명령을 입력합니다.

    oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES
    oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES

2.3.3. EFK 로깅 구성

3scale 애플리케이션 로그를 OpenShift로 전달하기 위해 stdout 에 감사 로깅을 활성화한 경우 EFK 로깅 툴을 사용하여 3scale 애플리케이션을 모니터링할 수 있습니다.

OpenShift에서 EFK 로깅을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

2.3.4. 로그 액세스

각 구성 요소의 배포 구성에는 액세스 및 예외에 대한 로그가 포함되어 있습니다. 배포에 문제가 발생하면 해당 로그에서 자세한 내용을 확인하십시오.

3scale의 로그에 액세스하려면 다음 단계를 따르십시오.

절차

  1. 로그를 수행할 Pod의 ID를 찾습니다.

    oc get pods
  2. oc logs 및 선택한 Pod의 ID를 입력합니다.

    oc logs <pod>

    시스템 포드에는 각각 별도의 로그가 있는 두 개의 컨테이너가 있습니다. 컨테이너의 로그에 액세스하려면 system-provider 및 system- developer Pod를 사용하여 --container 매개변수를 지정합니다.

    oc logs <pod> --container=system-provider
    oc logs <pod> --container=system-developer

2.3.5. 작업 대기열 확인

작업 대기열에는 system-sidekiq 포드에서 전송된 정보의 로그가 포함되어 있습니다. 이 로그를 사용하여 클러스터가 데이터를 처리 중인지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다.

oc get jobs
oc logs <job>

2.3.6. 단일 성장 방지

monotonic 증가를 방지하기 위해 기본적으로 3scale 일정으로 다음 테이블을 자동으로 삭제합니다.

  • user_sessions - clean up은 매주 한 번 트리거되고 2주가 지난 레코드를 삭제합니다.
  • audits - clean up은 하루에 한 번 트리거되며 3개월이 지난 레코드를 삭제합니다.
  • log_entries - 하루에 한 번 트리거되는 정리는 6개월이 지난 레코드를 삭제합니다.
  • event_store_events - clean up은 매주 한 번 트리거되고 1주일 이상 레코드가 삭제됩니다.

위에 나열된 테이블을 제외하고 다음 테이블에는 데이터베이스 관리자가 수동으로 삭제해야 합니다.

  • 경고

표 2.1. SQL 제거 명령

데이터베이스 유형SQL 명령

MySQL

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL 14 DAY;

PostgreSQL

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL '14 day';

Oracle

DELETE FROM alerts WHERE timestamp <= TRUNC(SYSDATE) - 14;

이 섹션에 지정되지 않은 다른 테이블의 경우 데이터베이스 관리자는 시스템이 자동으로 삭제되지 않는 테이블을 수동으로 정리해야 합니다.

추가 리소스

3장. 모니터링 3scale

Prometheus 는 기록 데이터를 저장하고 확장 가능한 대규모 시스템을 모니터링하기 위해 빌드된 컨테이너 네이티브 소프트웨어입니다. 현재 실행 중인 세션이 아닌, 장기간에 걸쳐 데이터를 수집합니다. Prometheus의 경고 규칙은 Alertmanager에서 관리합니다.

Grafana 와 같은 그래픽 도구를 사용하여 데이터에서 쿼리를 시각화하고 실행할 수 있도록 Prometheus 및 Alertmanager를 사용하여 3scale 데이터를 모니터링하고 저장합니다.

중요

Prometheus는 오픈 소스 시스템 모니터링 툴킷이며 Grafana는 오픈 소스 대시보드 툴킷입니다. Prometheus 및 Grafana에 대한 Red Hat 지원은 Red Hat 제품 설명서에 제공된 구성 권장 사항으로 제한됩니다.

3scale 운영자를 사용하면 기존 Prometheus 및 Grafana 운영자 설치를 사용하여 3scale 사용 및 리소스를 모니터링할 수 있습니다.

참고

3scale 운영자는 모니터링 리소스를 생성하지만 해당 리소스를 수정하지 않습니다.

사전 요구 사항

  • 3scale Operator가 설치되어 있습니다.
  • Prometheus Operator 는 클러스터에 설치됩니다. Prometheus 운영자는 Prometheus 인스턴스를 생성하고 관리하는 운영자입니다. 3scale 모니터링에 필요한 Prometheus 사용자 정의 리소스 정의를 제공합니다.

    다음 Prometheus Operator 및 이미지 버전은 3scale로 테스트됩니다.

    • Prometheus Operator v0.37.0
    • Prometheus 이미지: quay.io/prometheus/prometheus:v2.16.0
  • Grafana 운영자가 클러스터에 설치되어 있습니다. Grafana 운영자는 Grafana 인스턴스를 만들고 관리하는 운영자입니다. 3scale 모니터링에 필요한 GrafanaDashboard 사용자 정의 리소스 정의를 제공합니다.

    다음 Grafana Operator 및 이미지 버전은 3scale을 사용하여 테스트됩니다.

    • Grafana operator v3.9.0
    • Grafana 이미지: registry.hub.docker.com/grafana/grafana:7.1.1
중요

클러스터가 인터넷에 노출되면 Prometheus 및 Grafana 서비스를 보호해야 합니다.

이 섹션에서는 Grafana 대시보드를 볼 수 있도록 3scale 인스턴스를 모니터링하는 방법을 설명합니다.

3.1. 3scale 모니터링 활성화

3scale을 모니터링하려면 APIManager 사용자 지정 리소스를 설정하여 모니터링을 활성화해야 합니다.

절차

  1. 3scale 배포 YAML의 spec.monitoring.enabled 매개변수를 true 로 설정하여 모니터링을 활성화하도록 3scale을 구성합니다. 예를 들면 다음과 같습니다.

    1. 모니터링을 활성화하도록 3scale-monitoring.yml 이라는 APIManager 사용자 지정 리소스를 생성합니다.

      apiVersion: apps.3scale.net/v1alpha1
      kind: APIManager
      metadata:
        name: apimanager1
      spec:
        wildcardDomain: example.com
        monitoring:
          enabled: true
          enablePrometheusRules: false 1
      1
      선택적으로 PrometheusRules 를 비활성화할 수 있습니다. 그렇지 않으면 기본적으로 활성화되어 있습니다.
    2. OpenShift 클러스터에 로그인합니다. 3scale의 OpenShift 프로젝트에서 edit 클러스터 역할(예: cluster-admin )을 사용하여 사용자로 로그인해야 합니다.

      oc login
    3. 3scale 프로젝트로 전환합니다.

      oc project <project_name>
    4. 사용자 정의 리소스를 배포합니다.

      $ oc apply -f 3scale-monitoring.yml

3.2. 3scale을 모니터링하도록 Prometheus 구성

3scale의 모니터링을 활성화하려면 Prometheus 사용자 정의 리소스를 사용하여 Prometheus 를 배포하고 구성해야 합니다.

참고

Prometheus 설명서에 설명된 대로 권한이 올바르게 설정되었는지 확인합니다.

절차

  1. 클러스터의 모든 리소스를 모니터링할지 또는 3scale 리소스만 모니터링할지에 따라 Prometheus 사용자 정의 리소스를 다음과 같이 배포합니다.

    • 클러스터의 모든 리소스를 모니터링하려면 spec.podMonitorSelector 특성을 {} 로 설정하고 spec.ruleSelector 특성을 {} 로 설정합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.

      apiVersion: monitoring.coreos.com/v1
      kind: Prometheus
      metadata:
        name: example
      spec:
        podMonitorSelector: {}
        ruleSelector: {}
    • 3scale 및 Prometheus Operator를 동일한 OpenShift 프로젝트에 배포하고 APP_LABEL 값이 기본 3scale-api-management 로 설정된 경우 다음 단계를 사용하여 3scale 리소스를 모니터링합니다.

      1. spec.podMonitorSelector 특성을 다음과 같이 설정합니다.

         podMonitorSelector:
          matchExpressions:
          - key: app
              operator: In
              values:
              - 3scale-api-management
      2. spec.ruleSelector 특성을 다음과 같이 설정합니다.

           matchExpressions:
           - key: app
             operator: In
             values:
             - 3scale-api-management

        예를 들어 다음 사용자 정의 리소스를 적용합니다.

        apiVersion: monitoring.coreos.com/v1
        kind: Prometheus
        metadata:
          name: example
        spec:
         podMonitorSelector:
          matchExpressions:
          - key: app
              operator: In
              values:
              - 3scale-api-management
         ruleSelector:
           matchExpressions:
           - key: app
             operator: In
             values:
             - 3scale-api-management
    • 다른 OpenShift 프로젝트에 3scale 및 Prometheus Operator를 배포한 경우 다음 단계를 사용하여 3scale 리소스를 모니터링합니다.

      1. MYLABELKEY=MYLABELVALUE로 3scale이 배포되는 OpenShift 프로젝트에 레이블을 지정합니다.
      2. podMonitorNamespaceSelector 필터를 사용하여 3scale Pod를 선택합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.

        apiVersion: monitoring.coreos.com/v1
        kind: Prometheus
        metadata:
          name: example
        spec:
         podMonitorSelector: {}
         ruleSelector: {}
         podMonitorNamespaceSelector:
           matchExpressions:
           - key: MYLABELKEY
             operator: In
             values:
             - MYLABELVALUE
  2. 대시보드 및 경고가 예상대로 작동하도록 하려면 다음 중 하나를 수행하여 Kubernetes 메트릭, 즉 kube-state-metrics 를 통합해야 합니다.

    • Prometheus 인스턴스를 클러스터 기본 Prometheus 인스턴스와 연결합니다.
    • kubelet, etcd 등으로부터 메트릭을 가져오도록 자체 스크랩 작업을 구성합니다.

추가 리소스

3.3. 3scale을 모니터링하도록 Grafana 구성

3scale의 모니터링을 활성화하려면 Grafana를 구성해야 합니다.

절차

  1. app=3scale-api-management 레이블을 덮어쓰고 GrafanaDashboards 리소스를 모니터링하도록 Grafana 서비스가 구성되었는지 확인합니다. 예를 들어 다음 사용자 정의 리소스를 적용합니다.

    apiVersion: integreatly.org/v1alpha1
    kind: Grafana
    metadata:
      name: grafana
    spec:
      dashboardLabelSelector:
      - matchExpressions:
        - key: app
          operator: In
          values:
          - 3scale-api-management

    3scale 연산자가 생성한 Grafana 대시보드는 다음과 같이 레이블이 지정됩니다.

    app: 3scale-api-management
    monitoring-key: middleware
  2. Grafana Operator가 3scale과 다른 네임스페이스에 설치된 경우 --namespaces 또는 -- scan-all Operator 플래그를 사용하여 네임스페이스 외부의 리소스를 모니터링하도록 구성합니다. Operator 플래그에 대한 자세한 내용은 Grafana 설명서 를 참조하십시오.
  3. prometheus 유형의 GrafanaDataSource 사용자 지정 리소스를 생성하여 Grafana에서 Prometheus 데이터를 사용할 수 있도록 합니다. 예를 들면 다음과 같습니다.

    apiVersion: integreatly.org/v1alpha1
    kind: GrafanaDataSource
    metadata:
      name: prometheus
    spec:
      name: middleware
      datasources:
        - name: Prometheus
          type: prometheus
          access: proxy
          url: http://prometheus-operated:9090
          isDefault: true
          version: 1
          editable: true
          jsonData:
            timeInterval: "5s"

    여기서 http://prometheus-operated:9090 는 Prometheus 경로입니다.

  4. Grafana 설명서에 설명된 대로 권한이 올바르게 설정되었는지 확인합니다.

추가 리소스

3.4. 3scale 메트릭 보기

3scale, Prometheus 및 Grafana를 구성한 후 이 섹션에 설명된 지표를 볼 수 있습니다.

절차

  1. Grafana 콘솔에 로그인합니다.
  2. 다음에 대한 메트릭을 볼 수 있는지 확인합니다.

    • 3scale이 설치된 Pod 및 네임스페이스 수준에서 Kubernetes 리소스
    • APIcast 준비
    • APIcast 프로덕션
    • 백엔드 작업자
    • 백엔드 리스너
    • 시스템
    • zync

3.5. Prometheus에 노출된 3scale 시스템 지표

Prometheus 끝점에서 3scale 시스템 Pod를 사용하여 지표를 노출하도록 다음 포트를 구성할 수 있습니다.

표 3.1. 3scale 시스템 포트

system-app포트

system-developer

9394

system-master

9395

system-provider

9396

system-sidekiq포트

system-sidekiq

9394

끝점은 다음을 사용하여 내부적으로만 액세스할 수 있습니다.

http://${service}:${port}/metrics

예를 들면 다음과 같습니다.

http://system-developer:9394/metrics

추가 리소스

4장. Webhook를 사용한 3scale 자동화

Webhook는 자동화를 용이하게 하는 기능이며 3scale에서 발생하는 이벤트를 기반으로 다른 시스템을 통합하는 데에도 사용됩니다. 3scale 시스템 내에서 지정된 이벤트가 발생하면 웹 후크 메시지와 함께 애플리케이션에 알림이 표시됩니다. 예를 들어 Webhook를 구성하면 새 계정 등록의 데이터를 사용하여 개발자 포털을 채울 수 있습니다.

4.1. Webhook 개요

Webhook는 Webhooks 구성 창에서 사용할 수 있는 이벤트에서 선택한 이벤트에 의해 트리거되는 사용자 정의 HTTP 콜백입니다. 이러한 이벤트 중 하나가 발생하면 3scale 시스템은 Webhook 섹션에 지정된 URL 주소에 대한 HTTP 또는 HTTPS 요청을 수행합니다. Webhook를 사용하면 이벤트 추적과 같은 몇 가지 원하는 동작을 호출하도록 리스너를 구성할 수 있습니다.

웹 후크의 형식은 항상 동일합니다. 다음 구조의 XML 문서를 사용하여 끝점에 게시를 만듭니다.

<?xml version="1.0" encoding="UTF-8"?>
<event>
  <type>application</type>
  <action>updated</action>
  <object>
    THE APPLICATION OBJECT AS WOULD BE RETURNED BY A GET ON THE ACCOUNT MANAGEMENT
    API
  </object>
</event>

각 요소는 정보를 제공합니다.

  • <type>: 애플리케이션,계정 등 이벤트의 주체를 제공합니다.
  • & lt;action&gt; : updated,created,deleted.와 같은 값을 사용하여 수행된 항목을 지정합니다.
  • <object>: 계정 관리 API에서 반환하는 것과 동일한 형식으로 XML 오브젝트 자체를 구성합니다. 이를 확인하려면 대화형 ActiveDocs를 사용할 수 있습니다.

Webhook가 3scale에서 발행했음을 보장해야 하는 경우 HTTPS 웹 후크 URL을 노출하고 3scale의 Webhook 선언에 사용자 정의 매개변수를 추가합니다. 예: https://your-webhook-endpoint?someSecretParameterName=someSecretParameterValue. 매개변수 이름과 값을 결정합니다. 그런 다음 웹 후크 끝점 내부에서 이 매개변수 값이 있는지 확인합니다.

4.2. Webhook 구성

절차

  1. 계정 설정 > 통합 > Webhook 로 이동합니다. 계정 설정 은 창 오른쪽 상단에 있는 장치 아이콘입니다.
  2. Webhook의 동작을 나타냅니다. 두 가지 옵션이 있습니다.

    • Webhook 활성화: Webhook를 활성화하거나 비활성화하려면 이 확인란을 선택합니다.
    • 관리 포털의 작업도 Webhook를 트리거합니다. 이벤트가 발생할 때 Webhook를 트리거하려면 이 확인란을 선택합니다. 다음을 고려하십시오.

      • 트리거 이벤트로 구성된 내부 3scale API를 호출할 때 공급자 키가 아닌 액세스 토큰을 사용합니다.
      • 이 확인란을 선택 해제하는 경우 개발자 포털의 작업만 트리거 Webhook를 트리거합니다.
  3. 트리거 시 선택한 이벤트에 대한 알림에 대한 URL 주소를 지정합니다.
  4. 표시된 URL 주소로 콜백을 트리거할 이벤트를 선택합니다.

설정을 구성한 후 Webhook 설정 업데이트를 클릭하여 변경 사항을 저장합니다.

4.3. Webhook 문제 해결

청취 끝점이 중단되는 경우 실패한 전달을 복구할 수 있습니다. 3scale은 끝점이 200 코드로 응답하는 경우 제공되는 Webhook를 고려합니다. 그렇지 않으면 60 초 간격을 사용하여 5 번 다시 시도합니다. 중단 또는 주기적으로 복구한 후 검사를 실행하고 해당 대기열을 정리해야 합니다. 다음 방법에 대한 자세한 내용은 ActiveDocs에서 확인할 수 있습니다.

  • Webhook 목록이 실패한 전달
  • Webhook 삭제 실패

5장. 3scale toolbox

3scale 툴박스 는 명령줄에서 3scale 제품을 관리할 수 있는 Ruby 클라이언트입니다.

3scale 설명서 내에는 3scale toolbox, 지원되는 toolbox 명령, 서비스, 계획, SSL 및 TLS 문제 해결에 대한 정보가 있습니다. 자세한 내용은 아래 섹션 중 하나를 참조하십시오.

5.1. toolbox 설치

3scale toolbox 설치에서 공식적으로 지원되는 방법은 3scale toolbox 컨테이너 이미지를 사용하는 것입니다.

5.1.1. toolbox 컨테이너 이미지 설치

이 섹션에서는 toolbox 컨테이너 이미지를 설치하는 방법을 설명합니다.

사전 요구 사항

절차

  1. Red Hat Ecosystem Catalog에 로그인합니다.

    $ podman login registry.redhat.io
    Username: ${REGISTRY-SERVICE-ACCOUNT-USERNAME}
    Password: ${REGISTRY-SERVICE-ACCOUNT-PASSWORD}
    Login Succeeded!
  2. toolbox 컨테이너 이미지를 가져옵니다.

    $ podman pull registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11
  3. 설치를 확인합니다.

    $ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale help

추가 리소스

5.2. 지원되는 toolbox 명령

3scale toolbox를 사용하여 CLI(명령줄 도구)에서 API를 관리합니다.

참고

update 명령은 더 이상 사용되지 않으며 copy 명령으로 교체되었습니다. 더 이상 사용되지 않는 명령 사용은 지원되지 않습니다.

다음 명령이 지원됩니다.

COMMANDS
    account              account super command
    activedocs           activedocs super command
    application          application super command
    application-plan     application-plan super command
    backend              backend super command
    copy                 copy super command
    help                 print help
    import               import super command
    method               method super command
    metric               metric super command
    policy-registry      policy-registry super command
    product              product super command
    proxy-config         proxy-config super command
    remote               remotes super command
    service              services super command
    update               [DEPRECATED] 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 mode

5.3. 서비스 가져오기

아래에 지정된 순서로 다음 필드를 지정하여 CSV 파일에서 서비스를 가져옵니다. CSV 파일에 이러한 헤더를 포함합니다.

service_name,endpoint_name,endpoint_http_method,endpoint_path,auth_mode,endpoint_system_name,type

다음 정보가 필요합니다.

  • 3scale admin 계정 {3SCALE_ADMIN}
  • 3scale 인스턴스가 실행 중인 도메인: {DOMAIN_NAME}

    • 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
  • 계정의 액세스 키 {ACCESS_KEY}.
  • 서비스의 CSV 파일(예: example /import_example.csv)

다음을 실행하여 서비스를 가져옵니다.

예제

$ podman run -v $PWD/examples/import_example.csv:/tmp/import_example.csv registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale import csv --destination=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --file=/tmp/import_example.csv

이 예에서는 Podman 볼륨을 사용하여 컨테이너에 리소스 파일을 마운트합니다. 현재 $PWD 폴더에서 파일을 사용할 수 있다고 가정합니다.

5.4. 서비스 복사

동일한 계정 또는 다른 계정에서 기존 서비스를 기반으로 새 서비스를 생성합니다. 서비스를 복사할 때 관련 ActiveDocs도 복사됩니다.

다음 정보가 필요합니다.

  • 복사하려는 서비스 ID {SERVICE_ID}
  • 3scale admin 계정 {3SCALE_ADMIN}
  • 3scale 인스턴스가 실행 중인 도메인: {DOMAIN_NAME}

    • 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
  • 계정의 액세스 키 {ACCESS_KEY}.
  • 다른 계정으로 복사하는 경우 대상 계정의 액세스 키: {DEST_KEY}
  • 새 서비스의 이름 {NEW_NAME}

예제

$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale copy service {SERVICE_ID} --source=https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --destination=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME} --target_system_name={NEW_NAME}

참고

복사할 서비스에 사용자 지정 정책이 있는 경우 서비스를 복사할 대상에 해당하는 사용자 지정 정책 정의가 이미 있는지 확인합니다. 사용자 지정 정책 정의 복사에 대한 자세한 내용은 정책 레지스트리 복사를참조하십시오.

5.5. 서비스 설정만 복사

서비스 및 프록시 설정, 메트릭, 메서드, 애플리케이션 계획, 애플리케이션 계획 제한 및 서비스의 규칙을 다른 기존 서비스로 매핑하여 복사하고 업데이트할 수 있습니다.

다음 정보가 필요합니다.

  • 복사하려는 서비스 ID {SERVICE_ID}
  • 대상의 서비스 ID {DEST_ID}
  • 3scale admin 계정 {3SCALE_ADMIN}
  • 3scale 인스턴스가 실행 중인 도메인: {DOMAIN_NAME}

    • 호스팅된 API를 사용하는 경우 이는 3scale.net입니다.
  • 계정의 액세스 키 {ACCESS_KEY}.
  • 대상 계정의 액세스 키 {DEST_KEY}.

또한 선택적 플래그를 사용할 수 있습니다.

  • 복사하기 전에 기존 대상 서비스 매핑 규칙을 제거하는 -f 플래그입니다.
  • 대상 서비스에 규칙 매핑만 복사하기 위한 -r 플래그입니다.
참고

update 명령은 더 이상 사용되지 않으며 copy 명령으로 교체되었습니다. 더 이상 사용되지 않는 명령 사용은 지원되지 않습니다.

다음 예제 명령은 한 서비스에서 다른 기존 서비스로 대규모 업데이트를 수행합니다.

$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 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}

5.6. OpenAPI 정의 가져오기

새 서비스를 생성하거나 기존 서비스를 업데이트하려면 로컬 파일 또는 URL에서 OpenAPI 정의를 가져올 수 있습니다. 가져오기의 기본 서비스 이름은 OpenAPI 정의의 info.title 에 의해 지정됩니다. 그러나 --target_system_name=<NEW NAME> 을 사용하여 이 서비스 이름을 재정의할 수 있습니다. 서비스 이름이 이미 있으면 업데이트되거나 없는 경우 새 서비스 이름이 생성됩니다.

가져오기 openapi 명령에는 다음과 같은 형식이 있습니다.

3scale import openapi [opts] -d=<destination> <specification>

OpenAPI <specification> 은 다음 중 하나일 수 있습니다.

  • /path/to/your/definition/file.[json|yaml|yml]
  • http[s]://domain/resource/path.[json|yaml|yml]

예제

$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale import openapi [opts] -d=https://{DEST_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME}  my-test-api.json

명령 옵션

가져오기 openapi 명령 옵션은 다음과 같습니다.

-d --destination=<value>
3scale 대상 인스턴스(http [s]://<authentication>@3scale_domain ).
-t --target_system_name=<value>
3scale 대상 시스템 이름.
--backend-api-secret-token=<value>
API 게이트웨이에서 백엔드 API로 전송하는 사용자 지정 시크릿 토큰입니다.
--backend-api-host-header=<value>
API 게이트웨이에서 백엔드 API로 전송하는 사용자 지정 호스트 헤더입니다.

자세한 옵션은 3scale import openapi --help 명령을 참조하십시오.

OpenAPI 가져오기 규칙

지원되는 보안 스키마는 OAuth 흐름 유형이 있는 apiKeyoauth2 입니다.

OpenAPI 사양은 다음 중 하나여야 합니다. 사용 가능한 경로의 파일 이름. toolbox에서 콘텐츠를 다운로드할 수 있는 URL입니다. 지원되는 스키마는 httphttps 입니다. ** stdin 표준 입력 스트림에서 읽습니다. 이 설정은 - 값을 설정하여 제어합니다.

다음 추가 규칙은 OpenAPI 정의를 가져올 때 적용됩니다.

  • 정의는 OpenAPI 2.0 또는 OpenAPI 3.0으로 검증됩니다.
  • OpenAPI 정의에서 모든 매핑 규칙을 가져옵니다. API > 통합 에서 볼 수 있습니다.
  • 3scale 제품의 모든 매핑 규칙이 교체됩니다.
  • OpenAPI 정의에 포함된 방법만 수정됩니다.
  • OpenAPI 정의에만 있는 모든 메서드는 Hits 지표에 연결됩니다.
  • 메서드를 교체하려면 정확한 패턴 일치를 사용하여 메서드 이름을 OpenAPI 정의 operation.operationId 에 정의된 방법과 동일해야 합니다.
참고

사양에 보안 요구 사항이 없지만 서비스는 OpenAPI 로 간주됩니다. toolbox는 정책 체인에 없는 경우 anonymous_policy 라고도 하는 default_credentials 정책을 추가합니다. default_credentials 정책은 선택적 매개변수 --default-credentials-user key에 제공된 user key 로 구성됩니다.

OpenAPI 3.0 제한 사항

다음 제한 사항은 OpenAPI 3.0 정의를 가져올 때 적용됩니다.

  • servers 목록의 첫 번째 server.url 요소만 프라이빗 URL로 구문 분석됩니다. server.url 요소의 경로 구성 요소는 OpenAPI의 basePath 속성으로 사용됩니다.
  • toolbox는 작업 오브젝트의 경로 항목과 서버에서 서버를 구문 분석하지 않습니다.
  • 보안 체계 오브젝트의 여러 흐름이 지원되지 않습니다.

5.7. 원격 액세스 인증 정보 관리

원격 3scale 인스턴스 작업을 용이하게 하기 위해 3scale 툴박스를 사용하여 원격 URL 주소와 인증 세부 정보를 정의하여 구성 파일의 원격 인스턴스에 액세스할 수 있습니다. 그런 다음 toolbox 명령에서 짧은 이름을 사용하여 이러한 remotes를 참조할 수 있습니다.

구성 파일의 기본 위치는 $HOME/.3scalerc.yaml 입니다. 그러나 THREESCALE_CLI_CONFIG 환경 변수 또는 --config-file <config_ file> toolbox 옵션을 사용하여 다른 위치를 지정할 수 있습니다.

원격 액세스 인증 정보를 추가할 때 access_token 또는 provider_ key 를 지정할 수 있습니다.

  • http[s]://<access_token>@<3scale-instance-domain>
  • http[s]://<provider_key>@<3scale-instance-domain>

5.7.1. 원격 액세스 인증 정보 추가

다음 예제 명령은 <url>에서 짧은 <name> 을 사용하여 원격 3scale 인스턴스를 추가합니다.

3scale remote add [--config-file <config_file>] <name> <url>

예제

$ podman run --name toolbox-container registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale remote add instance_a https://123456789@example_a.net

$ podman commit toolbox-container toolbox

이 예제에서는 원격 인스턴스를 생성하고 컨테이너를 커밋하여 새 이미지를 생성합니다. 그런 다음 원격 정보가 포함된 새 이미지를 실행할 수 있습니다. 예를 들어 다음 명령은 새 이미지를 사용하여 새로 추가된 원격 을 표시합니다.

$ podman run toolbox 3scale remote list
instance_a https://example_a.net 123456789

그런 다음 기타 toolbox 명령은 새로 생성된 이미지를 사용하여 추가된 원격에 액세스할 수 있습니다. 이 예에서는 registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 대신 toolbox 라는 이미지를 사용합니다.

주의

컨테이너에 toolbox의 시크릿을 저장하는 것은 잠재적인 보안 위험입니다(예: 컨테이너를 다른 사용자에게 시크릿으로 배포하거나 자동화를 위해 컨테이너를 사용하는 경우). OpenShift에서 Podman 또는 시크릿에서 보안 볼륨을 사용합니다.

추가 리소스

Podman 사용에 대한 자세한 내용은 다음을 참조하십시오.

5.7.2. 원격 액세스 자격 증명 나열

다음 예제 명령은 원격 액세스 자격 증명을 나열하는 방법을 보여줍니다.

3scale remote list [--config-file <config_file>]

이 명령은 추가된 원격 3scale 인스턴스 목록을 <name> <URL&gt; < authentication-key> 형식으로 표시합니다.

예제

$ podman run <toolbox_image_with_remotes_added> 3scale remote list
instance_a https://example_a.net 123456789
instance_b https://example_b.net 987654321

5.7.3. 원격 액세스 인증 정보 제거

다음 예제 명령은 원격 액세스 자격 증명을 제거하는 방법을 보여줍니다.

3scale remote remove [--config-file <config_file>] <name>

이 명령은 짧은 <name>:이 명령을 사용하여 원격 3scale 인스턴스를 제거합니다.

예제

$ podman run <toolbox_image_with_remote_added> 3scale remote remove instance_a

5.7.4. 원격 액세스 인증 정보 이름 변경

다음 예제 명령은 원격 액세스 자격 증명의 이름을 변경하는 방법을 보여줍니다.

3scale remote rename [--config-file <config_file>] <old_name> <new_name>

이 명령은 짧은 <old_name>을 사용하여 원격 3scale 인스턴스의 이름을 < new_name> 으로 변경합니다.

예제

$ podman run <toolbox_image_with_remote_added> 3scale remote rename instance_a instance_b

5.8. 애플리케이션 계획 생성

3scale toolbox를 사용하여 개발자 포털에서 애플리케이션 계획을 생성, 업데이트, 나열, 삭제, 표시 또는 내보내기/가져오기/가져오기.

5.8.1. 새 애플리케이션 계획 생성

다음 단계를 사용하여 새 애플리케이션 계획을 생성합니다.

  • 애플리케이션 계획 이름을 제공해야 합니다.
  • system-name 을 재정의하려면 선택적 매개 변수를 사용합니다.
  • 동일한 이름의 애플리케이션 계획이 이미 존재하는 경우 오류 메시지가 표시됩니다.
  • --default 플래그를 사용하여 애플리케이션 계획을 기본값으로 설정합니다.
  • --publish 플래그를 사용하여 게시된 애플리케이션 계획을 생성합니다.

    • 기본적으로 숨겨집니다.
  • --disabled 플래그를 사용하여 비활성화된 애플리케이션 계획을 생성합니다.

    • 기본적으로 활성화되어 있습니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령은 새 애플리케이션 계획을 생성합니다.

3scale application-plan create [opts] <remote> <service> <plan-name>

애플리케이션 계획을 생성하는 동안 다음 옵션을 사용합니다.

Options
       --approval-required=<value>    The application requires approval:
                                      true or false
       --cost-per-month=<value>       Cost per month
       --default                      Make the default application plan
       --disabled                     Disable all methods and metrics in
                                      the application plan
    -o --output=<value>               Output format on stdout:
                                      one of json|yaml
    -p --published                    Publish the application plan
       --setup-fee=<value>            Set-up fee
    -t --system-name=<value>          Set application plan system name
       --trial-period-days=<value>    The trial period in days

Options for application-plan
    -c --config-file=<value>          3scale toolbox configuration file:
                                      defaults to $HOME/.3scalerc.yaml
    -h --help                         Print help for this command
    -k --insecure                     Proceed and operate even for server
                                      connections otherwise considered
                                      insecure
    -v --version                      Print the version of this command
       --verbose                      Verbose mode

5.8.2. 애플리케이션 계획 생성 또는 업데이트

다음 단계를 사용하여 새 애플리케이션 계획이 없는 경우 애플리케이션을 생성하거나 기존 애플리케이션 계획을 업데이트합니다.

  • --default 플래그를 사용하여 기본 애플리케이션 계획을 업데이트합니다.
  • --publish 플래그를 사용하여 게시된 애플리케이션 계획을 업데이트합니다.
  • --hide 플래그를 사용하여 숨겨진 애플리케이션 계획을 업데이트합니다.
  • --disabled 플래그를 사용하여 비활성화된 애플리케이션 계획을 업데이트합니다.
  • enabled 플래그 를 사용하여 활성화된 애플리케이션 계획을 업데이트합니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.
  • 계획 위치 인수는 계획 참조이며 계획 ID 또는 system_name 계획 중 하나일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령은 애플리케이션 계획을 업데이트합니다.

3scale application-plan create [opts] <remote> <service> <plan>

애플리케이션 계획을 업데이트하는 동안 다음 옵션을 사용합니다.

Options
       --approval-required=<value>    The application requires approval:
                                      true or false
       --cost-per-month=<value>       Cost per month
       --default                      Make the default application plan
       --disabled                     Disable all methods and metrics in
                                      the application plan
       --enabled                      Enable the application plan
       --hide                         Hide the application plan
    -n --name=<value>                 Set the plan name
    -o --output=<value>               Output format on stdout:
                                      one of json|yaml
    -p --publish                      Publish the application plan
       --setup-fee=<value>            Set-up fee
       --trial-period-days=<value>    The trial period in days

Options for application-plan
    -c --config-file=<value>          3scale toolbox configuration file:
                                      defaults to $HOME/.3scalerc.yaml
    -h --help                         Print help for this command
    -k --insecure                     Proceed and operate even for server
                                      connections otherwise considered
                                      insecure
    -v --version                      Print the version of this command
       --verbose                      Verbose mode

5.8.3. 애플리케이션 계획 나열

다음 명령은 애플리케이션 계획을 나열합니다.

3scale application-plan list [opts] <remote> <service>

애플리케이션 계획을 나열하는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for application-plan
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.8.4. 애플리케이션 계획 표시

다음 명령은 애플리케이션 계획을 보여줍니다.

3scale application-plan show [opts] <remote> <service> <plan>

애플리케이션 계획을 보여주는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for application-plan
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.8.5. 애플리케이션 계획 삭제

다음 명령은 애플리케이션 계획을 삭제합니다.

3scale application-plan delete [opts] <remote> <service> <plan>

애플리케이션 계획을 삭제하는 동안 다음 옵션을 사용합니다.

Options for application-plan
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.8.6. 애플리케이션 계획 내보내기/가져오기

단일 애플리케이션 계획을 yaml 콘텐츠로 내보내거나 가져올 수 있습니다.

다음을 확인합니다.

  • 애플리케이션 계획에 정의된 제한 사항이 포함됩니다.
  • 애플리케이션 계획에 정의된 가격 규칙이 포함됩니다.
  • 제한 및 가격 규칙에 의해 참조되는 지표/메서드가 포함됩니다.
  • 애플리케이션 계획에 정의된 기능이 포함되어 있습니다.
  • 서비스는 id 또는 system_name 에서 참조할 수 있습니다.
  • 애플리케이션 계획은 id 또는 system_name 에서 참조할 수 있습니다.

5.8.6.1. 파일로 애플리케이션 계획 내보내기

다음 명령은 애플리케이션 계획을 내보냅니다.

3scale application-plan export [opts] <remote> <service_system_name> <plan_system_name>

예제

$ podman run -u root -v $PWD:/tmp registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale application-plan export --file=/tmp/plan.yaml remote_name service_name plan_name

이 예제에서는 Podman 볼륨을 사용하여 현재 $PWD 폴더에 출력을 위해 컨테이너에 내보낸 파일을 마운트합니다.

참고

export 명령과 관련이 있습니다.

  • 원격 서비스 및 애플리케이션 계획에 대한 작업만 읽습니다.
  • 명령 출력은 stdout 또는 file일 수 있습니다.

    • 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:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.8.6.2. 파일에서 애플리케이션 계획 가져오기

다음 명령은 애플리케이션 계획을 가져옵니다.

3scale application-plan import [opts] <remote> <service_system_name>

예제

$ podman run -v $PWD/plan.yaml:/tmp/plan.yaml registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale application-plan import --file=/tmp/plan.yaml remote_name service_name

이 예에서는 Podman 볼륨을 사용하여 현재 $PWD 폴더에서 컨테이너에 가져온 파일을 마운트합니다.

5.8.6.3. URL에서 애플리케이션 계획 가져오기

3scale application-plan import -f http[s]://domain/resource/path.yaml remote_name service_name
참고

명령과 관련된:

  • 명령 입력 내용은 stdin, 파일 또는 URL 형식일 수 있습니다.

    • f 옵션에 지정하지 않은 경우 기본적으로 yaml 콘텐츠는 stdin 에서 읽습니다.
  • 원격 서비스에서 애플리케이션 계획을 찾을 수 없는 경우 생성됩니다.
  • 원격 대상 애플리케이션 계획 id 또는 system_name 을 재정의하는 선택적 매개 변수 -p,--plan.

    • 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:
                                       defaults to $HOME/.3scalerc.yaml
    -h --help                          Print help for this command
    -k --insecure                      Proceed and operate even for server
                                       connections otherwise considered
                                       insecure
    -v --version                       Print the version of this command
       --verbose                       Verbose mode

5.9. 메트릭 생성

3scale toolbox를 사용하여 개발자 포털에서 지표를 생성, 업데이트, 나열 및 삭제합니다.

다음 단계를 사용하여 메트릭을 생성합니다.

  • 지표 이름을 제공해야 합니다.
  • system-name 을 재정의하려면 선택적 매개 변수를 사용합니다.
  • 동일한 이름의 지표가 이미 있는 경우 오류 메시지가 표시됩니다.
  • --disabled 플래그를 사용하여 비활성화된 지표를 생성합니다.

    • 기본적으로 활성화되어 있습니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령은 메트릭을 생성합니다.

3scale metric create [opts] <remote> <service> <metric-name>

메트릭을 생성하는 동안 다음 옵션을 사용합니다.

Options
       --description=<value>      Set a metric description
       --disabled                 Disable this metric in all application
                                  plans
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml
    -t --system-name=<value>      Set the application plan system name
       --unit=<value>             Metric unit: default hit

Options for metric
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.9.1. 메트릭 생성 또는 업데이트

다음 단계를 사용하여 새 메트릭이 없는 경우 해당 지표를 생성하거나 기존 지표를 업데이트합니다.

  • 동일한 이름의 지표가 이미 있는 경우 오류 메시지가 표시됩니다.
  • --disabled 플래그를 사용하여 비활성화된 지표를 업데이트합니다.
  • --enabled 플래그를 사용하여 메트릭을 활성화 하도록 업데이트합니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.
  • 지표 위치 인수는 지표 참조이며 지표 ID 또는 system_name 중 하나일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령 목록은 메트릭을 업데이트합니다.

3scale metric apply [opts] <remote> <service> <metric>

메트릭을 업데이트하는 동안 다음 옵션을 사용합니다.

Options
       --description=<value>      Set a metric description
       --disabled                 Disable this metric in all application
                                  plans
       --enabled                  Enable this metric in all application
                                  plans
    -n --name=<value>             This will set the metric name
       --unit=<value>             Metric unit: default hit
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for metric
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.9.2. 메트릭 나열

다음 명령은 메트릭을 나열합니다.

3scale metric list [opts] <remote> <service>

메트릭을 나열하는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for metric
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.9.3. 메트릭 삭제

다음 명령은 메트릭을 삭제합니다.

3scale metric delete [opts] <remote> <service> <metric>

메트릭을 삭제하는 동안 다음 옵션을 사용합니다.

Options for metric
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.10. 방법 생성

3scale toolbox를 사용하여 개발자 포털에서 메서드를 생성, 적용, 나열 및 삭제합니다.

5.10.1. 방법 생성

방법을 생성하려면 다음 단계를 사용하십시오.

  • 메서드 이름을 제공해야 합니다.
  • system-name 을 재정의하려면 선택적 매개 변수를 사용합니다.
  • 같은 이름의 메서드가 이미 존재하는 경우 오류 메시지가 표시됩니다.
  • --disabled 플래그를 사용하여 비활성화된 메서드를 생성합니다.

    • 기본적으로 활성화되어 있습니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령은 메서드를 생성합니다.

3scale method create [opts] <remote> <service> <method-name>

방법을 생성하는 동안 다음 옵션을 사용합니다.

Options
       --description=<value>      Set a method description
       --disabled                 Disable this method in all
                                  application plans
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml
    -t --system-name=<value>      Set the method system name

Options for method
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.10.2. 생성 또는 업데이트 방법

새로운 메서드가 없는 경우 새 메서드를 생성하거나 기존 메서드를 업데이트하려면 아래 단계를 사용합니다.

  • 같은 이름의 메서드가 이미 있으면 명령에서 오류 메시지를 반환합니다.
  • --disabled 플래그 를 사용하여 disabled 메서드로 업데이트합니다.
  • --enabled 플래그 를 사용하여 enabled 메서드를 업데이트합니다.
참고
  • 서비스 위치 인수는 서비스 참조이며 서비스 ID 또는 서비스 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.
  • 메서드 위치 인수는 메서드 참조이며 메서드 id 또는 메서드 system_name 일 수 있습니다.

    • toolbox는 둘 중 하나를 사용합니다.

다음 명령은 메서드를 업데이트합니다.

3scale method apply [opts] <remote> <service> <method>

방법을 업데이트하는 동안 다음 옵션을 사용합니다.

Options
       --description=<value>      Set a method description
       --disabled                 Disable this method in all
                                  application plans
       --enabled                  Enable this method in all
                                  application plans
    -n --name=<value>             Set the method name
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for method
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.10.3. 방법 나열

다음 명령은 메서드를 나열합니다.

3scale method list [opts] <remote> <service>

방법을 나열하는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for method
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.10.4. 방법 삭제

다음 명령은 메서드를 삭제합니다.

3scale method delete [opts] <remote> <service> <metric>

방법을 삭제하는 동안 다음 옵션을 사용합니다.

Options for method
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.11. 서비스 생성

3scale toolbox를 사용하여 개발자 포털에서 서비스를 생성, 적용, 나열, 표시 또는 삭제합니다.

5.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
    -o --output=<value>                  Output format on stdout:
                                         one of json|yaml
    -s --system-name=<value>             Specify the system-name of the
                                         service
       --support-email=<value>           Specify the support email of the
                                         service

Options for service
    -c --config-file=<value>             3scale toolbox configuration file:
                                         defaults to $HOME/.3scalerc.yaml
    -h --help                            Print help for this command
    -k --insecure                        Proceed and operate even for
                                         server connections otherwise
                                         considered insecure
    -v --version                         Print the version of this command
       --verbose                         Verbose mode

5.11.2. 서비스 생성 또는 업데이트

다음을 사용하여 새 서비스를 생성하거나 기존 서비스를 업데이트합니다.

참고
  • service-id_or_system-name 위치 인수는 서비스 참조입니다.

    • 서비스 ID 또는 서비스 system _name 일 수 있습니다.
    • 툴박스가 이 문제를 자동으로 해결합니다.
  • 이 명령은 멱등 입니다.

다음 명령은 서비스를 업데이트합니다.

3scale service apply <remote> <service-id_or_system-name>

서비스를 업데이트하는 동안 다음 옵션을 사용합니다.

Options
    -a --authentication-mode=<value>     Specify authentication mode of
                                         the service:
                                           - '1' for API key
                                           - '2' for App Id/App Key
                                           - 'oauth' for OAuth mode
                                           - 'oidc' for OpenID Connect
    -d --deployment-mode=<value>         Specify the deployment mode of
                                         the service
       --description=<value>             Specify the description of the
                                         service
    -n --name=<value>                    Specify the name of the metric
       --support-email=<value>           Specify the support email of the
                                         service
    -o --output=<value>                  Output format on stdout:
                                         one of json|yaml

Options for services
    -c --config-file=<value>             3scale toolbox configuration file:
                                         defaults to $HOME/.3scalerc.yaml
    -h --help                            Print help for this command
    -k --insecure                        Proceed and operate even for
                                         server connections otherwise
                                         considered insecure
    -v --version                         Print the version of this command
       --verbose                         Verbose mode

5.11.3. 서비스 나열

다음 명령은 서비스를 나열합니다.

3scale service list <remote>

서비스를 나열하는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for services
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.11.4. 서비스 표시

다음 명령은 서비스를 표시합니다.

3scale service show <remote> <service-id_or_system-name>

서비스를 보여주는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for services
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.11.5. 서비스 삭제

다음 명령은 서비스를 삭제합니다.

3scale service delete <remote> <service-id_or_system-name>

서비스를 삭제하는 동안 다음 옵션을 사용합니다.

Options for services
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.12. ActiveDocs 생성

3scale toolbox를 사용하여 개발자 포털에서 ActiveDocs를 생성, 업데이트, 나열 또는 삭제합니다.

5.12.1. 새 ActiveDocs 생성

OpenAPI 사양과 호환되는 API 정의에서 새 ActiveDocs를 생성하려면 다음을 수행합니다.

  1. API 정의를 3scale에 추가하여 선택적으로 이름을 지정합니다.

    3scale activedocs create <remote> <activedocs-name> <specification>

    ActiveDocs에 대한 OpenAPI 사양이 필요하며 다음 값 중 하나여야 합니다.

    • 사용 가능한 경로의 파일 이름.
    • toolbox에서 콘텐츠를 다운로드할 수 있는 URL입니다. 지원되는 스키마는 httphttps 입니다.
    • stdin 표준 입력 스트림에서 읽습니다. 이 설정은 - 값을 설정하여 제어합니다.

      ActiveDocs를 생성하는 동안 다음 옵션을 사용하십시오.

      Options
          -d --description=<value>        Specify the description of
                                          the ActiveDocs
          -i --service-id=<value>         Specify the Service ID
                                          associated to the ActiveDocs
          -o --output=<value>             Output format on stdout: one
                                          of json|yaml
          -p --published                  Specify to publish the
                                          ActiveDocs on the Developer
                                          Portal. Otherwise it is hidden.
          -s --system-name=<value>        Specify the system-name of
                                          the ActiveDocs
             --skip-swagger-validations   Specify to skip validation
                                          of the Swagger specification
      Options for ActiveDocs
          -c --config-file=<value>        toolbox configuration file.
                                          Defaults to $HOME/.3scalerc.yaml
          -h --help                       Print help for this command
          -k --insecure                   Proceed and operate even for
                                          server connections otherwise
                                          considered insecure
          -v --version                    Print the version of this command
             --verbose                    Verbose mode
  2. 개발자 포털에 정의를 게시합니다.

5.12.2. ActiveDocs 생성 또는 업데이트

다음 명령을 사용하여 새 ActiveDocs가 없는 경우 새로 생성하거나 기존 ActiveDocs를 새 API 정의로 업데이트합니다.

3scale activedocs apply <remote> <activedocs_id_or_system_name>

ActiveDocs를 업데이트하는 동안 다음 옵션을 사용하십시오.

Options
  -d --description=<value>              Specify the description of the
                                        ActiveDocs
       --hide                           Specify to hide the ActiveDocs
                                        on the Developer Portal
 -i --service-id=<value>                Specify the Service ID associated
                                        to the ActiveDocs
 -o --output=<value>                    Output format on stdout:
                                        one of json|yaml
    --openapi-spec=<value>              Specify the Swagger specification.
                                        Can be a file, a URL or '-' to read
                                        from stdin. This is a mandatory
                                        option when applying the ActiveDoc
                                        for the first time.
 -p --publish                           Specify to publish the ActiveDocs
                                        on the Developer Portal. Otherwise
                                        it is hidden
 -s --name=<value>                      Specify the name of the ActiveDocs
    --skip-swagger-validations=<value>  Specify whether to skip validation
                                        of the Swagger specification: true
                                        or false. Defaults to true.

Options for ActiveDocs
    -c --config-file=<value>           3scale toolbox configuration file:
                                       defaults to $HOME/.3scalerc.yaml
    -h --help                          Print help for this command
    -k --insecure                      Proceed and operate even for server
                                       connections otherwise considered
                                       insecure
    -v --version                       Print the version of this command
       --verbose                       Verbose mode
참고

activedocs 동작은 3scale 2.8에서 --skip-swagger-validations를 적용합니다. activedocs apply를 사용하여 기존 스크립트를 업데이트해야 할 수도 있습니다. 이전에는 각 activedocs apply 명령에 이 옵션을 지정하지 않은 경우 유효성 검사를 건너뛰지 않았습니다. 이제 기본적으로 --skip-swagger-validationstrue 입니다.

5.12.3. ActiveDocs 나열

다음 명령을 사용하여 다음을 포함하여 개발자 포털의 모든 ActiveDocs에 대한 정보를 가져옵니다.

  • id
  • name
  • 시스템 이름
  • description
  • 게시됨(즉, 개발자 포털에 표시될 수 있음)
  • 생성 날짜
  • 최신 업데이트 날짜

다음 명령은 정의된 모든 ActiveDocs를 나열합니다.

3scale activedocs list <remote>

ActiveDocs를 나열하는 동안 다음 옵션을 사용하십시오.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml
    -s --service-ref=<value>      Filter the ActiveDocs by service
                                  reference
Options for ActiveDocs
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.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:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.13. 프록시 구성 나열

3scale 툴박스를 사용하여 개발자 포털에서 정의된 모든 프록시 구성을 나열, 표시, 승격합니다.

다음 명령은 프록시 구성을 나열합니다.

3scale proxy-config list <remote> <service> <environment>

프록시 구성을 나열하는 동안 다음 옵션을 사용합니다.

Options
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for proxy-config
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.13.1. 프록시 구성 표시

다음 명령은 프록시 구성을 표시합니다.

3scale proxy-config show <remote> <service> <environment>

프록시 구성을 표시하는 동안 다음 옵션을 사용합니다.

Options
       --config-version=<value>   Specify the proxy configuration version.
                                  If not specified, defaults to latest
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

Options for proxy-config
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered
                                  insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.13.2. 프록시 구성 승격

다음 명령은 최신 스테이징 프록시 구성을 프로덕션 환경으로 승격합니다.

3scale proxy-config promote <remote> <service>

최신 스테이징 프록시 구성을 프로덕션 환경으로 승격하는 동안 다음 옵션을 사용합니다.

Options for proxy-config
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.13.3. 프록시 구성 내보내기

예를 들어, 3scale 인스턴스에 연결되어 있지 않은 자체 관리 APIcast 게이트웨이가 있는 경우 proxy-config export 명령을 사용합니다. 이 시나리오에서는 3scale 구성을 수동으로 삽입하거나 API cast 배포 및 구성 옵션을 사용하여 삽입합니다. 두 경우 모두 3scale 구성을 제공해야 합니다.

다음 명령은 APIcast 게이트웨이에 삽입할 수 있는 구성을 내보냅니다.

3scale proxy-config export <remote>

3scale 구성 파일로 사용할 공급자 계정의 프록시 구성을 내보낼 때 다음 옵션을 지정할 수 있습니다.

Options for proxy-config
--environment=<value>      Gateway environment. Must be 'sandbox' or
                           'production' (default: sandbox)
-o --output=<value>        Output format. One of: json|yaml

5.13.4. 프록시 구성 배포

다음 배포 명령은 서비스 메시를 사용하는 경우 APIcast 구성을 3scale의 스테이징 환경 또는 프로덕션 환경으로 승격합니다.

3scale proxy-config deploy <remote> <service>

deploy 명령을 사용하여 APIcast 구성을 스테이징 환경으로 승격할 때 다음 옵션을 지정할 수 있습니다.

-o --output=<value>        Output format. One of: json|yaml

추가 리소스

5.14. 정책 레지스트리 복사

다음과 같은 경우 toolbox 명령을 사용하여 3scale 소스 계정의 정책 레지스트리를 대상 계정으로 복사합니다.

  • 대상 계정에 누락된 사용자 지정 정책이 생성 중입니다.
  • 대상 계정에서 일치하는 사용자 지정 정책이 업데이트됩니다.
  • 이 복사 명령은 멱등입니다.
참고
  • 누락된 사용자 지정 정책은 소스 계정에 있고 계정 테넌트에 없는 사용자 지정 정책으로 정의됩니다.
  • 일치하는 사용자 지정 정책은 소스 계정과 대상 계정에 모두 존재하는 사용자 지정 정책으로 정의됩니다.

다음 명령은 정책 레지스트리를 복사합니다.

3scale policy-registry copy [opts] <source_remote> <target_remote>
Option for policy-registry
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.15. 애플리케이션 나열

3scale toolbox를 사용하여 애플리케이션 개발자 포털을 나열, 생성, 표시, 적용 또는 삭제합니다.

다음 명령은 애플리케이션을 나열합니다.

3scale application list [opts] <remote>

애플리케이션을 나열하는 동안 다음 옵션을 사용합니다.

OPTIONS
       --account=<value>          Filter by account
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml
       --plan=<value>             Filter by application plan. Service
                                  option required.
       --service=<value>          Filter by service

OPTIONS FOR APPLICATION
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.15.1. 애플리케이션 생성

create 명령을 사용하여 지정된 3scale 계정 및 애플리케이션 계획에 연결된 하나의 애플리케이션을 만듭니다.

필요한 위치 매개 변수는 다음과 같습니다.

  • <service> 참조. 서비스 ID 또는 서비스 system _name 일 수 있습니다.
  • <account> 참조 다음 중 하나일 수 있습니다.

    • 계정 ID
    • 계정의 admin 사용자의 사용자 이름,이메일 또는 user_id
    • provider_key
  • <애플리케이션 계획> 참조. 이 ID는 계획 ID 이거나 system_name 계획일 수 있습니다.
  • <name> 애플리케이션 이름.

다음 명령은 애플리케이션을 생성합니다.

3scale application create [opts] <remote> <account> <service> <application-plan> <name>

애플리케이션을 생성하는 동안 다음 옵션을 사용합니다.

OPTIONS
       --application-id=<value>     App ID or Client ID (for OAuth and
                                    OpenID Connect authentication modes)
                                    of the application to be created.
       --application-key=<value>    App Key(s) or Client Secret (for OAuth
                                    and OpenID Connect authentication
                                    modes) of the application created.
       --description=<value>        Application description
    -o --output=<value>             Output format on stdout:
                                    one of json|yaml
       --redirect-url=<value>       OpenID Connect redirect url
       --user-key=<value>           User Key (API Key) of the application
                                    to be created.

OPTIONS FOR APPLICATION
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.15.2. 애플리케이션 표시

다음 명령은 애플리케이션을 보여줍니다.

3scale application show [opts] <remote> <application>

애플리케이션 매개변수는 다음을 수행할 수 있습니다.

  • user_key - API 키
  • app_id - app_id/app_key 쌍 또는 OAuth 및 OIDC (OpenID Connect ) 인증 모드의 클라이언트 ID
  • 애플리케이션 내부 ID
OPTIONS
    -o --output=<value>           Output format on stdout:
                                  one of json|yaml

OPTIONS FOR APPLICATION
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Print help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode

5.15.3. 애플리케이션 생성 또는 업데이트

다음 명령을 사용하여 새 애플리케이션이 없는 경우 애플리케이션을 생성하거나 기존 애플리케이션을 업데이트합니다.

3scale application apply [opts] <remote> <application>

애플리케이션 매개변수는 다음을 수행할 수 있습니다.

  • user_key - API 키
  • app_id - app_id/app_key 쌍 또는 OAuthOIDC 인증 모드의 클라이언트 ID 에서
  • 애플리케이션 내부 ID
  • 애플리케이션을 찾을 수 없는 경우 계정 선택적 인수가 필요하며 생성해야 합니다. 다음 중 하나일 수 있습니다.

    • 계정 ID
    • 3scale 계정의 관리자 사용자의 사용자 이름,이메일 또는 user_id
    • provider_key
  • 애플리케이션 이름은 3scale에서 고유하지 않으므로 이름은 고유 식별자로 사용할 수 없습니다.
  • --resume 플래그로 일시 중단된 애플리케이션을 다시 시작합니다.
  • 애플리케이션 일시 중단 - --suspend 플래그에 의해 일시 중단된 상태로 변경합니다.

애플리케이션을 업데이트하는 동안 다음 옵션을 사용합니다.

OPTIONS
       --account=<value>           Application's account. Required when
                                   creating
       --application-key=<value>   App Key(s) or Client Secret (for OAuth
                                   and OpenID Connect authentication
                                   modes) of the application to be
                                   created. Only used when application
                                   does not exist.
       --description=<value>       Application description
       --name=<value>              Application name
    -o --output=<value>            Output format on stdout:
                                   one of json|yaml
       --plan=<value>              Application's plan. Required when
                                   creating.
       --redirect-url=<value>      OpenID Connect redirect url
       --resume                    Resume a suspended application
       --service=<value>           Application's service. Required when
                                   creating.
       --suspend                   Suspends an application (changes the
                                   state to suspended)
       --user-key=<value>          User Key (API Key) of the application
                                   to be created.

OPTIONS FOR APPLICATION
    -c --config-file=<value>      3scale toolbox configuration file:
                                  defaults to $HOME/.3scalerc.yaml
    -h --help                     Show help for this command
    -k --insecure                 Proceed and operate even for server
                                  connections otherwise considered insecure
    -v --version                  Print the version of this command
       --verbose                  Verbose mode.

5.15.4. 애플리케이션 삭제

다음 명령은 애플리케이션을 삭제합니다.

3scale application delete [opts] <remote> <application>

애플리케이션 매개변수는 다음을 수행할 수 있습니다.

  • user_key - API 키
  • app_id - app_id/app_key 쌍 또는 OAuthOIDC 인증 모드의 클라이언트 ID 에서
  • 애플리케이션 내부 ID

5.16. 제품 내보내기

소스 3scale 인스턴스와의 연결이 없는 3scale 인스턴스로 해당 제품을 가져올 수 있도록 3scale 제품 정의를 .yaml 형식으로 내보낼 수 있습니다. 3scale 제품을 설정해야 해당 제품을 내보낼 수 있습니다. API 호출을 테스트하기 위해 새 제품 생성 을 참조하십시오.

두 개의 3scale 인스턴스에 네트워크 연결이 있는 경우 3scale 인스턴스에서 동일한 3scale 제품을 사용하려는 경우 toolbox 3scale copy 명령을 사용하십시오.

설명

3scale 제품을 내보내면 toolbox는 제품 및 백엔드 CRD(사용자 정의 리소스 정의)를 준수하는 .yaml 형식으로 제품 정의를 직렬화합니다. output. yaml에는 제품의 기본 정보와 함께 다음이 포함됩니다.

  • 제품에 연결된 백엔드입니다.
  • 연결된 백엔드에 대한 지표, 메서드 및 매핑 규칙.
  • 애플리케이션 계획에 정의된 제한 및 가격 결정 규칙.
  • 제한 및 가격 규칙에 따라 참조되는 지표 및 방법.

제품 내보내기는 읽기 전용 작업입니다. 즉, 제품을 반복적으로 내보내는 것이 안전합니다. toolbox는 내보낼 제품을 변경하지 않습니다. 원하는 경우 .yaml 출력을 다른 3scale 인스턴스로 가져오기 전에 수정할 수 있습니다.

3scale 제품 내보내기는 다음과 같은 상황에 적합합니다.

  • 소스와 대상 3scale 인스턴스 간에는 연결이 없습니다. 예를 들어 2개 이상의 3scale 인스턴스에서 동일한 제품을 사용하려는 경우 toolbox 3scale copy 명령을 실행하지 않는 심각한 네트워크 제한이 있을 수 있습니다.
  • Git 또는 일부 기타 소스 제어 시스템을 사용하여 3scale 제품 정의를 .yaml 형식으로 유지 관리하려고 합니다.

3scale toolbox 내보내기가져오기 명령은 제품 정의를 백업하고 복원하는 데에도 유용할 수 있습니다.

형식

export 명령을 실행하려면 이 형식을 사용하십시오.

3scale product export [-f output-file] <remote> <product>

export 명령은 출력을 stdout 또는 파일에 전송할 수 있습니다. 기본값은 stdout 입니다. 출력을 파일로 보내려면. yaml 파일 이름으로 -f 또는 --file 옵션을 지정합니다.

<remote> 를 제품을 내보낼 3scale 인스턴스와 연결된 3scale 공급자 계정 별칭 또는 URL로 바꿉니다. 이 값을 지정하는 방법에 대한 자세한 내용은 원격 액세스 자격 증명 관리를 참조하십시오.

<product> 를 시스템 이름 또는 내보낼 제품의 3scale ID로 바꿉니다. 이 제품은 지정한 3scale 공급자 계정과 연결되어야 합니다. 제품의 시스템 이름은 제품 개요 페이지의 3scale GUI에서 확인할 수 있습니다. 제품의 3scale ID를 가져오려면 toolbox 3scale services show 명령을 실행합니다.

예제

다음 명령은 my-3scale-1 공급자 계정과 연결된 3scale 인스턴스에서 petstore 제품을 내보내고 petstore-product.yaml 파일에 출력합니다.

3scale product export -f petstore-product.yaml my-3scale-1 petstore

다음은 Default API 제품에 대한 직렬화 예입니다.

apiVersion: v1
kind: List
items:
- apiVersion: capabilities.3scale.net/v1beta1
  kind: Product
  metadata:
    annotations:
      3scale_toolbox_created_at: '2021-02-17T10:59:23Z'
      3scale_toolbox_version: 0.17.1
    name: api.xysnalcj
  spec:
    name: Default API
    systemName: api
    description: ''
    mappingRules:
    - httpMethod: GET
      pattern: "/v2"
      metricMethodRef: hits
      increment: 1
      last: false
    metrics:
      hits:
        friendlyName: Hits
        unit: hit
        description: Number of API hits
    methods:
      servicemethod01:
        friendlyName: servicemethod01
        description: ''
    policies:
    - name: apicast
      version: builtin
      configuration: {}
      enabled: true
    applicationPlans:
      basic:
        name: Basic
        appsRequireApproval: false
        trialPeriod: 0
        setupFee: 0.0
        custom: false
        state: published
        costMonth: 0.0
        pricingRules:
        - from: 1
          to: 1000
          pricePerUnit: 1.0
          metricMethodRef:
            systemName: hits
        limits:
        - period: hour
          value: 1222222
          metricMethodRef:
            systemName: hits
            backend: backend_01
    backendUsages:
      backend_01:
        path: "/v1/pets"
      backend_02:
        path: "/v1/cats"
    deployment:
      apicastSelfManaged:
        authentication:
          oidc:
            issuerType: rest
            issuerEndpoint: https://hello:test@example.com/auth/realms/3scale-api-consumers
            jwtClaimWithClientID: azp
            jwtClaimWithClientIDType: plain
            authenticationFlow:
              standardFlowEnabled: false
              implicitFlowEnabled: true
              serviceAccountsEnabled: false
              directAccessGrantsEnabled: true
            credentials: query
            security:
              hostHeader: ''
              secretToken: some_secret
            gatewayResponse:
              errorStatusAuthFailed: 403
              errorHeadersAuthFailed: text/plain; charset=us-ascii
              errorAuthFailed: Authentication failed
              errorStatusAuthMissing: 403
              errorHeadersAuthMissing: text/plain; charset=us-ascii
              errorAuthMissing: Authentication parameters missing
              errorStatusNoMatch: 404
              errorHeadersNoMatch: text/plain; charset=us-ascii
              errorNoMatch: No Mapping Rule matched
              errorStatusLimitsExceeded: 429
              errorHeadersLimitsExceeded: text/plain; charset=us-ascii
              errorLimitsExceeded: Usage limit exceeded
        stagingPublicBaseURL: http://staging.example.com:80
        productionPublicBaseURL: http://example.com:80
- apiVersion: capabilities.3scale.net/v1beta1
  kind: Backend
  metadata:
    annotations:
      3scale_toolbox_created_at: '2021-02-17T10:59:34Z'
      3scale_toolbox_version: 0.17.1
    name: backend.01.pcjwxbdu
  spec:
    name: Backend 01
    systemName: backend_01
    privateBaseURL: https://b1.example.com:443
    description: new desc
    mappingRules:
    - httpMethod: GET
      pattern: "/v1/pets"
      metricMethodRef: hits
      increment: 1
      last: false
    metrics:
      hits:
        friendlyName: Hits
        unit: hit
        description: Number of API hits
    methods:
      mybackendmethod01:
        friendlyName: mybackendmethod01
        description: ''
- apiVersion: capabilities.3scale.net/v1beta1
  kind: Backend
  metadata:
    annotations:
      3scale_toolbox_created_at: '2021-02-17T10:59:34Z'
      3scale_toolbox_version: 0.17.1
    name: backend.02.tiedgjsk
  spec:
    name: Backend 02
    systemName: backend_02
    privateBaseURL: https://b2.example.com:443
    description: ''
    mappingRules:
    - httpMethod: GET
      pattern: "/v1/cats"
      metricMethodRef: hits
      increment: 1
      last: false
    metrics:
      hits:
        friendlyName: Hits
        unit: hit
        description: Number of API hits
    methods:
      backend02_method01:
        friendlyName: backend02_method01
        description: ''

제품 CR 내보내기 및 파이핑

내보내기 명령을 실행하면 출력을 파이프하여 제품 사용자 정의 리소스(CR) 를 생성할 수 있습니다. 이 CR이 포함된 3scale 인스턴스는 다음에 따라 다릅니다.

  • 3scale-provider-account 시크릿이 정의된 경우 3scale 운영자는 해당 시크릿으로 식별된 3scale 인스턴스에 product CR을 생성합니다.
  • 3scale-provider-account 시크릿이 정의되지 않은 경우 새 제품 CR이 있는 네임스페이스에 3scale 인스턴스가 설치되면 3scale 운영자가 해당 네임스페이스에 제품 CR을 생성합니다.
  • 3scale-provider-account 시크릿이 정의되지 않고 새 제품 CR이 있는 네임스페이스에 3scale 인스턴스가 포함되지 않은 경우 3scale 운영자는 제품 CR을 실패 상태로 표시합니다.

3scale-provider-account 시크릿을 포함하는 네임스페이스에서 다음 명령을 실행하도록 가정합니다. toolbox는 petstore CR을 threescale -provider-account 보안에서 식별된 3scale 인스턴스에 파이프합니다.

3scale product export my-3scale-1 petstore | oc apply -f -

자세한 내용은 3scale Operator가 사용자 정의 리소스 링크가 있는 테넌트를 식별하는 방법을 참조하십시오.

5.17. 제품 가져오기 중

소스 및 대상 3scale 인스턴스에 네트워크 연결이 없는 경우 둘 이상의 3scale 인스턴스에서 동일한 3scale 제품을 사용하려면 3scale 인스턴스 1개에서 3scale 제품을 내보내고 다른 3scale 인스턴스로 가져옵니다. 제품을 가져오려면 toolbox 3scale product import 명령을 실행합니다.

두 개의 3scale 인스턴스에 네트워크 연결이 있는 경우 3scale 인스턴스에서 동일한 3scale 제품을 사용하려는 경우 toolbox 3scale copy 명령을 사용하십시오.

설명

3scale 제품을 가져올 때 toolbox에는 ProductBackend CRD(사용자 정의 리소스 정의)를 준수하는 .yaml 형식으로 직렬화된 제품 정의가 필요합니다. toolbox 3scale product export 명령을 실행하거나 .yaml 형식의 제품 정의를 수동으로 생성하여 이 .yaml 콘텐츠를 가져올 수 있습니다.

제품을 내보낸 경우 가져온 정의에는 내보낸 항목이 포함되어 포함될 수 있습니다.

  • 제품에 연결된 백엔드입니다.
  • 연결된 백엔드에 대한 지표, 메서드 및 매핑 규칙.
  • 애플리케이션 계획에 정의된 제한 및 가격 결정 규칙.
  • 제한 및 가격 규칙에 따라 참조되는 지표 및 방법.

원하는 경우 exported .yaml 출력을 다른 3scale 인스턴스로 가져오기 전에 수정할 수 있습니다.

가져오기 명령은 멱등입니다. 여러 번 실행하여 동일한 제품을 가져올 수 있으며 결과적으로 3scale 구성은 동일합니다. 가져오기 프로세스 중에 오류가 있으면 명령을 다시 실행하는 것이 안전합니다. 가져오기 프로세스에서 3scale 인스턴스에서 제품을 찾을 수 없는 경우 제품을 생성합니다. 또한 .yaml 정의에 정의된 지표, 메서드 또는 백엔드를 생성하고 3scale 인스턴스에서 찾을 수 없습니다.

3scale 제품을 가져오는 것은 다음과 같은 상황에 적합합니다.

  • 소스와 대상 3scale 인스턴스 간에는 연결이 없습니다. 예를 들어 2개 이상의 3scale 인스턴스에서 동일한 제품을 사용하려는 경우 toolbox 3scale copy 명령을 실행하지 않는 심각한 네트워크 제한이 있을 수 있습니다.
  • Git 또는 일부 기타 소스 제어 시스템을 사용하여 3scale 제품 정의를 .yaml 형식으로 유지 관리하려고 합니다.

3scale toolbox 내보내기가져오기 명령은 제품 정의를 백업하고 복원하는 데에도 유용할 수 있습니다.

형식

가져오기 명령을 실행하려면 다음 형식을 사용하십시오.

3scale product import [<options>] <remote>

import 명령은 stdin 또는 파일에서 .yaml 입력을 가져옵니다. 기본값은 stdin 입니다.

다음 옵션을 지정할 수 있습니다.

  • -f 또는 --file 뒤에 파일 이름을 입력하면 지정한 .yaml 파일에서 입력을 가져옵니다. 이 파일에는 3scale Product 및 Backend CRD를 준수하는 3scale 제품 정의가 포함되어야 합니다.
  • -o 또는 --output 뒤에 json 또는 yaml 은 지정한 형식으로 가져온 항목을 나열하는 보고서를 출력합니다. 기본 출력 형식은 json 입니다.

<remote> 를 제품을 가져올 3scale 공급자 계정 별칭 또는 3scale 인스턴스와 연결된 URL로 바꿉니다. 이 값을 지정하는 방법에 대한 자세한 내용은 원격 액세스 자격 증명 관리를 참조하십시오.

예제

다음 명령은 petstore-product.yaml 에 정의된 제품을 my-3scale-2 공급자 계정과 연결된 3scale 인스턴스로 가져옵니다. 기본적으로 가져온 보고서는 .json 형식으로 되어 있습니다.

3scale product import -f petstore-product.yaml my-3scale-2

import 명령은 가져온 항목을 나열하는 보고서를 출력합니다. 예를 들면 다음과 같습니다.

api:
  product_id: 2555417888846
  backends:
    backend_01:
      backend_id: 73310
      missing_metrics_created: 1
      missing_methods_created: 1
      missing_mapping_rules_created: 1
    backend_02:
      backend_id: 73311
      missing_metrics_created: 0
      missing_methods_created: 2
      missing_mapping_rules_created: 1
  missing_methods_created: 1
  missing_metrics_created: 1
  missing_mapping_rules_created: 2
  missing_application_plans_created: 2
  application_plans:
    basic:
      application_plan_id: 2357356246461
      missing_limits_created: 7
      missing_pricing_rules_created: 7
    unlimited:
      application_plan_id: 2357356246462
      missing_limits_created: 1
      missing_pricing_rules_created: 0

직렬화된 제품 정의의 예는 내보내기 제품의 끝에 있습니다.

5.18. 제품 정책 체인 내보내기 및 가져오기

제품의 정책 체인을 yaml 또는 json 콘텐츠로 내보내거나 가져올 수 있습니다. 명령줄에서 id 또는 system 값으로 제품을 참조합니다. 제품의 정책 체인을 내보내거나 가져올 수 있으려면 3scale 제품을 설정해야 합니다. 다음 내용을 참조하십시오. API 호출을 테스트하기 위해 새 제품을 생성합니다.

export 명령의 기능

  • 명령은 원격 제품에 대한 읽기 전용 작업입니다.
  • 명령은 기본적으로 해당 출력을 표준 출력 stdout 에 씁니다. f 플래그는 명령의 출력을 파일에 쓰는 데 사용할 수 있습니다.
  • 명령 출력 형식은 json 또는 yaml 입니다. 기본 형식은 yaml 입니다.

내보내기 제품 정책 체인에 대한 도움말 옵션

NAME
    export - export product policy chain
USAGE
    3scale policies export [opts] <remote>
    <product>
DESCRIPTION
    export product policy chain
OPTIONS
    -f --file=<value>             Write to file instead of stdout
    -o --output=<value>           Output format. One of: json|yaml

명령 형식

  • 다음은 yaml 의 파일로 정책 체인을 내보내는 명령의 형식입니다.

    $ 3scale policies export -f policies.yaml -o yaml remote_name product_name

import 명령의 기능:

  • 명령은 표준 입력 또는 stdin 에서 입력을 읽습니다. f FILE 플래그가 설정되면 파일에서 입력을 읽습니다. u URL 플래그가 설정되면 URL에서 입력을 읽습니다.
  • 가져온 콘텐츠는 yaml 또는 json 중 하나일 수 있습니다. toolbox에서 자동으로 해당 형식을 탐지하므로 형식을 지정할 필요가 없습니다.
  • 기존 정책 체인은 새로 가져온 정책 체인으로 덮어씁니다. 그러면 SET 의미 체계가 구현됩니다.
  • 모든 콘텐츠 검증은 3scale API에 위임됩니다.

가져오기 제품 정책 체인에 대한 도움말 옵션

NAME
    import - import product policy chain
USAGE
    3scale policies import [opts] <remote>
    <product>
DESCRIPTION
    import product policy chain
OPTIONS
    -f --file=<value>             Read from file
    -u --url=<value>              Read from url

명령 형식

  • 다음은 파일에서 정책 체인을 가져오는 명령 형식입니다.

    $ 3scale policies import -f plan.yaml remote_name product_name
  • 다음은 URI에서 정책 체인을 가져오는 명령 형식입니다.

    $ 3scale policies import -f http[s]://domain/resource/path.yaml remote_name product_name

5.19. API 백엔드 복사

지정된 3scale 시스템에 지정된 소스 API 백엔드의 복사본을 만듭니다. 기본적으로 대상 시스템은 소스 백엔드 시스템 이름으로 먼저 검색합니다.

  • 선택한 시스템 이름의 백엔드를 찾을 수 없는 경우 생성됩니다.
  • 선택한 시스템 이름을 가진 백엔드가 발견되면 교체됩니다. 매핑 규칙은 완전히 새 항목으로 교체되는 동안 누락된 지표와 메서드만 생성됩니다.

target _system_name 옵션을 사용하여 시스템 이름을 재정의할 수 있습니다.

복사된 구성 요소

다음 API 백엔드 구성 요소가 복사됩니다.

  • 메트릭
  • 방법
  • 매핑 규칙: 복사 및 교체됩니다.

절차

  • 다음 명령을 입력하여 API 백엔드를 복사합니다.

    3scale backend copy [opts] -s <source_remote> -d <target_remote> <source_backend>

    지정된 3scale 인스턴스는 원격 이름 또는 URL일 수 있습니다.

    참고

    명령당 하나의 API 백엔드만 복사할 수 있습니다. 여러 명령을 사용하여 여러 백엔드를 복사할 수 있습니다. 다른 --target_system_name 이름을 지정하여 동일한 백엔드를 여러 번 복사할 수 있습니다.

API 백엔드를 복사할 때 다음 옵션을 사용합니다.

Options
    -d --destination=<value>             3scale target instance: URL or
                                         remote name (required).
    -s --source=<value>                  3scale source instance: URL or
                                         remote name (required).
    -t --target_system_name=<value>      Target system name: defaults to
                                         source system name.

다음 예제 명령은 --target_system_name 에 다른 값을 지정하여 API 백엔드를 여러 번 복사하는 방법을 보여줍니다.

$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale backend copy [-t target_system_name] -s 3scale1 -d 3scale2 api_backend_01

5.20. API 제품 복사

대상 3scale 시스템에 지정된 소스 API 제품의 복사본을 만듭니다. 기본적으로 소스 API 제품 시스템 이름은 먼저 대상 시스템을 검색합니다.

  • 선택한 system-name 을 가진 제품을 찾을 수 없는 경우 생성됩니다.
  • 선택한 시스템 이름의 제품이 있으면 업데이트됩니다. 매핑 규칙은 완전히 새 항목으로 교체되는 동안 누락된 지표와 메서드만 생성됩니다.

target _system_name 옵션을 사용하여 시스템 이름을 재정의할 수 있습니다.

복사된 구성 요소

다음 API 제품 구성 요소가 복사됩니다.

  • 구성 및 설정
  • 메트릭 및 방법
  • 매핑 규칙: 복사 및 교체됩니다.
  • 애플리케이션 계획, 가격 결정 규칙 및 제한 사항
  • 애플리케이션 사용 규칙
  • Policies
  • 백엔드
  • ActiveDocs

절차

  • 다음 명령을 입력하여 API 제품을 복사합니다.

    3scale product copy [opts] -s <source_remote> -d <target_remote> <source_product>

    지정된 3scale 인스턴스는 원격 이름 또는 URL일 수 있습니다.

    참고

    명령당 하나의 API 제품만 복사할 수 있습니다. 여러 명령을 사용하여 여러 제품을 복사할 수 있습니다. 다른 --target_system_name 이름을 지정하여 동일한 제품을 여러 번 복사할 수 있습니다.

API 제품을 복사할 때 다음 옵션을 사용합니다.

Options
    -d --destination=<value>             3scale target instance: URL or
                                         remote name (required).
    -s --source=<value>                  3scale source instance: URL or
                                         remote name (required).
    -t --target_system_name=<value>      Target system name: defaults to
                                         source system name.

다음 예제 명령은 --target_system_name 에 다른 값을 지정하여 API 제품을 여러 번 복사하는 방법을 보여줍니다.

$ podman run registry.redhat.io/3scale-amp2/toolbox-rhel8:3scale2.11 3scale product copy [-t target_system_name] -s 3scale1 -d 3scale2 my_api_product_01

5.21. SSL 및 TLS 관련 문제 해결

이 섹션에서는 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 관련 문제를 해결하는 방법을 설명합니다.

자체 서명 SSL 인증서와 관련된 문제가 발생하면 이 섹션에 설명된 대로 원격 호스트 인증서를 다운로드하여 사용할 수 있습니다. 예를 들어 일반적인 오류에는 SSL 인증서 문제, 즉 자체 서명된 인증서 또는 인증서 체인의 자체 서명 인증서가 포함됩니다.

절차

  1. 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
  2. curl 을 사용하여 인증서가 올바르게 작동하는지 확인합니다. 예를 들면 다음과 같습니다.

    $ SSL_CERT_FILE=self-signed-cert.pem curl -v https://self-signed.badssl.com

    인증서가 올바르게 작동하는 경우 더 이상 SSL 오류가 표시되지 않습니다. 인증서가 올바르게 작동하지 않는 경우 -k 옵션(또는 긴 형식인 --insecure)을 사용하여 curl 명령을 실행해 보십시오. 이는 비보안으로 간주되는 서버 연결에서도 진행하려고 함을 나타냅니다.

  3. SSL_CERT_FILE 환경 변수를 3scale 명령에 추가합니다. 예를 들면 다음과 같습니다.

    $ podman run --env "SSL_CERT_FILE=/tmp/self-signed-cert.pem" -v $PWD/self-signed-cert.pem:/tmp/self-signed-cert.pem egistry.redhat.io/3scale-amp2/toolbox-rhel7:3scale2.11 3scale service list https://{ACCESS_KEY}@{3SCALE_ADMIN}-admin.{DOMAIN_NAME}

    이 예에서는 Podman 볼륨을 사용하여 컨테이너에 인증서 파일을 마운트합니다. 현재 $PWD 폴더에서 파일을 사용할 수 있다고 가정합니다.

    대체 방법은 3scale toolbox 이미지를 기본 이미지로 사용하여 자체 toolbox 이미지를 생성한 다음 고유한 신뢰할 수 있는 인증서 저장소를 설치하는 것입니다.

추가 리소스

6장. 3scale에서 API 환경 매핑

API 프로바이더는 3scale 관리 포털을 통해 관리되는 API에 대한 액세스를 제공합니다. 그런 다음 다양한 환경에서 API 백엔드를 배포합니다. API 백엔드 환경에는 다음이 포함됩니다.

  • 개발, 품질 보증(QA), 스테이징 및 운영에 사용되는 다양한 환경.
  • 자체 API 백엔드 세트를 관리하는 팀 또는 부서에 사용되는 다양한 환경입니다.

Red Hat 3scale API Management 제품은 단일 API 또는 API 하위 집합을 나타내지만 다양한 API 백엔드 환경을 매핑하고 관리하는 데에도 사용됩니다.

3scale 제품의 API 환경 매핑에 대한 자세한 내용은 다음 섹션을 참조하십시오.

6.1. 환경별 제품

이 방법은 각 API 백엔드 환경에 별도의 3scale 제품을 사용합니다. 게이트웨이 구성 변경 사항을 API 백엔드와 마찬가지로 안전하게 테스트하고 프로덕션 구성으로 승격할 수 있도록 제품마다 프로덕션 게이트웨이와 스테이징 게이트웨이를 구성합니다.

Production Product => Production Product APIcast gateway => Production Product API upstream
Staging Product => Staging Product APIcast gateway => Staging Product API upstream

다음과 같이 API 백엔드 환경에 대한 제품을 구성합니다.

개발 환경

  • 개발 백엔드 만들기

    • 이름: Dev
    • 개인 기본 URL: API 백엔드의 URL
  • Dev 제품 만들기

    • 프로덕션 공개 기반 URL: https://dev-api-backend.yourdomain.com
    • 준비 공개 기본 URL: https://dev-api-backend.yourdomain.com
    • 백엔드 경로를 사용하여 Dev 백엔드 추가 /

QA 환경

  • QA 백엔드 만들기

    • 이름: QA
    • 개인 기본 URL: API 백엔드의 URL
  • QA 제품 만들기

    • 프로덕션 공개 기반 URL: https://qa-api-backend.yourdomain.com
    • 준비 공개 기본 URL: https://qa-api-backend.yourdomain.com
    • 백엔드 경로 / 를 사용하여 QA 백엔드 추가

프로덕션 환경

  • 프로덕션 백엔드 만들기

    • 이름: prod
    • 개인 기본 URL: API 백엔드의 URL
  • Prod 제품 만들기

추가 리소스

6.2. 3scale 온프레미스 인스턴스

3scale 온프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 여러 가지 방법이 있습니다.

  • 각 API 백엔드 환경에 대해 별도의 3scale 인스턴스
  • 멀티 테넌시 기능을 사용하는 단일 3scale 인스턴스

6.2.1. 환경당 3scale 인스턴스 분리

이 방법에서는 각 API 백엔드 환경에 별도의 3scale 인스턴스가 배포됩니다. 이 아키텍처의 이점은 각 환경이 서로 격리되므로 공유 데이터베이스 또는 기타 리소스가 없다는 것입니다. 예를 들어 한 환경에서 수행되는 모든 부하 테스트는 다른 환경의 리소스에 영향을 주지 않습니다.

참고

이러한 설치 분리는 위에서 설명한 대로 이점이 있지만 더 많은 운영 리소스와 유지 관리가 필요합니다. 이러한 추가 리소스는 OpenShift 관리 계층에 필요하며 3scale 계층에는 필요하지 않습니다.

6.2.2. 환경당 3scale 테넌트 분리

이 방법에서는 단일 3scale 인스턴스가 사용되지만 멀티 테넌시 기능은 여러 API 백엔드를 지원하는 데 사용됩니다.

두 가지 옵션이 있습니다.

  • 단일 테넌트 내에서 환경과 3scale 제품 간 1대-1 매핑을 만듭니다.
  • 필요에 따라 테넌트당 하나 이상의 제품을 사용하여 환경과 테넌트 간의 1대-1 매핑을 만듭니다.

    • API 백엔드 환경에 해당하는 테넌트 3개가 dev-tenant, qa-tenant, prod-tenant입니다. 이 접근 방식의 이점은 환경을 논리적으로 분리할 수 있지만 공유된 물리적 리소스를 사용한다는 것입니다.
참고

공유 물리적 리소스는 API 환경을 여러 테넌트가 있는 단일 설치에 매핑하기 위한 최적의 전략을 분석할 때 고려해야 합니다.

6.3. 3scale 혼합 접근 방식

3scale 온-프레미스 인스턴스에 설명된 접근법을 결합할 수 있습니다. 예를 들면 다음과 같습니다.

  • 프로덕션용 별도의 3scale 인스턴스
  • dev 및 qa의 프로덕션 이외의 환경에서 별도의 테넌트가 있는 별도의 3scale 인스턴스

6.4. APIcast 게이트웨이를 사용하는 3scale

3scale 온프레미스 인스턴스의 경우 API 백엔드 환경을 관리하기 위해 3scale을 설정하는 두 가지 대안이 있습니다.

  • 3scale 설치마다 스테이징 및 프로덕션을 위한 2개의 내장 APIcast 게이트웨이가 제공됩니다.
  • 3scale이 실행 중인 OpenShift 클러스터에 추가 APIcast 게이트웨이를 배포합니다.

6.4.1. APIcast 기본 제공 기본 게이트웨이

APIcast 내장 게이트웨이를 사용하면 API cast 게이트웨이와 함께 3scale에 설명된 위의 방식으로 구성된 API 백엔드가 자동으로 처리됩니다. 3scale Master Admin에서 테넌트를 추가하면 프로덕션 및 기본 제공 APIcast 게이트웨이를 스테이징하는 테넌트에 대한 경로가 생성됩니다. 멀티 테넌시 하위 도메인 이해

  • <API_NAME>-<TENANT_NAME>-apicast.staging.<WILDCARD_DOMAIN>
  • <API_NAME>-<TENANT_NAME>-apicast.production.<WIDLCARD_DOMAIN>

따라서 다른 테넌트에 매핑되는 각 API 백엔드 환경에는 해당 경로가 할당됩니다. 예를 들면 다음과 같습니다.

  • Dev <API_NAME>-dev-apicast.staging.<WILDCARD_DOMAIN>
  • QA <API_NAME>-qa-apicast.staging.<WILDCARD_DOMAIN>
  • prod <API_NAME>-prod-apicast.staging.<WILDCARD_DOMAIN>

6.4.2. 추가 APIcast 게이트웨이

추가 APIcast 게이트웨이는 3scale 인스턴스가 실행 중인 것과 다른 OpenShift 클러스터에 배포됩니다. 추가 APIcast 게이트웨이를 설정하고 사용하는 방법은 여러 가지가 있습니다. APIcast를 시작할 때 사용되는 환경 변수 THREESCALE_PORTAL_ENDPOINT 의 값은 추가 APIcast 게이트웨이를 설정하는 방법에 따라 다릅니다.

각 API 백엔드 환경에 별도의 APIcast 게이트웨이를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

DEV_APICAST -> DEV_TENANT ; DEV_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for DEV_TENANT
QA_APICAST -> QA_TENANT ; QA_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for QA_APICAST
PROD_APICAST -> PROD_TENANT ; PROD_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for PROD_APICAST

THREESCALE_PORTAL_ENDPOINT 는 APIcast에서 구성을 다운로드하는 데 사용됩니다. API 백엔드 환경에 매핑되는 각 테넌트는 별도의 APIcast 게이트웨이를 사용합니다. THREESCALE_PORTAL_ENDPOINT 는 해당 API 백엔드 환경과 관련된 모든 제품 구성을 포함하는 테넌트의 관리 포털로 설정됩니다.

단일 APIcast 게이트웨이를 여러 API 백엔드 환경에서 사용할 수 있습니다. 이 경우 THREESCALE_PORTAL_ENDPOINT마스터 관리 포털 로 설정됩니다.

추가 리소스

  • API 공급자에 대한 자세한 내용은 용어집을 참조하십시오.
  • 3scale 제품에 대한 자세한 내용은 용어집을 참조하십시오.

7장. 3scale toolbox로 API 라이프사이클 자동화

이 주제에서는 Red Hat 3scale API Management를 통한 API 라이프사이클 개념에 대해 설명하고 3scale toolbox 명령을 사용하여 Jenkins CI/CD(Continuous Deployment) 파이프라인을 사용하여 API 프로바이더가 배포 단계를 자동화하는 방법을 보여줍니다. 샘플 Jenkins CI/CD 파이프라인을 배포하는 방법, 3scale 공유 라이브러리를 사용하여 사용자 정의 Jenkins 파이프라인 생성 방법 및 처음부터 사용자 정의 파이프라인 생성 방법을 설명합니다.

7.1. API 라이프사이클 단계 개요

API 라이프사이클은 더 이상 사용되지 않을 때까지 API가 생성될 때 까지 필요한 모든 활동을 설명합니다. 3scale을 사용하면 API 프로바이더가 전체 API 라이프사이클 관리를 수행할 수 있습니다. 이 섹션에서는 API 라이프사이클의 각 단계에 대해 설명하고 해당 목표와 예상 결과를 설명합니다.

다음 다이어그램에서는 왼쪽의 API 공급자 기반 단계와 오른쪽에 API 소비자 기반 단계를 보여줍니다.

API 라이프사이클 단계
참고

Red Hat은 현재 API 프로바이더 사이클 단계 및 API 소비자 사이클의 모든 단계를 설계, 구현, 배포, 보안 및 관리합니다.

7.1.1. API 공급자 사이클

API 프로바이더 사이클 단계는 API 지정, 개발 및 배포를 기반으로 합니다. 다음은 각 단계의 목표와 결과를 설명합니다.

표 7.1. API 공급자 라이프사이클 단계

Stage목적결과

1. 전략

목표, 리소스, 목표 시장, 기간을 비롯하여 API의 기업 전략을 결정하고 계획을 수립합니다.

기업 전략은 목표 달성을 위한 명확한 계획으로 정의됩니다.

2. 설계

API 계약을 조기에 만들어 프로젝트 간 종속성을 해제하고 피드백을 수집하며, 위험과 출시 시간을 줄입니다(예: Apicurio Studio 사용).

소비자 중심의 API 계약은 API와 교환할 수 있는 메시지를 정의합니다. API 소비자는 피드백을 제공했습니다.

3. Mock

API 소비자가 구현을 시작하는 데 사용할 수 있는 실제 예제 및 페이로드를 사용하여 API 계약을 추가로 지정합니다.

mock API가 실시간이며 실제 예제를 반환합니다. API 계약이 예제로 완료되었습니다.

4. 테스트

개발 API를 테스트하는 데 사용할 수 있는 비즈니스 기대 사항과 API 계약을 추가로 지정합니다.

일련의 수락 테스트가 생성됩니다. API 설명서는 비즈니스의 기대에 부응합니다.

5. 구현

Red Hat Fuse와 같은 통합 프레임워크 또는 원하는 개발 언어를 사용하여 API를 구현합니다. 구현이 API 계약과 일치하는지 확인합니다.

API가 구현됩니다. 사용자 지정 API 관리 기능이 필요한 경우 3scale APIcast 정책도 개발됩니다.

6. 배포

3scale toolbox와 함께 CI/CD 파이프라인을 사용하여 API 통합, 테스트, 배포 및 관리를 자동화합니다.

CI/CD 파이프라인은 자동화된 방식으로 프로덕션 환경에 API를 통합, 테스트, 배포 및 관리합니다.

7. 보안

API가 안전한지 확인합니다(예: 보안 개발 사례 및 자동화된 보안 테스트 사용).

보안 지침, 프로세스 및 게이트가 마련되어 있습니다.

8. 관리

환경, 버전 관리, 폐기, 규모에 따른 폐기 간의 API 승격 관리.

프로세스 및 도구는 대규모 API를 관리하기 위한 것입니다(예: API의 변경 사항을 분리하지 않도록 의미 버전 지정).

7.1.2. API 소비자 주기

API 소비자 사이클 단계는 사용을 위해 API를 승격, 배포 및 재설정하는 방법을 기반으로 합니다. 다음은 각 단계의 목표와 결과를 설명합니다.

표 7.2. API 소비자 라이프사이클 단계

Stage목적결과

9. 검색

API를 타사 개발자, 파트너 및 내부 사용자에게 홍보합니다.

개발자 포털은 실시간 및 최신 문서가 지속적으로 이 개발자 포털(예: 3scale ActiveDocs 사용)으로 푸시됩니다.

10. 개발

타사 개발자, 파트너 및 내부 사용자를 안내하고 API를 기반으로 애플리케이션을 개발할 수 있도록 합니다.

개발자 포털에는 모범 사례, 가이드 및 권장 사항이 포함되어 있습니다. API 개발자는 mock 및 테스트 엔드포인트에 액세스하여 소프트웨어를 개발할 수 있습니다.

11. 사용

증가하는 API 사용을 처리하고 대규모의 API 소비자를 관리합니다.

준비된 애플리케이션 계획은 소비가 가능하며 최신 가격 및 제한사항이 지속적으로 반영됩니다. API 소비자는 CI/CD 파이프라인에서 API 키 또는 클라이언트 ID/시크릿 생성을 통합할 수 있습니다.

12. 모니터

API 상태, 품질 및 개발자 참여에 대한 팩트 및 수량화된 피드백을 수집합니다(예: Time to first Hello World!).

모니터링 시스템이 설치되어 있습니다. 대시보드에는 API에 대한 KPI(예: 가동 시간, 분당 요청, 대기 시간 등)가 표시됩니다.

13. 수익화

규모에 따라 새 수입을 유도합니다(이 단계는 선택 사항임).

예를 들어, 다수의 소규모 API 소비자를 대상으로 하는 경우 수익화가 활성화되고 소비자는 자동화된 방식으로 사용량에 따라 청구됩니다.

7.2. 샘플 Jenkins CI/CD 파이프라인 배포

3scale toolbox를 사용한 API 라이프사이클 자동화에서는 API 라이프사이클의 배포 단계에 중점을 두고 CI/CD 파이프라인을 사용하여 API 관리 솔루션을 자동화할 수 있습니다. 이 주제에서는 3scale toolbox를 호출하는 샘플 Jenkins 파이프라인을 배포하는 방법에 대해 설명합니다.

7.2.1. Jenkins CI/CD 파이프라인 샘플

다음 샘플은 API 라이프사이클 자동화를 위해 Jenkins 파이프라인을 생성하고 배포하는 방법에 대한 예로 Red Hat 통합 리포지토리에 제공됩니다.

표 7.3. Jenkins 공유 라이브러리 파이프라인 샘플

샘플 파이프라인대상 환경보안

SaaS - API 키

3scale 호스팅

API 키

하이브리드 - 오픈

APIcast 자체 관리가 포함된 3scale 호스팅 및 3scale 온프레미스

없음

하이브리드 - OpenID Connect

APIcast 자체 관리가 포함된 3scale 호스팅 및 3scale 온프레미스

OpenID Connect (OIDC)

다중 환경

3scale APIcast 자체 관리와 함께 개발, 테스트 및 프로덕션 호스팅

API 키

의미 체계 버전

3scale APIcast 자체 관리와 함께 개발, 테스트 및 프로덕션 호스팅

API 키, 없음, OIDC

이러한 샘플은 3scale 툴박스를 호출하여 주요 API 관리 기능을 보여주는 3scale Jenkins 공유 라이브러리를 사용합니다. 이 항목에서 설정 단계를 수행한 후 Red Hat 통합 리포지토리의 각 샘플 사용 사례에 제공된 OpenShift 템플릿을 사용하여 파이프라인을 설치할 수 있습니다.

중요

샘플 파이프라인 및 애플리케이션은 예제로만 제공됩니다. 샘플 파이프라인에서 활용하는 기본 API, CLI 및 기타 인터페이스는 Red Hat에서 완벽하게 지원합니다. 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다.

7.2.2. 3scale 호스팅 환경 설정

3scale 호스팅 환경 설정은 모든 샘플 Jenkins CI/CD 파이프라인에 필요합니다.

참고

SaaS - API 키,멀티 환경의미 버전 지정 샘플 파이프라인은 3scale 호스팅만 사용합니다. 하이브리드 - 개방형 하이브리드 - OIDC 파이프라인은 또한 3scale 온프레미스를 사용합니다. 또한 3scale 온-프레미스 환경 설정을 참조하십시오.

사전 요구 사항

절차

  1. 3scale 호스팅 관리 포털 콘솔에 로그인합니다.
  2. 계정 관리 API에 대한 쓰기 액세스 권한이 있는 새 액세스 토큰을 생성합니다.
  3. 나중에 사용하기 위해 생성된 액세스 토큰을 저장합니다. 예를 들면 다음과 같습니다.

    export SAAS_ACCESS_TOKEN=123...456
  4. 나중에 사용하기 위해 3scale 테넌트의 이름을 저장합니다. 관리 포털 URL에서 -admin.3scale.net 이전의 문자열입니다. 예를 들면 다음과 같습니다.

    export SAAS_TENANT=my_username
  5. 관리 포털의 대상 &gt ; 계정 > 목록으로 이동합니다.
  6. Developer (개발자)를 클릭합니다.
  7. 개발자 계정 ID 를 저장합니다. /buyers/accounts/ 뒤의 URL의 마지막 부분입니다. 예를 들면 다음과 같습니다.

    export SAAS_DEVELOPER_ACCOUNT_ID=123...456

7.2.3. 3scale 온프레미스 환경 설정

3scale 온프레미스 환경 설정은 하이브리드( 오픈 및 하이브리드) - OIDC 샘플 Jenkins CI/CD 파이프라인에만 필요합니다.

참고

이러한 하이브리드 샘플 파이프라인을 사용하려면 3scale 온프레미스 환경과 3scale 호스팅 환경을 설정해야 합니다. 3scale 호스팅 환경 설정 도 참조하십시오.

사전 요구 사항

절차

  1. 3scale 사내 관리 포털 콘솔에 로그인합니다.
  2. 계정 관리 API에 대한 쓰기 액세스 권한이 있는 새 액세스 토큰을 생성합니다.
  3. 나중에 사용하기 위해 생성된 액세스 토큰을 저장합니다. 예를 들면 다음과 같습니다.

    export SAAS_ACCESS_TOKEN=123...456
  4. 나중에 사용하기 위해 3scale 테넌트의 이름을 저장합니다.

    export ONPREM_ADMIN_PORTAL_HOSTNAME="$(oc get route system-provider-admin -o jsonpath='{.spec.host}')"
  5. 와일드카드 경로를 정의합니다.

    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)로 설정해야 합니다.

  6. 기존 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
  7. 관리 포털의 대상 &gt ; 계정 > 목록으로 이동합니다.
  8. Developer (개발자)를 클릭합니다.
  9. 개발자 계정 ID 를 저장합니다. /buyers/accounts/:

    export ONPREM_DEVELOPER_ACCOUNT_ID=5

7.2.4. OpenID Connect용 Red Hat Single Sign-On 배포

Hybrid - OpenID Connect (OIDC) 또는 Semantic 버전 지정 샘플 파이프라인을 사용하는 경우 이 섹션의 단계를 수행하여 3scale로 RH-SSO(Red Hat Single Sign-On)를 배포합니다. 이는 두 샘플 모두에서 사용되는 OIDC 인증에 필요합니다.

절차

  1. RH-SSO 7.3 설명서에 설명된 대로 RH-SSO 7.3을 배포합니다.

    다음 예제 명령은 간단한 요약을 제공합니다.

    oc replace -n openshift --force -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso73-dev/templates/sso73-image-stream.json
    
    oc replace -n openshift --force -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso73-dev/templates/sso73-x509-postgresql-persistent.json
    
    oc -n openshift import-image redhat-sso73-openshift:1.0
    
    oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
    
    oc new-app --template=sso73-x509-postgresql-persistent --name=sso -p DB_USERNAME=sso -p SSO_ADMIN_USERNAME=admin -p DB_DATABASE=sso
  2. 나중에 사용하기 위해 RH-SSO 설치의 호스트 이름을 저장합니다.

    export SSO_HOSTNAME="$(oc get route sso -o jsonpath='{.spec.host}')"
  3. 3scale 개발자 포털 설명서에 설명된 대로 RH-SSO for 3scale 을 구성합니다.
  4. 나중에 사용하기 위해 영역 이름, 클라이언트 ID 및 클라이언트 시크릿을 저장합니다.

    export REALM=3scale
    
    export CLIENT_ID=3scale-admin
    
    export CLIENT_SECRET=123...456

7.2.5. 3scale toolbox 설치 및 액세스 활성화

이 섹션에서는 toolbox를 설치하고, 원격 3scale 인스턴스를 생성하며, 관리 포털에 액세스하는 데 사용되는 시크릿을 프로비저닝하는 방법을 설명합니다.

절차

  1. 3scale toolbox에 설명된 대로 3scale toolbox 를 로컬로 설치합니다.
  2. 적절한 toolbox 명령을 실행하여 3scale 원격 인스턴스를 생성합니다.

    3scale 호스팅

    3scale remote add 3scale-saas "https://$SAAS_ACCESS_TOKEN@$SAAS_TENANT-admin.3scale.net/"

    3scale 온프레미스

    3scale remote add 3scale-onprem "https://$ONPREM_ACCESS_TOKEN@$ONPREM_ADMIN_PORTAL_HOSTNAME/"

  3. 다음 OpenShift 명령을 실행하여 3scale 관리 포털 및 액세스 토큰이 포함된 시크릿을 프로비저닝합니다.

    oc create secret generic 3scale-toolbox -n "$TOOLBOX_NAMESPACE" --from-file="$HOME/.3scalerc.yaml"

7.2.6. API 백엔드 배포

이 섹션에서는 샘플 파이프라인과 함께 제공되는 예제 API 백엔드를 배포하는 방법을 보여줍니다. 자체 파이프라인을 생성 및 배포할 때 필요에 따라 자체 API 백엔드를 교체할 수 있습니다.

절차

  1. 다음 샘플과 함께 사용할 예제 Beer Catalog API 백엔드를 배포합니다.

    • SaaS - API 키
    • 하이브리드 - 오픈
    • 하이브리드 - OIDC

      oc new-app -n "$TOOLBOX_NAMESPACE" -i openshift/redhat-openjdk18-openshift:1.4 https://github.com/microcks/api-lifecycle.git --context-dir=/beer-catalog-demo/api-implementation --name=beer-catalog
      
      oc expose -n "$TOOLBOX_NAMESPACE" svc/beer-catalog
  2. 나중에 사용하기 위해 Beer Catalog API 호스트 이름을 저장합니다.

    export BEER_CATALOG_HOSTNAME="$(oc get route -n "$TOOLBOX_NAMESPACE" beer-catalog -o jsonpath='{.spec.host}')"
  3. 다음 샘플과 함께 사용할 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
  4. 나중에 사용하기 위해 이벤트 API 호스트 이름을 저장합니다.

    export EVENT_API_HOSTNAME="$(oc get route -n "$TOOLBOX_NAMESPACE" event-api -o jsonpath='{.spec.host}')"

7.2.7. 자체 관리 APIcast 인스턴스 배포

이 섹션은 3scale 호스팅 환경에서 APIcast 자체 관리 인스턴스에 사용하기 위한 것입니다. SaaS - API 키를 제외한 모든 샘플 파이프라인에 적용됩니다.

절차

  1. 와일드카드 경로를 정의합니다.

    export APICAST_SELF_MANAGED_STAGING_WILDCARD_DOMAIN=saas-staging.$OPENSHIFT_ROUTER_SUFFIX
    
    export APICAST_SELF_MANAGED_PRODUCTION_WILDCARD_DOMAIN=saas-production.$OPENSHIFT_ROUTER_SUFFIX
  2. 프로젝트에 APIcast 자체 관리 인스턴스를 배포합니다.

    oc create secret generic 3scale-tenant --from-literal=password=https://$SAAS_ACCESS_TOKEN@$SAAS_TENANT-admin.3scale.net
    
    oc create -f https://raw.githubusercontent.com/3scale/apicast/v3.5.0/openshift/apicast-template.yml
    
    oc new-app --template=3scale-gateway --name=apicast-staging -p CONFIGURATION_URL_SECRET=3scale-tenant -p CONFIGURATION_CACHE=0 -p RESPONSE_CODES=true -p LOG_LEVEL=info -p CONFIGURATION_LOADER=lazy -p APICAST_NAME=apicast-staging -p DEPLOYMENT_ENVIRONMENT=sandbox -p IMAGE_NAME=registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.11
    
    oc new-app --template=3scale-gateway --name=apicast-production -p CONFIGURATION_URL_SECRET=3scale-tenant -p CONFIGURATION_CACHE=60 -p RESPONSE_CODES=true -p LOG_LEVEL=info -p CONFIGURATION_LOADER=boot -p APICAST_NAME=apicast-production -p DEPLOYMENT_ENVIRONMENT=production -p IMAGE_NAME=registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.11
    
    oc scale dc/apicast-staging --replicas=1
    
    oc scale dc/apicast-production --replicas=1
    
    oc create route edge apicast-staging --service=apicast-staging --hostname="wildcard.$APICAST_SELF_MANAGED_STAGING_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain
    
    oc create route edge apicast-production --service=apicast-production --hostname="wildcard.$APICAST_SELF_MANAGED_PRODUCTION_WILDCARD_DOMAIN" --insecure-policy=Allow --wildcard-policy=Subdomain

7.2.8. 샘플 파이프라인 설치 및 배포

필수 환경을 설정한 후에는 Red Hat 통합 리포지토리의 각 샘플 사용 사례에 제공된 OpenShift 템플릿을 사용하여 샘플 파이프라인을 설치하고 배포할 수 있습니다. 예를 들어 이 섹션에는 SaaS - API Key 샘플만 표시됩니다.

절차

  1. 제공된 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 -
  2. 다음과 같이 샘플을 배포합니다.

    oc start-build saas-usecase-apikey

7.2.9. 3scale toolbox를 사용한 API 라이프사이클 자동화의 제한 사항

이 릴리스에서는 다음과 같은 제한 사항이 적용됩니다.

OpenShift 지원
샘플 파이프라인은 OpenShift 3.11에서만 지원됩니다. OpenShift 4는 현재 지원되지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat 3scale API Management Supported Configurations 페이지를 참조하십시오.
애플리케이션 업데이트
  • 3scale 애플리케이션 apply toolbox 명령을 사용하여 애플리케이션을 생성하고 업데이트할 수 있습니다. 지원 명령 생성 계정, 계획, 서비스 및 애플리케이션 키.
  • 업데이트 명령은 계정, 계획 또는 서비스의 변경 사항을 지원하지 않습니다. 변경 사항이 전달되면 파이프라인이 트리거되고 오류가 표시되지 않지만 해당 필드는 업데이트되지 않습니다.
서비스 복사
3scale 복사 서비스 toolbox 명령을 사용하여 사용자 지정 정책으로 서비스를 복사하는 경우 사용자 지정 정책을 먼저 별도로 복사해야 합니다.

7.3. 3scale Jenkins 공유 라이브러리를 사용하여 파이프라인 생성

이 섹션에서는 3scale toolbox를 사용하는 사용자 지정 Jenkins 파이프라인을 생성하는 모범 사례를 제공합니다. 3scale Jenkins 공유 라이브러리를 사용하여 예제 애플리케이션을 기반으로 toolbox를 호출하는 방법인 Groovy에서 Jenkins 파이프라인을 작성하는 방법을 설명합니다. 자세한 내용은 Jenkins 공유 라이브러리를 참조하십시오.

중요

Red Hat은 Red Hat 통합 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.

이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 대해 생성한 사용자 지정 파이프라인은 지원되지 않습니다.

사전 요구 사항

절차

  1. Jenkins 파이프라인 시작 부분에 다음을 추가하여 파이프라인에서 3scale 공유 라이브러리를 참조합니다.

    #!groovy
    
    library identifier: '3scale-toolbox-jenkins@master',
       retriever: modernSCM([$class: 'GitSCMSource',
         remote: 'https://github.com/rh-integration/3scale-toolbox-jenkins.git'])
  2. 3- scaleService 오브젝트를 보유 하도록 글로벌 변수를 선언하여 파이프라인의 여러 단계에서 사용할 수 있습니다.

    def service = null
  3. 모든 관련 정보를 사용하여 three scaleService 를 만듭니다.

    stage("Prepare") {
      service = toolbox.prepareThreescaleService(
         openapi: [ filename: "swagger.json" ],
         environment: [ baseSystemName: "my_service" ],
         toolbox: [ openshiftProject: "toolbox",
                       destination: "3scale-tenant",
                       secretName: "3scale-toolbox" ],
         service: [:],
         applications: [
            [ name: "my-test-app", description: "This is used for tests", plan: "test", account: "<CHANGE_ME>" ]
            ],
         applicationPlans: [
           [ systemName: "test", name: "Test", defaultPlan: true, published: true ],
           [ systemName: "silver", name: "Silver" ],
           [ artefactFile: "https://raw.githubusercontent.com/my_username/API-Lifecycle-Mockup/master/testcase-01/plan.yaml"],
         ]
        )
    
      echo "toolbox version = " + service.toolbox.getToolboxVersion()
     }
    • OpenAPI.filename 은 OpenAPI 사양을 포함하는 파일의 경로입니다.
    • environment.baseSystemNameenvironment.environmentName 및 OpenAPI 사양 info. version 의 API 주 버전을 기반으로 최종 system_name 을 계산하는 데 사용됩니다.
    • toolbox.openshiftProject 는 Kubernetes 작업이 생성될 OpenShift 프로젝트입니다.
    • Toolbox.secretName 은 3scale toolbox 설치 및 액세스 활성화에 표시된 대로 3scale toolbox 구성 파일이 포함된 Kubernetes 시크릿의 이름입니다.
    • toolbox.destination 은 3scale toolbox 원격 인스턴스의 이름입니다.
    • applicationPlans.yaml 파일을 사용하거나 애플리케이션 계획 속성 세부 정보를 제공하여 생성할 애플리케이션 계획 목록입니다.
  4. 3scale에서 서비스를 프로비저닝하는 파이프라인 단계를 추가합니다.

    stage("Import OpenAPI") {
      service.importOpenAPI()
      echo "Service with system_name ${service.environment.targetSystemName} created !"
    }
  5. 애플리케이션 계획을 생성하는 단계를 추가합니다.

    stage("Create an Application Plan") {
      service.applyApplicationPlans()
    }
  6. 글로벌 변수와 단계를 추가하여 테스트 애플리케이션을 생성합니다.

    stage("Create an Application") {
      service.applyApplication()
    }
  7. 통합 테스트를 실행하는 단계를 추가합니다. APIcast 호스팅 인스턴스를 사용하는 경우 프록시 정의를 가져와 스테이징 공용 URL을 추출해야 합니다.

    stage("Run integration tests") {
      def proxy = service.readProxy("sandbox")
      sh """set -e +x
      curl -f -w "ListBeers: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer -H 'api-key: ${service.applications[0].userkey}'
      curl -f -w "GetBeer: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer/Weissbier -H 'api-key: ${service.applications[0].userkey}'
      curl -f -w "FindBeersByStatus: %{http_code}\n" -o /dev/null -s ${proxy.sandbox_endpoint}/api/beer/findByStatus/   available -H 'api-key: ${service.applications[0].userkey}'
      """
    }
  8. API를 프로덕션으로 승격하는 단계를 추가합니다.

    stage("Promote to production") {
      service.promoteToProduction()
    }

7.4. Jenkinsfile을 사용하여 파이프라인 생성

이 섹션에서는 3scale 툴박스를 사용하는 Groovy에서 처음부터 사용자 지정 Jenkinsfile 을 작성하는 모범 사례를 제공합니다.

중요

Red Hat은 Red Hat 통합 리포지토리에 제공된 Jenkins 파이프라인 샘플을 지원합니다.

이러한 파이프라인에 대한 수정 사항은 Red Hat에서 직접 지원하지 않습니다. 환경에 대해 생성한 사용자 지정 파이프라인은 지원되지 않습니다. 이 섹션은 참조용으로만 제공됩니다.

사전 요구 사항

절차

  1. 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.11",
                 "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 작업을 생성하고, 대기합니다.

    • CreatedRunning 상태 간에 포드를 전환해야 하는 시간과 일치하도록 서버 속도에 맞게 대기 기간을 조정할 수 있습니다. 폴링 루프를 사용하여 이 단계를 구체화할 수 있습니다.
    • OpenAPI 사양 파일은 openapi라는 ConfigMap 에서 가져옵니다.
    • 3scale 관리 포털 호스트 이름 및 액세스 토큰은 3scale toolbox 설치 및 액세스 활성화에 표시된 대로 3scale-toolbox 라는 시크릿에서 가져옵니다.
    • ConfigMap 은 파이프라인에서 3단계에서 생성됩니다. 그러나 보안은 이미 파이프라인 외부에 프로비저닝되었으며 보안을 강화하기 위해 RBAC(역할 기반 액세스 제어)가 적용됩니다.
  2. Jenkins 파이프라인 단계에서 3scale toolbox와 함께 사용할 글로벌 환경 변수를 정의합니다. 예를 들면 다음과 같습니다.

    3scale 호스팅

    def targetSystemName = "saas-apikey-usecase"
    def targetInstance = "3scale-saas"
    def privateBaseURL = "http://echo-api.3scale.net"
    def testUserKey = "abcdef1234567890"
    def developerAccountId = "john"

    3scale 온프레미스

    자체 관리 APIcast를 사용하거나 3scale의 온프레미스 설치를 사용하는 경우 다음 두 가지 변수를 선언해야 합니다.

    def publicStagingBaseURL = "http://my-staging-api.example.test"
    def publicProductionBaseURL = "http://my-production-api.example.test"

    변수는 다음과 같이 설명됩니다.

    • targetSystemName: 생성할 서비스의 이름입니다.
    • targetInstance: 3scale toolbox 설치 및 액세스 활성화에서 생성된 3scale 원격 인스턴스의 이름과 일치합니다.
    • privateBaseURL: API 백엔드의 엔드포인트 호스트입니다.
    • testUserKey: 통합 테스트를 실행하는 데 사용되는 사용자 API 키입니다. 표시된 대로 하드 코딩하거나 HMAC 함수에서 생성할 수 있습니다.
    • developerAccountId: 테스트 애플리케이션이 생성될 대상 계정의 ID입니다.
    • publicStagingBaseURL: 생성할 서비스의 공개 스테이징 기반 URL입니다.
    • publicProductionBaseURL: 생성할 서비스의 공개 프로덕션 기본 URL입니다.
  3. 파이프라인 단계를 추가하여 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"
       """
     }
  4. 3scale 툴박스를 사용하여 API를 3scale로 가져오는 파이프라인 단계를 추가합니다.

    3scale 호스팅

    stage("Import OpenAPI") {
      runToolbox([ "3scale", "import", "openapi", "-d", targetInstance, "/artifacts/swagger.json", "--override-private-base-url=${privateBaseURL}", "-t", targetSystemName ])
    }

    3scale 온프레미스

    자체 관리 APIcast를 사용하거나 3scale의 온프레미스 설치를 사용하는 경우 공용 스테이징 및 프로덕션 기반 URL에 대한 옵션도 지정해야 합니다.

    stage("Import OpenAPI") {
      runToolbox([ "3scale", "import", "openapi", "-d", targetInstance, "/artifacts/swagger.json", "--override-private-base-url=${privateBaseURL}", "-t", targetSystemName, "--production-public-base-url=${publicProductionBaseURL}", "--staging-public-base-url=${publicStagingBaseURL}" ])
    }
  5. 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}'
      """
    }
  6. toolbox를 사용하여 API를 프로덕션 환경으로 승격하는 단계를 추가합니다.

    stage("Promote to production") {
      runToolbox([ "3scale", "proxy", "promote", targetInstance,  targetSystemName ])
    }

8장. 3scale 연산자를 사용하여 3scale 구성 및 프로비저닝

3scale 관리자는 3scale 연산자를 사용하여 3scale 서비스를 구성하고 3scale 리소스를 프로비저닝할 수 있습니다. OCP(OpenShift Container Platform) 사용자 인터페이스에서 Operator를 사용합니다. 운영자를 사용하는 것은 관리 포털에서 또는 3scale 내부 API를 사용하여 3scale을 구성하고 프로비저닝하는 대안입니다.

3scale 운영자를 사용하여 서비스를 구성하거나 리소스를 프로비저닝하는 경우 해당 서비스 또는 리소스를 업데이트하는 유일한 방법은 CR(사용자 정의 리소스)을 업데이트하는 것입니다. 관리 포털에 새 서비스와 리소스가 표시되는 경우 관리 포털에서 또는 내부 3scale API를 사용하여 서비스 또는 리소스를 업데이트할 수 없습니다. 를 시도하면 Operator가 업데이트를 되돌리고 CR은 그대로 유지됩니다.

중요

기능을 위한 3scale 연산자는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

이 장에서는 운영자 애플리케이션 기능이 작동하는 방법과 사용자 정의 리소스를 배포하는 Operator를 사용하는 방법에 대해 자세히 설명합니다.

또한 3scale 연산자를 사용할 때의 기능 제한에 대한 정보가 있습니다.

8.1. 일반 사전 요구 사항

3scale 연산자를 사용하여 3scale을 구성하고 프로비저닝하는 데 필요한 요소는 다음과 같습니다.

8.2. 3scale Operator를 통한 애플리케이션 기능

3scale Operator에는 다음과 같은 기능이 포함되어 있습니다.

  • 기본 Red Hat 3scale API Management 솔루션과의 상호 작용 지원.
  • OpenShift의 사용자 지정 리소스를 사용하여 3scale 애플리케이션을 선언적으로 관리합니다.

아래 다이어그램은 선언적 방식으로 OpenShift 사용자 지정 리소스를 사용하여 관리가 가능한 3scale 엔터티 및 관계를 보여줍니다. 제품에는 하나 이상의 백엔드가 포함됩니다. 제품 수준에서는 애플리케이션, 애플리케이션 계획 및 매핑 규칙을 구성할 수 있습니다. 백엔드 수준에서 각 백엔드에 대한 지표, 메서드 및 매핑 규칙을 설정할 수 있습니다.

3scale 엔터티 및 OpenShift 사용자 지정 리소스를 사용하여 관리가 가능한 관계.

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

3scale 엔터티 및 OpenShift 사용자 지정 리소스를 사용하여 관리가 가능한 관계.

8.3. 첫 번째 3scale 제품 및 백엔드 배포

새로 생성된 테넌트에서 Openshift Container Platform을 사용하여 필요한 최소 구성으로 첫 3scale 제품 및 백엔드를 배포합니다.

사전 요구 사항

일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항과 다음 사항을 고려합니다.

  • 3scale 계정은 작동하는 OpenShift 네임스페이스 또는 원격 설치에서 로컬이 될 수 있습니다.
  • 이 계정의 필수 매개 변수는 3scale 관리 URL 주소와 액세스 토큰입니다.

절차

  1. 3scale 관리 포털의 자격 증명을 사용하여 3scale 프로바이더 계정의 시크릿을 생성합니다. 예: adminURL=https://3scale-admin.example.comtoken=123456

    oc create secret generic threescale-provider-account --from-literal=adminURL=https://3scale-admin.example.com --from-literal=token=123456
  2. 업스트림 API URL을 사용하여 3scale 백엔드를 구성합니다.

    1. 다음 콘텐츠를 사용하여 YAML 파일을 생성합니다.

      apiVersion: capabilities.3scale.net/v1beta1
      kind: Backend
      metadata:
        name: backend1
      spec:
        name: "Operated Backend 1"
        systemName: "backend1"
        privateBaseURL: "https://api.example.com"
      • 파일을 만들고 나면 운영자가 해당 단계가 성공했는지 확인합니다.
      • 백엔드 사용자 정의 리소스 필드 및 가능한 값에 대한 자세한 내용은 백엔드 CRD 참조를 참조하십시오.
    2. 사용자 정의 리소스를 생성합니다.

      oc create -f backend1.yaml
  3. 3scale 제품을 구성합니다.

    1. 이전에 생성한 백엔드에 적용된 모든 기본 설정으로 제품을 생성합니다.

      apiVersion: capabilities.3scale.net/v1beta1
      kind: Product
      metadata:
        name: product1
      spec:
        name: "OperatedProduct 1"
        systemName: "operatedproduct1"
        backendUsages:
          backend1:
            path: /
      • 파일을 만들고 나면 운영자가 해당 단계가 성공했는지 확인합니다.
      • 제품 사용자 정의 리소스 필드와 가능한 값에 대한 자세한 내용은 Product CRD 참조를 참조하십시오.
    2. 사용자 정의 리소스를 생성합니다.

      oc create -f product1.yaml
  4. 생성된 사용자 지정 리소스는 3scale 인스턴스를 채우는 데 몇 초가 걸립니다. 리소스가 동기화되는 경우 다음 대안 중 하나를 선택할 수 있습니다.

    • 오브젝트의 status 필드를 확인합니다.
    • oc wait 명령을 사용합니다.

      oc wait --for=condition=Synced --timeout=-1s backend/backend1
      oc wait --for=condition=Synced --timeout=-1s product/product1

8.4. 제품의 APIcast 구성 승격

3scale Operator를 사용하여 제품의 APIcast 구성을 스테이징 또는 프로덕션으로 승격할 수 있습니다. ProxyConfigPromote 사용자 정의 리소스(CR)는 최신 APIcast 구성을 스테이징 환경으로 승격합니다. 필요한 경우 production 환경으로 승격하도록 ProxyConfigPromote CR을 구성할 수 있습니다.

참고

ProxyConfigPromote 오브젝트는 생성 시에만 적용됩니다. 생성 후에는 해당 업데이트가 조정되지 않습니다.

사전 요구 사항

다음을 포함하여 일반 사전 요구 사항에 나열된 것과 동일한 설치 요구 사항:

  • 제품 CR 이 이미 생성되어 있어야 합니다.

절차

  1. 다음 콘텐츠를 사용하여 YAML 파일을 생성하고 저장합니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ProxyConfigPromote
    metadata:
      name: proxyconfigpromote-sample
    spec:
      productCRName: product1-sample

    APIcast 구성을 프로덕션 환경으로 승격하려면 선택적 필드 spec.productiontrue 로 설정합니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ProxyConfigPromote
    metadata:
      name: proxyconfigpromote-sample
    spec:
      productCRName: product1-sample
      production: true

    승격 후 ProxyConfigPromote 오브젝트 를 삭제하려면 선택적 필드 spec.deleteCRtrue 로 설정합니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ProxyConfigPromote
    metadata:
      name: proxyconfigpromote-sample
    spec:
      productCRName: product1-sample
      deleteCR: true
  2. 파일의 상태 조건을 확인하려면 다음 명령을 입력합니다.

    oc get proxyconfigpromote proxyconfigpromote-sample -o yaml
    1. satus가 Ready 임을 출력에 표시됩니다.

      apiVersion: capabilities.3scale.net/v1beta1
      kind: ProxyConfigPromote
      metadata:
        name: proxyconfigpromote-sample
      spec:
        productCRName: product1-sample
      status:
        conditions:
        - lastTransitionTime: "2022-10-28T11:35:19Z"
          status: "True"
          type: Ready
  3. 사용자 정의 리소스를 생성합니다.

    oc create -f proxyconfigpromote-sample.yaml
    • 주어진 예에서 출력은 다음과 같습니다.

      proxyconfigpromote.capabilities.3scale.net/proxyconfigpromote-sample created

8.6. 3scale OpenAPI 사용자 정의 리소스 배포

OpenAPI CR(사용자 정의 리소스)은 개발자 포털의 ActiveDocs에 사용할 수 있는 OCI(OpenAPI Specification) 문서를 가져오는 한 가지 방법입니다. OAS는 API에 대해 특정 프로그래밍 언어를 사용하는 것과 관련이 없는 표준입니다. 사람과 컴퓨터는 소스 코드 액세스, 문서 또는 네트워크 트래픽 검사 없이 API 제품의 기능을 보다 쉽게 이해할 수 있습니다.

사전 요구 사항

  • 3scale 2.11 On-Premises 인스턴스에 대한 관리자 권한이 있는 사용자 계정.
  • API를 정의하는 OAS 문서입니다.
  • OpenAPI CR이 테넌트에 연결되는 방법에 대한 이해.

8.6.1. 시크릿에서 OAS 문서를 가져오는 3scale OpenAPI 사용자 정의 리소스 배포

3scale 백엔드제품을 생성할 수 있도록 OpenAPI CR(사용자 정의 리소스)을 배포합니다.

참고

Operator는 시크릿의 콘텐츠만 읽습니다. Operator는 시크릿에서 필드 이름을 읽지 않습니다.

절차

  1. OAS 문서가 포함된 시크릿을 정의합니다. 예를 들어 다음 콘텐츠를 사용하여 myoasdoc1.yaml 을 생성할 수 있습니다.

    openapi: "3.0.2"
    info:
      title: "some title"
      description: "some description"
      version: "1.0.0"
    paths:
      /pet:
        get:
          operationId: "getPet"
          responses:
            405:
              description: "invalid input"
  2. 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create secret generic myoasdoc1 --from-file myoasdoc1.yaml
    
    secret/myoasdoc1 created
  3. OpenAPI CR을 정의합니다. OAS 문서가 포함된 보안에 대한 참조를 지정해야 합니다. 예를 들어 myopenapicr1.yaml 파일을 생성할 수 있습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: OpenAPI
    metadata:
      name: myopenapicr1
    spec:
      openapiRef:
        secretRef:
          name: myoasdoc1
  4. 방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create -f myopenapicr1.yaml

    주어진 예에서 출력은 다음과 같습니다.

    openapi.capabilities.3scale.net/myopenapicr1 created

8.6.2. 3scale OpenAPI 사용자 정의 리소스 정의의 기능

CRD(OpenAPI 사용자 정의 리소스 정의) 배포 기능에 대한 정보는 3scale 제품, 백엔드 및 개발자 포털에 대한 ActiveDoc을 구성하는 데 도움이 됩니다.

  • OAS 문서는 다음에서 읽을 수 있습니다.

    • Kubernetes 시크릿
    • http 및 https 형식의 URL
  • OAS 문서에서 info.title 설정은 215자를 초과해서는 안 됩니다. Operator는 이 설정을 사용하여 길이 제한이 있는 OpenShift 오브젝트 이름을 생성합니다.
  • 서버 목록의 첫 번째 서버[0].url 요소만 개인 URL로 구문 분석됩니다. OAS(OpenAPI Specification)는 servers[0].url 요소의 basePath 구성 요소를 사용합니다.
  • OpenAPI CRD는 단일 최상위 보안 요구 사항을 지원하지만 운영 수준 보안은 지원하지 않습니다.
  • OpenAPI CRD는 apiKey 보안 스키마를 지원합니다.

8.6.3. OpenAPI 사용자 정의 리소스 정의 시 규칙 가져오기

가져오기 규칙은 3scale 배포에 대해 OpenAPI 문서를 설정할 때 OCI(OpenAPI Specification)가 3scale로 작동하는 방식을 지정합니다.

제품 이름

기본 제품 시스템 이름은 OpenAPI 문서의 info.title 필드에서 가져온 것입니다. OpenAPI 문서의 제품 이름을 재정의하려면 OpenAPI CR(사용자 정의 리소스)에서 spec.productSystemName 필드를 지정합니다.

프라이빗 기본 URL

개인 기본 URL은 OpenAPI CR servers[0].url 필드에서 읽습니다. OpenAPI CR의 spec.privateBaseURL 필드를 사용하여 이 값을 덮어쓸 수 있습니다.

3scale 방법

가져온 OpenAPI 문서에 정의된 각 작업은 제품 수준에서 하나의 3scale 메서드로 변환됩니다. 메서드 이름은 작업 오브젝트의 operationId 필드에서 읽습니다.

3scale 매핑 규칙

가져온 OpenAPI 문서에 정의된 각 작업은 제품 수준에서 하나의 3scale 매핑 규칙으로 변환됩니다. 이전 버전에서는 기존 매핑 규칙이 OpenAPI CR로 가져온 규칙으로 교체되었습니다.

OpenAPI 문서에서 paths 오브젝트는 동사 및 패턴 속성에 대한 매핑 규칙을 제공합니다. 3scale 방법은 operationsId 에 따라 연결됩니다.

delta 값은 1 로 하드 코딩됩니다.

기본적으로 Strict 일치 정책이 구성됩니다. 일치하는 정책은 OpenAPI CRD의 spec.PrefixMatching 필드를 사용하여 Prefix matching 로 전환할 수 있습니다.

인증

하나의 최상위 보안 요구 사항만 지원됩니다. 작업 수준 보안 요구 사항은 지원되지 않습니다.

지원되는 보안 스키마는 apiKey 입니다.

apiKey 보안 스키마 유형:

  • 자격 증명 위치는 보안 스키마 오브젝트의 OpenAPI 문서에서 읽습니다.
  • 인증 사용자 키는 보안 스키마 오브젝트의 OpenAPI 문서 이름 필드에서 읽습니다.

다음은 apiKey 보안 요구 사항이 있는 OAS 3.0.2의 일부입니다.

openapi: "3.0.2"
security:
  - petstore_api_key: []
components:
  securitySchemes:
    petstore_api_key:
      type: apiKey
      name: api_key
      in: header

OpenAPI 문서에서 보안 요구 사항을 지정하지 않으면 다음이 적용됩니다.

  • 제품 인증은 apiKey 에 대해 구성됩니다.
  • 인증 정보 위치는 기본적으로 3scale 값 인 쿼리 매개변수(GET) 또는 본문 매개변수(GET/PUT/DELETE) 로 설정됩니다.
  • Auth 사용자 키의 기본값은 3scale 값 user_key 입니다.

3scale Authentication SecurityOpenAPI CRD의 spec.privateAPIHostHeaderspec.privateAPISecretToken 필드를 사용하여 설정할 수 있습니다.

ActiveDocs

3scale ActiveDoc이 생성되지 않습니다.

3scale 제품 정책 체인

3scale 정책 체인은 기본 1개 3scale 생성입니다.

3scale 배포 모드

기본적으로 구성된 3scale 배포 모드는 APIcast 3scale managed입니다. 그러나 spec.productionPublicBaseURL 또는 spec.stagingPublicBaseURL. 또는 두 필드가 OpenAPI CR에 있는 경우 제품의 배포 모드는 APIcast 자체 관리입니다.

사용자 정의 공용 기본 URL이 있는 OpenAPI CR의 예:

apiVersion: capabilities.3scale.net/v1beta1
kind: OpenAPI
metadata:
  name: openapi1
spec:
  openapiRef:
    url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml"
  productionPublicBaseURL: "https://production.my-gateway.example.com"
  stagingPublicBaseURL: "https://staging.my-gateway.example.com"

8.6.4. URL에서 OAS 문서를 가져오는 3scale OpenAPI 사용자 정의 리소스 배포

지정하는 URL에서 OAS 문서를 가져오는 OpenAPI 사용자 정의 리소스를 배포할 수 있습니다. 그런 다음 이 OAS 문서를 개발자 포털에서 API의 ActiveDocs 기반으로 사용할 수 있습니다.

사전 요구 사항

  • 동일한 네임스페이스에 있는 3scale 인스턴스에서 기본 테넌트에 연결되지 않는 OpenAPI 사용자 정의 리소스를 생성하는 경우 OpenAPI CR을 포함할 네임스페이스에는 OpenAPI CR이 연결되는 테넌트를 식별하는 보안이 포함되어 있습니다. 보안 이름은 다음 중 하나입니다.

    • threescale-provider-account
    • 사용자 정의

    이 시크릿에는 3scale 인스턴스의 URL과 해당 3scale 인스턴스의 테넌트 1개에 대한 액세스 자격 증명이 포함된 토큰이 포함됩니다.

절차

  1. OpenShift 계정에서 Operator > 설치된 운영자로 이동합니다.
  2. 3scale Operator를 클릭합니다.
  3. YAML 탭을 선택합니다.
  4. OpenAPI 사용자 정의 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: OpenAPI
    metadata:
      name: openapi1
    spec:
      openapiRef:
        url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml"
      providerAccountRef:
        name: mytenant
  5. 저장을 클릭합니다. 3scale Operator가 OpenAPI CR을 생성하는 데 몇 초가 걸립니다.

검증

  1. OpenShift에서 3scale 제품 개요 페이지에서 동기화 조건이 True 로 표시되는지 확인합니다.
  2. 3scale 계정으로 이동합니다.
  3. OAS 문서가 있는지 확인합니다. 위의 예제에서는 openapi1 이라는 새 OAS 문서를 볼 수 있습니다.

8.6.5. 추가 리소스

8.7. 3scale ActiveDoc 사용자 정의 리소스 배포

Red Hat 3scale API Management ActiveDocs는 OpenAPI 사양 을 준수하는 RESTful 웹 서비스를 정의하는 API 정의 문서를 기반으로 합니다. ActiveDoc CR(사용자 정의 리소스)은 개발자 포털에서 ActiveDocs에 사용할 수 있는 OCI(OpenAPI Specification) 문서를 가져오는 한 가지 방법입니다. OAS는 API에 대해 특정 프로그래밍 언어를 사용하는 것과 관련이 없는 표준입니다. 사람과 컴퓨터는 소스 코드 액세스, 문서 또는 네트워크 트래픽 검사 없이 API 제품의 기능을 보다 쉽게 이해할 수 있습니다.

사전 요구 사항

  • 3scale 2.11 On-Premises 인스턴스에 대한 관리자 권한이 있는 사용자 계정.
  • API를 정의하는 OAS 문서입니다.
  • ActiveDoc CR이 테넌트에 연결되는 방법에 대한 이해입니다.

8.7.1. 시크릿에서 OAS 문서를 가져오는 3scale ActiveDoc 사용자 정의 리소스 배포

3scale 백엔드제품 을 생성할 수 있도록 ActiveDoc CR(사용자 정의 리소스)을 배포합니다.

참고

Operator는 시크릿의 콘텐츠만 읽습니다. Operator는 시크릿에서 필드 이름을 읽지 않습니다. 예를 들어 데이터는 key: value 쌍으로 구성되는데, 여기서 value 는 파일의 내용을 나타내고 는 파일 이름입니다. 이 ActiveDoc CRD 컨텍스트에서 Operator는 파일 이름을 무시합니다. Operator는 파일의 콘텐츠만 읽습니다.

사전 요구 사항

절차

  1. 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create secret generic myoasdoc1 --from-file myoasdoc1.yaml
    
    secret/myoasdoc1 created
  2. ActiveDoc CR을 정의합니다. OAS 문서가 포함된 보안에 대한 참조를 지정해야 합니다. 예를 들어 myactivedoccr1.yaml 파일을 생성할 수 있습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ActiveDoc
    metadata:
      name: myactivedoccr1
    spec:
      name: "Operated ActiveDoc From secret"
      activeDocOpenAPIRef:
        secretRef:
          name: myoasdoc1
  3. 방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create -f myactivedoccr1.yaml

    주어진 예에서 출력은 다음과 같습니다.

    activedoc.capabilities.3scale.net/myactivedoccr1 created

검증

  1. Red Hat OCP(OpenShift Container Platform) 관리자 계정에 로그인합니다.
  2. Operator > 설치된 Operator로 이동합니다.
  3. Red Hat Integration - 3scale 을 클릭합니다.
  4. Active Doc 탭을 클릭합니다.
  5. OAS 문서가 있는지 확인합니다. 위의 예에서는 myactivedoccr1 이라는 새 OAS 문서가 표시됩니다.

8.7.2. 3scale ActiveDoc 사용자 정의 리소스 정의의 기능

ActiveDoc CRD(사용자 정의 리소스 정의)는 개발자를 위한 OpenAPI 문서 형식의 제품 문서에 관련이 있습니다. ActiveDoc CRD 배포 기능에 대한 지식이 있으면 개발자 포털에 ActiveDocs를 생성할 수 있습니다.

  • ActiveDoc CR은 다음 중 하나에서 OpenAPI 문서를 읽고 사용할 수 있습니다.

    • Secret
    • http 또는 https 형식의 URL
  • 필요한 경우 productSystemName 필드를 사용하여 ActiveDoc CR을 3scale 제품과 연결할 수 있습니다. 값은 3scale 제품 CR의 system_name 이어야 합니다.
  • 게시된 필드를 사용하여 3scale에서 ActiveDoc 문서를 게시하거나 숨길 수 있습니다. 기본적으로 이 값은 숨겨 진 상태로 설정됩니다.
  • skipSwaggerValidations 필드를 사용하여 OpenAPI 3.0 유효성 검사를 건너뛸 수 있습니다. 기본적으로 ActiveDoc CR의 유효성이 검증됩니다.

8.7.3. URL에서 OAS 문서를 가져오는 3scale ActiveDoc 사용자 정의 리소스 배포

지정하는 URL에서 OAS(OpenAPI Specification) 문서를 가져오는 ActiveDoc CR(사용자 정의 리소스)을 배포할 수 있습니다. 그런 다음 이 OAS 문서를 개발자 포털에서 API의 ActiveDocs 기반으로 사용할 수 있습니다.

절차

  1. OpenShift 계정에서 Operator > 설치된 운영자로 이동합니다.
  2. 3scale Operator를 클릭합니다.
  3. Active Doc 탭을 클릭합니다.
  4. ActiveDoc CR을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ActiveDoc
    metadata:
      name: myactivedoccr1
    spec:
      openapiRef:
        url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml"
      providerAccountRef:
        name: mytenant
  5. 선택 사항: ActiveDoc CR에서 self-managed APIcast의 경우 productionPublicBaseURLstagingPublicBaseURL 필드를 배포 URL로 설정합니다. 예를 들면 다음과 같습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: ActiveDoc
    metadata:
      name: myactivedoccr1
    spec:
      openapiRef:
        url: "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/examples/v3.0/petstore.yaml"
      productionPublicBaseURL: "https://production.my-gateway.example.com"
      stagingPublicBaseURL: "https://staging.my-gateway.example.com"
  6. 저장을 클릭합니다. 3scale Operator가 ActiveDoc CR을 생성하는 데 몇 초가 걸립니다.

검증

  1. Red Hat OCP(OpenShift Container Platform) 관리자 계정에 로그인합니다.
  2. Operator > 설치된 Operator로 이동합니다.
  3. Red Hat Integration 3scale 을 클릭합니다.
  4. Active Doc 탭을 클릭합니다.
  5. OAS 문서가 있는지 확인합니다. 위의 예에서는 myactivedoccr1 이라는 새 OAS 문서가 표시됩니다.

8.7.4. 추가 리소스

8.10. 3scale CustomPolicyDefinition 사용자 정의 리소스 배포

CustomPolicyDefinition CRD를 사용하여 관리 포털에서 3scale 제품에 사용자 지정 정책을 구성할 수 있습니다.

3scale Operator가 새 CustomPolicyDefinition CR을 발견하면 Operator는 3scale Operator가 사용자 정의 리소스 링크가 있는 테넌트를 식별하는 대로 CR을 소유하는 테넌트를 식별합니다.

사전 요구 사항

절차

  1. CustomPolicyDefinition 사용자 정의 리소스를 정의하고 예를 들어 my-apicast-custom-policy-definition.yaml 파일에 저장합니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: CustomPolicyDefinition
    metadata:
      name: custompolicydefinition-sample
    spec:
      version: "0.1"
      name: "APIcast Example Policy"
      schema:
        name: "APIcast Example Policy"
        version: "0.1"
        $schema: "http://apicast.io/policy-v1/schema#manifest#"
        summary: "This is just an example."
        configuration:
          type: object
          properties: {}
  2. CustomPolicyDefinition CR을 배포합니다.

    oc create -f my-apicast-custom-policy-definition.yaml

8.11. 테넌트 사용자 정의 리소스 배포

테넌트 사용자 지정 리소스를 Provider Account (프로바이더 계정)라고 합니다.

APIManager 사용자 지정 리소스를 생성하면 3scale을 배포할 운영자가 표시됩니다. 기본 3scale 설치에는 사용할 준비가 된 기본 테넌트가 포함되어 있습니다. 선택적으로 테넌트 사용자 지정 리소스 오브젝트를 생성하는 다른 테넌트를 생성할 수 있습니다.

사전 요구 사항

3scale 인스턴스에 새 테넌트를 배포하려면 준비 단계를 수행해야 합니다.

  1. 3scale 마스터 인증 정보 시크릿을 가져오거나 생성합니다. MASTER_SECRET

    3scale 마스터 계정 자격 증명(액세스 토큰)만 사용하여 테넌트 관리 작업을 수행할 수 있습니다. 다음과 같은 옵션이 있습니다.

    • 테넌트 리소스가 3scale과 동일한 네임스페이스에 생성되는 경우 마스터 계정 자격 증명이 이미 생성되어 system-seed 라고 합니다.
    • 테넌트 리소스가 3scale과 동일한 네임스페이스에 생성되지 않은 경우 마스터 계정 자격 증명을 사용하여 시크릿을 생성합니다. 이 명령에서 시크릿 이름은 선택 사항입니다. 시크릿 이름은 테넌트 사용자 정의 리소스에서 사용됩니다.

      oc create secret generic system-seed --from-literal=MASTER_ACCESS_TOKEN=<master access token>
  2. 새 테넌트의 admin 계정에 대한 암호를 저장할 새 시크릿을 생성합니다. ADMIN_SECRET. 이 명령에서 시크릿 이름은 선택 사항입니다. 시크릿 이름은 테넌트 사용자 지정 리소스에서 사용됩니다.

    oc create secret generic ecorp-admin-secret --from-literal=admin_password=<admin password value>
  3. 3scale 마스터 계정 호스트 이름을 가져옵니다. MASTER_HOSTNAME. 운영자를 사용하여 3scale을 배포할 때 마스터 계정에는 이러한 패턴이 있는 고정 URL이 있습니다(master .${wildcardDomain}).

    • 3scale이 설치된 네임스페이스에 액세스할 수 있는 경우 마스터 계정 호스트 이름을 가져옵니다.

      oc get routes --field-selector=spec.to.name==system-master -o jsonpath="{.items[].spec.host}"

절차

  1. 새 테넌트 사용자 지정 리소스를 배포합니다.

    apiVersion: capabilities.3scale.net/v1alpha1
    kind: Tenant
    metadata:
      name: ecorp-tenant
    spec:
      username: admin
      systemMasterUrl: https://<MASTER_HOSTNAME>
      email: admin@ecorp.com
      organizationName: ECorp
      masterCredentialsRef:
        name: <MASTER_SECRET>
      passwordCredentialsRef:
        name: <ADMIN_SECRET*>
      tenantSecretRef:
        name: tenant-secret
  2. 테넌트 리소스를 생성합니다.

    oc create -f <yaml-name>
    • 이 명령은 3scale 솔루션에 새 테넌트 생성을 트리거합니다.
    • 3scale 운영자는 새 시크릿을 생성하고 새 테넌트 자격 증명을 시크릿에 저장합니다.
    • 새 테넌트 provider_keyadmin 도메인 URL 이 시크릿에 저장됩니다.
    • 보안 위치는 tenant SecretRef 테넌트 사양 키를 사용하여 지정할 수 있습니다.

이는 생성된 보안 콘텐츠의 예입니다.

apiVersion: v1
kind: Secret
metadata:
  name: tenant-secret
type: Opaque
stringData:
  adminURL: https://my3scale-admin.example.com:443
  token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

테넌트 사용자 정의 리소스 및 가능한 값 필드에 대한 자세한 내용은 테넌트 CRD 참조를 참조하십시오.

8.12. 사용자 정의 리소스를 배포하여 3scale 개발자 관리

3scale 관리자는 CR(사용자 정의 리소스)을 사용하여 개별 개발자 사용자를 그룹화하는 개발자 계정을 배포할 수 있습니다. 이 계정을 사용하면 개발자 포털에서 3scale 관리 API에 대한 개발자 액세스를 구성하고 관리할 수 있습니다.

테넌트는 원하는 수의 개발자 계정과 정확히 하나의 테넌트에 대한 각 개발자 계정 링크를 포함할 수 있습니다. 개발자 계정은 원하는 수의 개발자 사용자와 정확히 하나의 개발자 계정에 대한 각 개발자 사용자 링크를 포함할 수 있습니다. 테넌트 계획은 생성할 수 있는 개발자 계정 수와 각 개발자 계정에 그룹화할 수 있는 개발자 사용자 수에 대한 제한을 결정합니다.

개발자 사용자 지정 리소스를 사용하려면 3scale 운영자가 3scale을 설치해야 합니다. 3scale Operator가 포함된 네임스페이스에만 개발자 사용자 지정 리소스를 배포할 수 있습니다. 개발자 사용자 지정 리소스 배포는 3scale 관리 포털 또는 3scale 내부 API를 사용하여 개발자를 관리하는 대안입니다.

중요

사용자 지정 리소스를 배포하여 개발자 계정 또는 개발자 사용자를 생성하는 경우 관리 포털 또는 내부 3scale API를 사용하여 해당 개발자 계정 또는 개발자 사용자를 업데이트할 수 없습니다. 개발자 CR을 배포한 후 관리 포털에 새 developer 계정 또는 새 developer 사용자를 해당 Accounts (계정) 페이지에 표시하므로 이 점을 인식하는 것이 중요합니다. 관리 포털 또는 API를 사용하여 CR을 사용하여 배포된 개발자 계정 또는 developer 사용자를 업데이트하려는 경우 3scale Operator는 변경 사항을 되돌리고 배포된 CR을 반영합니다. 이는 향후 릴리스에서 제거될 것으로 예상되는 제한 사항입니다. 그러나 관리 포털 또는 API를 사용하여 CR을 배포하여 생성한 개발자 계정 또는 developer 사용자를 삭제할 수 있습니다.

8.12.1. 사전 요구 사항

  • 3scale은 3scale 연산자에 의해 설치되었습니다.
  • 3scale에 대한 관리자 권한을 제공하는 Account Management API 범위에서 읽기 및 쓰기 권한이 있는 토큰에 액세스합니다.

8.12.2. DeveloperAccount 사용자 정의 리소스를 배포하여 3scale 개발자 계정 관리

3scale Operator를 사용하여 3scale을 설치할 때 DeveloperAccount 및 Developer User CR(사용자 정의 리소스)을 배포할 수 있습니다. 이러한 CR을 사용하면 개발자 포털에서 3scale-managed API에 액세스할 수 있도록 계정을 생성하고 업데이트할 수 있습니다.

DeveloperAccount CR을 배포하려면 admin 역할이 있는 사용자에 대해 DeveloperUser CR도 배포해야 합니다. 여기에서 제공되는 절차는 새 DeveloperAccount CR을 배포하는 것입니다. DeveloperAccount CR을 배포한 후 이를 업데이트하거나 삭제하는 절차는 다른 CR과 동일합니다.

3scale Operator가 포함된 네임스페이스에만 CR을 배포할 수 있습니다.

사전 요구 사항

  • 3scale Operator가 사용자 정의 리소스 링크가 있는 테넌트를 식별하는 방법에 대한 이해입니다.
  • 동일한 네임스페이스에 있는 3scale 인스턴스에서 기본 테넌트에 연결되지 않는 DeveloperAccount 사용자 정의 리소스를 생성하는 경우 DeveloperAccount CR이 포함된 네임스페이스에 DeveloperAccount CR이 연결되는 테넌트를 식별하는 시크릿이 포함됩니다. 보안 이름은 다음 중 하나입니다.

    • threescale-provider-account
    • 사용자 정의

    이 시크릿에는 3scale 인스턴스의 URL과 해당 3scale 인스턴스의 테넌트 1개에 대한 액세스 자격 증명이 포함된 토큰이 포함됩니다.

  • DeveloperAccount CR에 admin 역할이 있는 developer 사용자를 위한 사용자 이름, 암호 및 이메일 주소가 있습니다.

절차

  1. 3scale 운영자가 포함된 네임스페이스에서 새 개발자 계정 리소스에 admin 역할이 있는 developer 사용자의 사용자 이름과 암호가 포함된 시크릿을 정의하는 리소스 파일을 만들고 저장합니다. 예를 들어 myusername01.yaml 파일에는 다음이 포함될 수 있습니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: myusername01
    stringData:
      password: "123456"
  2. 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    oc create -f myusername01.yaml

    주어진 예에서 출력은 다음과 같습니다.

    secret/myusername01 created
  3. admin 역할이 있는 개발자의 DeveloperUser CR을 정의하는 .yaml 파일을 생성하고 저장합니다. 3scale Operator가 새 Developer Account CR을 배포하는 데 이 Developer User CR이 필요합니다. 예를 들어 developeruser01.yaml 파일에는 다음이 포함될 수 있습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: DeveloperUser
    metadata:
      name: developeruser01
    spec:
      username: myusername01
      email: myusername01@example.com
      passwordCredentialsRef:
        name: myusername01
      role: admin
      developerAccountRef:
        name: developeraccount1
      providerAccountRef:
        name: mytenant

    DeveloperUser CR에서 다음을 수행합니다.

    • developer 사용자 계정 이름, 사용자 이름 및 이메일은 DeveloperAccount 가 연결되는 테넌트에서 고유해야 합니다.
    • 여기에서 지정하는 개발자 계정 이름은 이 프로세스에서 배포하는 DeveloperAccount CR의 이름과 일치해야 합니다. 이 Developer User CR을 생성하기 전후에 DeveloperAccount CR을 생성할지 여부는 중요하지 않습니다.
    • DeveloperUser CR을 연결하는 테넌트는 지정된 DeveloperAccount CR 링크와 동일한 테넌트여야 합니다.
  4. 방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    oc create -f developeruser01.yaml

    주어진 예에서 출력은 다음과 같습니다.

    developeruser.capabilities.3scale.net/developeruser01 created
  5. DeveloperAccount CR을 정의하는 .yaml 파일을 생성하고 저장합니다. 이 .yaml 파일에서 spec.OrgName 필드는 조직 이름을 지정해야 합니다. 예를 들어 developeraccount01.yaml 파일에는 다음이 포함될 수 있습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: DeveloperAccount
    metadata:
      name: developeraccount01
    spec:
      orgName: Ecorp
      providerAccountRef:
        name: mytenant
  6. 방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    oc create -f developeraccount01.yaml

    주어진 예에서 출력은 다음과 같습니다.

    developeraccount.capabilities.3scale.net/developeraccount01 created

다음 단계

3scale Operator가 3scale 구성을 업데이트하여 새 사용자 지정 리소스를 반영하는 데 몇 초가 걸립니다. Operator가 사용자 정의 리소스 정보를 전파하는지 확인하려면 DeveloperAccount 사용자 정의 리소스 상태 필드를 확인하거나 oc wait 명령을 실행합니다. 예를 들면 다음과 같습니다.

oc wait --for=condition=Ready --timeout=30s developeraccount/developeraccount1

실패하는 경우 사용자 정의 리소스의 상태 필드는 오류가 일시적이거나 영구적일지 여부를 나타내며 문제를 해결하는 데 도움이 되는 오류 메시지를 제공합니다.

새 개발자 사용자에게 개발자 포털에 로그인할 수 있음을 알립니다. 또한 로그인 자격 증명을 전달해야 할 수도 있습니다.

다른 사용자 정의 리소스를 업데이트하거나 삭제하는 것과 동일한 방식으로 배포된 DeveloperAccount 사용자 정의 리소스를 업데이트하거나 삭제할 수 있습니다. 그러나 DeveloperAccount CR을 삭제해도 3scale Operator는 실제로 해당 CR을 삭제하지 않습니다. 삭제한 DeveloperAccount CR과 동일한 이름을 가진 새 DeveloperAccount CR을 배포하려는 경우 해당 이름의 DeveloperAccount CR이 이미 있다는 메시지가 표시됩니다. 새 DeveloperAccount CR에 다른 이름을 지정해야 합니다.

8.12.3. DeveloperUser 사용자 정의 리소스를 배포하여 3scale 개발자 사용자 관리

3scale 운영자를 사용하여 3scale을 설치하는 경우 개발자 포털에서 3scale-managed API에 대한 개발자 액세스를 관리하기 위해 DeveloperUser CR(사용자 정의 리소스)을 배포할 수 있습니다. 여기에서 제공되는 절차는 새 DeveloperUser CR을 배포하는 것입니다. DeveloperUser CR을 배포한 후 업데이트하거나 삭제하는 절차는 다른 CR과 동일합니다.

3scale Operator가 포함된 네임스페이스에만 CR을 배포할 수 있습니다.

사전 요구 사항

  • 3scale Operator가 사용자 정의 리소스 링크가 있는 테넌트를 식별하는 방법에 대한 이해입니다.
  • admin 역할이 있는 사용자에 대해 배포된 Developer User CR이 하나 이상 포함된 Developer Account 사용자 정의 리소스가 하나 이상 있습니다. 동일한 네임스페이스에 있는 3scale 인스턴스에서 기본 테넌트에 연결되지 않는 DeveloperUser 사용자 지정 리소스를 생성하는 경우 DeveloperUser CR이 포함된 네임스페이스에 DeveloperUser CR이 연결되는 테넌트를 식별하는 시크릿이 포함됩니다. 보안 이름은 다음 중 하나입니다.

    • threescale-provider-account
    • 사용자 정의

    이 시크릿에는 3scale 인스턴스의 URL과 해당 3scale 인스턴스의 테넌트 1개에 대한 액세스 자격 증명이 포함된 토큰이 포함됩니다.

  • DeveloperUser 사용자 지정 리소스의 경우 해당 개발자의 사용자 이름, 암호 및 이메일 주소가 있습니다.

절차

  1. 3scale 운영자가 포함된 네임스페이스에서 developer 사용자의 사용자 이름과 암호가 포함된 시크릿을 정의하는 리소스 파일을 만들고 저장합니다. 예를 들어 myusername02.yaml 파일에는 다음이 포함될 수 있습니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: myusername02
    stringData:
      password: "987654321"
  2. 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    oc create -f myusername02.yaml

    주어진 예에서 출력은 다음과 같습니다.

    secret/myusername02 created
  3. DeveloperUser CR을 정의하는 .yaml 파일을 생성하고 저장합니다. spec.role 필드에 admin 또는 member 를 지정합니다. 예를 들어 developeruser02.yaml 파일에는 다음이 포함될 수 있습니다.

    apiVersion: capabilities.3scale.net/v1beta1
    kind: DeveloperUser
    metadata:
      name: developeruser02
    spec:
      username: myusername02
      email: myusername02@example.com
      passwordCredentialsRef:
        name: myusername02
      role: member
      developerAccountRef:
        name: developeraccount1
      providerAccountRef:
        name: mytenant

    DeveloperUser CR에서 다음을 수행합니다.

    • developer 사용자 이름(metadata .name 필드에 지정됨), 사용자 이름 및 이메일은 포함된 DeveloperAccount 링크가 포함된 테넌트에서 고유해야 합니다.
    • developerAccountRef 필드는 배포된 DeveloperAccount CR의 이름을 지정해야 합니다.
    • DeveloperUser CR을 연결하는 테넌트는 지정된 DeveloperAccount CR 링크와 동일한 테넌트여야 합니다.
  4. 방금 정의한 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    oc create -f developefuser02.yaml

    주어진 예에서 출력은 다음과 같습니다.

    developeruser.capabilities.3scale.net/developeruser02 created

다음 단계

3scale Operator가 3scale 구성을 업데이트하여 새 사용자 지정 리소스를 반영하는 데 몇 초가 걸립니다. Operator가 사용자 정의 리소스 정보를 전파하는지 확인하려면 DeveloperUser 사용자 정의 리소스 상태 필드를 확인하거나 oc wait 명령을 실행합니다. 예를 들면 다음과 같습니다.

oc wait --for=condition=Ready --timeout=30s developeruser/developeruser02

실패하는 경우 사용자 정의 리소스의 상태 필드는 오류가 일시적이거나 영구적일지 여부를 나타내며 문제를 해결하는 데 도움이 되는 오류 메시지를 제공합니다.

새 개발자 사용자에게 개발자 포털에 로그인할 수 있음을 알립니다. 또한 로그인 자격 증명을 전달해야 할 수도 있습니다.

다른 사용자 정의 리소스를 업데이트하거나 삭제하는 것과 동일한 방식으로 배포된 DeveloperUser 사용자 정의 리소스를 업데이트하거나 삭제할 수 있습니다. 그러나 DeveloperUser CR을 삭제할 때 3scale Operator는 실제로 해당 CR을 삭제하지 않습니다. 삭제한 DeveloperUser CR과 동일한 계정 이름, 사용자 이름 또는 이메일을 가진 새 DeveloperUser CR을 배포하려는 경우 DeveloperUser CR이 이미 있다는 메시지가 표시됩니다. 새 DeveloperUser CR에 다른 개발자 계정 이름, 사용자 이름 또는 이메일을 지정해야 합니다.

추가 리소스

8.13. 3scale Operator 기능 제한

Red Hat 3scale API Management 2.11에서 3scale operator에는 다음과 같은 제한 사항이 있습니다.

  • 백엔드 CRD(사용자 정의 리소스 정의)는 조정되지 않습니다. 3scale의 기존 백엔드는 삭제되지 않습니다.
  • 제품 CRD 삭제는 조정되지 않습니다. 3scale의 기존 제품은 삭제되지 않습니다.
  • DeveloperAccount 또는 Developer User 사용자 정의 리소스 삭제는 조정되지 않습니다. Operator가 삭제 이벤트를 수신하는 동안 Operator는 이벤트에서 작동하지 않습니다. developer 계정 또는 developer 사용자는 그대로 유지됩니다. 삭제한 사용자 정의 리소스와 동일한 계정 이름, 사용자 이름 또는 이메일 주소를 사용하여 새 개발자 계정 또는 developer 사용자를 생성하려는 경우 계정이 이미 존재하는 오류가 표시됩니다. 계정을 생성하려면 다른 매개변수를 지정해야 합니다.
  • 제품 CRD는 관리 및 개발자 포털에 SSO(Single Sign-On) 인증을 지원하지 않습니다.
  • 제품 CRD는 OpenID Connect 인증을 지원하지 않습니다.
  • ActiveDocs CRD는 현재 사용할 수 없습니다.
  • 게이트웨이 정책 CRD는 현재 사용할 수 없습니다.
  • 제품 CRD 게이트웨이가 응답 사용자 정의 코드 및 오류를 지원하지 않음
  • 3scale Operator CRD OAS3이 포함된 3scale Operator CRD는 3scale 제품 구성의 신뢰 소스로 참조되지 않습니다.

8.14. 추가 리소스

자세한 내용은 다음 가이드를 참조하십시오.

9장. 3scale 백업 및 복원

이 섹션에서는 Red Hat 3scale API Management 설치의 관리자가 다음과 같은 데 필요한 정보를 제공합니다.

  • 영구 데이터의 백업 프로시저를 설정합니다.
  • 영구 데이터 백업에서 복원을 수행합니다.

하나 이상의 MySQL 데이터베이스와 관련된 문제가 있는 경우 3scale을 이전 운영 상태로 올바르게 복원할 수 있습니다.

9.1. 사전 요구 사항

  • 3scale 2.11 인스턴스. 3scale을 설치하는 방법에 대한 자세한 내용은 OpenShift에 3scale 설치를 참조하십시오.
  • jq: JSON 데이터의 추출 또는 변환을 위해.
  • OpenShift 클러스터에서 다음 역할 중 하나가 있는 OpenShift Container Platform 4.x 사용자 계정:

    • cluster-admin
    • admin
    • edit
참고

3scale 설치의 네임스페이스에서 로컬로 바인딩된 edit 클러스터 역할을 가진 사용자는 백업 및 복원 절차를 수행할 수 있습니다.

다음 섹션에는 데이터 세트를 사용하고, 영구 데이터에 대한 백업 프로시저를 설정하고 시스템 데이터베이스 및 OpenShift 시크릿 복원 등의 영구 볼륨에 대한 정보가 포함되어 있습니다.

9.2. 영구 볼륨 및 고려 사항

PV(영구 볼륨)

OpenShift의 3scale 배포에서는 다음을 수행합니다.

  • 기본 인프라에서 클러스터에 제공하는 영구 볼륨(PV)입니다.
  • 클러스터 외부 스토리지 서비스. 이는 동일한 데이터 센터 또는 다른 위치에 있을 수 있습니다.

고려 사항

영구 데이터의 백업 및 복원 절차는 사용 중인 스토리지 유형에 따라 다릅니다. 백업과 복원이 데이터 일관성을 유지하기 위해 데이터베이스에 대한 기본 PV를 백업하는 것만으로는 충분하지 않습니다. 예를 들어 부분적인 쓰기 및 부분 트랜잭션만 캡처하지 마십시오. 대신 데이터베이스의 백업 메커니즘을 사용합니다.

데이터의 일부 부분은 다양한 구성 요소 간에 동기화됩니다. 하나의 복사본은 데이터 집합 의 진실 소스로 간주됩니다. 다른 하나는 로컬에서 수정되지 않았지만 신뢰 소스와 동기화된 사본입니다. 이러한 경우, 신뢰의 소스가 복원되고 다른 구성 요소의 복사본이 동기화되어야 합니다.

9.3. 데이터 세트 사용

이 섹션에서는 다양한 영구 저장소, 목적, 사용되는 스토리지 유형 및 정보 소스인지 여부에 대한 다양한 데이터 세트에 대해 자세히 설명합니다.

3scale 배포의 전체 상태는 다음 DeploymentConfig 오브젝트 및 해당 PV에 저장됩니다.

이름설명

system-mysql

mysql 데이터베이스(mysql-storage)

system-storage

파일의 볼륨

backend-redis

Redis 데이터베이스(backend-redis-storage)

system-redis

redis 데이터베이스(system-redis-storage)

9.3.1. system-mysql정의

system-mysql 은 3scale 관리 콘솔에 사용자, 계정, API, 계획 등에 대한 정보를 저장하는 관계형 데이터베이스입니다.

서비스와 관련된 이 정보의 하위 집합이 백엔드 구성 요소와 동기화되고 backend-redis.system-mysql 에 저장됩니다. 이 정보의 신뢰 소스입니다.

9.3.2. system-storage정의

참고

여러 Pod를 업로드하고 읽는 정적 파일을 사용하여 시스템을 수평으로 확장할 수 있으므로 RWX(ReadWriteMany) PersistentVolume이 필요합니다.

system-storage시스템 구성 요소에서 읽고 쓸 파일을 저장합니다.

두 가지 범주로 분류됩니다.

  • 런타임 시 시스템 구성 요소에서 읽은 구성 파일
  • 개발자 포털을 생성하기 위해 정적 파일(예: HTML, CSS, JS )이 CMS 기능에 의해 시스템에 업로드됩니다.
참고

여러 Pod를 업로드하고 읽는 정적 파일을 사용하여 시스템을 수평으로 확장할 수 있으므로 RWX(ReadWriteMany) PersistentVolume 이 필요합니다.

9.3.3. backend-redis정의

backend-redis 에는 백엔드 구성 요소에서 사용하는 여러 데이터 세트가 포함되어 있습니다.

  • 사용법 : 백엔드에서 집계한 API 사용 정보입니다. 백엔드에서 속도 제한 결정과 시스템이 UI 또는 API 통해 분석 정보를 표시하는 사용됩니다.
  • config: 이는 내부 API를 통해 시스템에서 동기화되는 서비스, 속도 제한 등에 대한 구성 정보입니다. 이것은 이 정보의 사실 소스 가 아니지만 Systemsystem-mysql 은 입니다.
  • 대기열: 작업자 프로세스에서 실행할 백그라운드 작업의 대기열입니다. 이는 임시이며 처리되면 삭제됩니다.

9.3.4. system-redis정의

system-redis 에는 백그라운드에서 작업을 처리할 대기열이 포함되어 있습니다. 이는 임시이며 처리되면 삭제됩니다.

9.4. 시스템 데이터베이스 백업

다음 명령은 특정 순서가 없으므로 시스템 데이터베이스를 백업하고 보관하는 데 필요한 대로 사용할 수 있습니다.

9.4.1. system-mysql백업

MySQL 백업 명령 실행:

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.gz

9.4.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

9.4.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

9.4.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

9.4.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

9.4.6. OpenShift 보안 및 ConfigMap 백업

다음은 OpenShift 보안 및 ConfigMap에 대한 명령 목록입니다.

9.4.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

9.4.6.2. ConfigMaps

oc get configmaps system-environment -o json > system-environment.json
oc get configmaps apicast-environment -o json > apicast-environment.json

9.5. 시스템 데이터베이스 복원

중요

system-app 과 같은 Pod를 축소하거나 경로를 비활성화하여 레코드 생성을 방지합니다.

다음 절차에 따라 OpenShift 시크릿 및 시스템 데이터베이스를 복원하십시오.

9.5.1. 템플릿 기반 배포 복원

다음 단계를 사용하여 템플릿 기반 배포를 복원합니다.

절차

  1. 템플릿을 배포하기 전에 시크릿을 복원합니다.
oc apply -f system-smtp.json
  1. 템플릿 매개변수는 복사된 보안 및 구성 맵에서 읽습니다.

    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')

9.5.2. Operator 기반 배포 복원

다음 단계를 사용하여 운영자 기반 배포를 복원합니다.

절차

  1. OpenShift에 3scale Operator를 설치합니다.
  2. 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
  3. APIManager 리소스를 생성하기 전에 ConfigMap을 복원합니다.

    oc apply -f system-environment.json
    oc apply -f apicast-environment.json
  4. APIManager 사용자 지정 리소스를 사용하여 Operator를 사용하여 3scale 을 배포합니다.

9.5.3. system-mysql복원

절차

  1. MySQL 덤프를 system-mysql 포드에 복사합니다.

    oc cp ./system-mysql-backup.gz $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq '.items[0].metadata.name' -r):/var/lib/mysql
  2. 백업 파일 압축을 풉니다.

    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'
  3. MySQL DB 백업 파일을 복원합니다.

    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'

9.5.4. system-storage복원

Backup 파일을 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

9.5.5. zync-database복원

zync-database 를 복원하는 지침은 3scale에 적용된 배포 유형에 따라 다릅니다.

9.5.5.1. 템플릿 기반 배포

절차

  1. zync DeploymentConfig를 0 Pod로 축소합니다.

    oc scale dc zync --replicas=0
    oc scale dc zync-que --replicas=0
  2. Zync 데이터베이스 덤프를 zync-database Pod에 복사합니다.

    oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/
  3. 백업 파일 압축을 풉니다.

    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'
  4. 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'
  5. 아래 명령에서 ${ZYNC_REPLICAS} 를 복제본 수로 교체하여 원래 복제본 수로 복원합니다.

    oc scale dc zync --replicas=${ZYNC_REPLICAS}
    oc scale dc zync-que --replicas=${ZYNC_REPLICAS}

9.5.5.2. Operator 기반 배포

참고

Operator를 사용하여 3scale 배포( 특히 APIManager 사용자 정의 리소스 배포)의 지침에 따라 3scale 인스턴스를 재배포합니다.

절차

  1. ${DEPLOYMENT_NAME} 을 3scale 배포를 만들 때 정의한 이름으로 대체하여 복제본 수를 저장합니다.

    ZYNC_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o json | jq -r '.spec.zync'`
  2. zync DeploymentConfig를 0 Pod로 축소합니다.

    oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync": {"appSpec": {"replicas": 0}, "queSpec": {"replicas": 0}}}}'
  3. Zync 데이터베이스 덤프를 zync-database Pod에 복사합니다.

    oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/
  4. 백업 파일 압축을 풉니다.

    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'
  5. 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'
  6. 원래 복제본 수로 복원합니다.

    oc patch APIManager ${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync":'"${ZYNC_SPEC}"'}}'

9.5.5.3. backend-redis 및 system-redis 를 사용하여 3scale 옵션 복원

3scale을 복원하면 backend-redissystem-redis 를 복원합니다. 이러한 구성 요소에는 다음과 같은 기능이 있습니다.

*backend-redis: 애플리케이션 인증 및 속도 제한을 3scale로 지원하는 데이터베이스입니다. 또한 통계 저장소 및 임시 작업 저장소에 사용됩니다. *system-redis: 3scale의 백그라운드 작업에 대한 임시 스토리지를 제공하며 system-app 포드의 Ruby 프로세스의 메시지 버스로도 사용됩니다.

backend-redis 구성 요소

backend-redis 구성 요소에는 두 개의 데이터베이스, 데이터 가 있습니다. 기본 3scale 배포에서는 데이터 가 Redis 데이터베이스에 배포되지만 논리적 데이터베이스 인덱스 /0 및 / 1 에 분산됩니다. 데이터 데이터베이스를 복원하면 문제 없이 실행되지만 대기열 데이터베이스를 복원하면 중복된 작업이 발생할 수 있습니다.

작업 복제와 관련하여 3scale에서 백엔드 작업자는 백그라운드 작업을 밀리초 단위로 처리합니다. 마지막 데이터베이스 스냅샷 후 30초 후에 backend-redis 가 실패하고 복원하려고 하면 백엔드에 중복을 방지하기 위한 시스템이 없으므로 30초 동안 발생한 백그라운드 작업이 두 번 수행됩니다.

이 시나리오에서는 /0 데이터베이스 인덱스에 다른 곳에 저장되지 않는 데이터가 포함되어 있으므로 백업을 복원해야 합니다. /0 데이터베이스 인덱스를 복원하면 /1 데이터베이스 인덱스도 복원해야 합니다. 이는 다른 데이터베이스 없이는 저장할 수 없기 때문입니다. 다른 색인에서 하나의 데이터베이스가 아닌 다른 서버에서 데이터베이스를 분리하면 대기열 크기가 약 0이 되므로 백업을 복원하지 않고 몇 가지 백그라운드 작업이 손실되지 않는 것이 좋습니다. 따라서 3scale Hosted 설정에서 서로 다른 백업 및 복원 전략을 적용해야 합니다.

'system-redis'component

대부분의 3scale 시스템 백그라운드 작업은 멱등입니다. 즉, 동일한 요청이 몇 번 실행해도 동일한 결과를 반환합니다.

다음은 시스템의 백그라운드 작업에서 처리하는 이벤트의 예입니다.

  • 계획 시험, 만료 예정인 신용 카드, 활성화 알림, 계획 변경, 송장 상태 변경, PDF 보고서 등의 알림 작업.
  • 송장 및 청구와 같은 청구.
  • 복잡한 오브젝트 삭제.
  • 백엔드 동기화 작업.
  • 색인화 작업(예: sphinx 포함).
  • Sanitisation 작업(예: 송장 ID).
  • 감사 제거, 사용자 세션, 만료된 토큰, 로그 항목, 비활성 계정 일시 중단 등의 재작성 작업.
  • 트래픽 업데이트.
  • 프록시 구성 변경 모니터링 및 프록시 배포.
  • 배경 등록 작업
  • SSO(Single Sign-On) 동기화와 같은 지연된 작업, 경로 생성.

위의 백그라운드 작업 목록을 복원하는 경우 3scale의 시스템은 복원된 각 작업의 상태를 유지합니다. 복원이 완료된 후 시스템의 무결성을 확인하는 것이 중요합니다.

9.5.6. 백엔드와 시스템간의 정보 일관성 보장

백엔드를 복원한 후 시스템에서 Config 정보를 동기화 한 후 백엔드 의 정보가 신뢰의 소스System 과 일치하는지 확인해야 합니다.

9.5.6.1. backend-redis의 배포 구성 관리

이러한 단계는 backend-redis 의 인스턴스를 실행하기 위한 것입니다.

절차

  1. redis-config configmap을 편집합니다.

    oc edit configmap redis-config
  2. redis-config configmap에서 SAVE 명령을 주석 처리하십시오.

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap에서 appendonlyno 로 설정합니다.

    appendonly no
  4. backend-redis 를 재배포하여 새 구성을 로드합니다.

    oc rollout latest dc/backend-redis
  5. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-redis
  6. 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'
  7. 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'
  8. 백업 파일을 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
  9. backend-redis 를 재배포하여 백업을 로드합니다.

    oc rollout latest dc/backend-redis
  10. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-redis
  11. 추가 전용 파일을 만듭니다.

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
  12. 잠시 후에 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은 실행이 완료되었음을 나타냅니다.
  13. redis-config configmap을 편집합니다.

    oc edit configmap redis-config
  14. redis-config configmap의 SAVE 명령 주석을 제거하십시오.

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap에서 appendonlyyes 로 설정합니다.

    appendonly yes
  16. 기본 구성을 다시 로드하려면 backend-redis 를 다시 배포합니다.

    oc rollout latest dc/backend-redis
  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-redis

9.5.6.2. system-redis의 배포 구성 관리

이러한 단계는 system-redis 의 인스턴스를 실행하기 위한 것입니다.

절차

  1. redis-config configmap을 편집합니다.

    oc edit configmap redis-config
  2. redis-config configmap에서 SAVE 명령을 주석 처리하십시오.

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap에서 appendonlyno 로 설정합니다.

    appendonly no
  4. system-redis 를 재배포하여 새 구성을 로드합니다.

    oc rollout latest dc/system-redis
  5. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-redis
  6. 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'
  7. 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'
  8. Backup 파일을 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
  9. system-redis 를 재배포하여 백업을 로드합니다.

    oc rollout latest dc/system-redis
  10. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-redis
  11. 추가 전용 파일을 만듭니다.

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
  12. 잠시 후에 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은 실행이 완료되었음을 나타냅니다.
  13. redis-config configmap을 편집합니다.

    oc edit configmap redis-config
  14. redis-config configmap의 SAVE 명령 주석을 제거하십시오.

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap에서 appendonlyyes 로 설정합니다.

    appendonly yes
  16. system-redis 를 재배포하여 기본 구성을 다시 로드합니다.

    oc rollout latest dc/system-redis
  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-redis

9.5.7. backend-worker복원

최신 버전의 backend-worker 로 복원 :

oc rollout latest dc/backend-worker
  1. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-worker

9.5.8. system-app복원

system-app 의 최신 버전으로 복원 :

oc rollout latest dc/system-app
  1. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-app

9.5.9. system-sidekiq복원

  1. 최신 버전의 system-sidekiq 로 복원 :

    oc rollout latest dc/system-sidekiq
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-sidekiq

9.5.9.1. system-sphinx복원

  1. system-sphinx 의 최신 버전으로 복원 :

    oc rollout latest dc/system-sphinx
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-sphinx

9.5.9.2. Zync에서 관리하는 OpenShift 경로 복원

  1. 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'

10장. 사용자 정의 리소스를 사용한 3scale 백업 및 복원

이 장에서는 API Manager CR(사용자 정의 리소스)을 사용하여 배포된 Red Hat 3scale API Management 설치의 백업 및 복원 기능에 대해 자세히 설명합니다. 이 컨텍스트에서 CRD는 3scale Operator에서 제공합니다.

운영자 기능의 사용자 지정 리소스는 3scale 설치의 일부가 아닙니다. 따라서 사용자 정의 리소스는 3scale 설치 백업 및 복원 기능의 일부로 포함되지 않습니다.

중요

운영자를 사용하는 3scale 백업 및 복원은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

사전 요구 사항

  • 3scale 설치

다음 섹션에는 운영자를 사용하여 3scale 백업 및 복원을 수행하는 절차가 포함되어 있습니다.

10.1. Operator를 사용하여 3scale 백업

다음 섹션에서는 APIManager 사용자 지정 리소스에서 배포한 3scale 설치를 백업하는 데 필요한 정보와 절차를 제공합니다.

10.1.1. 백업 호환 시나리오

백업할 수 있는 3scale 설치 구성을 보려면 다음 섹션을 참조하십시오.

사전 요구 사항

  • 3scale 외부 데이터베이스를 백업합니다.

    • backend-redis
    • system-redis
    • system-database - MySQL 또는 PostgreSQL
  • PVC에 백업된 데이터를 포함할 충분한 공간을 프로비저닝합니다.
참고

APIManager 를 사용하여 배포되는 3scale 배포는 시스템의 FileStorage로 S3을 사용하여 백업할 수 없습니다.

10.1.2. 백업 시나리오 범위

다음 데이터베이스가 외부에서 구성되면 백업 기능을 사용할 수 있습니다.

  • 백엔드 Redis 데이터베이스
  • 시스템 Redis 데이터베이스
  • 시스템 데이터베이스 - MySQL 또는 PostgreSQL

10.1.3. 백업된 데이터

다음 표는 백업된 데이터 목록을 보여줍니다.

표 10.1. 백업되는 데이터

개체개체 유형 데이터

보안

  • system-smtp
  • system-seed
  • backend-internal-api
  • backend-listener
  • system-events-hook
  • system-app
  • system-recaptcha
  • zync
  • system-master-apicast
  • system-memcache
  • system-database
  • backend-redis
  • system-redis

ConfigMaps

  • system-environment
  • apicast-environment

APIManager

APIManager 사용자 정의 리소스 Kubernetes 오브젝트 정의 - json 스키마 정의

System FileStorage

System FileStorage의 위치가 PVC(PersistentVolumeClaim)에 있을 때

10.1.4. 3scale 백업

기존 APIManager 와 함께 배포된 3scale 설치를 백업하려면 다음 단계를 사용합니다.

절차

  1. 다음 Kubernetes 시크릿을 백업합니다.

    • backend-redis
    • system-redis
    • system-database
  2. 예와 같이 APIManager 오브젝트에서 관리하는 3scale 설치가 배포되는 동일한 네임스페이스에 APIManager Backup 사용자 정의 리소스를 생성합니다.

    예시 1

      apiVersion: apps.3scale.net/v1alpha1
      kind: APIManagerBackup
      metadata:
       name: example-apimanagerbackup-pvc
      spec:
        backupDestination:
          persistentVolumeClaim:
            resources:
              requests: "10Gi"

    예 2에서는 기존 PersistentVolume 이름을 제공합니다.

      apiVersion: apps.3scale.net/v1alpha1
      kind: APIManagerBackup
      metadata:
       name: example-apimanagerbackup-pvc
      spec:
        backupDestination:
          persistentVolumeClaim:
            # resources specification is required but ignored when providing a volumeName as per K8s PVCs requirements behavior
            resources:
              requests: "10Gi"
            volumeName: "my-preexisting-persistent-volume"

  3. APIManagerBackup 이 완료될 때까지 기다립니다. APIManagerBackup 의 콘텐츠를 가져오고 .status.completed 필드가 true로 설정될 때까지 대기하여 이를 확인합니다.

백업 내용은 백업 데이터에 자세히 설명되어 있습니다.

APIManagerBackup 의 status 섹션에 있는 다른 필드에는 구성된 백업 대상이 PVC일 때 데이터가 백업된 PVC 이름과 같은 백업 세부 정보가 표시됩니다.

향후 참조의 경우 status.backupPersistentVolumeClaimName 필드 값을 기록해 두십시오. APIManager Restore를 사용하여 APIManager 설치를 복원할 때 필요한 필드 중 하나는 PersistentVolumeClaimName 백업 소스입니다.

10.2. Operator를 사용하여 3scale 복원

다음 섹션에서는 이전에 APIManager 사용자 지정 리소스에서 배포하고 APIManager Backup 으로 백업한 3scale 설치를 복원하는 데 필요한 정보와 절차를 설명합니다.

10.2.1. 호환 시나리오 복원

복원할 수 있는 3scale 설치 구성을 보려면 다음 섹션을 참조하십시오.

사전 요구 사항

  • 3scale 외부 데이터베이스를 복원합니다.

    • backend-redis
    • system-redis
    • system-database - MySQL 또는 PostgreSQL

10.2.2. 시나리오 범위 복원

3scale 운영자의 복원 기능은 APIManagerBackup 사용자 정의 리소스에서 생성된 백업을 사용하여 사용할 수 있습니다.

백업할 수 있는 3scale 솔루션 시나리오 목록은 참조용 데이터 백업을 참조하십시오.

다음은 Operator의 복원 기능 범위에 있지 않습니다.

  • APIManagerBackup 사용자 정의 리소스를 사용하여 수행하지 않은 백업 데이터 복원.
  • 다양한 3scale 버전에서 APIManagerBackup 을 통해 제공되는 백업 데이터 복원.

10.2.3. 복원된 데이터

다음 표는 복원된 데이터 목록을 보여줍니다.

표 10.2. 복원된 데이터

개체개체 유형 데이터

보안

  • system-smtp
  • system-seed
  • backend-internal-api
  • system-events-hook
  • system-app
  • system-recaptcha
  • zync
  • system-master-apicast

ConfigMaps

  • system-environment
  • apicast-environment

APIManager

APIManager 사용자 정의 리소스 Kubernetes 오브젝트 정의 - json 스키마 정의

System FileStorage

System FileStorage의 위치가 PVC(PersistentVolumeClaim)에 있을 때

라우트

3scale 관련 OpenShift 경로(예: master 및 tenants)

10.2.4. 3scale 복원

APIManager Backup 사용자 정의 리소스를 사용하여 백업한 APIManager 를 사용하여 이전에 배포한 3scale 설치를 복원하려면 다음 단계를 따르십시오.

  1. 복원을 수행하는 프로젝트에 APIManager 사용자 지정 리소스 및 해당 3scale 설치가 포함되어 있지 않은지 확인합니다.
  2. 다음 Kubernetes 시크릿을 복원합니다.

    • backend-redis
    • system-redis
    • system-database
  3. APIManagerRestore 사용자 지정 리소스를 생성하고 이전에 APIManagerBackup 사용자 정의 리소스에서 백업한 설치의 백업 데이터를 지정합니다.

    자세한 내용은 백업 시나리오 범위를 참조하십시오.

    다음은 APIManagerRestore 사용자 정의 리소스의 예입니다.

      apiVersion: apps.3scale.net/v1alpha1
      kind: APIManagerRestore
      metadata:
        name: example-apimanagerrestore-pvc
      spec:
       restoreSource:
         persistentVolumeClaim:
           claimSource:
             claimName: example-apimanagerbackup-pvc # Name of the PVC produced as the backup result of an `APIManagerBackup`
             readOnly: true
  4. APIManagerRestore 가 완료될 때까지 기다립니다. APIManagerRestore 의 콘텐츠를 가져오고 .status.completed 필드가 true로 설정될 때까지 대기하여 이를 확인합니다.

    APIManager 사용자 지정 리소스가 생성되었으며 3scale 설치가 배포되어야 합니다.

11장. 3scale에 대한 reCAPTCHA 구성

이 문서에서는 스팸으로부터 보호하기 위해 Red Hat 3scale API Management 온프레미스에 대한 reCAPTCHA를 구성하는 방법을 설명합니다.

사전 요구 사항

  • 지원되는 OpenShift 버전에 설치 및 구성된 3scale On-Premises 인스턴스입니다.
  • reCAPTCHA v2에 대한 사이트 키 및 비밀 키를 가져옵니다. Register a new site web page를 참조하십시오.
  • 도메인 이름 검증을 사용하려면 허용 목록에 개발자 포털 도메인을 추가합니다.

3scale에 대한 reCAPTCHA를 구성하려면 다음 절차에 설명된 단계를 수행합니다.

11.1. 3scale에서 스팸 보호를 위한 reCAPTCHA 구성

스팸 보호를 위해 reCAPTCHA를 구성하려면 reCAPTCHA가 포함된 비밀 파일을 패치하는 두 가지 옵션이 있습니다. 이러한 옵션은 OCP(OpenShift Container Platform) 사용자 인터페이스 또는 CLI(명령줄 인터페이스)를 사용합니다.

절차

  1. OCP 4.x: 프로젝트 탐색: [your_project_name] > 워크로드 > 시크릿.
  2. system-recaptcha 시크릿 파일을 편집합니다.

    reCAPTHCA 서비스의 PRIVATE _KEY 및 PUBLIC_KEY 는 base64 형식 인코딩이어야 합니다. 키를 base64 인코딩으로 수동으로 변환합니다.

참고

CLI reCAPTCHA 옵션에는 base64 형식 인코딩이 필요하지 않습니다.

  • CLI: 다음 명령을 입력합니다.

    oc patch secret/system-recaptcha -p '{"stringData": {"PUBLIC_KEY": "public-key-from-service", "PRIVATE_KEY": "private-key-from-service"}}'

진행 후 단계

  • 위의 옵션 중 하나를 완료한 후 시스템 포드를 다시 배포합니다.
  • 3scale 관리 포털에서 서명되지 않은 사용자에 대해 스팸 보호를 설정합니다.

    1. 대상 > 개발자 포털 > 범위 보호로 이동합니다.
    2. 다음 옵션 중 하나를 선택합니다.

      • always - 로그인하지 않은 사용자에게 양식이 표시되면 reCAPTCHA가 항상 표시됩니다.
      • 의심스러운 전용 - reCAPTCHA는 자동 검사가 가능한 스패머를 탐지하는 경우에만 표시됩니다.
      • Never - 범위 보호 해제.

system-app 을 재배포하면 개발자 포털에서 스팸 보호를 사용하는 페이지가 reCAPTCHA I'm a robot checkbox가 표시됩니다.

저는 로봇이 아닙니다.

추가 리소스

  • 자세한 내용은 ReCAPTCHA 홈페이지를 참조하십시오.

12장. API 인프라 문제 해결

이 가이드는 API 인프라 문제의 원인을 확인하고 수정하는 데 도움이 됩니다.

API 인프라는 길고 복잡한 주제입니다. 그러나 최소한 다음 세 가지 이동 부분은 인프라에서 보유하게 됩니다.

  1. API 게이트웨이
  2. 3scale
  3. API
3scale 게이트웨이 흐름

이러한 세 가지 요소 중 하나에서 오류가 발생하면 API 소비자가 API에 액세스할 수 없습니다. 그러나 오류가 발생한 구성 요소를 찾는 것은 어렵습니다. 이 가이드에서는 문제를 식별하기 위한 몇 가지 팁을 제공합니다.

다음 섹션을 사용하여 발생할 수 있는 일반적인 문제를 식별하고 해결합니다.

12.1. 일반적인 통합 문제

3scale과의 통합과 관련하여 몇 가지 매우 일반적인 문제를 가리킬 수 있는 몇 가지 증거가 있습니다. 이는 API 프로젝트를 시작했는지, 인프라를 설정했는지 또는 이미 운영 중인 운영 환경에 따라 달라질 수 있습니다.

12.1.1. 통합 문제

다음 섹션에서는 3scale과의 통합 초기 단계에서 APIcast 오류 로그에 표시되는 몇 가지 일반적인 문제를 개략적으로 설명합니다. APIcast Hosted를 사용하기 시작할 때 자체 관리 APIcast를 실행하기 전에 라이브로 실행할 수 있습니다.

12.1.1.1. APIcast 호스팅

Service Integration(서비스 통합) 화면에서 먼저 API를 APIcast와 통합하려는 경우 페이지에 표시되거나 테스트 호출에서 반환하여 통합에 성공했는지 확인하는 몇 가지 오류가 발생할 수 있습니다.

  • 테스트 요청 실패: 실행 만료

    공용 인터넷에서 API에 연결할 수 있는지 확인합니다. APIcast Hosted는 프라이빗 API와 함께 사용할 수 없습니다. APIcast Hosted와 API를 공개적으로 통합할 수 있도록 하려면 APIcast Hosted와 API 간의 비공개 시크릿을 설정하여 API 게이트웨이에서 들어오는 모든 호출을 거부할 수 있습니다.

  • 허용되는 형식은 protocol://address(:port)입니다.

    API 개인 기본 URL 끝에 있는 경로를 제거합니다. "매핑 규칙" 패턴 또는 API 테스트 GET 요청의 시작 부분에 추가할 수 있습니다.

  • HTTP 코드 XXX로 테스트 요청이 실패했습니다

    • 405: 엔드포인트에서 GET 요청을 수락하는지 확인합니다. APIcast는 통합을 테스트하기 위해 GET 요청만 지원합니다.
    • 403: 인증 매개변수 누락: API에 이미 일부 인증이 있는 경우 APIcast에서 테스트 요청을 할 수 없습니다.
    • 403: 인증 실패: 3scale을 사용하여 만든 첫 번째 서비스가 아닌 경우 테스트 요청을 수행하기 위해 자격 증명을 사용하여 서비스 아래에 애플리케이션을 생성했는지 확인합니다. 통합 중인 첫 번째 서비스인 경우 가입 시 생성한 테스트 계정이나 애플리케이션을 삭제하지 않았는지 확인합니다.

12.1.1.2. APIcast 자체 관리

APIcast 자체 관리와의 통합을 성공적으로 테스트한 후 API 게이트웨이를 직접 호스팅할 수 있습니다. 다음은 자체 관리 게이트웨이를 처음 설치하고 이를 통해 API를 호출할 때 발생할 수 있는 몇 가지 오류입니다.

  • 업스트림 시간 초과(110: 연결 시간이 초과되었습니다) 업스트림에 연결하는 동안

    API 게이트웨이와 공용 인터넷 사이에 자체 관리 게이트웨이가 3scale에 도달하지 못하도록 하는 방화벽 또는 프록시가 없는지 확인합니다.

  • 서비스 목록을 가져오지 못했습니다: 잘못된 상태: 403 (제외됨)

      2018/06/04 08:04:49 [emerg] 14#14: [lua] configuration_loader.lua:134: init(): failed to load configuration,   exiting (code 1)
      2018/06/04 08:04:49 [warn] 22#22: *2 [lua] remote_v2.lua:163: call(): failed to get list of services:   invalid status: 403 (Forbidden) url: https://example-admin.3scale.net/admin/api/services.json , context:   ngx.timer
      ERROR: /opt/app-root/src/src/apicast/configuration_loader.lua:57: missing configuration

    THREESCALE_PORTAL_ENDOINT 값에서 사용한 액세스 토큰이 올바른지 그리고 Account Management API 범위가 있는지 확인합니다. curl 명령으로 curl -v "https://example-admin.3scale.net/admin/api/services.json?access_token=<YOUR_ACCESS_TOKEN>"을/를 확인합니다.

    JSON 본문을 사용하여 200개의 응답을 반환해야 합니다. 오류 상태 코드가 반환되면 응답 본문에서 자세한 내용을 확인합니다.

  • 호스트 apicast.example.com에 대한 서비스를 찾을 수 없습니다

      2018/06/04 11:06:15 [warn] 23#23: *495 [lua] find_service.lua:24: find_service(): service not found for host apicast.example.com, client: 172.17.0.1, server: _, request: "GET / HTTP/1.1", host: "apicast.example.com"

    이 오류는 Public Base URL이 제대로 구성되지 않았음을 나타냅니다. 구성된 Public Base URL이 자체 관리 APIcast 요청에 사용하는 것과 동일한지 확인해야 합니다. 올바른 공용 기본 URL을 구성한 후 다음을 수행합니다.

    • APIcast가 "production(프로덕션)"용으로 구성되었는지 확인합니다( THREESCALE_DEPLOYMENT_ENV 변수로 재정의하지 않은 경우 독립 실행형 APIcast의 기본 구성). 구성을 프로덕션으로 승격하는지 확인합니다.
    • APIcast를 재시작합니다. APICAST_CONFIGURATION_ CACHE 및 APICAST_CONFIGURATION_ LOADER 환경 변수를 사용하여 구성 자동 다시 로드를 구성하지 않은 경우.

다음은 잘못된 APIcast 자체 관리 통합을 가리킬 수 있는 다른 몇 가지 증상입니다.

  • 매핑 규칙이 일치하지 않습니다 / API 호출 수: API의 메서드와 실제 URL 엔드포인트 간의 매핑을 정의하는 방법에 따라 요청당 메서드가 일치하지 않거나 두 번 이상 증가하지 않는 경우도 있습니다. 이 문제를 해결하려면 3scale debug 헤더 를 사용하여 API에 대한 테스트 호출을 수행하십시오. 그러면 API 호출과 일치하는 모든 메서드 목록이 반환됩니다.
  • 인증 매개 변수를 찾을 수 없습니다: Service Integration(서비스 통합) 화면에 지정된 대로 매개 변수를 올바른 위치에 보내는지 확인합니다. 자격 증명을 헤더로 전송하지 않으면 다른 모든 HTTP 메서드에 대한 GET 요청 및 본문 매개 변수에 대한 쿼리 매개 변수로 자격 증명을 전송해야 합니다. 3scale 디버그 헤더를 사용하여 API 게이트웨이의 요청에서 읽은 자격 증명을 다시 확인합니다.

12.1.2. 프로덕션 문제

설정을 완전히 테스트하고 잠시 API와 함께 실행한 후 API 게이트웨이에 문제가 발생하는 것은 드뭅니다. 그러나 실시간 프로덕션 환경에서 발생할 수 있는 몇 가지 문제는 다음과 같습니다.

12.1.2.1. 가용성 문제

가용성 문제는 일반적으로 nginx error.log의 업스트림 시간 초과 오류로 구분됩니다. 예:

upstream timed out (110: Connection timed out) while connecting to upstream, client: X.X.X.X, server: api.example.com, request: "GET /RESOURCE?CREDENTIALS HTTP/1.1", upstream: "http://Y.Y.Y.Y:80/RESOURCE?CREDENTIALS", host: "api.example.com"

간헐적으로 3scale 가용성 문제가 발생하는 경우 다음과 같은 이유가 있을 수 있습니다.

  • 더 이상 사용하지 않는 이전 3scale IP로 확인 중입니다.

    최신 버전의 API 게이트웨이 구성 파일은 매번 IP 확인을 강제 적용하는 변수로 3scale을 정의합니다. 빠른 수정을 위해 NGINX 인스턴스를 다시 로드합니다. 장기적인 수정을 위해 업스트림 블록에서 3scale 백엔드를 정의하지 않고 각 서버 블록 내에서 변수로 정의합니다. 예:

    server {
      # Enabling the Lua code cache is strongly encouraged for production use. Here it is enabled
      .
      .
      .
      set $threescale_backend "https://su1.3scale.net:443";

    이를 참조할 때 다음을 수행합니다.

    location = /threescale_authrep {
      internal;
      set $provider_key "YOUR_PROVIDER_KEY";
    
      proxy_pass $threescale_backend/transactions/authrep.xml?provider_key=$provider_key&service_id=$service_id&$usage&$credentials&log%5Bcode%5D=$arg_code&log%5Brequest%5D=$arg_req&log%5Bresponse%5D=$arg_resp;
    }
  • 화이트리스트에서 일부 3scale IP가 누락되었습니다. 다음은 3scale이 다음을 수행하는 현재 IP 목록입니다.

    • 75.101.142.93
    • 174.129.235.69
    • 184.73.197.122
    • 50.16.225.117
    • 54.83.62.94
    • 54.83.62.186
    • 54.83.63.187
    • 54.235.143.255

      위의 문제는 3scale 가용성이 인식되는 문제를 나타냅니다. 그러나 API가 AWS ELB 뒤에 있는 경우 API 게이트웨이에서 API 가용성과 유사한 문제가 발생할 수 있습니다. 이는 기본적으로 NGINX가 시작 시 DNS 확인을 수행한 다음 IP 주소를 캐시하기 때문입니다. 그러나 ELB는 정적 IP 주소를 확인하지 않으며 자주 변경될 수 있습니다. ELB가 다른 IP로 변경될 때마다 NGINX에서 연결할 수 없습니다.

      이에 대한 솔루션은 런타임 DNS 확인을 강제 적용하기 위한 위의 수정 사항과 유사합니다.

      1. http 섹션 상단에 이 행을 추가하여 Google DNS와 같은 특정 DNS 확인자를 설정합니다. 확인자 8.8.8.8 8.8.4.4;.
      2. 서버 섹션의 상단에서 API 기본 URL을 변수로 설정합니다. $api_base "http://api.example.com:80"를 설정합니다.
      3. 위치 / 섹션에서 proxy _pass 행을 찾아 proxy _ pass $api_base; 로 바꿉니다.

12.1.3. 배포 후 문제

새 엔드포인트 추가와 같은 API를 변경하는 경우 API 게이트웨이에 사용할 새 구성 파일 세트를 다운로드하기 전에 새 메서드 및 URL 매핑을 추가해야 합니다.

3scale에서 다운로드한 구성을 수정한 경우 가장 일반적인 문제는 Lua에서 코드 오류가 발생하여 다음과 같은 500 - 내부 서버 오류가 발생합니다.

curl -v -X GET "http://localhost/"
* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: localhost
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Server: openresty/1.5.12.1
< Date: Thu, 04 Feb 2016 10:22:25 GMT
< Content-Type: text/html
< Content-Length: 199
< Connection: close
<

<head><title>500 Internal Server Error</title></head>

<center><h1>500 Internal Server Error</h1></center>
<hr><center>openresty/1.5.12.1</center>


* Closing connection #0

다음과 같은 원인을 아는 nginx error.log를 볼 수 있습니다.

2016/02/04 11:22:25 [error] 8980#0: *1 lua entry thread aborted: runtime error: /home/pili/NGINX/troubleshooting/nginx.lua:66: bad argument #3 to '_newindex' (number expected, got nil)
stack traceback:
coroutine 0:
  [C]: in function '_newindex'
  /home/pili/NGINX/troubleshooting/nginx.lua:66: in function 'error_authorization_failed'
  /home/pili/NGINX/troubleshooting/nginx.lua:330: in function 'authrep'
  /home/pili/NGINX/troubleshooting/nginx.lua:283: in function 'authorize'
  /home/pili/NGINX/troubleshooting/nginx.lua:392: in function  while sending to client, client: 127.0.0.1, server: api-2445581381726.staging.apicast.io, request: "GET / HTTP/1.1", host: "localhost"

access.log에서 다음과 같이 표시됩니다.

127.0.0.1 - - [04/Feb/2016:11:22:25 +0100] "GET / HTTP/1.1" 500 199 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"

위의 섹션에서는 3scale 여행의 모든 단계에서 발생할 수 있는 가장 일반적인 잘 알려진 문제에 대한 개요를 제공합니다.

이러한 모든 항목이 확인되었으며 여전히 문제의 원인과 해결 방법을 찾을 수 없는 경우 API 요청 문제를 해결하는 방법에 대한 자세한 섹션을 진행해야 합니다. API에서 시작하고 실패 지점을 식별하기 위해 클라이언트로 돌아가십시오.

12.2. API 인프라 문제 처리

서버에 연결할 때 API 게이트웨이, 3scale 또는 API에 관계없이 오류가 발생하면 다음 문제 해결 단계가 호출의 첫 번째 포트여야 합니다.

12.2.1. 연결할 수 있습니까?

telnet을 사용하여 기본 TCP/IP 연결 telnet api.example.com 443을 확인합니다.

  • 성공
telnet echo-api.3scale.net 80
Trying 52.21.167.109...
Connected to tf-lb-i2t5pgt2cfdnbdfh2c6qqoartm-829217110.us-east-1.elb.amazonaws.com.
Escape character is '^]'.
Connection closed by foreign host.
  • 실패
telnet su1.3scale.net 443
Trying 174.129.235.69...
telnet: Unable to connect to remote host: Connection timed out

12.2.2. 서버 연결 문제

다른 네트워크 위치, 장치 및 지침에서 동일한 서버에 연결을 시도합니다. 예를 들어 클라이언트가 API에 연결할 수 없는 경우 API 게이트웨이와 같이 액세스해야 하는 시스템에서 API에 연결해 봅니다.

시도한 커넥션 중 하나라도 성공적으로 수행되면 실제 서버의 문제를 배제하고 문제 해결을 위해 네트워크에 집중할 수 있습니다. 문제가 발생할 가능성이 가장 높기 때문입니다.

12.2.3. DNS 문제입니까?

telnet apis.io 80 대신 호스트 이름(예: telnet 94.125.104.17 80 ) 대신 IP 주소를 사용하여 서버에 연결해 보십시오.

이렇게 하면 DNS에 문제가 없습니다.

예를 들어 3scale dig su1.3scale.net 의 경우 dig 를 사용하여 서버의 IP 주소를 가져오거나, 호스트가 확인할 수 있는 여러 개의 IP가 있다고 의심되는 경우 su1.3scale.net을 dig 로 분석할 수 있습니다.

NB: 일부 호스트는 'dig any'를 차단합니다.

12.2.4. SSL 문제입니까?

OpenSSL을 사용하여 다음을 테스트할 수 있습니다.

  • 쉘 프롬프트에서와 같은 호스트 또는 IP에 대한 보안 연결 openssl s_client -connect su1.3scale.net:443

    출력:

    CONNECTED(00000003)
    depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
    verify error:num=20:unable to get local issuer certificate
    ---
    Certificate chain
     0 s:/C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net
       i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
     1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
       i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIE8zCCA9ugAwIBAgIQcz2Y9JNxH7f2zpOT0DajUjANBgkqhkiG9w0BAQsFADBE
    ...
    TRUNCATED
    ...
    3FZigX+OpWLVRjYsr0kZzX+HCerYMwc=
    -----END CERTIFICATE-----
    subject=/C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net
    issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
    ---
    Acceptable client certificate CA names
    /C=ES/ST=Barcelona/L=Barcelona/O=3scale Networks, S.L./OU=IT/CN=*.3scale.net
    /C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
    Client Certificate Types: RSA sign, DSA sign, ECDSA sign
    Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1:RSA+MD5
    Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
    Peer signing digest: SHA512
    Server Temp Key: ECDH, P-256, 256 bits
    ---
    SSL handshake has read 3281 bytes and written 499 bytes
    ---
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES256-GCM-SHA384
        Session-ID: A85EFD61D3BFD6C27A979E95E66DA3EC8F2E7B3007C0166A9BCBDA5DCA5477B8
        Session-ID-ctx:
        Master-Key: F7E898F1D996B91D13090AE9D5624FF19DFE645D5DEEE2D595D1B6F79B1875CF935B3A4F6ECCA7A6D5EF852AE3D4108B
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        TLS session ticket lifetime hint: 300 (seconds)
        TLS session ticket:
        0000 - a8 8b 6c ac 9c 3c 60 78-2c 5c 8a de 22 88 06 15   ..l..<`x,\.."...
        0010 - eb be 26 6c e6 7b 43 cc-ae 9b c0 27 6c b7 d9 13   ..&l.{C....'l...
        0020 - 84 e4 0d d5 f1 ff 4c 08-7a 09 10 17 f3 00 45 2c   ......L.z.....E,
        0030 - 1b e7 47 0c de dc 32 eb-ca d7 e9 26 33 26 8b 8e   ..G...2....&3&..
        0040 - 0a 86 ee f0 a9 f7 ad 8a-f7 b8 7b bc 8c c2 77 7b   ..........{...w{
        0050 - ae b7 57 a8 40 1b 75 c8-25 4f eb df b0 2b f6 b7   ..W.@.u.%O...+..
        0060 - 8b 8e fc 93 e4 be d6 60-0f 0f 20 f1 0a f2 cf 46   .......`.. ....F
        0070 - b0 e6 a1 e5 31 73 c2 f5-d4 2f 57 d1 b0 8e 51 cc   ....1s.../W...Q.
        0080 - ff dd 6e 4f 35 e4 2c 12-6c a2 34 26 84 b3 0c 19   ..nO5.,.l.4&....
        0090 - 8a eb 80 e0 4d 45 f8 4a-75 8e a2 06 70 84 de 10   ....ME.Ju...p...
    
        Start Time: 1454932598
        Timeout   : 300 (sec)
        Verify return code: 20 (unable to get local issuer certificate)
    ---
  • SSLv3 지원 (3scale에서 지원 없음)

    openssl s_client -ssl3 -connect su.3scale.net:443

    출력 결과

CONNECTED(00000003)
140735196860496:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1456:SSL alert number 40
140735196860496:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:644:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1454932872
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

자세한 내용은 OpenSSL 도움말 페이지를 참조하십시오.

12.3. API 요청 문제 식별

API 요청의 문제를 식별하려면 다음 검사를 수행합니다.

12.3.1. API

API가 시작되어 요청에 응답하는지 확인하려면 API 게이트웨이를 통과하지 않음) API에 직접 동일한 요청을 수행합니다. API 게이트웨이를 통과하는 요청과 동일한 매개변수 및 헤더를 보내야 합니다. 오류가 발생한 정확한 요청이 확실하지 않은 경우 API 게이트웨이와 API 간의 트래픽을 캡처합니다.

호출이 성공하면 API에 대한 문제를 제외할 수 있습니다. 그렇지 않으면 API를 추가로 해결해야 합니다.

12.3.2. API 게이트웨이 > API

API 게이트웨이와 API 간의 네트워크 문제를 방지하려면 API 게이트웨이 서버와 동일한 호출을 수행합니다.

호출이 성공하면 API 게이트웨이 자체의 문제 해결으로 이동할 수 있습니다.

12.3.3. API 게이트웨이

API 게이트웨이가 올바르게 작동하는지 확인하는 여러 단계가 있습니다.

12.3.3.1. API 게이트웨이가 실행 중입니까?

게이트웨이가 실행 중인 시스템에 로그인합니다. 실패하면 게이트웨이 서버가 다운될 수 있습니다.

로그인한 후 NGINX 프로세스가 실행 중인지 확인합니다. 이를 위해 ps ax | grep nginx 또는 htop 을 실행합니다.

목록에 nginx 마스터 프로세스 및 nginx 작업자 프로세스가 표시되면 NGINX가 실행 중입니다.

12.3.3.2. 게이트웨이 로그에 오류가 있습니까?

다음은 게이트웨이 로그에 표시되는 일반적인 오류입니다(예: error.log).

  • API 게이트웨이가 API에 연결할 수 없습니다

    upstream timed out (110: Connection timed out) while connecting to upstream, client: X.X.X.X, server: api.example.com, request: "GET /RESOURCE?CREDENTIALS HTTP/1.1", upstream: "http://Y.Y.Y.Y:80/RESOURCE?CREDENTIALS", host: "api.example.com"
  • API 게이트웨이는 3scale에 연결할 수 없습니다.

    2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"

12.3.4. API 게이트웨이 > 3scale

API 게이트웨이가 올바르게 실행되고 있는지 확인한 후 다음 단계는 API 게이트웨이와 3scale 간 연결 문제를 해결하는 것입니다.

12.3.4.1. API 게이트웨이가 3scale에 도달할 수 있습니까?

NGINX를 API 게이트웨이로 사용하는 경우 게이트웨이가 3scale에 연결할 수 없을 때 nginx 오류 로그에 다음 메시지가 표시됩니다.

2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"

여기에서 업스트림 값을 확인합니다. 이 IP는 3scale 제품이 분석하는 IP 중 하나에 해당합니다. 이는 3scale에 도달하는 데 문제가 있음을 의미합니다. 역방향 DNS 조회를 수행하여 nslookup 을 호출하여 IP의 도메인을 확인할 수 있습니다.

예를 들어 API 게이트웨이가 3scale에 도달할 수 없으므로 3scale이 다운되었음을 의미하지 않습니다. 가장 일반적인 이유 중 하나는 API 게이트웨이가 3scale에 연결되지 못하도록 하는 방화벽 규칙입니다.

게이트웨이와 3scale 사이에 네트워크 문제가 있을 수 있으며 이로 인해 연결이 시간 초과될 수 있습니다. 이 경우 일반적인 연결 문제를 해결하여 문제가 있는 위치를 식별하는 단계를 거쳐야 합니다.

네트워킹 문제를 해결하려면 traceroute 또는 MTR을 사용하여 라우팅 및 패킷 전송을 확인합니다. 3scale 및 API 게이트웨이에 연결하고 출력을 비교할 수 있는 시스템에서 동일한 명령을 실행할 수도 있습니다.

또한 API 게이트웨이와 3scale 간에 전송되는 트래픽을 확인하려면 3scale 제품(su1.3scale.net)에 HTTP 끝점을 사용하여 일시적으로 전환하는 한 tcpdump를 사용할 수 있습니다.

12.3.4.2. API 게이트웨이가 3scale 주소를 올바르게 확인할 수 있습니까?

resolver 지시문이 nginx.conf에 추가되었는지 확인합니다.

예를 들어 nginx.conf에서 다음을 수행합니다.

http {
  lua_shared_dict api_keys 10m;
  server_names_hash_bucket_size 128;
  lua_package_path ";;$prefix/?.lua;";
  init_by_lua 'math.randomseed(ngx.time()) ; cjson = require("cjson")';

  resolver 8.8.8.8 8.8.4.4;

Google DNS(8.8.8.8 및 8.8.4.4)를 선호하는 DNS로 대체할 수 있습니다.

API 게이트웨이에서 DNS 확인을 확인하려면 지정된 확인자 IP를 사용하여 nslookup을 호출합니다.

nslookup su1.3scale.net 8.8.8.8
;; connection timed out; no servers could be reached

위 예에서는 Google DNS에 연결할 수 없는 경우 반환된 응답을 보여줍니다. 이 경우 확인자 IP를 업데이트해야 합니다. nginx error.log에도 다음 경고가 표시될 수 있습니다.

2016/05/09 14:15:15 [alert] 9391#0: send() failed (1: Operation not permitted) while resolving, resolver: 8.8.8.8:53

마지막으로, dig any su1.3scale.net 을 실행하여 현재 3scale 서비스 관리 API에 대한 IP 주소를 확인합니다. 이는 3scale에서 사용할 수 있는 전체 IP 주소 범위가 아닙니다. 용량상의 이유로 일부 객체가 인/아웃될 수 있습니다. 향후 3scale 서비스에 대한 도메인 이름을 추가할 수도 있습니다. 이 경우 항상 통합 중에 제공된 특정 주소에 대해 테스트해야 합니다(해당하는 경우).

12.3.4.3. API 게이트웨이가 3scale을 올바르게 호출합니까?

문제 해결을 위해 API 게이트웨이가 3scale에 수행하는 요청을 확인하려면 nginx.conf의 3scale authrep 위치(API Key 및 App\_id 인증 모드의 경우/threescale_authrep )에만 다음 스니펫을 추가할 수 있습니다.

body_filter_by_lua_block{
  if ngx.req.get_headers()["X-3scale-debug"] == ngx.var.provider_key then
    local resp = ""
    ngx.ctx.buffered = (ngx.ctx.buffered or "") .. string.sub(ngx.arg[1], 1, 1000)
    if ngx.arg[2] then
      resp = ngx.ctx.buffered
    end

    ngx.log(0, ngx.req.raw_header())
    ngx.log(0, resp)
  end
}

이 코드 조각은 X-3scale-debug 헤더 가 전송되면 nginx error.log에 다음과 같은 추가 로깅을 추가합니다(예: curl -v -H 'X-3scale-debug): YOUR_PROVIDER_KEY' -X GET "https://726e3b99.ngrok.com/api/contacts.json?access_token=7c6f24f5"

이렇게 하면 다음 로그 항목이 생성됩니다.

2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7: GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1
Host: 726e3b99.ngrok.io
User-Agent: curl/7.43.0
Accept: */*
X-Forwarded-Proto: https
X-Forwarded-For: 2.139.235.79

 while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"
2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8: <?xml version="1.0" encoding="UTF-8"?><error code="access_token_invalid">access_token "7c6f24f5" is invalid: expired or never defined</error> while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"

첫 번째 항목(2016/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:)은 3scale로 전송된 요청 헤더를 출력합니다. Host, User-Agent, accept, X-Forwarded-Proto 및 X-Forwarded-Forwarded.

두 번째 항목(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:)은 3scale의 응답을 출력합니다. 이 경우 <error code="access_token_invalid">access_token "7c6f24f is invalid: expired or never defined</error> 입니다.

둘 다 원래 요청(GET /api/contacts.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의 정확한 요청도 확인할 수 있습니다.

12.3.5. 3scale

12.3.5.1. 3scale이 오류를 반환합니까?

3scale을 사용할 수도 있지만 API로 호출되지 않도록 API 게이트웨이에 오류가 반환됩니다. 3scale에서 권한 부여 호출을 직접 시도하고 응답을 확인합니다. 오류가 발생하면 #troubleshooting-api-error-codes[Error code] 섹션을 확인하여 문제가 무엇인지 확인합니다.

12.3.5.2. 3scale 디버그 헤더 사용

X-3scale-debug 헤더를 사용하여 API를 호출하여 3scale 디버그 헤더를 활성화할 수도 있습니다. 예:

curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug: YOUR_SERVICE_TOKEN

그러면 API 응답과 함께 다음 헤더가 반환됩니다.

X-3scale-matched-rules: /, /api/contacts.json
< X-3scale-credentials: access_token=TOKEN_VALUE
< X-3scale-usage: usage[hits]=2
< X-3scale-hostname: HOSTNAME_VALUE

12.3.5.3. 통합 오류 확인

또한 관리 포털의 통합 오류를 확인하여 트래픽을 3scale으로 보고하는 문제를 확인할 수 있습니다. https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors 참조하십시오.

통합 오류의 이유 중 하나는 server 블록에서 활성화되지 않은 underscores_in_headers 지시문을 사용하여 헤더에 자격 증명을 보낼 수 있습니다.

12.3.6. 클라이언트 API 게이트웨이

12.3.6.1. 공용 인터넷에서 API 게이트웨이에 연결할 수 있습니까?

브라우저를 게이트웨이 서버의 IP 주소(또는 도메인 이름)로 전달해 보십시오. 실패하는 경우 관련 포트에서 방화벽을 열어야 합니다.

12.3.6.2. 클라이언트에서 API 게이트웨이에 연결할 수 있습니까?

가능한 경우 이전에 설명한 메서드(telnet, curl 등) 중 하나를 사용하여 클라이언트에서 API 게이트웨이에 연결을 시도합니다. 연결에 실패하면 이 둘 사이의 네트워크에 문제가 있습니다.

그렇지 않으면 클라이언트가 API에 대한 호출을 수행하는 문제 해결으로 이동해야 합니다.

12.3.7. 클라이언트

12.3.7.1. 다른 클라이언트를 사용하여 동일한 호출을 테스트합니다

요청이 예상 결과를 반환하지 않으면 다른 HTTP 클라이언트로 테스트합니다. 예를 들어 Java HTTP 클라이언트를 사용하여 API를 호출하고 cURL을 사용하여 잘못된 항목이 표시되는 경우.

클라이언트와 게이트웨이 간에 프록시를 통해 API를 호출하여 클라이언트가 보내는 정확한 매개변수와 헤더를 캡처할 수도 있습니다.

12.3.7.2. 클라이언트에서 보낸 트래픽 검사

Wireshark와 같은 도구를 사용하여 클라이언트가 수행하는 요청을 확인합니다. 이렇게 하면 클라이언트가 API에 대한 호출을 수행하는지 여부와 요청 세부 정보를 확인할 수 있습니다.

12.4. ActiveDocs 문제

ActiveDocs를 통과하면 명령줄에서 API를 호출할 때 이 작업을 호출하는 경우가 있습니다.

ActiveDocs 호출이 작동하도록 하려면 프록시를 통해 전송합니다. 이 프록시는 그렇지 않은 경우 API에서 문제를 일으킬 수 있는 특정 헤더를 추가합니다. 이 경우 다음 단계를 수행하십시오.

12.4.1. petstore.swagger.io 사용

Swagger는 최신 버전의 swagger-ui를 통해 Swagger 사양 및 API를 테스트하는 데 사용할 수 있는 petstore.swagger.io에 호스팅된 swagger-ui를 제공합니다. swagger-ui와 ActiveDocs가 같은 방식으로 실패하는 경우 ActiveDocs 또는 ActiveDocs 프록시에 문제가 발생하지 않고 문제 해결에 중점을 둘 수 있습니다. 또는 swagger-ui의 현재 버전과 관련하여 알려진 문제가 있는지 swagger-ui GitHub 리포지토리를 확인할 수 있습니다.

12.4.2. 방화벽이 ActiveDocs 프록시의 연결을 허용하는지 확인합니다.

API를 사용하는 클라이언트의 IP 주소를 허용 목록에 지정하지 않는 것이 좋습니다. ActiveDocs 프록시는 고가용성을 위해 유동 IP 주소를 사용하며 현재 이러한 IP에 대한 변경 사항을 알리는 메커니즘은 없습니다.

12.4.3. 잘못된 인증 정보를 사용하여 API 호출

ActiveDocs 프록시가 올바르게 작동하는지 확인하는 한 가지 방법은 잘못된 인증 정보를 사용하여 API를 호출하는 것입니다. 이렇게 하면 ActiveDocs 프록시 및 API 게이트웨이 둘 다에 문제가 있는지 확인하거나 배제하는 데 도움이 됩니다.

API 호출에서 403 코드를 다시 가져오거나 잘못된 자격 증명을 위해 게이트웨이에 구성된 코드에서 가져온 경우 호출이 게이트웨이에 도달하므로 API에 문제가 있습니다.

12.4.4. 호출 비교

ActiveDocs 외부와 ActiveDocs 외부에서 수행된 호출 간 헤더와 매개 변수의 차이점을 식별하려면 온프레미스 또는 Runscope와 같은 서비스를 통해 호출을 실행합니다. 이렇게 하면 HTTP 호출을 검사하고 비교한 후 API로 보낼 수 있습니다. 그러면 문제가 발생할 수 있는 요청에서 잠재적인 헤더 및/또는 매개 변수를 식별할 수 있습니다.

12.5. NGINX 로그인

이에 대한 포괄적인 가이드는 NGINX 로깅 및 모니터링 설명서를 참조하십시오.

12.5.1. 디버깅 로그 활성화

디버깅 로그 활성화에 대한 자세한 내용은 NGINX 디버깅 로그 설명서를 참조하십시오.

12.6. 3scale 오류 코드

3scale Service Management API 끝점에서 반환하는 오류 코드를 다시 확인하려면 다음 단계를 수행하여 3scale API 설명서 페이지를 참조하십시오.

  1. 관리 포털의 오른쪽 상단에 있는 물음표(?) 아이콘을 클릭합니다.
  2. 3scale API Docs 를 선택합니다.

다음은 3scale에서 반환한 HTTP 응답 코드와 반환되는 조건 목록입니다.

  • 400: 잘못된 요청. 이는 다음과 같은 이유로 발생할 수 있습니다.

    • 잘못된 인코딩
    • 페이로드가 너무 큽니다
    • 콘텐츠 유형이 올바르지 않습니다( POST 호출의 경우). Content-Type 헤더에 유효한 값은 application/x-www-form-urlencoded,multipart/form-data 또는 빈 헤더입니다.
  • 403:

    • 인증 정보가 유효하지 않습니다.
    • GET 요청을 위해 3scale에 본문 데이터 전송
  • 404: 애플리케이션, 지표 등 참조된 존재하지 않는 엔터티.
  • 409:

    • 사용 제한 초과
    • 애플리케이션이 활성화되어 있지 않습니다
    • 애플리케이션 키가 잘못되었거나 누락되어 있습니다 (app _id/app_key 인증 방법의 경우)
    • 참조가 허용되지 않거나 누락된 경우 (참조 필터가 활성화되어 필요한 경우)
  • 422: 필수 매개 변수 누락

이러한 오류 응답에는 대부분의 시스템에서 읽을 수 있는 오류 범주와 사람이 읽을 수 있는 설명이 있는 XML 본문이 포함됩니다.

표준 API 게이트웨이 구성을 사용하는 경우 3scale에서 제공하는 200과 다른 반환 코드가 있으면 다음 코드 중 하나를 사용하여 클라이언트에 응답할 수 있습니다.

  • 403
  • 404

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.