Una Arquitectura Basada en Eventos (EDA) o Event-Driven Architecture es un patrón de diseño de software en el cual se diseñan servicios desacoplados que se relacionan mediante la publicación, consumo y enrutado de eventos. También son conocidas como arquitectura orientada a eventos o arquitectura dirigida por eventos.

En una Arquitectura Basada en Eventos (EDA), un evento se define como un cambio de estado significativo en el sistema o en el entorno en el que nos encontremos. Será este cambio el que haga que los servicios reaccionen para dar una respuesta sobre dicho cambio.

Un cambio de estado puede ser cosas como “Se ha añadido un producto al carrito de la compra”, “Se ha realizado una transferencia bancaria”, “El cliente ha cambiado sus datos de contacto”,…

Modelos tradicionales versus Modelos de eventos

Los modelos tradicionales de desarrollo son modelos síncronos, en estos modelos lo que encontramos es un servicio emisor que realiza una petición directa sobre un servicio receptor del cual espera una respuesta directa. Independientemente del tiempo que esta respuesta tarde.

Por otro lado, el modelo asíncrono que nos presenta una arquitectura basada en eventos versa en que el servicio emisor genera un evento el cual será atendido de forma desconectada o asíncrona por un servicio receptor. En este modelo el servicio emisor continua su ejecución independientemente de lo que tarde el servicio receptor en procesar la petición.

Funcionamiento Básico de una Arquitectura Basada en Eventos (EDA)

El funcionamiento básico de una Arquitectura Basada en Eventos (EDA) es que se produce o lanza un evento por parte de uno o mas Emisores (Publisher). Esta emisión puede ser producida de forma manual, debido a una interacción de un usuario o bien puede ser emitido de forma automática cuando se produce una condición concreta en un sistema.

El evento suele ser almacenado en un contenedor que se denomina Cola (Queue) o en Temas (Topics). La cola va creciendo a medida que llegan los mensajes. En el caso de que la arquitectura basada en eventos ofrezca capacidades avanzadas como filtrado, enrutado, agregación o correlación de eventos, suele aparecer otra pieza que es el Bus de Mensajes (Message Broker), el cual cuenta con las colas para almacenar los mensajes y con las capacidades mencionadas para su manipulación.

Una vez que tenemos un mensaje dentro de una cola o de un bus de mensajes tendremos los Consumidores (Consumers), que son aquellos servicios que responden o ejecutan acciones atendiendo al evento que se ha generado y la información que este proporciona.

Beneficios y desafíos de las Arquitecturas Basadas en Eventos (EDA)

La principal ventaja de las Arquitecturas Basadas en Eventos es su naturaleza asíncrona. Es decir, los componentes que la conforman no tienen por qué estar sincronizados en tiempo real y pueden funcionar de forma independiente. Este escenario nos permite una gran escalabilidad y crecimiento flexible de la arquitectura, pudiendo añadir más funcionalidades de forma sencilla o bien aumentando las capacidades de procesamiento de la arquitectura inicial.

Sin embargo, las Arquitecturas Basadas en Eventos (EDA) también presentan desafíos. Y es que los diseños, dado el modelo asíncrono pueden ser más complejos de implementar y de gestionar. Además en escenarios de error puede suponer un reto el encontrar los puntos de fallo si no se han tomado las medidas necesarias de control y trazabilidad dentro de la arquitectura.

Utilidad de la Arquitecturas Basadas en Eventos (EDA)

Con todo y con esto, las Arquitecturas Basadas en Eventos (EDA) son una opción de diseño muy potente que nos permiten resolver múltiples escenarios entre los que encontramos entornos de alta carga y volúmenes dinámicos gracias a la escalabilidad de estos sistemas

Además, las Arquitecturas Basadas en Eventos (EDA) nos pueden ser muy útiles en situaciones que necesitemos realizar evoluciones de aplicaciones legacy o monolíticas a entornos más modernos basados en microservicios.

Si hablamos de funcionalidades que pueden ser implementados mediante Arquitecturas Basadas en Eventos (EDA) podemos implementar, estos son diferentes, y van desde gestión de procesos empresariales como pueden ser los casos de Alta de Clientes o la Adquisición de Productos, pasando por planos técnicos para escalar microservicios o aislar los datos de los dominios, o en áreas como la integración de datos hacía sistemas externos como pueden ser las aplicaciones SaaS.

Tecnologías detrás de las Arquitecturas Basadas en Eventos (EDA)

Si hablamos del software o de las tecnologías que nos ayudan a implementar Arquitecturas Basadas en Eventos (EDA) encontramos algunas soluciones como:

