2025-07-03 02:28:49 +00:00
2024-10-15 10:30:16 -03:00
2025-03-07 14:58:55 -03:00
2025-06-18 15:44:57 -04:00
2024-09-06 12:27:48 -04:00
2025-06-18 21:41:42 -04:00
2024-09-10 10:50:21 -03:00
2024-09-02 13:11:18 -04:00
2025-07-03 02:28:49 +00:00

ABYAYA.LA

Este sistema automatiza el despliegue de la red Abyaya.la, mediante Ansible, un software de automatización de código abierto, que permite la gestión de configuraciones, el despliegue de aplicaciones y la orquestación de tareas.

  • Sintaxis basada en YAML, que significa "Yet Another Markup Language". Un formato de serialización de datos legible por humanes.
  • Se definien playbooks, que son scripts que automatizan secuencias de tareas y configuraciones.
  • Opera sin necesidad de instalar agentes en los nodos gestionados, ya que se comunica a través de SSH.

abyayala.yml

Así, gestionamos la infraestructura como código, en un único archivo de matriz abyayala.yml

Este describe los componentes a desplegar para qu esta red funcione. Podríamos dividirlos en dos grandes componentes:

La RAP

La Red Autónoma Pirata es la VPN que nos permite acceder a nuestros servidores, sin importar el lugar donde estén conectados.

Características
Red 10.13.12.1/24
DHCP Automático
Resolución de nombres Hostname (ej. ping ka.comun)

El PROXY

Es un servidor con una IP pública, a la que apuntamos el dominio abyaya.la.

Hace de proxy reverso para los demás servidores, ruteando el tráfico a cada servidor a través de la RAP.

Características
Subdominios para los servidores nuevo.abyaya.la
Servicios en los sub-sub-dominios Ej: https://sitio.nuevo.abyaya.la
Certificados Wildcard *.nuevo.abyaya.la

Cómo funciona

La idea es reducir todo a un solo comando único *deploy.yml", el cual leerá la matriz abyayala.yml para desplegar o actualizar, tanto a la VPN como al Proxy.

Componentes Principales

Estructura de Archivos

  • deploy.yml: Playbook principal, el "comando único"
  • abyayala.yml: Configuración principal (YAML) en donde se define declarativamente la infraestructura de ambos componentes (VPN y Proxy)
  • tasks/: Playbooks adicionales para tareas específicas
  • roles/: Cada rol configura un servicio del sistema

ALTA DE NODOS "EN 2 PASOS"

Esta se hace en dos partes, pues hay que configurarlo primero en el nodo de destino y después en el servidor del proxy.

1.1 - Autorizar nuevo nodo en la RAP...

También tenemos que avisar a la RAP, la cual se define en el archivo abyayala.yml, en el server_name: vpn

En la lista de nodos mantenemos los nodos autorizados para conectarse a la RAP

  - service_name: vpn
    roles:
      - rap
    nodos:
      - marmite
      - ka

Lo agregamos a la lista y ejecutamos el comando deploy.yml para autorizarlos.

Le especificaremos parámetros con - e:

ansible-playbook deploy.yml -e "alt=abyayala host=hetzner"

Así estamos desplegando entonces los servicios definidos en el archivo abyayala.yml, a nuestro servidor en hetzner.

Parámetros de deploy.yml

Los parámetros obligatorios son:

  • alt: nombre de nuestro servidor autónomo, en este caso siempre es 'abyayala'
  • host: nombre del servidor de destino en el archivo de inventario hosts.production

Los parámetros opcionales pueden ser:

  • service: limita al despliegue a un servicio específico, en lugar de actualizarlos todos

Siguiendo con el ejemplo anterior, utilizaremos el parametro service para ejecutar solamente la vpn.

ansible-playbook deploy.yml -e "alt=abyayala host=hetzner service=vpn"

1.2 - Instalar la RAP en el nodo

Para desplegar la RAP en nuestro nodo destino, utilizamos otro playbook, el script tasks/rap.yml especificando sus parámetros con -e "..."

ansible-playbook --become tasks/rap.yml -e "nodo=nuevo host=miservidora"

En donde:

  • host: es el nodo nuevo a configurar, según su definición en el inventario de ansible
  • nodo: es el nombre que le daremos, el cual debe coincidir con el que desplegamos en el proxy más adelante

