이 페이지는 Cloud Translation API를 통해 번역되었습니다.

API 개발 수명 주기

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

모든 조직에는 고유한 소프트웨어 개발 수명 주기(SDLC)가 있습니다. 다른 애플리케이션 개발, 테스트, 배포에 사용되는 것과 동일한 프로세스에 API 프록시 배포를 동기화하고 정렬해야 하는 경우가 종종 있습니다.

API 서비스는 API 프록시 배포 및 관리를 조직의 SDLC에 통합할 수 있는 도구와 RESTful API를 제공합니다. RESTful API은 API 프록시를 프로그래매틱 방식으로 배포하는 스크립트나 코드를 작성하거나, 다른 애플리케이션을 배포하거나 이전하는 대규모 자동화 프로세스의 일환으로 API 프록시를 다른 환경으로 마이그레이션하는 스크립트나 코드를 작성하는 용도로 흔히 쓰입니다. API 서비스는 조직의 SDLC(또는 다른 조직의 SDLC)를 가정하지 않습니다. 오히려 개발팀이 조율할 수 있는 원자 함수를 노출하여 API 개발 수명 주기를 자동화하고 최적화합니다.

API 서비스 API는 API 참조에 자세히 설명되어 있습니다. API 참조 시작하기를 참조하세요.

API 환경 및 API 개발 수명 주기에 대한 소개는 이 동영상을 참조하세요.

환경

Apigee Edge의 모든 조직에는 API 프록시에 사용할 수 있는 2개 이상의 배포 환경('test' 및 'prod')이 있습니다. 두 환경의 차이점은 임의적입니다. 각 환경은 단순히 다른 네트워크 주소(URL)로 식별됩니다. 목표는 API가 외부 개발자에게 노출되기 전에 API 프록시를 빌드하고 확인할 수 있는 도메인을 제공하는 것입니다.

이러한 환경을 활용하여 SDLC에서 처리되는 API 프록시 개발을 동기화할 수 있습니다. 각 환경은 네트워크 주소로 정의되므로 작업 중인 API 프록시와 런타임 시 앱에서 액세스하는 API 프록시 간의 트래픽을 구분할 수 있습니다. 각 환경에서 사용 가능한 네트워크 주소는 해당 환경에서 사용할 수 있는 VirtualHosts 집합에 정의되어 있습니다.

인바운드, 서버 TLS/SSL은 환경별로 자동으로 사용 설정됩니다. 각 환경에는 VirtualHost 두 개(default 및 secure)가 사전 정의되어 있습니다. 기본값은 HTTP 주소를 정의하고, 보안은 사전 구성된 서버 측 TLS/SSL을 사용하여 HTTP/S 주소를 정의합니다. API 프록시 구성에서 ProxyEndpoint가 리슨할 VirtualHost를 지정합니다. prod로 승격할 때 일반적으로 API 프록시 구성에서 default VirtualHost를 삭제하여 HTTP를 사용 중지합니다.

예를 들어 다음 ProxyEndpoint는 HTTP 및 HTTPS에서 리슨합니다.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

ProxyEndpoint 구성에서 default VirtualHost를 삭제하면 HTTP가 아닌 HTTPS에서만 리슨하는 API 프록시를 만듭니다.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

관리 UI 기본 메뉴에서 환경을 선택하여 환경에서 사용할 수 있는 VirtualHosts를 확인할 수 있습니다.

환경은 데이터와 리소스의 분리도 제공합니다. 예를 들어 해당 환경에서 실행되는 API 프록시에서만 액세스할 수 있는 테스트 및 prod에서 다른 캐시를 설정할 수 있습니다. 또한 테스트 환경에서 발급되는 API 키는 prod 환경에서 유효하지 않으며 그 반대의 경우도 마찬가지입니다.

환경에 API 프록시 배포

