Laboratorio de OpenTofu: la infraestructura como código, con plan, apply y estado, en una VM

Este laboratorio da a cada alumno OpenTofu en su propia máquina Ubuntu. La infraestructura como código consiste en describir en archivos lo que debe existir y dejar que una herramienta averigüe cómo llegar: compara los archivos con el registro de lo que ya ha construido, muestra la diferencia como un plan y solo entonces cambia algo. El alumno escribe un proyecto pequeño, lee planes, mira el estado y arregla un proyecto roto.

OpenTofu es libre y gratuito, y no hace falta ninguna licencia. No se instala nada en el ordenador del alumno. Lo único que el laboratorio deja fuera es una nube real: lo dice él mismo, y esta página también.

Qué aprenden los alumnos

Los hábitos de trabajo de la infraestructura como código, en seis partes. Un primer plan y un primer apply, y el archivo de estado que dejan. Variables y salidas. Varias copias de una cosa a partir de una descripción, con count y con for_each, y por qué for_each es el que conserva los nombres. Leer un plan después de un cambio y decir qué se creará, cambiará o destruirá antes de que ocurra nada. Para qué sirve el estado, borrándolo y viendo que el plan quiere volver a crearlo todo. Y encontrar tres errores en un proyecto, un tipo incorrecto, una variable que falta y un ciclo, con tofu validate. Por el camino, tofu fmt, tofu console y las dependencias entre recursos.

Qué es real aquí y qué no

Las nubes y los servicios reales se alcanzan mediante proveedores, complementos que OpenTofu descarga de un registro. La VM de un alumno solo llega al archivo de Ubuntu, PyPI, npm y GitHub, así que no se puede descargar ningún proveedor y en este laboratorio nunca se crea nada real. Lo que viene integrado en OpenTofu no necesita descarga: el recurso terraform_data, que solo guarda un valor y lo devuelve. Con él, las variables, las salidas, count, for_each, las dependencias, plan, apply, destroy y el estado son lo auténtico. Un proveedor como AWS o Docker solo cambia lo que fabrica un bloque de recurso. El README muestra uno como texto para leer y el laboratorio no lo ejecuta nunca.

Las tres carpetas

En la carpeta personal hay tres carpetas. hello funciona tal como está, para el primer plan y apply, una variable y el estado. campus es el proyecto del alumno, escrito desde cero según una lista del README: tres variables, servidores hechos con for_each, aulas hechas con count, un resumen que lee ambos y dos salidas. fix es un proyecto con tres errores que encontrar y corregir.

Ejecútalo en tu navegador

Los laboratorios de VM se ponen como tarea de laboratorio en un módulo, y el ejemplo está en la página del laboratorio. La máquina es pequeña: una CPU, 1 GB de memoria y 10 GB de disco. El propio OpenTofu usa unos 80 MB mientras trabaja.

  1. Añade el laboratorio. En un módulo que impartes, añade una tarea y elige la tarjeta de laboratorio de VM Ubuntu. La página muestra una descripción corta de la máquina en lugar de un archivo compose.
  2. Empieza desde el ejemplo. La página ofrece laboratorios ya hechos para empezar. Elige OpenTofu. Usar un ejemplo sustituye el texto, y Deshacer recupera el tuyo.
  3. Publica e inicia tu propia copia. Publica y pulsa Iniciar. El script setup del laboratorio instala algunas herramientas desde el archivo de Ubuntu, descarga OpenTofu 1.13.2 desde su versión publicada en GitHub, comprueba el archivo con una suma de comprobación fija y lo instala, la primera vez que arranca la VM, en un minuto o dos. La descarga necesita una cuenta: la VM de un visitante solo llega al archivo de Ubuntu.
  4. Abre el terminal. Abre su terminal y lee README.md en la carpeta personal: dice qué hacer en seis partes y no da ninguna respuesta.

Una lección básica en este laboratorio

OpenTofu Basics es una pequeña lección que se trabaja en este laboratorio, una VM Ubuntu. Tiene un gancho, un objetivo «puedo», palabras clave, un arranque, una comprobación tras las ideas, un error frecuente y una comprobación final, y cada paso tiene un botón Ejecutar que escribe su comando en el terminal de la máquina. El alumno lee un proyecto, ejecuta init y plan, aplica y lista el estado, cambia un valor y lee el plan, y después borra el estado y ve que el plan quiere crear lo que ya existe.

La lección explora y deja al alumno la tarea propia del laboratorio, el proyecto y el proyecto roto, así que no da ninguna respuesta.

Cómo se califica

