Tema: deployment
-
¿Qué reglas de retención de imágenes mantienen pequeño un registro de contenedores sin eliminar imágenes que todavía están desplegadas?
Pregunta abierta: los registros solo recolectan como basura los blobs que ningún manifiesto referencia, y las políticas de ciclo de vida caducan imágenes por antigüedad, cantidad o patrón de etiqueta; ¿qué combinación de reglas han ejecutado los equipos durante años sin crecimiento ilimitado ni una reversión que fallara porque su imagen había desaparecido?
-
¿Qué estrategia de despliegue funciona en un único host con Docker Compose y proxy inverso?
Pregunta abierta: los despliegues rodantes (rolling), blue-green y canary están descritos para orquestadores; pero muchos servicios pequeños se ejecutan en un único host con Docker Compose detrás de Traefik, nginx o Caddy. ¿Qué imitación de esas estrategias —un segundo contenedor con la regla del proxy conmutada, distribución ponderada del tráfico, arranque «start-first»— han mantenido los equipos en producción durante meses, qué se ha roto con ellas, y a partir de qué tamaño compensa pasar a un orquestador?
-
Etiquetas y releases: etiquetas ligeras frente a etiquetas anotadas y cómo se propagan
Una etiqueta ligera es solo un nombre para un commit; una etiqueta anotada es un objeto con quien la crea, la fecha, un mensaje y, opcionalmente, una firma, razón por la cual git describe ignora las etiquetas ligeras de forma predeterminada y por la que los releases deberían usar etiquetas anotadas o firmadas; las etiquetas no se envían junto con las ramas a menos que se use --follow-tags o --tags, y una etiqueta ya publicada nunca debería moverse.
-
Apagado ordenado: gestión de SIGTERM en los servicios
Los entornos de ejecución de contenedores envían SIGTERM y esperan un período de gracia antes de SIGKILL; un servicio debe dejar de aceptar trabajo nuevo, terminar o devolver el trabajo en curso, cerrar las conexiones y finalizar dentro de ese período. Ignorar la señal convierte cada despliegue en una interrupción del servicio.
-
Diseñar la reversión antes del despliegue
Redactar un árbol de decisión de recuperación antes del despliegue, distinguiendo los cambios de configuración reversibles de las migraciones de datos que necesitan compensación.
-
Cambios en la base de datos sin interrupción: expandir y contraer
Modificar un esquema en tres pasos desplegables por separado: expandir (crear una columna o tabla nueva y conservar la antigua), migrar (escribir por duplicado y rellenar en lotes pequeños), contraer (eliminar lo antiguo en cuanto todo el código use lo nuevo); evitar bloqueos largos no reescribiendo ninguna tabla en una sola sentencia, y limitando toda espera con lock_timeout.
-
Cambios de comportamiento en canario antes del despliegue
Exponer a una cohorte acotada a un comportamiento nuevo, compararlo con una línea base y detenerse según condiciones de fallo declaradas de antemano.
-
Modo de mantenimiento de solo lectura: servir lecturas mientras las escrituras están pausadas
Para traslados de almacenamiento, conmutaciones por error y migraciones largas, un servicio puede seguir sirviendo lecturas y rechazar las escrituras con un mensaje claro en lugar de quedar fuera de servicio; default_transaction_read_only de PostgreSQL hace de las nuevas transacciones transacciones de solo lectura a nivel de base de datos como respaldo, y el 503 de HTTP con Retry-After indica a los clientes cuándo volver a intentarlo. El modo necesita un único interruptor, un mensaje visible para los usuarios y un ensayo.
-
Despliegues rolling, blue-green y canary comparados
Las actualizaciones rolling reemplazan las instancias de forma gradual dentro de unos límites de exceso e indisponibilidad; blue-green ejecuta la pila nueva completa junto a la antigua y conmuta el tráfico de una sola vez; canary envía una pequeña parte del tráfico real a la nueva versión y la promueve según la evidencia. La elección depende de la capacidad, la velocidad de reversión y de si dos versiones pueden servir al mismo tiempo.
-
La aplicación de doce factores como lista de verificación para servicios
Los doce factores describen convenciones para servicios desplegables: una única base de código, dependencias declaradas, configuración en el entorno, servicios de respaldo como recursos adjuntos, separación estricta entre build, release y run, procesos sin estado, y registros como flujos de eventos.
-
Gestionar los secretos fuera del repositorio
Las credenciales pertenecen a una configuración protegida inyectada en tiempo de ejecución, nunca al control de versiones, a las imágenes ni a los registros; rotarlas según un calendario y ante cualquier sospecha, y dar a cada servicio las suyas propias.
-
Promover un mismo build a través de los entornos: promoción de configuración y paridad entre desarrollo y producción
Construir un artefacto una sola vez, darle una identidad inmutable y promover ese artefacto exacto desde pruebas a staging y a producción, cambiando solo la configuración específica de cada entorno; mantener los entornos similares en servicios de respaldo y topología, para que superar una etapa permita predecir la siguiente.
-
Las migraciones de esquema ejecutadas con un lock_timeout corto y reintento automático causan menos incidentes en el momento del despliegue que las migraciones sin él
Hipótesis: dado que la mayoría de las formas de ALTER TABLE toman un bloqueo ACCESS EXCLUSIVE que se pone en cola detrás de cualquier transacción larga mientras bloquea toda consulta posterior, las migraciones ejecutadas con un lock_timeout de unos pocos segundos y un bucle de reintento acotado producen interrupciones más cortas y menos frecuentes en el momento del despliegue que las mismas migraciones ejecutadas con la espera ilimitada por defecto, al costo de que algunas migraciones necesiten una reejecución manual.
-
Desplegar un service worker de forma segura: alcance, cachés versionadas, el worker en espera y un interruptor de emergencia
Un service worker que almacena en caché el HTML puede dejar a los usuarios atados a código antiguo tras un despliegue. Registrarlo con un alcance explícito, obtener el script actualizado en cada comprobación de actualización, versionar las cachés por compilación y eliminar las antiguas en activate, elegir estrategias por tipo de recurso, decidir cómo toma el control el worker en espera, y entregar un interruptor de emergencia probado antes del primer lanzamiento.
-
¿Qué comprobaciones previas al despliegue han detenido realmente una versión defectuosa en el último año, y cuáles nunca se han activado?
Pregunta abierta: las canalizaciones (pipelines) acumulan controles (pruebas, escaneos, comprobaciones de humo, análisis canario, aprobaciones manuales, plazos de despliegue), y la documentación de Kubernetes señala que un Deployment estancado solo se reporta, no se revierte; qué controles tienen un historial de haber detenido una versión defectuosa, cuáles nunca se activaron, y cuáles solo se activaron por falsos positivos.
-
Feature toggles: tipos, ciclo de vida y limpieza
Los toggles desacoplan el despliegue del lanzamiento, pero cada toggle es una bifurcación en el código; se clasifican según su propósito (de lanzamiento, de experimento, operativos, de permiso), y a cada uno se le asigna una persona responsable y una fecha de eliminación.
-
Cambios de esquema sin tiempo de inactividad con expandir y contraer
Cambiar un esquema en tres pasos desplegables: expandir (añadir la columna o tabla nueva, conservar la antigua), migrar (escritura doble y relleno retroactivo por lotes), contraer (eliminar lo antiguo una vez que todo el código use lo nuevo); se evitan los bloqueos largos al no reescribir tablas en una sola sentencia.
-
Construir imágenes de contenedor pequeñas y reproducibles
Fijar las imágenes base por digest, instalar desde lockfiles con verificación de hash, copiar solo lo que necesita el runtime, ejecutar como un usuario sin privilegios, añadir una comprobación de salud, y mantener los secretos fuera de las capas y de los argumentos de compilación.
-
Etiquetas frente a digests en imágenes de contenedor: nombres mutables y direcciones de contenido
Una etiqueta es un puntero legible para humanos que puede moverse a un manifiesto distinto en cualquier momento; un digest es el hash de los bytes del manifiesto e identifica exactamente una imagen para siempre. Conviene construir y probar por etiqueta, pero desplegar y fijar por digest, y registrar el digest en cada nota de release.
-
Ejecutar un servicio con systemd
Un archivo de unidad declara cómo se inicia, se reinicia y se confina un servicio; usa Type, Restart=on-failure, límites de recursos y directivas de aislamiento, y lee los logs con journalctl en lugar de escribir tu propia daemonización.
Legible por máquina: JSON