48 lines
4.6 KiB
Markdown
48 lines
4.6 KiB
Markdown
> **El Examen de Desarrollo (El Jefe Final - Fase 1)**
|
|
|
|
# Pregunta 1: El dilema del constructor vs. el decorador.
|
|
|
|
Te encargan montar la nueva plataforma web del ayuntamiento. Necesitas crear 10 máquinas virtuales nuevas en el clúster de virtualización y, después, instalar en todas ellas Nginx y configurarlo. Teniendo en cuenta las herramientas de software libre del esquema (Terraform y Ansible), ¿usarías solo una para todo, o combinarías ambas? Explica qué rol le darías a cada herramienta y por qué.
|
|
|
|
## Respuesta
|
|
|
|
Aquí voy a hablar a ciegas porque nunca usé ninguna de estas tecnologías, y de lo poco que leí sobre éstas, para la parte de configuración e implementación de Software usaría Ansible, mientras que para la parte de la gestión de las máquinas virtuales usaría Terraform, por tanto, las combinaría.
|
|
|
|
## Corrección
|
|
|
|
- **Tu respuesta**: Combinarlas. Terraform para las máquinas y Ansible para el software.
|
|
- **Veredicto**: ¡Perfecto! Has definido el estándar de la industria. En el argot técnico, decimos que Terraform hace el *Provisioning* (construye la casa, la red, el hardware virtual) y Ansible hace el *Configuration Management* (pinta las paredes y pone los muebles, es decir, instala Nginx). Usar la herramienta adecuada para cada fase es de manual.
|
|
|
|
# Pregunta 2: El agente secreto.
|
|
|
|
En el departamento de informática hay un debate acalorado. El administrador más veterano quiere usar Puppet para gestionar la configuración de los servidores Linux, pero tú prefieres usar Ansible. Convence al veterano explicándole la principal diferencia arquitectónica entre ambas (agente vs. sin agente / Push vs. Pull) y por qué tu opción es más rápida de implementar.
|
|
|
|
## Respuesta
|
|
|
|
Ansible permite hacer una gestión de las máquinas sin necesidad de poner en cada una de ellas el agente correspondiente que sí requiere Puppet, con Ansible simplemente configuramos túneles SSH y ya no hay que condicionar a un Software implementado, dejando la máquina más limpia, además, si lo que queremos es centralizar la gestión, lo lógico es que sea el servidor de automatización y orquestación quien lleve las órdenes a las máquinas sin esperar reacción de las mismas. mediante su sistema Push. Anseible es más rápido tanto a nivel de:
|
|
|
|
- Aprender como nueva tecnología pues sólo es implementar túneles SSH y gestionar configuraciones vía YML.
|
|
- No tener que aprender la lógica de un DSL que trae Puppet.
|
|
- No hace falta un despliegue como tal fuera de la implementación de los certificados para los túneles SSH, por tanto, más rápido de implementar, gestionar y mantener en el tiempo.
|
|
|
|
## Corrección
|
|
|
|
- **Tu respuesta**: Ansible va por SSH sin agente, modo Push, sin el engorro del DSL de Puppet, usando YAML.
|
|
- **Veredicto**: ¡Matrícula de honor! Le acabas de dar un repaso argumental al veterano ficticio. Has tocado las tres palabras mágicas que caen en los test: *Agentless (sin agente), SSH, y Push*. Efectivamente, no dejar "basura" (agentes) instalada en los servidores destino es la gran ventaja de Ansible.
|
|
|
|
# Pregunta 3: El salto de fe.
|
|
|
|
Has estado usando docker-compose para levantar contenedores aislados (como vamos a hacer luego con Zabbix y Nagios). De repente, el servicio crece muchísimo y te exigen que la aplicación nunca se caiga, aunque un servidor físico arda en llamas. Te dicen que tienes que dar el salto a Kubernetes. ¿Qué problema fundamental te resuelve Kubernetes (orquestación) que un simple Docker o docker-compose no puede solucionar por sí solo?
|
|
|
|
## Respuesta
|
|
|
|
La implementación y el mantenimiento vital del conjuto de contenedores sobre una única estructura de control. Si lo miramos así tenemos que:
|
|
|
|
- Docker sólo es capaz de trabajar contenedor por contenedor pese a que éstos estén vinculados en su ecosistema.
|
|
- Docker Compose nos permite gestionar un conjunto de contenedores sobre un único gestor de control.
|
|
- Kubernetes lo lleva un paso más hallá y uno sobre un único sistema de gestión el conjunto de los anteriores en cantidades múltiples.
|
|
|
|
## Corrección
|
|
|
|
- **Tu respuesta**: Compose gestiona un conjunto, pero Kubernetes unifica múltiples gestiones a mayor escala.
|
|
- **Veredicto**: **¡Bien tirado, pero vamos a afilar el colmillo para el test!** El concepto lo tienes, pero el matiz exacto que busca un tribunal es el concepto de **Clúster y Alta Disponibilidad (HA)**. `docker-compose` levanta contenedores en un *único* servidor físico (Host). Si ese servidor arde, la app muere. Kubernetes (K8s) orquesta contenedores a través de *múltiples* servidores físicos (Nodos). Si uno arde, K8s hace *self-healing* (autocorrección) y levanta automáticamente esos contenedores en otro servidor sano que siga vivo. |