#6 I'm going to give it a try
1º esto es correcto? todos los contenedores en la misma maquina, hay perdida de rendimiento así?
Si tienes todas las aplicaciones en contenedores te da igual si corren en una o N maquinas, la idea es acabar teniendo algo a donde subir el contenedor/imagen y que te abstraiga del "metal"
2º que paquete npm o que es lo que se usa como api gateway, o como se monta eso?
Lo mejor es saberse bien estos dos conceptos, ya que van a ir muy de la mano
https://microservices.io/patterns/apigateway.html
https://microservices.io/patterns/server-side-discovery.html
Al final el API Gateway es el encargado de "enrutar" todo el tráfico a los distintos MS, cosas como el service discovery ayudan, además de proveer cosas como load balancing.
Hay muchos frameworks/herramientas para hacer API Gateway, desde Zuul (JVM based), Nginx, o incluso un servicio de Node con express que haga esta labor.
3º que usamos para exponer fuera la ip del gateway? o de cada uno de los servicios.
La idea es que todo el tráfico pase a través del gateway, por lo que el resto de los servicios no deberían de ser públicos, o que tengas una manera en el momento de crear un MS que te permita decidir si es público o no.
En mi empresa por ejemplo se configura en un yml, ahí decides la url si quieres que sea público, por defecto solo es accesible desde dentro.
4º que papel juega nginx? es lo de la api gateway?
nginx puede actuar de API Gateway, pero no sé cómo podrías implementar service discovery usando nginx (según ellos, se puede).
5º todos los módulos van con su contenedor/imagen de docker no? y las bbdd también
No sé a qué te refieres con módulos en este contexto, ten en cuenta que en diferentes lenguajes la palabra módulo tiene diferentes significados.
Lo suyo es que cada aplicación tenga la configuración necesaria para poder crear una imagen de docker con el código de la aplicación y cualquier dependencia (interna, vease node y node-modules).
Cualquier dependencia externa (DB, Redis, kafka), las puedes declarar con docker-compose para que en tiempo de desarrollo puedas levantar los diferentes contenedores.
Para esto necesitarás una configuración diferente dev/prod (donde le digas la url donde encontrará la DB y el resto de dependencias externas)
6º si se compone todo esto en un solo contenedor, las peticiones van solo a ese contenedor? o a los subcomponentes que lo forman, es decir, perdemos rendimiento al juntarlo todo en un contenedor con docker compose?
En un contenedor solo deberías tener la aplicación y si tuviera alguna dependencia nativa (algún módulo para procesado de imagenes, etc), el resto debería ir cada uno en su contenedor. En el registro de docker tienes imágenes de casi todos los tipos (contenedor basado en Alpine Linux con postgresql XX.XX, mysql, redis, kafka, lo que quieras)
Esas las defines en el docker-compose y cuando quieras probar en local levantas docker-compose up y levantará tantos contenedores como dependencias tenga.
7º como montar esto en local? tengo linux, instalo el nginx y las imagenes de docker en la terminal y ya está o tengo que crear una maquina virtual?
Creo que esto ya está aclarado en los puntos anteriores, pero vamos, la idea es que en local levantes el docker-compose y listo.