• Apache Kafka: Es una plataforma distribuida de transmisión de eventos que permite publicar, almacenar y procesar flujos de registros en tiempo real. Kafka es conocido por su capacidad para manejar grandes cantidades de datos y su alta resiliencia. Podemos encontrar soluciones empresariales de Apache Kafka como Confluent, los cuales añaden muchas más capacidades que las básicas ofrecidas por Apache Kafka.
• RabbitMQ: Es uno de los brokers de mensajes más antiguos y ampliamente utilizados. RabbitMQ soporta múltiples protocolos de mensajería como AMQP, MQTT y STOMP. El broker RabbitMQ es conocido por su fiabilidad y flexibilidad. Ofrece capacidades de persistencia de mensajes, confirmación de entrega y enrutado de mensajes. Además dispone de un sistema de plugins para poder extender sus capacidades.
• Amazon SNS/SQS: Amazon Simple Notification Service (SNS) y Amazon Simple Queue Service (SQS) son servicios gestionados de mensajería en la nube que permiten la comunicación entre sistemas distribuidos. SNS se utiliza para la transmisión de mensajes a múltiples suscriptores, mientras que SQS se enfoca en la gestión de colas de mensajes.
• IBM MQ: Conocido como IBM Message Queue es un middleware de mensajería que permite el intercambio de información entre aplicaciones asegurando que los mensajes se entreguen una vez y en el orden correcto.
• PubSub+: PubSub+ es una plataforma avanzada de mensajería que permite el intercambio en tiempo real de eventos e información entre aplicaciones, dispositivos y usuarios desarrollada por Solace. Ofrece capacidades de filtrado de temas (topics), persistencia de mensajes y enrutado dinámico. PubSub+ ofrece capacidades de integración con diferentes sistemas SaaS.
• Tibco Messaging: es una plataforma sofisticada diseñada para facilitar la comunicación fluida entre diversas aplicaciones y sistemas. Proporciona una infraestructura robusta y escalable que soporta una amplia gama de protocolos y patrones de mensajería. Tibco Messaging se integra fácilmente con otros productos de Tibco, mejorando sus capacidades y permitiendo una solución más completa para satisfacer las diversas necesidades.

Dentro de las comunidades W3C, un modelo algo más abierto que el encorsetado sistema propio de las especificaciones de la W3C existe el Invisible Markup Community Group.

¿Qué es Invisible XML?

Por explicarlo de forma resumida, la idea detrás de Invisible XML es que los autores puedan escribir los documento en el formato que quieran, que no sientan ataduras o limitaciones para definir en XML sus documentos. Pero Invisible XML establecería un método por el cual tratar esos documentos como si realmente fuesen XML y de esta manera aprovecharnos de las capacidades de intercambio, manipulación,… que da de facto el lenguaje XML.

Solemos pensar que si no utilizamos un lenguaje como XML o JSON no estamos estructurando un documento. Y esto no es del todo cierto, ya que cuando generamos un documento, este implícitamente suele llevar una estructura.

Por ejemplo cuando escribimos una carta podemos tener el encabezado, el saludo, el contenido de la carta, el cierre o cómo despides la carta,… es decir implícitamente hay una estructura en el propio documento.

Otro ejemplo es una lista de la compra o de tareas pendiente. En este caso se puede diferenciar en que tenemos una parte en la que indicamos si la tareas está hecha o en que estado se encuentra, la tarea en sí y la fecha en la que queremos hacer la tarea. Nuevamente la lista de tareas tiene su estructura implícita.

Estas estructuras las entendemos todos cuando miramos ese tipo de documentos. Pero, qué pasa cuando se lo damos a una máquina, cómo podemos decirte la estructura implícita que lleva asociado el documento para que pueda ser tratado de una forma automática. Pues eso es la idea de Invisible XML, el poder describir esa estructura para que dado un documento se genere un documento XML que pueda ser tratado por la máquina. Lo que estamos haciendo con Invisible XML es crear una gramática que interprete el documento.

Invisible XML proporciona una sintaxis específica para la descripción declarativa, esta descripción declarativa será utilizada por el procesador Invisible XML para generar un documento XML del documento inicial.

Invisible XML está liberado como especificación oficial en junio 2022

Gramática Invisible XML

La definición de la gramática de un fichero Invisible XML es sencilla y en ella se van especificando las diferentes reglas que queremos que se apliquen sobre el documento para poder interpretarlo.

Para explicarlo veamos cómo sería para aplicar Invisible XML sobre un documento de fechas que tengan un formato de estilo 11 febrero 23023.

De esta manera definiremos una regla principal en la que identifiquemos la fecha

fecha: dia, " ", mes, " ", annio.

Vemos que hemos creado tres entidades sobre las cuales iremos indicando nuevas reglas. Así un día podrá ser un número de uno o dos dígitos.

dia: digito;
     digito, digito.

A su vez esas entidades podrán ser números del 0 al 9.

-digito: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9".

Y así con cada una del resto de las entidades que hemos definido en la regla. Tampoco vamos a ir mucho más allá, pero nuestro fichero ixml quedaría de la siguiente forma:

fecha: dia, " ", mes, " "?, annio?.
dia: digito;
     digito, digito.
-digito: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9".
mes: "Enero"; "Febrero"; "Marzo"; "Abril"; "Mayo"; "Junio";
     "Julio"; "Agosto"; "Septiembre"; "Octubre"; "Noviembre"; "Diciembre".
annio: digito, digito, digito, digito;
       digito, digito.

Luego hay opciones para indicar si queremos que sean elementos o atributos (con @), o serializar elementos (con -) u elementos opcionales (con ?).

Si queréis aprender algo más sobre Invisible XML no dejéis de seguir este tutorial que enseña a crear una gramática paso a paso

Una vez que pasemos nuestro fichero iXML por el procesador veremos que la salida en XML quedará de la siguiente forma:

<fecha>
   <dia>11</dia>
   <mes>Febrero</mes>
   <annio>2023</annio>
</fecha>

Herramientas para Invisible XML

Si quieres empezar a trabajar con Invisible XML y hacer probaturas creando gramáticas hay un par de herramientas que te pueden ser de utilidad:

• WebService para poder probar iXML
• Navegador Javascript que interpreta iXML

Habrá que ver cómo evoluciona y las utilidades que se le van dando a esta especificación de Invisible XML. De momento, espero que al menos haya llamado tu atención.

Un poco de historia de Java SE, Java EE y Java ME

Pero lo primero es echar la vista un poco atrás y revisar las diferentes tecnologías Java que han ido apareciendo a lo largo del tiempo vemos que la base se fundamenta en la especificación Java SE que es la edición estándar del lenguaje y que fue publicada en 1995.

Después aparecerían otras especificaciones como Java EE (o como se conocíoa entonces J2EE) en 2001 dónde se recogen tecnologías como los EJB, WebServices, JavaServer Pages, JavaServer Faces, JSON,… La especificación Java EE está definida para que poder realizar aplicaciones más complejas y dentro del ámbito empresarial.

Y más tarde tenemos, en 2006, el desarrollo de Java ME para dispositivos de menor capacidad como móviles, electrodomésticos,…

Todo este crecimiento de las tecnologías Java nace y crece bajo el amparo de SUN Microsystems quién guía su desarrollo hasta el año 2010 dónde es comprada por Oracle. Esto hace que todos los derechos de la marca Java pasen a ser propiedad de Oracle.

¿Qué es Jakarta EE?

En 2017 Oracle decide que deja de controlar el desarrollo de Java EE y decide pasarlo a la comundidad para que sea guiado en un proceso más abierto y flexible por la Eclipse Foundation. Manteniendo el modelo de JCP que se seguía en su desarrollo.

Si bien en este proceso de traspaso se decide no pasar la marca Java EE y la comunidad tiene que renombrar el proyecto a Jakarta EE. En este proceso de renombrado, otros elementos como el servidor Glassfish también se han visto afectados y ahora se llama Eclipse Glassfish.

El nombre Jakarta EE es elegido por la comunidad Eclipse en una votación entre Jakarta EE y Enterprise Profile.

Así que Jakarta EE pasa a ser la nueva plataforma opensource de Java EE gestionada por Eclipse Foundation.

Además los paquetes deJakarta EE , que en Jakarta EE 8.0 se mantuvieron iguales, han pasado a ser jakarta.* en Jakarta EE 9.0. Desapareciendo los javax.* De esta forma tenemos, entre muchos otros:

• jakarta.activation
• jakarta.annotation
• jakarta.batch
• jakarta.decorator
• jakarta.ejb
• jakarta.faces
• jakarta.json
• jakarta.mail
• jakarta.security
• …

Versión de Jakarta EE

La versión actual de Jakarta es Jakarta EE 9.0 que fue publicada en noviembre 2020. En esta versión el cambio principal ha sido el renombrado del namespace por el de jakarta.*.

Contamos con el servidor Glassfish 6 para tener un soporte de Jakarta EE 9.0. Otros como Payara 5 , Tomcat 10, Jetty 11 y Wildfly 22 dan soporte a Jakarta EE 8.0.

Futuro de Jakarta EE

Parece que de momento Jakarta EE y Java EE van a seguir vidas paralelas. Tendiendo Jakarta EE un proceso más flexible y gestionado por la comunidad. Parece que el único que queda es Jakarta EE dirigido por la comunidad. Pero veremos que nos depara el futuro de Jakarta EE.

Principales Competidores

No creáis que Jenkins es la única que sabe hacer este tipo de cosas. Existen en el mercado otras muy decentes, a la par que potentes, que le plantan cara:

Azure DevOps

Microsoft optó por ofrecer junto a su plataforma Azure DevOps toda una suite de herramientas para la Integración Continua y los Despliegues. Aquí el Multibranch se llamaría Build el cual genera un artefacto que desplegará la parte de Release (el equivalente cercano del Freestyle). La principal diferencia es que este está enfocado al Drag & Drop de un conjunto de cajitas configurables que ofrecen una funcionalidad concreta. Como lo del pipeline as code se ha puesto muy de moda, los chicos de Micro están permitiendo guardar las configuraciones en formato yml, que aunque no es tan flexible como Jenkins permite que los almacenemos y metamos en un control de versiones. Una cosa que es inresante remarcar es que, si no dispones de infra, Azure te presta la suya para que tires millas a un coste razonable.

Bamboo

Bamboo sigue una técnica similar a la anterior. Puede ser una herramienta factible para aquellos que dispongan de otras de la suite de Atlassian, por las integraciones de caja que que ofrece. No obstante, Atlassian está moviéndose muy rápido a su formato SaaS y todo apunta a que terminará desconinuando esto para seguir mejorando la nueva Bitbucket Pipelines. Aunque aún es un poco joven y no dispone de demasiados plugins, todo apunta a que se covertira en una opción que ocupará buena tajada en el mercado.

Travis CI