API 프록시를 만들 때는 작업할 환경을 결정해야 합니다. 프로덕션에서 새로운 API 프록시를 만들 수 있지만 API가 준비되기 전에 개발자에게 API를 노출할 수 있으므로 권장하지 않습니다. 일반적으로 test에서 API 프록시를 만들어 테스트한 후 prod로 승격합니다.

참고: 역할에 따라 일부 환경에 배포하지 못할 수도 있습니다. 예를 들어 '사용자' 역할은 test 환경에만 배포할 수 있습니다. 관리자는 모든 환경에 배포할 수 있습니다.

자세한 내용은 배포 이해하기를 참조하세요.

테스트 환경의 반복 개발

API 프록시에서 작업할 때 API 서비스는 구성 반복을 버전으로 저장합니다. API 프록시를 배포할 때 배포할 특정 버전을 선택합니다. 일반적으로 최신 버전을 배포하고 필요한 경우 이전 버전 번호로 되돌립니다. 버전을 배포할 위치를 선택할 수 있습니다. 예를 들어 개발자가 API 작업을 시작할 수 있도록 버전을 prod로 승격할 수 있습니다. 동시에 테스트 시 여러 버전을 반복할 수 있습니다. 여기에서 기능을 추가하거나 정책을 세부 조정할 수 있습니다. 그런 다음 준비가 되면 새 버전을 prod에 배포하여 해당 환경의 기존 버전을 덮어쓸 수 있습니다. 이 방법을 사용하면 개발 중에 항상 개발자에게 API의 라이브 버전을 제공할 수 있습니다.

프로덕션으로의 승격

API 프록시가 완전히 구현되고 테스트되면 'prod'로 승격될 준비가 된 것입니다. 테스트 중인 API 프록시 버전은 prod에 배포된 API 프록시 버전을 덮어쓰는 데 사용됩니다.

API 서비스는 API 프록시의 원활한 배포를 보장하는 기능을 제공하여 배포 절차 중 앱 및 최종 사용자에게 미치는 영향을 최소화합니다.

스크립팅 배포

Apigee Edge 관리 UI를 사용하면 API 프록시 빌더에서 직접 prod에 API 프록시를 배포할 수 있습니다. 그러나 많은 상황에서 보안, 안정성, 일관성에 대한 요구사항에 따라 개발팀은 배포 절차를 스크립트로 작성해야 합니다. 이렇게 하려면 API 서비스에 의해 노출된 RESTful API를 호출하는 코드 및 스크립트를 작성하면 됩니다.

환경 리소스

승격 중에 제어를 강화하려면 테스트 중인 API 프록시를 반복하고 프로덕션에 배포된 API 프록시를 필요에 따라 변경하는 것이 좋습니다.

이렇게 하려면 각 환경과 연결된 특정 리소스가 API 프록시 구성에서 정적 상태를 유지할 수 있도록 구성되어 있는지 확인해야 합니다.

대상 URL: 테스트 및 프로덕션 중에 API 프록시가 다른 백엔드 URL을 호출하는 것이 일반적입니다. TargetServer 구성을 사용하여 환경에 독립적인 TargetEndpoint 구성을 만들 수 있습니다. 백엔드 서버 간 부하 분산을 참고하세요.
캐시 및 키/값 맵: 지속성 리소스 모두 환경별로 범위가 지정됩니다. API 프록시가 승격 중에 구성 변경 없이 데이터를 저장할 수 있도록 이름 지정 규칙을 사용해야 합니다. 환경 캐시 만들기 및 수정을 참고하세요.
ServiceCallout 대상: 테스트 환경의 ServiceCallout이 데모 서비스를 사용하는 경우 환경에 따라 다른 콜아웃을 사용할 수 있습니다. 서비스 콜아웃 정책을 참조하세요.

API 프록시 구성을 환경과 독립적으로 만들려면 조건문을 사용할 수도 있습니다. environment.name 변수를 사용하여 작성된 조건문은 정책을 시행하기 전이나 백엔드의 URL로 라우팅하기 전에 현재 환경을 평가하는 데 사용할 수 있습니다.

자세한 내용은 배포 이해하기를 참조하세요.