Proposal: Allow users to provide their own Docker hosting


#1

Currently, Janitor’s biggest growth bottleneck is the shortage of available Docker container hosting:

  • Relying exclusively on sponsored hosting means that we can’t grow very fast (i.e. whenever we get a new sponsored server, we’re super happy and can invite more users, but pretty soon that server is full and we’re back to resource shortage / not being able to invite more users). This slows us down.

  • Additionally, dealing with the constant resource shortage makes us an ops/infra project, as opposed to adding value as a software tools project (because we spend most of our time cramming as many containers as we can into a limited supply of servers + having to find new tricks to make containers use less disk; RAM; or CPU). This makes us focus a lot of efforts on domains where we don’t add value.

I have a few ideas that could allow us to spend fewer efforts on container hosting, and more on solving actual software development problems (see Master Plan), while also allowing Janitor to grow much faster (i.e. not require manual invites anymore).

1. Bring Your Own Hosting?

I’d like to get rid our email invites. Instead, I’d like anyone to be able to sign in to Janitor, and then see a checklist like this:

  • [ ] Set up Docker container hosting
  • [ ] Review your settings and configurations
  • [ ] Pick a project and start your first container

“Docker container hosting” could be a new tab in settings, and it could have an option called “Request free/sponsored hosting” (i.e. that would be our current “invite required” system, where we manually approve open source developers and let them use our sponsored servers).

But this section could also contain another option called “Use your own Docker hosting”, taking you through this flow:

1.A. Add your Docker server manually

  • What is your server’s hostname or IP address?
  • Please make your Docker daemon serve the Docker Remote API via TLS, like so (sample daemon.json config)
  • Please clone Janitor; configure its proxy like so (sample janitor.json config); and then run it

1.B. Or just run our “Janitor agent”

It would be great to automate the above flow, or a similar flow, using an agent. I think we could do it like Datadog, which provides a simple Docker one-liner:

docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=abcd1234 datadog/agent:latest

Maybe our one-liner could run a privileged container that phones home to janitor.technology, then offers to run any Janitor container for the owner on their server, and route any authenticated requests to it.

2. Connect your favorite cloud platform

We could also write integrations with OVH Cloud / DigitalOcean / Google Cloud Platform / etc, which would allow you to easily connect Janitor to your favorite container hosting platform (and let it responsibly use your free/paid resources there).

This has the benefit of completely externalizing the hosting / infastructure management (we don’t need to do it; our users don’t need to do it; it’s a service provided by the chosen cloud platform), allowing us to focus on building a great development experience; and our users to focus on using their containers to develop great software.

But it requires users to set up a separate hosting account (potentially with billing), and to give Janitor limited access to it (maybe we need to set up a maximum monthly budget or something similar).

Note that some platforms offer sandbox containers, which are good for temporary web-app-like environments (i.e. don’t compile things on them): Heroku has a free tier with free tiny containers, and OVH Cloud has super-cheap sandbox containers.

3. Or simply pay for your hosting?

We could save our developers even more time and cognitive overhead (i.e. choosing an appropriate cloud platform, and then tracking costs & resource usage) by allowing them to simply provide a credit card to pay for their hosting, letting us interface with cloud platforms and manage container hosting for them (but since they’re paying, it simplifies our job because we can just use a cloud platform instead of running everything on our own dedicated infrastructure).

For example, we could imagine having a simple 5€ / month “web app development” hosting option for small projects, or a 30€ / month “compiled app development” option for projects like Firefox and Chromium that need a lot of power, and this would be enough to cover super fast container hosting for an amazing developer experience. And any excess income could go directly toward more sponsored hosting for open source developers (e.g. we could say something like “if you like Janitor, please consider supporting it by paying for your hosting”, and the monthly bill could act like a recurring donation).


Please let me know what you think about these ideas. I’m very much looking forward to solving our hosting bottleneck, thus opening our doors to many more projects and users! :smile:


#2

Great feedback from IRC:

10:13:49 <@ntim> janx: “2. Connect your favorite cloud platform” seems like a good option
11:01:59 <@bnjbvr> janx, nice idea! i think 3. is the most sustainable in the long term, and you could also add an option for “shared hosting” that has a lower price tag (for web dev it definitely makes sense)
11:02:32 <@bnjbvr> my point is: no need to rent a full machine just for one person for a few projects, they can easily share hardware with other people
11:03:22 <@bnjbvr> option 2 sounds like a nice-to-have, option 1 may be overly complicated

Thanks!


#3

I would love it if Janitor switched to offering a for-pay service. I’d buy it in a heartbeat. But you have to switch to a different IDE first.


#4

Thanks a lot @notriddle, and you’re totally right. Maybe let’s look into fixing & improving Theia?

Also, more IRC discussion:

13:33:18 <Coder206[m]> janx: I fancy the option 1 because it allows for people to access a personal server, to me this could be useful when working on security critical bugs as it’s not a shared environment.
13:35:16 <Coder206[m]> Option 2 and 3 seem like great solutions to also eventually integrate Windows and macOS as we (or the user) could justify the cost of services like Azure
13:58:01 <@janx> Coder206[m]++ great point about Azure and macOS
13:59:08 <@janx> option 1 might be very work-heavy, as bnjbvr pointed out, but potentially worth it for use cases like security critical bugs (but then, would you really trust a local privileged agent that exposes local content to the web?)
14:00:26 <@janx> currently I tend to agree that maybe it’s a bit too complicated to implement while not addressing many large core use cases


#5

This is not a bad thing. Working on browsers or compilers needs huge machine power, and what we really need to do is to make the power utilization better.

This is exactly where we add value. Web IDEs themselves are nothing new. There are already many competitors in this field, like GitLab or Codenvy (Eclipse Che) that focuses on making small contributions easier (for a normal scale project, of course). They have much more contributors and backers, which we lack.


#6

Not sure if this is the intended use case, but I do now use the PrivateBin Janitor image frequently locally. It allows me to quickly spin up instances, try out stuff, even offline. This has greatly simplified my development workflow already.

Maybe this option should just be mentioned as an alternative? Or does this cause issues with the VNC (which I don’t use)?


#7

This is a super cool use case indeed, and I know that people use the Firefox images directly as well (myself included for various projects).

The approach doesn’t have any issues (VNC or otherwise), you just need to expose the right ports when running the container.

I agree that we should totally advertise this possibility more, e.g. with a blog post and/or “run locally” one-liners directly in the Projects page.

The only things you’ll miss are the automated configuration management (which you can work around with a few hacks), convenient UI for managing containers and finding the ports you want, logging in from any device (e.g. start a build on your laptop, close it, take the bus, check/fix the build on your phone), and maybe a few other features we’d like to add like sharing containers port URLs, live collaboration with others, etc. In the future we’d also like to build a GitHub integration (and/or WebExtension) that would basically add a Janitor Terminal (and IDEs / preview ports) directly to all your GitHub repositories. I think that’d be a pretty cool demo of the Web’s power.


#8

Ok, agreed, we’ll still need to optimize disk; RAM; and CPU as best we can, in order to improve the development experience and reduce costs. What I meant is that we currently spend a ton of time doing ops/sysadmin things (maintaining/rebooting servers, dealing with OOMs, upgrading kernels, etc) which is time that we don’t spend on making Janitor better for our users.

Ops/sysadmin is where we don’t add value. Making it possible and even practical to work on large complex software projects in a containerized environment, that’s indeed one of the places where we do create value.