Que es un docker

Tu equipo acaba de cerrar una feature. En local funciona. En staging falla por una versión distinta de una librería. En producción, además, el proceso arranca con otra configuración y rompe un endpoint crítico. Si trabajas en una startup, esta escena no es rara. Es el coste de mover software entre máquinas que no son idénticas.

‍

Por eso tanta gente busca entender qué es un Docker y por qué se ha vuelto una pieza tan común en equipos de producto, backend, plataforma y DevOps. La respuesta corta es simple: Docker empaqueta tu aplicación con lo que necesita para ejecutarse igual en distintos entornos. La respuesta útil, que es la que de verdad sirve en una startup, incluye también cómo usarlo bien y cómo detectar si un candidato realmente lo domina más allá del tutorial básico.

‍

Introducción a los retos de despliegue en startups

‍

En una startup, los fallos de despliegue casi nunca vienen de una sola gran decisión mala. Suelen venir de pequeñas diferencias: una variable de entorno que falta, una dependencia instalada a otra versión, un sistema operativo con matices distintos o un servicio auxiliar que en local estaba levantado y en producción no.

‍

Ahí entra Docker. Docker es una plataforma de código abierto lanzada en 2013 por Docker, Inc. que automatiza el despliegue de aplicaciones en contenedores de software, ofreciendo virtualización a nivel de núcleo sin hipervisores, tal como explica IBM sobre Docker. La idea práctica es que tu app viaje con sus dependencias en un formato consistente.

‍

Muchos developers novatos confunden esto con “una forma de subir cosas al servidor”. Se queda corto. Docker resuelve un problema de consistencia operativa. Si el mismo artefacto se ejecuta en tu portátil, en CI y en producción, reduces una clase entera de errores absurdos que consumen horas.

‍

Regla práctica: si una startup despliega rápido, necesita reducir diferencias entre entornos antes de discutir optimizaciones finas.

‍

Esto afecta también a la organización del equipo. Cuando producto acelera y el backend cambia varias veces por semana, necesitas que desarrollo y sistemas hablen el mismo idioma. Si estás definiendo responsabilidades entre perfiles de infraestructura, conviene entender cómo encajan funciones como las de un administrador de redes y de sistemas informáticos con prácticas modernas de despliegue basadas en contenedores.

‍

Conceptos clave de Docker

‍

La mejor forma de entender Docker es pensar en un contenedor marítimo. Da igual si dentro van muebles, ropa o electrónica. El puerto, el camión y la grúa no necesitan rediseñarse para cada carga. Con Docker pasa algo parecido: metes tu aplicación y sus dependencias en una imagen, y el sistema sabe cómo ejecutarla de forma predecible.

‍

Docker se ha consolidado como estándar en contenedorización desde 2013, usando cgroups y namespaces para ejecutar múltiples contenedores en un solo Linux sin hipervisores, como resume Grupo Castilla en su explicación sobre Docker. Esa frase técnica importa porque responde a una duda habitual: Docker no aísla aplicaciones inventando una máquina completa para cada una. Aprovecha funciones del kernel de Linux para separarlas.

‍

‍

Qué aíslan cgroups y namespaces

‍

No hace falta memorizar internals para usar Docker bien, pero sí entender lo básico.

• Namespaces separan la visión que tiene un proceso del sistema. Un contenedor puede “creer” que tiene su propio espacio de procesos, red o sistema de archivos.
• Cgroups limitan y controlan recursos. Sirven para que un contenedor no se coma CPU o memoria sin control.
• El kernel se comparte. Esto hace a Docker ligero, pero también marca sus límites de aislamiento frente a otras tecnologías.

‍

Si vienes de backend, piensa en ello así: ejecutas tu app como un proceso aislado, no como un servidor entero dentro de otro servidor.

‍

Por qué importa tanto en startups españolas

‍

En el ecosistema español, Docker aparece una y otra vez en roles de DevOps y Cloud porque ayuda a estandarizar cómo se construye y ejecuta software. También encaja muy bien con arquitecturas de microservicios, donde varios servicios pequeños deben convivir con dependencias distintas sin pisarse entre sí.

‍

Un ejemplo realista. Tienes una API en Node.js, un worker en Python y una base de datos PostgreSQL. Sin contenedores, cada nuevo developer invierte tiempo en alinear versiones, instalar paquetes del sistema y corregir diferencias locales. Con Docker, el equipo fija esa receta una vez y la reutiliza.

‍

Si alguien en una entrevista define Docker solo como “una VM más ligera”, sospecha. Entiende la superficie, no el modelo.

‍

Componentes esenciales del ecosistema Docker

‍

Docker no es un único comando ni una caja negra. Si quieres usarlo bien, hay cinco piezas que debes distinguir sin confundir términos. Esa confusión es muy común en entrevistas.

‍

Imágenes y contenedores

‍

Una imagen es la plantilla. Un contenedor es la instancia en ejecución de esa plantilla.

‍

