Tutorial: Alta disponibilidad para gateways de API en entornos multinube e híbridos

NGINX | 20 de diciembre de 2022

Las implementaciones multicloud han llegado para quedarse. Según el informe de F5 «State of Application Strategy in 2022», el 77 % de las empresas ejecuta aplicaciones en varias nubes. La adopción de arquitecturas multicloud e híbridas aporta importantes ventajas, como una mayor eficiencia, un menor riesgo de interrupciones y la posibilidad de evitar la dependencia de un proveedor. Sin embargo, estas complejas arquitecturas también plantean desafíos específicos.

Los responsables de software y TI encuestados por F5 señalaron los siguientes como sus principales retos en entornos multicloud:

  • Visibilidad (45 % de los encuestados)
  • Seguridad (44 %)
  • Migración de aplicaciones (41 %)
  • Optimización del rendimiento (40 %)

La gestión de las API para microservicios en entornos multinube es especialmente compleja. Sin una estrategia integral de API, estas proliferan en entornos de nube pública, locales y perimetrales más rápido de lo que los equipos de operaciones de plataforma pueden protegerlas y gestionarlas. A este problema lo denominamos «proliferación de API» y, en una publicación anterior, explicamos por qué supone una amenaza tan importante.

Necesita una estrategia de API multinube que le permita adoptar un enfoque bien planificado para unificar sus microservicios —ahora distribuidos entre varias nubes— y garantizar la conectividad de extremo a extremo. Dos de los escenarios habituales para las implementaciones multinube e híbridas son:

  • Servicios diferentes en entornos multinube/híbridos – Debe operar distintas aplicaciones y API en diferentes ubicaciones, ya sea para optimizar los costes o porque cada servicio resulta relevante para distintos grupos de usuarios.
  • Los mismos servicios en entornos multinube/híbridos – Debe garantizar la alta disponibilidad de las mismas aplicaciones implementadas en distintas ubicaciones.

En el siguiente tutorial mostramos paso a paso cómo utilizar API Connectivity Manager, que forma parte de F5 NGINX Management Suite, en el segundo escenario: implementar los mismos servicios en varios entornos para garantizar una alta disponibilidad. Esto elimina los puntos únicos de fallo en su entorno de producción multinube o híbrido: si una instancia de puerta de enlace falla, otra toma el relevo y sus clientes no sufren ninguna interrupción, aunque uno de los servicios en la nube deje de estar disponible.

API Connectivity Manager es una solución nativa de la nube e independiente del entorno de ejecución para implementar, gestionar y proteger API. Desde un único panel, puede gestionar todas las operaciones de sus API para las puertas de enlace de API de NGINX Plus y los portales para desarrolladores implementados en entornos de nube pública, locales y perimetrales. Esto proporciona a sus equipos de operaciones de plataforma una visibilidad completa del tráfico de las API y facilita la aplicación de políticas coherentes de gobernanza y seguridad en todos los entornos.

Habilitación de la alta disponibilidad para puertas de enlace de API en una implementación multinube

Como se menciona en la introducción, en este tutorial configuramos API Connectivity Manager para garantizar la alta disponibilidad de los servicios que se ejecutan en varios entornos de implementación. En concreto, implementamos NGINX Plus como una puerta de enlace de API que dirige el tráfico a dos servicios: Servicio A y Servicio B, que se ejecutan en dos nubes públicas, Google Cloud Platform (GCP) y Amazon Web Services (AWS). (La configuración se aplica igualmente a cualquier combinación de entornos de implementación, incluidos Microsoft Azure y los centros de datos locales).

La figura 1 muestra la topología utilizada en el tutorial.

Topología con un cliente que accede a puertas de enlace de API de alta disponibilidad implementadas en dos nubes
Figura 1: API Connectivity Manager permite el despliegue de alta disponibilidad en varias nubes de puertas de enlace de API y servicios

Sigue los pasos de estas secciones para completar el tutorial:

Instalar y configurar API Connectivity Manager

  1. Obtenga una suscripción de prueba o de pago a NGINX Management Suite, que incluye Instance Manager y API Connectivity Manager, además de NGINX Plus como puerta de enlace de API y NGINX App Protect para proteger sus API. Empiece con una prueba gratuita de 30 días de NGINX Management Suite.
  2. Instale NGINX Management Suite. En la sección Instalar módulos de Management Suite, siga las instrucciones para API Connectivity Manager (y, opcionalmente, para otros módulos).
  3. Añada la licencia para cada módulo instalado.
  4. (Opcional.) Configure la terminación TLS y mTLS, para proteger, respectivamente, las conexiones de los clientes con NGINX Management Suite y el tráfico entre API Connectivity Manager y las instancias de NGINX Plus en el plano de datos.

