Geekly articles weekly

Tutorial de DataPower

Material en coautoría de wedmeed


En 2017, cuando nuestro proyecto comenzó en Vietnam, nos encontramos con la nueva bestia IBM DataPower. IBM DataPower es un producto de puerta de enlace entre clientes y backends diseñado para filtrar, enrutar, enriquecer u otras transformaciones de mensajes que lo atraviesan (en lo sucesivo, las solicitudes). Era necesario aprender rápidamente, no había tiempo para la acumulación, por lo que nos invitaron a familiarizarnos con él, después de lo cual hubo muchas horas de conferencia de Skype con nuestro colega de Moscú, quien nos transmitió su conocimiento y experiencia con este producto.


El autoestudio se basó en estudiar la documentación y mirar videos de capacitación de Internet, y aquí estaba esperando una captura. Prácticamente no pude encontrar información en ruso. Por cierto, mi conocimiento del idioma inglés en ese momento no estaba en el nivel más alto, además fue mi primer proyecto y, probablemente, estos factores complicaron mi vida. Esto me hizo escribir un artículo de capacitación en ruso y de la manera más simple posible para los desarrolladores principiantes que encontraron este producto y están tratando de comprender rápidamente sus conceptos básicos. El artículo no lo liberará de leer la documentación, pero facilitará la vida en las primeras etapas de comprensión de "cómo funciona".


También vale la pena señalar que la estructura dada en la práctica estará cerca del proyecto real, lo que le permitirá usarlo como base, expandiendo y complementando sus requisitos. En conclusión, se darán algunas palabras sobre el proyecto ya implementado, así como algunas características a las que vale la pena prestar atención, en las secciones de Teoría.




Parte 1. Instalación de DataPower con Docker Toolbox


Instala y ejecuta la aplicación Docker Toolbox. Inmediatamente después de comenzar, verá la dirección IP de la máquina, a través de la cual DataPower estará disponible en el futuro:




Para iniciar la imagen, debe cambiar algunas configuraciones de la máquina virtual (relevante para la versión IDG.2018.4.1.0) y reiniciarla:


  1. Detenga la máquina acoplable con el comando:

    docker-machine stop
  2. Sistema -> Placa base -> Memoria principal: mínimo 4096Mb;
  3. Sistema -> Procesador: mínimo 2;
  4. Pantalla -> Pantalla -> Memoria de video: al menos 128Mb;
  5. Lanzamos la máquina acoplable con el comando:

     docker-machine start

    Nota Si se le solicita que reinicie la máquina docker env, ejecute:

     docker-machine env
  6. A continuación, debe desinflar la imagen de IBM DataPower:

     docker pull ibmcom/datapower
  7. Luego, inicie el contenedor docker con el siguiente comando:

     docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower
  8. Después de completar el comando, presione Entrar e ingrese admin / admin como nombre de usuario y contraseña
  9. Para iniciar la Interfaz de administración web, use los comandos:

     co

    y

     web-mgmt 0 9090
  10. Después de todos estos pasos, ejecute en el navegador https://192.168.99.100:9090/

Parte 2. Dominios


2.1. Teoría


Los dominios en DataPower le permiten separar las herramientas de administración y desarrollo, así como proporcionar seguridad.


Después de la instalación, solo hay un dominio predeterminado desde el que se pueden crear dominios de aplicación. Cada dominio tiene su propia configuración de parámetros.


Algunos recursos y parámetros comunes solo se pueden definir en el dominio predeterminado, que incluyen interfaces de red, usuarios y control de acceso, dominios de aplicación y otros.


Un dominio de aplicación es una sección de desarrollo para servicios de procesamiento de solicitudes. Los servicios definidos en él no se pueden compartir con otro dominio de aplicación. Los dominios de aplicación se pueden reiniciar por separado e independientemente, sin la necesidad de un reinicio completo de DataPower.


