1/29

Anexo I - Arquitectura Solución Liferay IZFE INTRODUCCIÓN

DIMENSIONAMIENTO

Análisis de la carga actual

Conclusiones del análisis de carga

VISIÓN DE LA PLATAFORMA COMPLETA A FUTURO

Justificación de los Componentes

Indexación

Almacenamiento

Proxy Inverso

Gestión de Identidades

Single Sign On (SSO)

Crawler

RETOS DE ARQUITECTURA EN LIFERAY

Instancias

Staging

Seguridad en las Plantillas de contenidos y similares

Certificados SSL

Despliegue controlado de Hot-Fixes de Liferay

REQUISITOS

ESCENARIOS PLATAFORMA LIFERAY

ESCENARIO 1: 1 SERVICIO LIFERAY PARA TODO

Entornos

Servidores soporte iniciales

Retos de la Arquitectura

ROADMAP IMPLANTACIÓN

FASE I: Habilitar Infraestructura Liferay

FASE II: Validar/parchear/solucionar problemas detectados

FASE III: Migrar framework actual

FASE IV: Publicación del entorno en producción

FASE V: Migraciones de Sites

ESCENARIO 2: SERVICIOS PÚBLICO - INTRANET

Entornos

Entorno Público

Entorno Intranets

Servidores soporte iniciales

Retos de la Arquitectura

2/29

ROADMAP LIFERAY

FASE I.A: Habilitar Infraestructura Liferay Pública

FASE II.A: Validar/parchear/solucionar problemas detectados

FASE I.B: Habilitar Infraestructura Liferay para Intranets

FASE II.B: Validar/parchear/solucionar problemas detectados

FASE III.A: Migrar framework actual

FASE III.B: Desarrollar framework para Intranets

FASE IV: Publicación de los entornos en producción

FASE V: Migraciones de Sites

SELECCIÓN ESCENARIO - RECOMENDACIÓN

OTROS SERVICIOS

ROADMAP CRAWLER & SSO

ROADMAP SSO - GESTIÓN DE IDENTIDADES

NOTAS CLOUD

ADJUNTOS

Servidores Liferay Actuales

3/29

INTRODUCCIÓN Este documento sirve de base para la evolución de la plataforma de portales de IZFE basada en Liferay y describe la arquitectura deseable para dicha plataforma. Además, este documento describe las tareas a realizar para llegar a implantar dicha arquitectura. Actualmente Liferay ya está implantado en IZFE sobre la versión 6.2 EE, dando soporte a los portales públicos de la diputación y los ayuntamientos de gipuzkoa. Es importante mencionar que la versión actual de Liferay (6.2 EE) fue lanzada en 2014. Teniendo en cuenta que liferay ofrece 4 años de soporte para sus versiones EE, ello quiere decir que para 2018 el liferay 6.2 actual saldrá de soporte. Este documento se plantea por lo tanto sobre la versión de Liferay DXP Digital Enterprise 7.0 SP1 (Liferay 7.0 EE), y no sobre la versión 6.2 EE implantada actualmente en IZFE. Liferay 7 incorpora muchas novedades, sobre todo en su organización interna. Es por ello que se ve necesario, a pesar de tener ya una experiencia con versiones anteriores de liferay, de testear las características (nuevas y sobre todo las ya existentes) que puedan interesar, como son:

● Clustering: Poder incrementar el rendimiento de la plataforma si se empieza a notar una sobrecarga en el sistema o habilitar la alta disponibilidad si en algún momento se requiere (p.e. publicación a través del portal de procesos sensibles de hacienda).

● Staging: Poder establecer un entorno de edición independiente del entorno de publicación. ● Instancias: Poder trabajar con instancias independientes para independizar espacios a todos los

niveles (ayuntamientos, etc.). Ya que el objetivo es implantar una plataforma que dé soporte a las webs albergadas en IZFE, lo primero que se debe hacer es dimensionar la carga que existe sobre las plataformas actuales y cuál será el objetivo a futuro. Se presentará una visión de cómo se debe implantar Liferay, integrado con otros componentes, algunos de ellos siguiendo recomendaciones propias de Liferay. Esta visión es independiente de cómo se ejecute o cómo se implante la plataforma y debe tenerse en cuenta en todo momento. Aunque se deben trabajar en todos los componentes presentados en dicha visión, este documento se centra específicamente en la parte de la plataforma Liferay. A continuación se describen, en base al contexto de IZFE, los retos principales relacionados con toda la plataforma en los que habrá que trabajar y los requisitos en base a los cuales se deben tomar las decisiones. Ahora ya solo queda presentar los distintos escenarios arquitecturales previstos y seleccionar una plataforma específica. Para cada escenario, se detalla la arquitectura requerida y el proceso en fases para su implantación.

4/29

DIMENSIONAMIENTO Con el objetivo de dimensionar la plataforma se ha realizado un análisis de la carga actual (2016) y del número de peticiones recibidas con el objetivo de poder extrapolarlas a la nueva plataforma.

Análisis de la carga actual En esta sección se presentan los datos capturados usando el Google Analitics de las Webs de la diputación. 1er ejemplo

2º ejemplo

5/29

3 er ejemplo

4º ejemplo

5º ejemplo

6/29

6º ejemplo

7º ejemplo

Conclusiones del análisis de carga Como vemos, podemos establecer que en el uso durante 2016 se ven picos de hasta unas 30000 peticiones diarias combinando las distintas webs. Cuando analizamos uno de los días de más utilización con más detalle, vemos que dichos picos llegan a 2000 peticiones a la hora. Esto puesto en cifras que podamos medir más fácilmente implica que estamos por debajo de 1 petición/segundo. Esto nos da una idea del tráfico, sobre todo público, que la plataforma debe soportar. Con el objetivo que tiene la plataforma de crecer, podemos establecer el requisito de número de páginas públicas servidas por segundo se establezca en 10 peticiones/segundo. Éste es un nivel de carga que la plataforma actual es capaz de servir.

7/29

VISIÓN DE LA PLATAFORMA COMPLETA A FUTURO En esta sección vamos a tratar cuál es la visión que se tiene de lo que va a ser la plataforma Liferay de IZFE y los distintos componentes principales que intervienen en ella. Recordamos que en este documento se trabaja sobre la versión de Liferay DXP Digital Enterprise 7.0 SP1 (Liferay 7.0 EE), y no sobre la versión 6.2 EE implantada actualmente en IZFE. El siguiente diagrama presenta cómo el liferay interactuará con los principales componentes de la infraestructura.

En esta arquitectura se requiere de los siguientes elementos:

● Infraestructura Liferay: Infraestructura Liferay que da soporte a las necesidades de IZFE. Esta infraestructura estará soportada por una infraestructura de almacenamiento y BBDD.

● Proxy Inverso: Punto de entrada a la plataforma y a las herramientas adicionales. Gestor de los distintos dominios (y sus certificados) publicados en la plataforma.

● Crawler: Araña que busca páginas y contenidos en las webs y dominios configurados y los indexa cada X tiempo, haciéndolos buscables.

● Indexador: Motor de indexación que independiza la indexación del liferay, aligerando la carga en los servidores liferay. Aloja varios tipos de indexaciones, aunque en este caso nos centramos en 2 tipos: indexación interna en liferay e indexación para realizar búsquedas generales.

