Cómo planificar el crecimiento de una infraestructura Docker

Introducción

Planificar el crecimiento de una infraestructura Docker significa conseguir que la plataforma pueda incorporar más servicios, más datos y más carga sin obligar a reconstruirla cada vez que cambia de escala. No consiste en instalar desde el primer día un clúster complejo ni en reservar enormes cantidades de CPU y memoria. Consiste en conocer los límites actuales, medir cómo evolucionan y preparar caminos de ampliación antes de que el crecimiento se convierta en una emergencia.

Una plataforma Docker pequeña puede comenzar con un único servidor y unos pocos proyectos. Durante meses, esa arquitectura puede funcionar perfectamente. El problema aparece cuando aumentan las aplicaciones, las bases de datos, los volúmenes, los procesos programados, las imágenes almacenadas, los logs y el tráfico. En ese momento, el servidor puede seguir pareciendo estable mientras se reduce silenciosamente el margen de memoria, crece el uso de disco, aparecen picos de CPU o las ventanas de copia y mantenimiento se hacen demasiado largas.

El crecimiento tampoco es únicamente un problema de hardware. Una infraestructura puede tener recursos suficientes y, aun así, volverse difícil de mantener porque cada servicio comparte demasiadas dependencias, todos los proyectos utilizan la misma red, las bases de datos están mezcladas, no existe un inventario fiable o mover una aplicación a otro host exige modificar muchas piezas.

Por eso, una estrategia de crecimiento Docker debe combinar capacidad, arquitectura y operación. Hay que saber qué medir, qué margen mantener, qué servicios pueden seguir compartiendo host, cuáles conviene separar, cuándo ampliar verticalmente, cuándo añadir otra máquina, cómo preparar el almacenamiento y cómo evitar que la solución de crecimiento introduzca más complejidad que el problema original.

Este artículo se centra en esa evolución. La estructura general de la plataforma se desarrolla en cómo diseñar una plataforma Docker para una pequeña empresa; la separación entre proyectos se trata en cómo estructurar un entorno Docker para varios servicios independientes. Aquí la pregunta es distinta: ¿cómo hacer que esa infraestructura pueda crecer de forma gradual, medible y reversible?

Índice

• Qué significa realmente escalar una infraestructura Docker
• Tipos de crecimiento que debe soportar la plataforma
• Medir antes de ampliar
• Cuánto margen de capacidad conviene mantener
• Identificar el primer cuello de botella
• Planificar crecimiento de CPU
• Planificar crecimiento de memoria
• Planificar crecimiento de almacenamiento
• No confundir capacidad de disco con rendimiento
• Planificar red y tráfico
• Controlar logs, cachés e imágenes
• Cuándo escalar verticalmente
• Cuándo separar cargas en otro host
• Cómo introducir un segundo host sin rehacer la plataforma
• Separar crecimiento de aplicaciones y crecimiento de datos
• Cuándo sacar una base de datos del host Docker
• Revisar servicios compartidos al crecer
• Evitar que las dependencias bloqueen la evolución
• Mantener proyectos migrables
• Controlar crecimiento de versiones e imágenes
• Hacer que las copias sigan siendo viables
• Monitorizar tendencia y no solo estado instantáneo
• Automatizar sin perder control
• Cuándo el crecimiento exige pensar en disponibilidad
• Cuándo Docker Compose puede dejar de ser suficiente
• Plan de crecimiento por fases
• Ejemplo de evolución de una plataforma Docker
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa realmente escalar una infraestructura Docker

Escalar no significa únicamente ejecutar más contenedores. Una infraestructura crece cuando aumenta cualquiera de los recursos o responsabilidades que debe sostener.

Puede crecer porque:

• se incorporan nuevos proyectos;
• una aplicación recibe más tráfico;
• una base de datos almacena más información;
• los usuarios suben más archivos;
• aumentan tareas programadas y procesos en segundo plano;
• se conservan más logs;
• las copias tardan más;
• las imágenes ocupan más espacio;
• un servicio pasa de auxiliar a crítico;
• se necesita separar producción y pruebas;
• el mantenimiento ya no cabe en una ventana razonable.

