|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
# Nuestra cultura _DevOps_
|
|
|
|
|
|
|
|
Desde que desplegamos [nuestra actual plataforma de computación en la nube](http://proyectos.interior.edu.uy/projects/servidores/wiki/Plataforma_de_servidores_del_Interior), en 2018, procuramos construir nuestra cultura _devops_, concepto que abordamos en el encuentro de la Red de Unidades Informáticas de 2016, en Rocha. Acercamos las actividades de desarrollo y administración de sistemas organizando nuestros procesos en forma cíclica e iterativa, primero de los prototipos de desarrollo, luego de la evolución y mantenimiento de los sistemas:
|
|
|
|
|
|
|
|
|
|
|
|
## Los areneros y la producción (_prod & stage_)
|
|
|
|
|
|
|
|
Conforme a prácticas usuales, distinguimos sólo dos grandes categorías para las instancias de nuestros sistemas: prod y stage, que a veces en criollo denominamos producción y arenero. Los sistemas en producción son aquellos que usuarixs funcionales utilizan en el contexto de sus procesos de trabajo, por ende cuyos datos y procesos tienen cierto nivel de criticidad directo. Los areneros sirven al desarrollo, las pruebas y la integración de sistemas, a la formación, o a cualquier otra función que no esté vinculada a la producción.
|
|
|
|
|
|
|
|
Prod y stage corresponden globalmente a cada una de las dos bucles del infinito del ciclo devops: la producción sustenta la de la izquierda, las operaciones, y los areneros la de la derecha, el desarrollo.
|
|
|
|
|
|
|
|
No obstante, la categorización prod/stage puede darse a varios niveles de la generación de servicios, desde la infraestructura física hasta el servicio al usuarix final, pasando por la virtualización y los diferentes componentes de plataforma (bases de datos, hospedaje LAMP, etc.). Y en diferentes casos, existen razones para correr instancias de stage sobre una infraestructura de producción.
|
|
|
|
|
|
|
|
Por ejemplo, si clonamos un servidor de correo de producción para estudiar una actualización, o cualquier modificación que requiera estudio sobre datos reales, éste será claramente de stage. No obstante, en nuestra configuración actual será más simple hacerlo en el mismo servidor físico, de producción, y puede no ser necesario el esfuerzo de apartarlo a un servidor físicos de stage.
|
|
|
|
|
|
|
|
Otro ejemplo es el multisitio wordpress [grupos.csic.edu.uy](https://grupos.csic.edu.uy), arenero que armamos para que [los grupos I+D de CSIC trabajen en el hospedaje de su sitio web](https://www.cielito.uy/-Grupos-I-D-), que luego pasaría a una cuenta propia de [hospedaje LAMP](https://www.cielito.uy/Hospedaje-web) o al [multisitio de producción](https://www.cielito.uy/Multisitio). Ese arenero de grupos I+I usa recursos de producción, en una cuenta diferente, pero en el mismo servidor de hospedaje LAMP que el multisitio de prod.
|
|
|
|
|
|
|
|
Un tercer ejemplo es el virtual gaucho, modelo simplificado y virtualizado de nuestra plataforma de computación en la nube a los fines de [nuestro taller devops](https://eva.unorte.edu.uy/course/view.php?id=996) para enrolar a nuevos integrantes a la comunidad. Por los recursos y disponibilidad que requiere, gaucho es un virtual de producción pero, por esencia de su función, ofrece una plataforma de stage para nuestra formación.
|
|
|
|
|
|
|
|
Podríamon pensar que, a la inversa, no habría razón de correr algo de producción sobre algo de stage. No obstante, en los hechos también algo así se da. Por ejemplo, al [actualizar nuestra infraestructura PVE](procedimiento-de-actualizacion-del-cluster-de-produccion-de-proxmox-6-a-8), como no funcionaba el cabezal de VPN vpn.interior.edu.u (bo), apelamos a su clon de pruebas figurita, en el cluster de stage. Al no tener todos los components garantizado disponible redundante, apelamos al stage como infraestrutura de
|
|
|
|
auxilio.
|
|
|
|
|
|
|
|
## Infraestructura, Tecnología & herramientas
|
|
|
|
|
|
|
|
Aprendimos que _devops_ es ante todo cultura, pero no viene sin una infraestructura de computación en la nube y una importante indumentaria de herramientas, que permiten desplegar paradigmas de automatización como [_infraestructura como código (IaC)_](https://es.wikipedia.org/wiki/Infraestructura_como_c%C3%B3digo), [Integración continua y Despliegue continuo](https://es.wikipedia.org/wiki/Integraci%C3%B3n_continua) o [desarrollo guiado por pruebas](https://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas). La cultura llega al construir estas prácticas, y siempre tiene algo propio a cada equipo de trabajo.
|
|
|
|
|
|
|
|
En la nueva plataforma mantenemos plenamente vigentes los lineamientos estratégicos y tecnológicos aplicados desde los inicios de la redUI y en la UdelaR en general, sustentados por [resoluciones del CDC](https://www.proyectos.udelar.edu.uy/redmine/documents/151) y [la ley 19.179](https://www.impo.com.uy/bases/leyes/19179-2013) : software libre e infraestructura soberana.
|
|
|
|
|
|
|
|
### Información, código, claves y direcciones
|
|
|
|
|
|
|
|
Usamos como espacio público de la redUI el sitio web [**cielito.uy**](https://cielito.uy). Comprende en particular [la presentación y referencia de instructivos de uso de nuestros servicios](https://www.cielito.uy/-Servicios-transversales-).
|
|
|
|
|
|
|
|
Al otro extremo, conservamos las credenciales compartida de acceso a sistemas que no tienen capacidad de acceso personal en un servidor [passbolt](https://www.passbolt.com/): https://fortaleza.cure.edu.uy/. Puedes solicitar acceso [al equipo transversal](https://www.cielito.uy/_Equipo-transversal-DevOps_#formulaire_ecrire_auteur_33).
|
|
|
|
|
|
|
|
Este contiene en particular un acceso invitado (sólo en lectura) a nuestro inventario de infraestructura y red: https://red.interior.edu.uy/
|
|
|
|
|
|
|
|
Nuestro principal repositorio de código es https://git.interior.edu.uy/, para el nuestro propio, tanto como, cuando es posible, para el que compartimos como software libre. A continuación se presenta como todo esto se articula para proveer los servicios mencionados, y más.
|
|
|
|
|
|
|
|
### Infraestructura física propia
|
|
|
|
|
|
|
|
El entorno devops aquí en cuestión se despliega en un conjunto de servidores físicos conectados a diferentes puntos de la [RAU](https://www.rau.edu.uy/), como parte integrante de la internet pública. Como infraestructura transversal a todos los Servicios que participan de la redUI, disponemos de medio rack de 42U en el datacenter central de la UdelaR:
|
|
|
|
|
|
|
|
[](https://red.interior.edu.uy/dcim/racks/18/)
|
|
|
|
|
|
|
|
Sin embargo, desde una misma fuente devops, también gestionamos varios recursos que están situados en las sedes de los CENURES distribuidas en todo el territorio nacional, e incluso los puntos de acceso de una red wifi del Campus Luisi Janicki se gestiona desde un contenedor desplegado de esta manera.
|
|
|
|
|
|
|
|
### [Red, direccionamiento & nombres](https://git.interior.edu.uy/adminsys/config/-/wikis/home#red-direccionamiento-nombres)
|
|
|
|
|
|
|
|
### [Plataforma de virtualización Proxmox VE](https://git.interior.edu.uy/adminsys/config/-/wikis/home#plataforma-de-virtualizaci%C3%B3n-proxmox-ve)
|
|
|
|
|
|
|
|
# Automatización de la configuración
|
|
|
|
|
|
|
|
Para automatizar el aprovisionamiento, la configuración y el mantenimiento de nuestra plataforma de servidores, en un paradigma de [_infraestructura como código_](https://es.wikipedia.org/wiki/Infraestructura_como_c%C3%B3digo) utilizamos [Ansible](https://www.ansible.com/) (si no lo conocés, [empezá acá](https://docs.ansible.com/ansible/latest/user_guide/index.html)).
|
|
|
|
|
|
|
|
El repo central de nuestra IaC es [git.interior.edu.uy/adminsys/config](https://git.interior.edu.uy/adminsys/config) (perdón por la terminología, no quiere decir nada, estábamos aprendiendo. Acceso con una cuenta en [login.interior.edu.uy](https://login.interior.edu.uy/), en un grupo o con derechos apropiados)
|
|
|
|
|
|
|
|
## Compartiendo y liberando código
|
|
|
|
|
|
|
|
Usamos el software libre compartido en la [Ansible Galaxy](https://galaxy.ansible.com/), a la que también contribuimos activamente, aportando a roles existentes o compartiendo nuestros propios roles y colecciones, inicialmente en [github.com/udelaRInterior/](https://github.com/udelaRInterior/) y, ahora que se puede, en nuestro propio gitlab, en particular acá: https://git.interior.edu.uy/cielito
|
|
|
|
|
|
|
|
Puedes ver los roles que usamos en el [`requirements.yml` de la IaC ansible](https://git.interior.edu.uy/adminsys/config/-/blob/main/requirements.yml).
|
|
|
|
|
|
|
|
## Nuestro inventario ansible-PVE
|
|
|
|
|
|
|
|
Manejamos actualmente dos inventarios ansible estáticos:
|
|
|
|
* [host_stage](https://git.interior.edu.uy/adminsys/config/-/blob/main/hosts_stage), inventario de _stage_ donde referenciamos los areneros de nuestra infra. Será el inventario por omisión al ejecutar un playbook desde una réplica del repo, en una cuenta personal con claves y derechos necesarios,
|
|
|
|
* [host_prod](https://git.interior.edu.uy/adminsys/config/-/blob/main/host_prod), inventario de _producción_ donde se describe [el cluster PVE de producción](#cluster_prod), con sus nodos virtuales KVM y sus contenedores LXC. Para usar este inventario, debemos indicarlo explícitamente al tirar un playbook ansible.
|
|
|
|
|
|
|
|
Estos dos inventarios comparten (o deberían compartir, tenemos refactor en curso adminsys/config#390) buena parte su estructura de grupos, difiriendo esencialmente en el un sub-nivel:
|
|
|
|
* el primer nivel es el del _site_, la localización física. ahora en la rama main manejamos todo en `seciu`, pero llegamos a gestionar cosas de `csic` y en [una rama](https://git.interior.edu.uy/adminsys/config/-/blob/124-empezar-a-manejar-los-servidores-del-cure-con-ansible/hosts_prod#L104) (que ya es un árbol en sí) se maneja la infra del `cure`.
|
|
|
|
* el segundo o tercer nivel es el del cluster PVE: el inventario de stage menciona y distingue la infraestructura de stage y (parte de) la de prod. A la inversa, la prod sólo menciona un conjunto de nodos que conforman _el_ cluster. Esto es porque, como explicado más arriba, no todos los areneros están en una infraestructura de stage, algunos usan recursos de prod. El stage ve la prod, la prod no ve el stage.
|
|
|
|
* el resto de la estructura de grupos, en particular los funcionales y varios grupos de grupos que sirven para delimitar alcances de plays, procuran ser compartidos entre prod y stage, de manera a compartir código de orquestación ansible.
|
|
|
|
|
|
|
|
El disponer así de dos grupos específicos a la IaC de stage, `seciu_prod` y `seciu_stage`, los dos diferentes de la IaC de prod, que solo conoce `seciu_nodos`, permite acceder con credenciales diferentes según el contexto.
|
|
|
|
|
|
|
|
|
|
|
|
## Introducción a nuestro flujo de trabajo
|
|
|
|
|
|
|
|
Trabajamos paralelamente, en forma distribuida pero [coordinada](flujo-de-trabajo-con-Git-en-Gitlab-y-GitHub), 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. 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).
|
|
|
|
- Más precisamente, para cualquier tarea que querramos emprender:
|
|
|
|
- si bien hay algunas tareas que hacemos por un commit directo a master, como [las configuraciones DNS](https://git.interior.edu.uy/cielito/adminsys/-/wikis/manejo-de-zonas-con-ansible) o correcciones redaccionales o muy menores (o si por error rompimos algo en master)
|
|
|
|
- Creamos [una incidencia en neuestro repo de IaC](https://git.interior.edu.uy/adminsys/config/-/boards), con descripción clara y etiquetas pertinentes,
|
|
|
|
- En cuanto necesitamos código ansible para configurar algo en [nuestra plataforma de IaaS](https://mate.interior.edu.uy:8006/) [en VPN], creamos, desde la incidencia, una Merge Request con su rama, la cyal llevará el número de la incidencia, digamos XXX. Descargamos esa rama en nuestro entorno local con:
|
|
|
|
```
|
|
|
|
git pull
|
|
|
|
git checkout XXX-...
|
|
|
|
```
|
|
|
|
Se optiene fácilmente el nombre completo con la autocompleción de comando (<tab>)
|
|
|
|
- Si vamos a necesitar un host de prueba en nuestra infraestructura de nube, debemos elegirlo entre los nombres/IPs disponibles del [plan de direccionamiento de la plataforma](https://git.interior.edu.uy/adminsys/config/blob/master/files/bind/zones/db.interior.edu.uy#L96). Conviene enseguida anunciarlo por el grupo de chat del equipo transversal, para estar seguro que nadie lo usa, y conversar todo lo que sea pertinente. Si queremos preserval el host en el tiempo, conviene comentarlo en el [plan de direccionamiento de la plataforma](https://git.interior.edu.uy/adminsys/config/blob/master/files/bind/zones/db.interior.edu.uy#L96) y commitear.
|
|
|
|
- analiza luego la estructura de [nuestro inventario de staging](https://git.interior.edu.uy/adminsys/config/blob/master/hosts_stage) y [nuestro inventario de producción](https://git.interior.edu.uy/adminsys/config/blob/master/hosts_prod). En éstos se define en qué servidor va un host, si es un contenedor LXC o un virtual KVM, y qué configuraciones recibe, además de las que recibe por omisión, como la configuración de cuentas de usuarios y privilegios. Salvo excepción, todos los host de pruebas van en el servidor (node proxmox) mate, los de producción van *siempre* en los nodos de producción: gurí, botija, guyunusa, con almacenamientos y/o respaldos en redota.
|
|
|
|
- Puedes consultar [nuestros procedimientos](https://git.interior.edu.uy/cielito/adminsys/-/wikis/home#procedimientos-ya-automatizados) como un primer juego de herramientas para armar tu host y configurarlo, es decir establecer sus archivos: `host_vars/<mi_host>.interior.edu.uy/vars|vault` y otros archivos ansible que se requieran.
|
|
|
|
- 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 publican [en la Ansible Galaxy](https://galaxy.ansible.com/udelarinterior/) y se mantienen en nuesto espacio en [GitHub](https://github.com/UdelaRInterior), en los que [interactuamos con la comunidad FLOSS](forks-y-aportes-a-la-comunidad) (Free, Libre and Open Source Software).
|
|
|
|
- contamos con una [lista de correo del equipo de trabajo](https://listas.softwarelibre.edu.uy/sympa/info/becarixs), pero también conversamos bastante por [chat Matrix](https://chat.interior.edu.uy) y en reuniones periódicas por [videoconferencia web](https://www.interior.edu.uy/Web-conferencia), todo sobre instancias soberanas.
|
|
|
|
- En la gestión de nuestras ramas, ponemos en práctica las metodologías siguientes:
|
|
|
|
- trabajamos entre pares. En particular, a la hora de fusionar en master, lo debe hacer una persona que no sea la que trabajó sobre la rama que se va a fusionar en master y la infraestructura que esta arma. De preferencia, debería ser la persona que estuvo la más alejada del trabajo que se está integrando quien, con una mirada externa y cándida, realice la *review* del cófigo y su consecuente fusión en master.
|
|
|
|
- Actualizamos a menudo nuestras ramas de trabajo a master, de manera a estar actualizadxs al trabajar, y para evitar cualquier efecto de borde sobre la infraestructura en producción cuando corremos orquestaciones de servicios,
|
|
|
|
- Quien realiza una fusión de código en master deberá anunciarlo en el chat, en particular para que la gente piense en actualizar cuanto antes. No obstante, deberá analizar si introduce alguna modificación que pueda tener consecuencias para un código desactualizado, como pueden ser modificaciones de APIs de roles que coniernen varios host, o modificaciones en el firewall de cluster `cluster.fw`.
|
|
|
|
|
|
|
|
|
|
|
|
## 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, pero de forma mas concreta (no hace doble empleo de esta página).
|
|
|
|
|
|
|
|
> **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, 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.
|
|
|
|
|
|
|
|
### 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. [Originalmente usábamos llaves rsa de 8192 bits](https://proyectos.interior.edu.uy/projects/servidores/wiki/Acceso_en_ssh), ahora pasamos a curvas elípticas, siempre con un *passphrase* robusto.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
ssh-keygen -t ed25519
|
|
|
|
```
|
|
|
|
|
|
|
|
* 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** :flushed: o usando un **¡playbook Ansible!** :smiley:.
|
|
|
|
|
|
|
|
#### Automatizada (si tu estación de trabajo es base debian):
|
|
|
|
|
|
|
|
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 --tags pip -K
|
|
|
|
```
|
|
|
|
|
|
|
|
> **Tip:** las opciones `--tags pip` y `-K` solo serán necesarias la primera vez que se ejecute el playbook. Esto debido a que es necesario escalar privilegios (*sudo*) para instalar ***python-pip***. Una vez instalado *pip*, no será necesario escalar privilegios.
|
|
|
|
|
|
|
|
Una vez finalizada la ejecución satisfactoria del playbook, ya tienes todo lo necesario para desarrollar y operar la plataforma de servidores.
|
|
|
|
|
|
|
|
#### Manual:
|
|
|
|
|
|
|
|
* Comenzamos instalando las librerías/paquetes Python: `netaddr`, `jmespath` y `zabbix-api`, dependencias de nuestros playbooks:
|
|
|
|
|
|
|
|
**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` (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`:**
|
|
|
|
|
|
|
|
```
|
|
|
|
UdelaRInterior
|
|
|
|
├── ...
|
|
|
|
├── ...
|
|
|
|
└── crear_lxc
|
|
|
|
├── defaults
|
|
|
|
├── .git <-----
|
|
|
|
├── .gitignore
|
|
|
|
├── handlers
|
|
|
|
├── LICENSE
|
|
|
|
├── meta
|
|
|
|
├── README.md
|
|
|
|
├── tasks
|
|
|
|
├── tests
|
|
|
|
└── 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`).
|
|
|
|
|
|
|
|
|
|
|
|
## ¡Todo listo!
|
|
|
|
|
|
|
|
Completados todos los pasos, tu directorio `interior/` debería lucir algo así:
|
|
|
|
|
|
|
|
```
|
|
|
|
interior
|
|
|
|
├── config
|
|
|
|
│ ├── ansible.cfg
|
|
|
|
│ ├── arenero
|
|
|
|
│ ├── config_host.yml
|
|
|
|
│ ├── configurar_fierros_proxmox.yml
|
|
|
|
│ ├── configurar_firewall_cluster_proxmox.yml
|
|
|
|
│ ├── crear_kvm.retry
|
|
|
|
│ ├── crear_kvm.yml
|
|
|
|
│ ├── crear_lxc.yml
|
|
|
|
│ ├── files
|
|
|
|
│ ├── group_vars
|
|
|
|
│ ├── hosts_prod
|
|
|
|
│ ├── hosts_stage
|
|
|
|
│ ├── host_vars
|
|
|
|
│ ├── info_servidor.yml
|
|
|
|
│ ├── README.md
|
|
|
|
│ ├── requirements.yml
|
|
|
|
│ ├── roles
|
|
|
|
│ ├── site.retry
|
|
|
|
│ └── site.yml
|
|
|
|
├── contrasenha_vault
|
|
|
|
└── UdelaRInterior
|
|
|
|
├── alternc
|
|
|
|
├── ...
|
|
|
|
├── ...
|
|
|
|
└── 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í:
|
|
|
|
|
|
|
|
```ini
|
|
|
|
## Conforme a las ubicaciones propuestas en:
|
|
|
|
## https://docs.ansible.com/ansible/latest/intro_configuration.html
|
|
|
|
|
|
|
|
[defaults]
|
|
|
|
|
|
|
|
## Nuestro inventario
|
|
|
|
inventory = ./hosts_stage
|
|
|
|
|
|
|
|
## Nuestra carpeta con roles publicados en la ansible-galaxy
|
|
|
|
roles_path = ../UdelaRInterior
|
|
|
|
|
|
|
|
## la contraseña de los vault
|
|
|
|
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/`
|
|
|
|
|
|
|
|
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` 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`
|
|
|
|
|
|
|
|
Los archivos de inventario (`#nuestra-cultura-devopshosts_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, Guyunusa 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 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.
|
|
|
|
- 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:
|
|
|
|
```
|
|
|
|
usuario@pc:~/interior/config$ ansible-playbook --limit seciu site.yml --tags adminsys
|
|
|
|
```
|
|
|
|
- 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
|
|
|
|
```
|
|
|
|
|
|
|
|
Además de las buenas prácticas, algunas elecciones que hemos hecho:
|
|
|
|
- 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 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...
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
Entre otros, ya tenemos y usamos los *playbooks* 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
|
|
|
|
```
|
|
|
|
|
|
|
|
> **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/cielito/adminsys/-/wikis/home#procedimientos-ya-automatizados)
|
|
|
|
|
|
|
|
|
|
|
|
## 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 (***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 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 Encrypt
|
|
|
|
|
|
|
|
El playbook **config/configurar_fierros_proxmox.yml** ya hace parte de esto.
|
|
|
|
|
|
|
|
# Explorar herramientas Ansible, Proxmox y otros
|
|
|
|
|
|
|
|
- [Debian Appliance Builder](https://pve.proxmox.com/wiki/Debian_Appliance_Builder) para LXC en Proxmox
|
|
|
|
- Los template disponibles para LXC (y el nombre del archivo, que no aparece por la GUI hasta descargar) [están acá](http://download.proxmox.com/images/system/ ).
|
|
|
|
|
|
|
|
## Compartir más
|
|
|
|
|
|
|
|
* Luego de esta introducción (a mitad de ella) pudes ejercitarte siguiendo [nuestro "taller devops" en el EVA del Litoral](https://eva.unorte.edu.uy/course/view.php?id=996)
|
|
|
|
|
|
|
|
* Además del proyecto [`config`](https://git.interior.edu.uy/adminsys/config) (que es reservado, por contener datos sensibles, de inventario y acceso a nuestra infra), encontrarás cantidad de lo nuestro el los espacios de la Ansible Galaxy:
|
|
|
|
* [cielito](https://galaxy.ansible.com/ui/namespaces/cielito/), que trabajamos [en un grupo de nuestro Gitlab](https://git.interior.edu.uy/cielito)
|
|
|
|
* [UdelaRInterior](https://galaxy.ansible.com/ui/standalone/namespaces/7197/), que trabajábamos, como sólo se podía entonces, en [github.com/UdelaRInterior](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*. |
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
# Nuestra cultura _DevOps_
|
|
|
|
|
|
|
|
Desde que desplegamos [nuestra actual plataforma de computación en la nube](http://proyectos.interior.edu.uy/projects/servidores/wiki/Plataforma_de_servidores_del_Interior), en 2018, procuramos construir nuestra cultura _devops_, concepto que abordamos en el encuentro de la Red de Unidades Informáticas de 2016, en Rocha. Acercamos las actividades de desarrollo y administración de sistemas organizando nuestros procesos en forma cíclica e iterativa, primero de los prototipos de desarrollo, luego de la evolución y mantenimiento de los sistemas:
|
|
|
|
|
|
|
|
|
|
|
|
## Los areneros y la producción (_prod & stage_)
|
|
|
|
|
|
|
|
Conforme a prácticas usuales, distinguimos sólo dos grandes categorías para las instancias de nuestros sistemas: prod y stage, que a veces en criollo denominamos producción y arenero. Los sistemas en producción son aquellos que usuarixs funcionales utilizan en el contexto de sus procesos de trabajo, por ende cuyos datos y procesos tienen cierto nivel de criticidad directo. Los areneros sirven al desarrollo, las pruebas y la integración de sistemas, a la formación, o a cualquier otra función que no esté vinculada a la producción.
|
|
|
|
|
|
|
|
Prod y stage corresponden globalmente a cada una de las dos bucles del infinito del ciclo devops: la producción sustenta la de la izquierda, las operaciones, y los areneros la de la derecha, el desarrollo.
|
|
|
|
|
|
|
|
No obstante, la categorización prod/stage puede darse a varios niveles de la generación de servicios, desde la infraestructura física hasta el servicio al usuarix final, pasando por la virtualización y los diferentes componentes de plataforma (bases de datos, hospedaje LAMP, etc.). Y en diferentes casos, existen razones para correr instancias de stage sobre una infraestructura de producción.
|
|
|
|
|
|
|
|
Por ejemplo, si clonamos un servidor de correo de producción para estudiar una actualización, o cualquier modificación que requiera estudio sobre datos reales, éste será claramente de stage. No obstante, en nuestra configuración actual será más simple hacerlo en el mismo servidor físico, de producción, y puede no ser necesario el esfuerzo de apartarlo a un servidor físicos de stage.
|
|
|
|
|
|
|
|
Otro ejemplo es el multisitio wordpress [grupos.csic.edu.uy](https://grupos.csic.edu.uy), arenero que armamos para que [los grupos I+D de CSIC trabajen en el hospedaje de su sitio web](https://www.cielito.uy/-Grupos-I-D-), que luego pasaría a una cuenta propia de [hospedaje LAMP](https://www.cielito.uy/Hospedaje-web) o al [multisitio de producción](https://www.cielito.uy/Multisitio). Ese arenero de grupos I+I usa recursos de producción, en una cuenta diferente, pero en el mismo servidor de hospedaje LAMP que el multisitio de prod.
|
|
|
|
|
|
|
|
Un tercer ejemplo es el virtual gaucho, modelo simplificado y virtualizado de nuestra plataforma de computación en la nube a los fines de [nuestro taller devops](https://eva.unorte.edu.uy/course/view.php?id=996) para enrolar a nuevos integrantes a la comunidad. Por los recursos y disponibilidad que requiere, gaucho es un virtual de producción pero, por esencia de su función, ofrece una plataforma de stage para nuestra formación.
|
|
|
|
|
|
|
|
Podríamon pensar que, a la inversa, no habría razón de correr algo de producción sobre algo de stage. No obstante, en los hechos también algo así se da. Por ejemplo, al [actualizar nuestra infraestructura PVE](procedimiento-de-actualizacion-del-cluster-de-produccion-de-proxmox-6-a-8), como no funcionaba el cabezal de VPN vpn.interior.edu.u (bo), apelamos a su clon de pruebas figurita, en el cluster de stage. Al no tener todos los components garantizado disponible redundante, apelamos al stage como infraestrutura de
|
|
|
|
auxilio.
|
|
|
|
|
|
|
|
## Infraestructura, Tecnología & herramientas
|
|
|
|
|
|
|
|
Aprendimos que _devops_ es ante todo cultura, pero no viene sin una infraestructura de computación en la nube y una importante indumentaria de herramientas, que permiten desplegar paradigmas de automatización como [_infraestructura como código (IaC)_](https://es.wikipedia.org/wiki/Infraestructura_como_c%C3%B3digo), [Integración continua y Despliegue continuo](https://es.wikipedia.org/wiki/Integraci%C3%B3n_continua) o [desarrollo guiado por pruebas](https://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas). La cultura llega al construir estas prácticas, y siempre tiene algo propio a cada equipo de trabajo.
|
|
|
|
|
|
|
|
En la nueva plataforma mantenemos plenamente vigentes los lineamientos estratégicos y tecnológicos aplicados desde los inicios de la redUI y en la UdelaR en general, sustentados por [resoluciones del CDC](https://www.proyectos.udelar.edu.uy/redmine/documents/151) y [la ley 19.179](https://www.impo.com.uy/bases/leyes/19179-2013) : software libre e infraestructura soberana.
|
|
|
|
|
|
|
|
### Información, código, claves y direcciones
|
|
|
|
|
|
|
|
Usamos como espacio público de la redUI el sitio web [**cielito.uy**](https://cielito.uy). Comprende en particular [la presentación y referencia de instructivos de uso de nuestros servicios](https://www.cielito.uy/-Servicios-transversales-).
|
|
|
|
|
|
|
|
Al otro extremo, conservamos las credenciales compartida de acceso a sistemas que no tienen capacidad de acceso personal en un servidor [passbolt](https://www.passbolt.com/): https://fortaleza.cure.edu.uy/. Puedes solicitar acceso [al equipo transversal](https://www.cielito.uy/_Equipo-transversal-DevOps_#formulaire_ecrire_auteur_33).
|
|
|
|
|
|
|
|
Este contiene en particular un acceso invitado (sólo en lectura) a nuestro inventario de infraestructura y red: https://red.interior.edu.uy/
|
|
|
|
|
|
|
|
Nuestro principal repositorio de código es https://git.interior.edu.uy/, para el nuestro propio, tanto como, cuando es posible, para el que compartimos como software libre. A continuación se presenta como todo esto se articula para proveer los servicios mencionados, y más.
|
|
|
|
|
|
|
|
### Infraestructura física propia
|
|
|
|
|
|
|
|
El entorno devops aquí en cuestión se despliega en un conjunto de servidores físicos conectados a diferentes puntos de la [RAU](https://www.rau.edu.uy/), como parte integrante de la internet pública. Como infraestructura transversal a todos los Servicios que participan de la redUI, disponemos de medio rack de 42U en el datacenter central de la UdelaR:
|
|
|
|
|
|
|
|
[](https://red.interior.edu.uy/dcim/racks/18/)
|
|
|
|
|
|
|
|
Sin embargo, desde una misma fuente devops, también gestionamos varios recursos que están situados en las sedes de los CENURES distribuidas en todo el territorio nacional, e incluso los puntos de acceso de una red wifi del Campus Luisi Janicki se gestiona desde un contenedor desplegado de esta manera.
|
|
|
|
|
|
|
|
### [Red, direccionamiento & nombres](https://git.interior.edu.uy/adminsys/config/-/wikis/home#red-direccionamiento-nombres)
|
|
|
|
|
|
|
|
### [Plataforma de virtualización Proxmox VE](https://git.interior.edu.uy/adminsys/config/-/wikis/home#plataforma-de-virtualizaci%C3%B3n-proxmox-ve)
|
|
|
|
|
|
|
|
# Automatización de la configuración
|
|
|
|
|
|
|
|
Para automatizar el aprovisionamiento, la configuración y el mantenimiento de nuestra plataforma de servidores, en un paradigma de [_infraestructura como código_](https://es.wikipedia.org/wiki/Infraestructura_como_c%C3%B3digo) utilizamos [Ansible](https://www.ansible.com/) (si no lo conocés, [empezá acá](https://docs.ansible.com/ansible/latest/user_guide/index.html)).
|
|
|
|
|
|
|
|
El repo central de nuestra IaC es [git.interior.edu.uy/adminsys/config](https://git.interior.edu.uy/adminsys/config) (perdón por la terminología, no quiere decir nada, estábamos aprendiendo. Acceso con una cuenta en [login.interior.edu.uy](https://login.interior.edu.uy/), en un grupo o con derechos apropiados)
|
|
|
|
|
|
|
|
## Compartiendo y liberando código
|
|
|
|
|
|
|
|
Usamos el software libre compartido en la [Ansible Galaxy](https://galaxy.ansible.com/), a la que también contribuimos activamente, aportando a roles existentes o compartiendo nuestros propios roles y colecciones, inicialmente en [github.com/udelaRInterior/](https://github.com/udelaRInterior/) y, ahora que se puede, en nuestro propio gitlab, en particular acá: https://git.interior.edu.uy/cielito
|
|
|
|
|
|
|
|
Puedes ver los roles que usamos en el [`requirements.yml` de la IaC ansible](https://git.interior.edu.uy/adminsys/config/-/blob/main/requirements.yml).
|
|
|
|
|
|
|
|
## Nuestro inventario ansible-PVE
|
|
|
|
|
|
|
|
Manejamos actualmente dos inventarios ansible estáticos:
|
|
|
|
* [host_stage](https://git.interior.edu.uy/adminsys/config/-/blob/main/hosts_stage), inventario de _stage_ donde referenciamos los areneros de nuestra infra. Será el inventario por omisión al ejecutar un playbook desde una réplica del repo, en una cuenta personal con claves y derechos necesarios,
|
|
|
|
* [host_prod](https://git.interior.edu.uy/adminsys/config/-/blob/main/host_prod), inventario de _producción_ donde se describe [el cluster PVE de producción](#cluster_prod), con sus nodos virtuales KVM y sus contenedores LXC. Para usar este inventario, debemos indicarlo explícitamente al tirar un playbook ansible.
|
|
|
|
|
|
|
|
Estos dos inventarios comparten (o deberían compartir, tenemos refactor en curso adminsys/config#390) buena parte su estructura de grupos, difiriendo esencialmente en el un sub-nivel:
|
|
|
|
* el primer nivel es el del _site_, la localización física. ahora en la rama main manejamos todo en `seciu`, pero llegamos a gestionar cosas de `csic` y en [una rama](https://git.interior.edu.uy/adminsys/config/-/blob/124-empezar-a-manejar-los-servidores-del-cure-con-ansible/hosts_prod#L104) (que ya es un árbol en sí) se maneja la infra del `cure`.
|
|
|
|
* el segundo o tercer nivel es el del cluster PVE: el inventario de stage menciona y distingue la infraestructura de stage y (parte de) la de prod. A la inversa, la prod sólo menciona un conjunto de nodos que conforman _el_ cluster. Esto es porque, como explicado más arriba, no todos los areneros están en una infraestructura de stage, algunos usan recursos de prod. El stage ve la prod, la prod no ve el stage.
|
|
|
|
* el resto de la estructura de grupos, en particular los funcionales y varios grupos de grupos que sirven para delimitar alcances de plays, procuran ser compartidos entre prod y stage, de manera a compartir código de orquestación ansible.
|
|
|
|
|
|
|
|
El disponer así de dos grupos específicos a la IaC de stage, `seciu_prod` y `seciu_stage`, los dos diferentes de la IaC de prod, que solo conoce `seciu_nodos`, permite acceder con credenciales diferentes según el contexto.
|
|
|
|
|
|
|
|
|
|
|
|
## Introducción a nuestro flujo de trabajo
|
|
|
|
|
|
|
|
Trabajamos paralelamente, en forma distribuida pero [coordinada](flujo-de-trabajo-con-Git-en-Gitlab-y-GitHub), 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. 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).
|
|
|
|
- Más precisamente, para cualquier tarea que querramos emprender:
|
|
|
|
- si bien hay algunas tareas que hacemos por un commit directo a main, como [las configuraciones DNS](https://git.interior.edu.uy/cielito/adminsys/-/wikis/manejo-de-zonas-con-ansible) o correcciones redaccionales o muy menores (o si por error rompimos algo en main)
|
|
|
|
- Creamos [una incidencia en neuestro repo de IaC](https://git.interior.edu.uy/adminsys/config/-/boards), con descripción clara y etiquetas pertinentes,
|
|
|
|
- En cuanto necesitamos código ansible para configurar algo en [nuestra plataforma de IaaS](https://mate.interior.edu.uy:8006/) [en VPN], creamos, desde la incidencia, una Merge Request con su rama, la cyal llevará el número de la incidencia, digamos XXX. Descargamos esa rama en nuestro entorno local con:
|
|
|
|
```
|
|
|
|
git pull
|
|
|
|
git checkout XXX-...
|
|
|
|
```
|
|
|
|
Se optiene fácilmente el nombre completo con la autocompleción de comando (<tab>)
|
|
|
|
- Si vamos a necesitar un host de prueba en nuestra infraestructura de nube, debemos elegirlo entre los nombres/IPs disponibles del [plan de direccionamiento de la plataforma](https://git.interior.edu.uy/adminsys/config/-/tree/main/group_vars/cielito_ns_authoritative/vars/zonas/interior?ref_type=heads). Conviene enseguida anunciarlo por el grupo de chat del equipo transversal, para estar seguro que nadie lo usa, y conversar todo lo que sea pertinente. Si queremos preserval el host en el tiempo, conviene comentarlo en el [plan de direccionamiento de la plataforma](https://git.interior.edu.uy/adminsys/config/-/tree/main/group_vars/cielito_ns_authoritative/vars/zonas/interior?ref_type=heads) y commitear.
|
|
|
|
- analiza luego la estructura de [nuestro inventario de staging](https://git.interior.edu.uy/adminsys/config/blob/main/hosts_stage) y [nuestro inventario de producción](https://git.interior.edu.uy/adminsys/config/blob/main/hosts_prod). En éstos se define en qué servidor va un host, si es un contenedor LXC o un virtual KVM, y qué configuraciones recibe, además de las que recibe por omisión, como la configuración de cuentas de usuarios y privilegios. Salvo excepción, todos los host de pruebas van en el servidor (node proxmox) mate, los de producción van *siempre* en los nodos de producción: gurí, botija, guyunusa, con almacenamientos y/o respaldos en redota.
|
|
|
|
- Puedes consultar [nuestros procedimientos](https://git.interior.edu.uy/cielito/adminsys/-/wikis/home#procedimientos-ya-automatizados) como un primer juego de herramientas para armar tu host y configurarlo, es decir establecer sus archivos: `host_vars/<mi_host>.interior.edu.uy/vars|vault` y otros archivos ansible que se requieran.
|
|
|
|
- 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 publican [en la Ansible Galaxy](https://galaxy.ansible.com/udelarinterior/) y se mantienen en nuesto espacio en [GitHub](https://github.com/UdelaRInterior), en los que [interactuamos con la comunidad FLOSS](forks-y-aportes-a-la-comunidad) (Free, Libre and Open Source Software).
|
|
|
|
- contamos con una [lista de correo del equipo de trabajo](https://listas.softwarelibre.edu.uy/sympa/info/becarixs), pero también conversamos bastante por [chat Matrix](https://chat.interior.edu.uy) y en reuniones periódicas por [videoconferencia web](https://www.interior.edu.uy/Web-conferencia), todo sobre instancias soberanas.
|
|
|
|
- En la gestión de nuestras ramas, ponemos en práctica las metodologías siguientes:
|
|
|
|
- trabajamos entre pares. En particular, a la hora de fusionar en main, lo debe hacer una persona que no sea la que trabajó sobre la rama que se va a fusionar en main y la infraestructura que esta arma. De preferencia, debería ser la persona que estuvo la más alejada del trabajo que se está integrando quien, con una mirada externa y cándida, realice la *review* del cófigo y su consecuente fusión en main.
|
|
|
|
- Actualizamos a menudo nuestras ramas de trabajo a main, de manera a estar actualizadxs al trabajar, y para evitar cualquier efecto de borde sobre la infraestructura en producción cuando corremos orquestaciones de servicios,
|
|
|
|
- Quien realiza una fusión de código en main deberá anunciarlo en el chat, en particular para que la gente piense en actualizar cuanto antes. No obstante, deberá analizar si introduce alguna modificación que pueda tener consecuencias para un código desactualizado, como pueden ser modificaciones de APIs de roles que coniernen varios host, o modificaciones en el firewall de cluster `cluster.fw`.
|
|
|
|
|
|
|
|
|
|
|
|
## 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, pero de forma mas concreta (no hace doble empleo de esta página).
|
|
|
|
|
|
|
|
> **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, 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.
|
|
|
|
|
|
|
|
### Procedimiento:
|
|
|
|
|
|
|
|
** //!\\ Procedimiento obsoleto //!\\ ** ahora la mejor manera de instalar ansible es con pipx, es _work in progress_ pero tenemos [la collección `gurisitx.devops`](https://galaxy.ansible.com/ui/repo/published/gurisitx/devops/) para armar un entorno.
|
|
|
|
|
|
|
|
* [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, (si todavía no tienes), un par de llaves ~~RSA~~ ED 25519 para poder autenticarte en GitLab y acceder a los servidores de la plataforma. [Originalmente usábamos llaves rsa de 8192 bits](https://proyectos.interior.edu.uy/projects/servidores/wiki/Acceso_en_ssh), ahora pasamos a curvas elípticas, siempre con un *passphrase* robusto.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
ssh-keygen -t ed25519
|
|
|
|
```
|
|
|
|
|
|
|
|
* 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 `ta.interior.edu.uy:~/compartido/ansible/contrasenha_vault` 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** previamente un adminsys debes haberte creado un usuario y otorgado acceso, preferentemente a través de llave ssh.
|
|
|
|
|
|
|
|
### 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** :flushed: o usando un **¡playbook Ansible!** :smiley:.
|
|
|
|
|
|
|
|
#### Automatizada (si tu estación de trabajo es base debian):
|
|
|
|
|
|
|
|
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 --tags pip -K
|
|
|
|
```
|
|
|
|
|
|
|
|
> **Tip:** las opciones `--tags pip` y `-K` solo serán necesarias la primera vez que se ejecute el playbook. Esto debido a que es necesario escalar privilegios (*sudo*) para instalar ***python-pip***. Una vez instalado *pip*, no será necesario escalar privilegios.
|
|
|
|
|
|
|
|
Una vez finalizada la ejecución satisfactoria del playbook, ya tienes todo lo necesario para desarrollar y operar la plataforma de servidores.
|
|
|
|
|
|
|
|
#### Manual:
|
|
|
|
|
|
|
|
* Comenzamos instalando las librerías/paquetes Python: `netaddr`, `jmespath` y `zabbix-api`, dependencias de nuestros playbooks:
|
|
|
|
|
|
|
|
**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` (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`:**
|
|
|
|
|
|
|
|
```
|
|
|
|
UdelaRInterior
|
|
|
|
├── ...
|
|
|
|
├── ...
|
|
|
|
└── crear_lxc
|
|
|
|
├── defaults
|
|
|
|
├── .git <-----
|
|
|
|
├── .gitignore
|
|
|
|
├── handlers
|
|
|
|
├── LICENSE
|
|
|
|
├── meta
|
|
|
|
├── README.md
|
|
|
|
├── tasks
|
|
|
|
├── tests
|
|
|
|
└── 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`).
|
|
|
|
|
|
|
|
|
|
|
|
## ¡Todo listo!
|
|
|
|
|
|
|
|
Completados todos los pasos, tu directorio `interior/` debería lucir algo así:
|
|
|
|
|
|
|
|
```
|
|
|
|
interior
|
|
|
|
├── config
|
|
|
|
│ ├── ansible.cfg
|
|
|
|
│ ├── arenero
|
|
|
|
│ ├── config_host.yml
|
|
|
|
│ ├── configurar_fierros_proxmox.yml
|
|
|
|
│ ├── configurar_firewall_cluster_proxmox.yml
|
|
|
|
│ ├── crear_kvm.retry
|
|
|
|
│ ├── crear_kvm.yml
|
|
|
|
│ ├── crear_lxc.yml
|
|
|
|
│ ├── files
|
|
|
|
│ ├── group_vars
|
|
|
|
│ ├── hosts_prod
|
|
|
|
│ ├── hosts_stage
|
|
|
|
│ ├── host_vars
|
|
|
|
│ ├── info_servidor.yml
|
|
|
|
│ ├── README.md
|
|
|
|
│ ├── requirements.yml
|
|
|
|
│ ├── roles
|
|
|
|
│ ├── site.retry
|
|
|
|
│ └── site.yml
|
|
|
|
├── contrasenha_vault
|
|
|
|
└── UdelaRInterior
|
|
|
|
├── alternc
|
|
|
|
├── ...
|
|
|
|
├── ...
|
|
|
|
└── 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í:
|
|
|
|
|
|
|
|
```ini
|
|
|
|
## Conforme a las ubicaciones propuestas en:
|
|
|
|
## https://docs.ansible.com/ansible/latest/intro_configuration.html
|
|
|
|
|
|
|
|
[defaults]
|
|
|
|
|
|
|
|
## Nuestro inventario
|
|
|
|
inventory = ./hosts_stage
|
|
|
|
|
|
|
|
## Nuestra carpeta con roles publicados en la ansible-galaxy
|
|
|
|
roles_path = ../UdelaRInterior
|
|
|
|
|
|
|
|
## la contraseña de los vault
|
|
|
|
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/`
|
|
|
|
|
|
|
|
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` 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`
|
|
|
|
|
|
|
|
Los archivos de inventario (`#nuestra-cultura-devopshosts_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, Guyunusa 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 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/main/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:
|
|
|
|
```
|
|
|
|
usuario@pc:~/interior/config$ ansible-playbook --limit seciu site.yml --tags adminsys
|
|
|
|
```
|
|
|
|
- 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
|
|
|
|
```
|
|
|
|
|
|
|
|
Además de las buenas prácticas, algunas elecciones que hemos hecho:
|
|
|
|
- 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 mediante el rol [`acceso_deploy`](https://git.interior.edu.uy/adminsys/config/tree/main/roles/acceso_deploy), que utiliza como insumo las variables globales ([`group_vars/all`](https://git.interior.edu.uy/adminsys/config/tree/main/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...
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
Entre otros, ya tenemos y usamos los *playbooks* 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/main/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
|
|
|
|
```
|
|
|
|
|
|
|
|
> **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/cielito/adminsys/-/wikis/home#procedimientos-ya-automatizados)
|
|
|
|
|
|
|
|
|
|
|
|
## 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 (***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 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 Encrypt
|
|
|
|
|
|
|
|
El playbook **config/configurar_fierros_proxmox.yml** ya hace parte de esto.
|
|
|
|
|
|
|
|
# Explorar herramientas Ansible, Proxmox y otros
|
|
|
|
|
|
|
|
- [Debian Appliance Builder](https://pve.proxmox.com/wiki/Debian_Appliance_Builder) para LXC en Proxmox
|
|
|
|
- Los template disponibles para LXC (y el nombre del archivo, que no aparece por la GUI hasta descargar) [están acá](http://download.proxmox.com/images/system/ ).
|
|
|
|
|
|
|
|
## Compartir más
|
|
|
|
|
|
|
|
* Luego de esta introducción (a mitad de ella) pudes ejercitarte siguiendo [nuestro "taller devops" en el EVA del Litoral](https://eva.unorte.edu.uy/course/view.php?id=996)
|
|
|
|
|
|
|
|
* Además del proyecto [`config`](https://git.interior.edu.uy/adminsys/config) (que es reservado, por contener datos sensibles, de inventario y acceso a nuestra infra), encontrarás cantidad de lo nuestro el los espacios de la Ansible Galaxy:
|
|
|
|
* [cielito](https://galaxy.ansible.com/ui/namespaces/cielito/), que trabajamos [en un grupo de nuestro Gitlab](https://git.interior.edu.uy/cielito)
|
|
|
|
* [UdelaRInterior](https://galaxy.ansible.com/ui/standalone/namespaces/7197/), que trabajábamos, como sólo se podía entonces, en [github.com/UdelaRInterior](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*. |