● SSO - Gestión de identidades: Gestión Externa de los usuarios, identidades y perfiles / permisos. Gestión independiente del Liferay para poder gestionar los usuarios independientemente de la instancia del liferay en la que participen. El motor de SSO nos proporciona la capacidad de no tener que volver a identificarnos al cambiar de una web con un dominio a otra con otro dominio.

PROXY INVERSO

SSO -

GESTION IDENTIDADES

LIFERAY INDEXADOR

indexación interna liferay búsqueda interna liferay

CRAWLER

usuario perfil / permisos

localizar páginas y contenidos

indexar páginas y contenidos

búsqueda general

ALMACENAMIENTO BBDD

8/29

Todos estos componentes (a parte del Liferay) no tienen por qué ser exclusivos de la plataforma Liferay y pueden soportar otros casos de uso en IZFE. Es por ello que en este documento sólo nos centraremos en por qué y para qué necesitamos dichos componentes. Esta infraestructura sigue las recomendaciones de implantación proporcionadas por Liferay:

● Liferay DXP Deployment Checklist https://www.liferay.com/documents/10182/1645493/Liferay+DXP+Deployment+Checklist/bf452028-62f2-49bd-b024-94ce04a0c941?version=1.0

● Liferay EE https://www.liferay.com/documents/10182/1645493/Liferay+Portal+EE+Reference+Architecture+%26+Hardware+Requirements/7f618f87-ca55-4e39-ba21-b3faadbca206 La siguiente imagen extraída de este último documento detalla las recomendaciones de implantación.

9/29

Justificación de los Componentes Indexación Liferay recomienda que la indexación debe estar externalizada fuera del servidor donde se ejecuta el liferay por 2 motivos principalmente:

● La indexación carga el sistema ● Es un requisito para entornos en cluster

Se soportan SOLR y ElasticSearch. Liferay 7 viene de forma nativa con ElasticSearch. Almacenamiento Si por temas de rendimiento / HA pensamos en montar un cluster de servidores liferay, es importante pensar en cómo y dónde alojamos la información que el liferay gestiona, de forma que pueda crecer según la plataforma crece. Esto comprende 2 partes:

● BBDD ● Almacenamiento de Documentos

Proxy Inverso Teniendo en cuenta que se gestionan múltiples dominios independientes, un proxy inverso facilita la gestión de los dominios y sus certificados y controla la exposición pública hacia internet. Además, el establecer un proxy inverso mejora la seguridad del sistema al imponer un intermediario y poder trabajar las políticas pertinentes en el firewall. Gestión de Identidades El tener todas las webs de la diputación implica tener webs con espacios y contenidos completamente independientes entre si, incluyendo los usuarios. Hay que tener en cuenta que entre dichas webs se incluyen tanto las de ayuntamientos como las de organizaciones independientes asociadas a la diputación. Actualmente no existe un control unificado de los usuarios externos para permitir el acceso a la plataforma. La gestión de los usuarios externos se está realizando de forma individualizada, dándoles de alta en aquellas instancias/sites de liferay a las que requieren acceso. Además, empieza a surgir la necesidad de permitir el acceso de los ciudadanos a funcionalidades provistas desde la diputación (participación ciudadana, administración electrónica, etc.). Desde un punto de vista de Seguridad resulta importante mínimamente poder controlar de forma centralizada y unificada qué usuario tiene acceso a qué instancia y/o site. Incluso poder controlar los tipos/perfiles de usuarios (ciudadano, editor de contenidos, usuario ayuntamiento, etc.). Los ciudadanos deben poder darse de alta en la plataforma, bien publicando la aplicación que gestiona los usuarios externos bien desarrollando un portlet de liferay que contemple el alta de usuarios externos. Al unificar las múltiples plataformas actuales sobre una única, cada liferay actual se trabajaría sobre una instancia en la nueva plataforma. Sin embargo cada instancia tiene su propio repositorio de usuarios. En el momento en que el número de instancias y usuarios crezca esta gestión se puede convertir en un infierno. Teniendo en cuenta además que algunos usuarios tendrán acceso sobre distintas instancias en distintos roles, se multiplican por lo tanto los puntos de gestión de accesos para dicho usuario. Si además tenemos en cuenta que los ciudadanos podrán darse de alta como usuarios para las instancias pertinentes, la complejidad de la gestión se incrementa.

10/29

El objetivo de una gestión de identidades es controlar los siguientes aspectos:

● Mantenimiento de usuarios sobre la plataforma Liferay de IZFE. Incluye el alta, tanto interna como externa a IZFE de usuarios. Incluye así mismo el repositorio con la gestión de las claves de acceso.

● Controlar a dónde puede acceder un usuario y establecer qué permisos/roles tiene sobre qué espacio de una forma centralizada.

Single Sign On (SSO) Al tener múltiples dominios, el navegar de un dominio a otro obligaría al usuario a tener que loguearse continuamente en cada dominio de la diputación al que quiera acceder. Un enfoque Single Sign On externo al Liferay (login independiente del liferay) permite que una vez un usuario se identifique, no tenga que volver a hacerlo al navegar por los distintos espacios de la plataforma (salvo que a propósito se requiera). Además, el mecanismo de SSO sirve no solo para autenticar al usuario contra el repositorio pertinente de usuarios (gestión de identidades) y transmitir su identidad a la aplicación de destino, sino que también permite transmitir a las aplicaciones el perfil del usuario conectado. Existen diferentes protocolos de autenticación SSO con los que Liferay es compatible (CAS, OAuth, SAML, etc.). En base a dicha información, el liferay de forma integrada ajustará los permisos del usuario que se está conectando. Esta integración requerirá la realización de algún ajuste en base al protocolo seleccionado. Crawler Las capacidades de búsqueda del liferay son limitadas. Liferay indexa todos sus contenidos y documentos sobre un índice único. Ello hace que la indexación esté basada en contenidos y no en páginas o URLs, que es la forma más tradicional en la que se espera que funcione un buscador. En IZFE este comportamiento está trayendo problemas y generando ruido. Se está estudiando una indexación externa de páginas y documentos que además permite indexar páginas y documentos no almacenados en el propio liferay. Dicho crawler cada cierto tiempo navegará las páginas de los sites y los indexará, permitiendo una búsqueda más tradicional ‘a lo google’ basada en páginas como resultados de una búsqueda. Dicho índice se alojará en el indexador y podrá ser consultado desde desarrollos específicos en Liferay (nuevo buscador de la diputación). Con ello, la indexación interna de liferay queda únicamente para la localización de contenidos desde la administración.

11/29

RETOS DE ARQUITECTURA EN LIFERAY Esta sección describe los retos (o riesgos) conocidos que se deben afrontar en la arquitectura y que durante la implantación se deberán resolver.