La estrategia debe responder a la dimensión concreta que está creciendo. Comprar CPU no resuelve un disco saturado. Añadir RAM no arregla una base de datos mal diseñada. Crear un segundo host no soluciona por sí mismo una arquitectura donde todos los proyectos dependen del mismo almacenamiento.

Escalabilidad técnica y escalabilidad operativa

La infraestructura debe poder crecer técnicamente, pero también debe poder seguir siendo administrada. Si el número de proyectos aumenta de cinco a treinta y la única forma de saber qué existe es ejecutar comandos manuales y recordar rutas, la plataforma ha superado su capacidad operativa aunque el servidor todavía tenga recursos.

La planificación correcta busca que ampliar sea una intervención prevista, no una reacción urgente.

Tipos de crecimiento que debe soportar la plataforma

Crecimiento de servicios

Aparecen nuevas aplicaciones. Cada una consume recursos y añade redes, volúmenes, imágenes, variables, copias y procedimientos.

Crecimiento de carga

Un mismo servicio recibe más peticiones, ejecuta más tareas o procesa más datos.

Crecimiento de datos

Las bases de datos, archivos persistentes y copias aumentan de tamaño aunque el número de contenedores permanezca estable.

Crecimiento de criticidad

Una herramienta interna puede convertirse en un servicio esencial. Esto cambia requisitos de monitorización, copia, recuperación y mantenimiento.

Crecimiento de complejidad

Aumentan dependencias, integraciones y servicios compartidos. Este crecimiento puede ser más peligroso que el de hardware porque no siempre se detecta con métricas.

Crecimiento del equipo técnico

Más administradores o colaboradores necesitan convenciones, documentación y fuentes de verdad claras.

Crecimiento del ciclo de mantenimiento

Actualizar diez proyectos no requiere el mismo trabajo que actualizar dos. El tiempo humano también es una capacidad limitada.

Medir antes de ampliar

Una plataforma no debe ampliarse basándose únicamente en sensaciones. Conviene medir tanto el host como los proyectos principales.

Métricas del host

• uso medio y picos de CPU;
• memoria utilizada y disponible;
• swap cuando exista;
• espacio libre;
• crecimiento del almacenamiento;
• latencia y uso de disco;
• tráfico de red;
• carga sostenida;
• temperatura y salud del hardware cuando corresponda.

Métricas de Docker

• consumo por contenedor;
• reinicios;
• cantidad de imágenes;
• espacio utilizado por capas;
• volúmenes;
• tamaño de logs;
• contenedores detenidos o huérfanos.

Métricas funcionales

• peticiones por minuto;
• usuarios activos;
• tiempos de respuesta;
• tareas pendientes;
• duración de procesos;
• tamaño de bases de datos;
• crecimiento de uploads;
• duración de backups;
• tiempo de restauración.

Lo importante no es obtener cientos de métricas, sino detectar tendencias. Saber que el disco está al 62 % hoy es menos útil que saber que aumenta un 4 % cada mes.

Cuánto margen de capacidad conviene mantener

No existe un porcentaje universal que sirva para todas las plataformas, pero trabajar permanentemente cerca del límite elimina capacidad de reacción.

El margen debe cubrir:

• picos normales de carga;
• crecimiento próximo;
• procesos de mantenimiento;
• copias;
• reconstrucción de imágenes;
• actualizaciones que temporalmente consumen más recursos;
• recuperación después de un incidente.

La media puede engañar

Un servidor con una CPU media del 30 % puede sufrir picos diarios del 100 %. Una memoria media aparentemente cómoda puede quedarse sin margen durante importaciones o tareas programadas.

Capacidad libre no es capacidad desperdiciada

Parte del margen tiene una función: absorber variaciones y permitir cambios. El objetivo no es maximizar la utilización de cada recurso, sino mantener una plataforma estable.