Travis CI es otra opción más que interesante. Está a la cabeza de las soluciones SaaS y es largamente conocida por su amplia cartera de tecnologías soportadas. Una de las características que la hacen más potente es la matriz de test que permite ejecutarlos sobre nuestro software con diferentes configuraciones de versiones de sus paquetes, dependencias, etc. Y además soporta Docker por lo que no tendrás problema para ejecutarlos en las mismas condiciones que tus entornos (y tienen MACs, una máquina complicadísima de simular o integrar en casa). Te interesará saber que hay planes gratuitos para proyectos OpenSource!!.

Conclusiones

En definitiva, DevOps como paradigma, cada vez dispone de más adeptos, y con ellos, la cantidad de herramientas de todos los sabores está creciendo en los últimos años. Si bien, Jenkins está a la cabeza y sigue apretando fuerte gracias a los amigos de Cloudbees, desarrolladores principales de su fuente (porque Jenkins es OpenSource). Ellos, además de comercializar una versión con soporte, ofrecen otra suerte de herramientas muy útiles para otros segmentos de DevOps un tanto más avanzados que el ya tradicional CI & CD. Os animáis a hacer algún pipeline? Pues tenemos en el horno un post que mete las manos en harina y os acompaña a tirar uno sencillito pero muy didáctico.

Espero que os haya gustado las alternativas a Jenkins, ¿cuál es vuestra preferida?

Jenkins entiende que un pipeline no es otra cosa que una distribución de pasos, de pequeñas tareas, las cuales concatenadas (o paralelizadas) consiguen aquello que se conoce como Integración o Despliegue (los conceptos de “continuo” que suelen acompañar a estos dos conceptos son un apostrofre que habla de una dinámica, de un paradigma de desarrollo que consiste en hacer estas dos cosas mucho y con cada cambio de los fuentes del sofware).

Para echaros un cable a aquellos que quieran atreverse a dar los primeros pasitos en este mundillo, he aquí una introducción en su herramienta más importante.

Esperemos que os ayude =)

Conceptos básicos

Básicamente, en Jenkins trabajamos con:

Un Pipeline

First things firts. Qué es un pipeline?? Pues bien, tan simple como un flujo de tareas que se ordenan. Cuando planteemos un pipeline siempre debemos pensar en sus extremos:

• El final. La pregunta aquí es qué queremos conseguir y cuál es el elemento de salida que va a generar (un objeto, un cambio en un sistema, un evento…)
• El pricipio. Cuál es el triger que iniciará su ejecución?

Parece una tontería, pero este señor requiere tener la cabeza muy estructurada…

Aunque Jenkins sirve para automatizar cualquier cosa, su propósito original fue dedicarlo para temas de Integración Continua y Despliege. No es un martillo que sirva para todo pero no cerréis la mente a sus posibilidades. Con la experiencia sabréis discriminar qué situaciones Jenkins tiene la potencia suficiente como para cubrirlas y en cuáles se nos queda corto.

Mi mejor consejo cuando queráis hacer un pipeline es que apliquéis siempre el patrón de única responsabilidad. Más vale concatenar múltiples pipelines para alcanzar un objetivo mayor que construir flujos megalómanos que luego no hay Dios que entienda… ni mantenga…

Un Conjunto de pasos

Más arriba, en la introducción, ya hablamos de los pasos. Digamos que un paso (o step) es la unidad más pequeña que tiene integridad propia en un pipeline. Esto quiere decir que se trata de cierta tarea, apenas unas pocas líneas de código ;), que tienen como propósito realizar una funcionalidad muy concreta. MUY CONCRETA.

No os lieis con gigasnipsets. Recordad el principio de única responsabilidad. En mi opinión, más vale hacer un pipeline de pasos muy granulares que uno que solo disponga de 3 pasos muy extensos y ya. Ahora bien, cada paso debe añadir valor, tiene que ofrecer algo que le dé entidad y que no sea una símple operación de sistema operativo (lee o imprime algo). La funcionalidad debe ser acotada pero que represente algo para la semántica del pipeline que estamos construyendo.

Cada vez que hagáis uno, pensad que queréis venderlo.. de hecho, y aunque es un concepto complicado, se pueden agrupar estos pasos en librerías y construir así nuestro propio framework de pasos. Esto es un tema un tanto avanzamos que mejor requiere verlo en un post independiente.

A Groovy

Vale, ahora quiero implementar un paso. Con Jenkins no nos abandona el código.

Groovy es el lenguaje principal de Jenkins. A aquellos que manejen Java, no le verán ningún problema. De hecho se trata de un Java “tuneado” y simplificado para hacer scripts de este tipo.

Jenkins tiene sus complicaciones, pero el lenguaje base no es una de ellas.

Ahora bien, podéis hacer vuestros pasos en el idioma que queráis. Si instaláis las librerías de vuestro lenguaje favorito en la máquina donde corre Jenkins, podréis ejecutar cualquier tipo de script. De hecho DevOps pide a gritos ser poliglota dado que no todos los lenguajes están optimizados para lo mismo. Por ejemplo, Python dispone potentes librerías para hacer operaciones complejas, y Perl viene muy a mano para tratar expresiones regulares. Pero sin ir mas lejos, interactuar con el SO mediante un shell script es de lo más habitual que encontrarás.

Dos maneras de describirlo

Para describir la secuencia de pasos, es decir, para ordenar los steps que compondrán nuestro pipeline, existen dos maneras. Ambas igual de potentes:

