| ... | ... | @@ -83,7 +83,7 @@ Trabajamos paralelamente, en forma distribuida pero [coordinada](flujo-de-trabaj |
|
|
|
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)
|
|
|
|
- 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:
|
|
|
|
```
|
| ... | ... | @@ -91,15 +91,15 @@ 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.
|
|
|
|
- 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 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`.
|
|
|
|
- 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
|
| ... | ... | @@ -112,6 +112,9 @@ En el [README del proyecto](https://git.interior.edu.uy/adminsys/config) está ( |
|
|
|
> 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:**
|
| ... | ... | @@ -130,7 +133,7 @@ En el [README del proyecto](https://git.interior.edu.uy/adminsys/config) está ( |
|
|
|
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.
|
|
|
|
* 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
|
| ... | ... | @@ -149,9 +152,9 @@ En el [README del proyecto](https://git.interior.edu.uy/adminsys/config) está ( |
|
|
|
|
|
|
|
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.
|
|
|
|
* 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** o **Bourdieu**, previamente un adminsys debes haberte creado un usuario y otorgado acceso, preferentemente a través de llave RSA.
|
|
|
|
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:
|
|
|
|
|
| ... | ... | @@ -286,7 +289,7 @@ Procuramos atenernos a las [buenas prácticas de Ansible](https://docs.ansible.c |
|
|
|
- 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.
|
|
|
|
- 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:
|
|
|
|
```
|
| ... | ... | @@ -302,7 +305,7 @@ Además de las buenas prácticas, algunas elecciones que hemos hecho: |
|
|
|
```
|
|
|
|
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`.
|
|
|
|
- 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...
|
| ... | ... | @@ -329,7 +332,7 @@ Entre otros, ya tenemos y usamos los *playbooks* siguientes: |
|
|
|
```
|
|
|
|
|
|
|
|
* 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).
|
|
|
|
- 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:
|
| ... | ... | |
| ... | ... | |