Identificar el primer cuello de botella

La infraestructura suele tener un primer límite dominante. Detectarlo evita ampliar componentes que todavía no lo necesitan.

Los cuellos más habituales son:

• memoria insuficiente;
• almacenamiento lleno;
• disco lento;
• base de datos saturada;
• CPU sostenida al límite;
• red insuficiente;
• demasiadas escrituras de logs;
• procesos programados que coinciden;
• copias que consumen demasiados recursos;
• capacidad humana de administración.

No ampliar antes de diagnosticar

Si una consulta ineficiente consume CPU, duplicar el procesador puede ocultar temporalmente el problema sin resolverlo. Si un log crece sin control, añadir disco solo aplaza el incidente.

La primera ampliación debe atacar la limitación real.

Planificar crecimiento de CPU

Docker permite que muchos servicios compartan procesador, pero la competencia aumenta a medida que aparecen nuevas cargas.

Observar picos por proyecto

Un contenedor puede consumir mucha CPU durante segundos sin ser un problema. Lo preocupante es la carga sostenida o la coincidencia de varios procesos intensivos.

Evitar tareas pesadas simultáneas

Backups, indexaciones, importaciones, generación de informes o procesamiento multimedia pueden programarse en horarios distintos.

Aplicar límites cuando sea útil

Los límites de CPU pueden impedir que una aplicación defectuosa monopolice el host, aunque deben probarse para no degradar artificialmente un servicio importante.

Escalar verticalmente primero cuando sea sencillo

En una plataforma pequeña, aumentar vCPU o sustituir el procesador puede ser más simple que distribuir la carga. La arquitectura distribuida solo compensa cuando existe una razón clara.

Planificar crecimiento de memoria

La memoria suele convertirse en uno de los primeros límites en hosts con varios servicios.

Bases de datos, runtimes, cachés y aplicaciones Java o similares pueden mantener memoria incluso cuando la carga instantánea es baja.

Medir por proyecto

No basta con observar el total. Conviene identificar qué servicios consumen memoria y si ese consumo crece con usuarios, datos o tiempo de ejecución.

Dejar margen para el host

Docker no es el único consumidor. El kernel, el sistema de archivos, servicios del sistema y herramientas de copia o monitorización también necesitan memoria.

Evitar depender de swap como estrategia

La swap puede evitar una terminación brusca en determinadas situaciones, pero una plataforma que funciona habitualmente gracias a intercambio intensivo ya está bajo presión.

Separar servicios muy intensivos

Si una aplicación necesita cada vez más memoria y el resto permanece estable, moverla a otro host puede ser más limpio que sobredimensionar todo el servidor.

Planificar crecimiento de almacenamiento

Docker utiliza almacenamiento para mucho más que los datos empresariales.

El disco puede contener:

• imágenes;
• capas;
• contenedores;
• volúmenes;
• bases de datos;
• uploads;
• logs;
• cachés;
• artefactos de construcción;
• copias locales;
• exportaciones temporales.

Separar categorías

El crecimiento de imágenes no debe confundirse con el de datos persistentes. Una imagen puede descargarse de nuevo; una base de datos no.

Medir velocidad de crecimiento

Registrar tamaños mensualmente permite estimar cuándo será necesario ampliar o migrar.

Prever expansión

En servidores físicos conviene conocer opciones de discos, bahías, interfaces y capacidad. En entornos virtuales conviene saber si el volumen puede crecer y qué procedimiento requiere.

La gestión específica de volúmenes Docker tendrá su propio tratamiento dentro del clúster; para el crecimiento, lo esencial es que el almacenamiento persistente tenga una estrategia de expansión independiente del ciclo de vida de los contenedores.

No confundir capacidad de disco con rendimiento

Tener terabytes libres no garantiza que el almacenamiento pueda atender la carga.

Una base de datos puede sufrir por latencia o IOPS aunque el disco esté casi vacío. Del mismo modo, varias aplicaciones escribiendo logs y bases simultáneamente pueden competir por el mismo dispositivo.

