FIXME: Esta página requiere aactualización #6117, en particular con la nota: #6118#note-2

Automatización de la configuración

Para automatizar el aprovisionamiento, la configuración y el mantenimiento de nuestra plataforma de servidores, utilizamos Ansible (si no conocés, empezá acá). Estamos trabajando en esta automatización en esta tarea: #5903 y las tareas relacionadas.

Para su producción de código, este proyecto:

En el README del proyecto está (también) descrito como configurar un entorno de trabajo. (OjO que no haga doble empleo con esta página...)

Entorno de trabajo personal

Trabajamos en forma distribuida pero coordinada, con git (Es útil leer esta introducción a git: Bases de git para trabajar juntos).

Generá tu propio entorno en tu cuenta en la máquina que quieras. Sólo OjO: ¡info sensible! 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, con passphrase robusta.

En breve, se recomendará tener tal espacio de trabajo en una cuenta personal (con acceso ssh con contraseña) en la consola de administración ta.interior.edu.uy. Acceso únicamente con clave pública/privada a esa cuenta ssh.

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.

Instalá en tu máquina git y ansible. Este último debe ser de versión reciente (>= 2.5, se logra fácilmente con los backports de al debian o el ppa oportuno de la Ubuntu).

Para el proyecto config, debes tener una cuenta en el gestor de código fuente y ser miembro del mismo (la inscripción está abierta para mails en .uy, y contactanos).

Simplemente te creas una carpeta de trabajo limpia, llamémosla interior/, en la que bajás los juegos de scripts:
  • el proyecto config del gitlab del interior,
    git clone git@git.interior.edu.uy:adminsys/config.git
    
  • creás una sub-carpeta UdelaRInterior, en la que se descargarán los roles de la galaxia ansible que usamos, en particular los de nuestro espacio ahí.

En esa carpeta, para cuando ejecutamos ansible desde ahí, hay que crearse el archivo ansible.cfg que, por ahora, define el lugar de nuestro inventario, el lugar de los roles (¿qué precedencia tiene con config/roles?) y una característica respecto a una laxidad de seguridad (que podemos permitirnos al no tener usuarios unix bizantinos)

## Conforme a las ubicaciones propuestas en: 
## docs.ansible.com/ansible/latest/intro_configuration.html

[defaults]

## Nuestro inventario
inventory = ./hosts

## Nuestra carpeta con roles publicados en la ansible-galaxy
roles_path = ../UdelaRInterior

## Necesario para el rol systemli.bind9, 
## en que tenemos que hacer un "become" del usuario deploy al usuario bind
ALLOW_WORLD_READABLE_TMPFILES = true

Una vez configurado ese archivo, se pueden descargar los roles del requirements.yml con ansible-galaxy (FIXME)

Cualquier cosa, hay una instancia de los scripts de administración, disponibles para todo el equipo, en (pronto en ta.interior.edu.uy FIXME):

bourdieu.csic.edu.uy:~compartido/ansible

en la que, en particular, por ahora, hay que recuperar el archivo secretos.yml (que contiene lo que su nombre indica :) y que hay que tener en la raíz de nuestra flamenate carpeta de trabajo.

Pero OjO: una vez recuperado ese archivo (más aún si tu clave ssh ya está entre los admin), son un mono con una metralleta frente a un pelotón de servidores... :)

Organización de los playbooks en el proyecto config

El inventario, hosts, está escrito en yaml, y organiza 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).

Procuramos atenernos a las buenas prácticas de ansible, 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:
    ansible-playbook --limit interior 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:
    • el grupo de administradores de la plataforma y sus claves serán las que se instalan por omisión, y se suben en este archivo. Esta variable puede ser sobre-escrita indicando valores particulares en las host_vars u otros lugares que tenga precedencia al default de roles.
    • los parámetros de configuración por omisión de un contenedor están definidos acá
  • 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 (como indicado acá arriba), se va a agregar automáticamente a todos los hosts que corresponda corriendo:
      ansible-playbook --limit interior config/site.yml --tags=adminsys
      
    • tag descarga, que se exluye para evtar Gb de descargas. Por ejemplo, para crear los contenedores lxc que falten, sin por eso volver a descargar los más de 500Gb del template sólo para verificar que ya tenés la útlima versión, correríamos:
      ansible-playbook config/creaer_lxc.yml --skip-tags=descarga
      
Además de las buenas prácticas algunas elecciones que hemos hecho:
  • Nuestra carpeta de trabajo no es la carpeta de la copia del proyecto git, sino su carpeta madre. Por ende, solemos correr los playbooks indicando el camino relativo:
    ansible-playbook config/mi_playbook.yml
    

    O, para los playbooks que ya hicimos públicos:
    ansible-playbook adminsys/el_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, que está vinculado al rol acceso_adminsys para recuperar las claves de todxs lxs 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 delmismo 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.

Playbooks disponibles

Estamos trabajando sobre los playbook para la nueva plataforma acá: #6009

Ya tenemos y usamos los playbook siguientes:

  • config/site.yml, que simplemente incluye secuencialmente:
    • config/configurar_fierros_proxmox.yml para el nivel de servidores físicos,
    • config/crear_lxc.yml, que por ahora simplemente crea los contenedores definidos en el inventario y les configura accesos.
  • adminsys/debian_upgrade.yml, para actualizar por apt todos los servidores Debian y derivadas (en particular Ubuntu)
Todo el resto son muchas pruebas, en las que desarrollamos individualmente funciones, las primeras sin aún usar roles. Conviene hacer un poco de limpieza, pero ojo con limpiar demasiado, dado que hay funciones aún no retomadas, como:
  • adminsys/instalar_agente_zabbix.yml, playbook basado en uns script de Víctor A

Procesos de instalació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).

En ocasión de la instalación de un próximo nodo al cluster, convendría retomar esta tarea: #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:

  1. configuración de los repos de la UdelaR,
  2. desactivación del repo proxmox con suscripción y activación del sin suscripción,
  3. instalación del usuario deploy y de los adminsys
  4. puesta en cluster de los proxmox
  5. instalación de los certificados letsencryt

El playbook config/configurar_fierros_proxmox.yml ya hace parte de esto.

Explorar herramientas ansible, proxmox y otros

Compartir más

Además del proyecto * config, proyecto reservado, que contiene el inventario de servidores y scripts específicos a nuestra plataforma. Empezamos trabajando en este, habíamos empezado un segundo, que pretendía ser abierto, retirando la información sensible. Pero al final el compartir pasó más bien, según la propuesta de comunidad ansible, en la galaxy.

No obstante, quizás que algún día continuemos el proyecto adminsys, armá tu propia nube.