Nadie sabe cómo se montó
Una empresa de reparto de Bilbao tiene su web en tres servidores. Los montó Javier, a mano, hace cuatro años.
Javier ya no trabaja allí. Un día el disco de un servidor se rompe. Nadie sabe qué programas tenía, qué versiones ni qué ajustes.
El equipo tarda tres días en rehacerlo. Esta lección explica cómo se rehace en minutos.
Al final de esta lección
Nota
Puedo explicar por qué los servidores se describen en archivos.
Palabras clave
| Palabra | Qué significa |
|---|---|
| Infraestructura | las máquinas, redes y bases de datos donde vive una aplicación |
| Infraestructura como código | describir la infraestructura en archivos de texto |
| Estado deseado | lo que el archivo dice que debe existir |
| Plan | la lista de cambios para llegar al estado deseado |
| Deriva | la diferencia entre el archivo y lo que hay de verdad |
| Idempotente | que aplicarlo dos veces da lo mismo que una |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
A mano no queda nada escrito
Montar un servidor a mano es hacer clic en la consola del proveedor o escribir órdenes una a una. Funciona, pero no deja rastro.
Con infraestructura como código, escribes en un archivo qué servidores quieres y cómo son. Una herramienta lee el archivo y los crea.
El archivo vive en Git. Se revisa como el código, tiene historial y sirve para rehacerlo todo.
A mano o en un archivo
| Pregunta | A mano | En un archivo |
|---|---|---|
| ¿Cómo era el servidor? | Hay que preguntar a alguien | Se lee en el archivo |
| ¿Quién lo cambió y cuándo? | No se sabe | Lo dice el historial de Git |
| ¿Cuánto se tarda en rehacerlo? | Días | Minutos |
| ¿Y montar una copia para pruebas? | Otra vez a mano | El mismo archivo |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
La herramienta compara lo deseado con lo real
El archivo describe el estado deseado. La herramienta mira lo que existe de verdad y lo compara.
De esa comparación sale un plan: qué crear, qué cambiar y qué borrar. Si alguien tocó algo a mano, aparece como deriva.
El bloque siguiente hace esa comparación con dos listas. Ejecútalo y haz el cambio del último comentario.
Comparar lo deseado con lo real
mkdir -p infra && cd infra
# Lo que dice el archivo del repositorio
printf 'web-1 pequeño\nweb-2 pequeño\nbase-datos grande\n' > deseado.txt
# Lo que hay de verdad en el proveedor
printf 'web-1 pequeño\nbase-datos mediano\nprueba-javi pequeño\n' > real.txt
echo "Falta o es distinto (hay que crearlo o cambiarlo):"
grep -vxF -f real.txt deseado.txt
echo "Sobra (nadie lo pidió en el archivo):"
grep -vxF -f deseado.txt real.txt
# Añade 'web-2 pequeño' a real.txt y vuelve a ejecutar.
Terraform enseña el plan antes de aplicarlo
Terraform es una de las herramientas más pedidas en las ofertas de empleo. Antes de cambiar nada, terraform plan enseña lo que va a hacer.
El signo + es crear, ~ es cambiar y - es borrar. Después, terraform apply hace los cambios. Esta salida es real y no se ejecuta aquí.
La salida de un plan
$ terraform plan
# aws_instance.web_2 will be created
+ resource "aws_instance" "web_2" {
+ instance_type = "t3.small"
}
# aws_db_instance.base will be updated in-place
~ resource "aws_db_instance" "base" {
~ instance_class = "db.t3.medium" -> "db.t3.large"
}
Plan: 1 to add, 1 to change, 0 to destroy.Aplicarlo dos veces no hace daño
Si aplicas el mismo archivo dos veces, la segunda vez el plan sale vacío. Ya no hay diferencias.
Eso se llama ser idempotente. Por eso se puede aplicar el archivo cada día sin miedo. Si alguien ha tocado algo a mano, se corrige solo.
Un error frecuente
Advertencia
Mucha gente cree que, con el archivo escrito, un arreglo rápido en la consola no importa. Sí importa. El arreglo no está en el archivo, y la próxima vez que se aplique se perderá. Cambia siempre el archivo, nunca solo el servidor.