[FEAT]: Optimize Docker

[ImBIOS]

📈 What's Improved?

• Use clippy instead of clippy-preview, it's more stable and works properly for this project.
• Add the --no-cache flag to the npm install command to avoid storing the package cache in the Docker layer.
• Cleans up the package cache after installing with apt-get.
• Use postgres:12-alpine instead of postgres:12 to save up to 200 MB of image size
• Add comments with notes and todo to explicitly tell contributors about the current condition and flow of the code
• Add ImBIOS and use Dynamic Profile Image URL to automatically sync profile image with current contributor profile image (@griffobeid @darioalessandro I recommend this automated alternative: https://allcontributors.org/)
• Use vscode's .devcontainer feature for better developer experience and local-first development.
• Ignore unused dir into .dockerignore
• Compile tailwindcss for production in trunk hook
• From ~4 GB of total containers, reduced to ~1GB of total container size (-75%)
• Format README.md with markdownlint

✅ Objective

### Mandatory
- [x] Able to build production docker containers with multi-stage build technique
- [x] Production docker containers with multi-stage build technique running properly
- [x] Able to build development docker containers
- [x] Development docker containers running properly
- [x] Document on how to run production containers
- [x] Document on how to run development containers

### Optional
- [x] Able to run Dev Container

[ImBIOS]

The first step of #68

[ImBIOS]

@griffobeid @darioalessandro I think it's ready for review now.

I think #71 and this PR should be discussed, what's the main purpose to achieve in this containerization? Are we going to combine dev and prod environment, or we will split it so each one optimized for each purpose?

[griffobeid]

@griffobeid @darioalessandro I think it's ready for review now.

I think #71 and this PR should be discussed, what's the main purpose to achieve in this containerization? Are we going to combine dev and prod environment, or we will split it so each one optimized for each purpose?

I think we can have them both together in the same Dockerfile and optimize for each purpose simultaneously by using multi-stage builds. I like to use three stages, development which contains all of the development resources, build which inherits from the development container but also contains the source code, and finally, the production container which is just a slim OS image and any system-level dependencies that the application requires.

I prefer this approach because we have fewer Dockerfiles to update which can often lead to dev and production Dockerfiles going out of sync on some versions.

So I guess the ask is could you reduce the number of Dockerfiles and also docker-compose yaml files? I would prefer to have 1 docker-compose.yaml and a single Dockerfile for each application

[ImBIOS]

@griffobeid I love your idea ⭐

I just need to sync and cook that idea, my current progress, and the current main branch containerization progress.

It'll be great developer experience to have a maintainable source code 👍

[darioalessandro]

Hey @ImBIOS thank you so much for your contributions!

1. would it be possible only to merge the docker-compose changes for dev purposes? We are using helm in prod with a different set of Docker images.
2. Can we split this PR into smaller PRs? I saw some changes that confused me like a vscode config file I think?

[griffobeid]

Hey @ImBIOS are you still working on this?