Cómo configurar tu entorno de trabajo DevOps en 2026

En pocas palabras: Según la guía publicada el 22 de octubre de 2026 en dev.to, un entorno DevOps se configura creando una VM local Ubuntu 24.04 LTS con Multipass (comando: multipass launch 24.04 --name devops-lab --cpus 2 --memory 4G --disk 30G), generando una clave SSH con ssh-keygen e instalando herramientas básicas como git, curl, vim y jq. Como alternativa en Windows, Microsoft ofrece WSL2 mediante wsl --install.

Configurar un entorno de trabajo DevOps no empieza con Kubernetes ni con Terraform, aunque esa sea la expectativa típica. Según la guía publicada el 22 de octubre de 2026 en dev.to, el primer paso real es levantar una VM Ubuntu 24.04 LTS local con Multipass, generar una clave SSH y dominar un puñado de herramientas de terminal antes de tocar infraestructura en serio.

Un entorno de trabajo DevOps es la combinación de una terminal Linux, un conjunto de herramientas de línea de comandos y una máquina (local o remota) donde se pueden correr servicios, scripts y procesos sin arriesgar el sistema principal del usuario. Sirve como base de práctica antes de meterse con contenedores, Kubernetes o proveedores cloud.

¿Qué necesita realmente un entorno de aprendizaje DevOps?

Un entorno de aprendizaje DevOps necesita cubrir cuatro cosas, ni una más: manejar una terminal Linux, instalar herramientas de línea de comandos, correr servicios y procesos, y conectarse a máquinas remotas por SSH. No necesita parecerse a producción desde el primer día.

Pensalo como aprender a cocinar: nadie practica su primera milanesa en la plancha industrial del restaurante de la esquina, con el cocinero principal mirando el reloj. Primero se cocina en la casa, con margen para quemar algo, probar de nuevo y entender por qué el aceite salpica cuando está demasiado caliente. Un entorno de aprendizaje DevOps cumple esa misma función: un lugar donde el error no tiene consecuencias reales.

Ponele que arrancás sin saber nada de permisos de archivos ni de systemd. No pasa nada: la propuesta es empezar justo ahí, con una terminal básica, antes de sumar contenedores o clusters. Si todavía Git te genera ansiedad, ese es un problema aparte (y bastante común, dicho sea de paso).

¿Por qué se recomienda una VM local con Ubuntu 24.04 LTS?

Se recomienda Ubuntu 24.04 LTS porque da un baseline compartido de Linux real: systemd, systemctl, journalctl, networking, permisos y paquetes, todo en una máquina que se puede romper sin tocar el sistema principal. No es que Ubuntu sea mágicamente mejor que otras distros.

Es, básicamente, un servidor de práctica en miniatura. Si la destruís, la borrás y creás otra: es más sensato que intentar entender cómo funciona un motor desarmando el auto de la familia en la vereda. Te puede servir nuestra cobertura de la comparativa completa entre Microsoft y GitHub.

La herramienta elegida para crear esa VM es Multipass, de Canonical, que permite levantar máquinas Ubuntu desde la CLI de forma reproducible. El esquema es simple: tu máquina física corre Multipass, y Multipass administra una VM llamada devops-lab.

Eso sí: Multipass no es un requisito religioso. Si trabajás en una laptop corporativa con restricciones de seguridad, o ya usás VirtualBox, VMware, UTM, Hyper-V o libvirt, podés seguir con lo que tengas permitido. El objetivo final siempre es el mismo: terminar con una Ubuntu 24.04 LTS (o distro equivalente) accesible, donde instalar paquetes y practicar sin miedo.

Criterios de decisión: ¿qué opción elegir según tu situación?

Antes de instalar nada, conviene responder tres preguntas que determinan qué camino seguir de los cuatro disponibles (Multipass, WSL2, Linux local o cloud):

• ¿Qué sistema operativo usás a diario? Si es Windows y no hay restricciones corporativas, Multipass o WSL2 son las opciones naturales. Si ya usás Linux, podés evaluar si querés aislar el aprendizaje en una VM o animarte directo en tu sistema real.
• ¿Tenés restricciones de virtualización o de política de IT? Una laptop corporativa con virtualización deshabilitada en BIOS, o una política que prohíbe instalar hipervisores de terceros, descarta Multipass y VirtualBox de entrada. Ahí WSL2 (si es Windows) o una cuenta cloud con free tier quedan como alternativas más viables.
• ¿El objetivo es aprender conceptos o practicar contra infraestructura real? Para fijar conceptos de terminal, permisos y SSH, una VM local alcanza y sale gratis. Para practicar IAM, redes de nube o Terraform contra recursos reales, no hay atajo: en algún momento hace falta una cuenta cloud, aunque sea con free tier.

