시작하기


Red Hat 3scale API Management 2.16

3scale API Management 설치 시작하기.

Red Hat Customer Content Services

초록

이 가이드에서는 3scale 작업을 시작하는 방법에 대한 정보를 제공합니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다.

개선 사항을 제안하려면 Jira 문제를 열고 제안된 변경 사항을 설명합니다. 귀하의 요청을 신속하게 처리할 수 있도록 가능한 한 자세한 정보를 제공하십시오.

사전 요구 사항

  • Red Hat 고객 포털 계정이 있어야 합니다. 이 계정을 사용하면 Red Hat Jira Software 인스턴스에 로그인할 수 있습니다. 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

프로세스

  1. 다음 링크를 클릭합니다. 문제 생성.
  2. 요약 텍스트 상자에 문제에 대한 간략한 설명을 입력합니다.
  3. 설명 텍스트 상자에 다음 정보를 입력합니다.

    • 문제를 발견한 페이지의 URL입니다.
    • 문제에 대한 자세한 설명입니다.
      다른 필드에 있는 정보는 기본값에 따라 그대로 둘 수 있습니다.
  4. 생성 을 클릭하여 Jira 문제를 문서 팀에 제출합니다.

피드백을 제공하기 위해 시간을 내어 주셔서 감사합니다.

1장. 3scale API Management의 첫 번째 단계

Red Hat 3scale API Management 기능을 사용한 첫 번째 단계에서는 고객용 및 내부 관점에서 API(애플리케이션 프로그래밍 인터페이스)를 통합하고 관리하는 방법을 배울 수 있습니다.

1.1. 3scale API Management API의 제품 및 백엔드

Red Hat 3scale API Management는 API를 두 개의 주요 그룹으로 구분합니다.

  • 백엔드

    제품에 번들된 내부 API입니다. 백엔드는 API 공급자에 내부 API 조직 구조를 3scale에 매핑할 수 있는 자유를 부여합니다.

  • 제품

    고객용 API입니다. 제품은 API 소비자를 위한 강력하고 단순화된 제품을 쉽게 생성할 수 있습니다.

제품에 다중 백엔드를 포함할 수 있으며 백엔드는 여러 제품에서 사용할 수 있습니다. 즉, 3scale에서 API를 통합하고 관리하려면 다음 두 가지를 모두 생성해야 합니다.

  • 적어도 API의 URL이 포함된 백엔드입니다. 재사용성을 용이하게 하기 위해 매핑 규칙, 방법 및 지표를 사용하여 백엔드를 선택적으로 구성할 수 있습니다.
  • 애플리케이션 계획을 정의하고 APIcast를 구성하는 제품입니다.

1.2. 3scale API Management 마법사를 사용하여 첫 번째 API 구성

3scale 마법사는 제품 및 백엔드 작업 시 초기 지원을 제공합니다.

중요

3scale 계정에 처음 로그인하는 경우에만 3scale 마법사를 실행합니다. 마법사를 실행하여 후속 3scale 구성 요소를 생성하면 기존 구성 요소를 덮어씁니다.

사전 요구 사항

  • 3scale 계정이 필요합니다.

프로세스

  1. 마법사를 실행합니다. 3scale 마법사를 다음 두 가지 방법으로 실행할 수 있습니다.

    • 3scale 계정에 처음 로그인하는 경우 다음과 같이 실행합니다.
    • 다음 URL 주소에서 your_admin_domain 을 교체하여 마법사를 실행합니다.

      https://<your_admin_domain>-admin.3scale.net/p/admin/onboarding/wizard/intro

      예를 들어 관리 도메인이 testing-area이면 다음에서 마법사를 사용할 수 있습니다.

      https://testing-area-admin.3scale.net/p/admin/onboarding/wizard/intro

  2. OK, how does 3scale work?를 클릭합니다.
  3. 소개 애니메이션을 참조하십시오. 완료되면 Got it! Let’s add my API를 클릭합니다.
  4. 백엔드를 생성합니다.

    1. 백엔드 이름을 지정합니다. 예: 인벤토리
    2. 백엔드의 기본 URL을 나타냅니다. 예: https://echo-api.3scale.net:443
    3. 백엔드 추가를 클릭합니다.
  5. 제품을 생성합니다.

    1. 제품 이름을 표시합니다. 예: Petstore
    2. 제품 추가를 클릭합니다.
  6. 백엔드를 제품에 연결하는 경로를 지정하고 제품에 백엔드 추가를 클릭합니다.

    • 기본값을 그대로 둘 수 있습니다. 경로: /
  7. GET 요청으로 테스트를 만들려면 요청 보내기를 클릭합니다.

    • GET 메서드를 지정할 수 있습니다.
  8. 이러한 단계를 수행하면 API Gateway에 대한 성공적인 요청이 확인이 표시됩니다. 다음 구성에 대한 자세한 내용은 Cool, what's next?를 클릭하십시오.

