Cíclopes, sirenas y conexiones remotas – Gitea como redundancia de control de versiones

A día de hoy, las empresas y los desarrolladores no solo utilizan, sino que necesitan de algún tipo de control de versiones para su código, los usos son tan diversos como las diferentes herramientas en funcionamiento productivo y/o en desarrollo. Ejemplo de esto puede ser tener proyectos dedicados a micro-servicios de pasarelas de pago, este puede ser el caso de tiendas online, o banca en general; o,en un caso diametralmente diferente, podrían estar teniendo también en cuenta los diferentes playbook utilizados para re-establecer un servidor en caso de caída o una actualización mal ejecutada, como puede darse en casos de fallos en proveedores de servicio.

En el caso de un perfil de una persona como developer, utilizamos los sistemas de control de versiones para trabajar en equipo en diferentes funcionalidades y proyectos, también son utilizados entregar código para su compilación en herramientas de CI/CD, etc.

Servidores de control de versiones redundantes

Es aquí donde entra la duda de la redundancia, normalmente en ambos contextos, personal y profesional, contamos con un solo entorno de control de versiones (véase Github, Gitlab, Bitbucket…), muchas de estas opciones se pueden instalar en local/servidores on-premise a nivel corporativo o que permita el acceso a todos los miembros del equipo, para así tener más control de la infraestructura y el código en desarrollo. Normalmente esto es una situación segura, pero, ¿Qué pasa si ese servidor, o grupo de servidores, queda indisponible, más allá del impacto inicial que pueda tener una caída?

Lo normal es que salten todas las alarmas para equipos de Devops, infraestructura o similares, las acciones comunes en estos casos suelen ser, una vez asimilado que el servicio se encuentre caído, ejecutar las instrucciones necesarias para re-establecerlo. Fácil,sencillo e incluso obvio ¿no?. Pero, ¿Y si la máquina se encuentra apagada, o requiere de un reinicio manual, por pérdida de conexión con el CPD?¿Y si se trata de otro problema totalmente diferente, como un DNS que está impidendo el acceso, por ejemplo? Es una situación extraña y poco plausible, por supuesto, pero no imposible, cómo hemos visto recientemente en la caída de AWS.

Es aquí donde la redundancia de sistemas siempre será útil, en el caso del código es especialmente crítica, ya que debe estar disponible al máximo de tiempo disponible tanto para equipos productivos como desarrolladores.

Gitea, bueno bonito barato – Una solución para versionarlos a todos

Gitea es una solución open source disponible para una cantidad asombrosa de plataformas, que ofrece una respuesta a la necesidad de tener esta redundancia de control de versiones. Cabe destacar que para este artículo se ha escogido como entorno secundario, pero es perfectamente capaz de funcionar como herramienta principal para versionado en git.

Escrito en Go, se trata de un fork de Gogs, pero desde sus inicios en 2016, han cambiado muchas cosas.

A nivel productivo, cabe destacar que tiene integraciones con LDAP y otros servicios, como Azure Active Directory, lo cual simplifica el acceso de cuentas de usuario ya existentes en la organización.

Instalando Gitea en local, muchas opciones, un mismo destino.

Para este caso de estudio, se ha instalado Gitea en un contenedor que utiliza Alpine Linux como sistema operativo, se ha escogido debido a su tamaño ligero y habitual uso para entornos productivos (Docker, Kubernetes etc). Guía

Primero de todo, debemos tener en cuenta las capacidades del equipo y los requisitos a la hora de definir cuántos usuarios accederán, las especificaciones mínimas son:

• 2 CPU cores y 1GB RAM es normalmente suficiente para pequeños equipos/proyectos, en nuestro caso se trata de un contenedor con estas mismas especificaciones, más 512MB de Swap.
• Gitea debería ser ejecutado por cuentas de sistema no-root en sistemas tipo UNIX.
• Git version 2.0.0 o posterior.

Un gran poder, conlleva una gran responsabilidad

Una vez instalado y verificado que podemos acceder al servidor, es momento de establecer la estrategia de remotes, lo cual en líneas generales se hará en base a cada repositorio que queramos tener como redundante.

Como pequeño ejemplo, si tuvieramos nuestro servidor Gitea en la IP 178.16.1.123 y quisiéramos añadir un repositorio de prueba con código en JS, ejecutaríamos el siguiente comando.

git remote add gitea http://178.16.1.123:3000/prueba/ApplicacionPagos.gitLenguaje del código: JavaScript (javascript)

Y una vez quisieramos establecer una igualdad de push entre ambas instancias de git, podríamos, entre otras posibles soluciones, establecer un mirror, para evitar la cantidad necesaria de comandos a ejecutar.

git push --mirror gitea

Ahora bien, si por ejemplo, queremos tener varios Gitea distribuidos entre equipos, o bajo cualquier otra circunstancia, que nos requiera reinstalar este servicio, entra en juego la automatización y uso de tecnologías cómo Ansible, para hacer de estas instalaciones un protocolo más sencillo.

Para este artículo, hemos llevado a cabo un pequeño test, seguramente muy mejorable, pero nos ofrece un pequeño vistazo a los pasos que requeriría instalar este servicio utilizando tecnologías de automatización.

---
- hosts: gitea
  vars_files:
    - common_vars.yml
  become: yes
  tasks:
    # https://wiki.alpinelinux.org/wiki/Gitea  
     - name: Update repositories
       community.general.apk:
         state: latest
         update_cache: true  

     - name: Install Gitea, Mariadb & Python requirements     
       community.general.apk:
         name: 
           - gitea
           - mariadb
           - mariadb-client
           - python3
         state: present

     - name: Initialize MariaDB Data dir
       ansible.builtin.command:
         cmd: mysql_install_db --user=mysql --datadir=/var/lib/mysql
         creates: /var/lib/mysql/mysql

     - name: Start & Enable mariadb service
       ansible.builtin.service:
         name: mariadb
         state: started
         enabled: yes

# mysql_secure_installation

# Requirement
     - name: Packaging dependencies
       community.general.apk:
         name:
           - py3-pymysql
           - py3-packaging
         state: present

     - name: Create .my.cnf for future authentication
       ansible.builtin.template:
         src: my.cnf.j2
         dest: /root/.my.cnf
         mode: 0600
       no_log: true

     - name: Set MariaDB root password
       community.mysql.mysql_user:
         name: root
         password: "{{ mysql_root_password }}"
         check_implicit_admin: true

     - name: Remove anonymous user account for localhost
       community.mysql.mysql_user:
         name: ''
         host: localhost
         state: absent 

     - name: Remove remote access to mysql root account
       community.mysql.mysql_query:
         query:
         - DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');   
Lenguaje del código: PHP (php)

Si quisieramos llevarlo un paso más allá, cabe destacar que existe más información sobre cómo Ansible puede automatizar despliegues, aquí

Aquél que controle git, controlará el universo

Gitea es una herramienta completa y ligera, que puede servir y ser implementada a muchos niveles y entornos tech, ¿Quieres alejarte de las big tech que ofrecen servicios online, vulnerables a caídas, errores humanos, o el siempre temido DNS? ¿O bien quieres tener mayor control sobre el código que manejan los desarrolladores de tu equipo?. No solo es de instalación rápida, sino que es fácilmente integrable con proveedores de identidad.