Nuestra estrategia de Infraestructura como Código (IaC)

En Principia Informática nos gusta gestionar las infraestructuras de cómputo que usamos para desarrollo y producción de manera tal que, en todo momento, conozcamos y entendamos cada línea que se ejecuta en nuestros servidores. Eso significa construir entornos reproducibles desde cero, probarlos de forma destructiva, y desplegarlos sin frameworks ni intermediarios que oculten lo que está pasando. También significa decidir, con criterio propio, qué herramientas no usamos.

Stack de base

Nuestro entorno de desarrollo corre sobre Windows como host, con máquinas virtuales Ubuntu Server gestionadas con VirtualBox. El acceso a las VMs lo hacemos vía Bitvise SSH Client; la edición de archivos remotos, con Notepad++ usando el plugin NppFTP. Las carpetas compartidas de VirtualBox nos permiten editar en Windows y ejecutar en Linux en tiempo real. Es un stack consolidado, sobre el que tenemos control completo y visibilidad de cada componente.

Infraestructura inmutable

Tratamos nuestros servidores de prueba como "ganado", no como "mascotas". Si un script falla a la mitad o deja el sistema en un estado inconsistente, no perdemos tiempo depurando: descartamos la VM, clonamos una limpia y volvemos a probar desde cero.

Para hacer eso viable sin fricción, mantenemos una arquitectura de imágenes por capas, lo que la industria llama Golden Images. Conservamos una serie de VMs configuradas hasta cierta capa, que funciona como nuestro propio caché de construcción:

Capa 1: solo las características del hardware emulado.
Capa 2: Ubuntu Server instalado.
Capa 3: VirtualBox Guest Additions instaladas.
Capa 4: nuestro stack habitual de trabajo configurado.

Cuando necesitamos incorporar algo nuevo, reconstruimos desde la última capa que puede permanecer intacta. El costo de empezar de cero es bajo; la confianza en el entorno resultante, alta.

Despliegue y seguridad

El salto del entorno de pruebas a producción es directo. Al usar VMs locales con Ubuntu Server completo, tenemos fidelidad 1:1 con el servidor destino: misma red, mismo systemd, mismo firewall. Nos conectamos con el mismo cliente SSH que usamos localmente, abrimos una sesión SFTP, copiamos los archivos del instalador y ejecutamos el script en la VM remota. Sin agentes intermediarios.

Cuando nuestros scripts aprovisionan el servidor de producción, aplican dos políticas que no están en discusión. La primera es la separación de configuración y código: la información sensible — contraseñas, tokens, variables de entorno — jamás va en el código. Reside en archivos separados, con los permisos más restrictivos posibles.

La segunda es el principio de mínimo privilegio. Configuramos los servicios para que corran bajo un usuario propio, creado específicamente para ese proceso. Ese usuario no tiene directorio home, no tiene contraseña asignada y no tiene shell interactiva. Si el proceso es vulnerado, el atacante gana acceso a una cuenta con la que no se puede operar dentro del servidor.

Las herramientas que descartamos

Conocemos las herramientas que la industria usa para estas tareas. Nuestra preferencia, de momento, es no incorporarlas.

WSL 2. No nos resulta adecuado para este caso de uso. Desarrollar scripts que tocan systemd a bajo nivel requiere la garantía de un entorno idéntico a producción. WSL tiene una red abstraída y no ofrece el ciclo de clonación rápida y destructiva que nos da VirtualBox para recrear entornos limpios.

Vagrant y HashiCorp Packer. Nuestra preferencia es el control manual. Nos interesa observar el proceso de instalación en la consola: en la salida estándar aparecen warnings de deprecación, incompatibilidades entre paquetes y oportunidades de optimización que la automatización ciega no expone.

Ansible, Chef y Puppet. El flujo SFTP + SSH hace exactamente lo mismo — transferencia segura de artefactos y ejecución remota — sin obligarnos a incorporar un lenguaje declarativo adicional, sin instalar dependencias extra, y manteniendo el control completo sobre cada línea del script que se ejecuta en el servidor.

Apuntes generales

Hay una presión constante en la industria hacia la adopción de herramientas estándar. La lógica es comprensible: las herramientas populares tienen comunidades, documentación y soporte. Nuestra lectura es que esa lógica aplica mejor a equipos grandes, con rotación de personal y necesidad de estandarizar prácticas entre muchas personas.

En nuestro caso, el criterio que prima es otro: entender cada línea de lo que se ejecuta en nuestros servidores. Eso no es posible cuando la herramienta abstrae el proceso. De momento estamos convencidos de que esa visibilidad vale más que la comodidad de delegar.