La lógica de fondo es de dependencias, no de preferencia estética: primero necesitás una máquina Linux estable (VM o real), después una forma de entrar a ella (SSH o acceso directo), y solo después tiene sentido instalar herramientas. Saltarse el orden —por ejemplo, instalar Kubernetes antes de entender permisos de archivos— suele traducirse en errores que parecen de Kubernetes pero son, en el fondo, errores de Linux básico.

Ejemplo hipotético: elegir entorno según el perfil

Ejemplo hipotético, no corresponde a un caso real. Imaginemos dos perfiles distintos que necesitan preparar el mismo entorno de aprendizaje DevOps:

• Perfil A: usa una notebook personal con Windows 11, sin restricciones de IT, y nunca tocó una terminal Linux. Según los criterios anteriores, Multipass es la opción más directa: instala con winget install -e --id Canonical.Multipass, crea la VM con el comando estándar, y entra con multipass shell devops-lab sin necesidad de configurar SSH todavía.
• Perfil B: usa una laptop corporativa con Windows 11, virtualización de terceros bloqueada por política de seguridad, pero WSL ya habilitado por el equipo de IT. En este caso Multipass queda descartado de entrada, y wsl --install desde PowerShell como administrador es el camino razonable, aceptando que el comportamiento de filesystem y networking no va a ser idéntico al de una VM tradicional.

Ninguno de los dos perfiles necesita decidir sobre cloud todavía: esa decisión llega después, cuando el objetivo deja de ser “entender una terminal Linux” y pasa a ser “practicar contra infraestructura real con consecuencias de facturación”.

¿Cómo instalar Multipass y crear la VM devops-lab?

Multipass se instala con un comando distinto según el sistema operativo, y la VM devops-lab se crea con un único comando que define CPU, memoria y disco. Así de directo.

• macOS y Linux con Homebrew: brew install --cask multipass
• Ubuntu/Debian: sudo snap install multipass
• Arch Linux (AUR): paru -S canonical-multipass
• Windows (PowerShell): winget install -e --id Canonical.Multipass

Los usuarios de Arch ya conocen la rutina: si multipassd no arranca, hay que instalar dnsmasq y agregar ReadWritePaths=/usr/local/etc/multipassd al servicio. Si QEMU no encuentra OVMF.fd, hay que simlinkearlo desde edk2-ovmf.

Una vez instalado, se verifica con multipass version y se crea la VM del curso con:

multipass launch 24.04 --name devops-lab --cpus 2 --memory 4G --disk 30G Complementá con cómo conectarte por SSH a una VM.

Eso deja una Ubuntu 24.04 con 2 CPUs, 4 GB de RAM y 30 GB de disco. Si la máquina física anda corta de recursos, se puede bajar a --memory 2G, aunque 4 GB da más margen para lo que sigue.

• Listar VMs: multipass list
• Entrar a la VM: multipass shell devops-lab
• Salir: exit
• Detenerla: multipass stop devops-lab
• Volver a arrancarla: multipass start devops-lab
• Borrarla del todo: multipass delete devops-lab seguido de multipass purge

Romper una VM de laboratorio no es tragedia, es casi parte del proceso: es más parecido a armar un mueble sin leer las instrucciones la primera vez. Queda torcido, pero la segunda vez entendés cómo encajan las piezas.

Multipass, WSL2, Linux local o cloud: ¿qué alternativa conviene?

La alternativa que conviene depende del sistema y las restricciones de cada uno: Multipass es el baseline recomendado, WSL2 funciona bien en Windows cuando Multipass no entra, Linux local sirve para quien ya lo usa a diario, y el cloud queda para más adelante, cuando entran IAM y redes reales.

