Saltar al contenido principal

wiki-home

Ver en Git

home

  • sentry: https://logs.auravant.com/organizations/auravant/issues/?project=81&statsPeriod=14d

  • El mfe_manager es el servicio que:

  • API:

  • recibe desde el CICD de cada microfrontend el build del commit para hacer el seguimiento de las versiones. Crea la nueva versión del microfrontend y sube el build a s3.

  • Tiene el back de la consola de microfrontends, con la que se administran los deployments. Acá se hace el ABM de microfrontends, proyectos y se administra el versionado.

  • Es el servicio de discovery de la nueva arquitectura. La arquitectura cuando arranca le consulta a este servicio qué versiones de cada microfrontend debe cargar.

  • Script

  • Sincroniza s3 con el servidor que sirve el contenido estático

  • Está compuesto de dos partes, la API http y el sync_script

  • Todo corre en el server front (10.0.18.165) diagrama: https://excalidraw.com/#json=fUbLMVJooODI3WtVxQKi9,Kn1lqEV4zd7_w6Oc1VxGjA (Está el excalidraw completo entre los archivos de documentación)

  • Los 3 puntos de la API idealmente deberían estar separados, para poder escalar independientemente. Además, no está bueno que el procesamiento de los commits se haga en el mismo lugar que la consulta de discovery, siendo que de esta última depende el funcionamiento de la arquitectura. Sin embargo por simplicidad y por la escala, se deployaron juntos

  • Se pretendía que el manager estuviera en ECS, pero implica configuraciones que no pudimos resolver. Como usa s3, cada servidor debe tener una ip pública, y con larry no pudimos hacerlo andar. Entonces se puso en el server front.

  • El código buildeado de cada mFE está en S3. Servirlo a los clientes desde s3 resulta muy caro, entonces se puso un servidor con un apache que sirve el contenido estático. Para sincronizar s3 con el disco del servidor se usa el sync_script. El script cada cierto tiempo ejecuta un comando de la CLI de aws que sincroniza un bucket con el disco. Entonces todo cambio que se haga en s3, eventualmente llega al disco. Además, el script está suscrito a un pub/sub de redis en el cual la API que recibe los commits publica avisos, de modo que ni bien se sube un nuevo commit a s3, el script lo baja a disco.

peligro

No tenemos una política de borrado de archivos, por lo que cada tanto habría que borrar de s3 para no llenar el disco del servidor. Hay que implementar una policy en s3 o automatizar e incluirlo en el script

  • Hay que implementar una policy en s3 o automatizar e incluirlo en el script.
  • El código descargado está en /var/www/microfrontends/.
  • El apache del server de front tiene reglas sobre qué ips pueden acceder a cada directorio. Eso se puede ver en el archivo /etc/apache2/sites-available/100-microfrontends.conf. (Para entender por qué esto, ver la documentación del feature)
  • Todo el front se hostea en microfrontends.auravant.com. Esta regla está en el loadbalancer. Si se quieren agregar funcionalidades que impliquen login, habrá que agregarla para los demás tenants también.
aviso

To-Do:

  • Las apis de administradores tienen el viejo sistema de sudo. Hay que reemplazarlo por la consulta a la BD para determinar que tenga permiso para deployar mfes.
  • armar un dns interno