Implementar instancias de NGINX Plus como puertas de enlace de API

Seleccione los entornos que conforman su infraestructura multinube o híbrida. Para este tutorial, hemos elegido AWS y GCP e instalaremos una instancia de NGINX Plus en cada nube. En cada entorno, siga estos pasos en cada host del plano de datos que vaya a actuar como puerta de enlace de API:

  1. Instale NGINX Plus en un sistema operativo compatible.
  2. Instale el módulo JavaScript de NGINX (njs).
  3. Añada las siguientes directivas en el contexto principal (de nivel superior) de /etc/nginx/nginx.conf:
load_module modules/ngx_http_js_module.so;load_module modules/ngx_stream_js_module.so;
  1. Reinicie NGINX Plus, por ejemplo, ejecutando este comando:
$ nginx -s reload

Configurar un espacio de trabajo de infraestructura

Puede crear varios espacios de trabajo de infraestructura (hasta 10 en el momento de redactar este documento) en API Connectivity Manager. Los espacios de trabajo independientes permiten aplicar políticas y requisitos de autenticación/autorización específicos para distintas líneas de negocio, equipos de desarrolladores, socios externos, nubes, etc.

En la interfaz gráfica de API Connectivity Manager, cree un nuevo espacio de trabajo:

  1. Haga clic en «Infraestructura» en la columna de navegación izquierda.
  2. Haga clic en el botón + Crear para crear un nuevo espacio de trabajo, como se muestra en la figura 2.
    Figura 2: Creación de un nuevo espacio de trabajo de infraestructura
  3. En el panel Crear espacio de trabajo que se abre, rellene el campo Nombre (demo en la figura 3). Si lo desea, rellene el campo Descripción y los campos de la sección Información de contacto del espacio de trabajo. El administrador de la infraestructura (por ejemplo, su equipo de Operaciones de Plataforma) puede utilizar la información de contacto para informar a los usuarios del espacio de trabajo sobre el estado o cualquier incidencia.
    Figura 3: Asignación de un nombre a un nuevo espacio de trabajo de infraestructura y adición de información de contacto
  4. Haz clic en Crear botón.

Crear un entorno y clústeres de API Gateway

En API Connectivity Manager, un entorno es una agrupación lógica de recursos dedicados (como puertas de enlace de API o portales para desarrolladores de API). Puede crear varios entornos por espacio de trabajo (hasta 25 en el momento de redactar este documento); normalmente se corresponden con distintas fases del desarrollo y despliegue de aplicaciones, como la programación, las pruebas y la producción, pero pueden utilizarse para cualquier fin que desee.

Dentro de un entorno, un clúster de puertas de enlace de API es una agrupación lógica de instancias de NGINX Plus que actúan como puertas de enlace de API. Un mismo entorno puede tener varios clústeres de puertas de enlace de API que compartan el mismo nombre de host (por ejemplo, api.nginx.com, como en este tutorial). Las instancias de NGINX Plus de un clúster de puertas de enlace de API pueden estar ubicadas en más de un tipo de infraestructura, por ejemplo, en varias nubes.

Hay dos formas de configurar un entorno en API Connectivity Manager para proporcionar alta disponibilidad activo-activo a las puertas de enlace de API:

El motivo principal para implementar varios clústeres de API Gateway es poder aplicar un conjunto diferente de políticas de seguridad a cada clúster.

En Implementar instancias de NGINX Plus como puertas de enlace de API, implementamos dos instancias de NGINX Plus: una en AWS y otra en GCP. En el tutorial se utilizan las mismas instancias para ilustrar ambos tipos de entorno (con un único clúster de puertas de enlace de API o con varios clústeres de puertas de enlace de API); si desea implementar ambos tipos de entorno en un único espacio de trabajo, deberá crear instancias adicionales de NGINX Plus para el segundo entorno.

Implementar un entorno con un clúster de puerta de enlace de API

Para un entorno con un único clúster de API Gateway, se aplican las mismas políticas de seguridad a todas las instancias de puerta de enlace de API de NGINX Plus, como se muestra en la figura 4.

Diagrama que muestra cómo se aplican las mismas políticas de seguridad a las puertas de enlace de API implementadas en un único clúster de API Gateway en API Connectivity Manager
Figura 4: Las mismas políticas de seguridad se aplican a las puertas de enlace de API implementadas en un único clúster de puertas de enlace de API