제안된 추가 구성을 살펴보면 3scale을 사용할 준비가 된 것입니다. Got it! Take me to my API on 3scale을 클릭하면 제품의 개요 페이지가 표시됩니다.

1.3. 테스트 호출을 수행하기 위한 초기 API 구성

초기 구성을 사용하면 API 트래픽이 기본 속도 제한 및 제어를 통해 3scale에 의해 보호되고 추적 및 모니터링됩니다. 3scale로 처음 작업하는 경우 마법사를 실행하여 첫 번째 API 구성 지원을 받을 수 있습니다.

1.4. 제품에 대한 백엔드 생성

백엔드는 제품에 번들로 제공되는 내부 API입니다.

사전 요구 사항

  • 3scale 계정이 필요합니다.

프로세스

  1. 대시보드로 이동합니다.
  2. API 섹션의 백엔드 카드에서 백엔드 생성을 클릭합니다.
  3. 다음 세부 정보를 제공합니다.

    • 이름

      백엔드 식별자입니다.

    • 시스템 이름

      내부 목적으로 사용되는 식별자입니다.

    • 설명

      백엔드에 대한 자세한 정보가 포함된 선택적 필드입니다.

    • 프라이빗 기본 URL

      프라이빗 API의 기본 URL 끝점입니다.

  4. 백엔드 생성을 클릭합니다.

API에 대한 백엔드 생성 단계를 수행하면 내부 API가 생성됩니다. 필요에 따라 더 많은 백엔드를 생성할 수 있습니다.

1.5. API 호출을 테스트하기 위한 새 제품 생성

3scale API 공급자로 이러한 공용 API를 통해 API 호출을 테스트할 제품을 생성합니다. 제품은 하나 이상의 백엔드를 패키지하는 고객용 API입니다.

다음 옵션 중 하나를 수행하여 새 제품을 생성할 수 있습니다.

  • 제품을 수동으로 정의합니다.
  • OpenShift에서 제품을 가져옵니다.

여기에서 수동 정의에 대한 자세한 내용을 확인할 수 있습니다. OpenShift에서 제품을 가져오려면 Service Discovery 를 참조하십시오.

사전 요구 사항

  • 3scale 계정이 필요합니다.

프로세스

  1. 대시보드로 이동합니다. API 섹션의 제품 생성에서 제품 만들기를 클릭합니다.
  2. 다음 세부 정보를 제공합니다.

    • 이름

      제품 식별자입니다.

    • 시스템 이름

      내부 목적으로 사용되는 식별자입니다. 제품 system_name은 프록시 끝점 및 도메인 이름을 생성하는 데 사용됩니다. 기본적으로 system_name은 다음과 같은 대체 패턴 중 하나로 사용할 수 있는 레이블의 일부입니다.

      • APIcast 스테이징의 경우

        %{system_name}-%{tenant_name}-apicast-staging

      • APIcast 프로덕션의 경우

        %{system_name}-%{tenant_name}-apicast-production

    • 자동 생성 URL 레이블이 63자를 초과하면 시스템은 다음과 같이 라벨을 줄입니다. < truncated_label>-<unique_hash>

      • <truncated_label>

        원래 URL의 처음 54 또는 55자입니다.

      • <unique_hash>

        고유한 SHA-1 해시의 처음 7 문자는 원래 레이블에서 계산됩니다.

        예를 들어, 잘라내기 전의 URL은 다음과 같습니다.

        https://my-very-long-system-name-also-very-long-tenant-name-apicast-staging.3scale.net

        잘라낸 후의 URL입니다.

        https://my-very-long-system-name-also-very-long-tenant-name-api-72588d2.3scale.net

    • 설명

      제품에 대한 자세한 정보가 포함된 선택적 필드입니다.

  3. 제품 생성을 클릭합니다.

이러한 단계를 수행한 후에는 공개 API를 나타내는 제품이 생성됩니다.

1.6. 제품에 백엔드 추가

이 절차가 끝나면 제품에 백엔드를 추가합니다. 필요한 대로 절차를 반복하여 더 많은 백엔드를 추가합니다.

사전 요구 사항

프로세스

  1. [ your_product_name] > Integration > Backends로 이동합니다.
  2. 백엔드 추가를 클릭합니다.
  3. 드롭다운 목록에서 다음 작업 중 하나를 수행합니다.

    • 기존 백엔드를 선택합니다.
    • 전체 목록을 보려면 모두 보기를 클릭합니다.

      • 새 백엔드를 생성해야 하는 경우 새 백엔드 만들기를 클릭하고 세부 정보를 완료합니다.
  4. 경로 텍스트 상자에 라우팅 경로를 지정합니다. 자세한 내용은 특정 제품의 백엔드 경로를 참조하십시오.
  5. 제품에 추가를 클릭합니다.
  6. [ your_product_name] > Integration > Configuration제품 탭에서 제품을 승격합니다.