• La freaky. Consiste en describir con Groovy “a pelo” todos los pasos, abriendo y cerrando llaves de Ifs que nos permitirán evaluar “si sucedió esto antes”, ahora “ejecuta este step”.
• La moderna. Se trata de definir en un json llamadas a una serie de funciones (que son cada step) una detras de otra.

Aquí otro consejo, que no os engañen, la primera manera es más molona, más compleja y menos “práctica”. En una empresa buscamos sobre todo legibilidad, mantenibilidad y sobre todo funcionalidad. La forma moderna es mucho mejor en las dos primeras e igual de potente en la tercera.

Hace tiempo ya los ingenieros de Jenkins se dieron cuenta de esto e inventaron un DSL (Domain-Specific Language), es decir, una manera compacta de especificar lo mismo pero dando técncias que orienten el lenguaje al propósito (o dominio) que debe describir.

Maestros y esclavos

En todas las operaciones hay alquien que manda y otro (o algunos) que ejecutan.

Para Jenkins, el Maestro es el centro de operaciones, un punto logístico que se encarga de disparar los pipelines y centralizar la información del resultado de todos ellos. No solo eso, si no que es el punto con el que interactuaremos para configurar todas las capacidades que queramos habilitar en Jenkins.

Sin embargo, los esclavos son individuos que despiertan cuando el Maestro tiene una tarea que delegar. El Maestro recibe el evento de que debe ejecutarse un nuevo pipeline y ordena a los esclavos que ejecuten sus pasos.

Es interesante tener en la cabeza que un pipeline puede ejecutarse enteramente con único esclavo, pero los ingenieros solemos utilizar varios durante un mismo pipeline. Esto es porque creemos muy fuerte en el que “quien mucho abarca, poco aprieta” y un solo individuo es imposible que sea bueno en hacer de todo. Por esto preparamos disintas tipologías de esclavos que trabajan juntos para resolver un pipeline. De hecho tenemos esclavos para trabajar con Java, otros con .Net, con Python… ahora, gracias a los contenedores Docker esto se ha hecho tan fácil…

Dos tipos distintos de pipelines

Bueno, no sólo hay dos.. hay unos cuantos, pero los más famosos son:

• Multibranch pipeline
• Freestyle pipeline

El primero, el Multibranch, tiene un propósito muy concreto. supervisará un repositorio de git y explorará todas las ramas buscando cambios. Este tipo se usa casi exclusivamente para la Integración Continua. Al final, lo que pretendemos con esto es ejecutar un pipeline (que mezcle con otras ramas, que compile, pase test, empaquete, versione, etc.) cada vez que se descubra un nuevo cambio en una de nuestras rámas del código.

Sin embargo, el segundo está pensado para ejecutarse o bien de forma manual, un despliegue a pulso de click o de forma reactiva a otro tipo de evento (otro pipeline a terminado). Por ejemplo, nosotros lo usamos para disparar un despliegue cuando termina una Integración Continua satisfactoriamente y alcanzar así el Despliegue Continuo.

Un sin fin de plugins

Por suerte, no todos las tareas hay que “picárselas”. Jenkins dispone de un amplio catálogo de plugins que incorporan funcionalidad específica a nuestros pipelines. Y es esta una de las grandes ventajas de la herramienta.

Como buenos techies muchas veces nos dejamos llevar por la arrogancia de querer implementarlo todo nosotros, como si fuéramos infalibles. Pues bien, es un error. Nuestra potencia como ingeniero DevOps está en perjiñar un pipeline, de conceptualizarlo, y desarrollarlo rápido y de forma robusta. Es nuestra industria la que está en juego!! Recordad que los mantras de DevOps pretenden hacer llegar el software mucho al usuario final y hacerlo ágilmente. Cuando Jenkins falla demasiado se convierte en un incordio más que una ayuda, y nació para esto último. Nuestra foco debe estar en descubrir cada vez más escenarios que necesitan ayuda y podemos optimizar.

La comunidad es muy buena en liberar nuevas capacidades, y un código probado mucho es mejor que uno molón.

Espero que os haya gustado y ahora sepáis un poco más sobre ¿qué es Jenkins?.

Lo primero que hacemos en el proceso de instalación es seleccionar el idioma en el cual queremos instalar Drupal. Aquí podremos elegir entre una serie de idiomas para iniciar el proceso: inglés, español, alemán,…

Si por ejemplo realizamos la instalación en español veremos que el proceso de instalación nos va a decir algo así como:

"The translations directory does not exist. The installer requires that you create a translations directory as part of the installation process. Create the directory sites/default/files/translations . More details about installing Drupal are available in INSTALL.txt."

Así que deberemos de acudir a dónde estamos instalando Drupal para poder crear el directorio /sites/default/translations. Pero no solo deberemos de crear el directorio, si no que deberemos de asignarle los permisos 555 a dicho directorio. Es decir, estamos dejando leer y ejecutar sobre dicho directorio a todos los usuarios.

Lo que sería ejecutar la siguiente secuencia de comandos en la consola.

mkdir ./sites/default/files/translations
chmod 555 ./sites/default/files/translations

Hay que decir que aunque el proceso de instalación habla de permisos 555, en mi caso he tenido que darle permisos 755, es decir, el propietario del directorio puede también escribir en él, para poder realizar el proceso de instalación.

