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

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동
정보

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

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

Edge API는 SDLC (또는 그와 관련하여 다른 사람)에 대해 어떤 가정도 하지 않습니다. 그보다는 개발팀에서 조정하여 API 개발 수명 주기를 자동화하고 최적화할 수 있는 원자적 함수를 노출합니다.

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

Edge API를 사용하려면 호출에서 본인 인증을 해야 합니다. 다음 방법 중 하나를 사용하여 이 작업을 수행할 수 있습니다.

  • OAuth2 (퍼블릭 클라우드만 해당)
  • SAML (퍼블릭 및 프라이빗 클라우드)
  • 기본 인증 (권장되지 않음, 퍼블릭 및 프라이빗 클라우드)

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

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

API와 상호작용

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

조직에서 API 나열

먼저 조직의 모든 API 프록시를 나열합니다. EMAIL:PASSWORDORG_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 프록시 버전을 늘리지 않으려면 Update API 프록시 버전 API를 사용하세요. Maven을 사용하여 배포하는 경우 Maven 플러그인 리드미에 설명된 대로 clean 또는 update 옵션을 사용합니다.

예를 들어 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의 모든 조직에는 최소 두 가지 환경(testprod)이 있습니다. 이러한 구분은 임의적입니다. 목표는 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를 노출합니다.

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

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요.
정보

먼저 기존 버전을 배포 취소하세요. 배포 취소할 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 프록시 버전을 다른 버전 위에 배포할 수 없습니다. 첫 번째는 항상 배포를 취소해야 합니다. overridetrue로 설정하면 현재 배포된 버전 위에 API 프록시 버전 1개를 배포해야 함을 나타냅니다. 그러면 배포 시퀀스가 반대로 됩니다. 즉, 새 버전이 배포되고, 배포가 완료되면 이미 배포된 버전의 배포는 취소됩니다.

다음 예에서는 양식 매개변수로 전달하여 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=truedelay 매개변수 집합에서 발생하는 결과입니다.

  • 버전 1에서 요청을 처리하고 있습니다.
  • 버전 2가 동시에 배포됩니다.
  • 버전 2가 완전히 배포되면 새 트래픽이 버전 2로 전송됩니다. 새 트래픽이 버전 1로 전송되지 않습니다.
  • 하지만 버전 1에서 아직 기존 거래를 처리하는 중일 수 있습니다. 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

기본값은 false입니다 (일반적인 배포 동작: 기존 버전이 배포되지 않은 후 새 버전이 배포됨).

일반적인 배포 동작을 재정의하고 원활한 배포를 제공하려면 true로 설정합니다. 새 버전도 배포되는 동안 기존 버전은 배포된 상태로 유지됩니다. 새 버전이 배포되면 이전 버전은 배포 취소됩니다. 배포 취소가 발생하는 시기를 제어하려면 delay 매개변수와 함께 사용합니다.

delay

배포 취소 전에 기존 버전에서 트랜잭션 처리가 완료되도록 하고 502 Bad Gateway 또는 504 Gateway Timeout errors의 가능성을 없애려면 이 매개변수를 배포 취소를 지연하려는 시간(초)으로 설정합니다. 설정 가능한 시간(초)에는 제한이 없으며 초를 크게 설정해도 성능에 미치는 영향도 없습니다. 지연 시간 동안에는 새 트래픽이 이전 버전으로 전송되지 않습니다.

기본값은 0초입니다. override이 true로 설정되고 delay이 0이면 새 버전이 배포된 직후에 기존 버전이 배포 취소됩니다. 음수 값은 0초로 취급됩니다.

override=truedelay와 함께 사용하면 배포 중 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이므로 동일한 리소스에 JSON 또는 XML 페이로드와 함께 POST 메서드를 사용하여 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: 이름이 지정된 ProxyEndpoint 목록
  • Resources: 이 API 프록시에서 실행할 수 있는 리소스 (JavaScript, Python, Java, XSLT) 목록
  • TargetServers: 부하 분산 목적으로 고급 구성에서 사용되는 이름이 지정된 TargetServer (관리 API를 사용하여 만들 수 있음) 목록
  • TargetEndpoints: 이름이 지정된 TargetEndpoint 목록

위의 간단한 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