Cómo convertir Docker en la plataforma central de una infraestructura tecnológica

Introducción

Convertir Docker en la plataforma central de una infraestructura tecnológica significa utilizar los contenedores como capa común para desplegar, organizar, actualizar y recuperar una parte significativa de los servicios empresariales, sin confundir centralización con concentración indiscriminada.

Docker puede aportar una gran ventaja cuando una infraestructura ha crecido a base de aplicaciones instaladas de formas diferentes: paquetes del sistema, servidores web configurados manualmente, servicios con dependencias incompatibles, aplicaciones alojadas en distintos directorios y procedimientos de actualización que solo conoce una persona. Los contenedores permiten introducir un lenguaje operativo común.

Sin embargo, convertir Docker en una plataforma central no significa que todo deba ejecutarse en un único servidor ni que cualquier aplicación tenga que contenerizarse. Una plataforma madura necesita distinguir qué servicios encajan bien en Docker, cuáles dependen demasiado del hardware o del sistema operativo, qué componentes deben mantenerse separados y qué funciones continúan siendo mejores como servicios externos.

El objetivo es construir una arquitectura en la que Docker actúe como capa de estandarización: cada aplicación tiene un proyecto identificable, versiones conocidas, almacenamiento persistente explícito, redes controladas, monitorización, backups y documentación. De esta forma, desplegar un nuevo servicio deja de ser una excepción y pasa a seguir un patrón repetible.

Este artículo explica cómo diseñar esa transición: qué papel debe ocupar Docker, cómo estructurar hosts y proyectos, cómo organizar redes y datos, cómo centralizar el acceso sin crear dependencias peligrosas, qué servicios conviene mantener fuera y cómo evolucionar hacia una plataforma estable que pueda administrarse durante años.

Índice

• Qué significa utilizar Docker como plataforma central
• Qué no significa centralizar en Docker
• Qué problemas puede resolver una plataforma Docker común
• Qué servicios encajan bien y cuáles no
• Arquitectura por capas de una plataforma Docker
• Uno o varios hosts: cómo decidir
• Organizar aplicaciones como proyectos independientes
• Crear estándares de nombres y estructura
• Diseñar redes fáciles de entender
• Proxy inverso, DNS y punto de entrada común
• Separar ejecución, configuración y datos
• Cómo tratar las bases de datos
• Secretos y credenciales
• Imágenes, versiones y registros
• Diseñar un proceso común de actualización
• Monitorización y observabilidad comunes
• Integrar copias de seguridad y recuperación
• Seguridad de la plataforma
• Inventario y catálogo de aplicaciones
• Automatizar despliegues sin perder control
• Evitar dependencias centrales peligrosas
• Qué conviene mantener fuera de Docker
• Cómo migrar una infraestructura existente
• Cómo preparar la plataforma para crecer
• Ejemplo de arquitectura para una pequeña empresa
• Errores frecuentes
• Conclusión
• Preguntas frecuentes

Qué significa utilizar Docker como plataforma central

Una plataforma central es una capa tecnológica común sobre la que se ejecutan muchos servicios de manera homogénea. Docker puede desempeñar ese papel porque permite describir cómo se despliega una aplicación con independencia de buena parte de las particularidades del sistema operativo anfitrión.

En una infraestructura organizada alrededor de Docker, la mayor parte de las aplicaciones siguen un patrón parecido:

• un proyecto claramente identificado;
• una o varias imágenes;
• un archivo Compose o definición equivalente;
• redes declaradas;
• almacenamiento persistente identificado;
• variables y secretos gestionados;
• versiones controladas;
• procedimiento de actualización;
• monitorización;
• backup;
• documentación.

El beneficio no está únicamente en ejecutar contenedores. Está en conseguir que servicios diferentes puedan administrarse mediante principios comunes.

Esto reduce la cantidad de conocimiento específico que hay que recordar para cada aplicación y facilita que la infraestructura pueda evolucionar sin reconstruirse desde cero cada vez que se incorpora una herramienta nueva.

Qué no significa centralizar en Docker

El término “plataforma central” puede interpretarse mal. Existen varias cosas que no deberían deducirse de él.

No significa ejecutar todo en un solo servidor

Docker puede ser la plataforma común aunque existan varios hosts. De hecho, separar cargas puede ser necesario por seguridad, rendimiento o continuidad.

No significa que todo deba contenerizarse

