<h2>Por qué decidimos tener un registry in-house</h2><p>En un principio, como muchos proyectos que crecen rápido, quisimos tener todo bajo control. Montamos un <code>registry:2</code> dentro de nuestros propios servidores — una instancia interna de <em>Docker Registry</em> que alojaba todas las imágenes de nuestros microservicios. Al comienzo funcionaba bien: control total, rapidez en red local, sin depender de nadie. Pero lo que parecía ideal, empezó a mostrar su lado menos amable cuando crecimos y nos acercabamos a la apertura de la Season 7, con ello el refresh completo de la comunidad y todos sus microservicios.</p><h3>El costo oculto de cada push</h3><p>Cada imagen que subíamos tenía un costo asociado. Con la subida pasiva del dólar, cada build terminaba costando entre 0.10 y 0.15 USD por imagen mensual, considerando los layers y las distintas versiones generadas por entorno. Con <strong>más de 10 microservicios</strong> activos y builds constantes en <em>develop</em> y <em>main</em>, los costos de almacenamiento escalaron rápidamente. Y no solo era plata — también mantenimiento, limpieza de capas obsoletas, monitoreo del espacio, uptime del servicio y varias cosas más....</p><h2>Decisión: migrar a Docker Hub</h2><p>Evaluamos varias alternativas externas como Cloudflare Registry, DigitalOcean Container Registry, el de AWS, GCP, el de github, bueno... varios realmente, pero finalmente optamos por Docker Hub, el servicio oficial y mejor documentado <em>(bajo mi punto de vista)</em>. La migración fue más sencilla de lo esperado gracias a nuestra integración con GitHub Actions.</p><p>Solo tuvimos que cambiar el <code>registry base</code>, las <code>credenciales</code> y ajustar algunos pasos del flujo de build. Desde ese momento, cada push comenzó a publicarse directamente en nuestro nuevo registry externo. Y sí... perdimos las versiones iniciales, pero que realmente eran despreciables versus el ahorro que nos estaba generando.</p><h3>Fragmento de nuestro flujo de GitHub Actions</h3><p>Este es el bloque clave que permitió hacer el cambio casi sin fricción, ni deuda técnica:</p><pre><code class="language-yaml">
- name: Login to Docker Hub
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Build & Push
uses: docker/build-push-action@v6
with:
context: .
push: true
platforms: linux/amd64
tags: ${{ steps.meta.outputs.tags }}
cache-from: type=gha
cache-to: type=gha,mode=max
</code></pre><p>Este bloque automatiza el build y publicación de cada imagen. Además, usamos metadatos y control de versiones por tags, lo que nos permite mantener builds consistentes en <em>develop</em> y <em>main</em> sin duplicar trabajo.</p><h2>Resultado: menos costos, más foco</h2><p>Después del cambio, los costos se redujeron de inmediato. Dejamos de preocuparnos por la infraestructura y mantenimiento del registry, y pudimos dedicar ese tiempo y recursos a lo que realmente importa: mejorar la experiencia de nuestros jugadores y optimizar nuestros microservicios.<br>Pasamos de gastar cerca de 70 USD mensuales (y en aumento) a mantener un costo fijo de aproximadamente 16 USD mensuales. </p><p>Nuestro sistema de despliegue interno sigue recibiendo las imágenes desde Docker Hub, asegurando un flujo CI/CD limpio y transparente.</p><h2>Qué aprendimos</h2><ul><li><p>A veces, externalizar un servicio no es una pérdida de control, sino una ganancia de eficiencia (y de costos).</p></li><li><p>Un par de centavos por imagen parecen poco, hasta que multiplicas por versiones, entornos y microservicios.</p></li><li><p>Automatizar bien es clave: si tu pipeline está sólido, migrar es cuestión de minutos, no días... y esto nunca estuvo planificado, como dirían por ahí fue "un cueazo". </p></li></ul><p>Esto nos reafirmó que en el Desarrollo, la optimización no siempre es técnica, hay veces que también es estratégica. Muchas de estas cosas quedan reservadas en algunos desarrolladores o administradores de comunidades y esto les puede permitir tomar decisiones que les puede ayudar a iniciar más rápido.</p>