이 단계를 수행한 후 제품에 하나의 백엔드가 생성됩니다. 이 절차를 반복하여 제품 또는 여러 제품에 백엔드를 추가할 수 있습니다.

1.7. 특정 제품의 백엔드 경로

제품에 백엔드를 추가할 때 백엔드가 지정된 제품과 통신하는 데 사용하는 경로를 정의합니다. 이 경로는 백엔드의 일부가 아닙니다.

제품에 백엔드 추가에 설명된 절차에서 APIcast는 4단계에 표시된 백엔드의 경로를 사용하는 API 게이트웨이입니다. APIcast는 요청된 끝점 경로의 접두사와 일치하는 지정된 경로를 사용하여 트래픽을 백엔드로 리디렉션합니다.

백엔드의 경로를 정의할 때:

  • /를 백엔드 중 하나의 경로로 나타낼 수 있습니다.
  • 경로는 제품 내에서 고유해야 합니다. 즉, 동일한 제품 내부에 동일한 경로가 있는 두 백엔드를 추가할 수 없습니다. 동일한 백엔드를 동일한 제품에 두 번 추가할 수 없습니다.
  • 다른 제품에서 동일한 백엔드에 동일한 경로를 제공할 수 있습니다.

백엔드 경로가 작동하는 방식은 다음과 같습니다.

  • 제품에 추가된 각 백엔드는 지정된 경로에 마운트됩니다.
  • 트래픽을 리디렉션하기 전에 제품에 대한 요청의 공개 URL에서 경로가 제거됩니다.

제품에 백엔드를 추가하려면 다음 구성을 고려하십시오.

  • 백엔드: 인벤토리
  • 리소스 경로: /list
  • 제품: Petstore
  • 백엔드 경로: /supplies

다음은 구성에서 사용하는 URL입니다.

  • 공개 URL: <public-api-domain>/supplies/list
  • 비공개 URL: <private-api-domain>/list

요청이 전송될 때의 작업 흐름입니다.

  1. 애플리케이션이 요청을 보냅니다.
  2. 요청이 공개 URL로 전송됩니다. <public-api-domain>/supplies/list
  3. 비공개 URL로 리디렉션하기 전에 백엔드 경로가 제거됩니다. <private-api-domain>/list
  4. 요청이 Inventory 백엔드로 리디렉션됩니다.

1.8. 매핑 규칙 정의

매핑 규칙은 API에 대한 액세스를 추적 및 제한하기 위한 지정된 메서드 및 메트릭과 끝점에 대한 호출을 연결합니다. 백엔드 및 제품 수준에서 매핑 규칙을 정의할 수 있습니다. 백엔드 수준에서 매핑 규칙을 정의할 때의 장점은 여러 제품에 백엔드를 추가할 수 있다는 점입니다. API의 요청에 따라 사용 정보를 수집하는 메트릭 또는 방법에 대한 자세한 내용은 제품 및 백엔드 수준에서 모두 3scale API Management API 사용에 대한 매핑 규칙을 적용하는 방법을 참조하십시오.

사전 요구 사항

프로세스

  1. 대시보드에서 매핑 규칙을 정의할 백엔드 를 클릭합니다.
  2. 탐색 패널에서 매핑 규칙을 클릭합니다.
  3. 매핑 규칙 생성 을 클릭합니다.
  4. 다음 설정을 지정합니다.

    • verb

      HTTP 요청 동사(GET,POST,DELETE 또는 PUT).

    • 패턴

      일치시킬 패턴입니다. 예: /hello.

    • 증가시킬 메트릭 또는 방법

      메트릭 또는 메서드 이름입니다.

    • 증가 기준

      지표 증가 번호입니다. 예를 들면 1 입니다.

    • 마지막은?

      요청이 Last? 로 표시된 규칙과 일치하는 경우 APIcast는 처리를 중지하고 나머지 매핑 규칙에서 일치하는 항목을 검색하지 않으면 메트릭 증가도 중지합니다.

    • 위치

      매핑 규칙을 정렬하는 매핑 규칙의 위치를 나타내는 번호입니다.

  5. 매핑 규칙 생성 을 클릭합니다.

다음 단계

이러한 단계를 수행한 후 매핑 규칙이 [Your_API_backend] > Mapping Rules백엔드에 추가됩니다. 매핑 규칙은 현재 백엔드를 사용하는 각 제품에도 사용할 수 있습니다. 제품 수준에서 매핑 규칙을 활성화하려면 [ your_product_name] > Integration > Configuration제품 탭에서 최신 구성을 승격합니다.

구성을 승격한 후 3scale은 제품 수준에서 백엔드 매핑 규칙을 활성화합니다. 매핑 규칙은 제품에 지정된 백엔드 경로를 따릅니다. 예를 들어 다음과 같은 구성이 있다고 가정합니다.

  • 백엔드의 매핑 규칙 패턴: /thousands
  • 경로와 함께 제품에 백엔드가 추가됨: /unit price

