ooni
Create an official, Automated Build image on Docker Hub
Docker Hub allows you to create Automated Builds from source: https://docs.docker.com/docker-hub/builds/
It would add another packaging/distribution/installation method, whose buildings would be triggered automatically on each commit. It also allows to create different image tags from git tags & branches.
Also, documentation could easily include a canonical docker run statement to quickly spin up a Ooni probe instance with just a single command.
By making the image build via an AB, you give the resulting image verifiability and auditability. Also, the build is fully automatic. You can have the latest image tag build from HEAD and individual image tags from git's release tags. Some people avoid non-verifiable (manually uploaded) images due to security & traceability reasons.
Docker search command clearly displays AB when listing images. Real example:
$ docker search ooni
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
sinar/ooniprobe 1 [OK]
acustura/ooni-global 0
acustura/ooni-geo 0
cdrfun/ooni-probe Fork of https://github.com/TheTorProject/oon… 0 [OK]
...
Just a free Docker Hub account and a quick setup would do. Ping me if you need help.
@bassosimone @hellais Any feedback on this? For Docker Hub, is just registering and account, linking your GitHub repo and creating a new Automated Build which links the master git branch to build to :latest image tag. Ping me if you need help.
However, I see Docker images on GitHub registry. Stale issue? I couldn't find neither Docker documentation nor Dockerfile to build my own.
Should this issue change to docs/support request?
@pataquets we are currently working on debian packages for probe-cli (see: https://github.com/ooni/probe/issues/1061), which would enable us to then easily build a docker image based on these packages using debian as a base OS.
We would prefer to keep the deployment matrix of OONI Probes as lean as possible hence we would prefer waiting for that to converge before making a docker image.
I looked a bit into doing this and I am going to share here some of the findings and the challenges.
For starters I think it's useful to define the requirements for this docker image of OONI Probe.
How I see it these are the requirements for it:
- It should be as close as possible to what we are shipping to most users. The behaviour of the docker based probe should be as close as possible to the behaviour of the other probes.
- It should not require any additional packaging or build infrastructure to be setup. We shouldn’t need to have to create any additional build artifacts or make changes to our build infrastructure in order to support docker images.
- It should be very easy for users to set it up and run it
- It should support automatic update of ooniprobe-cli
Based on the above requirements, I investigated the possibility of re-using our OONI Probe debian package and using unattended upgrades for keeping the package up to date.
However this approach presents some challenges. The main issue is that the OONI Probe package is reliant on systemd for scheduling of automatic runs, yet in order to run systemd inside of docker you need to either run it in priviledged mode or grant it the CAP_SYS_ADMIN capability. Both of these options I don't think are ideal from both a security and usability perspective (requiring non-standard OS-specific commands to run the container).
In researching this I came across this python replacement for systemctl: https://github.com/gdraheim/docker-systemctl-replacement, but it doesn't really cover our use-case as we need support for timers. That said the documentation of the repo explains in depth quite well the issues related to using systemd in docker.
In light of this I can see a few different options on how we might go about addressing this:
- We implement a cronjob based autorun system that is specific to the docker based installations. This can either be implemented inside of the docker image itself or perhaps even shipped as part of the debian package.
- We add support in probe-cli for running tests automatically at regular intervals. This would either involve creating a system daemon that runs the tests periodically in the backend or could even be a simple wait loop that triggers the run command at a specified interval.
- We ignore the issue with docker needing priviledged mode and just document that as the way to run it
I am kind of leaning more towards option 1 or 3. 2 seems quite a lot of work and I don't think it's justified unless we have a use case for this command beyond the docker image.
It was also pointed out on slack that there is a docker image for ripe atlas probes (https://github.com/Jamesits/docker-ripe-atlas) and we might want to look at that for some inspiration. An interesting thing that they do in order to support automatic update of the software is recommend the installation and usage of watchtower: https://github.com/containrrr/watchtower.
@hellais Nothing official but I've created an image for my needs over here: https://github.com/altertek/docker-ooni-probe I tried to stay as simple as possible for the image, I support the regular runs at the docker-compose level (option 2 more or less) The automatic update could be added with watchtower as you said.
Feedbacks are welcome !
I forked altarek's repo and tried to create a different ooniprobe docker image: https://github.com/lorenzoPrimi/docker-ooni-probe
- It uses debian:11.6-slim
- Add the ooniprobe GPG key and repo and install the package from there
- Has a random value of sleep between test
This is what is still left TODO
- Enable UnattendedUpgrades
- Remove or cut logs
- Disable
onboard --yesbefore releasing to Umbrel