Opción	Cuándo usarla	Trade-off principal
Multipass	Baseline recomendado del curso	Depende de la virtualización local
WSL2	Usás Windows y Multipass no te cierra	Muy práctico, con algunos momentos típicos de Windows
Linux local	Ya usás Linux y sabés qué estás tocando	Podés romper tu sistema real
Cloud	Querés infraestructura pública real	Más realista, pero entra la facturación en la conversación

Para WSL2, Microsoft documenta la instalación básica con un solo comando desde PowerShell como administrador: wsl --install, que instala WSL y, por defecto, Ubuntu. Windows después va a pedir un reinicio (el ritual que mantiene humilde a todo el ecosistema).

¿Y el cloud? Puede esperar. Entra cuando hace falta de verdad: seguridad, networking de nube, Terraform contra infraestructura real. El free tier de los proveedores cloud sirve si se respetan los límites, aunque prometer que todo el curso sale gratis en cloud sería tan arriesgado como jurar que ese YAML va a andar bien a la primera. Si en algún momento el plan es alojar servicios propios en Argentina de forma permanente (no solo de práctica), vale mirar opciones de hosting y VPS como las de donweb.com, pensadas para infraestructura real y no solo para laboratorio.

¿Cómo practicar SSH contra la VM local?

SSH se practica generando un par de claves con ssh-keygen -t ed25519, transfiriendo la clave pública a la VM con multipass transfer y agregándola al archivo authorized_keys dentro de la máquina. Después se conecta con ssh ubuntu@<ip-de-la-vm>.

Los pasos, en orden:

• Generar la clave: ssh-keygen -t ed25519 -C "devops-course", aceptando la ruta por defecto (~/.ssh/id_ed25519).
• Transferir la clave pública: multipass transfer ~/.ssh/id_ed25519.pub devops-lab:/home/ubuntu/id_ed25519.pub.
• Agregarla a authorized_keys: dentro de la VM, con mkdir -p ~/.ssh, cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys, chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys.
• Obtener la IP de la VM: con multipass info devops-lab, buscando la línea IPv4.
• Conectar por SSH: ssh ubuntu@<ip>, o con -i ~/.ssh/id_ed25519 si hace falta especificar la clave.

La clave privada (id_ed25519, sin extensión) nunca se comparte. Funciona más parecido al PIN de una tarjeta que a una llave física: se la mostrás únicamente a tu propia terminal para que te reconozca, y nunca la mandás por un chat de equipo aunque alguien lo pida con apuro. Obvio, hasta que alguien lo hace. Sobre eso hablamos en las certificaciones de Azure según tu rol.

Si la conexión por IP no funciona, no hay drama: algunos drivers, firewalls o configuraciones de red bloquean el acceso directo. Para seguir el curso alcanza con multipass shell; SSH acá es práctica extra, y vuelve en serio cuando aparece el cloud.

¿Qué herramientas esenciales instalar en la terminal?

Las herramientas esenciales para arrancar son siete: git, curl, wget, vim, htop, jq y net-tools (o sus equivalentes modernos). Cada una cubre una necesidad puntual del trabajo diario en DevOps.

• git: versiona archivos y scripts.
• curl y wget: hacen requests y descargan recursos.
• vim: edita archivos en terminal (si te atrapa y no sabés salir, no es un bug, es una ceremonia de iniciación).
• htop: muestra procesos sin sufrir la estética de 1998 de top.
• jq: permite trabajar con JSON sin llorar.
• net-tools: cubre comandos básicos de networking.

La instalación cambia según el sistema:

• Homebrew: brew install git curl wget vim htop jq
• Ubuntu/Debian: sudo apt update && sudo apt install -y git curl wget vim htop jq net-tools
• Arch Linux: sudo pacman -S git curl wget vim htop jq net-tools

Después de instalar, conviene verificar con git --version, curl --version, vim --version y jq --version. No hace falta memorizar cada herramienta de entrada: git da trazabilidad, curl permite hablar con servicios, jq lee JSON sin drama, y htop muestra procesos de forma legible.

¿Cómo dejar la terminal más cómoda con zsh y Oh My Zsh?

La terminal se vuelve más cómoda instalando zsh y, opcionalmente, Oh My Zsh encima. Se puede hacer todo el curso con bash default, sin plugins ni colores, de la misma forma que se puede escribir código en un editor de texto con fuente diminuta: posible no es lo mismo que prudente.

La instalación de zsh:

