Introducing Docker Compose for Enhanced Development Experience

[teamchong]

This pull request introduces Docker Compose to the existing Docker setup:

• Added a docker-compose.yml file to simplify container orchestration and environment setup.
• Ensured proper volume binding and environment variable management with Docker Compose.
• Modified wiki.md to guide users on utilizing Docker Compose and the flexibility it offers, such as changing the default online_log/app.py.

This PR aim to further enhance the developer experience, making it easier for new users to get started.

Feedback and testing are welcome.

[Bioblaze]

Good changes, just a slight redundancy with the .env.sample. Just leave it as .env

this is a bad idea, most .gitignores should have .env by default. having .env.sample or even sample.env would be good to have, legit for the long run. When your running in production or development environments for teams and such.

[ManindraDeMel]

Good changes, just a slight redundancy with the .env.sample. Just leave it as .env

this is a bad idea, most .gitignores should have .env by default. having .env.sample or even sample.env would be good to have, legit for the long run. When your running in production or development environments for teams and such.

This is a good point, but I've never seen an env.sample or sample.env used personally. the environment can just be defined in the documentation

[Bioblaze]

Good changes, just a slight redundancy with the .env.sample. Just leave it as .env

this is a bad idea, most .gitignores should have .env by default. having .env.sample or even sample.env would be good to have, legit for the long run. When your running in production or development environments for teams and such.

This is a good point, but I've never seen an env.sample or sample.env used personally. the environment can just be defined in the documentation

Well this isn't for the actual environment its more for storage in the repo, and then we add the different .env production.env, etc into the gitignore.

This way we can just use cp example.env .env and we can put our envs in there, and not worry about it ever accidently getting pushed. Cause you know someone is going todo it. Hell we all have done it at 1 point or another.

[ManindraDeMel]

Good changes, just a slight redundancy with the .env.sample. Just leave it as .env

this is a bad idea, most .gitignores should have .env by default. having .env.sample or even sample.env would be good to have, legit for the long run. When your running in production or development environments for teams and such.

This is a good point, but I've never seen an env.sample or sample.env used personally. the environment can just be defined in the documentation

Well this isn't for the actual environment its more for storage in the repo, and then we add the different .env production.env, etc into the gitignore.

This way we can just use cp example.env .env and we can put our envs in there, and not worry about it ever accidently getting pushed. Cause you know someone is going todo it. Hell we all have done it at 1 point or another.

Yeah, alright sure! I don't really mind it's a minor thing.

[cryptictech]

Good changes, just a slight redundancy with the .env.sample. Just leave it as .env

this is a bad idea, most .gitignores should have .env by default. having .env.sample or even sample.env would be good to have, legit for the long run. When your running in production or development environments for teams and such.

This is a good point, but I've never seen an env.sample or sample.env used personally. the environment can just be defined in the documentation

Laravel (docs) is a good example of .env.example (in their case) where the official instruction is to cp .env.example .env

[ManindraDeMel]

Please fix the conflicts