Pruebas en producción (API Dry Run)
Equinix Fabric admite una capacidad API Dry Run directamente en el entorno de producción.
La ejecución en seco le permite simular de forma segura las llamadas a API compatibles para verificar las cargas útiles de las solicitudes, la lógica empresarial y la disponibilidad de recursos sin aprovisionar ninguna infraestructura ni incurrir en cargos.
Utilice la ejecución en seco cuando esté validando nuevas integraciones, probando cambios en la automatización o confirmando que una solicitud compleja tendrá éxito antes de ejecutarla "de verdad".
Cómo funciona la ejecución en seco
La ejecución en seco se activa añadiendo un parámetro de consulta como dryRun=true a una solicitud de API compatible.
Cuando el parámetro de ejecución en seco está presente, la plataforma Fabric realiza la validación del lado del servidor únicamente, en lugar de completar toda la transacción. En concreto, la plataforma
- Validar entradas - Compruebe que los campos obligatorios están presentes y correctamente formateados, y que valores como Metros, códigos IBX, ancho de banda y tipos de paquete son válidos.
- Verificar la lógica empresarial - Ejecute comprobaciones externas e internas, como confirmar que un metro, puerto o enrutador de nube está disponible para la operación solicitada.
- Omita la persistencia y el aprovisionamiento - No se crean registros de bases de datos, no se generan órdenes de trabajo y no se reservan, actualizan ni eliminan recursos físicos o lógicos.
Las comprobaciones de autenticación, autorización y cuotas se siguen aplicando de la misma forma que en una llamada en directo.
::::importante La ejecución en seco no omite ningún permiso ni requisito de cuenta. Si su llamada de producción fuera rechazada debido a la falta de derechos o a un estado de cuenta no válido, la llamada de Ejecución en Seco también será rechazada. ::::
Recursos y operaciones compatibles
La ejecución en seco está disponible para recursos y operaciones específicas de Fabric v4.
| Domain / Resource | API Endpoint | Supported Operations |
|---|---|---|
| Cloud Routers | /fabric/v4/routers | Create |
| Connections | /fabric/v4/connections | Create, Update |
| Networks | /fabric/v4/networks | Create |
| Ports | /fabric/v4/ports | Create, Update, Delete |
| Service Tokens | /fabric/v4/serviceTokens | Create, Update |
Para el resto de puntos finales y operaciones, las llamadas que incluyen dryRun=true se comportan como las peticiones de producción estándar.
Comprender las respuestas en seco
La respuesta devuelta por una ejecución en seco está diseñada para reflejar fielmente lo que vería en una llamada de producción en directo, con algunas diferencias importantes.
Validación exitosa
Si la solicitud supera todas las comprobaciones de validación, la API devuelve 200 OK.
- Identificadores de recursos - Campos como
uuidohrefpueden sernullu omitidos, porque en realidad no se crea ningún recurso durante una ejecución en seco. - Números de pedido - No se generan números de pedido ni otros identificadores comerciales.
- Efectos secundarios - No se produce ningún aprovisionamiento, modificación o eliminación de recursos.
Puede utilizar esta respuesta para confirmar que la estructura de su carga útil, los valores y las transiciones de estado solicitadas son aceptables antes de enviar una solicitud en vivo sin dryRun=true.
Errores de validación
Si la solicitud no supera la validación, la API devuelve los mismos códigos de estado HTTP y estructuras de error que devolvería una llamada de producción en directo (por ejemplo, 400 Bad Request para una entrada no válida).
Los fallos típicos de validación incluyen:
- Datos de ubicación no válidos - Un código Metro o IBX no admitido o mal escrito.
- Transiciones de estado de recursos no admitidas - Intento de modificar o eliminar un recurso que se encuentra en un estado transitorio como
PROVISIONING. - Dependencias no satisfechas - Por ejemplo, al intentar eliminar un puerto que todavía tiene conexiones virtuales o tokens de servicio activos asociados a él.
Estos errores se devuelven durante la ejecución en seco sin realizar ningún cambio en los recursos de producción.
Uso de la ejecución en seco con puertos
El punto final /fabric/v4/ports expone un rico comportamiento de validación cuando se utiliza con Dry Run.
Crear puertos
Utilice la operación POST /fabric/v4/ports?dryRun=true cuando envíe una solicitud de creación de ejecución en seco para un puerto:
- La API valida los atributos Metro, IBX y otros atributos de ubicación solicitados.
- Se comprueba la compatibilidad y disponibilidad de las propiedades de paquetes e interfaces (como
interfaceSpeed,bandwidthyencapsulation). - No se reserva ningún puerto físico ni se crea ningún pedido.
::::note La creación masiva de puertos no está soportada a través de la API pública de Fabric. Cada solicitud de creación de funcionamiento en seco debe describir un único puerto. ::::
Actualizar puertos
Utilice la operación PATCH /fabric/v4/ports/{uuid}?dryRun=true para probar de forma segura los cambios de configuración de los puertos antes de aplicarlos:
- Puede validar las actualizaciones de las propiedades descriptivas de un puerto (por ejemplo,
nombre) o atributos de configuración comoencapsulación. - La API aplica reglas de estado: los intentos de actualizar un puerto que se encuentre en un estado transitorio (como
PROVISIONING) devolverán un error. Para la mayoría de las actualizaciones, el puerto debe estar en estado "activo". - También se aplican reglas de dependencia: por ejemplo, no puede cambiar la
encapsulaciónsi el puerto tiene conexiones o perfiles de servicio existentes que quedarían invalidados por el cambio.
No se aplica ningún cambio al puerto durante una ejecución en seco; sólo recibe el resultado de la validación y cualquier mensaje de error asociado.
Borrar puertos
Utilice la operación DELETE /fabric/v4/ports/{uuid}?dryRun=true para validar si una solicitud de eliminación tendría éxito:
- La API comprueba que el puerto existe y se encuentra en un estado que permite su eliminación (normalmente
ACTIVO). - La API garantiza que no haya conexiones activas, tokens de servicio u otros servicios dependientes aún vinculados al puerto.
Si se detecta alguna dependencia, la llamada de borrado en seco devuelve el mismo error que devolvería una solicitud de borrado en vivo, sin eliminar ni modificar el puerto.
Cuándo utilizar la ejecución en seco
Considere la posibilidad de utilizar la ejecución en seco en estos escenarios:
- Antes de desplegar una nueva automatización - Valide que las solicitudes de API generadas son estructuralmente correctas y respetan las reglas de negocio de Fabric.
- Cuando realice pruebas en producción - Confirme que los datos reales de la cuenta (Puertos, Conexiones, Redes, Enrutadores de Nube y Tokens de Servicio) soportan la operación prevista antes de ejecutarla.
- Para la resolución de problemas - Reproduzca escenarios de fallo de forma segura para comprender qué regla de validación o dependencia está bloqueando un cambio.
Tras una ejecución en seco satisfactoria y los ajustes necesarios, puede volver a enviar la misma solicitud sin dryRun=true para realizar la operación real.