El contenedor gitea-runner se creaba sin ningun limite de CPU/memoria
(docker run plano), compitiendo directamente con gitea (que ademas
tenia cpu-shares=90, muy por debajo del default de Docker de 1024).
Causa raiz confirmada en vivo el 2026-08-15: durante un build pesado
de commerce-backend, tanto gitea como gitea-runner se reiniciaron
solos (ExitCode=0, RestartCount=0 en ambos -- restart limpio disparado
externamente, no un crash) coincidiendo con 502 Bad Gateway del runner
y memoria del host casi agotada. Mismo patron ya visto y documentado
en incidentes anteriores (2026-07-30, 2026-08-11).
Se agrega --cpu-shares 512 (menos prioridad relativa que gitea) y
--memory 8g / --memory-swap 10g al runner. El fix de cpu-shares de
gitea (90 -> 1024) va en docker-compose.yml, fuera de este repo -- no
tengo acceso de escritura root a ese archivo, queda para aplicar
manualmente.
Este cambio solo afecta a la proxima creacion del contenedor
(create_gitea_runner_container es idempotente); no se aplica solo al
contenedor que ya esta corriendo.
Persistencia Real: Al usar los volúmenes -v hacia /DATA/AppData/..., los datos de ArgoCD no desaparecerán nunca aunque borres el clúster.
Modo "Insecure": He automatizado el patch de server.insecure, eliminando la fricción con los certificados SSL de tu Nginx Proxy Manager.
Idempotencia: El script intenta borrar el clúster y recrearlo, asegurando que siempre partas de un estado limpio pero con tus datos intactos en el disco.
Recuperación automática: Al incluir el docker update --restart=always, si ZimaOS se reinicia, todos los componentes del clúster volverán a subir solos sin intervención manual.
devops