search

Seneca-CDOT / telescope

A tool for tracking blogs in orbit around Seneca's open source involvement
https://telescope.cdot.systems
BSD 2-Clause "Simplified" License
96 stars 189 forks source link

Give more options for starting a sub-set of our containers #3017

Open humphd opened 2 years ago

humphd commented 2 years ago

Telescope continues to grow, and as we add more services and sub-systems, the size of the the running containers is a lot for many people. Talking with @cindyledev tonight I had a thought.

We have a monorepo, with lots of moving parts. However, developing any one part often only involves a few of our sub-systems in order to run. For example, if I'm working on the web front-end, or if I'm hacking on the Dashboard, or a particular microservice.

We have a script, pnpm services:start, which runs all of our containers. It can also start just a subset: pnpm services:start sso posts.

I think we should define something like services:start in all of our sub-packages. So in src/web/package.json and src/api/sso/package.json and src/api/status/package.json, etc. If you're working on one of our sub-projects, we write a script that you can run in that sub-directory that will start only the containers you need, and nothing more.

If you run pnpm services:start in the root we can still run them all, but this way, we make it easy for devs to opt into the containers they need for a part of the project vs always having to run the whole thing.

The dependency graph can partially be defined in the docker-compose files via depends_on (e.g., sso depends on traefik), and the rest can be done via args to services:start container1 container2 ...

humphd commented 2 years ago

I also wonder if we could leverage https://code.visualstudio.com/docs/remote/containers and https://code.visualstudio.com/docs/remote/containers#_create-a-devcontainerjson-file to define our environment.