• Homebrew: brew install zsh
• Ubuntu/Debian: sudo apt install -y zsh
• Arch Linux: sudo pacman -S zsh

Oh My Zsh se instala con un script remoto, y ahí va la salvedad obligada: la versión responsable es leerlo antes de ejecutarlo; la versión realista es, al menos, correrlo desde la fuente oficial de GitHub y no desde cualquier blog random de 2020.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" Relacionado: el caso de repos de GitHub comprometidos.

Para cambiar el shell por defecto, en la VM de Multipass el usuario ubuntu no tiene password, así que hace falta sudo: sudo chsh -s $(which zsh) ubuntu. En otros sistemas, chsh puede pedir la contraseña directamente sin sudo; el resultado final es el mismo.

Errores comunes al configurar el entorno de trabajo DevOps

• Arrancar directo en cloud sin pasar por una VM local: genera factura desde el día uno y complica depurar errores básicos de permisos o networking que convendría resolver gratis, en local, primero.
• Compartir la clave privada SSH por error: solo la clave pública (.pub) va a la máquina remota. Si la privada se pegó en un chat de equipo alguna vez, hay que rotarla, no solo borrarla del mensaje.
• Asignarle muy pocos recursos a la VM: con 2 GB de RAM una VM “funciona”, pero de forma parecida a un router viejo prestado: anda, hasta que justo lo necesitás y se cuelga.
• Ejecutar scripts remotos de instalación sin mirarlos: pasa seguido con instaladores tipo Oh My Zsh. Conviene al menos confirmar que el script viene de la fuente oficial antes de correrlo con curl | sh.

Preguntas Frecuentes

¿Qué necesito instalar para trabajar en DevOps?

Para empezar hacen falta una terminal Linux (real o virtualizada), y siete herramientas CLI básicas: git, curl, wget, vim, htop, jq y net-tools. A partir de ahí se suma SSH para conectarse a máquinas remotas, y más adelante contenedores y orquestadores.

¿Conviene usar WSL2 o una máquina virtual Linux para DevOps?

Una VM Linux tradicional, como la que crea Multipass con Ubuntu 24.04 LTS, da un comportamiento más parecido a un servidor real en filesystem, networking y servicios. WSL2 es una alternativa válida en Windows cuando Multipass no funciona, pero no se comporta exactamente igual que una VM en todos los casos.

¿Cómo creo una VM Ubuntu con Multipass?

Con el comando multipass launch 24.04 --name devops-lab --cpus 2 --memory 4G --disk 30G, que crea una Ubuntu 24.04 con 2 CPUs, 4 GB de RAM y 30 GB de disco. Para entrar a la VM alcanza con multipass shell devops-lab.

¿Qué herramientas de terminal son esenciales en DevOps?

Las esenciales para arrancar son git, curl, wget, vim, htop, jq y net-tools. Cubren versionado, requests HTTP, edición de archivos, monitoreo de procesos, lectura de JSON y comandos básicos de red respectivamente.

¿Cómo configuro acceso SSH a una VM local?

Generando una clave con ssh-keygen -t ed25519, transfiriendo la parte pública a la VM con multipass transfer, agregándola al archivo ~/.ssh/authorized_keys dentro de la máquina, y conectando después con ssh ubuntu@<ip-de-la-vm>, usando la IP que devuelve multipass info devops-lab.

Conclusión

Configurar un entorno de trabajo DevOps en 2026 no requiere un clúster, ni facturación cloud desde el minuto uno, ni siquiera decidir entre diez distros de Linux. Alcanza con una VM Ubuntu 24.04 LTS local manejada con Multipass, una clave SSH generada a mano y un set chico de herramientas CLI bien elegidas.

Lo que sí vale la pena hacer antes de avanzar a Kubernetes o Terraform: practicar en una VM que se pueda romper sin consecuencias, entender permisos y procesos con systemctl y journalctl, y animarse a conectar por SSH aunque Multipass ya dé una puerta cómoda por defecto. Un criterio simple para verificar que el entorno está listo antes de seguir: si podés crear la VM, entrar por SSH con tu propia clave, instalar las siete herramientas básicas y destruir la VM sin miedo, el entorno cumple su función. Lo demás (zsh, Oh My Zsh, alias) es comodidad, no requisito.

Fuentes

• dev.to – Setting up your DevOps work environment: Linux, terminal, and essential tools