Señales de presión de almacenamiento

• tiempos de respuesta que empeoran durante escrituras;
• backups que ralentizan aplicaciones;
• colas de procesos;
• latencias elevadas;
• contenedores que parecen consumir poca CPU pero responden lentamente.

Separar almacenamiento por carga

Una base de datos importante puede justificar almacenamiento distinto al usado para imágenes, logs o archivos grandes.

Optimizar antes de migrar

Índices, configuración de la aplicación o rotación de logs pueden reducir presión sin cambiar hardware.

Planificar red y tráfico

La red puede convertirse en un límite cuando crecen servicios web, copias remotas, almacenamiento externo o comunicación entre hosts.

Distinguir tráfico interno y externo

• tráfico de usuarios;
• comunicación entre contenedores;
• replicación o almacenamiento;
• copias;
• descarga de imágenes;
• monitorización.

Evitar que las copias compitan con producción

Si una copia consume todo el ancho de banda disponible, la ventana o el mecanismo deben revisarse.

Segundo host implica nueva dependencia de red

Cuando una base de datos o almacenamiento se mueve a otra máquina, la latencia y la disponibilidad de red pasan a formar parte del rendimiento de la aplicación.

Controlar logs, cachés e imágenes

Una plataforma puede crecer aparentemente por “datos” cuando en realidad el espacio lo consumen recursos regenerables.

Logs

Necesitan rotación y retención. Un contenedor que escribe sin límite puede llenar el host.

Cachés

Deben tener políticas de tamaño y limpieza.

Imágenes antiguas

Conservar algunas versiones puede ayudar a revertir, pero acumular todas indefinidamente consume almacenamiento sin aportar valor.

Artefactos de construcción

Las cachés de build y capas intermedias pueden crecer de forma significativa.

Limpieza controlada

No debe ejecutarse de forma destructiva sin inventario. Un volumen aparentemente huérfano puede contener datos importantes.

Cuándo escalar verticalmente

Escalar verticalmente significa aumentar recursos del mismo host: CPU, memoria, almacenamiento o capacidad de red.

Para una plataforma Docker pequeña suele ser el primer camino porque:

• mantiene una arquitectura sencilla;
• evita distribuir datos y redes;
• reduce número de sistemas que administrar;
• conserva procedimientos existentes;
• puede resolverse rápidamente en VPS o virtualización.

Cuándo tiene sentido

• el host todavía admite ampliaciones;
• la mayoría de servicios crecen de forma parecida;
• la criticidad no exige separación física;
• la administración de un solo host sigue siendo razonable;
• el coste de ampliar es menor que el de distribuir.

Cuándo deja de ser suficiente

Si una sola carga domina recursos, el host alcanza límites físicos o la concentración de servicios genera demasiado riesgo, seguir ampliando verticalmente puede dejar de ser la mejor opción.

Cuándo separar cargas en otro host

Añadir un segundo host no debe ser una respuesta automática. Introduce red, copias, monitorización y administración adicionales.

Puede tener sentido cuando:

• una aplicación consume una parte dominante de los recursos;
• producción y pruebas compiten;
• una base de datos necesita almacenamiento específico;
• un servicio tiene criticidad distinta;
• una carga pública requiere una frontera adicional;
• el mantenimiento de una aplicación no debe afectar a las demás;
• el host ha alcanzado un límite físico;
• la recuperación mejora al separar funciones.

Separar por motivo, no por simetría

No es necesario distribuir cada proyecto en una máquina distinta. La separación debe resolver un problema concreto de capacidad, seguridad, criticidad o mantenimiento.

Cómo introducir un segundo host sin rehacer la plataforma

Una infraestructura bien organizada permite mover proyectos progresivamente.

Elegir un candidato independiente

El primer servicio a migrar debería tener dependencias conocidas y datos identificados.

Reutilizar la definición

El proyecto debe poder desplegarse desde su Compose, variables y configuración sin depender de cambios manuales ocultos del host original.