Instancias El objetivo es que la nueva plataforma de soporte a todas las webs albergadas en liferay en IZFE actualmente y otras futuras. Ello incluye no solo a las webs de la diputación, sino también a las webs de los ayuntamientos e incluso de organizaciones asociadas a la diputación pero independientes de ésta. También en cómo se afrontan los espacios colaborativos o intranets que se deberán incorporar en la plataforma. En este punto nos planteamos, ¿cómo organizamos las webs en la infraestructura liferay? Es aquí donde entran en juego las instancias. Liferay es una plataforma de construcción de portales. A cada uno de estos portales se les llaman instancias de portales. Una instancia está asociada con un conjunto de sites que comparten un mismo conjunto de usuarios. Todos los Assets de Liferay están asociados a los sites, y por lo tanto a sus instancias pertinentes. Es decir, las instancias separan los sites y sus contenidos en zonas independientes no relacionadas (aunque internamente se pueden programar accesos cruzados …). En este sentido la decisión todavía no está tomada. Por ejemplo, teniendo en cuenta sólamente los ayuntamientos se plantean los siguientes escenarios:

● 1 instancia para todos los ayuntamientos - Facilita el que un mismo usuario acceda o trabaje en las webs de más de un ayuntamiento.

● 1 instancia por ayuntamiento - Mayor separación de usuarios y contenidos - Sobre un dominio de un ayuntamiento no se puede acceder a las páginas de otro

ayuntamiento a través de URLs tipo /web/site/pagina donde se está especificando el site. - Favorece la creación de espacios internos de documentación - Se le aporta mayor independencia administrativa a los ayuntamientos. - Mantenimiento general algo más complejo, pero se pueden proveer mecanismos que lo

simplifiquen. La decisión de realizar la división está muy relacionada con la implantación de una Gestión de Identidades centralizada ya que cada instancia tendrá su propio repositorio interno de usuarios y muy posiblemente se requiera un gobierno externo de los usuarios de todas las instancias que se definan. Staging El Staging en Liferay es un mecanismo que permite la separación de la gestión de contenidos y Assets en 2 entornos. Uno público y otro de edición. Los editores trabajan sobre los contenidos en el entorno de edición sin preocuparse de publicar contenidos incompletos. Una vez que el editor está satisfecho, puede pasarlos al entorno público. El Staging es una característica de Liferay que ya se ha probado en plataformas anteriores (6.2 EE) y ha resultado en un fracaso. El Staging introduce complejidad en los mecanismos de publicación de los contenidos, que no se desea trasladar a los editores. Liferay 7.0 DXP por un lado ha actualizado sus interfaces de gestión y por otro ha reorganizado internamente la forma de funcionar. Se debe evaluar si la mejora es suficiente en un entorno de Staging remoto y sin la mochila de pruebas anteriores. Si lo es, se debe establecer cuál es la mejor forma de trabajo para la edición de contenidos usando el staging, y estandarizarla para los editores que vayan a trabajar con la plataforma.

12/29

Si el Staging ya de por si solo ya es un reto, dado a cómo se han realizado los desarrollos sobre la versión 6.2 de IZFE, se añaden otros retos que hay que superar:

● Indirecciones sobre contenidos usando el UUID en lugar del ID. ● Complejidad del paso de contenidos al entorno público.

En la gestión de contenidos, temas y desarrollos actuales, los contenidos se referencian en base al ID. La referencia usando el ID es válida cuando se trabaja de forma local ya que los contenidos reciben un ID principal (clave primaria en BBDD) que facilita la identificación. Cuando se plantea un escenario de staging en remoto, el problema viene de que al realizar el insert sobre la nueva BBDD, el ID que se le asigna es nuevo y por lo tanto la indirección en el nuevo entorno falla. Son 2 plataformas diferentes. Para estos casos Liferay específica que el mecanismo principal de identificación de contenidos es el UUID. Este cambio en la forma de trabajo supone actualizar los desarrollos actuales para que trabajen con UUIDs.

Seguridad en las Plantillas de contenidos y similares Las plantillas de contenidos son una parte a la que los editores de contenidos pueden tener acceso. Desde ellas se puede hacer un uso directo de los local service de liferay que ignoran los permisos de los usuarios. A través de los local service, se puede llegar a acceder a contenidos de otros sites o incluso de otras instancias del liferay. Su uso debe ser controlado. Una posible solución puede ser un HOOK que se suscriba al guardar de una plantilla para inspeccionar y/o modificar dichos usos indeseados al guardar. Habrá que explorar otras soluciones si el problema persiste en Liferay 7. Certificados SSL Dado que cada ayuntamiento necesita alojar su sede electrónica, ¿cómo se resuelve el tema de los certificados SSL? Pero ¿a qué nivel se protege con SSL? La sede es todo el site. Además el SSL permite proteger el login de los usuarios y el acceso a áreas internas.

Despliegue controlado de Hot-Fixes de Liferay Liferay no es infalible, y por lo tanto, como en todo software existen bugs y problemas de seguridad que se deben resolver. Para ello, Liferay cada cierto tiempo lanza Hot-Fixes que van corrigiendo dichos problemas. En algunos casos incluso añaden nuevas funcionalidades. Este proceso es un proceso típico de mantenimiento. Dichos Hot-Fixes, en ciertas ocasiones pueden chocar con personalizaciones que se hayan aplicado sobre la plataforma tales como HOOKs o Portlets que tiran de ciertas características de Liferay. En IZFE se han dejado notar dichos choques de las siguientes maneras:

● Portlets / HOOKs que han tenido que ser re-desplegados ● Problemas con la indexación de los contenidos. Se ha tenido que realizar re-indexaciones. ● Algunos de los problemas se han encontrado directamente en producción ya que en desarrollo no

se tenían contenidos suficientes como para forzar los errores. Dada la experiencia actual, la aplicación de los hot-fixes debe ser lo menos problemática posible y lo más controlada posible. Para ello se debe controlar cuidadosamente qué se modifica mediante plugins.

13/29

REQUISITOS En IZFE se plantean los siguientes requisitos a tener en cuenta y que debe cumplir la plataforma que finalmente se monte. R1. La plataforma debe soportar una carga de 10 peticiones por segundo sirviendo páginas públicas. Prioridad ALTA.

R2. La plataforma debe garantizar su disponibilidad como hasta ahora. Se puede considerar un tiempo máximo de no disponibilidad por servicio o caída. Prioridad ALTA.

R3. La plataforma debe estar preparada para montarse en HA en caso de que en un futuro se incluya algún elemento que lo requiera. Prioridad ALTA.

R4. La plataforma debe poder escalar (incrementar cluster) para aumentar el rendimiento en caso de ser necesario. Prioridad ALTA.

R5. La plataforma debe poder ofrecer espacios internos de colaboración o intranets. Prioridad ALTA.

R6. La plataforma debe poder ser fácilmente actualizable con los hot-fixes de Liferay. Prioridad BAJA.

R7. La plataforma debe garantizar la seguridad de acceso a los contenidos. Los usuarios a través de plantillas dinámicas no deben poder acceder a contenidos sobre los que no tiene permisos. Prioridad ALTA.

14/29

ESCENARIOS PLATAFORMA LIFERAY IZFE se plantea Liferay como plataforma para albergar muchos sitios con lógicas muy independientes entre sí. Entre las distintas funcionalidades a cubrir se encuentran las siguientes:

● Sites Públicos Diputación (incluye hacienda) ● Sites Públicos Ayuntamientos ● Intranets Diputación ● Intranets Ayuntamientos ● Servicios al Ciudadano

