What is the suggested way to have a multi process app (Run Multiple Process Groups in an App · Fly Docs) with multiple domains? I.e. worker.example.com, example.com and api.example.com all in the same app? Is this possible without another reverse proxy underneath fly-proxy?
1 Like
If you just want multiple processes running somewhere I’d probably make separate apps and hook up the domains to each individual app. This is probably the most straightforward thing you could do, depending on your use-case - it sounds like you have a particular reason in mind to use one app though.
With one app running multiple processes, you need to do some of that routing work on your own, unfortunately.
There are a couple ways to do it, but I usually wind up setting up nginx to front everything if there’s a good reason to keep some processes tied to one app.
Just for my own curiosity is there a particular reason you’d like to avoid separate apps?
It’s a frontend and a backend and a worker, their versions are tied and a mismatch would cause failure. I haven’t found a good way yet to sync up multiple app deploys on fly.io, so we cope with the moments of downtime, but we have SLA stuff coming up that requires we transition smoothly.
Gotcha!
Hmm thinking on how to do that a bit. Are you booting these with the [processes] section or just starting several services on one VM as part of your app boot?
What kinds of failures do you experience? Brief mismatches in logic or can you share more about the failure scenario?
We just have two apps right now, scoping out how to do it better. We have a GraphQL API so failures are usually small, but if there are larger changes we sometimes have a desync period and it can cause some serious headaches.
We also have been stuck on pull request deploys for a while due to not being able to deploy our bits together, orchestrating putting multiple apps up for every PR has been a blocker.
Hi @endigma
Your best bet to improve resiliency would be if your backend could support both the new frontend and the old frontend, that way you could deploy your backend first, then your workers, then your frontend.
If it’s completely not possible then another strategy which I’ve seen mentioned by @ignoramous is to use a blue-green like strategy where you have two copies of every app (e.g. my-frontend-green, my-frontend-blue, my-backend-green, my-backend-blue), one set of apps is severing live traffic while the other set of apps is not.
You can then deploy your new versions to the apps that are not live, once the deploys are successful you can then swap the DNS entries to point to the updated apps. So essentially every production deploy would cause you to swap which set of apps is live.
This does require that your database/storage layer and backend accommodate both an old version and a new version so breaking changes in your database schema would need to be done over multiple releases to ensure the previous version of your backend (which would be the live version) doesn’t break.
3 Likes
I understand that supporting multiple frontend versions with the new backend version would be best, but we don’t have the capacity for this right now.
The blue-green strategy might work for production, but we still have the separate issue of pull request deploys.
I’m thinking we’ll end up with a 4th “nginx” process to handle traffic routing internally.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.