LEAMO
This commit is contained in:
parent
7e4eb3f21f
commit
868393a045
86
README.md
86
README.md
@ -1,36 +1,49 @@
|
||||
# QUÉ | CHEM |
|
||||
Es un programa para para mantener una infraestructura como código.
|
||||
# QUE ES ESTO?
|
||||
Es un programa para para mantener una infraestructura como código. Es como la receta de todo lo que hay que hacer para crear nodos pero ejecutable.
|
||||
|
||||
Por ahora, solo diremos que es un comando en la terminal.
|
||||
La idea es reducir todo a un minimo de comandos de consola para conectarse al vpn y al proxy.
|
||||
|
||||
Que mantiene un anillo de servicios interoperando. Pero en un solo comando. *-- one ring to rule'm all...*
|
||||
Reducir todo a un solo comando. *-- one ring to rule'm all...* y un solo archivo de configuración que es **abyayala.yml**
|
||||
|
||||
Con
|
||||
Ese comando se llama Ansible y ejecuta un playbook.
|
||||
```
|
||||
ansible-playbook
|
||||
```
|
||||
|
||||
Recetas, playbooks, script. Son todas infusiones que hacen bailar tods lxs enanites que mantienen los servicios andando.
|
||||
Y especificando un par de parámetros, que se detallan más abajo, se ejecutan todos los demás comandos necesarios para crear un nodo en la red llamada **Abyaya.la**
|
||||
|
||||
En realidad, a medida que se adentren en el juego, verán que hay un par de recetas más. Recetas, playbooks, script. Son todas infusiones que hacen bailar tods lxs enanites.
|
||||
En realidad, a medida que se adentren en el juego, verán que hay un par de recetas más para tareas específicas en *tasks/*. Este es un juego de **roles** donde cada rol es uno de los softwares que interoperan para mantener el sistema.
|
||||
|
||||
Hay un archivo en especial que define est despliegue de interfaces virtuales disponibles por URLs en que consiste **abyayala.yml**
|
||||
|
||||
### Abyayala.yml
|
||||
Es un archivo YAML (Yet Another Markup Lang., como una especie de XML) en donde se define declarativamente la infraestructura del Proxy Nginx conectado con un VPN (Red Autónoma Pirata)
|
||||
Es un archivo YAML (Yet Another Markup Lang., como una especie de XML pero bien legible) en donde se define declarativamente la infraestructura del Proxy Nginx conectado con un VPN (Red Autónoma Pirata)
|
||||
|
||||
La RAP tiene capacidad de DHCP en una *red.comun* para circumnavegar redes privativas que puedan tener NAT, no permitir Port Forwarding, aplicar Firewalls y todas esas chingaderas nasty
|
||||
La RAP tiene capacidad de DHCP en una *red.comun* para circumnavegar redes privativas que puedan tener NAT, no permitir Port Forwarding, aplicar Firewalls y todas esas chingaderas nasty.
|
||||
|
||||
EL proxy tiene capacidad DE SSL/TLS con Let's Encrypt de la E.F.F. El certbot tiene capacidad wildcard *.subm.abyaya.la validando por registros DNS.
|
||||
EL proxy tiene capacidad de SSL/TLS con Let's Encrypt de la E.F.F. El certbot tiene capacidad wildcard **\*.subm.abyaya.la**, validando por registros DNS.
|
||||
|
||||
## Cómo probarlo
|
||||
|
||||
En consecuencia, el resultado de esto debiera ser (sic)administrar una red de servidoras en una VPN comun,
|
||||
por ende la maquina nebe poder resolver su nombre por ej. su.comun y a otrx.comun como IPv4 en el rango 10.13.12.1/24 y pingearse, o al menos a abyayala.comun que es el server ?)
|
||||
En consecuencia, el resultado de esto debiera ser (dis)administrar una red de servidoras en una VPN comun,
|
||||
|
||||
El 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
|
||||
|
||||
Además, debe existir el subdominio DNS **node.**abyaya.la en el cual cada node puede publicar sus servicios en internet.
|
||||
Estos son accesibles a través de SSL/DNS en un sub-sub-domain. Por ej. **https://sitio.node.abyaya.la** y convivir como vástagxs con una nube en **https://nube.node.abyaya.la**
|
||||
El server 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
|
||||
```
|
||||
|
||||
Los servidores DNS los provee Sutty, infraestructura autonoma de Argentina quienes ademas cuentan con redundancia y mas.
|
||||
Por otra parte, como resultado del despliegue de la segunda parte **(PROXY)**, es que el **servidor** debe publicar el subdominio DNS **node.**abyaya.la
|
||||
|
||||
En este, cada organizacion puede publicar sus servicios en internet. Estos son accesibles a través de SSL/DNS en **sub-sub-**dominios.
|
||||
|
||||
Por ej. **https://sitio.node.abyaya.la** y convivir como vástagxs con una nube en **https://nube.node.abyaya.la**
|
||||
|
||||
Los servidores DNS los provee *Sutty*, infraestructura autonoma de Argentina quienes ademas cuentan con redundancia y mas.
|
||||
|
||||
#### P.S:
|
||||
Lo que está resaltado así es código fuente
|
||||
@ -56,7 +69,7 @@ En realidad recomendaríamos mantener en mente que son dos dispositivos, la *tor
|
||||
|
||||
En desarrollo se puede emular con máquinas virtuales a las cuales configura su laptop. O se puede invocar directamente sobre un juguete para animarlo de vida.
|
||||
|
||||
# CÓMO SE USA | HOWTO |
|
||||
# CÓMO SE USA
|
||||
|
||||
# DESPLIEGUE DE LA RAP
|
||||
|
||||
@ -71,7 +84,7 @@ ansible-playbook --become tasks/rap.yml -e "nodo=chem host=rakiduam"
|
||||
```
|
||||
En donde:
|
||||
- **host**: es el nodo 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 arriba
|
||||
- **nodo**: es el nombre que le daremos, el cual debe coincidir con el que desplegamos en el proxy más adelante
|
||||
|
||||
|
||||
En este ejemplo, intentamos convertir nuestro localhost en un nodo
|
||||
@ -91,16 +104,29 @@ En la lista de **nodos** mantenemos los nodos autorizados para conectarse a la R
|
||||
- rap
|
||||
nodos:
|
||||
- marmite
|
||||
- chemka
|
||||
```
|
||||
Luego podemos volver a ejcutar el primer comando deploy de este manual. O si queremos ejecutar solamente la RAP utilizaremos el parámetro service, como se explica más arriba
|
||||
|
||||
```
|
||||
ansible-playbook deploy.yml -e "host=abyayala alt=abyayala service=vpn" --skip-tags=installation,proxy,rap
|
||||
- ka
|
||||
```
|
||||
|
||||
En este ejemplo, estamos salteando la parte de instalación para mayor velocidad y el proxy pues solamente queremos actualizar la VPN.
|
||||
Además, estamos salteando un paso específico, *porque no queremos pisar configuraciones locales de la RAP*
|
||||
### DEPLOY
|
||||
|
||||
De ahora en adelante, trabajaremos en el proxy. El único comando que vamos a necesitar es **deploy.yml"" y le especificaremos parámetros. Vamos viendo.
|
||||
|
||||
Cada vez que ejecutamos
|
||||
|
||||
```
|
||||
ansible-playbook deploy.yml -e "alt=abyayala host=hetzner"
|
||||
```
|
||||
Desplegamos los servicios definidos en el archivo abyayala.yml a nuestro servidor que esta en hetzner.
|
||||
|
||||
#### 1 - DEPLOY DE LA RAP
|
||||
|
||||
Para ser mas especificos, aqui utilizaremos el parametro **service** para ejecutar solamente la vpn.
|
||||
|
||||
```
|
||||
ansible-playbook deploy.yml -e "host=abyayala alt=abyayala service=vpn" --skip-tags=installation
|
||||
```
|
||||
|
||||
En este ejemplo, estamos salteando la parte de instalación para mayor velocidad.
|
||||
|
||||
# DESPLIEGUE SIMULTANEO DEL PROXY CON HTTPS Y DEL DNS
|
||||
|
||||
@ -120,7 +146,7 @@ Donde
|
||||
- **ssl**: habilita la conexión SSL/TLS en ese dominio y sus subdominios
|
||||
- **force_https**: igual al parámetro anterior, pero fuerza la conexión segura (no permitiendo http plano)
|
||||
|
||||
Luego, ejecutamos el comando deploy especificando en -e "..." sus parámetros
|
||||
Luego, volvemos a ejecutar comando **deploy** para actualizar el estado del host.
|
||||
```
|
||||
ansible-playbook deploy.yml -e "alt=abyayala host=hetzner"
|
||||
|
||||
@ -133,20 +159,16 @@ Los parámetros opcionales pueden ser:
|
||||
- **service**: limita al despliegie a un servicio específico, en lugar de actualizar todos
|
||||
|
||||
|
||||
También podemos utilizar parámetros de ansible, por ejemplo
|
||||
O también podemos actualizar la *configuración del proxy* de solamente **un nodo** especificandolo con **service**.
|
||||
```
|
||||
ansible-playbook deploy.yml -e "alt=abyayala host=hetzner" --skip-tags=installation,proxy
|
||||
ansible-playbook deploy.yml -e "alt=abyayala host=hetzner service=chem"
|
||||
|
||||
```
|
||||
Saltea dos partes del proceso, marcadas por tags. En este ejemplo, la instalación y la actualización de Nginx
|
||||
|
||||
|
||||
### DEPLOY LOCAL
|
||||
#### DEPLOY LOCAL
|
||||
|
||||
Para desarrollo, podemos desplegar en nuestro localhost así
|
||||
|
||||
```
|
||||
ansible-playbook --become deploy.yml -e "host=localhost alt=abyayala" -i hosts.local
|
||||
```
|
||||
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user