Puede crear, reiniciar, restablecer, pausar, renovar o eliminar dominios. Puede encontrar información más detallada sobre todas las funciones de administración en la documentación oficial.


Un poco sobre el proyecto completado. Utilizamos 3 dominios:


  • default: el dominio predeterminado que contiene recursos y parámetros compartidos;
  • troncal: el dominio principal que contiene todo lo necesario para procesar solicitudes;
  • configuración: configuración y dominio de seguridad, los archivos locales contienen información sobre las reglas de enrutamiento del servicio y la configuración de seguridad.

La necesidad de transferir todas las configuraciones a un dominio separado surgió en relación con la búsqueda de una ruta de implementación más simple. Como en muchos proyectos, los entornos de desarrollo, prueba y producción se separaron, y la transferencia a un dominio de configuración separado nos permitió instalar todos los dominios principales del entorno de desarrollo en otros entornos a través de la exportación / importación, sin el riesgo de perder la configuración del entorno.


2.2. Practica


  • En el campo de búsqueda, ingrese "dominio", seleccione "Dominio de aplicación" y haga clic en "Agregar"
  • Aquí debe especificar el nombre de dominio, comentar (si lo desea) y activar la auditoría y el registro. Complete los campos y aplique los cambios.
  • Del mismo modo, agregue otro dominio "troncal"
  • Ir a Revisar cambios
  • y guardar la configuración del dominio
  • Puede verificar el estado de los objetos creados yendo al dominio predeterminado en el árbol de navegación en Estado -> Principal -> Estado del objeto
  • Elija Ver por: tipos
  • Busque el dominio de aplicación en la lista y verifique el estado de los objetos: cada uno de ellos debe guardarse, activarse y estar en estado activo. Si es así, continúe con el próximo capítulo.



Parte 3. Administradores de colas


El gestor de colas no es un componente obligatorio de IBM DataPower, pero es a través del ejemplo de MQ que puede mostrar toda la potencia de este producto. Utilizaremos MQ de IBM. Durante las pruebas descritas en el Capítulo 6, necesitaremos enviar un mensaje al gestor de colas local. En este artículo, haré esto usando la utilidad rfhutil, pero puedes usar cualquier método disponible para ti. Para realizar pruebas, deberá crear una conexión desde DP a su gestor de colas local utilizando el gestor de colas MQ.



3.1. Teoría


El gestor de colas proporciona intercambio de datos entre la puerta de enlace y los gestores de colas remotos.


También puede configurar el Grupo MQ Queue Manager, lo que aumentará la tolerancia a fallas del sistema. Esto puede ser útil, por ejemplo, si desea conectar el cliente a cualquiera de los gestores de colas de trabajo y, en algunos casos, lo puede encontrar en la documentación oficial.


Según la experiencia del proyecto, solo se debe tener en cuenta una característica: en un momento queríamos intentar implementar el equilibrio de carga utilizando DataPower, en particular, utilizando grupos de gestores de colas, pero en la práctica no encontramos esa posibilidad. Una solución alternativa es crear un grupo de gestores de colas.



3.2. Practica


3.2.1. Preparación


  1. Instalar WebSphere MQ;
  2. Cree un gestor de colas LOCAL_DP_QM local, accesible en el puerto 3630;
  3. Configurar el canal DP.SVRCONN;

    Al crear un canal, los siguientes comandos pueden serle útiles:


     strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END

  4. Crear las colas DP.IIB.REQIN y DP.IIB.RESIN
  5. Ejecute rfhutil con el nombre del usuario para el que se creó el canal. En la línea Nombre del gestor de colas (para conectarse), escriba:

     DP.SVRCONN/TCT/127.0.0.1(3630)

  6. Intente cargar la lista de nombres de la cola; no debería haber ningún error en la ventana del mensaje. La conexión al canal ha sido verificada.

3.2.2. Crear IBM MQ Queue Manager


  1. Vaya al dominio troncal.
  2. En la búsqueda, escriba MQ, seleccione IBM MQ Queue Manager y haga clic en Agregar.
  3. Debe especificar el nombre (TEST_QM), el nombre de host del gestor de colas, el nombre del gestor de colas y el nombre del canal, así como el tiempo de espera. Configurar y guardar los cambios.


Compruebe el estado del objeto del gestor de colas de forma similar a la comprobación del estado de los dominios. Para hacer esto, seleccione Estado del objeto y el filtro Ver por: tipos del dominio troncal. En la sección "IBM MQ Queue Manager", busque el objeto apropiado y verifique su estado.


Parte 4. Puertas de enlace multiprotocolo


4.1. Teoría


La puerta de enlace multiprotocolo (MPG) es una puerta de enlace multiprotocolo que le permite recibir solicitudes de clientes que usan varios protocolos y luego transferirlas a diferentes servidores usando varios protocolos. El protocolo utilizado por el cliente puede no coincidir con el protocolo utilizado por el servidor de acceso remoto.


En la configuración principal de MPG, puede definir los siguientes componentes:

  • Administrador XML: controla la compilación y el almacenamiento en caché de hojas de estilo (xsl, xslt), el almacenamiento en caché de documentos.
  • Política: consta de reglas, cada una de las cuales define un conjunto de acciones aplicadas al mensaje que pasa por la puerta de enlace.
  • Configuración de la parte frontal y posterior (configuración de URL, tipos de mensajes entrantes y salientes, tiempos de espera y más).

Algunas palabras sobre el proyecto:


El proyecto utiliza 4 puertas de enlace multiprotocolo (enrutamiento, 2 transformadoras para diferentes sistemas finales y una adicional diseñada para recibir archivos del dominio de configuración). El siguiente diagrama muestra el esquema de interacción general:



La cantidad de MPG puede variar según la arquitectura de la solución en su conjunto. En nuestro caso, DataPower enfrenta un bus de integración (IIB) y microservicios, que tienen diferencias significativas en las interfaces (json / http versus xml / mq), por lo que se decidió hacer MPG transformacionales para cada backend específico y nombrarlo en consecuencia. Para todos los clientes, trabajamos en json / http, por lo que el enrutamiento MPG es uno. Los MPG principales consisten en 3 reglas para procesar mensajes: solicitud, respuesta y errores. Cada regla consta de las acciones necesarias, como la transformación, el registro, el enrutamiento y otros.


Desde las características: si en la política usa la acción ConvertQueryParamToXML, esté atento a InputConversion. Si configura la codificación predeterminada en JSON e intenta enviar una solicitud GET, se sorprenderá al descubrir que el mensaje no ha sufrido ninguna transformación que haya especificado y no encontrará ningún rastro de él. Esta característica ayudará a superar la creación de una regla separada para las solicitudes GET.


4.2. Practica


4.2.1 Preparación


Puede encontrar todos los archivos necesarios para trabajar en el enlace https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1. Tronco de dominio


  1. Vaya al dominio troncal.
  2. En el panel de control, seleccione Administración de archivos.
  3. En el directorio local, cree la siguiente estructura de directorio y coloque los archivos correspondientes en él (cada archivo contiene una breve descripción de las funciones que realiza, así como una discusión más detallada de esto más adelante en el artículo).


4.2.1.2. Configuraciones de dominio


  1. Vaya al dominio de configuración.
  2. En el panel de control, seleccione Administración de archivos.
  3. En el directorio local, cree la siguiente estructura de directorio y coloque los archivos apropiados en él (los archivos también contienen una breve descripción de ellos).


4.2.2 Crear GetFileMPG


Primero, cree un MPG auxiliar simple que devolverá archivos del dominio de configuración.


  1. Vaya al dominio de configuración.
  2. En el panel de control, seleccione Puerta de enlace multiprotocolo y haga clic en Crear.
  3. Especifique el nombre (GetFileMPG), la descripción (opcional) y el tipo de back-end (dinámico). De hecho, dado que no habrá llamadas al backend, y solo el archivo será devuelto desde el sistema local, en este ejemplo puede especificar cualquier tipo de backend.

  4. Especifique los tipos de solicitud y respuesta. Especificar explícitamente los tipos reducirá el número de comprobaciones en línea. La especificación del tipo Pass through le permite no crear una regla (en este caso, para transformar la respuesta). Si especificamos que el Tipo de solicitud también se transfiere, no podremos procesar el mensaje de ninguna manera. Esta opción no nos conviene, por lo que restringimos el tipo de solicitud que utiliza no XML.


  5. Haga clic en + y seleccione el controlador HTTP para crear un nuevo protocolo frontal.


  6. Aquí debe especificar un nombre, dirección IP, puerto y una lista de métodos permitidos. Presta atención a la dirección IP. Si especifica 0.0.0.0, todos pueden acceder a esta puerta de enlace. Si 127.0.0.1: solo otras puertas de enlace dentro del mismo DataPower. Como hay parámetros de seguridad entre las configuraciones, utilizamos la segunda opción. Complete los campos y haga clic en "Aplicar", el protocolo se agregará automáticamente a la puerta de enlace.


  7. Haga clic en + para agregar una nueva política.


  8. Complete el nombre de la política "GetFilePolicy".
  9. Cree una nueva regla, complete el nombre y la dirección de la regla. Como realmente no hay backend y solo se devuelve el archivo deseado, solo habrá una regla (cliente a servidor).


  10. Haga doble clic en la acción Coincidir para configurarla, seleccione una regla existente y aplique los cambios. Sería ideológicamente correcto establecer una restricción en la capacidad de recibir solo solicitudes de obtención, pero dentro del marco de la tarea de capacitación, puede seleccionar la existente.
  11. Agregue otra acción: GatewayScript arrastrándolo a la regla y configúrelo. Como transformación, utilizaremos el archivo preparado, que en el sistema de archivos local: /// encontrará el archivo por nombre del URI de la solicitud entrante y lo colocará en el cuerpo del mensaje. El resultado de la operación se transferirá directamente al búfer de salida de la regla. Guarda los cambios.


  12. El resultado final de la política debería verse así:


  13. La creación de MPG está completa, guarde los cambios.
  14. Puede verificar el éxito de su creación utilizando Object Status, similar a verificar el estado de los dominios y el gestor de colas. Para hacer esto, seleccione Estado del objeto y Ver por: filtro de servicios del dominio de configuración. En la sección "Puerta de enlace multiprotocolo", busque el objeto correspondiente y verifique su estado.
  15. No puede llamar a este MPG desde el exterior, ya que lo protegió con ip. Cambie temporalmente la ip de 127.0.0.1 a 0.0.0.0 y el puerto de 7171 a 7170 y ejecute la siguiente consulta:

     curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml"

  16. Debería obtener la siguiente respuesta:


  17. Nuevamente, cambie la ip y el puerto al 127.0.0.1:7171 original.

4.2.3 Creando EnrutamientoMPG


