Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Edge Microgateway의 작업 및 구성 참조

Apigee Edge 문서입니다.
Apigee X 문서로 이동 info

Edge Microgateway v. 2.5.x

이 주제에서는 Edge Microgateway를 관리하고 구성하는 방법을 설명합니다.

인터넷에 연결된 경우 Edge Microgateway 업그레이드

다음 npm 명령어를 실행하여 최신 버전의 Edge Microgateway로 업그레이드합니다.
```
npm upgrade edgemicro -g
```
특정 버전의 Edge Microgateway로 업그레이드하려면 업그레이드 명령어에 버전 번호를 지정해야 합니다. 버전 번호를 지정하지 않으면 최신 버전이 설치됩니다. 예를 들어 버전 2.5.26으로 업그레이드하려면 다음 명령어를 사용합니다.
```
npm upgrade edgemicro@2.5.26 -g
```

버전 번호를 확인합니다. 예를 들어 버전 2.5.26을 설치한 경우:

edgemicro --version
current nodejs version is v8.9.0
current edgemicro version is 2.5.26

마지막으로 최신 버전의 edgemicro-auth 프록시로 업그레이드합니다.
```
edgemicro upgradeauth -o org_name -e env_name -u username
```

구성 변경

알아야 할 구성 파일은 다음과 같습니다.

기본 시스템 구성 파일
새로 초기화된 Edge Microgateway 인스턴스의 기본 구성 파일
실행 중인 인스턴스의 동적 구성 파일

이 섹션에서는 이러한 파일과 파일을 변경할 때 알아야 할 사항에 대해 설명합니다.

기본 시스템 구성 파일

Edge Microgateway를 설치하면 기본 시스템 구성 파일이 다음 위치에 배치됩니다.

prefix/lib/node_modules/edgemicro/config/default.yaml

여기서 prefix은 npm 프리픽스 디렉터리입니다. 이 디렉터리를 찾을 수 없는 경우 Edge Microgateway가 설치된 위치를 참조하세요.

시스템 구성 파일을 변경하는 경우 Edge Microgateway를 다시 초기화, 재구성, 다시 시작해야 합니다.

edgemicro init
edgemicro configure [params]
edgemicro start [params]

새로 초기화된 Edge Microgateway 인스턴스의 기본 구성 파일

edgemicro init를 실행하면 위에서 설명한 시스템 구성 파일 default.yaml이 ~/.edgemicro 디렉터리에 배치됩니다.

~/.edgemicro에서 구성 파일을 변경하는 경우 Edge Microgateway를 다시 구성하고 다시 시작해야 합니다.

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

실행 중인 인스턴스의 동적 구성 파일

edgemicro configure [params]를 실행하면 ~/.edgemicro에 동적 구성 파일이 생성됩니다. 파일 이름은 org-env-config.yaml 패턴에 따라 지정됩니다. 여기서 org 및 env는 Apigee Edge 조직 및 환경 이름입니다. 이 파일을 사용하여 구성을 변경한 후 다운타임 없이 다시 로드할 수 있습니다. 예를 들어 플러그인을 추가하고 구성하는 경우 아래 설명된 대로 다운타임 없이 구성을 새로고침할 수 있습니다.

Edge Microgateway가 실행 중인 경우(다운타임 없는 옵션):

Edge Microgateway 구성을 새로고침합니다.
```
edgemicro reload -o org_name -e env_name -k key -s secret
```
각 항목의 의미는 다음과 같습니다.
- org_name는 Edge 조직 이름입니다(조직 관리자여야 함).
- env_name은 조직의 환경입니다(예: 'test' 또는 'prod').
- key는 이전에 configure 명령어로 반환된 키입니다.
- secret는 이전에 configure 명령어로 반환된 키입니다.
예를 들면 다음과 같습니다.
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

Edge Microgateway가 중지된 경우:

Edge Microgateway를 다시 시작합니다.
```
edgemicro start -o org_name -e env_name -k key -s secret
```
각 항목의 의미는 다음과 같습니다.
- org_name는 Edge 조직 이름입니다(조직 관리자여야 함).
- env_name은 조직의 환경입니다(예: 'test' 또는 'prod').
- key는 이전에 configure 명령어로 반환된 키입니다.
- secret는 이전에 configure 명령어로 반환된 키입니다.
예를 들면 다음과 같습니다.
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

다음은 구성 파일의 예시입니다. 구성 파일 설정에 대한 자세한 내용은 Edge Microgateway 구성 참조를 확인하세요.

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

환경 변수 설정

Edge 조직 및 환경의 값이 필요한 명령줄 인터페이스 명령어와 Edge Microgateway를 시작하는 데 필요한 키 및 보안 비밀을 다음 환경 변수에 저장할 수 있습니다.

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

이러한 변수를 설정하는 것은 선택사항입니다. 이를 설정하면 명령줄 인터페이스(CLI)를 사용하여 Edge Microgateway를 구성하고 시작할 때 값을 지정할 필요가 없습니다.

Edge Microgateway 서버에서 SSL 구성

SSL을 사용하도록 Microgateway 서버를 구성할 수 있습니다. 예를 들어 SSL이 구성된 경우 다음과 같이 'https' 프로토콜을 사용하여 Edge Microgateway를 통해 API를 호출할 수 있습니다.

https://localhost:8000/myapi

Microgateway 서버에서 SSL을 구성하려면 다음 단계를 따르세요.

openssl 유틸리티 또는 원하는 방법을 사용하여 SSL 인증서와 키를 생성하거나 가져옵니다.
edgemicro:ssl 속성을 Edge Microgateway 구성 파일에 추가합니다. 전체 옵션 목록은 아래 표를 참조하세요. 예를 들면 다음과 같습니다.
```
edgemicro:
  ssl:
   key: <absolute path to the SSL key file>
   cert: <absolute path to the SSL cert file>
   passphrase: admin123 #option added in v2.2.2
   rejectUnauthorized: true #option added in v2.2.2
   requestCert: true
```
참조된 SSL 키 파일에 지정된 키는 암호화되지 않아야 합니다.
Edge Microgateway를 다시 시작합니다. 수정한 구성 파일(기본 파일 또는 런타임 구성 파일)에 따라 구성 변경에 설명된 단계를 따릅니다.

다음은 SSL이 구성된 구성 파일의 edgemicro 섹션의 예시입니다.

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

지원되는 모든 서버 옵션 목록은 다음과 같습니다.

옵션	설명
`key`	`ca.key` 파일의 경로입니다(PEM 형식).
`cert`	`ca.cert` 파일의 경로입니다(PEM 형식).
`pfx`	PFX 형식의 클라이언트 비공개 키, 인증서, CA 인증서가 포함된 `pfx` 파일의 경로입니다.
`passphrase`	비공개 키 또는 PFX의 암호가 포함된 문자열입니다.
`ca`	PEM 형식의 신뢰할 수 있는 인증서 목록이 포함된 파일의 경로입니다.
`ciphers`	':'로 구분하여 사용할 암호를 설명하는 문자열입니다.
`rejectUnauthorized`	true인 경우 서버 인증서가 제공된 CA 목록과 비교하여 확인됩니다. 확인에 실패하면 오류가 반환됩니다.
`secureProtocol`	사용할 SSL 메서드입니다. 예를 들어 SSLv3_method는 SSL을 버전 3으로 강제 적용합니다.
`servername`	SNI(서버 이름 표시) TLS 확장 프로그램의 서버 이름입니다.
`requestCert`	양방향 SSL의 경우 true, 단방향 SSL의 경우 false

클라이언트 SSL/TLS 옵션 사용

대상 엔드포인트에 연결할 때 Edge Microgateway를 TLS 또는 SSL 클라이언트로 구성할 수 있습니다. Microgateway 구성 파일에서 targets 요소를 사용하여 SSL/TLS 옵션을 설정합니다.

이 예시에서는 모든 호스트에 적용되는 설정을 제공합니다.

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

