[hruk]

Yes, we use this setup for two "branch" services. It is pretty easy to get going, but setting things up to achieve zero-downtime deploys requires a little thought.

We're using ECS to manage our containers. What worked best for us is two task definitions, one daemon with only Litestream, another replica task with our web app. The web app task has a placement rule ensuring that Litestream has started before it can be placed, ensuring the database is "in place" before the app starts. Both containers have the same directory on the host mounted as volumes, so they can both access the same database. This series of tests convinced me that this is a safe setup: https://tangentsoft.com/sqlite/doc/trunk/walbanger/README.md

This has been working well for us - the db is fast, we can deploy whenever we want, and I don't feel anxious about the host going down.

One remaining source of anxiety is updating the machine image of the host - that will cause some downtime, of course. I think the safest strategy will be to increase the size of the ASG the host is in to warm up a second, updated EC2, then drain the first one.

[raro11]

I was about to explore sqlite/litestream but didn't because we have two services (cron and admin-web) that write to the database. Regular www-web services are read-only.

We only have one instance of cron and admin-web. We could make sure they are always on the same host. So reading this made me happy.

Do you have a blog/gist where I can find/steal some of your work?

[hruk]

I do not - however, I keep meaning to write up a generic version of our CDK code for sharing/reuse. I'll make a post here when I do.

[raro11]

Thank you

[gketuma]

Are you using EFS to share the DB between containers?

[hruk]

No, we're using EBS with Docker volumes, since all the containers are running on the same host.

SQLite actually performs very poorly on EFS in my experience (likely due to the fact that acquiring file locks is over the network).