De esta manera ya saber que te tocará modificar manualmente algunos directorios a la hora de instalar Drupal.

Cuando trabajamos con CMS que funcionan bajo PHP y el servidor Apache como puede ser WordPress o Drupal nos podemos encontrar con un error que nos viene a decir algo así como “Fatal Error: Maximum Execution Time Exceeded”. Error que nos puede llevar por la calle de la amargura cuando intentemos solucionarlo.

¿Qué está sucediendo en estos casos? Básicamente es que el servidor Apache está cortando la ejecución de un código PHP que se está excediendo en el tiempo de ejecución y que por lo tanto puede afectar al rendimiento general del servidor Apache. Es decir, se ejecuta como medida de control sobre la ejecución del código y evitar que se produzcan conexiones a la base de datos de larga duración o casos de bucles infinitos que harían que el programa PHP no acabase nunca.

Es por ello que el servidor Apache viene con una configuración en la que a los 30 o 60 segundos procede a cortar la ejecución y genera el famoso “Fatal Error: Maximum Execution Time Exceeded”.

Cuando trabajemos con CMS del tipo WordPress o Drupal veremos que este error puede producirse en los procesos de instalación o en ciertas ocasiones cuando se conecta a la base de datos en búsqueda de contenido.

Configurar max-execution-time

Si queremos cambiar este comportamiento deberemos de acudir a la configuración del servidor y en concreto a modificar el valor de la variable max-execution-time. Para poder modificar la variable max-execution-time tenemos dos alternativas.

La primera es aplicándolo a todo el servidor. Para ello deberemos de buscar la variable en el fichero de configuración del servidor Apache, es decir el fichero php.ini. En este caso lo que haremos será modificar el valor y asignarle el valor que queramos de tiempo máximo de ejecución en segundos.

max_execution_time = 300

En este caso le indicamos que el tiempo máximo es de 300 segundos, es decir, de 5 minutos.

Si no pudiésemos acceder a la configuración del servidor apache. Algo que sucede en algunos servicios de hosting, podemos realizar la configuración de max-execution-time en el fichero .htaccess. En este caos esta configuración solo aplicará a nuestra aplicación web.

Para ello añadiremos la siguiente sentencia en el fichero .htaccess

php_value max_execution_time 300

Nuevamente el valor va en segundo, por lo que serían 5 minutos de límite.

Ejecuciones infinitas

Hay una opción de indicarle al servidor Apache de que no corte la ejecución del código PHP independientemente de el tiempo que esta tome. En este caso es dándole el valor de 0 a la variale max_execution_time.

max_execution_time = 0

Lógicamente esta práctica no es recomendada para entornos productivos ya que podríamos dejar colapsado al servidor Apache teniendo que reiniciarlo para poder recuperar su ejecución.

Lo primero que tenemos que hacer para instalar Drupal es descargarnos la versión que queramos instalar. Para ello lo podemos hacer desde el área de descargas de Drupal dónde encontraremos la última versión de Drupal (A día de hoy Drupal 9.0.7) o bien podemos ir a la página de descargas de todas las versiones de Drupal dónde podemos encontra las versiones de Drupal 8 (a día de hoy Drupal 8.9.7) y Drupal 7 (a día de hoy Drupal 7.73), así cómo los múltiples fixes y minor version que tiene el producto.

Una vez hayamos decargado el fichero podremos descomprimirlo y veremos todos los ficheros que contiene Drupal.

Cuando tengamos descomprimido el fichero deberemos de chequear el fichero /core/install.txt que nos dará información relativa al proceso de instalación de Drupal, así como los requisitos mínimos que necesitaremos.

Requerimientos Instalar Drupal 8

Seguiremos la secuencia para instalar un Drupal 8.9.7. En el fichero /core/install.txt podremos encontrar los requerimientos para instalar Drupal, entre ellos encontramos

• Mínimo PHP 7.0.8. Recomendable 7.2.17 por temas de seguridad
• WebServer que soporte PHP. Recomendados:
  • Apache 2.0 o superior
  • Nginx 1.1 o superior.
• Una base de datos. En este sentido recomienda:
  • MySQL 5.5.3 o superior
  • MariaDB 5.5.20 o superior
  • Percona Server 5.5.8 o superior
  • PostgreSQL 9.1.2 o superior
  • SQLite 3.7.11 o superior

1: Copiar los ficheros

Si trabajamos con un servidor Apache lo que habrá que hacer es localizar la carpeta htdocs que es dónde procederemos a instalar Drupal y copiar sobre ella los ficheros. Esta carpeta estará en un sitio u otro dependiendo de la instalación.

Dependiendo de como hayamos instalado nuestro servidor Apache podremos localizar la carpeta en diferentes sitios:

• Para XAMPP en Widnows, la encontraremos en c:/xampp/htdocs.
• Para LAMPP en Linux, la encontramos en /opt/lampp/etc/
• Para Macs que vienen con un Apache la encontramos en /Library/WebServer/Documents
• …

Siempre podremos conocer la ubicación de htdocs y cambiarla en el fichero httpd.conf de Apache.

2: Arrancar proceso de instalación

Para poder arrancar el proceso de instalación lo que tendremos que hacer es acceder a la carpeta de nuestro servidor web dónde tenemos los ficheros. Por ejemplo http://localhost/drupal. Solo accediendo a la raíz del directorio dónde instalamos los ficheros de Drupal nos permitirá el arrancar la instalación.