Crear un entorno y un clúster de API Gateway
  1. Vaya a su espacio de trabajo y haga clic en el botón Crear entorno, como se muestra en la figura 5.
    Figura 5: Creación de un nuevo entorno en un espacio de trabajo de infraestructura
  2. En el panel Crear entorno que se abre, rellene el campo Nombre (prod en la figura 6) y, opcionalmente, el campo Descripción, y seleccione el tipo de entorno (en este caso, elegimos Producción).
    Figura 6: Asignación de un nombre a un nuevo entorno y de un clúster de puerta de enlace de API
  3. En la sección Clústeres de API Gateway, rellene los campos Nombre y Nombre de host (api-cluster y api.nginx.com en la figura 6).
  4. Haga clic en el botón «Crear». Se abrirá el panel «Entorno creado», que mostrará el comando que debe ejecutar en cada instancia de NGINX Plus para asignarla al clúster de puerta de enlace de API. Para mayor comodidad, mostramos los comandos en el paso 7 que aparece a continuación.
Asignar instancias de API Gateway a un clúster de API Gateway

Repita el proceso en cada instancia de NGINX Plus:

  1. Usa ssh para conectarte e iniciar sesión en la instancia.
  2. Si NGINX Agent ya se está ejecutando, deténgalo:
$ systemctl stop nginx-agent
  1. Ejecute el comando que prefiera (ya sea curl o wget) para descargar e instalar el paquete de NGINX Agent:
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. o
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. Las instancias de NGINX Plus aparecen ahora en la sección Instancias de la ventana Clúster de api-cluster, como se muestra en la figura 7.
    Figura 7: Un único clúster de API Gateway agrupa instancias de NGINX Plus implementadas en varias nubes
    • Si no habilitó mTLS en «Instalar y configurar API Connectivity Manager», añada lo siguiente:
      • La opción «‑k» del comando «curl»
      • La opción --no-check-certificate del comando wget command
    • Para <NMS_FQDN>, introduzca la dirección IP o el nombre de dominio completo de su servidor de NGINX Management Suite.
    • Para <cluster_name>, sustituya el nombre del clúster de API Gateway (api-cluster en este tutorial).
  2. Continúe con «Aplicar políticas globales».

Desplegar un entorno con varios clústeres de API Gateway

En un entorno con varios clústeres de API Gateway, se pueden aplicar distintas políticas de seguridad a diferentes instancias de puerta de enlace de API de NGINX Plus, como se muestra en la figura 8.

Diagrama que muestra cómo se pueden aplicar distintas políticas de seguridad a las puertas de enlace de API implementadas en clústeres de API Gateway independientes en API Connectivity Manager
Figura 8: Se pueden aplicar distintas políticas de seguridad a las puertas de enlace de API implementadas en
clústeres de puerta de enlace de API independientes

Crear un entorno y un clúster de API Gateway
  1. Vaya a su espacio de trabajo y haga clic en el botón Crear entorno, como se muestra en la figura 9.
    Figura 9: Creación de un nuevo entorno en un espacio de trabajo de infraestructura
  2. En el panel Crear entorno que se abre, rellene el campo Nombre (prod en la figura 10) y, opcionalmente, el campo Descripción, y seleccione el tipo de entorno (en este caso, elegimos Producción).
    Figura 10: Asignación de un nombre a un nuevo entorno y del primer clúster de API Gateway a dicho entorno
  3. En la sección «Clústeres de API Gateway», rellene los campos «Nombre» y «Nombre de host» (en la figura 10, son «aws-cluster» y «api.nginx.com»).
  4. Haga clic en el botón «Crear». Se abrirá el panel «Entorno creado», que muestra el comando que debe ejecutar en cada instancia de NGINX Plus para asignarla al clúster de API Gateway. Para mayor comodidad, mostramos los comandos en el paso 10 que aparece a continuación.
  5. Vuelva a la pestaña Entorno y haga clic en el botón + Añadir situado en la esquina superior derecha de la sección Clústeres de API Gateway, como se muestra en la figura 11.
    Figura 11: Adición de otro clúster de API Gateway a un entorno
  6. En el panel Crear clúster de API Gateway, introduzca en el campo Nombre el nombre del segundo clúster (gcp-cluster en la figura 12) y, en el campo Nombre de host, el mismo nombre de host que para el primer clúster (api.nginx.com).
    Figura 12: Adición del segundo clúster de API Gateway a un entorno

