El reto del profesor: Caso Práctico

Para ver si ese "cerebelo" ya está carburando con la automatización, imagínate este escenario:

Escenario: El Concello de Ferrol necesita desplegar 10 servidores web nuevos para una campaña de participación ciudadana. Hacerlo a mano en vCenter te llevaría toda la mañana.
Pregunta: ¿Cómo justificarías técnicamente ante tu jefe el uso de una herramienta como Ansible para este proceso? Menciona al menos dos ventajas críticas relacionadas con la eficiencia y el error humano.

💡 Pistas para tu respuesta:

Idempotencia: Busca qué significa este término en Ansible (es clave en el examen).
Inventarios: Cómo Ansible sabe a qué máquinas atacar.
YAML: La sencillez de lectura del código.

Aclaraciones

Entiendo la Idempotencia, por su fórmula f(f(x)) = f(x) como una operación tal que f(x) = x / x por ejemplo, donde sea lo que sea x siempre dará 1, pero llevado a una matemática donde indendientemente de su resultado, éste sea el mismo sobre sí mismo como sobre el proceso de sí mismo. Según la definición sobre la aplicación informática es que tenemos una especie de maquetado para dar, mediante el mismo algoritmo, el mismo resultado. Entiendo con esto que Ansible es la Idempotencia de las VMs mediante los Templates. ¿Es así?

Por otro lado, me vas a matar, Gemini... ¿Te puedes creer que llevo 2 semanas omitiendo en mi cabeza esa parte de ferramentas libres que cláramente me enfatizaste? Que desastre... Por esa regla de tres, poco tiene que ver con el tema VMware. Aún así creo que fue importante por el hecho de que lo tenía bastante abandonado. Creo que en estos casos es mejor hablar sobre productos como VirtualBox, QemuKVM, etc. Por ese detalle.

Ahora la pregunta del millón... Leo que se puede configurar y demás el propio Ansible pero... ¿Realmente lo configuramos o configuramos un órgano genérico sobre un GUI como Virtual Box o incluso vCenter y éste se encarga de transmitirle lo que necesite a Ansimble para simplificar pues pese a usar YALM para simplificarlo, éste sea muy complejo como para tratarlo manualmente pese a los Playbooks?

Creo que es un tema que da miedo porque es un tema que fuera del ámbito profesional que masifica los servicios, este tipo de tecnologías ni se tocan ni en formación, y de ahí el problema que estoy teniendo, pero es una teoría simplemente.

Por otro lado... ¿Es Ansible quién tiene la gestión de las VMs y sus Templates o Scripts o archivos de maquetado?

Respuesta

Pues aquí, entendiendo como lo entiendo lo que es el Ansimble, y suponiendo que no halla capas de Software que ayuden a la definición simplificada de esta parte del Cloud Computing, sin ir más lejos, el hacer un intento de simplificación del lenguaje sobre YALM, eliminando factores programados o de codificación condicional como pueden ser archivos LUA entre otros. Además, a ésto le podemos sumar los Playbooks como una ayuda extra al lenguaje YALM para la gestión y configuración.

Por otro lado, un punto muy importante cara la gestión es el tema de gestión de agentes o una simple comunicación con los recursos, ya sea vía túnel como por integración con los recursos. En este caso tenemos una simplificación donde no se requieren agentes, evitando una implementación por cada entorno donde se despliegue el servicio.

Corrección

1. La "Pregunta del Millón": ¿Idempotencia es maquetar con Templates?

Tu intuición matemática es perfecta:

f(f(x))=f(x)

Si aplico una operación una vez, o la aplico cien veces, el resultado final es el mismo.

Pero en Ansible, la Idempotencia no es "hacer un template". Es una capacidad de decisión.

Sin Idempotencia (Script tradicional): Si ejecutas un script que dice "Crea la carpeta /var/www", y la carpeta ya existe, el script da error o intenta crearla de nuevo fallando.
Con Idempotencia (Ansible): Ansible primero mira la máquina. "¿Existe /var/www?". Si ya existe, no hace nada (estado OK). Si no existe, la crea (estado CHANGED).

En el examen: Define la idempotencia como la capacidad de Ansible de actuar solo si el estado actual no coincide con el estado deseado, garantizando la estabilidad del sistema sin importar cuántas veces lances el proceso.

2. ¿GUI o YAML? La cruda realidad de Ansible

Aquí es donde te doy el "toque" de profesor: Ansible es código puro (YAML). No hay un vCenter "bonito" donde arrastres cosas (bueno, existe Ansible Tower o AWX, pero para el examen, Ansible es línea de comandos).

¿Es complejo? Al revés. Se diseñó en YAML (Yet Another Markup Language) porque es casi como leer inglés.
¿Por qué no usamos una GUI? Porque el valor de la automatización en el Tema 25 es la Infraestructura como Código (IaC). Si el "plano" de tus 10 servidores es un archivo de texto, puedes guardarlo en Git, auditar quién lo cambió y replicarlo en otro Concello en segundos.

3. ¿Quién manda aquí? (Gestión de VMs)

Ansible no tiene las máquinas; Ansible da órdenes.

El Inventario: Un archivo de texto donde listas las IPs de tus 10 servidores.
El Playbook: El archivo YAML con las órdenes (instalar Apache, copiar la web, configurar el firewall).
El Destino: Ansible se conecta por SSH (en Linux) o WinRM (en Windows), ejecuta las órdenes y se desconecta.

Refinando tu respuesta para el Tribunal

Si te preguntan cómo justificar Ansible frente a tu jefe (o el tribunal), tu respuesta debe ser esta (aprovechando tus puntos buenos):

Justificación Técnica de Ansible

"Para el despliegue de los 10 servidores web, propongo el uso de Ansible por dos ventajas críticas:

Eficiencia mediante la arquitectura 'Agentless': A diferencia de otras herramientas, Ansible no requiere instalar software (agentes) en los servidores destino. Esto reduce la carga de mantenimiento y simplifica la seguridad, ya que solo necesitamos acceso vía SSH/WinRM.
Reducción del error humano mediante Idempotencia: Gracias a esta propiedad, podemos asegurar que los 10 servidores tendrán una configuración idéntica y predecible. Si lanzamos el proceso y uno falla a la mitad, podemos reintentarlo sin miedo a duplicar configuraciones o corromper el sistema, ya que Ansible solo aplicará los cambios estrictamente necesarios para alcanzar el estado deseado.
Trazabilidad con YAML: Al utilizar un lenguaje declarativo simple como YAML en nuestros Playbooks, cualquier técnico del departamento puede leer y entender la configuración de los servidores, eliminando la dependencia de scripts complejos y facilitando la documentación técnica exigida en la administración pública."

¿Cómo lo ves ahora?

Has dado en el clavo con lo de "sin agentes", eso es un punto ganador. Lo de VMware no te preocupes: en el examen puedes decir que usas Ansible para orquestar un entorno de virtualización KVM (que es libre) y quedarás como un auténtico experto en el Tema 25.

7.0 KiB Raw Blame History