Apigee는 다양한 유형의 리소스를 제공하며, 각각 다른 용도로 사용됩니다. Apigee UI, Apigee API, API를 사용하는 도구를 통해서 선행 조건 역할과 권한을 가진 사용자만 구성할 수 있는(생성, 업데이트, 삭제 등) 특정한 리소스가 있습니다. 예를 들어 특정 조직에 속한 조직 관리자만 이러한 리소스를 구성할 수 있습니다. 즉, 이러한 리소스는 개발자 포털을 통해 최종 사용자가 구성할 수 없으며 그 외에 다른 어떤 방법으로도 구성할 수 없습니다. 이러한 리소스는 다음과 같습니다.
API 프록시
공유 흐름
API 제품
캐시
KVMs
키 저장소 및 트러스트 저장소
가상 호스트
대상 서버
리소스 파일
이러한 리소스에는 액세스 권한이 제한되어 있지만, 권한이 있는 사용자가 리소스를 수정하면 수정이 수행된 경우 새로운 데이터가 간단히 이전 데이터를 덮어씁니다. 그 이유는 이러한 리소스가 현재 상태로만 Apigee에 저장되기 때문입니다.
이 규칙의 주된 예외는 API 프록시와 공유 흐름입니다.
버전 제어 환경에서 API 프록시 및 공유 흐름
API 프록시와 공유 흐름은 버전을 통해 관리, 즉 생성, 업데이트, 배포됩니다. 버전 번호는 순차적으로 지정되므로 새 변경사항을 추가하고 새 버전으로 저장하거나 이전 버전의 API 프록시/공유 흐름을 배포하여 변경사항을 되돌릴 수 있습니다. 어떤 버전에 다른 기본 경로가 없는 한, 환경에 배포된 API 프록시/공유 흐름은 어떤 시점에서나 한 가지 버전만 존재할 수 있습니다.
API 프록시와 공유 흐름은 버전을 통해 관리되지만 기존 버전을 수정하면 이전 변경사항을 간단히 덮어쓰므로 롤백할 수 있는 방법이 없습니다.
감사 및 기록
Apigee는 문제 해결 시나리오에 도움이 될 수 있는 감사 기능을 제공합니다. 이러한 기능을 사용하면 특정 작업(만들기, 읽기, 업데이트, 삭제, 배포, 배포 취소)을 수행한 사람과 Apigee 리소스에서 수행된 작업 등의 정보를 볼 수 있습니다. 하지만 Apigee 리소스에 업데이트 또는 삭제 작업이 수행되면, 감사는 이전 데이터를 제공할 수 없습니다.
안티패턴
소스 제어 시스템을 사용하지 않고 Apigee UI 또는 API를 통해 직접 위에 나열된 Apigee 리소스 관리
Apigee는 수정 또는 삭제 후에 이전 상태로 리소스를 복원할 수 있으리라는 오해가 있습니다. 그러나 Apigee는 이전 상태로 리소스를 복원할 수 없습니다. 따라서 Apigee 리소스와 관련된 모든 데이터를 소스 제어 시스템을 통해 관리하는 것은 사용자의 책임입니다. 그래야 실수로 삭제하거나 변경 사항을 롤백해야 하는 경우 이전 데이터를 신속하게 복원할 수 있습니다. 이 데이터가 런타임 트래픽에 필요한 프로덕션 환경에서 이는 특히 중요합니다.
소스 제어 시스템을 통해 데이터를 관리하지 않을 때 의도적으로 또는 의도치 않게 데이터가 수정 또는 삭제되는 경우 발생할 수 있는 상황과 그로 인한 영향을 몇 가지 예시를 들어 설명해 보겠습니다.
예시 1: API 프록시 삭제 또는 수정
API 프록시가 삭제되거나 기존 버전에 변경사항이 배포되면 이전 코드를 복구할 수 없습니다. API 프록시에 Apigee 외부의 소스 제어 관리(SCM) 시스템에서 관리되지 않는 자바, 자바스크립트, Python 코드가 포함된 경우 많은 개발 작업 및 작업이 수포로 돌아갈 수 있습니다.
예시 2: 특정 가상 호스트를 사용한 API 프록시 결정
가상 호스트의 인증서가 만료되어 가상 호스트에 업데이트가 필요합니다. API 프록시가 많으면 테스트 목적으로 해당 가상 호스트를 사용하는 API 프록시를 식별하기 어려울 수 있습니다. Apigee 외부의 SCM 시스템에서 API 프록시를 관리하면 저장소를 쉽게 검색할 수 있습니다.
예시 3: 키 저장소/트러스트 저장소 삭제
가상 호스트 또는 대상 서버 구성에서 사용하는 키 저장소/트러스트 저장소가 삭제되면 인증서나 비공개 키를 포함한 키 저장소/트러스트 저장소의 구성 세부 정보가 소스 제어 시스템에 저장되어 있지 않은 한 복원 할 수 없습니다.
영향
Apigee 리소스가 삭제되면 Apigee에서 리소스와 콘텐츠를 복구할 수 없습니다.
API 요청이 예상치 못한 오류로 인해 실패하여 리소스가 이전 상태로 복원될 때까지 서비스가 중단될 수 있습니다.
Apigee의 API 리소스와 다른 리소스 간의 상호 의존성을 검색하기가 어렵습니다.
권장사항
모든 표준 SCM과 지속적 통합 및 지속적 배포(CICD) 파이프라인을 함께 사용하여 API 프록시와 공유 흐름을 관리하세요.
API 제품, 캐시, KVM, 대상 서버, 가상 호스트, 키 저장소 등 다른 Apigee 리소스를 관리하는 데 표준 SCM을 사용하세요.
기존 Apigee 리소스가 있는 경우 Apigee API를 사용하여 해당 구성의 세부정보를 JSON/XML 페이로드로 가져와 소스 제어 관리에 저장합니다.
소스 제어 관리에서 이러한 리소스의 모든 새 업데이트를 관리합니다.
새 Apigee 리소스를 만들거나 기존 리소스를 업데이트해야 하는 경우 소스 제어 관리에 저장된 적절한 JSON/XML 페이로드를 사용하고 API를 이용해 Apigee의 구성을 업데이트하세요.
* 암호화된 KVM은 API에서 일반 텍스트로 내보낼 수 없습니다. 암호화된 KVM에 저장되는 값에 대한 기록을 유지하는 것은 사용자의 책임입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-30(UTC)"],[[["\u003cp\u003eApigee resources, such as API proxies, shared flows, and KVMs, can only be modified by authorized users through the Apigee UI, APIs, or related tools, and not through developer portals or other means.\u003c/p\u003e\n"],["\u003cp\u003eWhile API proxies and shared flows are managed through revisions, modifications to existing revisions overwrite old changes without a rollback option, and other resources simply update the current data without historical retention.\u003c/p\u003e\n"],["\u003cp\u003eApigee's Audits feature provides information on who performed operations and when, but it does not store older data if resources are updated or deleted, making a separate source control necessary.\u003c/p\u003e\n"],["\u003cp\u003eManaging all Apigee resources, including API proxies and shared flows, in a source control system (SCM) is crucial for data recovery and to avoid potential loss of development work, API request failures, and difficulties in identifying resource interdependencies.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended best practice is to utilize an SCM, often coupled with a CI/CD pipeline, for managing API proxies, shared flows, and other Apigee resources, utilizing Apigee APIs to initially get and subsequently update configurations.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Manage resources without using source control management\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/no-source-control) documentation.*\n\nApigee provides many different types of resources and each of them serve a different\npurpose. There are certain resources that can be configured (i.e., created, updated, and/or\ndeleted) only through the Apigee UI, Apigee APIs, or tools that use APIs, and by\nusers with the prerequisite roles and permissions. For example, only org admins belonging to a\nspecific organization can configure these resources. That means, these resources cannot be\nconfigured by end users through developer portals, nor by any other means. These resources\ninclude:\n\n- API proxies\n- Shared flows\n- API products\n- Caches\n- KVMs\n- Keystores and truststores\n- Virtual hosts\n- Target servers\n- Resource files\n\nWhile these resources do have restricted access, if any modifications are made to them even by\nthe authorized users, then the historic data simply gets overwritten with the new data. This is\ndue to the fact that these resources are stored in Apigee only as per their current state.\nThe main exceptions to this rule are API proxies and shared flows.\n\n#### API Proxies and Shared Flows under Revision Control\n\nAPI proxies and shared flows are managed -- in other words, created, updated and deployed --\nthrough revisions. Revisions are sequentially numbered, which enables you to add new changes and\nsave it as a new revision or revert a change by deploying a previous revision of the API\nproxy/shared flow. At any point in time, there can be only one revision of an API proxy/shared\nflow deployed in an environment unless the revisions have a different base path.\n\nAlthough the API proxies and shared flows are managed through revisions, if any modifications\nare made to an existing revision, there is no way to roll back since the old changes are simply\noverwritten.\n\n#### Audits and History\n\nApigee provides the Audits feature that\ncan be helpful in troubleshooting scenarios. These features enable you\nto view information like who performed specific operations (create, read, update, delete, deploy,\nand undeploy) and when the operations were performed on the Apigee resources. However, if any update\nor delete operations are performed on any of the Apigee resources, the audits cannot provide you the\nolder data.\n\nAntipattern\n-----------\n\n#### Managing the Apigee resources (listed above) directly through Apigee UI or APIs without\nusing source control system\n\nThere's a misconception that Apigee will be able to restore resources to their previous\nstate following modifications or deletes. However, Apigee does not provide restoration of\nresources to their previous state. Therefore, it is the user's responsibility to ensure that all\nthe data related to Apigee resources is managed through source control management, so that old data\ncan be restored back quickly in case of accidental deletion or situations where any change needs\nto be rolled back. This is particularly important for production environments where this data is\nrequired for runtime traffic.\n\nLet's explain this with the help of a few examples and the kind of impact that can be caused if\nthe data in not managed through a source control system and is modified/deleted knowingly or\nunknowingly:\n\n#### Example 1: Deletion or modification of API proxy\n\nWhen an API proxy is deleted, or a change is deployed on an existing revision, the previous code\nwon't be recoverable. If the API proxy contains Java, JavaScript, or Python code that is\nnot managed in a source control management (SCM) system outside Apigee, a lot of development work\nand effort could be lost.\n\n#### Example 2: Determination of API proxies using specific virtual hosts\n\nA certificate on a virtual host is expiring and that virtual host needs updating. Identifying\nwhich API proxies use that virtual host for testing purposes may be difficult if there are many\nAPI proxies. If the API proxies are managed in an SCM system outside Apigee, then it would be easy\nto search the repository.\n\n#### Example 3: Deletion of keystore/truststore\n\nIf a keystore/truststore that is used by a virtual host or target server configuration is\ndeleted, it will not be possible to restore it back unless the configuration details of the\nkeystore/truststore, including certificates and/or private keys, are stored in source control.\n\nImpact\n------\n\n- If any of the Apigee resources are deleted, then it's not possible to recover the resource and its contents from Apigee.\n- API requests may fail with unexpected errors leading to outage until the resource is restored back to its previous state.\n- It is difficult to search for inter-dependencies between API proxies and other resources in Apigee.\n\nBest Practice\n-------------\n\n- Use any standard SCM coupled with a continuous integration and continuous deployment (CICD) pipeline for managing API proxies and shared flows.\n- Use any standard SCM for managing the other Apigee resources, including API products, caches, KVMs, target servers, virtual hosts, and keystores.\n - If there are any existing Apigee resources, then use Apigee APIs to get the configuration details for them as a JSON/XML payload and store them in source control management.\n - Manage any new updates to these resources in source control management.\n - If there's a need to create new Apigee resources or update existing resources, then use the appropriate JSON/XML payload stored in source control management and update the configuration in Apigee using APIs.\n\n\\* Encrypted KVMs cannot be exported in plain text from the API. It is the user's responsibility\nto keep a record of what values are put into encrypted KVMs.\n\nFurther reading\n---------------\n\n- [Source Control for API Proxy Development](https://community.apigee.com/articles/34868/source-control-for-api-proxy-development.html)\n- [Guide to implementing CI on Apigee](https://community.apigee.com/articles/35173/continuous-integration-for-api-proxies.html)\n- [Maven Deploy Plugin for API\n Proxies](https://github.com/apigee/apigee-deploy-maven-plugin)\n- [Maven Config Plugin to manage\n Resources](https://github.com/apigee/apigee-config-maven-plugin)\n- [Apigee APIs (for automating\n backups)](https://apidocs.apigee.com/management/apis)"]]