Ahora crea RoutingMPG. Según la solicitud de entrada y las reglas de enrutamiento, determinará dónde y con qué parámetros se debe enviar la solicitud.


  1. Vaya al dominio troncal.
  2. Cree una nueva puerta de enlace multiprotocolo de acuerdo con las cláusulas 2-10 de la sección 4.2.2 utilizando los siguientes valores:
    • 3 - nombre: RoutingMPG, tipo de back-end: Dinámico (para la capacidad de enrutar solicitudes a diferentes MPG si es necesario).
    • 4 - Rq: no xml, Rs: no xml.
    • 6 - nombre: RoutingHTTP_FSH, ip: 0.0.0.0, puerto: 7170, + Método de obtención.
    • 8 - nombre: RoutingPolicy.
    • 9 - nombre: RoutingPolicy_rule_req, dirección: cliente a servidor.

  3. Agregue una acción más para enrutar la solicitud. Para hacer esto, arrastre la acción "Ruta" a la regla, haga doble clic en ella para configurarla, complete los campos y aplique los cambios. El archivo route.xsl recibe el archivo de configuración de enrutamiento del dominio de configuración a través de GetFileMPG creado anteriormente. Después de eso, según el URI, la configuración necesaria para esta operación ya está seleccionada del archivo. Algunos de ellos se utilizan para el enrutamiento, y otros se agregan a los encabezados para su uso en otros MPG. Los parámetros de entrada y salida determinan la forma de trabajar solo con el cuerpo del mensaje y de ninguna manera afectan los encabezados y las variables. Por lo tanto: entrada de nulo, ya que la información del cuerpo del mensaje no se utiliza para el enrutamiento. El resultado es nulo, ya que el resultado de la transformación es solo un cambio en la información del servicio.


  4. Del mismo modo, cree 2 reglas más y guarde todos los cambios:
    • Dirección: Servidor-Cliente, nombre: RoutingPolicy_rule_resp;
      Transformación: Entrada INPUT, Salida NULL, archivo de transformación local: ///RoutingMPG/transform/resp.xslt. El archivo resp.xslt recibe el estado http de la respuesta MPG de transformación y lo establece explícitamente en la respuesta RoutingMPG. Si esto no se hace, el código predeterminado se establecerá en 200, incluso si se produjo un error en la transformación MPG.
    • Dirección: error, nombre: RoutingPolicy_rule_error;
      Transformación: entrada INPUT, salida PIPE (de acuerdo con la documentación, el uso de PIPE entre dos nodos de acción adyacentes ya que INPUT y OUTPUT puede eliminar el procesamiento adicional y reducir la cantidad de memoria utilizada), el archivo de transformación es local: ///RoutingMPG/transform/errors.xsl. El archivo errors.xsl recibe el código de error y el texto de la respuesta de la transformación MPG y genera un mensaje de error JSON en el formato esperado por el cliente.

  5. El resultado final de la política debería verse así:


  6. La creación de MPG está completa, guarde los cambios.
  7. Usando, por ejemplo, la utilidad curl, ejecute la siguiente consulta:

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage"

  8. Si obtiene el siguiente error, todo se hace correctamente. Este error significa que el mensaje se recibió y procesó correctamente, pero el intento de llamar al backend (en este caso, IIBMPG) no tuvo éxito. Ve al siguiente paso.



4.2.4 Creación de IIBMPG


