Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ease deployment and maintenance #49

Open
rmartinsanta opened this issue Dec 16, 2019 · 6 comments
Open

Ease deployment and maintenance #49

rmartinsanta opened this issue Dec 16, 2019 · 6 comments
Labels

Comments

@rmartinsanta
Copy link

Context: After some tests & small contests, we are starting to use Domjudge a lot more. We are planning to host the AdaByron (an Spanish competitive programming contest http://ada-byron.es/) this year, so the objective was to simplify the deployment and maintenance of DomJudge as much as possible, so you may create your own instance without a deep knowledge of Domjudge or Docker internals.

All the customizations for our use case can be seen in the following repo: https://github.com/rmartinsanta/domjudge-automation.

Steps to test:

  1. Install Ubuntu Server (tested with 18.04.3) in a VM or equivalent.
  2. Clone the repo (git clone https://github.com/rmartinsanta/domjudge-automation)
  3. Install and reboot (./install-domjudge.sh)

The installation script will do all the tedious tasks, and give further instructions when finished.
There is a monitoring stack ready to use (cd mon-template && docker-compose up -d), that will expose Grafana on port 3000.

There is one thing I do not like but I have not found an alternative way to do it:
I am exposing the docker socket to the judgehost container (needed to dinamically assign a CPU ID), but as the container is already privileged, I do not think it is dangerous from a security point of view, correct me if I am wrong.

I would like to known your opinion about it, which parts would you like to add to this repo (so I can open a PR with them), what could be improved, etc.

@nickygerritsen
Copy link
Member

Very cool. I think @ubergeek42 is the person inside our team who is best to look into this.

@LDAP
Copy link

LDAP commented Aug 8, 2020

I did some tests with docker swarm to ease deployment and judgehost scaling.
Also I did work around the privileged judgehost by using a laucher image with DinD.

You can follow the development here: https://github.com/LDAP/domjudge-docker-stack

@jeremy-london
Copy link

@LDAP do you have any links to the DinD Judgehost replacement (Very intrested)? Does it need to run with a --privileged flag?

@LDAP
Copy link

LDAP commented Oct 20, 2020

@LDAP do you have any links to the DinD Judgehost replacement (Very intrested)? Does it need to run with a --privileged flag?

Have a look at my compose file regarding the judge service. The judge docker itself runs with --privileged in a container without --privileged. Short answer: The Judge ITSELF does.

Edit: Made consequence more clear

@nickygerritsen
Copy link
Member

@LDAP do you have any links to the DinD Judgehost replacement (Very intrested)? Does it need to run with a --privileged flag?

Have a look at my compose file regarding the judge service. The judge docker itself runs with --privileged in a container without --privileged. Short answer: It does not.

However, you do mount the /var/run/docker.sock volume inside that outside Docker container, which allows you to run anything you want inside it, including --privileged containers, which as far as I know basically makes this outside container 'privileged' as well.

@LDAP
Copy link

LDAP commented Oct 20, 2020

@LDAP do you have any links to the DinD Judgehost replacement (Very intrested)? Does it need to run with a --privileged flag?

Have a look at my compose file regarding the judge service. The judge docker itself runs with --privileged in a container without --privileged. Short answer: It does not.

However, you do mount the /var/run/docker.sock volume inside that outside Docker container, which allows you to run anything you want inside it, including --privileged containers, which as far as I know basically makes this outside container 'privileged' as well.

That is correct. I know no easy way using "real" dind without --privileged. However there are solutions out there providing exactly what you want (but I never used one of them).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants