[{"data":1,"prerenderedAt":196},["ShallowReactive",2],{"seo-verification":3,"blog-docker-v29-en-vps-migrar-sin-romper-stacks-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-docker-v29-en-vps-migrar-sin-romper-stacks-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":137,"ctaBody":138,"ctaButton":139,"ctaUrl":140,"relatedPosts":141},247,"docker-v29-en-vps-migrar-sin-romper-stacks",{"fr":12,"en":13,"ar":14,"es":10},"docker-v29-migration-vps-breaking-changes","docker-v29-on-vps-migrate-without-breaking-your-stacks","docker-v29-على-vps-الهجرة-دون-كسر-المكدسات","Docker v29 en VPS: migrar sin romper sus stacks","Docker Engine v29 cambia la API mínima, el backend de red y el almacén de imágenes. Guía de migración para agencias que gestionan una flota de VPS de clientes.",12,0,false,"2026-08-12T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"Despliegue","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-v29-migration-vps-breaking-changes-poster.svg","Docker Engine v29, publicado en marzo de 2026, modifica tres cimientos a la vez: versión mínima de API, backend de red nftables y almacén de imágenes containerd. Un VPS sin preparar que recibe esta actualización se rompe en silencio — docker-compose v1 standalone deja de funcionar, Dockge ya no arranca, las reglas iptables que sus stacks daban por hechas desaparecen. Esta guía le permite detectar lo que está roto, migrar limpiamente y evitar que el próximo `apt upgrade` se convierta en una incidencia de cliente a las 2 de la madrugada.",[34,38,49,52,62,71,80,89,109,113,116,134],{"type":35,"title":36,"body":37},"h2","Por qué Docker v29 rompe los stacks existentes — y por qué ahora","Una agencia que gestiona una flota de VPS de clientes vive en una tenaza particular: la actualización aguas arriba (Docker, Ubuntu, Debian) llega desde fuera, con independencia de quién administre el servidor. Cuando un VPS de cliente recibe `apt upgrade` sin control, tres rupturas ocurren al mismo tiempo.\n\n**Primera ruptura — versión mínima de API.** Docker Engine v29 eleva la versión mínima de API a `1.44`. Los clientes que todavía funcionan con el antiguo `docker-compose` v1 standalone (binario `\u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose`) fallan de inmediato: su código cliente está compilado para versiones de API anteriores, y el daemon rechaza la conexión con un mensaje de incompatibilidad.\n\n**Segunda ruptura — backend de red nftables.** Docker v29 activa nftables por defecto en lugar de iptables para gestionar las reglas de cortafuegos de las redes Docker. Los scripts de terceros que inspeccionan directamente las cadenas iptables (scripts de monitorización, cortafuegos a medida, algunas reglas UFW) ya no ven las reglas Docker — no porque hayan desaparecido, sino porque ahora viven en nftables.\n\n**Tercera ruptura — almacén de imágenes containerd.** El backend de almacenamiento de las imágenes pasa al almacén containerd. En opt-in desde v29, será el valor por defecto en v30. En un servidor migrado, las imágenes existentes siguen accesibles, pero la ruta de caché cambia, lo que puede sorprender a los scripts que inspeccionan `\u002Fvar\u002Flib\u002Fdocker\u002Fimage` directamente.\n\nLa objeción clásica — «nuestros clientes gestionan sus VPS ellos mismos» — no protege. La ruptura llega desde fuera, y es a la agencia a quien llama el cliente cuando su sitio deja de responder.",{"type":39,"title":40,"items":41},"ul","Lo que esta guía le permite hacer",[42,43,44,45,46,47,48],"**Detectar la versión de API** en tensión entre su cliente `docker` y el daemon del VPS, antes de que el próximo comando produzca un error críptico.","**Identificar en 30 segundos** si un VPS todavía funciona con `docker-compose` v1 standalone — el binario obsoleto desde Docker Desktop 3.6 y retirado de los paquetes oficiales.","**Migrar al plugin `docker compose` v2** con los dos comandos exactos, y luego verificar que sus `docker-compose.yml` existentes funcionan sin cambios de sintaxis.","**Comprender el impacto de nftables** en sus stacks: lo que sigue funcionando (las redes Docker), lo que puede romperse (sus scripts que leen iptables) y el comando de diagnóstico que lo aclara.","**Activar o aplazar el almacén containerd** según su calendario de migración, con la clave de configuración exacta y el comando de verificación.","**Evaluar la compatibilidad** de Dockge, Portainer y CasaOS App Store con v29, para no descubrir la incompatibilidad durante una incidencia de cliente.","**Preparar los VPS de sus clientes** para que el próximo `apt upgrade` sea un evento planificado, no una urgencia nocturna.",{"type":35,"title":50,"body":51},"Requisitos previos antes de empezar","Esta guía se aplica a cualquier VPS Ubuntu 22.04\u002F24.04 o Debian 11\u002F12 en el que Docker Engine esté instalado desde los repositorios oficiales de Docker Inc. (no el paquete `docker.io` de la distribución). Necesita un acceso SSH root o sudo. No se requiere ninguna interrupción de servicio para los pasos de diagnóstico; la migración del plugin compose necesita unos segundos durante los cuales los comandos `docker compose` no están disponibles. Prevea un snapshot del VPS antes de modificar `\u002Fetc\u002Fdocker\u002Fdaemon.json` si activa el almacén containerd — la restauración en caso de problema lleva menos de cinco minutos con un buen VPS que ofrezca snapshots bajo demanda.",{"type":53,"title":54,"steps":55},"steps","Paso 1 — Diagnosticar la versión de API",[56,59],{"title":57,"body":58},"Verificar la versión de API del cliente y del daemon","En cada VPS que vaya a auditar, ejecute los dos comandos siguientes:\n\n```bash\ndocker version --format '{{.Client.APIVersion}}'\ndocker version --format '{{.Server.APIVersion}}'\n```\n\nSi la versión del cliente es inferior a `1.44` y el daemon funciona en v29, obtendrá un error en los próximos comandos. El umbral `1.44` es el mínimo aceptado por Docker Engine v29: un cliente compilado para `1.43` o anterior falla con `Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client`.\n\nSi ambas líneas muestran `1.44` o más, su cliente es compatible. Pase al paso siguiente.",{"title":60,"body":61},"Detectar la presencia de docker-compose v1 standalone","El comando `docker-compose` con guion y el comando `docker compose` sin guion no son lo mismo. El v1 es un binario Python autónomo; el v2 es un plugin Go integrado en la CLI de Docker.\n\n```bash\nwhich docker-compose && docker-compose --version\n```\n\nSi el comando devuelve una ruta en `\u002Fusr\u002Flocal\u002Fbin\u002F` o `\u002Fusr\u002Fbin\u002F` con una versión `1.x.x`, tiene el binario standalone obsoleto. Tras la actualización a Docker v29, ese binario devuelve `docker-compose: command not found` si el paquete ha sido retirado, o el error de API descrito arriba si todavía está presente.\n\n```bash\ndocker compose version\n```\n\nSi este comando devuelve `Docker Compose version v2.x.x`, el plugin v2 ya está presente. Ambos pueden convivir temporalmente, pero el objetivo es usar únicamente el plugin v2.",{"type":53,"title":63,"steps":64},"Paso 2 — Migrar de docker-compose v1 al plugin v2",[65,68],{"title":66,"body":67},"Retirar el binario v1 e instalar el plugin","```bash\napt remove docker-compose\napt install docker-compose-plugin\n```\n\nEn un VPS Debian o Ubuntu que use los repositorios oficiales de Docker Inc. (`download.docker.com`), el paquete `docker-compose-plugin` está disponible sin configuración adicional. Si `apt remove docker-compose` responde `Package not found`, el binario se instaló manualmente: localícelo con `which docker-compose` y elimine el archivo.\n\nVerificación posterior a la migración:\n\n```bash\ndocker compose version\n# Docker Compose version v2.36.0\n```",{"title":69,"body":70},"Verificar la compatibilidad sintáctica de sus archivos Compose existentes","La gran mayoría de los archivos `docker-compose.yml` escritos para v1 funcionan sin modificación con el plugin v2. Las únicas rupturas de sintaxis afectan a las directivas `version:` superiores a `\"3.8\"` (ignoradas en v2, no bloqueantes) y a la opción `--compatibility` (retirada). Valide sus archivos existentes:\n\n```bash\ndocker compose config\n```\n\nEste comando resuelve las variables de entorno, valida la sintaxis y muestra la configuración resuelta. Una salida sin errores significa que su archivo es compatible.\n\nSi su equipo usa scripts de shell con `docker-compose` (con guion), ponga un alias de compatibilidad en el `\u002Fetc\u002Fbash.bashrc` del VPS:\n\n```bash\nalias docker-compose='docker compose'\n```\n\nEste alias no resuelve los scripts que llaman a `docker-compose` con ruta absoluta desde un cron o un servicio systemd — audítelos.",{"type":53,"title":72,"steps":73},"Paso 3 — Entender y adaptarse al cambio de backend de red nftables",[74,77],{"title":75,"body":76},"Verificar que las redes Docker siguen funcionando","La buena noticia: `docker network` funciona correctamente con nftables. El tráfico entre contenedores, el NAT y la exposición de puertos siguen funcionando. Lo que cambia es la herramienta subyacente que escribe las reglas.\n\n```bash\ndocker network ls\n```\n\nSus redes bridge existentes siguen apareciendo en la lista. Para comprobar que un contenedor recibe tráfico en el puerto esperado, pruebe directamente:\n\n```bash\ncurl -s http:\u002F\u002Flocalhost:8080\u002Fhealth\n```\n\nSi la respuesta es correcta, el plano de datos de Docker funciona con independencia del backend.",{"title":78,"body":79},"Diagnosticar el impacto en sus scripts iptables","El problema aparece cuando un script de terceros (monitorización, Ansible, reglas UFW) inspecciona `iptables` para comprobar que las reglas Docker están presentes:\n\n```bash\niptables -L DOCKER 2>&1\n```\n\nCon el backend nftables, esa cadena está vacía o ausente. El script devuelve un error mientras Docker funciona perfectamente. No es una avería de Docker — es su herramienta de auditoría, que ya no mira en el sitio correcto.\n\nPara inspeccionar las reglas reales:\n\n```bash\nnft list ruleset | grep -A 20 'docker'\n```\n\nSi sus scripts de monitorización o sus playbooks Ansible comprueban la presencia de reglas iptables específicas de Docker, adáptelos para consultar nftables en lugar de deducir de ahí una avería.\n\nSi tiene reglas UFW personalizadas que interactúan con las reglas Docker, consulte la documentación de Docker sobre el modo `DOCKER-USER` — existe tanto en nftables como en iptables, pero la sintaxis para añadir reglas difiere. El artículo [pare-feu-ufw-vps](\u002Fblog\u002Fpare-feu-ufw-vps) cubre UFW de forma general; para la interacción específica de Docker v29, consulte las notas de la versión oficial.",{"type":53,"title":81,"steps":82},"Paso 4 — Evaluar y activar el almacén de imágenes containerd",[83,86],{"title":84,"body":85},"Verificar el driver de almacenamiento actual","```bash\ndocker info | grep 'Storage Driver'\n```\n\nEn un VPS actualizado a v29 sin cambios de configuración, obtendrá normalmente `Storage Driver: overlay2`. El almacén containerd es opt-in en v29 — no se activa automáticamente. Será el valor por defecto en v30.\n\nSi ve `Storage Driver: overlayfs` (señal de que alguien ya ha activado el backend containerd), el almacén está activo.",{"title":87,"body":88},"Activar el almacén containerd (opt-in, recomendado antes de v30)","Para activar el almacén containerd en v29 y preparar la migración antes de que se imponga en v30, añada la clave siguiente en `\u002Fetc\u002Fdocker\u002Fdaemon.json`:\n\n```bash\n{\n  \"features\": {\n    \"containerd-snapshotter\": true\n  }\n}\n```\n\nReinicie el daemon:\n\n```bash\nsystemctl restart docker\n```\n\nVerificación:\n\n```bash\ndocker info | grep 'Storage Driver'\n# Storage Driver: overlayfs\n```\n\n**Punto de atención**: las imágenes existentes descargadas bajo `overlay2` siguen disponibles, pero las nuevas capas se escriben en el formato containerd. Si necesita volver atrás, elimine la clave y reinicie — las imágenes del nuevo formato dejarán de ser accesibles sin el backend containerd. Por eso se recomienda un snapshot antes de este paso.",{"type":90,"title":91,"headers":92,"rows":96},"comparison","Compatibilidad de las herramientas de terceros con Docker Engine v29",[93,94,95],"Herramienta","Estado de compatibilidad con v29","Acción recomendada",[97,101,105],[98,99,100],"**Dockge** (hasta 1.4.1 incluido)","No compatible: el daemon de Dockge llama a rutas de API retiradas en v29. El panel ya no arranca tras la actualización de Docker.","Actualizar Dockge a la versión 1.4.2 o superior, que apunta a la API v1.44. Revisar las notas de versión de Dockge antes de un `apt upgrade` en un VPS que lo aloje.",[102,103,104],"**Portainer** (Community Edition \u003C 2.21)","Parcialmente compatible: la interfaz funciona, pero los entornos Docker standalone pueden mostrar errores en las vistas de red. La versión 2.21 corrige las llamadas nftables.","Actualizar Portainer con `docker pull portainer\u002Fportainer-ce:latest` y luego `docker compose up -d` antes de actualizar Docker Engine.",[106,107,108],"**CasaOS App Store**","Compatibilidad parcial documentada: las apps desplegadas siguen funcionando, pero el gestor de apps puede señalar errores al inspeccionar las imágenes si el almacén containerd está activado. No hay versión correctiva anunciada a fecha de 2026-08.","Mantener el almacén containerd en opt-out (valor por defecto en v29) en los VPS con CasaOS hasta que haya una versión correctiva. Probar en un entorno de copia antes de cualquier actualización.",{"type":110,"title":111,"body":112},"tip","Pruebe la migración en un snapshot antes de tocar la producción","Un VPS con acceso root y snapshots permite validar cada paso de esta migración sin riesgo. Cree un snapshot llamado `avant-docker-v29`, realice la migración completa, valide sus stacks y elimine después el snapshot. Si algo sale mal por el camino, la restauración devuelve el VPS a su estado inicial en menos de cinco minutos. Es exactamente el uso que cubren los snapshots bajo demanda: probar una actualización de sistema arriesgada en una copia exacta, no en la producción del cliente.",{"type":35,"title":114,"body":115},"Resolución de problemas — errores reales y remedios","Los tres escenarios siguientes cubren la mayoría de las incidencias observadas durante migraciones a Docker v29 en flotas de VPS.",{"type":53,"title":117,"steps":118},"Escenarios de error frecuentes",[119,122,125,128,131],{"title":120,"body":121},"Error: `client version X.XX is too old. Minimum supported API version is 1.44`","**Causa**: el binario `docker-compose` v1 standalone sigue presente e intenta comunicarse con el daemon v29.\n\n**Remedio**:\n\n```bash\napt remove docker-compose\napt install docker-compose-plugin\ndocker compose version\n```\n\nSi el binario se instaló manualmente (fuera de apt), búsquelo:\n\n```bash\nwhich docker-compose\nrm \u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose\n```",{"title":123,"body":124},"Error: `docker-compose: command not found` tras `apt upgrade`","**Causa**: el paquete `docker-compose` (v1) fue retirado durante la actualización, y el plugin v2 no se instaló.\n\n**Remedio**:\n\n```bash\napt install docker-compose-plugin\n```\n\nCompruebe después que sus scripts que llaman a `docker-compose` (con guion) usan ahora `docker compose` (sin guion), o ponga el alias de sistema.",{"title":126,"body":127},"Error: `iptables: No chain\u002Ftarget\u002Fmatch by that name` en un script de monitorización","**Causa**: su script inspecciona la cadena `DOCKER` en iptables, pero Docker v29 con nftables ya no la escribe ahí.\n\n**Remedio**: sustituya la comprobación iptables por una comprobación nftables:\n\n```bash\nnft list ruleset | grep -c 'docker'\n```\n\nSi el recuento es mayor que cero, las reglas Docker están presentes en nftables. O use `docker network inspect bridge` para comprobar el estado del plano de datos directamente desde Docker, sin depender del backend de red.",{"title":129,"body":130},"Dockge ya no arranca tras la actualización","**Causa**: Dockge 1.4.1 y anteriores llaman a rutas de API ausentes en Docker Engine v29.\n\n**Remedio**:\n\n```bash\ncd \u002Fopt\u002Fdockge\ndocker compose pull\ndocker compose up -d\n```\n\nSi el tag `latest` de la imagen de Dockge ya está en 1.4.2 o superior, este comando basta. Si no, edite el `docker-compose.yml` de Dockge para apuntar al tag de la versión correctiva antes de relanzarlo.",{"title":132,"body":133},"Los contenedores ya no responden en sus puertos tras reiniciar el daemon","**Causa**: en el primer reinicio de `dockerd` en modo nftables, las reglas de NAT se reescriben en el backend correcto, pero algunas distribuciones tienen un conflicto entre el servicio `iptables-legacy` y nftables que retrasa la puesta en marcha de las reglas.\n\n**Remedio**:\n\n```bash\nsystemctl stop docker\nsystemctl disable iptables\nsystemctl start docker\n```\n\nCompruebe después que los contenedores se han reiniciado correctamente (`docker compose up -d`) y que los puertos están expuestos (`docker ps --format 'table {{.Names}}\\t{{.Ports}}'`).",{"type":35,"title":135,"body":136},"Preparar su flota para evitar la próxima incidencia","Una migración a Docker v29 bien llevada no es un acontecimiento aislado — es la ocasión de instaurar los reflejos que evitan la próxima urgencia nocturna.\n\n**Bloquee la versión de Docker en `apt`.** En los VPS de clientes, impida que Docker se actualice automáticamente durante los `apt upgrade` no supervisados:\n\n```bash\napt-mark hold docker-ce docker-ce-cli containerd.io\n```\n\nDesbloquee (`apt-mark unhold`) únicamente cuando esté listo para migrar, después de haber probado en un snapshot.\n\n**Automatice la auditoría de la flota.** Un playbook Ansible que verifique la versión de API de Docker en cada VPS se escribe en menos de una hora y le da un cuadro de mando de la exposición de su flota antes de cada versión mayor de Docker. El artículo [ansible-automatiser-serveurs-vps](\u002Fblog\u002Fansible-automatiser-serveurs-vps) cubre la implantación de este tipo de inventario.\n\n**Integre la migración de Docker en su rutina de parches.** El procedimiento descrito aquí — snapshot, verificación de API, migración de compose, prueba de nftables, validación de los stacks — se documenta como runbook y se repite en cada versión mayor. El artículo [routine-correctifs-apps-self-hosted](\u002Fblog\u002Froutine-correctifs-apps-self-hosted) ofrece una estructura para industrializar estos gestos en una flota de VPS.\n\n**Pruebe sus stacks en un entorno de copia.** Un VPS de staging con snapshot le permite reproducir exactamente el contexto de un VPS de cliente, repetir la migración y validar los stacks antes de intervenir en producción. Es lo que hacen posible, a escala de una agencia, los VPS con acceso root y snapshots bajo demanda.","VPS listos para Docker v29 — con snapshots y acceso root","Una agencia que gestiona varios VPS de clientes necesita una infraestructura Docker homogénea, versionada y preparada para las actualizaciones aguas arriba. ServOrbit ofrece VPS con acceso root, IPv4 dedicada y snapshots — para que cada migración se pruebe primero en un entorno de copia, no en la producción de un cliente.","Ver los VPS Cloud","\u002Fsolutions\u002Fagences",[142,157,177],{"id":143,"slug":144,"slugs":145,"title":149,"excerpt":150,"readTime":151,"views":18,"isPinned":19,"publishedAt":152,"updatedAt":21,"category":153,"categories":154,"featuredImage":29,"bgImage":30,"posterImage":156,"relatedSolution":29},229,"checklist-docker-compose-en-produccion",{"fr":146,"en":147,"ar":148,"es":144},"docker-compose-production-checklist","docker-compose-in-production-10-point-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","Docker Compose en producción: checklist de 10 puntos","Checklist de Docker Compose en producción: 10 ajustes esenciales, gestión de secretos sin downtime, copias de volúmenes sin corrupción, CVE-2026-17106.",8,"2026-08-06T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[155],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":158,"slug":159,"slugs":160,"title":164,"excerpt":165,"readTime":166,"views":167,"isPinned":19,"publishedAt":168,"updatedAt":21,"category":169,"categories":174,"featuredImage":29,"bgImage":30,"posterImage":176,"relatedSolution":29},224,"apps-self-hosted-rutina-de-parches",{"fr":161,"en":162,"ar":163,"es":159},"routine-correctifs-apps-self-hosted","self-hosted-apps-the-patching-routine","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","Aplicaciones self-hosted: la rutina de parches","Inventario, avisos de seguridad, ventana de parcheo, copia de seguridad y verificación: la rutina que falta en la mayoría de los parques self-hosted.",4,1,"2026-08-05T00:00:00+00:00",{"id":151,"name":170,"slug":171,"color":172,"icon":173},"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[175],{"id":151,"name":170,"slug":171,"color":172,"icon":173},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":186,"views":167,"isPinned":19,"publishedAt":187,"updatedAt":21,"category":188,"categories":193,"featuredImage":29,"bgImage":30,"posterImage":195,"relatedSolution":29},236,"automatizar-servidores-vps-con-ansible",{"fr":181,"en":182,"ar":183,"es":179},"ansible-automatiser-serveurs-vps","automating-vps-server-management-with-ansible","أتمتة-إدارة-خوادم-vps-باستخدام-ansible","Automatizar la gestión de servidores VPS con Ansible","Automatice la gestión de una flota de servidores VPS con Ansible: inventario, playbooks, roles y Vault para una infraestructura reproducible.",10,"2026-08-08T00:00:00+00:00",{"id":189,"name":190,"slug":191,"color":192,"icon":191},2,"Automatización","automatisation","bg-brand-action\u002F10 text-brand-action",[194],{"id":189,"name":190,"slug":191,"color":192,"icon":191},"\u002Fblog\u002Fcovers\u002Fansible-automatiser-serveurs-vps-poster.svg",1789665020018]