El siguiente paso es crear un MPG transformacional. Supongamos que el sistema externo está en el formato de solicitud JSON y el interno es XML. Necesitamos transformar el mensaje de entrada para que el sistema interno pueda entenderlo. Vale la pena señalar que esto no siempre es una simple conversión de todo el mensaje. A menudo se requiere transmitir un mensaje truncado o aumentado, a veces con una estructura completamente rediseñada.


  1. Vaya al dominio troncal.
  2. Cree una nueva puerta de enlace multiprotocolo de acuerdo con las cláusulas 2-10 de la sección 4.2.2 utilizando los siguientes valores:
    • 3 - nombre: IIBMPG, tipo de servidor: dinámico
    • 4 - Rq: JSON, Rs: XML
    • 6 - nombre: IIBHTTP_FSH, ip: 127.0.0.1 (solo solicitudes del mismo DataPower), puerto: 7172, + método Get
    • 8 - Nombre: IIBPolicy
    • 9 - nombre: IIBPolicy_rule_req, dirección: cliente a servidor

  3. Agrega una descripción. Basado en el X-DP-Transform-Name en los encabezados de solicitud, el archivo IIBRuleRoute.xsl recibe del archivo local: ///IIB/route/IIBRouteRules.xml los nombres de los archivos de transformación, respuesta y error de solicitud para este servicio y establece sus valores a las variables de contexto correspondientes var: // context / IIB / reqTransform, var: // context / IIB / ansTransform, var: // context / IIB / errTransform. Otros valores de encabezados (url, uri, caducar, tiempo de espera) también se colocan en variables de contexto.


  4. Agregue otra acción arrastrando Avanzado a su regla y seleccionando Convertir parámetros de consulta a XML de la lista, configurar. Debe agregar un nuevo mapa de conversión de entrada, dándole un nombre (cmnJSONParseCNVM) y el tipo requerido (JSON).




  5. Agregue la transformación después de la conversión estándar y configúrela. En este caso, la variable establecida en la transformación anterior se usa para indicar el archivo de transformación. Esto se hace para que la transformación sea universal y el archivo en sí mismo se sustituya "sobre la marcha" según el mensaje de entrada. El cuerpo del mensaje está listo. El siguiente paso es enrutar el mensaje, y el cuerpo del mensaje no cambiará, por lo que creamos la variable dpvar_1 y guardamos el resultado en ella. Es a esta variable a la que apuntamos la entrada a la acción Resultados. Guarda los cambios.


  6. Agregue una acción de enrutamiento y establezca los siguientes parámetros. El archivo IIBURLRoute.xsl recibe los valores de las variables de contexto, algunas de ellas se configuran como variables de solicitud de servicio, y del resto forma un URI para la solicitud al sistema de destino, que también se almacena en la variable de servicio.


  7. Del mismo modo, cree 2 reglas más y guarde todos los cambios:
    • Dirección: Servidor-Cliente, nombre: IIBPolicy_rule_resp;
      Transformación: Entrada INPUT, Salida PIPE, archivo de transformación var: // context / IIB / ansTransform (variable de contexto para sustituir la transformación de la respuesta "sobre la marcha").
    • Dirección: Error, nombre: IIBPolicy_rule_error;
      Transformación: entrada NULL, salida PIPE, archivo de transformación var: // context / IIB / errTransform (variable de contexto para sustituir la transformación de error sobre la marcha).

  8. El resultado final de la política debería verse así:

  9. La creación de MPG está completa, guarde los cambios.

Parte 5. Prueba


5.1. Preparación


  1. Descargue, por ejemplo, la utilidad rfhutil para leer y escribir mensajes en la cola;
  2. Los archivos de prueba se encuentran en la carpeta de pruebas del mismo directorio que los archivos del proyecto.

5.2. Control de salud


  1. Envíe la solicitud utilizando la utilidad curl (para la solicitud a continuación, el directorio actual debe ser el mismo que example.json).

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json

  2. Abra 2 instancias de la utilidad rfhutil y reste el mensaje de la cola DP.IIB.REQIN con la primera instancia;
  3. Vaya a la pestaña MQMD y copie el MessageID;
  4. En la segunda instancia, abra el archivo rs.xml, en la pestaña MQMD, inserte el identificador del mensaje en CorrelID y coloque el mensaje en la cola DP.IIB.RESIN;
  5. Deberías obtener una respuesta similar:


  6. Repita los pasos 1-3;
  7. rs_error.xml correllId;




6.


6.1. Teoría


Log Targets , .


Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .


6.2.


  1. trunk;
  2. Log Target ;
  3. :
    • (IIB_LOG);
    • (File);
    • (Text);
    • timestamp(zulu);
    • (logtemp:///IIB.log — IIBMPG);
    • (1000).


  4. . MPG IIBMPG.


  5. , , ( , ).


  6. ;
  7. ;
  8. .
  9. Log Targets MPG.
  10. :
    • , , .


    • .




7. -


  1. – , . – , , - .
  2. . View Logs. , « », « » .
  3. . . MPG Show Probe -> Enable Probe. . , .


  4. , .

– .

Source: https://habr.com/ru/post/442686/

More articles:


All Articles