¿systemd.service en lugar de Docker? Reexaminando la estrategia de despliegue de aplicaciones web en Linux

En los últimos años, la frase “despliegue = Docker + orquestación de contenedores (Kubernetes, ECS, etc.)” se ha vuelto casi un hecho. Por eso, subir una aplicación web a un servidor Linux como proceso + servicio systemd puede parecer anticuado.

Sin embargo, en la práctica:

  • Aplicación web única
  • Equipo pequeño / infraestructura sencilla
  • Entorno on‑premise o con regulaciones estrictas

a menudo resulta que desplegar con systemd es más simple, estable y amigable para la operación.

En este artículo veremos qué ventajas ofrece systemd frente a Docker y en qué situaciones el despliegue basado en systemd es más útil.

1. Repaso rápido de systemd y Docker

Commandbox 광고

Para resumir brevemente:

  • Docker
  • Empaqueta la aplicación en una imagen
  • La ejecuta en un contenedor

  • Ventaja: “entorno completo encapsulado → se ejecuta igual en cualquier lugar”

  • systemd

  • Sistema init por defecto en la mayoría de distribuciones Linux
  • Arranca servicios al iniciar el sistema, los reinicia si mueren y gestiona logs
  • Define y controla procesos mediante archivos de unidad *.service

Docker es una herramienta para encapsular el entorno de la aplicación, mientras que systemd es una herramienta para gestionar procesos en Linux.

A menudo se usan juntos: por ejemplo, ejecutar systemd dentro de un contenedor Docker o gestionar el demonio Docker con systemd. En este artículo nos enfocamos en el caso de desplegar una aplicación web sin Docker, solo con systemd.

2. Ventajas de desplegar con systemd.service en lugar de Docker

2‑1. Sencillez: se reduce una capa

Al usar Docker, el stack operativo incluye:

  • Demonio Docker
  • Pipeline de construcción de imágenes
  • Registro de imágenes (Registry)
  • Gestión de permisos y privilegios de ejecución de contenedores

Con systemd, la estructura es:

  • Instalar el runtime necesario (Python/Node/Java, etc.)
  • Desplegar el código de la aplicación
  • Registrar el servicio con systemd y ejecutarlo

Esta es una arquitectura relativamente simple.

En proyectos pequeños o servicios internos, el proceso de “construir imagen → push → pull → redeploy” puede ser más pesado que simplemente hacer git pull y systemctl restart.

2‑2. Integración natural con Linux

systemd se integra estrechamente con el sistema operativo, lo que facilita:

  • Logs: journalctl -u myapp.service
  • Arranque automático: systemctl enable myapp.service
  • Limitaciones de recursos (cgroups): MemoryMax, CPUQuota, etc.
  • Gestión de dependencias: After=network.target, After=postgresql.service, etc.

Con Docker, se deben separar logs, recursos y redes entre el contenedor y el host, lo que complica la depuración.

2‑3. Menor sobrecarga de recursos

Aunque Docker no añade mucha sobrecarga, suele implicar:

  • Múltiples capas de imágenes que consumen disco
  • Contenedores que permanecen activos sin necesidad
  • Gestión de logs y volúmenes por contenedor

Con systemd, solo se necesita el sistema operativo, el runtime y el código de la aplicación, lo que es ideal en entornos con recursos limitados.

2‑4. Red de red más intuitiva

Con Docker, se manejan:

  • IP y puertos internos del contenedor
  • Mapeo de puertos con el host
  • Redes de puente o superposición

Con systemd, la aplicación se enlaza directamente al IP/puerto del host, y las reglas de firewall se configuran a nivel de host. Esto simplifica la depuración de red.

2‑5. En entornos donde Docker no es viable

Es más frecuente de lo que parece:

  • Entornos financieros, públicos o médicos con regulaciones estrictas
  • Políticas que prohíben el uso de runtimes de contenedores
  • Redes aisladas donde no se puede acceder a registros externos

