Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. info
Apigee Edge proporciona muchos tipos diferentes de recursos, y cada uno tiene un propósito diferente. Existen ciertos recursos que se pueden configurar (es decir, crear, actualizar o borrar) solo a través de la IU de Edge, las APIs de administración o las herramientas que usan APIs de administración, y solo pueden hacerlo los usuarios con los roles y permisos necesarios. Por ejemplo, solo los administradores de organización que pertenecen a una organización específica pueden configurar estos recursos. Esto significa que los usuarios finales no pueden configurar estos recursos mediante portales para desarrolladores ni ningún otro medio. Entre estos recursos, se incluyen los siguientes:
- Proxies de API
- Flujos compartidos
- Productos de API
- Caché
- KVM
- Almacenes de claves y almacenes de confianza
- Hosts virtuales
- Servidores de destino
- Archivos de recursos
Si bien estos recursos tienen acceso restringido, si los usuarios autorizados realizan modificaciones, los datos históricos simplemente se reemplazan por los datos nuevos. Esto se debe a que estos recursos se almacenan en Apigee Edge solo según su estado actual. Las excepciones principales a esta regla son los proxies de API y los flujos compartidos.
Proxies de API y flujos compartidos en control de revisión
Los proxies de API y los flujos compartidos se administran, en otras palabras, se crean, actualizan e implementan, a través de revisiones. Las revisiones están numeradas de forma secuencial, lo que te permite agregar cambios nuevos y guardarlos como una revisión nueva o revertir un cambio mediante la implementación de una revisión anterior del flujo compartido o de proxy de API. En cualquier momento, solo puede haber una revisión de un flujo compartido o de proxy de API implementado en un entorno, a menos que las revisiones tengan una ruta base diferente.
Aunque los proxies de API y los flujos compartidos se administran a través de revisiones, si se realizan modificaciones a una revisión existente, no hay manera de revertir, ya que los cambios anteriores simplemente se reemplazan.
Auditorías e historial
Apigee Edge proporciona las funciones Auditorías y Historial de API, producto y organización, que pueden ser útiles para solucionar problemas. Estas funciones te permiten ver información como quién realizó operaciones específicas (crear, leer, actualizar, borrar, implementar y anular la implementación) y cuándo se realizaron las operaciones en los recursos de Edge. Sin embargo, si se realizan operaciones de actualización o eliminación en cualquiera de los recursos de Edge, las auditorías no pueden proporcionarte los datos más antiguos.
Antipatrón
Administra los recursos de Edge (indicados anteriormente) directamente a través de la IU de Edge o las APIs de administración sin usar el sistema de control de fuente
Existe una idea errónea de que Apigee Edge podrá restablecer los recursos a su estado anterior después de las modificaciones o eliminaciones. Sin embargo, Edge Cloud no proporciona restablecimiento de los recursos a su estado anterior. Por lo tanto, es responsabilidad del usuario asegurarse de que todos los datos relacionados con los recursos de Edge se administren a través de la administración del control del código fuente, de modo que los datos antiguos puedan restablecerse con rapidez en caso de eliminación accidental o situaciones en las que se necesite revertir cambios. Esto es muy importante para los entornos de producción en los que estos datos son necesarios para el tráfico del entorno de ejecución.
Explicaremos esto con algunos ejemplos y el tipo de impacto que podría deberse a que los datos no se administran mediante un sistema de control del código fuente y se modifican o borran de manera intencional o no:
Ejemplo 1: Eliminación o modificación del proxy de API
Cuando se borra un proxy de API o se implementa un cambio en una revisión existente, el código anterior no se podrá recuperar. Si el proxy de API contiene código Java, JavaScript, Node.js o Python que no está administrado en un sistema de administración del control del código fuente (SCM) fuera de Apigee, se podría perder mucho trabajo de desarrollo y esfuerzo.
Ejemplo 2: Determinación de proxies de API con hosts virtuales específicos
Un certificado en un host virtual está vencido y ese host virtual necesita actualizarse. Identificar qué proxies de API usan ese host virtual para fines de prueba puede ser difícil si hay muchos proxies de API. Si los proxies de API se administran en un sistema SCM fuera de Apigee, sería fácil buscar el repositorio.
Ejemplo 3: Eliminación del almacén de claves o almacén de confianza
Si se borra un almacén de claves o almacén de claves que usa un host virtual o configuración de servidor de destino, no podrá restablecerlo a menos que los detalles de configuración del almacén de claves o almacén de confianza, incluidos las claves privadas y/o los certificados se almacenan en el control de código fuente.
Impacto
- Si se borra alguno de los recursos de Edge, no es posible recuperar el recurso y su contenido desde Apigee Edge.
- Las solicitudes a la API pueden fallar con errores inesperados que dan lugar a una interrupción hasta que el recurso se restablece a su estado anterior.
- Es difícil buscar interdependencias entre proxies de API y otros recursos en Apigee Edge.
Práctica recomendada
- Usa cualquier SCM estándar junto con una canalización de integración continua y de implementación continua (CI/CD) para administrar proxies de API y flujos compartidos.
- Usa cualquier SCM estándar para administrar los otros recursos de Edge, incluidos productos de API, cachés, KVM, servidores de destino, hosts virtuales y almacenes de claves.
- Si hay recursos de Edge existentes, usa las APIs de administración para obtener los detalles de configuración como una carga útil de JSON/XML y almacenarlos en la administración del control de código fuente.
- Administra las actualizaciones nuevas de estos recursos en la administración del control de origen.
- Si necesitas crear recursos de Edge nuevos o actualizar recursos de Edge existentes, usa la carga útil JSON/XML adecuada que se almacena en la administración del control de código fuente y actualiza la configuración en Edge con las APIs de administración.
* Las KVM encriptadas no se pueden exportar en texto sin formato desde la API. Es responsabilidad del usuario mantener un registro de los valores que se colocan en KVM encriptados.