Gitlab

Entornos efímeros para un proyecto.

Submitted by Oskar on Thu, 27/10/2022 - 21:52

El otro día me pedían que analizase la petición de un cliente, el cliente planteaba la necesidad de realizar una teréa periódica de forma manual, no llevaría más de 2 o 3 horas como mucho, una vez al mes, y otra tarea anual que llevaría unas cuantas horas, pero que en cómputo general entre las dos tarenas no supondría más de +-40 horas.

Las tareas a realizar son:

  • Generar un informe.
  • Subir el informe a un directorio en un servidor.
  • Comunicar por correo electrónico la ejecución de la tarea.


Eso a todo el mundo le puede parecer perfecto, tareas que se repiten 1 vez al mes, pero uno de mis muchos TOCS es la automatización de tareas, sobre todo cuando son tareas repetitivas, mecánicas y que se pueden programar, así que me puse a pensar como sería la forma más sencilla para montar un robot que ejecutase la tarea.

Montar un robot en PHP es sencillo, existen varios "task runners", posiblemente el más conocido de todos ellos es Robo.li, pero existen otras alternativas como programar comandos en Symfony con una instalación mínama o en otro caso se puede plantear con algún otro microframework que trabaje con CLI como Minicli, en resumen programar la ejecución de las tareas será entretenido ya que será código puro y nada de front-end.

A lo que más le di al coco era a la arquitectura de sistemas, y veía tres opciones, un proyecto web levantado todo el rato que se ejecuta con un cron definido, un proyecto web que se levantase bajo demanda la arquitectura y que una vez finalizado se apaga, pero aunque esta apagado siempre esta encendido esperando una petición, un entorno efímero que se levanta para ejecutar la tarea y luego se vuelve a caer,  el sistema se levanta cuando se tiene que ejecutar la tarea y luego se apaga el entorno y no es accesible.

 

Para mi las ventajas de un entorno efímero son los siguientes:

  • Se levantan los entornos únicamente cuando se tienen tienen que llevar a cabo las tareas, luego se apagan, y no vuelven a ser accesibles, más seguros.
  • Al esta apagados consumen menos recursos del sistema dejando recuros para otros proyectos que si necesiten estar levantados todo el rato.

Las desventajas que le veo

  • Al ser un entorno completamente en PHP-CLI es más dificil de depurar, pero no imposible.
  • Al ser un entorno efímero posiblemente no existirá una bbdd, la mejor opción en esos casos habría que ver como registrar los logs del sistema en algún lado.
  • Es necesario tener un cron-job que levante todo el entorno, ejecute el proceso y luego vuelva a apagar todo.
  • Seguramente se tenga que construir uno o más contenedores de Docker para llevar a cabo todas las tareas.

 

La propuesta de arquitectura es sencilla:

Desplegar proyectos en un servidor con Cpanels con Gitlab pipeline y lftp

Submitted by Oskar on Tue, 04/01/2022 - 18:00

La idea es sencilla, poder desplegar un proyecto que tienes en un repositorio de Gitlab, en este caso un proyecto de Drupal, en un servidor gestionado mediante Cpanels y que no tenemos acceso vía SSH, lo que sería un servidor compartido de toda la vida.

 

Paso 1

Lo primero que tenemos que hacer es crear en el servidor con Cpanels el proyecto, la cuenta FTP para acceder al proyecto.

 

Paso 2

Lo segundo es dar de alta un proyecto en Gitlab, no me voy a parar a explicar esto, aquí os dejo un vídeo donde se explica como hacerlo, únicamente que para este ejemplo he creado una rama devel que es con la que hago todo, obviamente se puede cambiar por cualquier otra rama.

 

 

Paso 3

Aquí os dejo también como montar un Pipleline en Gitlab, luego entraré yo al detalle, pero como "entrante" viene bien si no conoces como funciona.

 

Lo importante en este caso es la configuración de las variables que vamos a usar en el pipeline, que son los valores para conectarnos vía FTP (obviamente tenemos que haber creado un proyecto en el servidor de CPanels, y tener una cuenta de FTP para acceder a los directorios de ese proyecto).

 

En el menú lateral izquierdo del proyecto en Gitlab accedemos a Settings > CD/CI

Image
gitlab > proyect settings > cdci

 

En la página que se carga expandimos las opciones de variables:

Image
Variables cdci gitlab

 

Creamos las variables en el botón Add variable:

Tome y gitlab pages para crear páginas estáticas de forma rápida y sencilla.

Submitted by Oskar on Sat, 20/03/2021 - 10:16

Vamos a ver esta magnífica unión para tener una web estática (html, css, y js) de forma rápida y sencilla.

Gitlab es una saas que tiene varios servicios, entre ellos ofrece la posibilidad de alojar páginas estáticas de forma sencilla, para hacerlo nos tenemos que fijar en esta sección de la documentación de Gitlab: User and Group website examples, y también en esta otra sección de la documentación de Gitlab: Specific configuration options for Pages.

Por otro lado vamos a usar Tome, que es un módulo de Drupal 8||9 que permite exportar el contenido de nuestra página web a contenido estático, la documentación de Tome esta aquí.

 

Ahora vamos a la miga de todo esto (en realidad es muy sencillo), para casar Tome con Gitlab Pages, tenemos que entender una cosa, tenemos que definir en Drupal una carpeta donde Tome se encargará de guardar todo el contenido estático, por seguridad y organización en la carpeta donde tenemos los archivos devueltos por Tome no tenemos ni el directorio .git, ni los archivos .gitignore, ni .gitlab-ci.yml. Yo lo que he hecho es crear un directorio llamado public_tome, y dentro de él otro llamado html, es este segundo directorio el que guarda todos los archivos generados por Tome, mientras que dentro de public_tome guardamos todo,  el directorio html sería como el docment_root y el resto de elementos son los que queda fuera del document_root.

 

Image
Gitlab Pages + Tome estructure static folders

 

Con esta estructura ya construida editamos el archivo de configuración (settings.php o settings.local.php) y añadimos lo siguiente:

$settings['tome_static_directory'] = '../public_tome/html';

Con esta configuración Tome despliega los archivos en la ruta que queremos.

El siguiente paso es configurar el archivo gitlab-ci.yml, este archivo es un archivo de configuración de pipeline que nos permite indicar (de forma sencilla) que queremos hacer durante el pipeline, lo importante para nosotros es la parte de script que es donde indicaremos que parte queremos copiar al servidor de estáticos de Gitlab.

Subscribe to Gitlab