2 - HABILITAR ACCESO HTTPS AL NUEVO NODO

Por otro lado, hay que actualizar al Proxy para que el nuevo nodo sea accesible por HTTPS, en un subdominio público.

Vemos que cada nodo debe tener una entrada en el archivo abyayala.yml, en donde se asocia su subdominio público con su nodo en la RAP, de esta forma:

  - service_name: nuevo
    domains:
      - nuevo.abyaya.la
    nodo: nuevo.comun
    ssl: yes

Donde

  • service_name: es un nombre arbitrario
  • domains: la unica entrada de domains es el subdominio principal
  • nodo: es el hostname del nodo en la RAP
  • ssl: habilita la conexión SSL/TLS

2.2 DEPLOY.YML

Luego de agregar nuestro nuevo nodo, volvemos entonces a ejecutar el comando deploy.yml para habilitar el acceso HTTPS a éste, y publicar ese subdominio.

En esta ocasión, lo acotaremos a actualizar la configuración de solamente un nodo, especificándolo con el parámetro service:

ansible-playbook deploy.yml -e "alt=abyayala host=hetzner service=nuevo"

TAGS

También hay tags que marcan secciones del código.

Por ejemplo se puede acotar aún más, saltándose todas las tareas de instalación con --skip-tags

ansible-playbook deploy.yml -e "alt=abyayala host=hetzner service=nuevo" --skip-tags=installation

INSTALACIÓN

Instalar Ansible

# Si tienen Python
pip install ansible

# Para sistemas basados en Debian/Ubuntu
sudo apt-get install ansible

# Para sistemas RHEL/CentOS
sudo yum install ansible

PREPARAR SSH

También deben tener sus llaves públicas de SSH añadidas tanto al nodo como al servidor de destino.

Generar clave SSH (si no existe)

ssh-keygen -t ed25519

Copiar clave pública al nodo de destino

ssh-copy-id root@nuevo.comun

ALTA DE USUARIXS EN EL PROXY

Para conectarse al proxy deben agregar sus llaves como dice a continuación:

  • Copiar la(s) llave(s) pública(s) de cada wayki en tasks/files/ssh/WAYKI.pub.
  • Agregarle en group_vars/all/ssh_users.yml (copiando la sintaxis)
  • Correr ansible-playbook tasks/users.yml -e "host=hetzner"

TESTING

Si todo anda bien, podemos probarlo así:

Conexión VPN

Como resultado del deploy de la primera parte (RAP), la máquina nodo debe conectarse a la red comun en IPv4 y en el rango 10.13.12.1/24 y poder pingear al server, que es 10.13.12.1

El proxy a su vez puede pingear a cada nodo por su nombre de host en la red comun. por ej.

root@proxy-reverso-escuela-comun:~# ping ka.comun
PING ka.comun (10.13.12.129) 56(84) bytes of data.
64 bytes from ka.comun (10.13.12.129): icmp_seq=1 ttl=64 time=169 ms

Acceso HTTPS

Por otra parte, como resultado del despliegue de la segunda parte (PROXY), el nodo debe ser accesible en el subdominio nuevo. abyaya.la

Los servicios de cada nodo son accesibles a través de SSL en sub-sub- dominios.

Por ej. https://sitio.nuevo.abyaya.la o https://nube.nuevo.abyaya.la


DEPLOY LOCAL

En este ejemplo, instalaremos todo en nuestro localhost para desarrollo, como si fuera un nodo del proxy.

ansible-playbook --become tasks/rap.yml -e "host=localhost nodo=nombrelo" -i hosts.local

Esto también es útil para instalar Ansible en nuestra terminal, junto con sus dependencias (Módulos para docker, etc.)

SSH PARA DESARROLLO

Para autoconectarse por SSH hay que autorizarse a sí mismx:

# Habilitar auto-conexión SSH
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
Description
Automatización de despliegue de proxy reverso mas red privada virtual y servidor DNS. Esta combinación permite alojar servicios localmente, pasando a través de cualquier instalación de red, sin necesidad de NAT, port-forwarding, etc.
Readme 425 KiB
Languages
Jinja 100%