La plataforma Liferay que dé cabida a todas estas necesidades se puede implementar de muchas maneras muy diferentes (escenarios de implantación de liferay). De cara a describir los escenarios, definimos como Servicio Liferay a una instalación específica de Liferay (sea en cluster o no) con sus configuraciones propias. Los escenarios más significativos son (en base a distintos criterios):

1. 1 Servicio Liferay en Cluster que aloja TODAS las necesidades (sin divisiones) 2. 1 Servicio Liferay de acceso público y 1 Servicio Liferay interno (división por tipo de acceso) 3. 1 Servicio Liferay para CADA ayuntamiento o entidad (división por entidad) 4. 1 Servicio Liferay para la Diputación y 1 Servicio Liferay para TODOS los ayuntamientos (división

por entidad y agrupación en base a uso y necesidades). Se descarta el escenario 3 (división por entidad) debido a los sobrecostes que supone un enfoque de este tipo. Sobrecostes de Licencias, Servidores, y sus correspondientes mantenimientos. Se descarta también el escenario 4, ya que en toda regla es similar al escenario 1, y lo que busca es simplemente dividir la plataforma para aumentar rendimientos. Ese enfoque se puede simplificar aumentando el tamaño del cluster en el escenario 1, reduciendo costes de mantenimiento. En este sentido en las siguientes secciones detallamos los escenarios 1 y 2.

15/29

ESCENARIO 1: 1 SERVICIO LIFERAY PARA TODO Este escenario plantea una única instalación liferay para dar soporte a todas las necesidades de IZFE. Dicha instalación por lo tanto deberá estar en cluster para poder soportar la carga de todos los casos a cubrir. Los casos que más cargan la infraestructura son aquellos que requieren el logueo del usuario (acceso a partes internas), ya que requieren un procesado completo de cada página del portal. El cacheo tradicional de liferay no actúa ya que las páginas se personalizan para el usuario conectado. El uso interno se puede clasificar en:

● Funcionalidades de colaboración: Intranets, espacios documentales, … ● Personalizaciones: Acceso a contenidos personalizados. ● Edición de contenidos: Administración de los contenidos de los portales públicos (o no).

En Liferay los clusters normalmente son activo-activo haciendo que los nodos se repartan la carga. Para eliminar puntos únicos de fallo, a ser posible los nodos en los clusters deben estar distribuidos en distintos data-centers. A continuación se definen y justifican los entornos que habría que montar en IZFE para implementar este escenario. Un entorno se define como una réplica de la plataforma orientada a cubrir una necesidad específica. Típicamente se suelen considerar los siguientes entornos:

● Entorno de DESARROLLO: Instalación contra la cual los desarrolladores trabajan. ● Entorno de PRE-PRODUCCIÓN: Entorno para validar los desarrollos entregados por los

desarrolladores, testeo de integraciones y realización de formaciones. ● Entorno de PRODUCCIÓN: Entorno principal que ofrece realmente el servicio.

En IZFE, solo se proveen 2 entornos, PRODUCCIÓN y PRE-PRODUCCIÓN. Este último también llamado de DESARROLLO o INTEGRACIÓN. El entorno de DESARROLLO reside únicamente en el equipo local de cada desarrollador. A continuación se describen y justifican los entornos necesarios para este escenario.

Entornos La plataforma de producción se divide en 2 entornos:

● Atención al público en general, con sus espacios de colaboración específicos y funcionalidades personalizadas para los ciudadanos.

● Edición de contenidos. Esta separación aporta varios beneficios, destacamos:

● La edición de contenidos, una tarea pesada en Liferay, no afecta a la plataforma que debe ser ágil y estar online continuamente.

● Los editores pueden realizar tantas pruebas como se consideren oportunas sin afectar en absoluto a la plataforma online. Los contenidos editados se publicarán cuando lo consideren oportuno.

● Permite requerir un acceso especial para los editores. Por ej. a través de una VPN. Es un entorno que NO está públicamente accesible.

Esta infraestructura, separando el entorno de edición de contenidos, se soporta de forma nativa en Liferay usando la característica de Staging remoto. El Staging es una característica de liferay que permite testear ciertos “Assets” antes de publicarlos en el sitio vivo. Un Asset hace referencia a unidades/conceptos integrados en las utilidades de nativas de liferay (permisos, etiquetas, etc.). Entre los distintos Assets nos interesa destacar aquellos que intervienen en la Gestión de Contenidos. Éstos son

16/29

Artículos, Estructuras, Plantillas, documentos, imágenes, etc. Es decir, podemos tener un site que es una réplica del real sobre el que poder ver cómo quedará un determinado contenido sin que éste llegue a producción hasta que se crea oportuno. Aquellos contenidos que se editen en la plataforma y se quieran hacer accesibles para el público en general, a través del staging serán enviados al entorno público. Ambos entornos deben estar en cluster. Como se ha comentado, el entorno de edición es un entorno que no está públicamente accesible, pero se plantea también como HA por los siguientes motivos:

● Reparto de la carga de edición entre los nodos

● Permite hacer demos de sites, antes de que éstos sean publicados online y accesibles por todos los ciudadanos

● Sirve como punto donde aplicar las actualizaciones, tanto de liferay como propias, en un entorno controlado similar al público y sin afectar directamente al público. Si surgen problemas se puede dar marcha atrás.

Adicionalmente, se dispondrá de un entorno de Integración, o de desarrollo en IZFE, cuyo objetivo es probar que los desarrollos funcionan correctamente sobre una plataforma similar a las de producción (online y edición de contenidos) y sin afectar a estas. Se utiliza así mismo para realizar pruebas de integraciones que puedan existir con otros sistemas de IZFE que en un entorno de desarrollo local no estarían disponibles. Dicha plataforma de Integración es de uso exclusivo para validaciones de desarrollo y por lo tanto es un entorno cuya disponibilidad puede verse comprometida. Es por ello que si se quieren realizar pruebas de aceptación de los desarrollos, éstas deben realizarse sobre un entorno más estable como es el de Edición de contenidos. Estas pruebas no afectarán al entorno online. Por último, los desarrolladores trabajarán sobre un entorno de desarrollo en su equipo local que se plantea sobre una instalación de Liferay basada en la versión CE con el objetivo de que no se requiera licencia y se pueda desarrollar desde cualquier empresa subcontratada. De todas formas en IZFE se dispone de una licencia para desarrolladores de Liferay EE así que ambas, dependiendo de la situación del desarrollador se podrían utilizar. Resumiendo, se plantean los siguientes entornos:

1. PRODUCCIÓN - ONLINE: HA. Liferay EE. 2. PRODUCCIÓN - EDICIÓN: HA. Liferay EE. 3. INTEGRACIÓN: No HA. Liferay EE. 4. DESARROLLO: No HA, Liferay CE/EE.

Servidores soporte iniciales Como se ha comentado se plantea la utilización de Liferay 7 DXP (EE). Liferay 7 requiere máquinas con más capacidad de proceso que las actuales corriendo Liferay 6.2. En el documento de implantación de referencia se menciona las siguientes características:

● Load Balancer Tier: Cisco Load Director or Cisco Content Services Switch (CSS) or F5 Big-IP

● Web Tier: Provides caching, compression, and other capabilities using Apache, Nginx, Varnish, etc. 1 – Intel Core 2 Duo E6405 2.13GHz CPU, 4GB memory, 1-146GB 10k RPM SCSI

17/29

● Application Tier: Represents the workhorse of the architecture. ○ 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps -

used for Liferay Portal ○ 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps -

used for Elasticsearch

● Database Tier: 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps

Sin llegar a plantear este hardware, trasladamos la necesidad de las siguientes características de máquinas (en esta parte no contemplamos el hardware para los productos no liferay): Entorno Num.

Servidores Cpus Ram (gb) Licencia Liferay

Producción - Online 2 4 12 Cluster Producción

Producción - Edición 2 4 8 Cluster No Producción

Integración 1 2 6 No Producción

El tema de las licencias Liferay para el entorno de Edición es considerarlo no Productivo ya que no es públicamente accesible (con el consiguiente ahorro). Liferay 7 implica que la MV de Java a utilizar es por lo menos la 1.8. La asignación de memoria real desde el servidor a la máquina virtual de Java se ajustará en base al rendimiento obtenido (siempre teniendo en cuenta que Liferay 7 supone una mayor carga que la actual con Liferay 6.2). Hay que tener en cuenta que el objetivo es unificar las diferentes plataformas en una única que dé servicio a todas las necesidades actualmente contempladas y a las futuras. La plataforma, al estar clusterizada, puede crecer horizontalmente en caso necesario.

Retos de la Arquitectura Esta arquitectura está basada principalmente en el uso del staging para dividir la carga y obtener los beneficios que aporta. Si no se consigue dar este paso habrá que cambiar la infraestructura de servidores, añadiendo más capacidad al cluster público que va a asumir todas las funciones. El entorno de integración deberá así mismo estar en cluster para permitir probar los desarrollos sobre un cluster antes de pasar a producción. El tema de la seguridad también afecta especialmente en el uso de las plantillas por los editores de contenidos. Como se ha comentado en ellas se puede hacer uso de los local service y a través de ellos llegar a contenidos para los que el usuario no tiene permisos. Su uso debe ser controlado. Una posible solución puede ser un HOOK que se suscriba al guardar de una plantilla para inspeccionar y/o modificar dichos usos indeseados al guardar. Habrá que explorar otras soluciones si el problema persiste en Liferay 7. Este escenario nos permite también tener un entorno muy parecido al de PUBLICACIÓN (el de EDICIÓN) como punto inicial donde aplicar los hot-fixes. Si algo va mal en su aplicación en producción solo “molesta” a los editores, dejando sin afectar la plataforma online. A diferencia de las pruebas de aplicación del hot-fix en integración, el entorno de edición de contenidos tiene los mismos contenidos que el online y también está en cluster.

18/29

ROADMAP IMPLANTACIÓN Esta sección describe los pasos a seguir para llegar a tener la plataforma de Liferay montada. FASE I: Habilitar Infraestructura Liferay En esta fase se montará la infraestructura que dará soporte a la nueva infraestructura de portales en Liferay. Se plantea una infraestructura que nos permitirá validar el servicio en producción aunque no será productiva inicialmente. Como hemos comentado en la descripción de los entornos para Liferay, la plataforma requiere al menos:

● 2 Servidores para las intranets y publicación de contenidos ● 2 Servidores específicos para los editores de contenidos

En este sentido requerimos 4 licencias no productivas de Liferay 7 de las cuales, en fases posteriores y según se considere necesario se migrarán a licencias Productivas. Sobre dichos servidores se montará los liferay en Cluster. Adicionalmente se requiere una infraestructura externa al propio liferay para el alojamiento de la BBDD de liferay y sus documentos. En cuanto a la BBDD, dicha infraestructura debiera estar en cluster, aunque no es imprescindible inicialmente y dependerá del rendimiento de la BBDD. Liferay 7.0 DXP ha sido certificado sobre las BBDD:

● DB2 10.1 ● DB2 10.5 ● MariaDB 10 ● MySQL 5.6 ● Oracle 12c Release 1 ● PostgreSQL 9.3 ● PostgreSQL 9.4 ● SQL Server 2012 ● Sybase ASE 16

y soportado sobre las BBDD:

● DB2 9.7 ● MySQL 5.7 ● Oracle 11g Release 2 ● SQL Server 2008 ● SQL Server 2008 R2 ● SQL Server 2014 ● SQL Server 2016 ● Sybase ASE 15

Se recomienda MySQL o MariaDB ya que son las BBDD más utilizadas en implantaciones de Liferay. Trasladado a servidores, se requieren:

● 2 servidores para alojar las BBDDs específicas para cada cluster de Liferay. ● 2 Unidades de red (SAN) con capacidades de acceso concurrente y bloqueo de ficheros.

Por último, de cara a poder montar el cluster de liferay, también se requiere que la indexación esté externalizada. Es por ello que se requiere:

● 1 servidor para alojar los índices de los 2 clusters de Liferay.

19/29

FASE II: Validar/parchear/solucionar problemas detectados Tras la instalación, en esta fase se deben realizar aquellas pruebas que se consideren oportunas, y desarrollar aquellos módulos que nos permitan solucionar los problemas encontrados.

Por ej. entre los problemas que se deben tratar en esta fase están los siguientes:

● la accesibilidad a datos de otras instancias de la plataforma liferay desde ADTs, plantillas de contenidos y similares. Solventar los problemas de seguridad que surjan.

● pruebas de Staging remoto y edición de contenidos. ● pruebas de espacios de colaboración ● pruebas de múltiples instancias y dominios ● etc.

El objetivo final es tener la plataforma preparada, testeada y con todos los conceptos de trabajo claros antes de empezar a trabajar sobre ella.

FASE III: Migrar framework actual Tanto el tema como los desarrollos realizados para el Liferay 6.2 EE actuales deben ser migrados a la nueva plataforma. El objetivo es poder disponer de las mismas herramientas que actualmente se disponen sobre el Liferay 6.2 EE para la realización de espacios web.

FASE IV: Publicación del entorno en producción En esta fase se actualizará la plataforma como entorno de producción. Si hace falta resetear las BBDDs y espacios documentales para empezar de 0 este es el momento. Al menos el cluster con las intranets y la publicación de los contenidos debe pasar a usar una licencia de producción y el liferay debe estar públicamente disponible (online en internet):

● Alta de 2 licencias de producción de Liferay ● Baja de 2 licencias no productivas de Liferay

En este momento tendremos tanto la plataforma vieja como la nueva en producción. Deberán coincidir de esta forma hasta que se hayan migrado todos los espacios a esta plataforma. Adicionalmente debemos montar un entorno de integración de desarrollos en IZFE. Con lo que necesitamos disponer de los siguientes servidores y licencias:

● 1 Servidor Liferay + 1 licencia no productiva ● 1 Servidor con la BBDD de integración (puede reutilizarse un Servidor de BBDD de integración

común. Debe estar basado en el mismo producto de BBDD que el de producción) ● 1 Servidor de Indexación (para no mezclar infraestructuras de producción y desarrollo).

