1 puntos por chcv0313 2025-12-26 | 9 comentarios | Compartir por WhatsApp

Hay un servidor que usan en común varias decenas de personas.

Cada quien está sirviendo su proyecto en un contenedor,

pero cuando ocurren problemas como un reinicio del servidor, al administrador le resulta complicado responder ante estos contenedores.

No está claro si habría que pedirles que entreguen de antemano el comando para ejecutar su contenedor Docker y luego correrlo uno por uno,
o si habría que hacerlo con Docker Compose y entrar carpeta por carpeta de cada proyecto para levantar el compose, etc.

Como administrador, agradecería consejos sobre cómo gestionar varios contenedores.

9 comentarios

 
chcv0313 2025-12-31

Gracias a todos los que respondieron. Creo que la meta de este año debería ser adoptar Kubernetes.

 
popopo 2025-12-28

La forma más sencilla es ejecutar el contenedor como daemon para que también se inicie cuando arranque el sistema operativo.

  • Antes de reiniciar, también se pueden apagar correctamente uno por uno.

Si es de la familia EL (Enterprise Linux, término general para la línea RHEL), se puede registrar el contenedor como un servicio de systemd. A eso le llaman Quadlet.

 
bungker 2025-12-27

A simple vista, parece que se podría resolver con depend on, restart always o unless stoped, pero da la impresión de que hay alguna situación complicada que no está incluida en la pregunta. Aun así, si hablamos de varias decenas de personas, al final parece que van a tener que pasarse a Kubernetes.

Tal como está la pregunta, probablemente también puedan encontrar la respuesta preguntándoselo a una IA.

 
tujuc 2025-12-27
  1. ¿Dónde tienen la infraestructura? ¿AWS? ¿Propio o con hosting de servidores? ¿Azure?
  2. ¿Lo administran ustedes solos?
  3. ¿En qué estado han estado trabajando hasta ahora y hasta dónde conocen?

Si comparten lo anterior, creo que será más fácil conversar del tema.

Respondiendo simplemente con base en lo que mencionaste...

No entiendo por qué sería necesario un comando para ejecutar contenedores. Pidan que les hagan un archivo de Compose, y con base en eso lo mejor es configurarlo para poder levantar todo con el mismo comando (el comando de Compose).

:) Como eres administrador, si pides que lo hagan así, seguro los demás te ayudarán, así que empújalo :)

Personalmente, no recomiendo mucho k8s porque me parece una solución con una carga grande para un entorno administrado por una sola persona.
Siempre pienso que lo mejor es mantener la infraestructura lo más simple posible.

 
chcv0313 2025-12-27

Son 4 servidores on-premise.
Lo hago yo solo.
Docker pasó seguridad y ya van 4 meses desde que se adoptó en la empresa, y de k8s solo conozco el concepto. La implementación de HARBOR para Docker pronto me tocará hacerla a mí, y una vez que Harbor quede implementado, está previsto bloquear Docker Hub. Probablemente solo yo tendré abierto Docker Hub y, cuando lleguen solicitudes, solo yo descargaré imágenes desde Docker Hub y las subiré al Harbor interno de la empresa.

No forcé todo con el comando de Compose ni fui proyecto por proyecto entrando a cada carpeta para ejecutar compose up manualmente porque me parecía poco realista; en su lugar pedí que me dieran los comandos de Docker con ruta absoluta, pero últimamente no puedo dejar de pensar que ha sido un enfoque equivocado.

 
byun1114 2025-12-27

¿No bastaría con darle una opción de reinicio a Docker?

 
click 2025-12-26

En ese caso, es mejor usar Kubernetes y asignar un context a cada usuario.
También se puede limitar los permisos para que cada usuario solo pueda usar ese context.

 
cafedead 2025-12-26

Se usa k8s.

 
selene 2025-12-29

Yo también pienso parecido a tujuc; creo que introducir k8s por cuenta propia sin alguien con experiencia y operarlo de forma estable sin incidentes implica bastante riesgo.

Pero como mencionas una situación en la que decenas de personas comparten 4 servidores, queda un poco ambiguo;
más que basarse en la cantidad de personas involucradas, si la cantidad de programas de servidor es demasiado grande y la complejidad es alta, sí valdría la pena considerar aprender k8s.

Si yo estuviera en la misma situación que el autor, probablemente iría mejorando el entorno por etapas, más o menos así.

  1. Tomar medidas para que no haya problema aunque los programas del servidor se apaguen en cualquier momento => incluir cosas como implementar graceful shutdown y refactorizar para que funcionen como stateless. (O pedírselo a los ingenieros)
  2. Contenerizar y estandarizar los programas del servidor => escribir un Dockerfile y un archivo de docker compose para cada servicio, y forzar que, al ejecutarlos con el mismo comando, siempre puedan levantarse sin falta.
  3. Gestionar el entorno para que, salvo el administrador, otros ingenieros no necesiten conectarse al servidor => se puede montar algo parecido a GitOps usando la plataforma de CI/CD que prefieras, como Jenkins/GitHub Actions/AWS CodePipeline. Con llegar a este punto, los ingenieros ya pueden controlar suficientemente los redespliegues y reinicios con algo tan simple como volver a ejecutar el pipeline.
  4. Después, como dijeron otros, seguir sofisticándolo (introducir K8s, ArgoCD, etc.)