Changes

Page history
Revision completa de Entorno de desarrollo y operaciones authored by Santiago Martinez's avatar Santiago Martinez
Hide whitespace changes
Inline Side-by-side
Entorno-de-desarrollo-operaciones.md
View page @ 4c0a15b7
......@@ -7,43 +7,100 @@ Para automatizar el aprovisionamiento, la configuración y el mantenimiento de [
Trabajamos paralelamente, en forma distribuida pero coordinada, mediante [Git](https://git-scm.com/) (Es útil leer esta introducción a [Git](https://proyectos.interior.edu.uy/documents/162)).
Para el desarrollo de código, en este proyecto:
- se hace amplio uso de la instancia [GitLab del Interior](https://git.interior.edu.uy/explore/projects). Más concretamente en [este proyecto de acceso restringido](https://git.interior.edu.uy/adminsys/config), en el que mediante issues y ramas, vamos discutiendo, ordenando y documentando nuestro avance y nuevas metas a corto plazo.
- se hace amplio uso de la instancia [GitLab del Interior](https://git.interior.edu.uy/explore/projects). Más concretamente en [este proyecto de acceso restringido](https://git.interior.edu.uy/adminsys/config), en el que mediante issues y ramas, vamos discutiendo, ordenando y documentando nuestro avance y nuevas metas a corto plazo. Para tener acceso al proyecto debes tener una cuenta en [nuestra instancia del gestor de desarrollo GitLab](https://git.interior.edu.uy) y ser miembro del mismo (la inscripción está abierta para mails en .uy).
- los [roles Ansible](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html) de interés general y desacoplados nuestra infraestructura particular, se mantienen en nuesto espacio en [GitHub](https://github.com/UdelaRInterior), en el que interactuamos con la comunidad open source.
- contamos con una [lista de correo del equipo de trabajo](https://listas.softwarelibre.edu.uy/sympa/info/becarixs), pero también conversamos bastante por Telegram.
## Conformando nuestro entorno de trabajo personal
En el [README del proyecto](https://git.interior.edu.uy/adminsys/config) está (también) descrito como configurar un entorno de trabajo. De forma mas concreta (no hace doble empleo de esta página).
En el [README del proyecto](https://git.interior.edu.uy/adminsys/config) está (también) descrito como configurar un entorno de trabajo, pero de forma mas concreta (no hace doble empleo de esta página).
> *Nota previa:*
> Generá tu propio entorno en tu cuenta en la máquina que quieras. **Cuidado: ¡info sensible!** ten en cuenta que eres responsable de estos datos, por lo cual debes proteger el acceso a esa máquina y a tu cuenta. Para el acceso remoto SSH, uso obligatorio de [claves ssh pública/privada](https://proyectos.interior.edu.uy/projects/servidores/wiki/Acceso_en_ssh), con passphrase robusta.
> **Nota previa:**
> Generá tu propio entorno en tu cuenta en la PC que quieras. **Cuidado: ¡info sensible!** ten en cuenta que eres responsable de estos datos, por lo cual debes proteger el acceso a esa PC y a tu cuenta. Para el acceso remoto SSH, uso obligatorio de [claves RSA pública/privada](https://proyectos.interior.edu.uy/projects/servidores/wiki/Acceso_en_ssh), con passphrase robusta.
> En breve, se recomendará tener tal espacio de trabajo en una cuenta personal (con acceso SSH más passphrase) en la consola de administración ta.interior.edu.uy.
> A mediano plazo, mejoraremos la separación de los derechos, accesos y compartimentación de los espacios de producción, de desarrollo, pruebas e integración. Contra servidores en producción sólo se podrá actuar desde cierto contexto (ej: sólo desde ta.interior), con AVISO CLARO, eventualmente con autenticación específica.
> A mediano plazo, planeamos mejorar la separación de los derechos, accesos y compartimentación de los espacios de producción, de desarrollo, pruebas e integración. Contra servidores en producción sólo se podrá actuar desde cierto contexto (ej: sólo desde ta.interior), con AVISO CLARO, eventualmente con autenticación específica.
Instalá en tu máquina **Git** y **Ansible**. **Este último debe ser de versión reciente, al menos superior o igual a 2.7**, se logra fácilmente con los backports de Debian o el PPA oportuno de Ubuntu. Adicionalmente **será necesario instalar las librerías Python de las que depende nuestro proyecto**, actualmente son: ***jmespath*** y ***netaddr***. Pueden instalarse fácilmente mediante el gestor Python pip:
```
pip install netaddr
pip install jmespath
### Procedimiento:
* [Instalar Ansible](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) de versión reciente. Al momento de comenzar el proyecto, se trabajaba con la versión 2.7.5, disponible desde de los [backports de la Debian Stretch](https://packages.debian.org/source/ansible) y desde [PPA para Ubuntu](http://ppa.launchpad.net/ansible/ansible/ubuntu/).
**Instalar Ansible en Debian y derivados:**
```bash
sudo echo 'deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main' > /etc/apt/sources.list.d/ansible.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
sudo apt update
sudo apt install ansible
```
**Instalar Ansible en Ubuntu desde PPA:**
```bash
sudo apt update
sudo apt install software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install ansible
```
* Generar un par de llaves RSA (si todavía no tienes) para poder autenticarte en GitLab y acceder a los servidores de la plataforma. De acuerdo a [nuestros estándares](https://proyectos.interior.edu.uy/projects/servidores/wiki/Acceso_en_ssh), deberá ser una llave de 8192 bits con un *passphrase* robusto.
```bash
ssh-keygen -b 8192
```
* Obtener el código de `config` en una carpeta de trabajo limpia, por ejemplo `interior/`. La descarga se realiza clonando este repositorio privado, por lo que será necesario que tengas `git` instalado y [permitir en tu cuenta de GitLab](https://git.interior.edu.uy/profile/keys) el uso de la llave RSA pública del paso previo.
```bash
sudo apt update
sudo apt install git
mkdir ~/interior
cd ~/interior
git clone git@git.interior.edu.uy:adminsys/config.git
```
Se creará directorio llamado **config** (`~/interior/config`) con el código del proyecto dentro.
* Recuperar el archivo `contrasenha_vault`, que puedes encontrar en `bourdieu.csic.edu.uy:~/compartido/ansible/contrasenha_vault` (también en `ta.interior.edu.uy`) y ubicarlo en el mismo nivel que el directorio `config`, es decir, en `~/interior/contrasenha_vault`. Este archivo contiene la contraseña que descifra todos los archivos de variables protegidos (*vaults*) de los hosts gestionados con Ansible.
Para acceder a **Ta** o **Bourdieu**, previamente un adminsys debes haberte creado un usuario y otorgado acceso, preferentemente a través de llave RSA.
### Dos formas de continuar:
Finalmente es necesario instalar las dependencias del proyecto: librerías Python y [roles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html) de la [Ansible Galaxy](https://galaxy.ansible.com). Puedes hacerlo **manualmente :(** o usando un **¡playbook Ansible! :D** .
#### Automatizada:
Para usar el método feliz, tan solo debes ubicarte en la raíz del proyecto `config` y correr el playbook `entorno_dev_ops.yml`:
```bash
usuario@pc:~/interior/config$ ansible-playbook entorno_dev_ops.yml
```
Para acceder y descargar el proyecto [config](https://git.interior.edu.uy/adminsys/config), debes tener una cuenta en [nuestra instancia del gestor de desarrollo GitLab](https://git.interior.edu.uy) y ser miembro del mismo (la inscripción está abierta para mails en .uy).
Una vez finalizada la ejecución satisfactoria del playbook, ya tienes todo lo necesario para desarrollar y operar la plataforma de servidores.
- Comenzá creando una carpeta de trabajo limpia, por ejemplo **'interior/'**. Ubícate dentro de ella en una terminal y clona el repositorio del proyecto **config**:
```
usuario@pc:~/interior$ git clone git@git.interior.edu.uy:adminsys/config.git
```
Se creará directorio llamado **config** con el código del proyecto dentro.
#### Manual:
- Luego necesitas recuperar el archivo **contrasenha_vault**, que puedes encontrar en la consola de administración de la vieja plataforma **bourdieu.csic.edu.uy:~/compartido/ansible/** (próximamente también en ta.interior.edu.uy) y ubicarlo dentro de **interior/**.
Este archivo contiene la contraseña que descifra todos los archivos de variables protegidos (*vaults*) de los hosts gestionados con Ansible.
* Comenzamos instalando las librerías/paquetes Python: `netaddr`, `jmespath` y `zabbix-api`, dependencias de nuestros playbooks:
- Por último necesitarás descargar los roles Ansible de los que **config** depende. Algunos se encuentran en la [galaxia de Ansible](https://galaxy.ansible.com) y otros se encuentran directamente publicados en nuestro espacio de GitHub. Esta tarea es muy sencilla gracias al archivo **requirements.yml** ubicado en la raíz del proyecto, que lista todos los roles de los que se depende. Deberás ubicarte en **interior/config** y ejecutar lo siguiente:
**Instalar el gestor pip y los paquetes Python en Debian y derivados:**
```bash
sudo apt update
sudo apt install python-pip
pip install netaddr # O mediante APT: sudo apt install python-netaddr
pip install jmespath
pip install zabbix-api
```
* Por último necesitarás descargar los roles Ansible de los que `config` depende. Algunos se encuentran en la [galaxia de Ansible](https://galaxy.ansible.com) y otros directamente publicados en nuestro espacio de GitHub. Esta tarea es muy sencilla gracias al archivo `requirements.yml` ubicado en la raíz del proyecto, que lista todos los roles de los que se depende. Deberás ubicarte en `interior/config` y ejecutar lo siguiente:
```bash
usuario@pc:~/interior/config$ ansible-galaxy install -r requirements.yml -g
```
Verás como los roles se descargarán uno a uno. Una vez finalizada la descarga, dentro de **interior/** contarás con un nuevo directorio llamado **UdelaRInterior**, con los roles deseados organizados en subcarpetas.
Verás como los roles se descargarán uno a uno. Una vez finalizada la descarga, dentro de `interior/` contarás con un nuevo directorio llamado `UdelaRInterior` (en referencia a nuestro espacio en [GitHub](https://github.com/UdelaRInterior) y en [Ansible Galaxy](https://galaxy.ansible.com/udelarinterior)), con los roles deseados organizados en subcarpetas.
> **Tip:** agregar la opción `--ignore-errors` permite descargar sólo los roles del `requirements.yml` que te faltan con mayor comodidad.
**Notar que al ejecutar ansible-galaxy con la opción '-g' (o '--keep-scm-meta' por su forma explícita) mantenemos en el directorio de cada role, la metadata del sistema de versionado utilizado. En este caso el directorio oculto '.git':**
**Notar que al ejecutar ansible-galaxy con la opción `-g` (o `--keep-scm-meta` por su forma explícita) mantenemos en el directorio de cada role, la metadata del sistema de versionado utilizado. En este caso el directorio oculto `.git`:**
```
UdelaRInterior
......@@ -62,12 +119,14 @@ Para acceder y descargar el proyecto [config](https://git.interior.edu.uy/admins
└── vars
```
**Mantener estos archivos de nos es de mucha utilidad, ya que permitirá:**
- Contar con los roles que requieren los playbooks para ejecutarse ya descargados, con nombre y ubicación correcta.
- Trabajar cada role como un repositorio Git convencional. Pudiendo entonces actualizarlo (git pull), realizar aportes (git commit y git push) y navegar entre diferentes versiones del mismo (git checkout).
**Mantener estos archivos de nos es de mucha utilidad, ya que permitirá:**
* Contar con los roles que requieren los playbooks para ejecutarse ya descargados, con nombre y ubicación correcta.
* Trabajar cada role como un repositorio Git convencional. Pudiendo entonces actualizarlo (`git pull`), realizar aportes (`git commit` y `git push`) y navegar entre diferentes versiones del mismo (`git checkout`).
## ¡Todo listo!
Completados todos los pasos, tu directorio **interior/** debería lucir así:
Completados todos los pasos, tu directorio `interior/` debería lucir algo así:
```
interior
......@@ -99,8 +158,7 @@ interior
└── crear_lxc
```
¿Te genera curiosidad saber por qué es necesario respetar esta estructura? Se debe a que en el mismo proyecto **config** contamos con un archivo de configuración que nos permite automatizar la conformación del entorno. Este archivo es **ansible.cfg** y luce así:
¿Te genera curiosidad saber por qué es necesario respetar esta estructura? Se debe a que en el mismo proyecto `config` contamos con un archivo de configuración que nos permite automatizar la conformación del entorno. Este archivo es `ansible.cfg` y luce así:
```ini
## Conforme a las ubicaciones propuestas en:
......@@ -118,75 +176,105 @@ roles_path = ../UdelaRInterior
vault_identity_list = ../contrasenha_vault
```
Como se aprecia, este archivo nos permite indicar la ubicación de nuestro inventario de hosts de la plataforma, la ubicación de descarga/consumo de roles externos y la contraseña utilizada por defecto para descifrar los vaults (archivos cifrados por contener datos sensibles). Este archivo simplificará mucho la ejecución de órdenes de Ansible siempre que lo hagas desde el directrio en la raíz del proyecto: **interior/config/**
Como se aprecia, este archivo nos permite indicar la ubicación de nuestro inventario de hosts de la plataforma, la ubicación de descarga/consumo de roles externos y la contraseña utilizada por defecto para descifrar los vaults (archivos cifrados por contener datos sensibles). Este archivo simplificará mucho la ejecución de órdenes de Ansible siempre que lo hagas desde el directrio en la raíz del proyecto: `interior/config/`
Es importante notar que manejamos dos archivos de inventario: **hosts_stage** para hosts de prueba y **hosts_prod** para los hosts de producción. Cuando ejecutes cualquier acción de Ansible, por defecto estarás utilizando el inventario de pruebas, ya que así se establece en **ansible.cfg**. Esto tiene implicación en simplificar el uso, pero por sobre todo, **evitar que sysadmins distraídos ejecuten playbooks sobre servidores en producción**.
Es importante notar que manejamos dos archivos de inventario: `hosts_stage` para hosts de prueba y `hosts_prod` para los hosts de producción. Cuando ejecutes cualquier acción de Ansible, por defecto estarás utilizando el inventario de pruebas, ya que así se establece en `ansible.cfg`. Esto tiene implicación en simplificar el uso, pero por sobre todo, **evitar que sysadmins distraídos ejecuten playbooks sobre servidores en producción**.
Para trabajar sobre servidores en producción, se requerirá estar lo suficientemente concentrado como para a indicar en la orden de ejecución que usaremos otro inventario, agregando **-i hosts_prod**. Por supuesto, los beneficios de esta característica dependerán de que los archivos de inventario se mantengan actualizados, principalmente quitando o comentando en **host_stage** las referencias a servidores que se declararon en producción.
Para trabajar sobre servidores en producción, se requerirá estar lo suficientemente concentrado como para a indicar en la orden de ejecución que usaremos otro inventario, agregando `-i hosts_prod` a la orden `ansible-playbook`. Por supuesto, los beneficios de esta característica dependerán de que los archivos de inventario se mantengan actualizados, principalmente quitando o comentando en `host_stage` las referencias a servidores que se declararon en producción.
## Organización de los playbooks en el proyecto **config**
## Organización de los playbooks en el proyecto `config`
Los archivos de inventario (**hosts_stage** y **hosts_prod**) se escriben en sintaxis [YAML](https://es.wikipedia.org/wiki/YAML) y organizan los grupos principales de nuestra infraestructura (OjO: incluye también cosas más allá de la nueva plataforma, en particular CSIC y el CURE. El grupo **interior** abarca la nueva plataforma en SeCIU).
Los archivos de inventario (`hosts_stage` y `hosts_prod`) se escriben en sintaxis [YAML](https://es.wikipedia.org/wiki/YAML) y organizan los grupos principales de nuestra infraestructura. El grupo `seciu` abarca la nueva plataforma de servidores: ***Gurí, Botija, Redota y Mate.*** (OjO: incluyen también cosas más allá de la nueva plataforma, en particular de CSIC y el CURE).
Procuramos atenernos a las [buenas prácticas de Ansible](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html), en particular:
- "colgamos" todo el código ya algo pulido tras un playbook general **site.yml**. Es decir que, a priori, si partimos de fierros básicamente instalados accesibles en root via SSH, obtenemos nuestra infraestructura funcional de la nueva plataforma lanzando:
```
usuario@pc:~/interior/config$ ansible-playbook --limit interior site.yml
usuario@pc:~/interior/config$ ansible-playbook --limit seciu site.yml
```
- usamos roles y toda su estructura, tanto como podemos.
- agrupamos en un rol **common** todo lo que convenga ejecutar en todos los servidores. Pero procuramos separar los conjuntos coherentes de tareas en archivos y roles incluidos.
- usamos variables en la carpeta **defaults** de los roles. Por ejemplo:
- los parámetros de configuración por omisión de un contenedor LXC [están definidos acá](https://github.com/UdelaRInterior/ansible-role-proxmox-create-lxc/blob/master/defaults/main.yml). Estas variables puede ser sobre-escritas indicando valores particulares en las **host_vars**, **group_vars** u otros lugares que tenga precedencia al **default** de roles.
- agrupamos en un rol `common` todo lo que convenga ejecutar en todos los servidores. Pero procuramos separar los conjuntos coherentes de tareas en archivos y roles incluidos.
- usamos variables en la carpeta `defaults` de los roles. Por ejemplo:
- los parámetros de configuración por omisión de un contenedor LXC [están definidos acá](https://github.com/UdelaRInterior/ansible-role-proxmox-create-lxc/blob/master/defaults/main.yml). Estas variables puede ser sobre-escritas indicando valores particulares en las `host_vars`, `group_vars` u otros lugares que tenga precedencia al `default` de roles.
- Usamos tags para alvianar la ejecución de los playbook, en particular:
- tag **adminsys** para los accesos de administradores. Por ejemplo, si agregamos la cuenta y claves de un nuevo miembro del equipo (**TO DO**), se va a agregar automáticamente a todos los hosts que corresponda ejecutamos:
- tag `adminsys` para los accesos de administradores. Por ejemplo, si [agregamos la cuenta y claves de un nuevo miembro del equipo](#TO_DO), se va a agregar automáticamente a todos los hosts que corresponda ejecutamos:
```
usuario@pc:~/interior/config$ ansible-playbook --limit interior site.yml --tags=adminsys
usuario@pc:~/interior/config$ ansible-playbook --limit seciu site.yml --tags adminsys
```
- tag **descarga**, que esta vez se exluye (*skip-tags*), para evitar GB de descargas. Por ejemplo, para crear los contenedores LXC que falten, sin por eso volver a descargar varios GB de templates para verificar que ya tenemos la última versión, correríamos:
- tag `descarga`, que esta vez se excluye (*skip-tags*), para evitar GB de descargas. Por ejemplo, para crear los contenedores LXC que falten, sin por eso volver a descargar varios GB de templates para verificar que ya tenemos la última versión, correríamos:
```
usuario@pc:~/interior/config$ ansible-playbook site.yml --limit mihost.interior.edu.uy --skip-tags=descarga
usuario@pc:~/interior/config$ ansible-playbook site.yml --limit mihost.interior.edu.uy --skip-tags descarga
```
Además de las buenas prácticas, algunas elecciones que hemos hecho:
- Nuestra carpeta de trabajo es la carpeta de la copia del proyecto Git. Por ende, solemos correr los playbooks para que tome correctamente la contraseña de los vaults del proyecto:
- Nuestro directorio de trabajo es la carpeta de resultante de clonar el repositorio del proyecto `config`. Por ende, solemos correr los playbooks para que tome correctamente la contraseña de los vaults del proyecto:
```
usuario@pc:~/interior/config$ ansible-playbook mi_playbook.yml
```
- El despliegue en los servidores administrados se hace con un usuario unix siempre denominado **deploy** (miembro del grupo **raices**, que tiene derechos **sudo** sin solicitud de contraseña). Se crea y configura en el rol [**acceso_deploy**](https://git.interior.edu.uy/adminsys/config/tree/master/roles/acceso_deploy), que utiliza como insumo las variables globales ([**group_vars/all**](https://git.interior.edu.uy/adminsys/config/tree/master/group_vars/all/vars)) para recuperar las claves de todos los adminsitradores del host y configurarlas en los usuarios **deploy** y **root**.
- En la configuración de la plataforma, es necesario configurar primero los servidores físicos (nodos Proxmox) y luego configurar contenedores, virtuales y otros. Por ende, el playbook **site.yml** es simplemente una inclusión secuencial de otros playbooks, empezando por el playbook **configurar_fierros_proxmox.yml**, que asegura la config del los fierros del mismo cluster Debian/Proxmox, en particular de los accesos **deploy** y **adminsys**, que serán un requisito a la hora de crear un virtual o un contenedor en su servidor madre.
- El despliegue en los servidores administrados se hace con un usuario unix siempre denominado `deploy` (miembro del grupo `raices`, que tiene derechos *sudo* sin solicitud de contraseña). Se crea y configura mediante el rol [`acceso_deploy`](https://git.interior.edu.uy/adminsys/config/tree/master/roles/acceso_deploy), que utiliza como insumo las variables globales ([`group_vars/all`](https://git.interior.edu.uy/adminsys/config/tree/master/group_vars/all/vars)) para recuperar las claves RSA de todos los adminsitradores del host y configurarlas en los usuarios `deploy` y `root`.
- En la configuración de la plataforma, es necesario configurar primero los servidores físicos (nodos Proxmox) y luego configurar contenedores, virtuales y otros. Por ende, el playbook `site.yml` es simplemente una inclusión secuencial de otros playbooks, empezando por el playbook `configurar_fierros_proxmox.yml`, que asegura la config del los fierros del mismo cluster Debian/Proxmox, en particular de los accesos `deploy` y `adminsys`, que serán un requisito a la hora de crear un virtual o un contenedor en su servidor madre.
## Por donde seguir...
## Playbooks disponibles
Estamos trabajando sobre los *playbooks* y *roles* para la nueva plataforma [acá](https://proyectos.interior.edu.uy/issues/6009) y (más recientemente) también [aquí](https://git.interior.edu.uy/adminsys/config/issues).
Estamos trabajando sobre los playbook para la nueva plataforma [acá](https://proyectos.interior.edu.uy/issues/6009) y (más recientemente) también [aquí](https://git.interior.edu.uy/adminsys/config/issues).
Entre otros, ya tenemos y usamos los *playbooks* siguientes:
Ya tenemos y usamos los playbook siguientes:
- ***config/site.yml***: incluye secuencialmente:
- ***config/configurar_fierros_proxmox.yml***: para el nivel de servidores físicos.
- ***config/crear_lxc.yml***: crea los contenedores definidos en el inventario con sus recursos específico, S.O. y les configura accesos.
- ***config/crear_kvm.yml***: crea las virtuales definidas en el inventario con sus recursos específicos y firewall Proxmox, sin S.O.
- ***config/config_host.yml***: aprovisiona a los hosts (sean LXC o KVM) con firewall, configuraciones de seguridad, paquetes, usuarios y servicios.
- ***config/configurar_firewall_cluster_proxmox.yml***: configura y establece reglas de firewall Proxmox para todo el cluster. Fue independizado de **config/site.yml**, ya que su incorrecta configuración y ejecución puede afectar la conectividad de varios o todos los hosts de la plataforma.
### Ejemplos:
**Para ejecutarlos, debes "pararte" en la carpeta `config` de tu entorno de trabajo:**
* Configurar toda la plataforma, partiendo de acceso `root` al cluster Proxmox:
```bash
usuario@pc:~/interior/config$ ansible-palybook site.yml
```
* Definir un nuevo contenedor:
- deben estar definidas sus IPs (IPv4, y eventualmente IPv6) en el [DNS](https://git.interior.edu.uy/adminsys/config/tree/master/files/bind/zones).
- incluirlo en el inventario `config/hosts_stage`, en el/los grupos oportunos (por ej. `seciu_contenedores_mate`) y con su fqdn en `.interior.edu.uy`,
- detallar sus parámetros en `config/host_vars/<fqdn>/vars/main`
- lanzar:
```bash
ansible-palybook --limit <fqdn> site.yml
```
Si se desea evitar descargar la plantilla del contenedor LXC cada vez (permanece almacenada y disponible en el nodo), se puede saltear ese paso indicándolo con tags:
```bash
ansible-palybook --limit <fqdn> site.yml --skip-tags descarga
```
Otro tag interesante es `adminsys`, que agrupa las tareas de configuración de usuarios. Si se desea ejecutar solo estas tareas:
```bash
ansible-palybook --limit <fqdn> site.yml --tags adminsys
```
- **config/site.yml**: incluye secuencialmente:
- **config/configurar_fierros_proxmox.yml**: para el nivel de servidores físicos.
- **config/crear_lxc.yml**: crea los contenedores definidos en el inventario con sus recursos específico, S.O. y les configura accesos.
- **config/crear_kvm.yml**: crea las virtuales definidas en el inventario con sus recursos específicos y firewall Proxmox, sin S.O.
- **config/config_host.yml**: aprovisiona a los hosts (sean LXC o KVM) con firewall, configuraciones de seguridad, paquetes, usuarios y servicios.
> **Tip: el uso de tags es muy conveniente para llevar a cabo muchas tareas cotidianas**. Los procedimientos ya automatizados se listan y documentan brevemente en la [wiki del proyecto Computación en la nube](https://git.interior.edu.uy/adminsys/config/-/wikis/home#procedimientos-ya-automatizados)
- **config/configurar_firewall_cluster_proxmox.yml**: configura y establece reglas de firewall Proxmox para todo el cluster. Fue independizado de **config/site.yml**, ya que su incorrecta configuración y ejecución puede afectar la conectividad de varios o todos los hosts de la plataforma.
## Procesos de instalación
## Instalación y aprovisionamiento del entorno de virtualización
### Tareas para un servidor Proxmox
Hay una parte del proceso que no se puede hacer con Ansible, dado que este trabaja mediante un acceso en SSH, por lo cual tiene que haber previamente instalado un sistema ya accesible en línea.
Instalamos los 3 primeros servidores físicos con un .iso de Proxmox, y a mano (en particular de disco, ya en RAID hardware).
Instalamos los 3 primeros servidores físicos (***Gurí, Botija y Redota***) con un *.iso* de Proxmox VE 5.X, y a mano (en particular de disco, ya en RAID hardware).
En ocasión de la instalación de un próximo nodo al cluster, convendría retomar [esta tarea](https://proyectos.interior.edu.uy/issues/5932), que ya fue un poco explorada.
Una vez que se tienen las máquinas en línea, con acceso root en SSH, podemos hacer las siguientes tareas con Ansible:
Una vez que se tienen las máquinas en línea, con acceso root en SSH, podemos hacer muchas cosas con ellas mediante Ansible. Por ejemplo:
- configuración de los repos de la UdelaR,
- desactivación del repo Proxmox con suscripción y activación del sin suscripción,
- instalación del usuario deploy y de los adminsys
- puesta en cluster de los Proxmox
- instalación de los certificados Let's Encryt
- instalación de los certificados Let's Encrypt
El playbook **config/configurar_fierros_proxmox.yml** ya hace parte de esto.
......@@ -197,6 +285,6 @@ El playbook **config/configurar_fierros_proxmox.yml** ya hace parte de esto.
## Compartir más
Además del proyecto [**config**](https://git.interior.edu.uy/adminsys/config), proyecto reservado, que contiene el inventario de servidores y scripts específicos a nuestra plataforma, habíamos empezado un segundo, que pretendía ser abierto retirando la información sensible. Pero al final lo compartido, de acuerdo a la propuesta de la comunidad Ansible, pasó a la galaxy, [nuestro espacio en GitHub](https://github.com/UdelaRInterior).
Además del proyecto [`config`](https://git.interior.edu.uy/adminsys/config), proyecto reservado, que contiene el inventario de servidores y scripts específicos a nuestra plataforma, habíamos empezado un segundo, que pretendía ser abierto retirando la información sensible. Pero al final lo compartido, de acuerdo a la propuesta de la comunidad Ansible, pasó a la galaxy, [nuestro espacio en GitHub](https://github.com/UdelaRInterior).
No obstante, quizás que algún día continuemos el proyecto [adminsys](https://git.interior.edu.uy/cielito/adminsys), *armá tu propia nube*.