En estos casos, la única opción práctica es OS + systemd. Con un buen conocimiento de systemd, se pueden implementar:

  • Reinicio automático
  • Gestión de logs
  • Límites de recursos
  • Chequeo de salud (indirecto)

3. Ejemplo de systemd.service: despliegue de una aplicación web

Commandbox 광고

Supongamos que servimos una aplicación Django/Flask con gunicorn.

3‑1. Archivo de unidad de ejemplo

/etc/systemd/system/myapp.service:

[Unit]
Description=My Web Application (Gunicorn)
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/srv/myapp
EnvironmentFile=/etc/myapp.env
ExecStart=/usr/bin/gunicorn \
    --workers 4 \
    --bind 0.0.0.0:8000 \
    config.wsgi:application

# Reinicio automático si el proceso muere
Restart=on-failure
RestartSec=5

# Límites de recursos (opcional)
# MemoryMax=512M
# CPUQuota=50%

[Install]
WantedBy=multi-user.target

El archivo de variables de entorno, por ejemplo /etc/myapp.env:

DJANGO_SETTINGS_MODULE=config.settings.prod
SECRET_KEY=super-secret-key
DATABASE_URL=postgres://...

Los comandos de gestión son muy simples:

# Registrar el servicio y habilitarlo al arranque
sudo systemctl enable myapp.service

# Iniciar / detener / reiniciar
sudo systemctl start myapp.service
sudo systemctl restart myapp.service
sudo systemctl stop myapp.service

# Estado y logs
sudo systemctl status myapp.service
sudo journalctl -u myapp.service -f

Para un equipo familiarizado con Linux, esta configuración permite operar sin curva de aprendizaje adicional.

4. ¿Cuándo es mejor usar systemd que Docker?

En resumen, considere systemd cuando:

4‑1. Servicio único o pequeño, sin necesidad de orquestación compleja

  • 1‑2 aplicaciones web
  • Base de datos gestionada (RDS, etc.)
  • Pocos servidores (1‑5)

En estos casos, la sobrecarga de Docker y la orquestación pueden ser innecesarias.

4‑2. El equipo ya domina Linux y systemd

Si la infraestructura existente se basa en systemd y el personal está familiarizado con systemctl, journalctl, rsyslog, etc., añadir Docker puede ser un costo adicional sin beneficios claros.

4‑3. Entornos regulados o con restricciones de Docker

  • Finanzas, gobierno, defensa, salud
  • Redes aisladas o con acceso limitado a registros externos

Docker puede representar un riesgo de cumplimiento; systemd es una alternativa probada.

4‑4. Depuración y análisis de rendimiento en el host

Si necesita usar herramientas como strace, perf o inspeccionar /proc directamente, es más sencillo trabajar con procesos nativos que con contenedores.

5. Claro, Docker también tiene sus casos de uso

Aunque hemos destacado las ventajas de systemd, Docker sigue siendo la opción adecuada cuando:

  • Se necesita un entorno idéntico en local, staging y producción
  • Se integran CI/CD pipelines de forma natural
  • Se gestionan múltiples servicios (web, workers, cron, base de datos) en un solo host

En entornos con varios servidores o con diferencias de configuración significativas, Docker puede simplificar la consistencia.

La decisión final depende de:

¿Qué herramienta es más simple, estable y fácil de operar en nuestro contexto?

image

6. Conclusión: la herramienta depende del contexto

Desplegar una aplicación web en Linux no es una cuestión de “siempre usar Docker” o “Docker es malo y systemd es mejor”.

  • Servicio único, infra sencilla, regulaciones estrictas → systemd.service puede ser la opción más realista.
  • Múltiples servicios, entornos variados, despliegues frecuentes → Docker aporta mayor valor.

Si ya usas Linux, vale la pena preguntarse:

  • ¿Realmente necesito Docker para esta aplicación?
  • ¿Podría simplificar el despliegue con systemd?

Las herramientas son medios para un fin; la simplicidad y la facilidad de operación suelen traducirse en mayor productividad a largo plazo.