You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 likeparseable
pose different issues where volumes are mounted differently incompose
than 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 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:
docker compose
based stack, this includes running apostgres
,rabbitmq
,redis
, workers fortaskiq
docker compose
files for legacy / alternative approachalembic
orpsql
in the container itselfDescribe 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
The text was updated successfully, but these errors were encountered: