API를 사용하여 API 프록시 배포

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

모든 조직에는 고유한 소프트웨어 개발 수명 주기 (SDLC)가 있습니다. 백엔드 서비스에 사용되는 프로세스와 API 프록시 배포를 동기화하고 정렬해야 하는 경우가 종종 있습니다.

이 주제에서 설명하는 Edge API 메서드를 사용하여 API 프록시 관리를 조직의 SDLC에 통합할 수 있습니다. 이 API는 API 프록시를 배포하는 스크립트나 코드 를 작성하거나, 다른 애플리케이션을 배포하거나 마이그레이션하는 대규모 자동화 프로세스의 일환으로 API 프록시를 다른 환경으로 마이그레이션하는 스크립트나 코드를 작성하는 용도로 흔히 쓰입니다.

Edge API는 조직의 SDLC (또는 다른 조직의 SDLC)를 가정하지 않습니다. 오히려 개발팀이 조율할 수 있는 원자 함수를 노출하여 API 개발 수명 주기를 자동화하고 최적화합니다.

자세한 내용은 Edge API를 참조하세요.

Edge API를 사용하려면 호출에서 인증을 받아야 합니다. 다음 방법 중 하나를 사용하여 인증할 수 있습니다:

• OAuth2 (공개 클라우드만 해당)
• SAML (공개 및 비공개 클라우드)
• 기본 인증 (권장하지 않음, 공개 및 비공개 클라우드)

이 주제에서는 API 프록시 관리를 위한 API 집합에 중점을 둡니다.

동영상: API를 배포하는 방법을 알아보려면 이 짧은 동영상을 확인하세요.

API와 상호작용

다음 단계에서는 API와의 간단한 상호작용을 안내합니다.

조직의 API 나열

먼저 조직의 모든 API 프록시를 나열할 수 있습니다. (Remember to substitute entries for EMAIL:PASSWORD 및 ORG_NAME. 자세한 내용은 Edge API 사용을 참조하세요.

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis

샘플 응답:

[ "weatherapi" ]

API 가져오기

조직의 모든 API 프록시에서 GET 메서드를 호출할 수 있습니다. 이 호출은 API 프록시의 사용 가능한 모든 버전 목록을 반환합니다.

curl -u EMAIL:PASSWORD -H "Accept: application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi

샘플 응답:

{
  "name" : "weatherapi",
  "revision" : [ "1" ]
}

이 메서드에서 반환되는 유일한 세부정보는 연결된 번호가 있는 연결된 버전과 함께 API 프록시의 이름입니다. API 프록시는 구성 파일 번들로 구성됩니다. 버전은 반복적으로 구성 업데이트를 관리하는 간단한 메커니즘을 제공합니다. 버전에 순차적으로 번호가 매겨지므로 API 프록시의 이전 버전을 배포하여 변경사항을 되돌릴 수 있습니다. 또한 API 프록시 버전을 프로덕션 환경에 배포하고 테스트 환경에서 API 프록시 버전을 계속 새로 만들 수 있습니다. 준비가 되면 프로덕션 환경의 이전 API 프록시 버전보다 높은 API 프록시 버전을 테스트 환경에서 승격 할 수 있습니다.

이 예시에서는 API 프록시가 방금 생성되었으므로 버전이 하나만 있습니다. API 프록시가 반복적인 구성 및 배포의 수명 주기를 거치면서 버전 번호 가 정수로 증가합니다. 배포를 위해 직접 API 호출을 사용하면 API 프록시의 버전 번호를 선택적으로 늘릴 수 있습니다. 사소한 변경사항을 적용할 때는 버전을 늘리지 않는 것이 좋습니다.

API 버전 가져오기

API 버전 (예: api.company.com/v1)은 매우 드물게 변경되어야 합니다. API 버전을 늘리면 API에서 노출하는 외부 인터페이스의 서명이 크게 변경되었음을 개발자에게 알립니다.

API 프록시 버전 은 API 프록시 구성과 연결된 증가된 숫자입니다. API 서비스는 구성에 문제가 발생할 때 구성을 되돌릴 수 있도록 구성 버전을 유지합니다. 기본적으로 API 프록시 가져오기 API를 사용하여 API 프록시를 가져올 때마다 API 프록시의 버전이 자동으로 증가합니다. API 프록시의 버전을 늘리지 않으려면 업데이트 API 프록시 버전 API를 사용하세요. Maven을 사용하여 배포하는 경우 clean 또는 update 옵션을 사용하세요. Maven plugin readme에 설명되어 있습니다.

예를 들어 API 프록시 버전 1에서 GET 메서드를 호출하여 세부정보를 확인할 수 있습니다.

curl -u EMAIL:PASSWORD -H "Accept:application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1

샘플 응답

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1343178905169,
  "createdBy" : "andrew@apigee.com",
  "lastModifiedAt" : 1343178905169,
  "lastModifiedBy" : "andrew@apigee.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

이러한 API 프록시 구성 요소는 API 프록시 구성 참조에 자세히 설명되어 있습니다.

환경에 API 배포

API 프록시가 요청을 수신하고 전달하도록 구성되면 하나 이상의 환경에 배포할 수 있습니다. 일반적으로 test에서 API 프록시를 반복한 후 준비가 되면 API 프록시 버전을 prod로 승격합니다. 프로덕션 환경에서는 반복을 훨씬 적게 수행하므로 테스트 환경에 API 프록시 버전이 훨씬 더 많다는 것을 알게 될 것입니다.

API 프록시는 환경에 배포되기 전에는 호출할 수 없습니다. API 프록시 버전을 프로덕션에 배포한 후에는 prod URL을 외부 개발자에게 게시할 수 있습니다.

환경을 나열하는 방법

Apigee Edge의 모든 조직에는 test 및 prod라는 두 개 이상의 환경이 있습니다. 구분은 임의적입니다. 목표는 외부 개발자에게 API 프록시를 공개하기 전에 API 프록시 가 제대로 작동하는지 확인할 수 있는 영역을 제공하는 것입니다.

각 환경은 실제로 네트워크 주소일 뿐이므로 작업 중인 API 프록시와 런타임 시 앱에서 액세스하는 API 프록시 간의 트래픽을 구분할 수 있습니다.

환경은 데이터와 리소스의 분리도 제공합니다. 예를 들어 해당 환경에서 실행되는 API 프록시에서만 액세스할 수 있는 테스트 및 프로덕션에서 다른 캐시를 설정할 수 있습니다.

조직의 환경 보기

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments

샘플 응답

[ "test", "prod" ]

배포 살펴보기

배포 는 환경에 배포된 API 프록시의 버전입니다. API 프록시는 배포됨 상태이며 해당 환경의 <VirtualHost> 요소에 정의된 주소에서 네트워크를 통해 액세스할 수 있습니다.

API 프록시 배포

API 프록시는 배포되기 전에는 호출할 수 없습니다. API 서비스는 배포 프로세스를 제어하는 RESTful API 를 노출합니다.

API 프록시의 버전은 한 번에 하나의 환경에만 배포할 수 있습니다. 따라서 배포된 버전을 배포 취소해야 합니다. 새 번들을 새 버전으로 배포할지 아니면 기존 버전을 덮어쓸지 제어할 수 있습니다.

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

먼저 기존 버전을 배포 취소합니다. 배포 취소하려는 API 프록시의 환경 이름과 버전 번호를 지정합니다.

curl -X DELETE \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

그런 다음 새 버전을 배포합니다. API 프록시의 새 버전이 이미 있어야 합니다.

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

원활한 배포 (다운타임 없음)

배포 중 다운타임 가능성을 최소화하려면 배포 메서드에서 override 매개변수 를 사용하고 true로 설정합니다.

API 프록시의 한 버전을 다른 버전 위에 배포할 수 없습니다. 첫 번째 버전은 항상 배포 취소되어야 합니다. override을 true로 설정하면 API 프록시의 한 버전 을 현재 배포된 버전 위에 배포해야 함을 나타냅니다. 결과적으로 배포 순서가 반전됩니다. 새 버전이 배포되고 배포가 완료되면 이미 배포된 버전이 배포 취소됩니다.

다음 예시에서는 양식 매개변수로 전달하여 override 값을 설정합니다.

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \
  -d "override=true" \
  -u EMAIL:PASSWORD

delay 매개변수를 설정하여 배포를 추가로 최적화할 수 있습니다. delay 매개변수는 이전 버전이 배포 취소되기 전의 시간 간격(초)을 지정합니다. 결과적으로 진행 중인 트랜잭션은 트랜잭션을 처리하는 API 프록시가 배포 취소되기 전에 완료할 수 있는 시간 간격이 있습니다. 다음은 override=true 및 delay 매개변수가 설정된 경우 발생하는 상황입니다.

• 버전 1이 요청을 처리합니다.
• 버전 2가 동시에 배포됩니다.
• 버전 2가 완전히 배포되면 새 트래픽이 버전 2로 전송됩니다. 새 트래픽은 버전 1로 전송되지 않습니다.
• 하지만 버전 1은 여전히 기존 트랜잭션을 처리할 수 있습니다. `delay` delay 매개변수 (예: 15초)를 설정하면 버전 1에 기존 트랜잭션 처리를 완료하는 데 15초가 주어집니다.
• 지연 간격 후 버전 1이 배포 취소됩니다.

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \
  -d "override=true" \
  -u EMAIL:PASSWORD

override=true가 delay와 함께 사용되면 배포 중 HTTP 5XX 응답을 삭제할 수 있습니다. 이는 두 API 프록시 버전이 동시에 배포되고 지연 후 이전 버전이 배포 취소되기 때문입니다.

API 버전의 모든 배포 보기

API 프록시의 현재 배포된 모든 버전 목록을 가져와야 하는 경우가 있습니다.

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \
  -u EMAIL:PASSWORD

{
  "aPIProxy" : "weatherapi",
  "environment" : [ {
    "configuration" : {
      "basePath" : "",
      "steps" : [ ]
    },
    "name" : "test",
    "server" : [ {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
    }, {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
    } ],
    "state" : "deployed"
  } ],
  "name" : "1",
  "organization" : "org_name"
}

위의 응답에는 Apigee Edge의 내부 인프라와 관련된 여러 속성이 포함되어 있습니다. Apigee Edge 온프레미스를 사용하지 않는 한 이러한 설정을 변경할 수 없습니다.

응답에 포함된 중요한 속성은 organization, environment, aPIProxy, name, state입니다. 이러한 속성 값을 검토하여 API 프록시의 특정 버전이 환경에 배포되었는지 확인할 수 있습니다.

테스트 환경의 모든 배포 보기

다음 호출을 사용하여 현재 배포된 API 프록시의 버전 번호를 포함하여 특정 환경의 배포 상태를 가져올 수도 있습니다.

curl -u EMAIL:PASSWORD
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments

테스트 환경에 배포된 모든 API에 대해 위와 동일한 결과를 반환합니다.

조직의 모든 배포 보기

모든 환경의 모든 API 프록시에서 현재 배포된 모든 버전 목록을 가져오려면 다음 API 메서드를 사용하세요.

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \
  -u EMAIL:PASSWORD

모든 환경에 배포된 모든 API 프록시에 대해 위와 동일한 결과를 반환합니다.

API는 RESTful이므로 동일한 리소스에 대해 POST 메서드를 사용하기만 하면 JSON 또는 XML 페이로드와 함께 API 프록시를 만들 수 있습니다.

API 프록시의 프로필이 생성됩니다. API 프록시의 기본 표현은 JavaScript 객체 표기법 (JSON)입니다. 아래는 weatherapi라는 API 프록시를 만든 위의 POST 요청에 대한 기본 JSON 응답입니다. 프로필의 각 요소에 대한 설명은 다음과 같습니다.

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1357172145444,
  "createdBy" : "you@yourcompany.com",
  "displayName" : "weatherapi",
  "lastModifiedAt" : 1357172145444,
  "lastModifiedBy" : "you@yourcompany.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

생성된 API 프록시 프로필은 API 프록시의 전체 구조를 보여줍니다.

• APIProxy revision: API 서비스에서 유지관리하는 API 프록시 구성의 순차적으로 번호가 매겨진 반복
• APIProxy name: API 프록시의 고유한 이름
• ConfigurationVersion: API 프록시 구성이 준수하는 API 서비스 버전
• CreatedAt: API 프록시가 생성된 시간(UNIX 시간 형식)
• CreatedBy: API 프록시를 만든 Apigee Edge 사용자의 이메일 주소
• DisplayName: API 프록시의 사용자 친화적인 이름
• LastModifiedAt: API 프록시가 생성된 시간(UNIX 시간 형식)
• LastModifiedBy: API 프록시를 만든 Apigee Edge 사용자의 이메일 주소
• Policies: 이 API 프록시에 추가된 정책 목록
• ProxyEndpoints: 이름이 지정된 ProxyEndpoints 목록
• Resources: 이 API 프록시에서 실행할 수 있는 리소스 (JavaScript, Python, Java, XSLT) 목록
• TargetServers: 부하 분산 목적으로 고급 구성에 사용되는 이름이 지정된 TargetServers 목록 (관리 API를 사용하여 만들 수 있음)
• TargetEndpoints: 이름이 지정된 TargetEndpoints 목록

위의 간단한 POST 메서드를 사용하여 만든 API 프록시 구성의 많은 요소가 비어 있습니다. 다음 주제에서는 API 프록시의 핵심 구성요소를 추가하고 구성하는 방법을 알아봅니다.

API 프록시 구성 참조에서 이러한 구성 요소에 관해 알아볼 수도 있습니다.

API에 대한 스크립팅

GitHub에서 사용할 수 있는 샘플 API 프록시 사용 은 Apigee 배포 도구를 래핑하는 셸 스크립트를 제공합니다. 어떤 이유로든 Python 배포 도구를 사용할 수 없는 경우 API를 직접 호출할 수 있습니다. 두 가지 접근 방식은 아래 샘플 스크립트에 나와 있습니다.

배포 도구 래핑

먼저 로컬 환경에서 Python 배포 도구를 사용할 수 있는지 확인합니다.

그런 다음 사용자 인증 정보를 저장할 파일을 만듭니다. 작성하는 배포 스크립트는 이러한 설정을 가져와 계정의 사용자 인증 정보를 중앙에서 관리하는 데 도움이 됩니다. API 플랫폼 샘플에서 이 파일의 이름은 setenv.sh입니다.

#!/bin/bash

org="Your ORG on enterprise.apigee.com"
username="Your USERNAME on enterprise.apigee.com"

# While testing, it's not necessary to change the setting below
env="test"
# Change the value below only if you have an on-premise deployment
url="https://api.enterprise.apigee.com"
# Change the value below only if you have a custom domain
api_domain="apigee.net"

export org=$org
export username=$username
export env=$env
export url=$url
export api_domain=$api_domain

위의 파일은 배포 도구를 래핑하는 셸 스크립트에서 모든 설정을 사용할 수 있도록 합니다.

이제 이러한 설정을 가져와 배포 도구를 호출하는 데 사용하는 셸 스크립트를 만듭니다. 예시는 Apigee API 플랫폼 샘플을 참조하세요.

#!/bin/bash

source path/to/setenv.sh

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Deploying $proxy to $env on $url using $username and $org

path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy

작업을 정말 쉽게 하려면 다음과 같이 API를 호출하고 테스트하는 스크립트도 만드세요:

#!/bin/bash

echo Using org and environment configured in /setup/setenv.sh

source /path/to/setenv.sh

set -x

curl "http://$org-$env.apigee.net/{api_basepath}"

API 직접 호출

API 프록시의 업로드 및 배포 프로세스를 자동화하는 간단한 셸 스크립트를 작성하는 것이 유용할 수 있습니다.

아래 스크립트는 관리 API를 직접 호출합니다. 업데이트 중인 API 프록시의 기존 버전을 배포 취소하고, 프록시 구성 파일이 포함된 /apiproxy 디렉터리에서 ZIP 파일을 만든 다음 구성을 업로드, 가져오기, 배포합니다.

#!/bin/bash

#This sets the name of the API proxy and the basepath where the API will be available
api=api

source /path/to/setenv.sh

echo Delete the DS_store file on OSX

echo find . -name .DS_Store -print0 | xargs -0 rm -rf
find . -name .DS_Store -print0 | xargs -0 rm -rf

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Undeploy and delete the previous revision

# Note that you need to explicitly update the revision to be undeployed.
# One benefit of the Python deploy tool is that it manages this for you.

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE

curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1"

rm -rf $api.zip

echo Create the API proxy bundle and deploy

zip -r $api.zip apiproxy

echo Import the new revision to $env environment 

curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST

echo Deploy the new revision to $env environment 

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST