Is Fly suitable for dynamic container-per-customer?

1

Hi, I have an unusual use case, and am wondering if Fly can help with it.

My company runs online coding classes. We give students access to “virtual machines running Ubuntu” that are actually Docker containers running Ubuntu with a VNC server that can communicate to a client on our website. Every student gets their own “VM”, and we try to semi-automate scaling of our servers when classes are starting.

Fly seems to have some big advantages here: Firecracker offers better security over Docker, we don’t have to worry about my ugly terraform code trying to scale up/down when classes are (which isn’t necessarily when students are using it), and the free HTTPS (which we have but it’s kludgey).

However Fly seems to assume (reasonably) that one app suits all customers. I think for Fly to work for us I’d have to maybe automate the creation of Fly apps, one per customer, and with a max instance of 1 and min of 0? Is this a crazy idea, or is there a better way to do it?

For what it’s worth, I’d be looking at hundreds of these Ubuntu machines spun up at a time, max.

2

There are two things here:

  1. VM per customer. Right this second, you’ll need an app per customer to do this. It’s not a bad idea! We have some tooling coming that will let you launch specific VMs per customer within the same app that might help.
  2. Getting them connected. If you run one app per customer, they’ll each get their own IP/Hostname to connect to when you enable a [service] in the config. If you run multiple VMs in a single app, though, you’ll need to build a little proxy to make sure they connect to the right one.

Do they connect over TCP to the VNC server?

This is a use case we’d like to handle well, so there’s nothing wrong with your idea. Our tooling is not quite there but you can still make it work.

1 Like
3

Multiple VMs per app seems complicated - I assume I’d need to do something like this: Running Multiple Processes Inside A Fly.io App - and do multiple users in the Ubuntu container.

In an ideal world I think I’d have one-app-per-customer, with some kind of routing so I didn’t need a hundred different IPs. Something like customer1.myvmservice.fly.dev. I don’t think that’s possible on fly.io right now - each app gets an IP, right?

They do connect over TCP - our containers are something similar to this, where VNC traffic is accessible via a web browser: GitHub - fcwu/docker-ubuntu-vnc-desktop: A Docker image to provide web VNC interface to access Ubuntu LXDE/LxQT desktop environment.

1 Like
4

Multiple VMs per app is very complicated … right now. :wink:

Each app does get a different IP. How would you differentiate between VNCs? If they work over SSL you could do SNI routing, I think. You could have one “router” app and deploy a bunch of separate apps with no [[services]] block on the same organization, then route to them over private networking.