3: Selección de Idioma

Lo primero será el elegir el idioma en el cual queremos instalar Drupal. El instalador nos ofrece múltiples opciones entre inglés, español, alemán,…

En el caso de que sea un idioma diferente al inglés, va a necesitar un fichero para guardar las traducciones, es por ello que deberemos de crear el directorio /sites/default/translations.

Pero no solo nos valdrá con crear el directorio /sites/default/translations si no que además deberemos de darle los permisos 555 o 755 para que el proceso de instalación pueda generar contenido en ese directorio.

4: Perfil de Instalación

Una vez pasado el proceso de elección del idioma vamos a selección del perfil de instalación. Los perfiles que nos ofrece son los siguientes:

• Estándar, instala las características de uso más comunes preconfiguradas.
• Mínimo, construye un sitio personalizado sin funcionalidades preconfiguradas.
• Demostración, nos instala un sitio de ejemplo que nos muestra algunas de las características de Drupal.

En nuestro caso vamos a elegir el perfil estándar. A partir de aquí Drupal verifica que las capacidades que necesitan están disponibles: servidor web, versión de PHP, extensiones PHP activadas, si está activado el caché OPCODE, si puede generar números aleatorios, si hay capacidades de la base de datos, el límite de la memoria PHP, capacidades UNICODE, si puede escribir en el sistema de ficheros y si existe el fichero de configuración.

Llegados a este punto puede darse que haya varios de los puntos que no tengamos configurados en nuestro sistema. Pero el primordial es que tengamos un fichero de configuración que es base para la instalación. Este fichero se puede encontrar en /sites/default/settings.php.

5: Configurar la base de datos

Lo siguiente será configurar la base de datos. Ya hemos visto más arriba las bases de datos que están soportadas. Para poder configurar la base de datos con Drupal tienes que indicarle los siguientes datos:

• Nombre de la base de datos
• Nombre del usuario de acceso a la base de datos
• Contraseña del usuario de acceso a la base de datos
• Servidor en el que se encuentra la base de datos. Si está en el mismo servidor de que instalamos el servidor web se podrá utilizar localhost.
• Puerto de conexión a la base de datos. Cada base de datos suele tener un puerto por defecto, como el 3306 de MySQL, pero puede ser que tu lo tengas configurado en otro puerto, así que aquí podrás indicar cual es dicho puerto. Por ejemplo el 55000.
• Prefijo de las tablas. Aunque se puede dejar vacío es bueno que des algún prefijo a tu instalación para diferenciar las tablas de Drupal.

Aunque Drupal te recomienda utilizar el prefijo drupal_, por motivos de seguridad es mejor que personalices tu prefijo. Sobre todo para no dar pistas de que tienes instalado un Drupal en tu sitio web.

Una vez configurada la base de datos pasaremos a realizar la instalación de Drupal.

Terminada la instalación es bueno que restauremos los permisos iniciales del fichero /sites/default/settings.php y solo dejarlos con permisos de lectura. Es decir, ejecutar la siguiente secuencia de comandos:

chmod 444 ./sites/default/settings.php

6: Configuración del Sitio

Cuando termine la instalación de los componentes básicos se procederá a realizar la configuración del sitio. Aquí podremos elegir cosas cómo el nombre que va a tener nuestra página web o el nombre del usuario que queremos que acceda al sitio.

Los datos que podemos rellenar son los siguientes:

• Nombre del sitio. Cómo se llamará nuestra página web.
• Dirección de correo del sitio. Para recibir notificaciones del sitio.
• Usuario de acceso. Aquí indicaremos el nombre del usuario con el que accederemos, así como su email y contraseña.
• Opciones regionales. Para poder configurar el país y zona horaria en el que se encuentra el sitio.

Una buena recomendación de seguridad es que el nombre del usuario con el que accedas al sitio no sea uno típico como admin, root o tu nombre. Utiliza un nombre de usuario que no sea identificativo.

Este será el último paso y ya estaremos en el Panel de Control de Drupal. De esta manera habríamos terminado de instalar Drupal.

OPcache es una extensión de PHP que nos permite mejorar el rendimiento de la ejecución del código PHP. Para ello OPcache almacena los scripts PHP precompilados en memoria para que puedan ejecutarse lo más rápido posible, evitando que se tengan que cargar y analizar cada vez que se piden.

OPcache está disponible de la versión PHP 5.5.0 en adelante.

Instalar OPcache

Lo más normal es que tu configuración de PHP ya traiga configurado el módulo de OPcache, en el caso de que no sea así deberás de añadir en el fichero php.ini la extensión

Para servidores en Linux y Mac:

zend_extension=/libreria/opcache.so

Para servidores en Windows:

zend_extension=C:\libreria\php_opcache.dll

Siendo la ruta librería el directorio dónde tengamos el módulo.

Configurar OPCache

Para configurar OPcache tenemos múltiples propiedades. Entre ellas encontramos algunas como:

