Repository navigation
Desired use case聽#116
Description
Evening 馃憢
I stumbled across your project whilst planning to develop something which sounds very similar. I thought I'd let you know my intended use case, because it sounds like you may already be developing the solution I'm looking for.
My plan was to authenticate users using my existing Keycloak OIDC SSO, and then spin up a fresh code-server container.
User story:
- User navigates to a site and is prompted to login with OAuth.
- Once logged in, server automatically spins up a new container.
- A volume (whose name is based on the user's username) is mapped to the new container for data persistence.
- Container is exposed on a subdomain via a reverse proxy.
- Server redirects user to the unique subdomain.
A crude diagram in an attempt to illustrate this is below.
I'd be interested to hear if this sort of architecture matches what you're aiming to achieve.
No worries if not! :-)
Activity
paulgb commentedon Aug 20, 2022
Hi @jackhadrill,
Yes, this use case fits squarely into the use cases we imagine for Spawner.
When Keycloak confirms that a user is valid, your system would send a
SpawnRequestto Spawner, which is a JSON message that looks like this:If the
SpawnRequestis successful (meaning Spawner found a place to run the container), you could track its progress starting over NATS and redirect the user when the backend is ready.For the volume mount, we don't have a way to do it yet, but it's something we've wanted to do. As a first pass, we could just add a
volumesfield toSpawnRequestthat passes the value along to Docker, and then delegate to Docker for volume management. I've opened #117 for this.Currently, once the backend is spun up, any access control has to be built into the application itself (for example, Jupyter notebooks have a built-in bearer token check). Implementing a simple way to gate a backend so that only users with a bearer token can access the backend is something I've wanted to support, so I've opened #118 for it.
We don't really have docs yet but I'd be glad to provide you some instructions on getting started for your use case. I will need to finish merging in some code for the scheduler (#106) and DNS server (#119). What's your timeline?
jackhadrill commentedon Aug 20, 2022
Thanks for your response. It's great to hear that our needs align!
I have no fixed timeline for this, and would be more than happy to trial this for you (and put together some example usage documentation) as and when you're ready.
Let me know!
paulgb commentedon Aug 22, 2022
We'd be glad to have you trial it! I'll keep this issue open and keep you apprised of progress. Getting Spawner into a state that people can use it is my top priority right now.
paulgb commentedon Aug 31, 2022
@jackhadrill do you have thoughts on how you'd like volumes/storage to work? If we just provided a way to send an arbitrary volume spec with a SpawnRequest, and that could use Docker's NFS storage driver, would that do the trick?