제품 수준의 매핑 규칙은 /unit price/thousands입니다.

1.9. 제품에 대한 3scale API MAnagement 애플리케이션 계획 생성

3scale 애플리케이션 계획은 API 제품을 사용하기 위한 제한, 가격 및 기능과 같은 규칙을 정의합니다. 자세한 내용은 애플리케이션 계획사용 세부 정보 캡처를 위한 방법 지정 및 메트릭 추가를 참조하십시오.

사전 요구 사항

프로세스

  1. [ your_product_name] > Applications > Application Plans 로 이동합니다.
  2. 애플리케이션 계획 생성을 클릭합니다.
  3. 애플리케이션 계획 생성 페이지에서 새 계획의 이름과 시스템 이름을 입력합니다. 시스템 이름은 3scale 설치에서 고유한 이름이어야 합니다.
  4. 애플리케이션 계획 생성을 클릭합니다.

1.10. 기본 계정에 API 호출을 테스트할 애플리케이션 생성

3scale 사용자로 기본 개발자 계정의 애플리케이션을 생성합니다. 애플리케이션은 애플리케이션 계획에 서브스크립션합니다. 이 서브스크립션의 결과 3scale은 API 제품을 호출하는 데 필요한 사용자 키를 제공합니다.

애플리케이션은 항상 애플리케이션 계획과 연결되어 있습니다. 애플리케이션은 개발자 계정 내에 저장됩니다. 기본 3scale 계획에서는 단일 애플리케이션만 허용됩니다. 엔터프라이즈 플랜에서는 계정당 여러 애플리케이션이 허용됩니다.

사전 요구 사항

프로세스

  1. Audience > Accounts > Listing으로 이동합니다.
  2. 기본 개발자 계정을 클릭합니다.
  3. 애플리케이션 탭을 클릭합니다.
  4. 애플리케이션 생성을 클릭합니다.
  5. 애플리케이션 생성 대화 상자에서 애플리케이션의 제품을 선택합니다.
  6. 애플리케이션 계획을 선택합니다.
  7. 애플리케이션 이름을 지정합니다.
  8. 설명 필드에 이 애플리케이션에 대한 정보를 입력합니다.
  9. 애플리케이션 생성을 클릭합니다.

Dashboard >inspector > Accounts > Applications > Listing 에서 새 애플리케이션을 볼 수 있습니다.

1.11. 백엔드 통합을 테스트하기 위해 제품에 요청 전송

3scale API 공급자는 제품에 추가된 첫 번째 매핑 규칙을 기반으로 백엔드 통합을 테스트하기 위해 명령줄 요청을 제품으로 보낼 수 있습니다.

테스트 요청을 보내기 전에 테스트하려는 백엔드가 포함된 APIcast 구성을 승격해야 합니다. 특정 APIcast 구성은 해당 매핑 규칙, 애플리케이션 및 애플리케이션 계획을 사용하여 제품에 추가한 백엔드로 구성됩니다.

3scale은 요청 호출에 지정된 경로에 따라 제품의 백엔드에 요청을 전달합니다. 제품의 각 백엔드에 대해 제품에 백엔드를 추가할 때 백엔드 경로를 구성했습니다. 즉, 백엔드마다 고유한 경로가 있습니다.

사전 요구 사항

프로세스

  1. 새 APIcast 구성을 스테이징으로 승격합니다.

    1. [ your_product_name] > Integration > Configuration 으로 이동합니다.
    2. APIcast 구성에서 Promote v.[n] to Staging APIcast를 클릭합니다.

      • v.[n]은 승격할 버전 번호를 나타냅니다.
      • 승격할 변경 사항이 없는 경우 Nothing to promote라는 텍스트가 있는 회색 버튼이 있습니다.
  2. Staging APIcast에서 Promote v.[n] to Production APIcast를 클릭하여 APIcast 구성을 프로덕션으로 승격합니다.

    • v.[n]은 승격할 버전 번호를 나타냅니다.
    • 승격할 변경 사항이 없는 경우 Nothing to promote라는 텍스트가 있는 회색 버튼이 표시됩니다.
  3. API 제품에 대한 요청을 테스트하려면 Example curl에 제공된 명령을 복사하여 터미널에서 테스트합니다.

    • curl 명령 예제는 제품의 첫 번째 매핑 규칙을 기반으로 합니다.
    • 명령을 실행한 후 테스트 중인 백엔드에서 결과가 포함된 HTML 응답이 표시됩니다.
    • 응답이 제공되지 않는 경우 제품의 catch-all 매핑 규칙을 삭제하고 새 APIcast 구성을 스테이징으로 승격한 다음 예제 curl 명령을 실행합니다.

다음 단계

제한 및 가격 규칙과 같은 메트릭 및 방법을 변경할 때 다양한 응답을 확인할 수 있습니다. 제품의 애플리케이션 계획 중 하나에 대해 제품에 대한 요청을 테스트할 때 방법 및 메트릭을 수정합니다. 자세한 내용은 메서드 및 메트릭 추가를 참조하십시오.

제품 구성을 수정하고 API를 호출하기 전에 업데이트된 구성을 스테이징 및 프로덕션 환경으로 승격해야 합니다. 스테이징 환경으로 승격할 보류 중인 변경 사항이 있는 경우 Integration 메뉴 항목 옆에 관리 포털에 느낌표가 표시됩니다.

2장. API 시작

이 장에서는 Red Hat 3scale API Management를 사용하여 API를 시작하는 몇 가지 주요 단계에 대해 알아봅니다. 이 가이드를 사용하기 위해 다음과 같은 내용을 가정합니다.

  • 3scale에는 백엔드API Backend라는 내부 API가 있습니다.
  • 3scale에는 제품Echo API 라는 고객용 API가 있습니다. 이는 개발자 포털을 통해 노출될 API입니다.

이 가이드에서는 API 제품을 시작하기 위해 다음 단계를 설명합니다.

  1. 제품을 보호합니다.
  2. 애플리케이션 계획을 사용하여 제품 액세스 정책을 구성합니다.
  3. 개발자 포털을 통해 개발자를 참여시킵니다.
  4. 프로덕션 환경으로 이동합니다.

2.1. 첫 번째 API를 시작하기 위한 경로

3scale 작업을 시작하려면 API 제품을 시작하고 게시하는 세 가지 경로 중 하나를 선택할 수 있습니다. API 제품은 일반적으로 공개되고 고객이 액세스하는 API입니다.

기간 가이드라인은 API 제품의 복잡성과 작업을 수행할 수 있는 리소스에 따라 다릅니다. 대부분의 시간을 API 제품을 조정하고 개발자 포털을 위한 콘텐츠를 준비하는 데 사용할 수 있습니다. 안정적인 제품 및 문서 콘텐츠가 이미 있는 경우 1주일 이내에 프로덕션 환경으로 마이그레이션할 수 있습니다.

다음은 첫 번째 API 제품을 게시하는 경로입니다.

프로토 타입

  • 목표: 일반에 노출되는 간단한 API 제품으로 3scale의 엔드 투 엔드 통합을 완료합니다.
  • 권장 사항: 이 경로를 사용하면 3scale의 엔드 투 엔드 기능에 대한 일반적인 개요를 얻을 수 있습니다. 기본 절차를 수행하기 전에 이 경로를 수행해야 합니다. 관리 포털에서 배포 마법사를 성공적으로 완료한 경우 이 경로를 건너뛰고 다음 경로로 이동할 수 있습니다.
  • 완료 시간: 1시간 미만.

Basic

  • 목표: API 제품을 프로덕션 환경에서 시작하기 위해 모든 구현 단계를 완료합니다.
  • 권장 사항: 프로덕션 환경에서 API 제품을 사용하고 시간이 제한된 경우 기본 경로는 대부분의 요구 사항을 다룹니다.
  • 완료 시간: 1주 미만.

고급 옵션

  • 목표: API 제품의 고급 제어 및 개발자 포털의 고급 사용자 지정과 같은 기본 경로를 완료한 후 선택 사항입니다.
  • 권장 사항: 보다 복잡한 요구 사항이 있거나 이미 기본 경로를 포함하는 경우 고급 옵션을 고려할 준비가 되어 있을 수 있습니다.
  • 완료 시간: 몇 주마다.

2.2. 프로토 타입 경로 절차

프로토타입 경로를 처음부터 끝까지 개별적으로 수행할 수 있습니다. 또는 필요에 따라 이 경로에서 몇 가지 단계를 수행하도록 선택할 수 있습니다. 각 경로는 독립적일 수 있지만 프로토타입,기본, 고급 경로가 순차적으로 빌드됩니다.

2.2.1. API 보안

다음 사례 중 하나를 가정하면 몇 분 내에 3scale 액세스 제어 계층의 프로토타입을 만들 수 있습니다.

  • 호스트형 3scale (SaaS)에서는 제품에 공개적으로 액세스할 수 있습니다.
  • 3scale 온-프레미스에서는 3scale 설치에서 제품에 연결할 수 있습니다.

Echo API는 공용 제품의 예입니다. 다음과 같은 기능이 있습니다.

  • 응답 본문에서 경로, 요청 매개변수, 헤더 등과 같은 요청에 대한 정보를 반환하는 간단한 API입니다.
  • 다음 URL에서 액세스할 수 있습니다. https://echo-api.3scale.net
  • 3scale을 처음 활성화하면 기존 API마다 제품이 생성됩니다. 처음으로 제품과 API 백엔드 간에 일대일 관계가 있습니다. 즉, API 백엔드가 포함된 제품인 Echo API가 표시됩니다.