Hay servicios que dependen directamente del hardware, del sistema operativo o de integraciones específicas y pueden funcionar mejor fuera de contenedores.

No significa sustituir toda la infraestructura

DNS, routers, almacenamiento, hipervisores, copias, directorio de identidad y otros componentes pueden seguir existiendo fuera de Docker.

No significa utilizar Docker como sistema de backup

Los contenedores facilitan reconstrucción, pero los datos necesitan una estrategia de protección independiente.

No significa crear una dependencia absoluta

Si todos los servicios dependen de un único host Docker sin alternativa, la centralización puede crear un punto único de fallo.

La plataforma debe centralizar métodos de operación, no concentrar riesgos innecesarios.

Qué problemas puede resolver una plataforma Docker común

Instalaciones heterogéneas

Cuando cada aplicación se instala de una manera distinta, actualizar y reconstruir requiere conocimientos específicos. Docker reduce parte de esa heterogeneidad.

Dependencias incompatibles

Aplicaciones que necesitan distintas versiones de runtimes o bibliotecas pueden coexistir con mayor aislamiento.

Servidores difíciles de reconstruir

Una definición declarativa ayuda a separar la configuración de la máquina concreta.

Actualizaciones improvisadas

Las imágenes versionadas permiten tratar una actualización como un cambio controlado.

Documentación insuficiente

El propio proyecto Docker puede reflejar redes, volúmenes, imágenes y variables necesarias.

Crecimiento desordenado

Una estructura común permite incorporar nuevas aplicaciones sin inventar un procedimiento diferente cada vez.

Estos beneficios aparecen únicamente cuando Docker se administra con disciplina. Una colección de comandos ejecutados manualmente puede reproducir los mismos problemas que pretendía resolver.

Qué servicios encajan bien y cuáles no

Antes de convertir Docker en la plataforma principal conviene clasificar cargas.

Buenos candidatos

• aplicaciones web;
• APIs;
• wikis;
• gestores documentales;
• automatizaciones;
• servicios internos;
• herramientas de monitorización;
• repositorios de código;
• paneles;
• determinadas bases de datos;
• servicios auxiliares;
• aplicaciones con despliegues oficialmente soportados mediante contenedores.

Candidatos que requieren evaluación

• aplicaciones con gran consumo de almacenamiento;
• servicios con uso intensivo de GPU;
• bases de datos críticas;
• aplicaciones que necesitan acceso privilegiado al host;
• servicios con requisitos especiales de red.

Servicios que pueden tener más sentido fuera

• componentes estrechamente ligados al hardware;
• hipervisor del propio servidor;
• determinados servicios de red de bajo nivel;
• agentes que necesitan controlar el host;
• software cuyo fabricante no soporta contenedores;
• servicios externos que no aportan ventaja al autoalojarse.

La selección no debe basarse en la pregunta “¿se puede contenerizar?”, sino en “¿qué ganamos operativamente al hacerlo?”.

Arquitectura por capas de una plataforma Docker

Una arquitectura clara puede dividirse en varias capas.

1. Hardware o virtualización: servidores físicos, máquinas virtuales o VPS.
2. Sistema operativo: base Linux mantenida y endurecida.
3. Docker: motor de ejecución y Compose.
4. Servicios comunes: proxy, DNS, monitorización y otras funciones compartidas.
5. Aplicaciones: proyectos independientes.
6. Persistencia: volúmenes, bind mounts, bases de datos y almacenamiento externo.
7. Operación: backups, actualizaciones, alertas y documentación.

Esta separación ayuda a comprender qué responsabilidad pertenece a cada capa.

Un problema de Docker no es necesariamente un problema de aplicación; un fallo de almacenamiento no se arregla recreando un contenedor; un problema de DNS no debe diagnosticarse como fallo del servicio interno.

La arquitectura madura precisamente cuando estas fronteras son visibles.

Uno o varios hosts: cómo decidir

Una pequeña empresa puede empezar perfectamente con un único host Docker si los servicios son modestos. La cuestión es conocer las consecuencias.

Un host

Ventajas:

• menor coste;
• administración simple;
• backups más fáciles de centralizar;
• menos componentes de red.

Limitaciones:

• punto único de fallo;
• competencia por recursos;
• mantenimiento que afecta a varios servicios;
• menor aislamiento físico.

Varios hosts

Pueden separarse por función:

• producción;
• pruebas;
• servicios públicos;
• servicios internos;
• datos;
• cargas de alto consumo;
• inteligencia artificial.

La separación debe responder a una necesidad real. Añadir hosts antes de necesitarlos aumenta administración, patching, monitorización y copias.

Organizar aplicaciones como proyectos independientes

Cada aplicación debería poder identificarse como una unidad operativa independiente.

Una estructura posible es:

/srv/docker/
  reverse-proxy/
  documentation/
  monitoring/
  automation/
  application-a/
  application-b/
  database-tools/

Cada proyecto puede contener:

• compose.yml;
• archivo de variables no sensibles;
• referencias a secretos;
• scripts necesarios;
• documentación mínima;
• subdirectorios de configuración cuando proceda.

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

El objetivo es que mover, actualizar o retirar una aplicación no obligue a entender un gran archivo Compose compartido con veinte servicios sin relación.

Crear estándares de nombres y estructura

Una plataforma central necesita convenciones.

Conviene normalizar:

• nombres de proyectos;
• nombres de redes;
• nombres de volúmenes;
• rutas del host;
• dominios y subdominios;
• labels;
• variables;
• nombres de backups;
• identificadores en monitorización.

Un estándar no tiene que ser complejo. Debe permitir que una persona pueda deducir a qué aplicación pertenece cada recurso.

Por ejemplo, si cada volumen empieza con el identificador del proyecto, un listado de recursos será mucho más fácil de interpretar.

La coherencia ahorra más tiempo a largo plazo que cualquier optimización puntual.

Diseñar redes fáciles de entender

La red de Docker puede convertirse rápidamente en una zona difícil de diagnosticar si todas las aplicaciones se conectan a todas las redes.

Un patrón sencillo es:

• una red privada por aplicación;
• una red compartida para servicios que necesitan comunicarse con el proxy;
• redes adicionales solo cuando existe una dependencia justificada.

La base de datos de una aplicación, por ejemplo, normalmente solo necesita comunicarse con su propio backend. No tiene por qué estar accesible por el resto de servicios.

Las redes deben reflejar arquitectura, no simplemente conectividad técnica.

Cuanto menor sea el número de comunicaciones implícitas, más fácil será comprender seguridad y dependencias.

Proxy inverso, DNS y punto de entrada común

Cuando varias aplicaciones proporcionan servicios web, un proxy inverso común simplifica el acceso.

Puede encargarse de:

• HTTPS;
• certificados;
• dominios;
• redirecciones;
• cabeceras comunes;
• encaminamiento hacia cada servicio.

Así se evita publicar puertos arbitrarios como:

servidor:8081
servidor:8082
servidor:8095
servidor:9003

Y se pueden utilizar nombres coherentes:

docs.empresa.local
monitor.empresa.local
automatizacion.empresa.local
archivos.empresa.local

Sin embargo, el proxy se convierte en un servicio común importante. Debe ser fácil de reconstruir y no debería convertirse en una pieza misteriosa de la que depende todo.

Separar ejecución, configuración y datos

Una plataforma central debe distinguir claramente tres tipos de elementos.

Ejecución

Imágenes y contenedores. Idealmente pueden recrearse.

Configuración

Compose, archivos de aplicación, variables, scripts y parámetros.

Datos

Información generada por usuarios, bases de datos, documentos, uploads y contenido persistente.

Esta separación permite aplicar ciclos de vida diferentes.

Un contenedor puede actualizarse cada semana. La configuración puede cambiar varias veces al año. Los datos pueden necesitar copias diarias o incluso más frecuentes.

Mezclar los tres elementos dificulta actualizaciones y recuperación.

La gestión específica de persistencia se desarrolla en cómo gestionar correctamente los volúmenes Docker.

Cómo tratar las bases de datos

Las bases de datos pueden ejecutarse dentro de Docker, fuera de Docker o en servicios administrados. No existe una única respuesta correcta.

Dentro de Docker

Puede ser perfectamente válido para muchas aplicaciones pequeñas si:

• los datos son persistentes;
• las versiones están controladas;
• existe backup coherente;
• los recursos están dimensionados;
• la recuperación está probada.

Servidor de datos separado

Puede tener sentido cuando varias aplicaciones dependen de una infraestructura de base de datos común o cuando la criticidad justifica separación.

Servicio administrado

Puede reducir carga operativa cuando la disponibilidad y el mantenimiento de la base son más importantes que el control local.

La plataforma Docker debe poder integrarse con cualquiera de estos modelos. Centralizar aplicaciones no obliga a centralizar también todos los datos.

Secretos y credenciales

Una infraestructura que concentra muchas aplicaciones también concentra credenciales.

Deben evitarse prácticas como:

• contraseñas dentro de Dockerfiles;
• tokens incluidos en repositorios;
• un único archivo de secretos para toda la plataforma;
• credenciales compartidas sin inventario;
• claves que nadie sabe recuperar.

Los secretos deben poder inyectarse en los servicios sin formar parte de la imagen y deben protegerse mediante un procedimiento compatible con la escala de la organización.

No siempre hace falta desplegar una plataforma compleja de gestión de secretos. Pero sí hace falta saber dónde están, quién puede acceder y cómo se recuperan.

Imágenes, versiones y registros

La reproducibilidad depende de saber qué software se está ejecutando.

Conviene registrar:

• nombre de imagen;
• origen;
• versión;
• fecha de actualización;
• personalizaciones;
• dependencias especiales.

Las etiquetas flotantes pueden ser cómodas para pruebas, pero una plataforma estable debería evitar que reiniciar un proyecto cambie silenciosamente la versión.

Cuando existen imágenes propias, puede ser útil disponer de un registro controlado o al menos de un proceso reproducible de construcción.

La imagen no debe convertirse en una pieza irrepetible creada manualmente en un servidor.

Diseñar un proceso común de actualización

Una de las mayores ventajas de una plataforma central es poder aplicar un procedimiento homogéneo.

Un proceso básico puede ser:

1. revisar la versión disponible;
2. leer cambios incompatibles;
3. comprobar requisitos;
4. hacer backup cuando proceda;
5. registrar la versión actual;
6. actualizar;
7. validar healthcheck y funcionamiento;
8. comprobar logs;
9. mantener capacidad de reversión.

No todas las aplicaciones necesitan actualizarse el mismo día ni con la misma rapidez.

La estrategia específica se desarrolla en cómo diseñar una estrategia de actualización de contenedores Docker.

La centralización debe permitir gestionar diferencias sin abandonar el estándar común.

Monitorización y observabilidad comunes

Una plataforma con múltiples aplicaciones necesita una visión conjunta.

Conviene monitorizar al menos:

• estado de contenedores;
• disponibilidad de aplicaciones;
• CPU;
• RAM;
• disco;
• crecimiento de volúmenes;
• reinicios;
• errores;
• caducidad de certificados;
• resultado de backups.

Las métricas deben poder relacionarse con aplicaciones, no únicamente con nombres internos de contenedor.

Un catálogo coherente y una nomenclatura estable hacen mucho más útil la monitorización.

Para comenzar puede utilizarse una aproximación sencilla como la descrita en cómo monitorizar contenedores Docker de forma sencilla.

Integrar copias de seguridad y recuperación

Si Docker se convierte en plataforma central, el backup no puede ser una tarea secundaria.

Cada aplicación debe tener identificado:

• qué datos necesita;
• dónde están;
• cómo se consiguen copias consistentes;
• qué configuración debe conservarse;
• qué secretos necesita;
• qué frecuencia corresponde;
• qué retención se aplica;
• cómo se restaura.

El enfoque detallado se desarrolla en cómo integrar Docker con copias de seguridad empresariales.

La prueba definitiva consiste en reconstruir una aplicación sobre un host limpio. Si puede hacerse a partir de configuraciones conocidas y copias verificadas, la plataforma empieza a ser verdaderamente reproducible.

Seguridad de la plataforma

Cuanto mayor sea el número de aplicaciones que dependen de Docker, mayor importancia tiene proteger el host.

Reducir privilegios

No todos los contenedores necesitan ejecutarse como root ni acceder a dispositivos del host.

Evitar el socket Docker

Montar el socket dentro de un contenedor proporciona capacidades muy elevadas. Debe hacerse únicamente cuando exista una necesidad clara.

Reducir puertos publicados

Los servicios internos pueden comunicarse mediante redes Docker sin aparecer directamente en la red física.

Mantener imágenes actualizadas

Las imágenes también contienen sistema operativo y bibliotecas que pueden acumular vulnerabilidades.

Proteger el host

