<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker on Patrones — Exeal</title><link>https://patterns.exeal.com/tags/docker/</link><description>Recent content in Docker on Patrones — Exeal</description><generator>Hugo</generator><language>es-ES</language><lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://patterns.exeal.com/tags/docker/index.xml" rel="self" type="application/rss+xml"/><item><title>One build, many deploys para imágenes de frontend</title><link>https://patterns.exeal.com/patterns/runtime-env-config/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/runtime-env-config/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un frontend construido con Vite lee sus variables de entorno (&lt;code&gt;VITE_*&lt;/code&gt;) en tiempo de build: Vite las sustituye literalmente en el bundle. Eso significa que la URL de la API, el authority OIDC o el DSN de Sentry quedan &amp;ldquo;planchados&amp;rdquo; dentro del JavaScript compilado. Si quieres desplegar la misma app en &lt;code&gt;staging&lt;/code&gt; y en &lt;code&gt;production&lt;/code&gt; con distinta configuración, te ves obligado a construir una imagen por entorno — un pipeline de CI que hace build, build y build otra vez, cada uno con sus &lt;code&gt;--build-arg&lt;/code&gt;, solo para cambiar cuatro strings.&lt;/p&gt;</description></item><item><title>Tests de aceptación de backend sobre una imagen Docker ya construida</title><link>https://patterns.exeal.com/patterns/tests-aceptacion-sobre-imagen-docker/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/tests-aceptacion-sobre-imagen-docker/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un backend .NET no se despliega como código fuente: se despliega como imagen Docker. Entre el código que pasa los tests unitarios y la imagen que corre en producción hay una capa entera que ningún test contra el código fuente toca — el &lt;code&gt;Dockerfile&lt;/code&gt;, las variables de entorno que el contenedor espera recibir, si el puerto publicado es el correcto, si las migraciones corren al arrancar, si el healthcheck responde. Un &lt;code&gt;WebApplicationFactory&lt;/code&gt; o un test de integración que arranca la app in-process compila contra las mismas clases que ya se probaron, así que no puede detectar ninguno de esos fallos — están todos fuera del código, en el empaquetado.&lt;/p&gt;</description></item><item><title>Tests de aceptación de frontend sobre una imagen Docker ya construida</title><link>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un frontend construido con Vite y servido como estático (nginx) no se despliega como código fuente: se despliega como imagen Docker. Una suite de Playwright que arranca contra &lt;code&gt;vite dev&lt;/code&gt; o contra un build en el propio runner de CI no ejercita nada de lo que hay entre ese código y el artefacto real — el &lt;code&gt;Dockerfile&lt;/code&gt;, si nginx sirve las rutas de la SPA correctamente, si el entrypoint que inyecta la configuración en tiempo de arranque (ver el patrón de runtime env config) realmente deja la app apuntando a la API correcta. Todo eso puede pasar los tests unitarios y de componente y romperse solo en la imagen empaquetada.&lt;/p&gt;</description></item></channel></rss>