이 예시에서는 설정이 지정된 호스트에만 적용됩니다.

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

다음은 TLS의 예입니다.

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

다음은 지원되는 모든 클라이언트 옵션의 목록입니다.

옵션	설명
`pfx`	PFX 형식의 클라이언트 비공개 키, 인증서, CA 인증서가 포함된 `pfx` 파일의 경로입니다.
`key`	`ca.key` 파일의 경로입니다(PEM 형식).
`passphrase`	비공개 키 또는 PFX의 암호가 포함된 문자열입니다.
`cert`	`ca.cert` 파일의 경로입니다(PEM 형식).
`ca`	PEM 형식의 신뢰할 수 있는 인증서 목록이 포함된 파일의 경로입니다.
`ciphers`	':'로 구분하여 사용할 암호를 설명하는 문자열입니다.
`rejectUnauthorized`	true인 경우 서버 인증서가 제공된 CA 목록과 비교하여 확인됩니다. 확인에 실패하면 오류가 반환됩니다.
`secureProtocol`	사용할 SSL 메서드입니다. 예를 들어 SSLv3_method는 SSL을 버전 3으로 강제 적용합니다.
`servername`	SNI(서버 이름 표시) TLS 확장 프로그램의 서버 이름입니다.

edgemicro-auth 프록시 맞춤설정

기본적으로 Edge Microgateway는 OAuth2 인증을 위해 Apigee Edge에 배포된 프록시를 사용합니다. 이 프록시는 edgemicro configure를 처음 실행할 때 배포됩니다. 이 프록시의 기본 구성을 변경하여 JSON 웹 토큰(JWT)에 커스텀 클레임 지원을 추가하고, 토큰 만료를 구성하고, 갱신 토큰을 생성할 수 있습니다. 자세한 내용은 GitHub의 edgemicro-auth 페이지를 참조하세요.

커스텀 인증 서비스 사용

기본적으로 Edge Microgateway는 OAuth2 인증을 위해 Apigee Edge에 배포된 프록시를 사용합니다. 이 프록시는 edgemicro configure를 처음 실행할 때 배포됩니다. 기본적으로 이 프록시의 URL은 Edge Microgateway 구성 파일에 다음과 같이 지정됩니다.

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

자체 커스텀 서비스를 사용하여 인증을 처리하려면 구성 파일의 authUri 값을 서비스를 가리키도록 변경합니다. 예를 들어 LDAP를 사용하여 ID를 확인하는 서비스가 있을 수 있습니다.

중요: 기본 인증 프록시를 재정의하는 경우 새 프록시 또는 서비스는 기본 edgemicro-auth 프록시와 동일한 응답 형식을 반환해야 합니다.

로그 파일 관리

Edge Microgateway는 각 요청 및 응답에 대한 정보를 로깅합니다. 로그 파일은 디버깅 및 문제 해결에 유용한 정보를 제공합니다.

로그 파일 저장 위치

기본적으로 로그 파일은 /var/tmp에 저장됩니다.

기본 로그 파일 디렉터리를 변경하는 방법

로그 파일이 저장되는 디렉터리는 Edge Microgateway 구성 파일에 지정됩니다. 구성 변경도 참조하세요.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

dir 값을 변경하여 다른 로그 파일 디렉터리를 지정합니다.

콘솔에 로그 전송

로그 정보가 로그 파일이 아닌 표준 출력으로 전송되도록 로깅을 구성할 수 있습니다. 다음과 같이 to_console 플래그를 true로 설정합니다.

edgemicro:
  logging:
    to_console: true

이 설정을 사용하면 로그가 표준 출력으로 전송됩니다. 현재는 로그를 stdout과 로그 파일 모두에 전송할 수 없습니다.

로깅 수준 설정 방법

info, warn, error 로그 수준을 설정할 수 있습니다. 정보 수준을 사용하는 것이 좋습니다. 모든 API 요청 및 응답을 로깅하며 기본값입니다.

로그 간격 변경 방법

Edge Microgateway 구성 파일에서 이러한 간격을 구성할 수 있습니다. 구성 변경도 참조하세요.

구성 가능한 속성은 다음과 같습니다.

stats_log_interval: (기본값: 60) 통계 레코드가 API 로그 파일에 기록되는 간격(초)입니다.
rotate_interval: (기본값: 24) 로그 파일이 순환되는 간격(시간)입니다. 예를 들면 다음과 같습니다.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

로그 파일 유지보수 권장사항

로그 파일 데이터가 시간이 지남에 따라 누적되므로 Apigee에서는 다음 관행을 채택하는 것이 좋습니다.

로그 파일이 상당히 커질 수 있으므로 로그 파일 디렉터리에 충분한 공간이 있는지 확인합니다. 로그 파일이 저장되는 위치 및 기본 로그 파일 디렉터리를 변경하는 방법 섹션을 참조하세요.
일주일에 한 번 이상 로그 파일을 삭제하거나 별도의 보관 디렉터리로 이동합니다.
로그를 삭제하는 정책이 있는 경우 CLI 명령어 edgemicro log -c를 사용하여 이전 로그를 삭제(정리)할 수 있습니다.

로그 파일 이름 지정 규칙

각 Edge Microgateway 인스턴스는 세 가지 유형의 로그 파일을 생성합니다.

api - Edge Microgateway를 통해 흐르는 모든 요청 및 응답을 로깅합니다. API 카운터(통계) 및 오류도 이 파일에 로깅됩니다.
err - stderr로 전송된 모든 항목을 로깅합니다.
out - stdout으로 전송된 모든 항목을 로깅합니다.

이름은 다음 규칙에 따라 지정합니다.

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

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

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

로그 파일 콘텐츠 정보

추가된 버전: v2.3.3

기본적으로 로깅 서비스는 다운로드한 프록시, 제품, JSON 웹 토큰(JWT)의 JSON을 생략합니다. 이러한 객체를 로그 파일에 출력하려면 Edge Microgateway를 시작할 때 DEBUG=*를 설정합니다. 예를 들면 다음과 같습니다.

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Windows에서는 SET DEBUG=*를 사용합니다.

'api' 로그 파일의 콘텐츠

'api' 로그 파일에는 Edge Microgateway를 통한 요청 및 응답 흐름에 대한 자세한 정보가 포함되어 있습니다. 'api' 로그 파일의 이름은 다음과 같습니다.

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Edge Microgateway에 대한 각 요청에 대해 'api' 로그 파일에 4개의 이벤트가 캡처됩니다.

클라이언트의 수신 요청
대상에 대한 발신 요청
대상에서 수신되는 응답
클라이언트에 대한 발신 응답

이러한 각 항목은 로그 파일을 더 간결하게 만들기 위해 약식 표기법으로 표시됩니다. 다음은 네 가지 이벤트를 각각 나타내는 네 가지 샘플 항목입니다. 로그 파일에서는 다음과 같이 표시됩니다(줄 번호는 문서에서 참조용으로만 사용되며 로그 파일에는 표시되지 않음).

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

하나씩 살펴보겠습니다.

1. 클라이언트에서 수신되는 요청 샘플:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

1436403888651 - Unix 날짜 스탬프
info - 컨텍스트에 따라 다릅니다. 로그 수준에 따라 정보, 경고 또는 오류일 수 있습니다. 통계 레코드의 통계, 경고의 경고 또는 오류의 오류일 수 있습니다.
req - 이벤트를 식별합니다. 이 경우 클라이언트의 요청입니다.
m - 요청에 사용된 HTTP 동사입니다.
u - 기본 경로 뒤에 오는 URL 부분입니다.
h - Edge Microgateway가 리슨하는 호스트 및 포트 번호입니다.
r - 클라이언트 요청이 시작된 원격 호스트 및 포트입니다.
i - 요청 ID입니다. 4개의 이벤트 항목 모두 이 ID를 공유합니다. 각 요청에는 고유한 요청 ID가 할당됩니다. 요청 ID로 로그 레코드를 상호 연결하면 대상의 지연 시간에 대한 유용한 정보를 얻을 수 있습니다.
d - Edge Microgateway에서 요청을 수신한 이후의 기간(밀리초)입니다. 위의 예시에서 요청 0에 대한 대상의 응답은 7밀리초 후에 수신되었고(3행) 응답은 추가로 4밀리초 후에 클라이언트로 전송되었습니다(4행). 즉, 총 요청 지연 시간은 11밀리초이며, 이 중 7밀리초는 대상에서, 4밀리초는 Edge Microgateway 자체에서 소요되었습니다.

2. 대상에 대한 발신 요청 샘플:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

1436403888651 - Unix 날짜 스탬프
info - 컨텍스트에 따라 다릅니다. 로그 수준에 따라 정보, 경고 또는 오류일 수 있습니다. 통계 레코드의 통계, 경고의 경고 또는 오류의 오류일 수 있습니다.
treq - 이벤트를 식별합니다. 이 경우 타겟 요청입니다.
m - 대상 요청에 사용되는 HTTP 동사입니다.
u - 기본 경로 뒤에 오는 URL 부분입니다.
h - 백엔드 대상의 호스트 및 포트 번호입니다.
i - 로그 항목의 ID입니다. 4개의 이벤트 항목 모두 이 ID를 공유합니다.

3. 대상에서 수신되는 응답 샘플

1436403888672 info tres s=200, d=7, i=0

1436403888651 - Unix 날짜 스탬프

info - 컨텍스트에 따라 다릅니다. 로그 수준에 따라 정보, 경고 또는 오류일 수 있습니다. 통계 레코드의 통계, 경고의 경고 또는 오류의 오류일 수 있습니다.
tres - 이벤트를 식별합니다. 이 경우 대상 응답입니다.
s - HTTP 응답 상태입니다.
d - 밀리초 단위의 재생 시간입니다. 대상에서 API 호출에 걸린 시간입니다.
i - 로그 항목의 ID입니다. 4개의 이벤트 항목 모두 이 ID를 공유합니다.

4. 고객에게 보내는 응답 샘플

1436403888676 info res s=200, d=11, i=0

1436403888651 - Unix 날짜 스탬프

info - 컨텍스트에 따라 다릅니다. 로그 수준에 따라 정보, 경고 또는 오류일 수 있습니다. 통계 레코드의 통계, 경고의 경고 또는 오류의 오류일 수 있습니다.
res - 이벤트를 식별합니다. 이 경우 클라이언트에 대한 응답입니다.
s - HTTP 응답 상태입니다.
d - 밀리초 단위의 재생 시간입니다. 대상 API에서 소요된 시간과 Edge Microgateway 자체에서 소요된 시간을 포함하여 API 호출에 소요된 총 시간입니다.
i - 로그 항목의 ID입니다. 4개의 이벤트 항목 모두 이 ID를 공유합니다.

로그 파일 일정

로그 파일은 rotate_interval 구성 속성에 지정된 간격으로 순환됩니다. 순환 간격이 만료될 때까지 항목이 동일한 로그 파일에 계속 추가됩니다. 하지만 Edge Microgateway가 다시 시작될 때마다 새 UID를 수신하고 이 UID로 새 로그 파일 집합을 만듭니다. 좋은 로그 파일 유지보수 관행도 참조하세요.

오류 메시지

일부 로그 항목에는 오류 메시지가 포함됩니다. 오류가 발생하는 위치와 이유를 파악하려면 Edge Microgateway 오류 참조를 확인하세요.

Edge Microgateway 구성 참조

구성 파일의 위치

이 섹션에서 설명하는 구성 속성은 Edge Microgateway 구성 파일에 있습니다. 구성 변경도 참조하세요.

edge_config 속성

이러한 설정은 Edge Microgateway 인스턴스와 Apigee Edge 간의 상호작용을 구성하는 데 사용됩니다.

bootstrap: (기본값: 없음) Apigee Edge에서 실행되는 Edge Microgateway 관련 서비스를 가리키는 URL입니다. Edge Microgateway는 이 서비스를 사용하여 Apigee Edge와 통신합니다. 이 URL은 공개/비공개 키 쌍을 생성하는 명령어(edgemicro genkeys)를 실행할 때 반환됩니다. 자세한 내용은 Edge Microgateway 설정 및 구성을 참조하세요.
jwt_public_key: (기본값: 없음) Apigee Edge에 배포된 Edge Microgateway 프록시를 가리키는 URL입니다. 이 프록시는 클라이언트에 서명된 액세스 토큰을 발급하기 위한 인증 엔드포인트 역할을 합니다. 이 URL은 프록시를 배포하는 명령어인 edgemicro configure를 실행할 때 반환됩니다. 자세한 내용은 Edge Microgateway 설정 및 구성을 참조하세요.

edgemicro 속성

이 설정은 Edge Microgateway 프로세스를 구성합니다.

port: (기본값: 8000) Edge Microgateway 프로세스가 리슨하는 포트 번호입니다.
max_connections: (기본값: -1) Edge Microgateway가 수신할 수 있는 최대 동시 수신 연결 수를 지정합니다. 이 수를 초과하면 다음 상태가 반환됩니다.

res.statusCode = 429; // Too many requests
max_connections_hard: (기본값: -1) Edge Microgateway가 연결을 종료하기 전에 수신할 수 있는 최대 동시 요청 수입니다. 이 설정은 서비스 거부 공격을 차단하기 위한 것입니다. 일반적으로 max_connections보다 큰 숫자로 설정합니다.
logging:
- level: (기본값: 오류)
  - info - Edge Microgateway 인스턴스를 통해 전달되는 모든 요청과 응답을 로깅합니다.
  - warn - 경고 메시지만 로깅합니다.
  - error - 오류 메시지만 로깅합니다.
- dir: (기본값: /var/tmp) 로그 파일이 저장되는 디렉터리입니다.
- stats_log_interval: (기본값: 60) 통계 레코드가 API 로그 파일에 기록되는 간격(초)입니다.
- rotate_interval: (기본값: 24) 로그 파일이 순환되는 간격(시간)입니다.

플러그인: 플러그인은 Edge Microgateway에 기능을 추가합니다. 플러그인 개발에 대한 자세한 내용은 커스텀 플러그인 개발을 참조하세요.

dir: ./gateway 디렉터리에서 ./plugins 디렉터리로의 상대 경로 또는 절대 경로입니다.
sequence: Edge Microgateway 인스턴스에 추가할 플러그인 모듈 목록입니다. 모듈은 여기에 지정된 순서대로 실행됩니다.

debug: Edge Microgateway 프로세스에 원격 디버깅을 추가합니다.
- port: 리슨할 포트 번호입니다. 예를 들어 이 포트에서 리슨하도록 IDE 디버거를 설정합니다.
- args: 디버그 프로세스의 인수입니다. 예를 들면 다음과 같습니다. args --nolazy
config_change_poll_interval:(기본값: 600초) Edge Microgateway는 주기적으로 새 구성을 로드하고 변경사항이 있으면 새로고침을 실행합니다. 폴링은 Edge에서 변경된 사항(제품, 마이크로게이트웨이 인식 프록시 등의 변경사항)과 로컬 구성 파일의 변경사항을 선택합니다.
disable_config_poll_interval:(기본값: false) 자동 변경 폴링을 사용 중지하려면 true로 설정합니다.
request_timeout: 대상 요청의 제한 시간을 설정합니다. 제한 시간은 초 단위로 설정됩니다. 제한 시간이 초과되면 Edge Microgateway는 504 상태 코드로 응답합니다. (v2.4.x 추가됨)

headers 속성

이 설정은 특정 HTTP 헤더가 처리되는 방식을 구성합니다.

x-forwarded-for: (기본값: true) x-forwarded-for 헤더가 대상으로 전달되지 않도록 하려면 false로 설정합니다. 요청에 x-forwarded-for 헤더가 있으면 해당 값이 Edge 분석의 client-ip 값으로 설정됩니다.
x-forwarded-host: (기본값: true) x-forwarded-host 헤더가 대상에 전달되지 않도록 하려면 false로 설정합니다.
x-request-id: (기본값: true) x-request-id 헤더가 대상으로 전달되지 않도록 하려면 false로 설정합니다.
x-response-time: (기본값: true) x-response-time 헤더가 대상으로 전달되지 않도록 하려면 false로 설정합니다.
via: (기본값: true) via 헤더가 대상으로 전달되지 않도록 하려면 false로 설정합니다.

oauth 속성

이러한 설정은 Edge Microgateway에서 클라이언트 인증을 시행하는 방법을 구성합니다.

allowNoAuthorization: (기본값: false) true로 설정하면 API 호출이 승인 헤더 없이 Edge Microgateway를 통과할 수 있습니다. 승인 헤더를 요구하려면 이 값을 false로 설정합니다(기본값).
allowInvalidAuthorization: (기본값: false) true로 설정하면 Authorization 헤더에 전달된 토큰이 잘못되었거나 만료된 경우 API 호출이 전달될 수 있습니다. 유효한 토큰을 요구하려면 이 값을 false로 설정합니다(기본값).
authorization-header: (기본값: Authorization: Bearer) 액세스 토큰을 Edge Microgateway로 전송하는 데 사용되는 헤더입니다. 대상이 다른 용도로 승인 헤더를 사용해야 하는 경우 기본값을 변경할 수 있습니다.
api-key-header: (기본값: x-api-key) API 키를 Edge Microgateway에 전달하는 데 사용되는 헤더 또는 쿼리 매개변수의 이름입니다. API 키 사용도 참조하세요.
keep-authorization-header: (기본값: false) true로 설정하면 요청에 전송된 Authorization 헤더가 대상으로 전달됩니다(보존됨).
allowOAuthOnly -- true로 설정하면 모든 API에 Bearer 액세스 토큰이 있는 승인 헤더가 있어야 합니다. OAuth 보안 모델만 허용할 수 있습니다(이전 버전과의 호환성 유지). (2.4.x 추가됨)
allowAPIKeyOnly -- true로 설정하면 모든 API에 API 키가 있는 x-api-key 헤더(또는 커스텀 위치)가 있어야 합니다.API 키 보안 모델만 허용할 수 있습니다(이전 버전과의 호환성 유지). (2.4.x 추가됨)
allowOAuthOnly와 allowAPIKeyOnly를 모두 true로 설정하지 마세요. 기본 설정은 두 플래그가 모두 false로 설정됩니다(이전 버전과의 호환성).
gracePeriod -- 이 매개변수는 시스템 시계와 JWT 승인 토큰에 지정된 Not Before(nbf) 또는 Issued At(iat) 시간 간의 약간의 불일치로 인해 발생하는 오류를 방지하는 데 도움이 됩니다. 이러한 불일치를 허용할 시간(초)으로 이 매개변수를 설정합니다. (2.5.7 추가됨)

플러그인별 속성

각 플러그인의 구성 가능한 속성에 대한 자세한 내용은 플러그인 사용을 참조하세요.

프록시 필터링

Edge Microgateway 인스턴스가 처리할 마이크로게이트웨이 인식 프록시를 필터링할 수 있습니다. Edge Microgateway가 시작되면 연결된 조직의 모든 마이크로게이트웨이 인식 프록시를 다운로드합니다. 다음 구성을 사용하여 마이크로게이트웨이가 처리할 프록시를 제한합니다. 예를 들어 이 구성은 마이크로게이트웨이가 처리할 프록시를 edgemicro_proxy-1, edgemicro_proxy-2, edgemicro_proxy-3의 세 가지로 제한합니다.

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

분석 푸시 빈도 구성

다음 구성 매개변수를 사용하여 Edge Microgateway가 Apigee에 분석 데이터를 전송하는 빈도를 제어합니다.

bufferSize(선택사항): 가장 오래된 레코드를 삭제하기 전에 버퍼가 보유할 수 있는 최대 분석 레코드 수입니다. 기본값: 10000
batchSize(선택사항): Apigee로 전송되는 분석 레코드 배치의 최대 크기입니다. 기본값: 500
flushInterval(선택사항): Apigee로 전송되는 분석 레코드 배치의 각 플러시 간격(밀리초)입니다. 기본값: 5000

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

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

분석 데이터 마스킹

다음 구성은 요청 경로 정보가 Edge 분석에 표시되지 않도록 합니다. 마이크로게이트웨이 구성에 다음을 추가하여 요청 URI 또는 요청 경로를 마스킹합니다. URI는 요청의 호스트 이름과 경로 부분으로 구성됩니다.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

Edge Analytics에서 API 호출 분리

Edge 분석 대시보드에서 별도의 프록시로 표시되도록 특정 API 경로를 분리하도록 분석 플러그인을 구성할 수 있습니다. 예를 들어 대시보드에서 상태 점검 API를 분리하여 실제 API 프록시 호출과 혼동하지 않도록 할 수 있습니다. 애널리틱스 대시보드에서 분리된 프록시는 다음 이름 지정 패턴을 따릅니다.

edgemicro_proxyname-health

다음 이미지는 애널리틱스 대시보드에서 분리된 두 프록시인 edgemicro_hello-health 및 edgemicro_mock-health를 보여줍니다.

이러한 매개변수를 사용하여 애널리틱스 대시보드에서 상대 경로와 절대 경로를 별도의 프록시로 분리합니다.

relativePath(선택사항): 애널리틱스 대시보드에서 분리할 상대 경로를 지정합니다. 예를 들어 /healthcheck를 지정하면 /healthcheck 경로가 포함된 모든 API 호출이 대시보드에 edgemicro_proxyname-health로 표시됩니다. 이 플래그는 프록시 기본 경로를 무시합니다. basepath를 포함한 전체 경로를 기준으로 분리하려면 proxyPath 플래그를 사용합니다.
proxyPath(선택사항): 분석 대시보드에서 분리할 프록시 기본 경로를 포함한 전체 API 프록시 경로를 지정합니다. 예를 들어 /mocktarget/healthcheck를 지정하는 경우(여기서 /mocktarget는 프록시 기본 경로) 경로가 /mocktarget/healthcheck인 모든 API 호출이 대시보드에 edgemicro_proxyname-health로 표시됩니다.

예를 들어 다음 구성에서 /healthcheck가 포함된 모든 API 경로는 분석 플러그인에 의해 분리됩니다. 즉, /foo/healthcheck 및 /foo/bar/healthcheck는 분석 대시보드에서 edgemicro_proxyname-health라는 별도의 프록시로 분리됩니다.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

다음 구성에서 프록시 경로가 /mocktarget/healthcheck인 모든 API는 분석 대시보드에서 edgemicro_proxyname-health라는 별도의 프록시로 분리됩니다.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

회사 방화벽 뒤에 Edge Microgateway 설정

지원되는 v2.4.x

Edge Microgateway가 방화벽 뒤에 설치된 경우 게이트웨이가 Apigee Edge와 통신하지 못할 수 있습니다. 이 경우 다음 두 가지 옵션을 고려할 수 있습니다.

옵션 1:

첫 번째 옵션은 마이크로게이트웨이 구성 파일에서 edgemicro: proxy_tunnel 옵션을 true로 설정하는 것입니다.

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

proxy_tunnel이 true이면 Edge Microgateway는 HTTP CONNECT 메서드를 사용하여 단일 TCP 연결을 통해 HTTP 요청을 터널링합니다. (프록시를 구성하는 환경 변수가 TLS를 사용 설정하는 경우에도 마찬가지입니다.)

옵션 2:

두 번째 옵션은 마이크로게이트웨이 구성 파일에서 프록시를 지정하고 proxy_tunnel을 false로 설정하는 것입니다. 예를 들면 다음과 같습니다.

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

이 경우 다음 변수를 설정하여 사용하려는 각 HTTP 프록시의 호스트를 제어하거나 Edge Microgateway 프록시를 처리하지 않아야 하는 호스트를 제어할 수 있습니다. HTTP_PROXY, HTTPS_PROXY, NO_PROXY.

NO_PROXY를 Edge Microgateway가 프록시하지 않아야 하는 도메인의 쉼표로 구분된 목록으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.

export NO_PROXY='localhost,localhost:8080'

Edge Microgateway가 메시지를 보낼 수 있는 HTTP 프록시 엔드포인트로 HTTP_PROXY 및 HTTPS_PROXY를 설정합니다. 예를 들면 다음과 같습니다.

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

이러한 변수에 대한 자세한 내용은 https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables를 참조하세요.

참고 항목

Apigee 커뮤니티의 회사 방화벽 뒤에 Edge Microgateway를 설정하는 방법

Microgateway 인식 프록시에서 와일드 카드 사용

edgemicro_*(Microgateway 인식) 프록시의 기본 경로에서 하나 이상의 '*' 와일드 카드를 사용할 수 있습니다. 예를 들어 /team/*/members의 기본 경로를 사용하면 클라이언트가 새 팀을 지원하기 위해 새 API 프록시를 만들 필요 없이 https://[host]/team/blue/members 및 https://[host]/team/green/members를 호출할 수 있습니다. /**/는 지원되지 않습니다.

중요: Apigee는 기본 경로의 첫 번째 요소로 와일드 카드 '*'를 사용하는 것을 지원하지 않습니다. 예를 들어 /*/ 검색은 지원되지 않습니다.

JWT 키 순환

JWT를 처음 생성한 후 어느 정도 지나면 Edge 암호화된 KVM에 저장된 공개 키/비공개 키 쌍을 변경해야 할 수 있습니다. 새 키 쌍을 생성하는 이 프로세스를 키 순환이라고 합니다.

Edge Microgateway에서 JWT를 사용하는 방법

JSON 웹 토큰(JWT)은 RFC7519에 설명된 토큰 표준입니다. JWT는 JWT 수신자가 안정적으로 확인할 수 있는 클레임 집합에 서명하는 방법을 제공합니다.

Edge Microgateway는 JWT를 OAuth 보안을 위한 Bearer 토큰으로 사용합니다. Edge Microgateway용 OAuth 토큰을 생성하면 JWT가 다시 수신됩니다. 그런 다음 API 호출의 승인 헤더에서 JWT를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

새 JWT 생성

edgemicro token 명령어 또는 API를 사용하여 Edge Microgateway의 JWT를 생성할 수 있습니다. 예를 들면 다음과 같습니다.

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

이 명령어는 Apigee Edge에 API 호출을 확인하는 데 사용할 수 있는 JWT를 생성하도록 요청합니다. -i 및 -s 매개변수는 Apigee Edge 조직의 개발자 앱에서 가져온 소비자 ID 및 보안 비밀 값입니다.

또는 Management API를 사용하여 JWT를 생성할 수도 있습니다.

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

각 항목의 의미는 다음과 같습니다.

org은 Edge 조직 이름입니다(조직 관리자여야 함).
env은 조직의 환경입니다(예: 'test' 또는 'prod').
client_id는 이전에 만든 개발자 앱의 소비자 ID입니다.
client_secret는 이전에 만든 개발자 앱의 소비자 보안 비밀번호입니다.

키 순환이란 무엇인가요?

JWT를 처음 생성한 후 어느 정도 지나면 Edge 암호화된 KVM에 저장된 공개 키/비공개 키 쌍을 변경해야 할 수 있습니다. 새 키 쌍을 생성하는 이 프로세스를 키 순환이라고 합니다. 키를 순환하면 새 비공개/공개 키 쌍이 생성되고 Apigee Edge 조직/환경의 'microgateway' KVM에 저장됩니다. 또한 이전 공개 키는 원래 키 ID 값과 함께 보관됩니다.

JWT를 생성하기 위해 Edge는 암호화된 KVM에 저장된 정보를 사용합니다. Edge Microgateway를 처음 설정(구성)할 때 microgateway라는 KVM이 생성되고 키로 채워졌습니다. KVM의 키는 JWT에 서명하고 암호화하는 데 사용됩니다.

KVM 키에는 다음이 포함됩니다.

private_key - JWT에 서명하는 데 사용되는 최신(가장 최근에 생성된) RSA 비공개 키입니다.
public_key - private_key로 서명된 JWT를 확인하는 데 사용되는 최신(가장 최근에 생성된) 인증서입니다.
private_key_kid - 최신(가장 최근에 생성된) 비공개 키 ID입니다. 이 키 ID는 private_key 값과 연결되며 키 순환을 지원하는 데 사용됩니다.
public_key1_kid - 최신(가장 최근에 생성된) 공개 키 ID입니다. 이 키는 public_key1 값과 연결되며 키 순환을 지원하는 데 사용됩니다. 이 값은 비공개 키 kid와 동일합니다.
public_key1 - 가장 최근에 생성된 공개 키입니다.

키 순환을 수행하면 기존 키 값이 맵에서 대체되고 이전 공개 키를 유지하기 위해 새 키가 추가됩니다. 예를 들면 다음과 같습니다.

public_key2_kid - 이전 공개 키 ID입니다. 이 키는 public_key2 값과 연결되며 키 순환을 지원하는 데 사용됩니다.
public_key2 - 이전 공개 키입니다.

확인을 위해 제공된 JWT는 새 공개 키를 사용하여 확인됩니다. 확인에 실패하면 이전 공개 키가 만료될 때까지(30분 후) 사용됩니다. 이렇게 하면 API 트래픽을 즉시 중단하지 않고도 키를 '순환'할 수 있습니다.

키 순환 방법

이 섹션에서는 키 순환을 수행하는 방법을 설명합니다.

버전 2.5.2 이전에 Edge Microgateway 인스턴스를 구성한 경우

버전 2.5.2 이전에 Edge Microgateway 인스턴스를 구성한 경우 다음 두 명령어를 실행하여 KVM 및 인증 정책을 업그레이드해야 합니다.

upgradekvm -o org -e env -u username

이 명령어에 대한 자세한 내용은 KVM 업그레이드를 참조하세요.

다음 명령어는 Edge Microgateway를 구성할 때 Apigee 조직에 배포된 edgemicro-oauth 프록시를 업그레이드합니다. 이 프록시는 토큰을 생성하는 데 필요한 서비스를 제공합니다.

upgradeauth -o org -e env -u username

이 명령어에 대한 자세한 내용은 edgemicro-auth 프록시 업그레이드를 참조하세요.

키 순환

~/.edgemicro/org-env-config.yaml 파일에 다음 줄을 추가합니다. 여기서 마이크로게이트웨이를 사용하도록 구성한 것과 동일한 조직 및 환경을 지정해야 합니다.

jwk_public_keys: 'https://org-env.apigee.net/edgemicro-auth/jwkPublicKeys'

키 순환 명령어를 실행하여 키를 순환합니다. 이 명령어에 대한 자세한 내용은 키 순환을 참조하세요.

edgemicro rotatekey -o org -e env -u username -k kid_value

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

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v6.9.1
current edgemicro version is 2.5.7
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

-k 파라미터는 키 ID(kid)를 지정합니다. 이 ID는 특정 키를 일치시키는 데 사용됩니다. Edge Microgateway는 이 값을 사용하여 키 순환 중에 키 집합 중에서 선택합니다. 자세한 내용은 JSON 웹 키 사양의 4.5절을 참조하세요.

키 순환 후 Edge는 Edge Microgateway에 여러 키를 반환합니다. 다음 예시에서 각 키에는 고유한 'kid'(키 ID) 값이 있습니다. 그런 다음 마이크로게이트웨이는 이러한 키를 사용하여 승인 토큰을 검증합니다. 토큰 검증이 실패하면 마이크로게이트웨이는 키 세트에 이전 키가 있는지 확인하고 해당 키를 시도합니다. 반환된 키의 형식은 JSON 웹 키(JWK)입니다. 이 형식에 대한 자세한 내용은 RFC 7517을 참조하세요.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

다운로드한 프록시 필터링

기본적으로 Edge Microgateway는 이름 프리픽스 'edgemicro_'로 시작하는 Edge 조직의 모든 프록시를 다운로드합니다. 이 기본값을 변경하여 이름이 패턴과 일치하는 프록시를 다운로드할 수 있습니다.

Edge Micro 구성 파일(~/.edgemicro/org-env-config.yaml)을 엽니다.
edge_config 아래에 proxyPattern 요소를 추가합니다. 예를 들어 다음 패턴은 edgemicro_foo, edgemicro_fast, edgemicro_first와 같은 프록시를 다운로드합니다.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

API 프록시 없이 제품 지정

Apigee Edge에서는 API 프록시가 포함되지 않은 API 제품을 만들 수 있습니다. 이 제품 구성을 사용하면 해당 제품과 연결된 API 키가 조직에 배포된 모든 프록시에서 작동할 수 있습니다. 버전 2.5.4부터 Edge Microgateway는 이 제품 구성을 지원합니다.

디버깅 및 문제 해결

디버거에 연결

node-inspector와 같은 디버거로 Edge Microgateway를 실행할 수 있습니다. 이는 커스텀 플러그인을 문제 해결하고 디버깅하는 데 유용합니다.

디버그 모드에서 Edge Microgateway를 다시 시작합니다. 이렇게 하려면 start 명령어의 시작 부분에 DEBUG=*를 추가합니다. 예를 들면 다음과 같습니다.
```
DEBUG=* edgemicro start -o  myorg -e test -k
      db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
      6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed
```
Windows에서는 SET DEBUG=*를 사용합니다.
디버거를 시작하고 디버깅 프로세스의 포트 번호에서 수신 대기하도록 설정합니다.
이제 Edge Microgateway 코드를 단계별로 실행하고 중단점을 설정하고 표현식을 감시하는 등의 작업을 수행할 수 있습니다.

디버그 모드와 관련된 표준 Node.js 플래그를 지정할 수 있습니다. 예를 들어 --nolazy는 비동기 코드 디버깅에 도움이 됩니다.

로그 파일 확인

문제가 발생하면 로그 파일에서 실행 세부정보와 오류 정보를 확인하세요. 자세한 내용은 로그 파일 관리를 참조하세요.

API 키 보안 사용

API 키는 Edge Microgateway에 요청하는 클라이언트를 인증하는 간단한 메커니즘을 제공합니다. Edge Microgateway 인증 프록시가 포함된 Apigee Edge 제품에서 고객 키(클라이언트 ID라고도 함) 값을 복사하여 API 키를 가져올 수 있습니다.

키 캐싱

API 키는 캐시된 Bearer 토큰으로 교환됩니다. Edge Microgateway에 대한 수신 요청에서 Cache-Control: no-cache 헤더를 설정하여 캐싱을 사용 중지할 수 있습니다.

API 키 사용

API 키는 API 요청에서 쿼리 매개변수 또는 헤더로 전달할 수 있습니다. 기본적으로 헤더 및 쿼리 매개변수 이름은 모두 x-api-key입니다.

쿼리 매개변수 예시:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

헤더 예시:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

API 키 이름 구성

기본적으로 x-api-key은 API 키 헤더와 쿼리 매개변수 모두에 사용되는 이름입니다. 구성 변경에 설명된 대로 구성 파일에서 이 기본값을 변경할 수 있습니다. 예를 들어 이름을 apiKey로 변경하려면 다음 안내를 따르세요.

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

이 예시에서는 쿼리 매개변수와 헤더 이름이 모두 apiKey로 변경됩니다. 어느 경우든 x-api-key 이름은 더 이상 작동하지 않습니다. 구성 변경도 참조하세요.

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

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

프록시 요청에 API 키를 사용하는 방법에 대한 자세한 내용은 Edge Microgateway 보안을 참조하세요.

OAuth2 토큰 보안 사용

이 섹션에서는 OAuth2 액세스 토큰 및 갱신 토큰을 가져오는 방법을 설명합니다. 액세스 토큰은 마이크로게이트웨이를 통해 보안 API 호출을 수행하는 데 사용됩니다. 갱신 토큰은 새 액세스 토큰을 가져오는 데 사용됩니다.

액세스 토큰을 가져오는 방법

이 섹션에서는 edgemicro-auth 프록시를 사용하여 액세스 토큰을 가져오는 방법을 설명합니다.

edgemicro token CLI 명령어를 사용하여 액세스 토큰을 가져올 수도 있습니다. CLI에 대한 자세한 내용은 토큰 관리를 참조하세요.

API 1

URL에서 조직 및 환경 이름을 대체하고 Apigee Edge의 개발자 앱에서 가져온 소비자 ID 및 소비자 보안 비밀번호 값을 client_id 및 client_secret 본문 매개변수로 대체합니다.

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2

(v2.5.31에 추가됨) 클라이언트 사용자 인증 정보를 기본 인증 헤더로 전송하고 grant_type를 양식 매개변수로 전송합니다. 이 명령어 형식은 RFC 6749: OAuth 2.0 승인 프레임워크에서도 설명합니다.

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

샘플 출력

API는 JSON 응답을 반환합니다. token 속성과 access_token 속성 간에는 차이가 없습니다. 둘 중 하나를 사용할 수 있습니다.

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": "108000"
}

갱신 토큰을 가져오는 방법

갱신 토큰을 가져오려면 edgemicro-auth 프록시의 /token 엔드포인트에 API 호출을 수행합니다. password 권한 부여 유형으로 이 API 호출을 수행해야 합니다. 다음 단계에서는 이 프로세스를 안내합니다.

/token API를 사용하여 액세스 및 갱신 토큰을 가져옵니다. 권한 부여 유형은 password입니다.

curl -X POST \
  https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
   "client_secret":"bUdDcFgv3nXffnU",
   "grant_type":"password",
   "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
   "password":"bUdD2FvnMsXffnU"
}'

API는 액세스 토큰과 갱신 토큰을 반환합니다. 응답은 다음과 유사합니다.

{
    "token": "your-access-token",
    "access_token": "your-access-token",
    "token_type": "bearer",
    "expires_in": "108000",
    "refresh_token": "your-refresh-token",
    "refresh_token_expires_in": "431999",
    "refresh_token_issued_at": "1562087304302",
    "refresh_token_status": "approved"
}

이제 갱신 토큰을 사용하여 동일한 API의 /refresh 엔드포인트를 호출하여 새 액세스 토큰을 가져올 수 있습니다. 예를 들면 다음과 같습니다.

curl -X POST \
  https://willwitman-test.apigee.net/edgemicro-auth/refresh \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
   "client_secret":"bUdDc2Fv3nMXffnU",
   "grant_type":"refresh_token",
   "refresh_token":"your-refresh-token"
}'

API가 새 액세스 토큰을 반환합니다. 응답은 다음과 유사합니다.

{
    "token": "your-new-access-token"
    }

지속적인 모니터링

Forever는 프로세스가 중단되거나 오류가 발생할 경우 Node.js 앱을 자동으로 다시 시작하는 Node.js 도구입니다. Edge Microgateway에는 Edge Microgateway를 다시 시작해야 하는 횟수와 간격을 제어하도록 구성할 수 있는 forever.json 파일이 있습니다. 이 파일은 Forever를 프로그래매틱 방식으로 관리하는 forever-monitor라는 Forever 서비스를 구성합니다.

Edge Microgateway 루트 설치 디렉터리에서 forever.json 파일을 찾을 수 있습니다. Edge Microgateway가 설치된 위치를 참조하세요. 구성 옵션에 대한 자세한 내용은 forever-monitor 문서를 참조하세요.

edgemicro forever 명령어에는 forever.json 파일의 위치를 지정할 수 있는 플래그(-f 플래그)와 Forever 모니터링 프로세스를 시작/중지하는 플래그(-a 플래그)가 포함되어 있습니다. 예를 들면 다음과 같습니다.

edgemicro forever -f ~/mydir/forever.json -a start

자세한 내용은 CLI 참조의 Forever 모니터링을 참고하세요.

구성 파일 엔드포인트 지정

여러 Edge Microgateway 인스턴스를 실행하는 경우 단일 위치에서 구성을 관리할 수 있습니다. Edge Micro가 구성 파일을 다운로드할 수 있는 HTTP 엔드포인트를 지정하면 됩니다. -u 플래그를 사용하여 Edge Micro를 시작할 때 이 엔드포인트를 지정할 수 있습니다.

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

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

여기서 mgconfig 엔드포인트는 구성 파일의 콘텐츠를 반환합니다. 이 파일은 기본적으로 ~/.edgemicro에 있으며 이름 지정 규칙은 org-env-config.yaml입니다.

TCP 연결 데이터 버퍼링 사용 중지

nodelay 구성 속성을 사용하여 Edge Microgateway에서 사용하는 TCP 연결에 대한 데이터 버퍼링을 사용 중지할 수 있습니다.

기본적으로 TCP 연결은 Nagle 알고리즘을 사용하여 데이터를 전송하기 전에 버퍼링합니다. nodelay를 true로 설정하면 이 동작이 사용 중지됩니다(socket.write()가 호출될 때마다 데이터가 즉시 전송됨). 자세한 내용은 Node.js 문서를 참조하세요.

nodelay를 사용 설정하려면 다음과 같이 Edge Micro 구성 파일을 수정합니다.

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

독립형 모드에서 Edge Microgateway 실행

Apigee Edge 종속 항목에서 완전히 연결 해제된 Edge Microgateway를 실행할 수 있습니다. 독립형 모드라고 하는 이 시나리오를 사용하면 인터넷 연결 없이 Edge Microgateway를 실행하고 테스트할 수 있습니다.

독립형 모드에서는 Apigee Edge에 연결해야 하므로 다음 기능이 작동하지 않습니다.

OAuth 및 API 키
할당량
애널리틱스

반면 커스텀 플러그인과 급증 방지는 Apigee Edge에 연결할 필요가 없으므로 정상적으로 작동합니다. 또한 extauth라는 새 플러그인을 사용하면 독립형 모드에서 JWT를 사용하여 마이크로게이트웨이에 대한 API 호출을 승인할 수 있습니다.

게이트웨이 구성 및 시작

독립형 모드에서 Edge Microgateway를 실행하려면 다음 안내를 따르세요.

Edge Microgateway 버전 2.5.25 이상이 설치되어 있는지 확인합니다. 그렇지 않으면 다음 명령어를 실행하여 최신 버전으로 업그레이드해야 합니다.
```
npm install -g edgemicro
```
도움이 필요하면 Edge Microgateway 설치를 참조하세요.
$HOME/.edgemicro/org_name-env_name-config.yaml과 같이 구성 파일을 만듭니다.
파일 이름에서 org_name 및 env_name에 원하는 값을 사용할 수 있습니다. 조직/환경 조합은 Edge Microgateway가 시작될 때 파일을 찾을 수 있도록 하는 규칙일 뿐입니다.

예를 들면 다음과 같습니다.
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
다음 코드를 파일에 붙여넣습니다.
```
edgemicro:
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - extauth
      - spikearrest
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
extauth:
  publickey_url: https://www.googleapis.com/oauth2/v1/certs
spikearrest:
  timeUnit: second
  allow: 10
  buffersize: 0
```
구성 파일에는 extauth라는 특별한 선택적 플러그인이 포함되어 있습니다. 이 플러그인은 마이크로게이트웨이에 전달된 유효한 JWT 토큰을 확인합니다. 이후 단계에서 토큰을 가져오고 사용하는 방법을 알아봅니다. 또한 spikearrest 플러그인은 Edge와의 연결에 의존하지 않으므로 포함됩니다. quota, oauth, analytics 플러그인은 Edge와의 연결에 의존하며 연결 해제 모드에서 작동하지 않으므로 제외됩니다. 커스텀 플러그인이 허용되며 예상대로 작동합니다.
값이 '1'인 다음 환경 변수를 내보냅니다.
```
export EDGEMICRO_LOCAL=1
```
다음 start 명령어를 실행하여 로컬 프록시를 인스턴스화하는 값을 제공합니다.
```
edgemicro start -o org_name -e environment_name -a local_proxy_name \
  -v local_proxy_version -t target_url -b base_path
```
각 항목의 의미는 다음과 같습니다.
- your_org은 구성 파일 이름에 사용한 'org' 이름입니다.
- your_environment은 구성 파일 이름에 사용한 'env' 이름입니다.
- local_proxy_name은 생성될 로컬 프록시의 이름입니다. 원하는 이름을 사용할 수 있습니다.
- local_proxy_version는 프록시의 버전 번호입니다.
- target_url은 프록시 대상의 URL입니다. (대상은 프록시가 호출하는 서비스입니다.)
- base_path는 프록시의 기본 경로입니다. 이 값은 슬래시로 시작해야 합니다. 루트 기본 경로의 경우 슬래시만 지정합니다(예: '/').
예를 들면 다음과 같습니다.
```
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
구성을 테스트합니다.
```
curl http://localhost:8000/echo  { "error" : "missing_authorization" }
```
extauth 플러그인이 foo-bar-config.yaml 파일에 있으므로 'missing_authorization' 오류가 발생합니다. 이 플러그인은 API 호출의 승인 헤더에 있어야 하는 JWT를 검증합니다. 다음 섹션에서는 오류 없이 API 호출을 통과시킬 수 있는 JWT를 가져옵니다.

예시: 승인 토큰 가져오기

다음 예시에서는 Apigee Edge(edgemicro-auth/jwkPublicKeys)의 Edge Microgateway JWT 엔드포인트에서 JWT를 가져오는 방법을 보여줍니다. 이 엔드포인트는 Edge Microgateway의 표준 설정 및 구성을 수행할 때 배포됩니다. Apigee 엔드포인트에서 JWT를 가져오려면 먼저 표준 Edge Microgateway 설정을 수행하고 인터넷에 연결되어 있어야 합니다. Apigee 엔드포인트는 예시 목적으로만 사용되며 필수는 아닙니다. 원하는 경우 다른 JWT 토큰 엔드포인트를 사용할 수 있습니다. 이 경우 해당 엔드포인트에 제공된 API를 사용하여 JWT를 가져와야 합니다.

마이크로게이트웨이 구성에 extauth 플러그인을 포함하는 것은 선택사항이지만, 포함하는 경우 API 호출을 위해 승인 헤더에 유효한 JWT 토큰을 제공해야 합니다.

다음 단계에서는 edgemicro-auth/jwkPublicKeys 엔드포인트를 사용하여 토큰을 가져오는 방법을 설명합니다.

Apigee Edge의 조직/환경에 edgemicro-auth 프록시를 배포하려면 Edge Microgateway의 표준 설정 및 구성을 수행해야 합니다. 이전에 이 단계를 수행한 경우 반복할 필요가 없습니다.
Edge Microgateway를 Apigee Cloud에 배포한 경우 이 엔드포인트에서 JWT를 가져올 수 있도록 인터넷에 연결되어 있어야 합니다.
Edge Microgateway를 중지합니다.
```
edgemicro stop
```
이전에 만든 구성 파일($HOME/.edgemicro/org-env-config.yaml)에서 extauth:publickey_url 속성을 Apigee Edge 조직/환경의 edgemicro-auth/jwkPublicKeys 엔드포인트로 가리킵니다. 예를 들면 다음과 같습니다.
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
구성 파일 이름에 사용한 조직/환경 이름을 사용하여 이전에 했던 것처럼 Edge Microgateway를 다시 시작합니다. 예를 들면 다음과 같습니다.
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
승인 엔드포인트에서 JWT 토큰을 가져옵니다. edgemicro-auth/jwkPublicKeys 엔드포인트를 사용하므로 다음 CLI 명령어를 사용할 수 있습니다.
이 단계에서는 인터넷 연결이 필요합니다. 다음 명령어는 Apigee Edge에서 토큰을 가져옵니다. 이 단계를 수행하려면 표준 Edge Microgateway 설정 및 구성을 수행한 Apigee 조직이 있어야 합니다. 이 단계를 완료한 후에는 인터넷에 연결되어 있지 않아도 됩니다. 토큰은 만료될 때까지 독립형 모드에서 계속 작동합니다.

edgemicro token 명령어 또는 API를 사용하여 Edge Microgateway의 JWT를 생성할 수 있습니다. 예를 들면 다음과 같습니다.

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

각 항목의 의미는 다음과 같습니다.

your_org은 이전에 Edge Microgateway를 구성한 Apigee 조직의 이름입니다.
your_env는 조직의 환경입니다.
i 옵션은 edgemicro-auth 프록시가 포함된 제품이 있는 개발자 앱의 고객 키를 지정합니다.
s 옵션은 edgemicro-auth 프록시가 포함된 제품이 있는 개발자 앱의 소비자 보안 비밀을 지정합니다.

이 명령어는 Apigee Edge에 API 호출을 확인하는 데 사용할 수 있는 JWT를 생성하도록 요청합니다.

토큰 생성도 참조하세요.

독립형 구성 테스트

구성을 테스트하려면 다음과 같이 승인 헤더에 추가된 토큰을 사용하여 API를 호출합니다.

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

예:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

출력 예시:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

로컬 프록시 모드 사용

로컬 프록시 모드에서 Edge Microgateway는 Apigee Edge에 마이크로게이트웨이 인식 프록시를 배포할 필요가 없습니다. 대신 마이크로게이트웨이를 시작할 때 로컬 프록시 이름, 기본 경로, 대상 URL을 제공하여 '로컬 프록시'를 구성합니다. 그러면 마이크로게이트웨이에 대한 API 호출이 로컬 프록시의 대상 URL로 전송됩니다. 다른 모든 측면에서 로컬 프록시 모드는 일반 모드에서 Edge Microgateway를 실행하는 것과 동일하게 작동합니다. 인증은 급증 방지, 할당량 적용, 커스텀 플러그인 등과 동일하게 작동합니다.

로컬 모드와 일반 Edge Microgateway 구성의 두 가지 중요한 차이점은 (1) 로컬 모드에서는 Apigee Edge에서 마이크로게이트웨이 인식 프록시를 만들 필요가 없으며 (2) Edge에서 API 제품을 만들 때 프록시를 하나만 추가해야 한다는 점입니다. 바로 edgemicro-auth 프록시입니다. 제품에 다른 프록시를 추가할 필요가 없습니다.

사용 사례 및 예시

로컬 프록시 모드는 단일 프록시를 Edge Microgateway 인스턴스와 연결해야 하는 경우에 유용합니다. 예를 들어 Edge Microgateway를 Kubernetes에 사이드카 프록시로 삽입할 수 있습니다. 여기서 마이크로게이트웨이와 서비스는 각각 단일 포드에서 실행되고 마이크로게이트웨이는 컴패니언 서비스와의 트래픽을 관리합니다. 다음 그림은 Edge Microgateway가 Kubernetes 클러스터에서 사이드카 프록시로 작동하는 아키텍처를 보여줍니다. 각 마이크로게이트웨이 인스턴스는 컴패니언 서비스의 단일 엔드포인트와만 통신합니다.

사이드카로서의 Edgemicro

이러한 아키텍처 스타일의 이점은 Edge Microgateway가 Kubernetes 클러스터와 같은 컨테이너 환경에 배포된 개별 서비스에 API 관리를 제공한다는 것입니다.

로컬 프록시 모드 구성

로컬 프록시 모드에서 실행되도록 Edge Microgateway를 구성하려면 다음 단계를 따르세요.

Edge Microgateway 버전 2.5.25 이상이 설치되어 있는지 확인합니다. 그렇지 않으면 다음 명령어를 실행하여 최신 버전으로 업그레이드해야 합니다.
```
npm install -g edgemicro
```
도움이 필요하면 Edge Microgateway 설치를 참조하세요.
edgemicro init를 실행하여 일반적인 Edge Microgateway 설정과 마찬가지로 로컬 구성 환경을 설정합니다. Edge Microgateway 구성도 참조하세요.
일반적인 Edge Microgateway 설정 절차와 마찬가지로 edgemicro configure를 실행합니다. 예를 들면 다음과 같습니다.
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
이 명령어는 edgemicro-auth 정책을 Edge에 배포하고 마이크로게이트웨이를 시작하는 데 필요한 키와 보안 비밀을 반환합니다. 도움이 필요하면 Edge Microgateway 구성을 참조하세요.
Apigee Edge에서 다음 필수 구성 요구사항을 사용하여 API 제품을 만듭니다(다른 모든 구성은 원하는 대로 관리할 수 있음).
- edgemicro-auth 프록시를 제품에 추가해야 합니다. 이 프록시는 edgemicro configure를 실행할 때 자동으로 배포되었습니다.
- 리소스 경로를 제공해야 합니다. Apigee에서는 이 경로를 제품에 추가하는 것이 좋습니다. /** 자세한 내용은 리소스 경로 동작 구성을 참조하세요. Edge 문서의 API 제품 만들기도 참조하세요.
Apigee Edge에서 개발자를 만들거나 원하는 경우 기존 개발자를 사용할 수 있습니다. 도움이 필요하면 Edge 관리 UI를 사용하여 개발자 추가를 참조하세요.
Apigee Edge에서 개발자 앱을 만듭니다. 방금 만든 API 제품을 앱에 추가해야 합니다. 도움이 필요하면 Edge 관리 UI에서 앱 등록을 참조하세요.
Edge Microgateway가 설치된 머신에서 값이 '1'인 다음 환경 변수를 내보냅니다.
```
export EDGEMICRO_LOCAL_PROXY=1
```
다음 start 명령어를 실행합니다.
```
edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
    -a local_proxy_name -v local_proxy_version -t target_url -b base_path
```
각 항목의 의미는 다음과 같습니다.
- your_org은 Apigee 조직입니다.
- your_environment는 조직의 환경입니다.
- your_key는 edgemicro configure를 실행할 때 반환된 키입니다.
- your_secret는 edgemicro configure를 실행할 때 반환된 보안 비밀입니다.
- local_proxy_name은 생성될 로컬 프록시의 이름입니다.
- local_proxy_version는 프록시의 버전 번호입니다.
- target_url은 프록시 대상의 URL입니다(프록시가 호출할 서비스).
- base_path는 프록시의 기본 경로입니다. 이 값은 슬래시로 시작해야 합니다. 루트 기본 경로의 경우 슬래시만 지정합니다(예: '/').
예를 들면 다음과 같습니다.
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

구성 테스트

프록시 엔드포인트를 호출하여 로컬 프록시 구성을 테스트할 수 있습니다. 예를 들어 기본 경로 /echo를 지정한 경우 다음과 같이 프록시를 호출할 수 있습니다.

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

유효한 API 키를 제공하지 않았기 때문에 이 초기 API 호출에서 오류가 발생했습니다. 이전에 만든 개발자 앱에서 키를 찾을 수 있습니다. Edge UI에서 앱을 열고 고객 키를 복사한 후 다음과 같이 해당 키를 사용합니다.

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

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

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

출력 예시:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}