Los dos clústeres de API Gateway aparecen ahora en Clústeres de API Gateway para el entorno Prod, como se muestra en la figura 13.

Figura 13: Lista de instancias de NGINX Plus implementadas en varias nubes y en clústeres de API Gateway independientes

Asignar instancias de API Gateway a un clúster de API Gateway

Repita el proceso en cada instancia de NGINX Plus:

  1. Usa ssh para conectarte e iniciar sesión en la instancia.
  2. Si NGINX Agent ya se está ejecutando, deténgalo:
$ systemctl stop nginx-agent
  1. Ejecute el comando que prefiera (ya sea curl o wget) para descargar e instalar el paquete de NGINX Agent:
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. o
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. La instancia de NGINX Plus correspondiente aparece ahora en la sección Instancias de las ventanas de Clúster de aws‑cluster (Figura 14) y gcp‑cluster (Figura 15).
    Figura 14: El primero de los dos clústeres de puerta de enlace de API de un entorno que abarca varias nubes
    Figura 15: El segundo de los dos clústeres de puerta de enlace de API de un entorno que abarca varias nubes Aplicar políticas globales Ahora puede añadir políticas globales que se apliquen a todas las instancias de NGINX Plus de un clúster de puerta de enlace de API. Por ejemplo, para proteger el acceso de los clientes a sus API, puede aplicar la política Parte de confianza de OpenID Connect o TLS entrante. Para proteger la conexión entre una puerta de enlace de API y el servicio de backend que expone la API, aplique la política TLS de backend. Para obtener más información sobre las políticas de TLS, consulte la documentación de API Connectivity Manager. Conclusión Gestionar arquitecturas multinube e híbridas no es tarea fácil. Son entornos complejos con aplicaciones que cambian rápidamente y que, a menudo, son difíciles de supervisar y proteger. Sin embargo, con las herramientas adecuadas, puede evitar la dependencia de un proveedor y, al mismo tiempo, conservar la agilidad y la flexibilidad necesarias para lanzar nuevas funcionalidades al mercado con mayor rapidez. Como herramienta nativa de la nube, API Connectivity Manager de NGINX le ofrece la escalabilidad, la visibilidad, la gobernanza y la seguridad que necesita para gestionar API en entornos multinube e híbridos. Inicie una prueba gratuita de 30 días de NGINX Management Suite, que incluye acceso a API Connectivity Manager, NGINX Plus como puerta de enlace de API y NGINX App Protect para proteger sus API.
    • Si no habilitó mTLS en «Instalar y configurar API Connectivity Manager», añada lo siguiente:
      • La opción ‑k del comando curl command
      • La opción --no-check-certificate del comando wget command
    • Para <NMS_FQDN>, introduzca la dirección IP o el nombre de dominio completo de su servidor de NGINX Management Suite.
    • Para <cluster_name>, sustituya el nombre del clúster de API Gateway correspondiente (en este tutorial, aws‑cluster para la instancia implementada en AWS y gcp‑cluster para la instancia implementada en GCP).
  1. Vaya a la pestaña Clúster de la puerta de enlace de API en la que desea aplicar una política (api-cluster en la Figura 16). Haga clic en el botón Administrar situado sobre la esquina superior derecha de la tabla de Políticas.
    Figura 16: Gestión de políticas de un clúster de puerta de enlace de API
  2. Haga clic en Políticas globales en la columna de navegación de la izquierda y, a continuación, en el icono … situado en la columna del extremo derecho de la fila de la política (Backend TLS en la Figura 17). Seleccione + Añadir política en el menú desplegable.
    Figura 17: Adición de una política global a un clúster de API Gateway


Compartir

Sobre el autor

Akash Ananthanarayanan
Akash AnanthanarayananResponsable de marketing técnico | F5 NGINX

Más artículos de Akash Ananthanarayanan

Artículos relacionados del blog

Únete a F5 NGINX en AppWorld 2024
NGINX | 04/01/2024

Únete a F5 NGINX en AppWorld 2024

Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
NGINX | 26/09/2023

Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source

La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.

Exposición de APIs en Kubernetes
NGINX | 10/03/2022

Exposición de APIs en Kubernetes

La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
NGINX | 23/08/2021

NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto

Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.

Presentamos NGINX Plus R22
NGINX | 09/06/2020

Presentamos NGINX Plus R22

NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.

Presentamos NGINX Plus R17
NGINX | 11/12/2018

Presentamos NGINX Plus R17

NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.