Piensa en una imagen como una foto inmutable de tu aplicación preparada para arrancar. Si creas una imagen de una app Node.js con su código, dependencias y comando de arranque, puedes lanzar varios contenedores a partir de ella. Todos nacen desde la misma base.

‍

Errores típicos aquí:

• Confundir imagen con contenedor. La imagen no “está corriendo”.
• Modificar un contenedor a mano y creer que esos cambios forman parte de la imagen.
• No versionar imágenes y depender del ambiguo latest.

‍

Dockerfile y construcción reproducible

‍

Aquí está la pieza que más valor aporta en equipos pequeños. Un Dockerfile es un archivo de texto que describe la estructura de una imagen Docker mediante comandos similares a un script, definiendo dependencias y configuración antes del empaquetado, según la guía de IONOS sobre Docker.

‍

Eso significa que documentas en código cómo se construye el entorno, en vez de depender de pasos manuales o memoria tribal.

‍

Un ejemplo sencillo:

FROM node:20WORKDIR /appCOPY package*.json ./RUN npm installCOPY . .EXPOSE 3000CMD ["npm", "start"]

‍

Qué hace cada línea:

• FROM node:20 elige una imagen base.
• WORKDIR /app define el directorio de trabajo.
• COPY package.json ./* copia primero los manifiestos de dependencias.
• RUN npm install instala paquetes.
• COPY . . añade el resto del código.
• EXPOSE 3000 documenta el puerto esperado.
• CMD ["npm", "start"] fija el comando por defecto.

‍

Criterio útil: si un candidato no sabe explicar por qué se copian antes los archivos de dependencias que el resto del código, probablemente ha usado Docker, pero no lo ha optimizado ni mantenido.

‍

Registries, CLI y daemon

‍

Las imágenes tienen que vivir en algún sitio. Ahí entran los registries, como Docker Hub o un registry privado en AWS, Google Cloud o Azure. Su función es almacenar y distribuir imágenes entre developers, pipelines y servidores.

‍

Luego están dos piezas operativas:

• Cliente Docker o CLI. Es la herramienta con la que lanzas comandos como docker build o docker run.
• Daemon Docker. Es el servicio que realmente crea contenedores, gestiona redes, imágenes y volúmenes.

‍

No hace falta hablar del daemon todos los días, pero sí entender que la CLI no “hace magia” sola.

‍

Docker Compose y proyectos con varios servicios

‍

Cuando una app depende de varios servicios, lanzar contenedores uno a uno deja de ser cómodo. Para eso se usa Docker Compose, que permite describir un conjunto de servicios en un único archivo.

‍

Un caso típico de startup:

• API en Node.js
• Base de datos PostgreSQL
• Redis para colas o caché

‍

Con Compose, el equipo arranca todo el stack local con un solo comando. Eso acelera onboarding, testing manual y depuración de integraciones.

‍

Comparación entre Docker y máquinas virtuales

‍

La comparación útil no es “cuál es mejor”, sino “qué problema resuelve cada una”. Docker y las máquinas virtuales aíslan cargas, pero no lo hacen de la misma manera.

‍

Docker opera con el kernel de Linux evitando la sobrecarga de hipervisores, lo que reduce el consumo de recursos y acelera el arranque frente a máquinas virtuales completas, como recoge la entrada de Wikipedia sobre Docker).

‍

Cuándo gana Docker

‍

Docker gana cuando necesitas rapidez, densidad y portabilidad operativa. Es una gran opción para APIs, workers, procesos batch, pipelines de CI y entornos de desarrollo consistentes.

‍

Si montas una app para una startup SaaS, rara vez quieres iniciar un sistema operativo completo para cada servicio. Quieres lanzar procesos aislados con el menor peso posible. Ahí Docker encaja muy bien.

‍

Además, si trabajas en backend, te conviene entender esta diferencia igual que entiendes qué es backend. No es solo código de negocio. También importa cómo empaquetas y ejecutas ese código.

‍

Cuándo una VM sigue teniendo sentido

‍

Una máquina virtual tiene más sentido cuando necesitas aislar sistemas operativos completos o cuando la frontera de aislamiento debe ser más fuerte. También es útil si tu carga depende de un entorno distinto del host o de requisitos muy específicos de sistema.

‍

Resumen rápido:

• Docker para empaquetar y mover aplicaciones con eficiencia.
• VM para virtualizar máquinas completas con su propio sistema operativo.

‍

No mezcles ligereza con superioridad universal. En ingeniería, el contexto manda.

‍

‍

Ejemplos prácticos de Docker y comandos básicos

‍

La teoría sirve hasta que abres la terminal. A partir de ahí, Docker se vuelve claro muy rápido.

‍

Primer ejemplo con Nginx

‍

Empieza con algo simple. Descarga y ejecuta Nginx en un contenedor.

‍

docker pull nginxdocker run -d -p 8080:80 --name mi-nginx nginxdocker ps

‍

Qué hace cada comando:

• docker pull nginx descarga la imagen.
• docker run -d -p 8080:80 --name mi-nginx nginx crea y arranca un contenedor en segundo plano, mapeando tu puerto 8080 al 80 del contenedor.
• docker ps muestra contenedores en ejecución.

‍

Si abres http://localhost:8080, deberías ver la página por defecto de Nginx.

‍

Cuando algo falla, el siguiente comando suele darte la pista:

‍

docker logs mi-nginx

‍

Ese comando muestra la salida del contenedor. En debugging real vale más que muchas suposiciones.

‍

No empieces aprendiendo veinte comandos. Empieza dominando cinco: pull, build, run, ps y logs.

‍

Segundo ejemplo con una app Node.js

‍

Supón una app con este app.js:

‍

const express = require('express');const app = express();app.get('/', (req, res) => res.send('Hola desde Docker'));app.listen(3000);

‍

Y este package.json mínimo:

{"name": "demo-docker","version": "1.0.0","dependencies": {"express": "^4.18.0"},"scripts": {"start": "node app.js"}}

‍

Crea el Dockerfile:

‍

FROM node:20WORKDIR /appCOPY package*.json ./RUN npm installCOPY . .EXPOSE 3000CMD ["npm", "start"]

Construcción y ejecución:

‍

docker build -t demo-node .docker run -d -p 3000:3000 --name mi-app demo-nodedocker psdocker logs mi-app

‍

Si no responde, revisa tres cosas antes de culpar a Docker:

• Puerto correcto entre host y contenedor.
• Comando de arranque definido en CMD.
• Dependencias instaladas durante docker build.

‍

Orquestar varios servicios con Compose

‍

Cuando la app necesita más de un contenedor, Compose simplifica el trabajo. Un docker-compose.yml básico puede verse así:

services:web:build: .ports:- "3000:3000"depends_on:- dbdb:image: postgresenvironment:POSTGRES_PASSWORD: ejemplo

‍

Lectura rápida:

• web construye la aplicación local.
• ports expone el servicio.
• depends_on indica dependencia de arranque.
• db usa una imagen oficial de PostgreSQL.

‍

Para levantarlo:

‍

docker-compose up

‍

Ese comando es perfecto para onboarding interno. Un developer nuevo clona el repositorio, ejecuta Compose y tiene un entorno utilizable sin instalar media internet a mano.

Si prefieres una explicación visual antes de probar comandos, este vídeo ayuda a fijar el modelo mental:

‍

Qué pedir a un junior y qué esperar de un senior

‍

No todos los niveles de experiencia deberían responder igual.

• Junior. Debería saber crear una imagen, correr un contenedor y leer logs.
• Mid-level. Debería manejar Compose, variables de entorno, volúmenes y depuración básica.
• Senior o DevOps. Debería razonar sobre construcción reproducible, seguridad básica de imágenes, separación entre build y runtime, y límites de usar Docker en producción.

‍

Importancia de Docker en el proceso de hiring

‍

Aquí está el punto que muchas startups descubren tarde. Saber qué es un Docker no basta. Lo difícil es distinguir entre quien ha seguido un tutorial y quien puede operar servicios reales sin introducir fragilidad.

‍

En España, más del 60 % de startups y scaleups españolas enfrentan retrasos en contratar perfiles DevOps/Cloud debido a la curva de aprendizaje de herramientas de contenedorización en producción, según Red Hat y su explicación sobre Docker y contenedores. Esa cifra encaja con lo que muchos CTOs ya notan en procesos de selección: abundan perfiles que conocen comandos, escasean perfiles que entienden operación.

‍

Cómo evaluarlo en entrevistas

‍

No hagas preguntas de memoria. Plantea situaciones.

• Escenario de debugging. “El contenedor arranca y se cae al instante. ¿Qué mirarías primero?”
• Dockerfile real. Pide revisar uno con errores y mejorar su orden.
• Compose sencillo. Solicita levantar API y base de datos con variables mínimas.
• Trade-off técnico. Pregunta cuándo no usaría Docker o qué riesgos ve en producción.

‍

Para entender mejor el tipo de perfil que suele trabajar con estas herramientas, ayuda revisar qué hace un ingeniero DevOps. No porque todo especialista en Docker sea DevOps, sino porque ahí suele estar el estándar operativo más alto.

‍

Contrata por capacidad de diagnóstico, no por recitar comandos.

‍

Conclusión y próximos pasos

‍

Docker merece la pena cuando necesitas consistencia, despliegues reproducibles y menos fricción entre desarrollo y producción. Instala Docker, crea una imagen pequeña, levanta una app con Compose y luego revisa cómo tu equipo evalúa ese conocimiento en entrevistas. Ahí es donde teoría y práctica se separan de verdad.

‍

Si tu startup necesita contratar perfiles que de verdad sepan moverse entre desarrollo, infraestructura y operación, Kulturo ayuda a definir el rol, evaluar competencia técnica y acelerar procesos de hiring para equipos de tecnología e IA en España.