Dockerfile for portability in running the handin server?

[CookieComputing]

I noticed that the handin server relies on a specific environment in order for the server to be run, but there seems to be no application of containers in the project that simplify the process of spinning up the server. I think setting up a Docker container would be great for being able to provide the handin server in a single image that can simply be executed via docker run

[NatTuck]

I see at least two complications with this idea:

• Bottlenose uses containers for sandbox autograding. Nesting containers is possible, but it's really ugly.
• Docker requires active administration to securely run in production. Bundling dependencies into images makes apps easier to try out, and be advantageous in high-budget environments with dedicated dev-ops staff, but it prevents normal OS package updates from being applied without manual intervention.

[CookieComputing]

With package updates, we could always run a very small Kubernetes cluster and have kops apply rolling updates, so if we were to actively maintain a cluster, it would be possible to update containers (through Kubernetes' thorough uptime for deployments). Although, I'm not entirely sure if setting up a Kubernetes cluster would be worth the hassle for the sake of a Docker container for the handin server, especially since we're not running enterprise level systems.

[grobalex]

I think the major advantage of using docker would be in a sub-prod environment to easily test new features or run a performance test etc. It would be nice to have CI build the code, launch a docker instance and then be accessible via a unique URL for a user to test the feature without interfering with anybody else .

[CookieComputing]

As an afterthought to the container problem, setting up an orchestration tool like Kubernetes would also help address the nested container issue if we broke up the handin server monolith: We could have the handin server as one pod, and then spin up new pods as needed for sandbox autograding. Again, this requires going deeper and using Kubernetes, which might entail over-engineering for the problem, but could be an interesting approach should NEU decide to move to a cluster-like environment.

[kylesferrazza]

My docker branch has a docker-compose setup for running bottlenose and postgres for development. It mounts the local directory into the container so that local changes are detected and update the containerized server in real time. This setup might be useful for @grobalex's CI idea.

I haven't gotten around to setting up the grading daemon in the container yet - it's just postgres and the rails server right now (which should still be fairly useful for testing purposes).