Skip to content

PM2 Replacement

Jump to bottom
Danilo Hoffmann edited this page Sep 25, 2023 · 1 revision

PM2 replacement

Motivations for Replacing

  • Current setup violates the "one process per container" rule
  • Operations doesn't look inside SSR containers so issues cannot be tracked easily
  • Independence from PM2

Tasks PM2 is handling at the moment

  1. run multiple themes in one container

  2. distribute incoming tasks to right process

  • page request by theme matrix parameter
  • file requests by checking local folders

  1. deploys a prometheus aggregator

  2. restart processes when exceeding memory limit (faster restarts than orchestrator but requires fine tuning often not done in projects)

  3. provides an easy way to setup thin multi-theme deployments using docker compose or CaaS INT and UAT.

Solution: Modified CaaS Setup

Task 1

Intershop Helm Charts will generate one SSR deployment per theme. The nginx container could then just have multiple UPSTREAM_PWA like:

  UPSTREAM_PWA: |
    b2c: my-release-pwa-main-b2c
    b2b: my-release-pwa-main-b2b
    ...

Each SSR container will have code for all themes in it, but only the code for the theme it is responsible for will be run as a single process.

Tasks and Complexities

  • extend Intershop PWA charts
    • additional property to provide a list of themes and generate deployments and services (L)
  • extend nginx container to handle multiple upstream servers (one per theme)
    • config could be supplied in YAML or JSON, use gomplate data source (M)

Task 2

The nginx container will know which SSR container to forward the request to by checking the theme matrix parameter.

As the PWA docker container will still have all themes in it, the request for files can be forwarded to any container.

Tasks and Complexities

  • assign correct upstream server based on theme matrix parameter in nginx config (S)
  • find a way to forward file requests to any SSR container (round robin) (S)
  • find a way to serve all files from all themes in one SSR container (M)
    • in server.ts use multiple BROWSER_FOLDER with express static? Remove BROWSER_FOLDER and scrape folders?

Task 3

The Helm Charts will deploy the prometheus aggregator as an additional container to the SSR container. The SSR container will then be able to access its personal aggregator via localhost.

Tasks and Complexities

  • investigate if the SSR container can access an aggregator via localhost (S)
  • adapt configuration of PR feat(pwa): monitoring with grafana to find all new aggregators (M)

Task 4

Memory management and limiting will be handled by the orchestrator. The orchestrator will be able to restart the SSR container when it exceeds its memory limit. Standard CaaS monitoring already monitors memory usage.

Tasks and Complexities

  • documentation (S)

Task 5

Docker compose files also need multiple ssr services (one per theme). Configuration could be shared using YAML anchors. It is also possible to write a script that generates the compose files. As an alternative way: local deployments can also be easily done with a local Kubernetes cluster. Documentation can solve this.

Tasks and Complexities

  • documentation (M)
  • script to generate compose files (L)

Summary

L M S
# 2 4 4
days per task 3 1 0.5
total days 6 4 2
total 12

This is only a rough and probably exaggerated estimate. It accounts for getting familiar with the used technologies and also for unclear tasks, that might not be possible as envisioned.

Clone this wiki locally