Patrón de diseño Observer

 Observador (en inglés: Observer) es un patrón de diseño de software que define una dependencia del tipo uno a muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos los dependientes.

Patrón de diseño basado en eventos

La arquitectura dirigida por eventos es un tipo de arquitectura software que se basa en la producción, detención y procesamiento de eventos y, si se considera oportuno, la reacción ante ellos. En la mayoría de los casos, el dispositivo que genera un evento no es el mismo que el que lo recibe y procesa.

Esta arquitectura está compuesta por productores y consumidores de eventos. El primero detecta los eventos y los representa como mensajes. No conoce al consumidor del evento ni el resultado que generará este último.

Una vez que se detecta un evento, este se transmite del productor a los consumidores a través de canales de eventos, donde se procesa de manera asíncrona con una plataforma para este fin. Cuando se produce un evento, se debe informar a los consumidores, quienes podrían procesarlo o simplemente recibirlo.

Procesamientos de eventos

Una arquitectura de este tipo puede se puede procesar 2 formas:

• Publicación/suscripción-->la infraestructura de mensajería mantiene el seguimiento de las suscripciones. Cuando se publica un evento, se envía el evento a cada suscriptor. Después de que se recibe un evento, no se puede reproducir, y los nuevos suscriptores no ven el evento. (Rabbit)
• Flujo de eventos-->los eventos se escriben en un registro. Los eventos siguen un orden estricto (dentro de una partición) y son duraderos. Los clientes no se suscriben al flujo, sino que un cliente puede leer desde cualquiera de sus partes. El cliente es responsable de avanzar su posición en el flujo. Esto significa que un cliente puede unirse en cualquier momento y puede reproducir los eventos. (Kakfka). Hay varios tipos de flujo de eventos:
  • El procesamiento de flujos de eventos utiliza una plataforma de transmisión de datos, como Apache Kafka, para incorporar los eventos y procesar o transformar su flujo. Este procesamiento se puede utilizar para detectar patrones significativos en los flujos.
  • El procesamiento de eventos simple surge cuando un evento desencadena inmediatamente una acción en el consumidor.
  • El procesamiento de eventos complejo requiere que un consumidor de eventos procese una serie de ellos para detectar patrones.

Estructura del evento
Un evento puede estar hecho de dos partes, el encabezado evento y el cuerpo evento. El encabezado de evento puede incluir información como el nombre del evento, fecha y hora para el evento, y el tipo de evento. El texto del evento es la parte que describe lo que ha ocurrido en realidad.

Capas del flujo del evento
Una arquitectura de evento disparado se basa en cuatro capas lógicas:

1. Generador evento
2. Canal de evento
3. Motor de procesamiento de eventos
4. Actividad de descarga dirigida por evento

Diferencias entre patrón DAO y Repository

 Una de las principales diferencias entre DAO y Repository se halla en el nivel en el que se ubican. El primero se ubica en un nivel mas bajo, mucho mas cerca a la fuente de datos, mientras que el segundo se ubica al mismo nivel de la capa de modelo de dominio, un poco más arriba que el primero.

Patrón de diseño repositorio

Patrón de diseño DAO

 DAO es el patrón mas usado para realizar la persistencia de los objetos de dominio, la forma mas común y básica de este patron es una clase que contiene las operaciones CRUD (Create, Read, Update, Delete).

Este patrón nos permite separar la lógica del negocio con respecto a la lógica de persistencia, de esta forma se pueden crear variedad de implementaciones de persistencia (usando ORM o ADO.Net) sin que lleguen a afectar al dominio. El problema es que mayormente este patrón no tiene una responsabilidad bien definida y muchos lo toman como una pasarela para hablar con la base de datos, creando un método para cada posible consulta que se realice o por cada actualización parcial

Usando Docker y Jenkins

Vamos a instalar un jenkins dentro de un contenedor docker para ellos vamos a utilizar la imagen oficial de jenkins jenkins/jenkins.

Podemos hacerlo de dos formas:

• Comandos:

           Ejecutamos un contendor a partir de una imagen jenkins

                        docker run -p 8081:8080 -p 50000:50000 jenkins/jenkins

Abrimos un navegador web y accedemos a http://localhost:8081 para entrar en la consola de administración de Jenkins.

