@saulwade/swl-ses 2.2.4 → 2.3.0

package/habilidades/contenedores-docker/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contenedores-docker
 description: Docker y containerización. Dockerfiles optimizados con multi-stage builds, docker-compose, volúmenes, networking, health checks, security scanning, build caching, distroless images. Anti-patrones comunes.
-version: "1.0.1"
+version: "1.0.2"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para orquestación Kubernetes (Deployments, Services, Helm, HPA) — para Kubernetes cargar `kubernetes-orquestacion`."
@@ -137,3 +137,5 @@ Para ejemplos completos de multi-stage Node.js/Angular, .dockerignore, docker-co
 **`.dockerignore` mal configurado incluye archivos `.env` o `node_modules` en el contexto de build, ralentizando el daemon y exponiendo secretos**: si `.dockerignore` no existe o no excluye `node_modules`, el contexto de build puede ser de cientos de MB — todo se transfiere al daemon antes del build. Causa: el contexto de build incluye todo el directorio por defecto. Fix: crear `.dockerignore` con al menos `.git`, `node_modules`, `__pycache__`, `.env*`, `*.pyc`, `dist`, `build`, y verificar el tamaño del contexto con `docker build` mirando la línea "Sending build context to Docker daemon X.XX MB".
 
 **Scripts en `database/init/` (mounted a `/docker-entrypoint-initdb.d`) no pueden depender de binarios fuera de la imagen base**: un script con `set -e` que invoca `mc` (cliente MinIO), `aws`, `gh`, `kubectl` o cualquier binario no presente en la imagen `postgres`/`postgis` aborta el initdb con `command not found` (exit 127). El contenedor sale con error y los scripts SQL que iban después (incluido schemas/seeds completos) NUNCA se ejecutan. Caso real (SIGM 2026-05-04): `02-crear-buckets-minio.sh` con `mc alias set` aborta `postgis/postgis:17-3.5` antes de cargar el schema; ningún schema se aplicaba aunque el archivo init.sh estaba bien. Causa: el directorio `/docker-entrypoint-initdb.d` ejecuta todos los archivos `.sh` y `.sql` en orden alfabético; cualquier fallo aborta toda la cadena. Fix: scripts que invocan binarios externos van en `scripts/setup/` o `scripts/init-deps/` y se ejecutan manualmente o via `docker compose run --rm --entrypoint /scripts/setup/X.sh <servicio_que_tiene_el_binario>`. Solo SQL puro o bash que use `psql` pueden vivir en `database/init/`.
+
+**`docker exec ... psql` lanzado en background contra una BD donde el rol no autentica cuelga y congestiona el subsistema `docker exec` de Docker Desktop (Windows)**: lanzar en background (`run_in_background`/`&`) un `docker exec <contenedor> psql -U rol -d db -c "..."` donde el rol no puede autenticar deja la sesión `exec` colgada esperando; varias de esas sesiones huérfanas **saturan el subsistema de `docker exec`** y luego TODO `docker exec` (incluso `echo`) y hasta `docker restart` hacen timeout, aunque `docker ps`/`version` sigan respondiendo. Causa: cada `exec` abre una sesión que no termina; el daemon las acumula. Síntoma distintivo: `docker ps` responde pero cualquier `docker exec` cuelga. Fix: `docker restart <contenedor>` mata las sesiones `exec` huérfanas y destraba el daemon — detener el bash local con TaskStop NO mata el `psql` que corre dentro del contenedor. Prevención: NUNCA lanzar `docker exec ... psql` en background contra una BD/rol cuya autenticación no esté confirmada; correrlo en foreground con timeout corto y verificar el `psql` interactivo primero. En Git Bash (Windows), pasar `MSYS_NO_PATHCONV=1` cuando el comando lleva rutas POSIX (`/tmp/...`) a `docker exec`/`docker cp` para que MSYS no las convierta.