Firewall, acceso SSH, actualizaciones, usuarios y permisos del sistema siguen siendo esenciales. Docker no reemplaza la seguridad del sistema operativo.

Separar cargas sensibles

Determinados servicios pueden justificar un host o entorno diferente por criticidad o exposición.

Inventario y catálogo de aplicaciones

Cuando Docker se convierte en plataforma central, un simple docker ps deja de ser una visión suficiente.

La organización necesita saber:

• qué aplicaciones existen;
• para qué sirven;
• quién las utiliza;
• quién es responsable;
• dónde se ejecutan;
• qué datos manejan;
• qué dependencias tienen;
• qué criticidad presentan;
• cómo se protegen;
• en qué estado de ciclo de vida se encuentran.

El inventario técnico y el catálogo funcional cumplen funciones complementarias.

Este segundo nivel se desarrolla en cómo crear un catálogo interno de aplicaciones Docker.

Automatizar despliegues sin perder control

Una plataforma común permite automatizar tareas repetitivas.

Pueden automatizarse:

• creación de proyectos;
• validación de Compose;
• actualizaciones;
• backups;
• pruebas de disponibilidad;
• inventarios;
• limpieza controlada;
• alertas.

Pero automatizar no debe ocultar la lógica.

Un buen procedimiento automático debe ser:

• documentado;
• versionado;
• observable;
• capaz de fallar de forma visible;
• repetible;
• reversible cuando corresponda.

La automatización aporta valor cuando estandariza decisiones conocidas. Automatizar un entorno caótico solo hace que los errores ocurran más deprisa.

Evitar dependencias centrales peligrosas

Una plataforma central introduce inevitablemente servicios compartidos. El objetivo es que esas dependencias sean conscientes y controladas.

Algunos candidatos a convertirse en puntos críticos son:

• proxy inverso;
• DNS;
• almacenamiento;
• base de datos compartida;
• autenticación central;
• host Docker;
• repositorio de imágenes;
• gestor de secretos.

No siempre hace falta duplicarlos. Pero sí debe conocerse qué ocurre cuando fallan.

Una dependencia compartida debe tener:

• criticidad elevada en el inventario;
• backup adecuado;
• documentación;
• monitorización;
• procedimiento de recuperación;
• alternativa temporal cuando sea necesaria.

La centralización responsable hace visibles los puntos únicos de fallo en lugar de ignorarlos.

Qué conviene mantener fuera de Docker

Una arquitectura madura también sabe dónde termina Docker.

Sistema operativo del host

Docker depende de él. Su administración, almacenamiento y red siguen necesitando procedimientos propios.

Hipervisor

Si Docker se ejecuta dentro de máquinas virtuales, el hipervisor pertenece a una capa inferior.

Infraestructura de red

Routers, switches, VPN perimetral y otros componentes de red no deben tratarse como simples aplicaciones.

Almacenamiento externo

NAS, SAN o sistemas de backup pueden proporcionar persistencia a Docker sin ejecutarse dentro de él.

Servicios externos con alta especialización

Correo, determinados sistemas financieros o plataformas con obligaciones particulares pueden seguir siendo mejores como servicios contratados.

Docker debe ocupar el centro de la capa de aplicaciones cuando aporta valor, no absorber toda la infraestructura.

Cómo migrar una infraestructura existente

No conviene migrar todo de una sola vez.

Fase 1: inventariar

Identificar aplicaciones, dependencias, datos, criticidad y responsables.

Fase 2: preparar estándares

Definir estructura de proyectos, redes, almacenamiento, proxy, backup y monitorización.

Fase 3: migrar una aplicación secundaria

Elegir un servicio útil pero no crítico permite validar la arquitectura.

Fase 4: documentar el patrón

El primer proyecto debe convertirse en referencia para los siguientes.

Fase 5: incorporar servicios comunes

Proxy, monitorización y procedimientos de backup empiezan a formar una plataforma.

Fase 6: migrar aplicaciones por grupos

Se priorizan aquellas donde el beneficio de contenerización sea claro.

Fase 7: revisar lo que queda fuera

No todo lo no migrado representa deuda. Algunas aplicaciones pueden permanecer fuera deliberadamente.

Fase 8: retirar infraestructura antigua

Solo después de validar estabilidad y recuperación deben eliminarse sistemas sustituidos.

Cómo preparar la plataforma para crecer

Una buena plataforma debe permitir incorporar más servicios sin rehacer su arquitectura básica.

