I’m trying to figure out the best way to spin up customer projects and each project requires multiple docker services with different images.
Option A
Create an app per customer project via GraphQL and then spin up a machine for each distinct docker image.
Option B
Create an app per service and then spin up customer instances of that service as machines nested under their respective apps. Will machines across apps be able to communicate using *.internal domains?
What’s the best way to architect this type of configuration?
Yes, but apparently one can carve out network namespace for a group of apps (in the same org) to isolate them away: Multi tenant applications - #23 by thomas
Yep, you can deploy different images (Machines) under a single Fly Machine app with its own env
, build
/ release_command
s, services
… if you’d continue to use the GraphQL APIs, then I don’t see why not. Except… public IP addresses (this might be a big deal) and secrets
(and may be a few other things that I can’t recall off the cuff) are common to all Machines of an app, which might be deal breaker.
These previous discussions may be of interest:
- Machines not responding to Non Standard Ports - #8 by dfragnito
- Machine Metrics Query and App Usage Report - #4 by kurt
- Machines + builder + private docker registry?
- Multi-region application where users / sessions are pinned to one region? - #3 by ignoramous
Thank you @ignoramous!
I’ll try the app per customer approach since I can isolate the app on its own network and keep each customer well encapsulated. I’ll use the API gateway image as the app image and it will delegate requests to the related machines with different images.
1 Like