En este punto solo se permitirán despliegues sobre la plataforma usando mecanismos de integración continua. NOTA: En este momento la plataforma estaría en HA, pero sus dependencias NO. Sería interesante trabajar en la clusterización de dichas dependencias (BBDD, Indexación, Crawling, SSO, etc.).

FASE V: Migraciones de Sites En este punto debemos realizar, uno por uno, la migración de los sites en el orden y prioridad que se establezca. P.e. se empieza integrando los sites de los ayuntamientos en la nueva plataforma. Es muy posible que la migración deba hacerse utilizando una herramienta desarrollada específica que nos permita actualizar p.e. estructuras y plantillas de contenidos.

20/29

ESCENARIO 2: SERVICIOS PÚBLICO - INTRANET Para este segundo escenario trabajaremos la siguiente división:

● Servicio Público (centrado en la gestión de contenidos): ○ Sites públicos de la Diputación ○ Sites públicos de los Ayuntamientos ○ Servicios al ciudadano / Extranets

● Intranets (centrado en espacios de colaboración): ○ Diputación ○ Ayuntamientos

Esta separación permite establecer distintas configuraciones globales en las instalaciones de liferay ajustadas a las necesidades de cada caso. Con este cambio, además, se divide la carga de usuarios logueados entre las 2 plataformas. Por un lado están los sitios públicos con los servicios al ciudadano y las capacidades de edición, y por otro tenemos el uso centrado en las intranets y espacios de colaboración. Entornos Al dividir la plataforma en 2 los entornos se incrementan proporcionalmente con respecto al escenario 1. Entorno Público Al igual que en el escenario 1, en la parte pública se sigue trabajando en la edición de contenidos. Es por ello que, aunque la carga de la plataforma sea menor que en el escenario 1, se sigue planteando la misma infraestructura. Sin embargo, aporta una mayor flexibilidad ya que en el entorno de publicación de producción podemos, mientras no exista una carga fuerte de ciudadanos, desactivar uno de los nodos del cluster. Recordamos las características especificadas en el escenario 1. El entorno público se encarga principalmente de publicar contenidos y servicios orientados al ciudadano. La plataforma de producción se divide en 2 entornos:

● Atención al público en general, con sus funcionalidades personalizadas para los ciudadanos. ● Edición de contenidos.

Esta separación aporta varios beneficios, destacamos:

● La edición de contenidos, una tarea pesada en Liferay, no afecta a la plataforma que debe ser ágil y estar online continuamente.

● Los editores pueden realizar tantas pruebas como se consideren oportunas sin afectar en absoluto a la plataforma online. Los contenidos editados se publicarán cuando lo consideren oportuno.

● Permite requerir un acceso especial para los editores. Por ej. a través de una VPN. Es un entorno que NO está públicamente accesible.

Esta infraestructura, separando el entorno de edición de contenidos, se soporta de forma nativa en Liferay usando la característica de Staging remoto. Tenemos un site que es una réplica del real sobre el que poder ver cómo quedará un determinado contenido sin que éste llegue a producción hasta que se crea oportuno. Aquellos contenidos que se editen en la plataforma y se quieran hacer accesibles para el público en general, a través del staging serán enviados al entorno público. Ambos entornos deben estar en configurados para trabajar en cluster.

21/29

Como se ha comentado, el entorno de edición es un entorno que no está públicamente accesible, pero se plantea también como HA/cluster por los siguientes motivos:

● Reparto de la carga de edición entre los nodos ● Permite hacer demos de sites, antes de que éstos sean publicados online y accesibles por todos los

ciudadanos ● Sirve como punto donde aplicar las actualizaciones, tanto de liferay como propias, en un entorno

controlado similar al público y sin afectar directamente al público. Si surgen problemas se puede dar marcha atrás.

● Sirve de punto para verificar que los desarrollos instalados son clusterizables. La plataforma puede, en algún momento por temas de rendimiento o necesidades de HA, clusterizarse. Es por ello que todo desarrollo debe estar preparado para trabajar en cluster y que la plataforma de edición lo esté permite garantizar este punto.

Adicionalmente, se dispondrá de un entorno de Integración, o de desarrollo en IZFE, cuyo objetivo es probar que los desarrollos funcionan correctamente sobre una plataforma similar a las de producción (online y edición de contenidos) y sin afectar a estas. Se utiliza así mismo para realizar pruebas de integraciones que puedan existir con otros sistemas de IZFE que en un entorno de desarrollo local no estarían disponibles. Dicha plataforma de Integración es de uso exclusivo para validaciones de desarrollo y por lo tanto es un entorno cuya disponibilidad puede verse comprometida. Es por ello que si se quieren realizar pruebas de aceptación de los desarrollos, éstas deben realizarse sobre un entorno más estable como es el de Edición de contenidos. Estas pruebas no afectarán al entorno online. Por último, los desarrolladores inicialmente trabajarán sobre un entorno de desarrollo en su equipo local que se plantea sobre una instalación de Liferay basada en la versión CE con el objetivo de que no se requiera licencia y se pueda desarrollar desde cualquier empresa subcontratada. De todas formas en IZFE se dispone de una licencia para desarrolladores de Liferay EE así que ambas, dependiendo de la situación del desarrollador, se podrían utilizar. Resumiendo, se plantean los siguientes entornos para el trabajo público:

1. PRODUCCIÓN - ONLINE: Clusterizable en base a rendimiento. Liferay EE. 2. PRODUCCIÓN - EDICIÓN: Cluster activo-activo. Liferay EE. 3. INTEGRACIÓN: No cluster. Liferay EE. 4. DESARROLLO: No cluster, Liferay CE/EE.

Entorno Intranets La segunda parte de la infraestructura se encarga de atender específicamente las necesidades de espacios de colaboración. Ello nos permite descargar la plataforma pública de una carga importante asociada a los espacios de colaboración, ya que al acceder a estos, las caches del liferay no actúan. Esta infraestructura no requiere un entorno de edición, ya que al ser un espacio de colaboración la información está viva y cualquier usuario puede publicar nuevos contenidos para ser consumidos por sus colaboradores. Este entorno no estará disponible públicamente garantizando que no se exponen contenidos privados de forma accidental. De esta forma se plantean los siguientes entornos.

5. PRODUCCIÓN - ONLINE: Clusterizable en base a rendimiento. Liferay EE. 6. INTEGRACIÓN: Cluster. Liferay EE. 7. DESARROLLO: No cluster, Liferay CE/EE.

22/29

El entorno de integración se plantea en cluster para que los desarrollos que se vayan a desplegar hayan sido probados en un cluster antes de ser pasados a producción (que en cualquier momento puede convertirse en un cluster). Como en el entorno público, es un entorno de uso exclusivo para validaciones de desarrollo y por lo tanto es un entorno cuya disponibilidad puede verse comprometida. Servidores soporte iniciales Como se ha comentado se plantea la utilización de Liferay 7 DXP (EE). Liferay 7 requiere máquinas con más capacidad de proceso que las actuales corriendo Liferay 6.2. En el documento de implantación de referencia se menciona las siguientes características:

● Load Balancer Tier: Cisco Load Director or Cisco Content Services Switch (CSS) or F5 Big-IP