Resolver conectividad

Si utiliza proxy, bases de datos o servicios comunes, hay que decidir cómo se comunicará entre hosts. Una red Docker local ya no será suficiente para servicios situados en máquinas diferentes.

Mover datos de forma controlada

La aplicación puede recrearse; los datos necesitan procedimiento de copia, sincronización y validación.

Actualizar DNS o entrada

El proxy o mecanismo de acceso debe apuntar al nuevo destino.

Probar antes de retirar el origen

Conviene mantener una ventana de reversión hasta validar funcionalidad, logs y rendimiento.

Separar crecimiento de aplicaciones y crecimiento de datos

Las aplicaciones suelen ser relativamente fáciles de recrear. Los datos crecen de forma acumulativa y condicionan copias, migraciones y tiempos de recuperación.

Aplicación reemplazable

Debe poder desplegarse desde imágenes y configuración.

Estado persistente

Necesita capacidad, copia y restauración.

No trasladar ambos problemas juntos

Cuando una aplicación crece, puede moverse a otro host manteniendo datos externos. O puede mantenerse el contenedor y trasladar almacenamiento si ese es el cuello real.

Separar ambos ciclos ofrece más opciones de evolución.

Cuándo sacar una base de datos del host Docker

Una base de datos puede convivir perfectamente con la aplicación durante mucho tiempo. Separarla solo aporta valor cuando existen necesidades claras.

Señales que pueden justificarlo:

• consumo elevado de memoria;
• crecimiento rápido del almacenamiento;
• necesidad de discos más rápidos;
• copias que afectan al resto del host;
• criticidad superior a la aplicación;
• varias aplicaciones dependen del mismo motor;
• necesidad de mantenimiento independiente;
• migraciones frecuentes de la capa de aplicación.

Coste de la separación

Aparece una dependencia de red y un sistema adicional que monitorizar. La separación debe compensar ese coste.

No confundir servicio separado con servicio gestionado

La base puede estar en otro host propio o en un servicio externo. Son decisiones distintas con implicaciones de coste, control y mantenimiento.

Revisar servicios compartidos al crecer

El proxy, la monitorización, el almacenamiento o un motor de base de datos común pueden empezar siendo adecuados y convertirse después en puntos críticos.

Preguntas de revisión

• ¿cuántos proyectos dependen del componente?
• ¿qué ocurre si falla?
• ¿puede actualizarse sin interrumpir demasiado?
• ¿tiene capacidad suficiente?
• ¿su copia es independiente?
• ¿puede recuperarse con rapidez?

El crecimiento aumenta el impacto común

Un proxy que inicialmente publica dos aplicaciones puede acabar publicando veinte. Su importancia cambia aunque el software sea el mismo.

Evitar que las dependencias bloqueen la evolución

Una plataforma crece mejor cuando los proyectos pueden moverse sin arrastrar una cadena de recursos invisibles.

Dependencias que conviene hacer explícitas

• redes compartidas;
• proxy;
• DNS;
• base de datos;
• SMTP;
• almacenamiento;
• APIs;
• secretos;
• servicios de identidad;
• tareas externas.

Evitar rutas locales ocultas

Un proyecto que depende de una carpeta concreta del host sin documentar será más difícil de migrar.

Evitar IP fijas cuando no sean necesarias

Las referencias rígidas a la topología actual dificultan cambiar de máquina o red.

La separación lógica de servicios se desarrolla en cómo estructurar un entorno Docker para varios servicios independientes.

Mantener proyectos migrables

Una de las mejores preparaciones para crecer es que cada proyecto pueda reconstruirse fuera del host actual.

Para ello necesita:

• definición Compose clara;
• imágenes identificadas;
• configuración separada;
• plantilla de variables;
• secretos recuperables;
• datos identificados;
• dependencias documentadas;
• procedimiento de comprobación.

La migración como prueba de calidad

No hace falta migrar periódicamente todos los servicios, pero probar uno en un entorno alternativo revela dependencias ocultas.