• opcache.enable, habilita la caché de opcode. El valor que espera es un booleano, siendo 1 para activarlo.
• opcache.enable_cli, habilita la caché de opcode para la versión CLI de PHP. El valor que espera es un booleano, siendo 1 para activarlo.
• opcache.memory_consumption, es el tamaño en megabytes de la caché.
• opcache.interned_strings_buffer, es la cantidad, en megabytes, para almacenar cadenas.
• opcache.max_accelerated_files, el número máximo de ficheros PHP que se almacenarán en la caché. Curisoamente se utilizará el primer número primo superior al número que le indiquemos, siendo 200 lo mínimo que podemos configurar.
• opcache.revalidate_freq, marca la frecuencia en la que revalidaremos los scripts para actualizarlos. Se indica en segundos.
• opcache.fast_shutdown, es un valor booleano que activado permite una liberación rápida de la memoria en la secuencia de apagado.

Para estas propiedades la configuración recomendada por PHP de introducir en el fichero php.ini es la siguiente:

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Puedes encontrar mucha más información sobre lo que es OPCache en la documentación general de PHP.

OPcache y Drupal

El proceso de instalación de Drupal va a chequear que está activado el módulo OpCache para poder realizar la instalación. Ya que necesita el tener activado esta mejora de rendimiento para su ejecución.

En el caso de que no lo tengamos activado en nuestro fichero php.ini nos mostrará un error del estilo

Opcache warning (PHP OPcode caching not enabled) PHP OPcode caching can improve your site's performance considerably. It is highly recommended to have OPcache installed on your server.

Así que es bueno que configures Opcache en su instalación de PHP antes realizar la instalación de Drupal.

Drupal es un gestor de contenidos web, o más conocido por sus siglas CMS(Content Management System), que nos permite crear páginas web dinámicas. Las páginas web pueden ser simples blogs, tiendas de comercio electrónico, foros de debate o cualquier tipo de web.

Drupal es un software open source desarrollado en PHP que cuenta con una gran comunidad de usuarios.

Dentro de Drupal podemos identificar el core del gestor de contenidos que nos ofrece las capacidades básicas y los módulos que amplian las capacidades que ofrece el gestor de contenidos. Los módulos pueden ser desarrollados por cualquier programador para poder así extender las funcionalidades de Drupal.

Además Drupal permite personalizar la forma en la que se muestran las páginas web mediante el uso de temas. Los temas que pueden ser desarrollados por los propios usuarios permitirán ubicar el contenido en un sitio u otro de la web, así como aplicar los estilos que se necesiten para su visualización web o móvil.

Posiblemente, junto con Wordpress, Drupal sea de los gestores de contenidos más extendidos en el mercado.

Versiones de Drupal

Drupal se empezó a desarrollar por Dries Buytaert publicando el 15 enero de 2001 la primera versión de Drupal.

A día de hoy las versiones de Drupal activas son tres:

• La versión actual es Drupal 9, actualmente en su versión 9.0.7
• La versión más extendida e instalada es Drupal 8, de la cual podemos encontrar la versión 8.9.7
• La versión que se está retirando es la versión Drupal 7, de la cual podemos encontrar hasta la versión 7.73.

Principales características

Muchas son las características que podríamos enumerar de Drupal. Pero entre las principales caractéristicas encontramos:

• Flexibilidad, mediante Drupal podemos crear cualquier tipo de web que nos imaginemos. Las capacidades de extensión son enormes, llegando a permitir la exposición de contenido mediante servicios API Rest.
• Sotfware Libre, Drupal es un software libre y gratuito que podemos utilizar en cualquier sitio. Se puede descargar el código fuente de Drupal desde Github
• Comunidad Drupal, Drupal cuenta con una de las mayores comunidades de sotware libre y que contribuye mediante repositorios en Github, en múltiples foros, mediante entradas en blogs,…
• Soporte multilenguaje, podemos utilizar Drupal en mas de 100 idiomas. Además mediante sus módulos podemos crear sistemas muti-idioma de forma sencilla.
• Extensibilidad, su sistema de módulos permite extender el core de Drupal con nuevas capacidades.
• Taxonomias, permite definir conceptos de negocio que pueden ser gestionados en los diferentes elementos de Drupal, como pueden ser vistas, bloques,…
• Caché, cuenta con un sistema de caché que mejora el rendimiento a la hora de servir los sitios web dinámicos.
• SEO, facilita la gestión de un modelo SEO del contenido para favorecer su posicionamiento web.

¿Quién utiliza Drupal?

WordPress ocupa el primer lugar de los CMS más utilizados, seguido por Shopify y Joomla. En cuarta posición ya podemos encontrar como CMS a Drupal con un share del 1,6% -atendiendo a los datos de junio 2020 de Joost de Valk-.

Según Vardot dentro de los sitios más importantes que utilizan Drupal encontramos:

• Nasa
• Entertainment Weekly
• Tesla
• NCAA
• Mint
• El Gobierno Australiano
• Le Figaro
• …

Dónde descargarlo

Lo primero que tenemos que hacer para instalar Drupal es descargarnos la versión que queramos instalar. Para ello lo podemos hacer desde el área de descargas de Drupal dónde encontraremos la última versión de Drupal (A día de hoy Drupal 9.0.7) o bien podemos ir a la página de descargas de todas las versiones de Drupal dónde podemos encontrar las versiones de Drupal 8 (a día de hoy Drupal 8.9.7) y Drupal 7 (a día de hoy Drupal 7.73), así cómo los múltiples fixes