chore(repo-structure): Docker images and stacks organized and clarified

[rafaelromcar-parabol]

Description

Deletes all deployment related files that are not used and simplifies that management of all the kept files. This makes it easier to understand how the application can be deployed in different environments and also simplifies how we maintain our repository.

Cleaner things are easier things to maintain.

Important changes

• build.yml Github Action pointing to https://hub.docker.com/r/pgvector/pgvector/tags?page=1&name=pg15 instead of the unmaintained ankane/pgvector:latest.
• Unused files are gone.
• Docker tags latest are replaced with specific versions of the applications.
• New folder run-it to host the how-to run the application in different use cases. docker-compose files under it are built with the same format, to ease comparing them and keeping them up to date.
  • Single-tenant: moved from docker/parabol-ubi/docker-host-st, but same content.
  • Development: dev.yml is placed in its own folder with (almost) everything it needs and names of the services are equal to the ones on the single-tenant deployment.

Questions

• Should we use pgvector:pg15 or use our own built Docker image for Postgres as the one in docker/postrgres? We agreed on keeping pgvector:pg15 for now.
• What about the Postgres README? Adapt it so it only shows what relates to the app and nothing about running Postgres or PGAdmin
• What about the Postgres file cacerts? the file is empty and it is used on the readCert.ts. Leave it like it is for now.
• Why keeping two different pm2 files? What's the use case for yarn start right now? that's running it without any Docker. Testing after building? It is uses in test.yml. Do as DevOps like. pm2.config.js is only used in testing and for anyone running the app directly from the repository.
• Postgres json-schema extension is installed on the Docker container built, but it isn't installed on any other environment. What about it? Still required? Extensions supported by GCP CloudSQL Postgres

Validations

• Github Action build working.
• RethinkDB readme.
• Postgres readme.
• Application works using in development with yarn && yarn db:start && yarn dev with the default .env.example, following the instructions on the README.md.
• Application works using yarn && yarn build && yarn predeploy && yarn start with the default .env.example.
• Application runs using the single-tenant docker-compose deployment

[rafaelromcar-parabol]

Do you think the files pm2.dev.config.js and pm2.config.js should be on the root folder or inside the folder run-it/development? @mattkrick @Dschoordsch

Edit: if pm2.config.js is meant for production use (even if not by us), then why is the Embedder already added to it?

[rafaelromcar-parabol]

yarn start is found three times in our repository:

• On the main README as instructions to deploy the application. Should we remove it from there?
• On the README of the alternative license for the US Department of Defense, also to indicate how to build for production and start the application.
• In our test.yml for Github. We can keep it here no problem.

Should we create a new pm2.tests.config.js and have that used for testing and keep pm2.configs.js with only stuff that are 100% production ready?

[Dschoordsch]

Looks good to me. No issues in dev while testing locally.