Is your feature request related to a problem? Please describe.
At present we use docker compose for our development experience. While this is completely fine, this is far removed from any of our deployment scenarios (which all use Kubernetes), further more integration of tools like parseable pose different issues where volumes are mounted differently in compose than what it would have been in K8s.
Given the major aim of containerised environments is consistency, the change suggestion here is to move away from using docker compose in development to align the stack closer to being in production.
Describe the solution you'd like
Initially propose and develop what a Kubernetes stack looks like? Points to consider here are:
We have moved away from Docker Hub to GHCR and is Docker Desktop still the optimal tool for running containers on macOS?
Provide a parallel solution that provides a one for one replacement for the docker compose based stack, this includes running a postgres, rabbitmq, redis, workers for taskiq
Ensure that ports can be exposed so all our development tools work the same
Ensure that volumes can be mounted for hot reload of python code
Provide a transition pathway (including documentation)
Maintain docker compose files for legacy / alternative approach
Ability to run tools like alembic or psql in the container itself
Describe alternatives you've considered
This is a migration process and at some point we did consider docker swarm but eventually settled for Kubernetes.
Additional context
Post the development of this, we will cease to use compose for any future projects.
See if kompose can do the trick as described in the documentation
Is your feature request related to a problem? Please describe. At present we use
docker composefor our development experience. While this is completely fine, this is far removed from any of our deployment scenarios (which all use Kubernetes), further more integration of tools likeparseablepose different issues where volumes are mounted differently incomposethan what it would have been inK8s.Given the major aim of containerised environments is consistency, the change suggestion here is to move away from using
docker composein development to align the stack closer to being in production.Describe the solution you'd like Initially propose and develop what a Kubernetes stack looks like? Points to consider here are:
docker composebased stack, this includes running apostgres,rabbitmq,redis, workers fortaskiqdocker composefiles for legacy / alternative approachalembicorpsqlin the container itselfDescribe alternatives you've considered This is a migration process and at some point we did consider
docker swarmbut eventually settled for Kubernetes.Additional context Post the development of this, we will cease to use
composefor any future projects.See if kompose can do the trick as described in the documentation