Echo API 제품을 보호하려면 다음 단계를 따르십시오.

  1. 제품에 연결할 수 있는지 확인합니다. 예: https://echo-api.3scale.net/v1/fast/track

    • 보안 계층을 배치한 후에는 백엔드 호스트에 대한 액세스를 숨기거나 제한할 수 있습니다.
  2. [ your_product_name] > Integration > Configuration 으로 이동합니다.
  3. [ your_product_name] 의 경우 프라이빗 엔드포인트가 기본 API Backend에 설정되어 있는지 확인합니다. 예: https://echo-api.3scale.net:443
  4. 스테이징으로 승격하려면 버튼을 클릭합니다.
  5. 기본 인증 정보로 user_key가 포함된 cURL 문을 복사하여 명령줄에서 호출합니다.

    curl "https://api-2445581407825.staging.apicast.io:443/v1/fast/track?user_key=287d64924e6120d215b1000ac07c063b"
    Copy to Clipboard Toggle word wrap

    다른 호출을 할 수 있습니다. 예를 들어 동일한 user_key를 추가하여 다른 엔드포인트에 대한 호출을 수행합니다.

    참고

    개발자 계정 중 하나에 있는 애플리케이션 세부 정보 페이지에서 API 제품 키를 가져올 수 있습니다.

    이제 3scale 액세스 제어 계층에서는 백엔드 API에 대해 인증된 호출만 허용합니다.

2.2.2. 애플리케이션 계획을 사용하여 API 액세스 정책 구성

API 보안 아래의 단계를 수행하면 API를 통해 인증된 호출만 허용됩니다. 이 섹션에서는 속도 제한을 구분하기 위해 정책을 적용합니다.

3scale에서 애플리케이션은 제품에 액세스할 수 있는 인증 정보를 정의합니다. 애플리케이션은 항상 액세스 정책을 결정하는 하나의 애플리케이션 계획과 연결되어 있습니다. 애플리케이션은 개발자 계정 내에 저장됩니다. 기본 3scale 계획에서는 단일 애플리케이션만 허용되지만, 상위 계획에서는 계정당 여러 애플리케이션이 허용됩니다.

이 예제에서는 다음 단계와 함께 이전 섹션에서 사용된 Echo API 제품에 정책을 추가합니다.

  1. [ your_product_name] > Applications > Application Plans 로 이동합니다.
  2. 애플리케이션 계획 섹션에서 기본 애플리케이션 계획으로 이동하여 3scale에 설치하거나 등록한 후 샘플 데이터에 의해 생성된 플랜 중 하나를 편집합니다.
  3. Metrics, Methods, Limits & pricing Rules 에서 hits 행의 limits를 선택하여 시간당 3번의 새 사용량 제한을 만듭니다.
  4. [Your_product_name] > Applications > Listing으로 이동하여 샘플 애플리케이션 중 하나를 찾으십시오. 애플리케이션이 기본 계획으로 설정되어 있는지 확인합니다. 그렇지 않은 경우 애플리케이션 세부 정보 페이지에서 계획을 변경합니다.
  5. 이 애플리케이션의 인증 정보를 사용하여 위의 샘플 호출을 적어도 세 번 반복합니다.

이제 3scale Basic 플랜에서 모든 애플리케이션에 대해 보다 제한적인 액세스 정책을 성공적으로 정의했습니다.

2.2.3. 개발자 포털을 사용하여 개발자 연결

Prototype 경로의 경우 문서 콘텐츠를 생성할 필요가 없습니다. 일반적으로 워크플로가 요구 사항을 충족하는지 확인하는 것으로 충분합니다.

이 제품은 개발 및 테스트이지만 다음 단계를 통해 전체 셀프 서비스 워크플로우를 비활성화할 수 있습니다.

  1. 관리 포털에서 Audience 공간으로 이동하여Developer Portal 메뉴에서 Visit Portal 링크를 클릭합니다.
  2. 테스트 등록 및 모든 단계를 수행합니다.
  3. 일반적으로 셀프 서비스는 기본적으로 활성화되어 있습니다. 이를 변경하려면 Audience > Accounts > Usage Rules로 이동하여 account approval required 확인란을 선택합니다.
  4. 테스트 등록 단계를 반복하고 사용자가 로그인하기 전에 관리 포털에서 계정을 승인해야 합니다.

이제 개발자 포털의 워크플로를 사용자 지정할 수 있습니다.

2.3. 기본 경로 절차

기본 경로를 처음부터 끝까지 개별적으로 수행할 수 있습니다. 또는 필요에 따라 이 경로에서 몇 가지 단계를 수행하도록 선택할 수 있습니다. 각 경로는 독립적일 수 있지만 프로토타입,기본, 고급 경로가 순차적으로 빌드됩니다.