El laboratorio tiene una comprobación. Copia las dos carpetas del alumno a otro sitio, de modo que su propio estado no cuenta, y rechaza proveedores y provisioners. Después valida y exige archivos ordenados (tofu fmt). Para el proyecto campus elige sus propios valores para las variables, un nombre de centro que nadie ha visto y sus propios servidores y aulas, planifica y aplica. El estado debe contener un servidor por cada nombre, cada uno con el sitio y el nombre como entrada, las aulas numeradas desde uno y una salida summary que lee un recurso en lugar de estar escrita a mano, además de los nombres. Un recurso sin entrada falla, y también una salida que no sigue las variables. Luego la comprobación quita un servidor y añade dos, vuelve a planificar y exige que solo se destruya ese y solo se creen los dos. Aplica, exige que no quede nada por cambiar y destruye. Por último, el proyecto roto debe validar, aplicarse, conservar sus recursos y seguir su variable. La primera línea de lo que imprimió la comprobación dice por qué.

  1. Reparte el laboratorio. Asigna el laboratorio como cualquier tarea, con fecha de entrega si quieres. Cada alumno recibe una VM propia, que se conserva entre sesiones.
  2. Ejecuta la comprobación. En la fila de un alumno en la lista de la clase, pulsa Ejecutar la comprobación. Inicia una copia de su máquina guardada que no se vuelve a guardar, ejecuta como root el script de comprobación del laboratorio y muestra si pasó, qué imprimió y cuándo. El alumno no recibe el resultado.
  3. Califica. Lee la primera línea de lo que imprimió la comprobación: dice qué no está bien, por ejemplo servidores que no coinciden con las variables, un resumen que no lee los servidores o un plan que después del apply aún quiere cambiar algo. Devuelve el trabajo con un motivo si necesita más.

La definición en GitHub

El archivo es toda la definición del laboratorio, el mismo texto que ejecuta la plataforma: tamaño, script setup, el comando tofulab, los tres proyectos, README y comprobación. Cópialo y cambia el proyecto, las variables o los errores para hacer un laboratorio más largo.

Prueba este laboratorio, y lo que cuesta

Con una cuenta personal gratuita puedes seguir las lecciones básicas de este laboratorio, con crédito gratuito suficiente cada mes para seguir la mayoría de las lecciones y sin tarjeta. Para una clase, un centro tiene gratis sus primeros 365 días, hasta 50 alumnos, y después paga por alumno y año, con todos los laboratorios incluidos y el profesorado gratis.

Preguntas frecuentes

¿Necesita licencia el laboratorio de OpenTofu?
No. OpenTofu es libre, con la Mozilla Public Licence 2.0, un proyecto de la Linux Foundation nacido como bifurcación de Terraform. El laboratorio usa OpenTofu y nunca Terraform, cuya licencia no es libre. Se descarga de la versión publicada del proyecto cuando arranca la VM del alumno, y nosotros no distribuimos nada de él.
¿Por qué los alumnos no pueden crear un servidor real?
Un servidor real se crea mediante un proveedor, y los proveedores se descargan de un registro al que la VM de un alumno no llega: solo llega al archivo de Ubuntu, PyPI, npm y GitHub. Por eso el laboratorio enseña todo menos el proveedor, con el único recurso que OpenTofu trae integrado. Plan, apply y estado se comportan igual con uno real, que es el sentido de aprenderlos aquí.
¿Quién puede ejecutarlo?
Quien tenga una cuenta, gratuita o de un centro. El laboratorio descarga OpenTofu de GitHub la primera vez que arranca la VM, y la VM de un visitante, que solo llega al archivo de Ubuntu, no puede. Si una descarga falla, sudo tofulab install lo reintenta, y la comprobación dice que falta OpenTofu en lugar de fallar por otro motivo.
¿Pueden los alumnos dañar algo?
Solo su propia copia. Nada de lo que crea el laboratorio queda fuera del propio estado de OpenTofu, y la VM llega al archivo de Ubuntu, PyPI, npm y GitHub y a nada más. Si un alumno estropea una carpeta, sudo tofulab reset devuelve sus archivos.
¿Se probó el laboratorio en una VM real de alumno?
El script setup, con la descarga real y su suma de comprobación, los comandos de la lección y la comprobación se ejecutaron en un Ubuntu 26.04 real, en un contenedor que sustituye a la VM, sin necesitar red después de la descarga. Una VM de alumno realmente arrancada tras el proxy de lista permitida de la plataforma, que la descarga de GitHub tiene que atravesar, merece una prueba antes de una clase.