Para conseguirlo conviene mantener:

• proyectos desacoplados;
• datos claramente separados;
• nombres consistentes;
• redes simples;
• servicios comunes bien documentados;
• backup por aplicación;
• monitorización escalable;
• versionado;
• automatización progresiva.

Cuando un host deja de ser suficiente, algunos proyectos pueden trasladarse a otro sin cambiar el modelo operativo completo.

Cuando una aplicación necesita una base de datos separada, puede desacoplarse.

Cuando aparece una carga de inteligencia artificial, puede reservarse un host específico y seguir utilizando Docker como capa común.

La arquitectura correcta no intenta predecir cada necesidad futura. Intenta que el cambio sea posible sin romper todo lo anterior.

Ejemplo de arquitectura para una pequeña empresa

Una pequeña empresa podría organizar su infraestructura de la siguiente forma:

Host Docker principal

• wiki interna;
• gestor documental;
• automatización;
• paneles internos;
• repositorio Git;
• monitorización;
• proxy inverso.

NAS independiente

• archivos empresariales;
• destino de backup local;
• almacenamiento histórico;
• determinados volúmenes compartidos.

Servicios externos

• correo;
• calendario;
• copias remotas;
• determinadas herramientas especializadas.

Acceso

Las aplicaciones internas se utilizan mediante VPN o red local. Las que necesitan acceso web se publican mediante el proxy con HTTPS.

Operación

• cada aplicación tiene Compose;
• las configuraciones están versionadas;
• los datos persistentes están inventariados;
• los backups se integran en una estrategia general;
• la monitorización muestra estado de servicios y hosts;
• el catálogo identifica responsables y criticidad.

En este modelo Docker es claramente la plataforma central de aplicaciones, pero no pretende sustituir almacenamiento, red, servicios externos ni todos los niveles de infraestructura.

Errores frecuentes

Meter todas las aplicaciones en un único Compose

Hace que cambios independientes terminen acoplados y dificulta mantenimiento.

Confundir centralización con un solo host

La plataforma puede ser común aunque las cargas estén distribuidas.

Crear demasiados servicios compartidos

Compartir todo parece eficiente al principio, pero aumenta dependencias y alcance de los fallos.

No separar datos de contenedores

Impide tratar ejecución y persistencia con ciclos de vida diferentes.

No controlar versiones

Una plataforma que cambia sin saber exactamente qué imágenes utiliza pierde reproducibilidad.

Exponer cada contenedor directamente

Genera puertos, reglas y superficies de ataque difíciles de gestionar.

No integrar backups

La centralización aumenta el impacto de un fallo si los datos no están protegidos correctamente.

Automatizar demasiado pronto

Primero debe existir un procedimiento estable. Después puede automatizarse.

Convertir Docker en una religión tecnológica

Algunos servicios funcionan mejor fuera. La arquitectura debe estar guiada por operación y riesgo, no por uniformidad absoluta.

No documentar la plataforma común

Proxy, redes compartidas, almacenamiento y procedimientos centrales deben entenderse especialmente bien porque afectan a muchas aplicaciones.

No planificar la retirada de aplicaciones

Una plataforma sostenible debe poder eliminar servicios igual de ordenadamente que los incorpora.

Conclusión

Convertir Docker en la plataforma central de una infraestructura tecnológica puede simplificar enormemente la operación cuando se utiliza para estandarizar despliegue, actualización, redes, persistencia, monitorización y recuperación.

La clave está en comprender que Docker debe ser una capa común, no una concentración absoluta. Una arquitectura bien diseñada puede utilizar varios hosts, almacenamiento externo, servicios contratados y componentes tradicionales mientras mantiene Docker como modelo principal para ejecutar aplicaciones.

Los proyectos independientes, las convenciones estables, las redes simples, el control de versiones y la separación entre configuración y datos son la base. Sobre ellos pueden construirse servicios comunes de proxy, monitorización, backups y automatización.

La plataforma también debe hacer visibles sus dependencias centrales y sus límites. DNS, almacenamiento, host, autenticación o proxy pueden convertirse en puntos críticos y necesitan tratamiento acorde con su impacto.

Docker se convierte realmente en una plataforma central cuando incorporar, actualizar, recuperar o retirar una aplicación deja de depender de improvisación y pasa a seguir un sistema común, comprensible y repetible.

Preguntas frecuentes