La organización interna de estas unidades se desarrolla en cómo organizar correctamente los proyectos Docker.

Controlar crecimiento de versiones e imágenes

El número de servicios también aumenta el número de imágenes y versiones que deben mantenerse.

No conservar todo indefinidamente

Una política de retención debe distinguir:

• versión actual;
• versión anterior útil para reversión;
• imágenes de pruebas;
• versiones obsoletas;
• artefactos temporales.

Conocer procedencia

Cuantos más proyectos existan, más importante resulta saber qué imágenes son oficiales, cuáles son propias y cuáles proceden de terceros.

No usar el host como archivo histórico

El registro de imágenes o repositorio debe conservar lo necesario. Producción debe mantener únicamente los recursos que sirven a la operación y recuperación.

Hacer que las copias sigan siendo viables

Una estrategia de copia que funciona con diez gigabytes puede dejar de ser adecuada con quinientos.

Medir duración

La ventana de backup debe revisarse según crecen los datos.

Medir restauración

El tiempo de recuperación puede aumentar incluso más que el de copia.

Separar por criticidad

No todos los proyectos necesitan la misma frecuencia ni la misma retención.

Evitar que backup y producción compitan

Si la copia satura disco, CPU o red, hay que modificar horario, método o arquitectura.

Reevaluar cuando cambie el volumen

El crecimiento debe activar revisiones de copia antes de que una restauración real revele que el procedimiento ya no cabe en el tiempo disponible.

Monitorizar tendencia y no solo estado instantáneo

El crecimiento se detecta observando evolución.

Conviene conservar históricos suficientes para responder:

• ¿cuánto crece el disco cada mes?
• ¿la memoria aumenta con nuevas versiones?
• ¿los backups tardan cada vez más?
• ¿los picos de CPU son más frecuentes?
• ¿aumenta el número de reinicios?
• ¿qué proyecto explica la mayor parte del crecimiento?

Alertas antes del límite

Una alerta útil deja tiempo para actuar. Avisar cuando el disco ya está completamente lleno llega demasiado tarde.

Revisión periódica

Además de alertas automáticas, una revisión mensual o trimestral ayuda a relacionar métricas con cambios de negocio y nuevos proyectos.

Automatizar sin perder control

A medida que crece el número de proyectos, repetir tareas manualmente aumenta errores.

Puede tener sentido automatizar:

• despliegues repetitivos;
• comprobaciones de salud;
• copias;
• rotación de logs;
• limpieza controlada;
• alertas de capacidad;
• inventario;
• validaciones previas a cambios.

Automatizar un proceso estable

No conviene automatizar una operación que todavía cambia cada vez que se ejecuta. Primero se define el procedimiento y después se automatiza.

Conservar trazabilidad

La automatización debe dejar claro qué cambió, cuándo y con qué resultado.

Cuándo el crecimiento exige pensar en disponibilidad

Más carga no implica automáticamente alta disponibilidad. Lo que cambia la decisión suele ser la criticidad.

Puede ser momento de revisar disponibilidad cuando:

• una caída afecta a una actividad principal;
• el tiempo de recuperación aceptable se reduce;
• el host único concentra demasiados servicios esenciales;
• las ventanas de mantenimiento dejan de ser aceptables;
• la restauración completa tarda demasiado.

Disponibilidad tiene coste operativo

Duplicar componentes puede exigir replicación de datos, balanceo, monitorización adicional y pruebas de conmutación.

Antes de introducirlo, conviene calcular si un procedimiento de recuperación rápido sigue siendo suficiente.

Cuándo Docker Compose puede dejar de ser suficiente

Docker Compose puede seguir siendo adecuado durante mucho tiempo si la plataforma tiene pocos hosts y los proyectos se gestionan de forma clara.

Una plataforma de orquestación más avanzada puede empezar a tener sentido cuando aparecen necesidades como:

• muchos hosts;
• reubicación automática de cargas;
• escalado horizontal frecuente;
• alta disponibilidad real de servicios;
• despliegues distribuidos complejos;
• gestión central de grandes cantidades de servicios.

No migrar por número de contenedores

No existe una cifra mágica. Veinte contenedores bien organizados pueden ser más fáciles de administrar que cinco proyectos con dependencias mal diseñadas.

Comparar el coste de la solución

Una orquestación avanzada añade nuevos componentes, conceptos, actualizaciones y requisitos de conocimiento. Solo aporta valor cuando esos costes son menores que los problemas que resuelve.

Plan de crecimiento por fases

Fase 1: plataforma inicial

• un host;
• proyectos independientes;
• redes claras;
• datos identificados;
• copias externas;
• monitorización básica.

Fase 2: control de capacidad

• históricos de CPU y memoria;
• seguimiento de almacenamiento;
• retención de logs;
• limpieza de imágenes;
• medición de backups;
• inventario de proyectos.

Fase 3: ampliación vertical

Se añaden recursos al host cuando el límite está claro y la arquitectura sigue siendo adecuada.

Fase 4: separación de cargas

Se mueve un proyecto, una base de datos, pruebas o almacenamiento cuando sus necesidades dejan de encajar con el resto.

Fase 5: varios hosts

Se formalizan redes entre máquinas, monitorización central, backups por host y procedimientos de migración.

Fase 6: revisión de disponibilidad

Se evalúa qué servicios requieren redundancia y cuáles pueden seguir dependiendo de recuperación.

Fase 7: orquestación avanzada solo si procede

Se adopta cuando la cantidad de hosts, despliegues y requisitos ya justifican su coste.

Ejemplo de evolución de una plataforma Docker

Etapa inicial

HOST 1
├── proxy
├── portal
├── automatizacion
└── monitorizacion

Todo funciona correctamente. La memoria y el disco tienen margen.

Primera ampliación

El portal aumenta su base de datos y uploads. Se amplía almacenamiento sin modificar el resto.

Segunda ampliación

La automatización empieza a ejecutar procesos intensivos y consume CPU en determinados horarios. Se reorganizan tareas y se aplican límites.

Tercera ampliación

La base de datos del portal se vuelve crítica y necesita almacenamiento más rápido. Se mueve a un segundo host:

HOST 1 - Docker
├── proxy
├── portal-web
├── automatizacion
└── monitorizacion

HOST 2 - Datos
└── base-portal

Cuarta ampliación

Los entornos de pruebas empiezan a competir con producción. Se crea un host de laboratorio:

HOST 1 - Producción
HOST 2 - Datos
HOST 3 - Pruebas

La evolución se ha realizado por necesidades concretas. No fue necesario rediseñar todo desde el primer día porque los proyectos, datos y dependencias ya estaban separados.

Errores frecuentes

Sobredimensionar desde el primer día

Consume presupuesto y puede llevar a una arquitectura compleja sin necesidad.

Esperar a que el disco esté lleno

El crecimiento debe medirse antes de alcanzar el límite.

Mirar solo CPU

Memoria, I/O, red y almacenamiento suelen ser igual o más importantes.

Añadir otro host sin separar dependencias

Distribuir físicamente una arquitectura acoplada puede aumentar el problema.

Confundir más contenedores con más escalabilidad

La cantidad no dice nada sobre capacidad real.

Convertir todo en microservicios

Puede multiplicar redes, despliegues, secretos y monitorización sin aportar valor.

Mover datos sin medir recuperación

Una arquitectura nueva puede mejorar rendimiento pero empeorar restauraciones.

Conservar todas las imágenes

Acumula espacio y dificulta saber qué versiones siguen siendo útiles.

No controlar logs

Un servicio estable puede llenar el disco lentamente.

No medir backups

La copia puede seguir ejecutándose “correctamente” mientras su duración crece hasta dejar de ser viable.

Añadir alta disponibilidad demasiado pronto

Introduce complejidad que puede superar la capacidad técnica disponible.

Migrar a una orquestación avanzada por moda

El cambio debe resolver problemas concretos de varios hosts, escalado o disponibilidad.

No considerar el tiempo humano

Una plataforma con recursos libres puede haber superado la capacidad de mantenimiento del equipo.

Lista de comprobación

• ¿Se conoce el número de proyectos activos?
• ¿Se mide CPU por host y por proyecto?
• ¿Se mide memoria disponible y tendencia?
• ¿Se conoce el crecimiento mensual del almacenamiento?
• ¿Se distingue datos persistentes de imágenes y logs?
• ¿Se controla latencia de disco cuando hay bases de datos?
• ¿Se conoce el tráfico de red relevante?
• ¿Los logs tienen rotación y retención?
• ¿Existe una política de limpieza de imágenes?
• ¿Los backups tienen duración medida?
• ¿Se conoce el tiempo de restauración?
• ¿Existe margen para picos y mantenimiento?
• ¿Se identifica cuál es el primer cuello de botella?
• ¿Se evita ampliar recursos que no son el problema?
• ¿El host puede ampliarse verticalmente?
• ¿Se conocen los límites físicos o del proveedor?
• ¿Los proyectos pueden migrarse por separado?
• ¿Los datos están identificados por proyecto?
• ¿Las dependencias externas están documentadas?
• ¿Puede introducirse un segundo host sin rehacer todas las aplicaciones?
• ¿Los servicios compartidos tienen capacidad suficiente?
• ¿Se revisa el impacto de fallo de componentes comunes?
• ¿Producción y pruebas pueden separarse cuando sea necesario?
• ¿Las tareas intensivas están programadas para no competir?
• ¿La automatización deja trazabilidad?
• ¿La monitorización conserva históricos?
• ¿Las alertas llegan antes del límite?
• ¿La alta disponibilidad responde a una necesidad real?
• ¿La orquestación avanzada solo se planteará cuando aporte valor?

Preguntas frecuentes

Conclusión

Planificar el crecimiento de una infraestructura Docker consiste en hacer que la ampliación sea gradual, medible y reversible. La plataforma no necesita anticipar todas las necesidades futuras, pero sí debe evitar decisiones que obliguen a reconstruirla cuando cambien CPU, memoria, almacenamiento, datos o número de servicios.

El primer paso es medir. CPU, memoria, disco, I/O, red, tamaño de bases de datos, duración de copias y crecimiento de logs permiten identificar qué límite se aproxima realmente. La tendencia es más importante que una cifra aislada.

La estrategia más sencilla suele ser ampliar verticalmente mientras siga siendo razonable. Añadir memoria, almacenamiento o capacidad de proceso conserva una arquitectura fácil de operar. Separar servicios en otros hosts debe hacerse cuando una carga tenga necesidades distintas, cuando se alcance un límite físico o cuando la criticidad justifique reducir concentración.

La capacidad técnica no es la única que crece. Aumentan proyectos, dependencias, imágenes, versiones y procedimientos. Una infraestructura puede tener recursos libres y estar saturada desde el punto de vista operativo. Por eso el crecimiento debe apoyarse en proyectos organizados, servicios independientes, inventario y monitorización.

Los datos merecen una atención especial porque su crecimiento es acumulativo. Aplicaciones e imágenes pueden recrearse; bases de datos y archivos persistentes necesitan capacidad, copia y restauración. Separar esos ciclos permite evolucionar la plataforma con menos riesgo.

Finalmente, crecer no significa adoptar automáticamente alta disponibilidad, múltiples hosts o una plataforma de orquestación compleja. Cada nueva capa debe resolver un problema real. Una infraestructura Docker está bien preparada cuando puede pasar de un host a varios, separar una base de datos, trasladar un proyecto o ampliar almacenamiento sin convertir cada cambio en una reconstrucción general.

Ese enfoque permite aprender y aplicar Docker como una herramienta de infraestructura sostenible: no solo para ejecutar contenedores, sino para diseñar sistemas capaces de evolucionar con control técnico y operativo.