Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. 정보
모든 조직에는 고유한 소프트웨어 개발 수명 주기(SDLC)가 있습니다. API 프록시 배포를 백엔드 서비스에 사용되는 프로세스와 동기화하고 조정해야 하는 경우가 많습니다.
이 주제에서 설명하는 Edge API 메서드는 API 프록시 관리를 조직의 SDLC에 통합하는 데 사용할 수 있습니다. 이 API의 일반적인 용도는 API 프록시를 배포하거나 API 프록시를 다른 애플리케이션도 배포하거나 마이그레이션하는 대규모 자동화 프로세스의 일부로 API 프록시를 마이그레이션하는 스크립트나 코드를 작성하는 것입니다.
Edge API는 사용자의 SDLC (또는 그와 관련하여 다른 사람)에 대해 어떠한 가정도 하지 않습니다. API 개발 수명 주기를 자동화하고 최적화하기 위해 개발팀에서 조정할 수 있는 원자적 함수를 제공합니다.
자세한 내용은 Edge API를 참조하세요.
Edge API를 사용하려면 호출에서 본인 인증을 해야 합니다. 다음 방법 중 하나를 사용하면 됩니다.
이 주제에서는 API 프록시 관리를 위한 API 집합에 초점을 맞춥니다.
동영상: API를 배포하는 방법을 알아보려면 이 짧은 동영상을 확인하세요.
API와 상호작용
다음 단계에서는 API와의 간단한 상호작용을 안내합니다.
조직의 API 나열
조직의 모든 API 프록시를 나열하는 것으로 시작할 수 있습니다. (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 프록시 버전을 늘리지 않으려면 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의 모든 조직에는 환경이 2개 이상(test 및 prod) 있습니다. 구분은 임의적입니다. 목표는 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 문서를 보고 있습니다.
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 프록시 버전을 다른 버전 위에 배포할 수 없습니다. 첫 번째는 항상 배포 취소해야 합니다. override를 true로 설정하면 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=true 및 delay 매개변수 집합에서 발생하는 결과입니다.
- 버전 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 |
기본값은 일반적인 배포 동작을 재정의하고 원활한 배포를 제공하려면 |
delay |
배포 취소 전에 기존 버전에서 트랜잭션 처리가 완료되도록 하고 기본값은 0초입니다. |
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이므로 동일한 리소스에 대해 JSON 또는 XML 페이로드와 함께 POST 메서드를 사용하여 API 프록시를 만들 수 있습니다.
API 프록시에 대한 프로필이 생성됩니다. API 프록시의 기본 표현은 자바스크립트 객체 표기법 (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, 자바, 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