2.3.1. API 보안

전체 프로덕션 구현을 위해서는 제품을 구조화하고 3scale과의 통합을 구현하는 방법에 대한 기본적인 결정을 해야 합니다.

제품 트래픽에 대한 여러 인증 모드를 선택할 수 있습니다. 사용 가능한 옵션에 대한 가이드를 참조하고 설정을 구성합니다.

중요

인증을 설정한 후에는 기존 인증 정보가 무효화될 수 있으므로 인증 모드를 전환해서는 안 됩니다.

추가 리소스

호스팅된 APIcast

  1. 처음으로 관리 포털에 로그인한 후 온보딩 마법사를 따릅니다.
  2. 프로덕션에 적합한 버전에 도달할 때까지 액세스 정책 거부와 같은 제품 구성을 계속합니다.
  3. APIcast 구성을 프로덕션 게이트웨이로 승격합니다.

자체 관리 APIcast

  1. OpenShift 에서 Operator를 사용하여 APIcast 게이트웨이 자체 관리 솔루션을 배포합니다.
  2. 프로덕션에 적합한 버전에 도달할 때까지 액세스 정책을 거부하는 등 API 구성을 계속 실행합니다.
  3. APIcast 구성을 프로덕션 게이트웨이로 승격합니다.
  4. 자체 관리 APIcast에 대한 자세한 내용은 APIcast 설치를 참조하십시오.

2.3.2. 애플리케이션 계획을 사용하여 API 액세스 정책 구성

API 보안 아래의 단계를 수행한 후 제품을 통해 인증된 호출만 허용됩니다. 이 섹션에서는 정책을 적용하여 유량 제어를 변경합니다.

3scale에서 애플리케이션은 API 제품에 액세스할 수 있는 인증 정보를 정의합니다. 애플리케이션은 항상 액세스 정책을 결정하는 하나의 애플리케이션 계획과 연결되어 있습니다. 애플리케이션은 개발자 계정 내에 저장됩니다. 기본 3scale 플랜에서는 단일 애플리케이션만 허용됩니다. 높은 플랜에서는 계정당 여러 애플리케이션이 허용됩니다.

프로토타입 에서는 제품의 총 조회수를 기반으로만 액세스를 제어할 수 있습니다. 3scale의 유연성은 사용자 지정 방법 및 메트릭을 사용하여 애플리케이션 계획을 위한 보다 정교한 계층을 만들고 제품에 대한 깊은 분석 통찰력을 향상시킬 수 있습니다. 자세한 내용은 분석 가이드를 참조하십시오.

중요
  • API 구조와 방법 또는 3scale의 지표 간의 매핑은 논리적입니다. 일관된 규칙을 정의하는 경우 3scale에서 제품 사용에 대한 보고서를 받을 수 있습니다. 세부 수준을 결정해야합니다. 일반적으로 5 ~ 20 가지 방법 / 인증 방법을 목표로 해야합니다.
  • 3scale로 보고되는 값은 늘릴 수 있습니다. 절대 값을 설정하거나 카운터를 줄일 수 없습니다.
  • 3scale에 새 메서드 또는 지표를 추가한 후 새 시스템 이름을 통합 지점에 추가하는 것이 중요합니다.
  • 다시 배포하지 않고 런타임에 속도 제한과 같은 변경을 수행할 수 있습니다.

이 예에서는 Echo API 제품의 적용 계획에 정책을 추가하려면 다음 단계를 수행합니다.

  1. 작업하려는 제품을 찾으십시오.
  2. 애플리케이션 계획 섹션에서 basic을 선택하여 3scale에 가입하거나 인스턴스를 배포한 한 후 자동으로 생성된 계획 중 하나를 편집합니다.
  3. hits에 유량 제어가 설정되어 있는 경우에는 그 설정을 삭제합니다.
  4. 시스템 이름 "test"를 사용하여 hits 메트릭 아래에 있는 새 방법을 계획에 추가합니다.
  5. 테스트 방법의 유량 제어를 시간당 5회로 설정합니다.
  6. 시스템 이름 v1v2를 사용하여 두 개의 새 지표를 추가합니다.
  7. v2 지표에서 활성화된 열을 클릭하여 액세스를 비활성화합니다. 이는 유량 제어를 0으로 설정하는 것과 동일합니다.

APIcast 배포

  1. [ your_product_name] > Integration > Configuration 으로 이동합니다.
  2. 매핑 규칙 섹션을 확장하고 다음 매핑을 추가합니다.

    참고

    "/"의 기본 매핑이 제거되었습니다. 이 기본 매핑을 사용하면 적중 횟수가 이중으로 두 번 계산됩니다.

2.3.3. 개발자 포털을 사용하여 개발자 연결

개발자 포털을 사용하여 API를 생성하고 제공하는 정보를 찾을 수 있습니다. 텍스트 또는 마크다운에 콘텐츠를 작성하는 것이 좋습니다. 다음은 고려할 수 있는 선택적 단계입니다.

2.4. 고급 경로 사용

고급 경로를 처음부터 끝까지 개별적으로 실행할 수 있습니다. 또는 필요에 따라 이 경로에서 몇 가지 단계를 수행하도록 선택할 수 있습니다. 각 경로는 독립적일 수 있지만 프로토타입,기본, 고급 경로가 순차적으로 빌드됩니다.

2.4.1. API 보안

제품을 보호하기 위해 다음과 같은 대체 방법이 있습니다.

고급 인증 모드: OpenID Connect(OIDC)

Red Hat Single Sign-On 기술 및 Red Hat build of Keycloak의 OpenID Connect와 APIcast 통합을 사용하여 제품을 보호합니다. 3scale의 애플리케이션은 IdM(Identity Provider)과 동기화됩니다. 현재 이 솔루션은 포괄적인 지원 솔루션입니다. 아래 표시된 OAuth 2.0의 주요 흐름에 해당합니다.

  • 허가 코드
  • 리소스 소유자 암호
  • 클라이언트 인증 정보
  • 암시적 부여

2.4.2. 애플리케이션 계획을 사용하여 API 액세스 정책 구성

API 보안 아래에 나열된 옵션을 사용하면 제품에 대해 인증된 호출만 허용되도록 합니다. 이 섹션에서는 정책을 적용하여 유량 제어를 변경합니다.

3scale에서 애플리케이션은 제품에 액세스할 수 있는 인증 정보를 정의합니다. 애플리케이션은 항상 액세스 정책을 결정하는 하나의 애플리케이션 계획과 연결되어 있습니다. 애플리케이션은 개발자 계정 내에 저장됩니다. Basic 3scale 플랜에서는 단일 애플리케이션만 허용됩니다. 높은 플랜에서는 계정당 여러 애플리케이션이 허용됩니다.

이메일 또는 웹 콘솔에 알림을 전송하도록 경보를 구성할 수 있습니다.

  1. API 설정 페이지로 이동합니다. [ your_product_name] > Applications > Settings > Usage Rules.
  2. 페이지의 경고 섹션으로 이동합니다. 여기서는 원하는 경고를 유량 제어 값의 백분율로 구성할 수 있습니다.

3scale을 사용하면 유량 제한 레벨을 유연하게 설정할 수 있습니다.

  • 소프트 유량 제한: 제한을 초과하는 호출을 통해 수행할 수 있습니다.
  • 하드 유량 제한: 애플리케이션에 도달하기 전에 호출이 거부됩니다.

APIcast는 기본적으로 하드 제한을 정의합니다. 이는 초과 제한 호출을 거부하지 않도록 Lua 파일에서 사용자 지정할 수 있습니다.

2.4.3. 개발자 포털을 사용하여 개발자 연결

기본 경로 설정을 완료한 후에는 개발자 포털에서 탐색할 수 있는 두 가지 고급 영역은 다음과 같습니다.

  • 유동 태그를 사용하면 시스템 개체에 직접 액세스할 수 있고 개발자 포털 페이지를 동적으로 렌더링할 수 있는 태그와 드롭을 제공합니다.
  • 모든 3scale 시스템 페이지를 사용자 지정할 수 있습니다. HTML이 복잡하기 때문에 사용자 지정은 고급 사용자를 위한 것입니다. 궁극적으로 개발자 포털의 모든 페이지를 사용자 지정할 수 있습니다. 일부 CSS를 변경하면 일반적으로 기본 페이지에서 전혀 문제가 없이 완벽하게 잘 작동합니다.

2.5. 프로덕션 환경으로 이동

이 섹션에서는 API 제품이 공개되기 전에 최종 체크리스트에 대해 설명합니다.

참고

리드 타임이 길기 때문에 가능한 한 빨리 사용자 정의 도메인 및 이메일에 대한 요청을 보냅니다.

  1. Audience > Developer Portal > Settings > Domains & Access 에서 사용자 지정 도메인을 개발자 포털 사이트 필드에 입력합니다.
  2. 선택적으로 Outgoing Email 필드에 사용자 정의 아웃 바운드 이메일 주소를 입력합니다.
  3. 개발자 포털 액세스 코드를 제거합니다.
  4. 계정 업데이트를 클릭하여 변경 사항을 저장합니다.

다음은 고려해야 할 몇 가지 추가 사항입니다.

  • API 제품에서 직접 수익을 생성하기 위해 가격을 추가하십시오. 이 기능은 3scale Hosted(SaaS) 계정에서만 사용할 수 있습니다.
  • Analytics 섹션아래에 있는 관리 포털에서 제품 분석의 정보를 사용하여 애플리케이션 계획을 조정합니다.

법적 공지

Copyright © 2024 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.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat