Create a cron job to run and cleanup any docker images that have not been run recently.

[benjaminkostiuk]

We create a new docker image tagged with each submission id (source files) so if the user submits new code it will most likely never be needed again. We need a cron job to run and delete images that have not been used in the last 6 hours? less?.

Need to create new function in the docker service that a scheduled job can use to delete the images.

[OZoneGuy]

You can mount the submission folder, this will reuse the docker images without having to create new ones (assuming nothing major changes, like requirements.txt for python). This should reduce the number of docker images.

Alternatively, have precreated images for different courses/assignments. This could require some work with course instructors/TAs. Or we can have trusted users submit images/image settings.

For some things, where the projects/submissions could vary wildly, we can allow custom images. Doesn't solve the problem entirely, but reduces it signigicantly, I believe.

Some relevant docker links:

• Create container with a mount
• Use a read-only mount. Can be useful in some/most scenarios, but can problematic if the user expects the program to write to some file.

[benjaminkostiuk]

I remember I was concerned about the security vulnerability of mounting the source code files and their ability to get traceback to the host system and cause havok. If we could securely do it with read-only volumes allowing the files to still execute properly (reading, writing binaries etc.) then I'd be okay with it.

[OZoneGuy]

I doubt that that could be an issue (even without read-only access), but I will look it up to double-check. That being said, I think we should look into volumes. Very similar to mounting system files, with a few differences; the biggest one is that we can mount volumes that exist on a different machine/host. Meaning, we can store all tests/source code on a safe machine away from the actual server host and mount from there. Check the first point, third from last, here.

Besides, only root and docker user have access to the docker directory under /var/lib/docker/, so normal users shouldn't have access to it.

Doesn't have to be a priority, but I really think the volume/mount approach is better than having to schedule a repeating container/image purge.

[benjaminkostiuk]

👍 Yeah I like this idea a lot more than having to repeatly build a new image and having to worry about managing images. I will work on fixing this asap (after the tests + styling is fixed) then we can follow the same model for Haskell & Java. For the moment I'll use volumes just from the host system and can improve the security later on.