As discussed in the previous post, we are incorporating competitor feedback and updating our web design contest to include more dynamic server-side interaction.
We procured a server to contain all the necessary services to host the contest. Being that this is a shared environment it was decided that we would use a Linux based operating system and would then subsequently sandbox each team into a Docker container as their shell. Doing this creates an environment where each team feels like they are on their own system and have complete control over it but yet are locked in with cpu, memory, and io quotas and cannot affect their neighbors around them nor access other’s data. The beauty of Linux Containers is that by default they are completely ephemeral and everything gets reset when you stop and restart the container. Following best practice, each container fulfills a single goal and has its command running as process id 1 allowing for debugging and an overall more secure implementation as unexpected services can’t be started up. The way we manage to preserve the state of the user shells as well as configurations for each service is by the ability to mount volumes from the server’s filesystem to the filesystem inside of the containers. Exposing TCP or UDP network ports is done in a similar fashion as the volumes; you can designate the port inside the container that you want to expose and then give it a public port number that does not necessarily have to be the same as the one on the inside, allowing for thousands of copies of the same application to live on the same server.
The design contest environment, in order to be provide the full intranet feel, comes complete with a DNS server, web server, and ftp server as well as the server hosting the API to be consumed as part of the contest requirements. Each of these services will also be containerized to securely lock them into a cpu/memory/io sandbox as well as provide the ability to quickly and effortlessly zip up the contest data and reset the server back to a pristine state to be ready for the next contest.
Below is a diagram of how the user will see the design contest network:
More changes in 2019 anticipated
Using this new configuration, we will be able to provide some new features with the competition and have room for growth in the future. We believe in small, successful changes. It is very important competitors provide feedback as to how this solution worked in our 2018 competition. We look forward to your feedback on these changes as well (comments are open below).
We are excited about these improvements. We hope you are as well.