La contraseña que se solicita la podemos obtener en la salida de la  ejecución del comando anterior o ejecutando el siguiente comando:

                

                        docker ps | grep jenkins/jenkins

                        3183b39448bd   jenkins/jenkins:lts   "/sbin/tini -- /usr/…"   16 hours ago   Up 16 hours                           50000/tcp, 0.0.0.0:8081->8080/tcp, :::8081->8080/tcp   jenkins1

Con el identificador del contenedor (la primera cadena de caracteres) lanzamos el siguiente comando y obtendremos la contraseña que nos solicitan al acceder a localhost:8081 :

docker exec -it 3183b39448bd cat /var/jenkins_home/secrets/initialAdminP

Si queremos que los cambios que realicemos en la configuración de Jenkins persistan incluso tras la destrucción del contenedor, debemos arrancar el contenedor con un volumen:

docker run -p 8081:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins

• Crear una imagen Docker con Jenkins a medida: para no tener que repetir las configuraciones manuales en cada nueva instalación podemos construir una imagen Docker con Jenkins a medida con todo lo que necesitemos. Lo podemos hacer con el DockerFile, añadiendo las instrucciones que necesitemos para crear la imagen o con Docker Compose (docker-compose.yml) con el que podemos ejecutar una serie de servicios como diferentes contenedores donde tienen que interactuar entre sí.

Usar Compose es básicamente un proceso de tres pasos.

1. Defina el entorno de su aplicación con un Dockerfile para que pueda reproducirse en cualquier lugar.
2. Defina los servicios que conforman su aplicación en docker-compose.yml para que puedan ejecutarse juntos en un entorno aislado.
3. Por último, ejecute docker-compose up y Compose se iniciará y ejecutará toda la aplicación.

Estructura del DockerFile (vamos a utilizar lo mínimo)

FROM jenkins/jenkins:lts

LABEL MAINTAINER = PruebasDocker

Un ejemplo de utilización de Compose:

version: '3.8' -->

services:
  pruebas-jenkins-master:
    container_name: jenkins1

    build: .
    image: pruebas/jenkins:1.0.0
    ports:
      - "8081:8080"
    networks:
      - pruebas-ci-network  
    volumes:
      - pruebas-jenkins-master:/var/jenkins_home
      - /usr/bin/docker:/usr/bin/docker
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always  

  pruebas-sonarqube:
    container_name: sonarqube
    image: sonarqube:community
    ports:
      - "9002:9000"
    restart: always          

volumes:
  pruebas-jenkins-master:
    name: pruebas-jenkins-master

networks:
  pruebas-ci-network:
    name: pruebas-ci-network
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: 172.16.239.0/24   

Veamos que significa algunos parámetro del docker-compose:

Puedes encontrar todos los parámetros que podemos definir en la documentación oficial.

version: Los archivos docker-compose.yml son versionados, lo que significa que es muy importante indicar la versión de las instrucciones que queremos darle. A medida de que Docker evoluciona, habrá nuevas versiones, pero de todos modos, siempre hay compatibilidad hacia atrás.

services: contiene una configuración que se aplica a cada contenedor iniciado para ese servicio.

image: imagen desde la que iniciar el contenedor. Puede ser un repositorio/etiqueta o una identificación de imagen parcial.

ports:  publicamos los puertos al host y podemos especificar el mapeo (HOST:CONTENEDOR).

networks: Son las redes a las que se unirán los contenedores, referenciando las entradas debajo de las redes de nivel superior.

volumes:  Montamos rutas o volúmenes, especificamos una ruta en el host (HOST:CONTENEDOR), Igual podemos especificar modo de acceso (HOST:CONTENEDOR:rw)

container-name: especifica un nombre de contenedor personalizado, en lugar de un nombre predeterminado generado.

restart: always: Indicamos la política de reinicio del contenedor si por cualquier condición se para.

Archivo jboss-web.xml

El jboss-web.xml es un archivo XML que contiene el comportamiento específico de JBossWeb de una aplicación web.

Por ejemplo he necesitado cambiar el nombre del contexto de la aplicación y he añadido entre las etiquetas jboss-web  <context-root>nombre</context-root>