Hi there, I'm trying out Pants to create a monorep...
# general
f
Hi there, I'm trying out Pants to create a monorepo. Previously, for my FastStream applications, I ran migrations in the Docker files using:
Copy code
CMD alembic upgrade head & uvicorn app.main:app
Now, inside the monorepo, should I have a separate build for each Alembic migration within each app, or is there a better approach?
Inside the monorepo, the structure looks like this:
Copy code
monorepo
├── .pants.d
├── dist
├── src
│   ├── docker
│   │   ├── app1
│   │   └── app2
│   └── python
│       ├── core
│       └── services
│           ├── app1
│           │   └── alembic
│           └── app2
│               └── alembic
e
A good answer will probably depend on how you use your database. • Do all apps use the same database? • Do you use a single database server with separate databases for each app? • How do you run your app? (eg. do you deploy all your containers into k8s or something else) My gut instinct is that you typically should have a "migration container" that runs all your migrations and gets your database into the right state, and then your regular apps can just assume the database is correct and ignore anything to do with migrations. Could you share more info about your situation?
f
sure , I use a single database server with separate databases for each app, and I run each app in Azure Container Apps
The apps are isolated from each other but use a common utility code in the monorepo
e
I don't know a lot about Azure Container Apps, but assuming it has some concept of an "init-container" (or other means of making some containers wait to run until others have completed): I think (emphasis on think) that you'd probably be best off with: • build a migration container (or more generically, a db-init container if its going to do user/permission setup and stuff too.) • build an application container (this can avoid needing alembic and related dependencies now) • on deploy: ◦ Run appX-db-init ◦ Run appX • This leaves you free to upgrade/redeploy your app with guarantees that you aren't touching the databsae migrations unless you need to. • You probably have smaller images since less dependencies are needed • Hopefully, this is more debuggable too, since migrations and app code are in separate containers with separate logs/error reporting YMMV, especially depending on how much these are quick small apps, vs. enterprise-grade type stuff. This is how my team has been working, and its been pretty good for us. (Using helm charts to coordinate and run in k8s)
f
Azure Container Apps is a service that provides simpler APIs to Kubernetes; under the hood, it’s just Kubernetes. I’m probably going with the init container since it looks like a straightforward approach. I appreciate the assistance!
e
no problem! Good luck with everything