● Web Tier: Provides caching, compression, and other capabilities using Apache, Nginx, Varnish, etc. 1 – Intel Core 2 Duo E6405 2.13GHz CPU, 4GB memory, 1-146GB 10k RPM SCSI

● Application Tier: Represents the workhorse of the architecture.

○ 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps - used for Liferay Portal

○ 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps - used for Elasticsearch

● Database Tier: 2 – Intel Core 2 Quad X5677 3.46GHz CPU, 64GB memory, 2-300GB 15K RPM SATA 6Gbps

Sin llegar a plantear este hardware, trasladamos la necesidad de las siguientes características de máquinas (en esta parte no contemplamos el hardware para los productos no liferay): Entorno Num. Servidores Cpus Ram (gb) Licencia Liferay

PUBLICO: Producción - Online 2 4 12 Cluster Producción

PUBLICO: Producción - Edición 2 4 8 Cluster No Producción

PUBLICO: Integración 1 2 6 No Producción

INTRANET: Producción 2 4 12 Cluster Producción

INTRANET: Integración 2 2 6 Cluster No Producción

El tema de las licencias Liferay para el entorno público de Edición es considerarlo no Productivo ya que no es públicamente accesible (con el consiguiente ahorro). Liferay 7 implica que la MV de Java a utilizar es por lo menos la 1.8. La asignación de memoria real desde el servidor a la máquina virtual de Java se ajustará en base al rendimiento obtenido (siempre teniendo en cuenta que Liferay 7 supone una mayor carga que la actual con Liferay 6.2). La plataforma, al estar clusterizada, podrá crecer horizontalmente en caso necesario.

23/29

Retos de la Arquitectura Al igual que en el anterior escenario, el staging sigue siendo un reto. Solo que en este caso la importancia de tener el staging es menor ya que la carga, al eliminar los sitios de colaboración, es menor y se podría asumir directamente desde el cluster público de producción. La diferenciación de trabajo en instancias / sites tiene la misma relevancia que en el escenario anterior. Es más, como se ha realizado una división entre espacios públicos y privados, debemos tener en cuenta que posiblemente todas las entidades (p.e. ayuntamiento) tengan tanto información pública como privada, y es posible que algunos usuarios sean compartidos. Por lo tanto, será más necesaria una gestión de las identidades de los usuarios que simplifique las gestiones. En otro punto importante como es el de la seguridad es donde se produce la principal ventaja de esta forma de organización. La plataforma pública no contendrá contenidos privados, y por lo tanto no existirá el problema de que se pueda acceder a los local service desde las plantillas que modifican los editores. Y como en el entorno de intranets no habrá una gestión de contenidos en toda regla, tampoco habrá necesidades de edición de plantillas. En este sentido se pueden aplicar las restricciones al uso de determinados servicios en las plantillas nativo en liferay. ROADMAP LIFERAY Al igual que en el escenario anterior, se plantea un roadmap de implantación de la infraestructura liferay asociada a este escenario. Se diferencian las Fases por los entornos (pública A, intranets B). FASE I.A: Habilitar Infraestructura Liferay Pública En esta fase se montará la infraestructura que dará soporte a la nueva infraestructura de portales públicos en Liferay. Se plantea una infraestructura que nos permitirá validar el servicio en producción aunque no será productiva inicialmente. Como hemos comentado en la descripción de los entornos para Liferay, la plataforma requiere al menos:

● 2 Servidores para el servicio público ● 2 Servidores específicos para los editores de contenidos

En este sentido requerimos 4 licencias no productivas de Liferay 7 de las cuales, en fases posteriores y según se considere necesario se migrarán a licencias Productivas. Sobre dichos servidores se montará los liferay en Cluster. Adicionalmente se requiere una infraestructura externa al propio liferay para el alojamiento de la BBDD de liferay y sus documentos. En cuanto a la BBDD, dicha infraestructura debiera estar en cluster, aunque no es imprescindible inicialmente y dependerá del rendimiento de la BBDD. Liferay 7.0 DXP ha sido certificado sobre las BBDD:

● DB2 10.1 ● DB2 10.5 ● MariaDB 10 ● MySQL 5.6 ● Oracle 12c Release 1 ● PostgreSQL 9.3 ● PostgreSQL 9.4 ● SQL Server 2012 ● Sybase ASE 16

24/29

y soportado sobre las BBDD:

● DB2 9.7 ● MySQL 5.7 ● Oracle 11g Release 2 ● SQL Server 2008 ● SQL Server 2008 R2 ● SQL Server 2014 ● SQL Server 2016 ● Sybase ASE 15

Se recomienda MySQL o MariaDB ya que son las BBDD más utilizadas en implantaciones de Liferay. Trasladado a servidores, se requieren:

● 2 servidores para alojar las BBDDs específicas para cada cluster de Liferay. ● 2 Unidades de red (SAN) con capacidades de acceso concurrente y bloqueo de ficheros.

Por último, de cara a poder montar el cluster de liferay, también se requiere que la indexación esté externalizada. Es por ello que se requiere:

● 1 servidor para alojar los índices de los 2 clusters de Liferay. FASE II.A: Validar/parchear/solucionar problemas detectados Tras la instalación, en esta fase se deben realizar aquellas pruebas que se consideren oportunas, y desarrollar aquellos módulos que nos permitan solucionar los problemas encontrados. Por ej. Entre los problemas que se deben tratar en esta fase están los siguientes:

● pruebas de Staging remoto y edición de contenidos. ● pruebas de múltiples instancias y dominios ● etc.

El objetivo final es tener la plataforma preparada, testeada y con todos los conceptos de trabajo claros antes de empezar a trabajar sobre ella. FASE I.B: Habilitar Infraestructura Liferay para Intranets En esta fase se montará la infraestructura que dará soporte a la nueva infraestructura de intranets en Liferay. Se plantea una infraestructura que nos permitirá validar el servicio en producción aunque no será productiva inicialmente. Como hemos comentado en la descripción de los entornos para Liferay, la plataforma requiere al menos:

● 2 Servidores para el servicio de intranets en producción En este sentido requerimos 2 licencias no productivas de Liferay 7 de las cuales, en fases posteriores y según se considere necesario se migrarán a licencias Productivas. Sobre dichos servidores se montará los liferay en Cluster. Adicionalmente se requiere una infraestructura externa al propio liferay para el alojamiento de la BBDD de liferay y sus documentos. En cuanto a la BBDD, dicha infraestructura debiera estar en cluster, aunque no es imprescindible inicialmente y dependerá del rendimiento de la BBDD.

25/29

Dicha infraestructura puede ser la utilizada para la plataforma pública (mismos servidores, distintos servicios):

● 1 servidores para alojar las BBDDs específicas para el cluster de Liferay de intranets. ● 1 Unidad de red (SAN) con capacidades de acceso concurrente y bloqueo de ficheros.

Por último, de cara a poder montar el cluster de liferay, también se requiere que la indexación esté externalizada. Para ello reutilizaremos el servidor de indexación del entorno público. FASE II.B: Validar/parchear/solucionar problemas detectados Tras la instalación, en esta fase se deben realizar aquellas pruebas que se consideren oportunas, y desarrollar aquellos módulos que nos permitan solucionar los problemas encontrados. Por ej. Entre los problemas que se deben tratar en esta fase están los siguientes:

● la accesibilidad a datos de otras instancias de la plataforma liferay desde ADTs, plantillas de contenidos y similares. Solventar los problemas de seguridad que surjan.

● pruebas de espacios de colaboración ● pruebas de múltiples instancias y dominios ● etc.

El objetivo final es tener la plataforma preparada, testeada y con todos los conceptos de trabajo claros antes de empezar a trabajar sobre ella. FASE III.A: Migrar framework actual Tanto el tema como los desarrollos realizados para el Liferay 6.2 EE actuales deben ser migrados a la nueva plataforma. El objetivo es poder disponer de las mismas herramientas que actualmente se disponen sobre el Liferay 6.2 EE para la realización de espacios web. FASE III.B: Desarrollar framework para Intranets Al igual que el framework actual, hay que desarrollar uno específico para las intranets de colaboración. FASE IV: Publicación de los entornos en producción En esta fase se actualizará la plataforma como entorno de producción. Si hace falta resetear las BBDDs y espacios documentales para empezar de 0 este es el momento. Ya se ha verificado que todos funcionan en Cluster. Es en este momento cuando podemos parar / apagar uno de los nodos, sabiendo que si lo necesitamos sólo tenemos que volver a ponerlo en marcha con su licencia pertinente. Es por ello que tendremos que cambiar las siguientes licencias:

● Alta de licencia entorno de producción de publicación de contenidos ● Alta de 1 licencias para el entorno de producción de intranets ● Baja de 4 licencias no productivas

En este momento tendremos tanto la plataforma vieja como la nueva en producción. Deberán coincidir de esta forma hasta que se hayan migrado todos los espacios a esta plataforma.

26/29

Adicionalmente debemos montar un entorno de integración de desarrollos en IZFE. Con lo que necesitamos disponer de los siguientes servidores y licencias:

● 1 Servidor Liferay + 1 licencia no productiva para el entorno de publicación de contenidos ● 2 Servidores Liferay + 2 licencias no productivas para el entorno de intranets en cluster ● 1 Servidor con la BBDD de integración (puede reutilizarse un Servidor de BBDD de integración

común. Debe estar basado en el mismo producto de BBDD que el de producción) ● 1 Servidor de Indexación (para no mezclar infraestructuras de producción y desarrollo).

En este punto solo se permitirán despliegues sobre la plataforma usando mecanismos de integración continua. NOTA: En este momento la plataforma estaría preparada para funcionar en HA si fuera necesario, pero sus dependencias NO. Sería interesante trabajar en la clusterización de dichas dependencias (BBDD, Indexación, Crawling, SSO, etc.). FASE V: Migraciones de Sites En este punto debemos realizar, uno por uno, la migración de los sites en el orden y prioridad que se establezca. P.e. se empieza integrando los sites de los ayuntamientos en la nueva plataforma. Es muy posible que la migración deba hacerse utilizando una herramienta desarrollada específica que nos permita actualizar p.e. estructuras y plantillas de contenidos.

27/29

SELECCIÓN ESCENARIO - RECOMENDACIÓN

Servicios Liferay

Beneficios Inconvenientes

1 para todo ● Facilita mantenimiento / administración

● Reduce costes ○ licencias ○ máquinas

● Facilita crecimiento de la plataforma

● Configuración global compartida para todo

● Seguridad: Uso de APIs ‘Local’

2 público / intranet

● Posibilidad de aplicar configuraciones independientes más simples:

○ seguridad plantillas ○ accesos protegidos

● Mayor coste:

○ licencias ○ máquinas

● Más puntos de administración / mantenimiento

En el marco de esta consultoría parece recomendable la implantación del escenario 2: público vs intranets por los siguientes motivos:

● Seguridad. Al separar y poder aplicar distintas configuraciones a los distintos entornos nos elimina el problema de la seguridad de las plantillas. Así mismo, se pueden establecer mecanismos adicionales de seguridad para conectarse a las intranets (VPNs, etc.).

● No se incrementa excesivamente la administración ya que solo se montan 2 plataformas.

● Existe interés en implantar una gestión de identidades que simplifique la administración / mantenimiento.

OTROS SERVICIOS

ROADMAP CRAWLER & SSO De forma paralela a la FASE I y II del ROADMAP de Liferay, se pueden trabajar también los otros 2 elementos que aparecen en la foto (crawling & SSO). Por un lado el establecer/desarrollar la gestión correcta que deben seguir los usuarios que interactúen con la plataforma y habilitar un mecanismo de Single Sign On que nos permita reforzar dicha gestión e integrarlo con el Liferay. Por otro, montar un Crawler que navegue las páginas y documentos públicos y los indexe como corresponde para que puedan ser buscados ‘a lo google’. Esta indexación es independiente de la que realiza liferay. Ambos sistemas requerirán una infraestructura de servidores y BBDD propia donde se considere oportuno.

28/29

ROADMAP SSO - GESTIÓN DE IDENTIDADES Aunque sea opcional, se recomienda desarrollar esta parte también de forma paralela a la FASE I y II para realizar pruebas de integración ANTES de empezar con los desarrollos sobre la plataforma. Al tenerlo ANTES, se valida la corrección de la infraestructura completa. Si se considera demasiado complejo, se puede inicialmente tantear una solución SSO que tire de la autenticación propia del liferay, de forma que un usuario no tenga que re-loguearse en otro dominio/instancia que contenga un usuario con su mismo ID.

NOTAS CLOUD Estas infraestructuras pueden montarse sobre infraestructuras cloud, bien albergadas en IZFE, bien en los servicios de nubes. Especialmente en lo que concierne a los motores de indexación y los de crawling ya que están de forma nativa desarrollados para soportar arquitecturas basadas en contenedores, facilitando un crecimiento horizontal cuando sea necesario. Los servidores de BBDD (MySQL, MariaDB) y Liferay podrían ser “contenedorizados” en caso de plantearse, aunque en el caso del Liferay no es una situación habitual y no se recomendaría.

29/29

ADJUNTOS

Servidores Liferay Actuales opedes01 Producto Versión Xmx MaxPermSize Jvm oracle

liferay 6.1.1 CE GA2 1024 256 1.6.0_45

liferayso 6.2 CE GA2 1024 512 1.6.0_45

liferay62 6.2 CE GA4 1280 512 1.6.0_45

liferaydfg 6.2 CE GA4 1024 512 1.6.0_45

opepro01 Producto Versión Xmx MaxPermSize Jvm oracle

liferay 6.1.1 CE GA2 1024 512 1.6.0_45

liferayso 6.2 CE GA2 1280 512 1.6.0_45

liferay62 6.2 CE GA4 5000 512 1.6.0_45

liferaydfg 6.2 CE GA4 2048 512 1.6.0_45

opedes04 Producto Versión Xmx MaxPermSize Jvm oracle

liferayee 6.2.10 EE GA1 2048 512 1.7.0_75

opepro04 Producto Versión Xmx MaxPermSize Jvm oracle

liferayee 6.2.10 EE GA1 4000 512 1.7.0_75