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.

Trabajamos en dos proyectos de código en git.interior.edu.uy:
  • adminsys, proyecto público en el que desarrollamos scripts genéricos que puedan ser reutilizados en otros contextos (por ahora un poco abandonado, pero tendremos que retomarlo, para entender mejor pasando en limpio y compartiendo),
  • config, proyecto reservado, que contiene el inventario de servidores y scripts específicos a nuestra plataforma. Empezamos trabajando en este.

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.

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, en esa bajas los juegos de scripts:

git clone git@git.interior.edu.uy:adminsys/config.git
git clone git@git.interior.edu.uy:cielito/adminsys.git

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:

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

[defaults]

inventory      = config/hosts

Cualquier cosa, hay una instancia de los scripts de administración, disponibles para todo el equipo, en:

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

en la que, en particular, por ahora, hay que recuperar el archivo secretos.yml.

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:
  • "colgmos" 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