Linux para DevOps: la guía que nadie te dio en 2026
Los fundamentos de Linux para DevOps son el conocimiento base que todo ingeniero de infraestructura necesita antes de tocar Kubernetes, Docker o cualquier pipeline de CI/CD. El sistema operativo Linux corre en la mayoría de los servidores de producción del mundo, y sin entender cómo funciona por dentro, estás construyendo sobre arena.
En 30 segundos
- Linux es el sistema operativo de base en la mayoría de entornos cloud y contenedores: Google, Meta y Amazon corren su infraestructura sobre él.
- El sistema de archivos de Linux tiene una jerarquía estándar con directorios como /etc, /bin, /var y /home, cada uno con un propósito específico.
- Los permisos rwx y el modelo de usuarios/grupos son críticos para la seguridad en producción: un chmod 777 puede abrir una brecha grave.
- Comandos de navegación, búsqueda, procesos y red son el vocabulario mínimo para operar cualquier servidor Linux.
- Ubuntu y CentOS/RHEL son las distros más comunes en ambientes DevOps; la elección impacta directamente en el gestor de paquetes y las rutas de configuración.
Por qué Linux es insustituible en DevOps y Cloud
Podés pasarte meses aprendiendo Helm charts, Terraform modules, GitHub Actions y toda la cadena de herramientas DevOps modernas, pero tarde o temprano vas a estar debugueando un pod que no levanta, un script de deploy que falla silenciosamente o un permiso de archivo que rompe todo en producción. Y ahí, sin excepción, necesitás entender Linux.
No es una exageración. Kubernetes corre sobre nodos Linux. Los contenedores Docker son procesos Linux con namespaces y cgroups. Las pipelines de CI/CD ejecutan sus jobs en runners Linux. Los servidores de base de datos, los balanceadores de carga, los servicios de monitoreo: Linux debajo de todo.
Según el artículo de referencia publicado el 13 de mayo de 2026, empresas como Google, Meta y Amazon dependen de Linux para su infraestructura. Eso no es una preferencia estética: es que Linux ofrece control granular sobre recursos, estabilidad probada en décadas de producción y un ecosistema de herramientas que no tiene equivalente en otros sistemas.
¿Y qué pasa cuando salteás esta base y te metés directo en Kubernetes? Exacto: configurás cosas sin entender qué están configurando, el primer error de permisos te paraliza horas, y cada vez que algo falla en producción dependés de que alguien más lo resuelva.
Linux: Kernel vs Distribuciones
Linux es el kernel (el núcleo que maneja la comunicación entre el hardware y el software: memoria, CPU, dispositivos, red). Las distribuciones (distros) son sistemas completos armados alrededor de ese kernel, con sus propias herramientas, gestores de paquetes y filosofías.
Las distros más comunes que vas a ver en entornos DevOps son Ubuntu, Debian, CentOS/RHEL y Alpine. Ubuntu domina en cloud pública y entornos de desarrollo. CentOS/RHEL es el estándar en empresas con infraestructura corporativa regulada. Alpine aparece en imágenes Docker porque pesa muy poco (menos de 10 MB base). Más contexto en automatización de deployments en Linux.
La elección de distro no es trivial: determina el gestor de paquetes, la frecuencia de actualizaciones de seguridad, la disponibilidad de ciertos paquetes y cómo se manejan los servicios del sistema. Si armás una pipeline que asume apt, va a explotar en un servidor CentOS que usa yum. Ese tipo de inconsistencia mata horas.
Estructura jerárquica del sistema de archivos de Linux
Acá viene una de las primeras confusiones para quienes vienen de Windows: Linux no tiene C:\, D:\, etc. Todo es un árbol único que arranca en / (raíz), y cada directorio tiene un propósito definido por el estándar FHS (Filesystem Hierarchy Standard).
| Directorio | Propósito | Relevancia DevOps |
|---|---|---|
| /bin | Ejecutables del sistema base (ls, cp, bash) | Siempre disponible, incluso en modo de recuperación |
| /etc | Archivos de configuración del sistema | Acá vivís: nginx.conf, sshd_config, resolv.conf |
| /home | Directorios de usuarios | Scripts, claves SSH, configuraciones de usuario |
| /var | Datos variables: logs, bases de datos, caches | /var/log es lo primero que revisás cuando algo falla |
| /usr | Programas instalados y sus datos | /usr/bin tiene la mayoría de herramientas que usás |
| /tmp | Archivos temporales (se borran al reiniciar) | Nunca guardes nada importante acá |
| /opt | Software de terceros instalado manualmente | Agentes de monitoreo, runtime de lenguajes custom |
Esta estructura predecible es una ventaja enorme: sabés dónde buscar los logs (siempre /var/log), dónde están los configs (siempre /etc), dónde van los binarios instalados por el sistema de paquetes (siempre /usr/bin). En Windows, cada aplicación decide dónde instala sus cosas y es un caos.
Permisos, usuarios y control de acceso
Ponele que deployás una app y el servicio no puede leer su propio archivo de configuración. O peor: alguien corrió chmod 777 en un directorio con credenciales porque “así funcionaba”. Estos son los escenarios que se evitan entendiendo el modelo de permisos de Linux.
Cada archivo en Linux tiene tres atributos de permisos (lectura r, escritura w, ejecución x) para tres niveles: el dueño del archivo, el grupo al que pertenece, y el resto del mundo. La notación numérica convierte eso en dígitos: 7 = rwx (4+2+1), 6 = rw-, 5 = r-x, 4 = r–. Un chmod 755 significa que el dueño puede hacer todo, y los demás solo leer y ejecutar.
chmod 777 es un agujero de seguridad real. Le das permisos de escritura a cualquier usuario del sistema sobre ese archivo o directorio. En servidores con múltiples usuarios o procesos comprometidos, eso es suficiente para escalar privilegios o modificar configs críticos. Esto se conecta con lo que analizamos en plataformas en la nube modernas.
El principio de menor privilegio aplica acá directamente: cada proceso, usuario o servicio debe tener acceso solo a lo que necesita para funcionar. Un proceso de nginx no necesita acceso a /home/deploy. Un script de backup no necesita ejecutar comandos como root.
sudo es el mecanismo para ejecutar comandos con privilegios elevados de forma controlada y auditada. Mucho mejor que loguear directo como root, porque deja registro de quién hizo qué. Los grupos en Linux permiten gestionar permisos colectivos: en vez de asignar permisos usuario por usuario, asignás al grupo y agregás usuarios ahí.
Comandos esenciales: de navegación a procesos
No hace falta memorizar 200 comandos. Hace falta tener claro el vocabulario mínimo para no estar paralizado frente a una terminal.
Navegación y exploración
ls -la lista todo el contenido incluyendo ocultos con permisos. cd /ruta para moverte, pwd para saber dónde estás. find /var/log -name "*.log" -mtime -1 busca logs modificados en las últimas 24 horas (útil para troubleshooting). cp, mv, rm son los básicos de manipulación de archivos; con rm -rf tenés que tener cuidado porque no pregunta confirmación y no hay papelera.
Búsqueda dentro de archivos
grep -r "error" /var/log/nginx/ busca la palabra “error” en todos los logs de nginx. grep -i para case-insensitive, grep -v para excluir líneas que matcheen. awk es más potente para procesar columnas de texto: awk '{print $1}' access.log te da la primera columna del log de acceso (la IP). Si alguna vez tuviste que parsear un log de 2GB a mano, sabés que grep y awk te salvan la vida.
Gestión de procesos
ps aux lista todos los procesos con su PID, usuario y uso de recursos. top o htop (si está instalado) para verlo en tiempo real. kill -9 PID mata un proceso de forma inmediata (es el último recurso, primero probá con kill PID que manda SIGTERM). systemctl status nginx para ver el estado de un servicio gestionado por systemd, que es el estándar en Ubuntu y RHEL modernos. Cubrimos ese tema en detalle en configuración multi-servidor correcta.
Red
ss -tlnp muestra qué puertos están escuchando (reemplazó a netstat en la mayoría de distros modernas). curl -I https://ejemplo.com trae solo los headers HTTP, útil para verificar configuración sin descargar todo el contenido. ssh usuario@servidor -i ~/.ssh/clave.pem para conectarte con clave privada. Saber interpretar la salida de estos comandos te saca de apuros en media hora de troubleshooting.
Automatización con Shell Scripting
Un script de bash bien escrito es un colega que trabaja sin quejarse a las 3 de la mañana.
La base es simple: variables con $NOMBRE, condicionales con if [ condición ]; then ... fi, loops con for archivo in *.log; do ... done. Con eso cubrís el 80% de las necesidades de automatización básica.
Un ejemplo concreto que usás más de lo que pensás: script de backup que comprime un directorio, lo nombra con la fecha actual y lo sube a un storage. Son 10 líneas de bash que ahorran una tarea manual repetitiva. El repositorio del journey de 30 días en cloud y DevSecOps tiene ejemplos prácticos de este tipo organizados por día, si querés una progresión estructurada.
Eso sí: los scripts de bash no escalan bien para lógica compleja. Cuando un script supera las 100 líneas o necesita manejo de errores sofisticado, Python es mejor opción. Bash para automatización operativa simple; Python para lógica de negocio.
Gestión de paquetes: apt vs yum
En Ubuntu y Debian usás apt. En CentOS, RHEL y Fedora usás yum (o dnf en versiones modernas). La sintaxis es parecida pero no igual.
| Acción | apt (Ubuntu/Debian) | yum/dnf (CentOS/RHEL) |
|---|---|---|
| Instalar paquete | apt install nginx | yum install nginx |
| Actualizar todo | apt upgrade | yum update |
| Buscar paquete | apt search nombre | yum search nombre |
| Remover paquete | apt remove nombre | yum remove nombre |
| Actualizar lista | apt update | yum check-update |
Cuando manejás infraestructura heterogénea (servidores con diferentes distros), esta diferencia es el primer tropiezo. Los scripts de aprovisionamiento que asumen apt fallan silenciosamente en CentOS, y a veces el error no es obvio. Si usás un proveedor como donweb.com para tu infraestructura, la elección de distro en el VPS determina cuál gestor de paquetes vas a usar desde el día uno.
Errores comunes al aprender Linux para DevOps
Error 1: Aprender comandos sueltos sin entender el contexto. Memorizar que grep busca texto no te dice nada si no entendés que podés combinarlo con | (pipe) para encadenar comandos. Linux tiene una filosofía de herramientas pequeñas que se encadenan: ps aux | grep nginx | awk '{print $2}' te da el PID de nginx en una sola línea. Ese encadenamiento es el corazón del modelo. Tema relacionado: servicios cloud para infraestructura.
Error 2: Ignorar los logs. La respuesta a casi cualquier problema en Linux está en /var/log. El error típico es intentar debuguear un servicio que no levanta sin revisar journalctl -u nginx --since "10 min ago" o tail -f /var/log/nginx/error.log. Los logs te dicen exactamente qué falló y en qué línea de configuración.
Error 3: Usar root para todo. Loguear directo como root en producción es mala práctica porque cualquier comando que ejecutés tiene permisos máximos sin fricción. Si un script bugueado hace rm -rf / corriendo como root, se borra todo. Con un usuario normal y sudo solo cuando hace falta, tenés una capa de protección y un registro de auditoría. (Sí, esto pasa en producción más seguido de lo que te gustaría saber.)
Error 4: Confundir la distro con Linux. “¿Funciona en Linux?” no es suficiente pregunta. Una dependencia que en Ubuntu viene en un paquete específico puede llamarse diferente o no existir en Alpine. Cuando escribís documentación o scripts de setup, especificá la distro y versión: “Ubuntu 24.04 LTS” no “Linux”.
Preguntas Frecuentes
¿Cuáles son los conceptos básicos de Linux que debo saber como DevOps?
El mínimo útil cubre cinco áreas: estructura del sistema de archivos (/etc, /var, /bin, /home), permisos y usuarios (chmod, chown, sudo), gestión de procesos (ps, kill, systemctl), comandos de red (ss, curl, ssh) y shell scripting básico (variables, condicionales, loops en bash). Con eso podés operar servidores en producción, debuguear problemas y automatizar tareas repetitivas.
¿Por qué Linux es importante para DevOps y SRE?
Kubernetes, Docker, la mayoría de los servicios cloud y prácticamente todos los servidores de producción corren sobre Linux. Un SRE o DevOps Engineer que no sabe Linux está dependiendo de que las abstracciones nunca fallen, y siempre fallan. Cuando un pod no levanta, un servicio se cae o un deploy rompe producción, el troubleshooting vuelve a la terminal Linux sin excepciones.
¿Cómo funcionan los permisos y usuarios en Linux?
Cada archivo tiene permisos para tres niveles: dueño, grupo, y resto. Los permisos son lectura (r=4), escritura (w=2) y ejecución (x=1). chmod 755 archivo le da permisos completos al dueño y solo lectura/ejecución a los demás. sudo permite ejecutar comandos con privilegios elevados de forma controlada y auditada, sin necesidad de loguear como root.
¿Cuál es la diferencia entre apt y yum?
Son los gestores de paquetes de diferentes familias de distribuciones. apt es de Debian/Ubuntu; yum o dnf es de RedHat/CentOS/Fedora. La funcionalidad es equivalente, pero la sintaxis y los nombres de paquetes pueden diferir. En infraestructura heterogénea, esta diferencia rompe scripts de aprovisionamiento que asumen una sola distro.
¿Qué comandos básicos necesita un DevOps engineer?
Por categoría: navegación (ls, cd, pwd, find), manipulación de archivos (cp, mv, rm, cat, less), búsqueda (grep, awk, sed), procesos (ps, top, kill, systemctl), red (ss, curl, ssh, ping), usuarios (useradd, id, sudo, chmod, chown). La hoja de comandos bash de referencia tiene estos organizados con ejemplos si necesitás un recurso de consulta rápida.
Conclusión
Saltarse Linux para ir directo a Kubernetes o Docker es una deuda técnica que se paga con intereses altos: horas perdidas debugueando problemas que tienen solución obvia si sabés dónde mirar, dependencia de otros para resolver incidentes básicos, y scripts de automatización que fallan de formas misteriosas.
La buena noticia es que el núcleo de conocimiento necesario no es enorme. Sistema de archivos, permisos, comandos de diagnóstico, gestión de paquetes y scripting básico: con eso cubrís el 90% de los escenarios cotidianos. El resto se aprende en el camino, pero sobre una base que no te traiciona cuando más la necesitás.
