Does anyone run satnogs-client inside a docker container ? How is your experience with it ? Didn’t find any documentation for deploying the client inside docker.
The main reason I’m trying it is to play with a HackRF as SDR receiver to experiment with higher frequencies than rtl-sdr allows and with its 8MS/s minimum sample rate my raspberry pi 3 is a little short of cpu. I didn’t want to deploy directly on my computer as i was afraid of breaking other things on it as i don’t know everything that is done when deploying the satnogs-client.
I’m mostly successful with deploying satnogs-client onto a docker container with ansible using the doc from https://wiki.satnogs.org/SatNOGS_Client_Ansible
The deployement goes fine (it always fails at the first run and succeeds on a second run, to be investigated), satnogs-setup runs fine and the client connects to the network. Devices (HackRF, Rtl-Sdr and LimeSDR-mini) are correctly recognized and seem to work fine as long as they are connected to the host before starting the container. Connecting them later currently fails, they are recognized as usb devices but fail to open.
Need to perform some more testing and clean some config up but basically it is working. I’d happily share the configs i use if someone is interested and would be happy to hear of some others experience.
That would be amazing. I have a Synology NAS that has mulitple USB ports and being able to run 2 containers for SatNOGS instead of 2 Raspberry PI’s would be really good !
Very cool work !
I’m interested in learning more about what it takes to create a Docker container that’s meant to encapsulate something as complex as the Client and its various dependencies (Python, device drivers, etc…) on hardware interfacing.
I’ve used existing Docker containers for a while, even created one or two small “test” ones to learn the basics, but didn’t feel comfortable enough with it to try something more complicated.
Like you, for some of my more advanced SDR’s, I want to explore the Client in a “sandbox” of sorts, on a system that has more resources than a Pi, but I also don’t want to permanently affect a working system… thus the isolation procedures.
When you feel comfortable sharing the scripts, I’d love to try them out. I think this approach would be equally valuable in trying out upcoming changes to the Client, as the project moves forwards.
FYI: There’s a different project I’ve been keeping my eye on, called OpenWebRX, which recently got forked, and updated, and whose new maintainer made a concerted effort to get the new “version” configured as a Docker container. He includes the scripts he uses in his Github repo, and I’ve been slowly looking through them to better understand some of the config details (USB hardware pass-through, permissions set to access the hardware, etc…). It’s less complex than the SATNOGS client, but shares similar dependencies, so every little bit helps me learn.
@9v1rm is your Synology x86 or arm based ? As long as the cpu power is enough i don’t see a reason it couldn’t work. I use footloose for the docker setup, they don’t provide arm binaries but there is no reason it wouldn’t compile on arm. I already successfully built footloose’s docker image on arm but didn’t have time to further test it on arm.
@luckyjunknowitz i don’t think full isolation is possible, currently even /lib/modules is shared into the docker. But it isolates all other dependencies like drivers, gnuradio and so on so the specific versions used for satnogs won’t mess up system installed ones.
The goal is to keep all existing deployment and setup tools (like satnogs-client-ansible and satnogs-setup) and as they heavily depend on satnogs-client running as a service i opted to use footloose (https://github.com/weaveworks/footloose) as it makes it easy to start a docker container with systemd and ssh so it is possible to use satnogs-client-ansible to install satnogs-client and use satnogs-setup for the configuration. It is certainely possible to run satnogs-client as a normal docker main process but satnogs-client-ansible or satnogs-setup would need to be seriously modified or a separate setup tool would need to be written. So for me footloose is a good choice in this case.
Will test some more but it seems to work fine. Mostly the doc will need to be updated and then i’ll share the link to my fork here.
The config files to start a docker to install satnogs are in my docker branch of my fork of satnogs-client-ansible:
I updated the README.md with the steps to deploy SatNOGS in a docker. Might need some more updates.
Only tested on x86, for Arm footloose would need to be compiled as no binary is provided, and the docker image must be generated as there is only an x86 one publicly available. If there is interest x86 and Arm docker images could be published containing already some base dependencies.
Currently if the docker containers are deleted, the config gets deleted as well.
If the updated documentation is not clear i’ll happily respond to yor questions and update the doc, if it works for you i can open a merge-request on gitlab.
@cmorgan The choice of footloose is done so it is possible to use an unmodified satnog-client with the satnog-setup inside of the docker. Both depend on having systemd running in the docker.
It would certainely be possible to start a docker container with systemd running but it is a lot easier with footloose. Without footloose there would be quite a bunch of options to provide to docker (could be done inside a docker-compose.yml file for example). And footloose is quite a lightweight dependency.
The Dockerfile used is the one from footloose, it uses their ready-to-use docker image from their own docker hub. Currently they only provide amd64 images, to run the dockerized version on a raspberry you would need to generate your own docker image from their dockerfile. Haven’t tested it on a Pi but at work we heavily use footloose on arm64 nvidia platforms with success. I need to update the doc for this once i tried satnogs in a docker on a Pi.
I could publish an amd64 and arm version of the image on docker hub if desired, it could come pre-packed with many of the dependencies so it would speed up the initial deployement.
Just giving this a go and running into the below error. I am running this from an AWS debian AMI, which most likely would be the problem. Does this have to run from a raspbian os?
Error:
admin@ip-172-31-8-39:~/satnogs-client-ansible$ ansible-playbook -i production/inventory/footloose site.yml
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this
will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can
be disabled by setting deprecation_warnings=False in ansible.cfg.
[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details
Executing playbook site.yml
satnogs-setups on hosts: satnogs-setups -
Gathering Facts…
Configure needrestart for Raspbian…
satnogs failed | msg: The conditional check ‘ansible_lsb.id == ‘Raspbian’’ failed. The error was: error while evaluating conditional (ansible_lsb.id == ‘Raspbian’): ‘dict object’ has no attribute ‘id’
The error appears to be in ‘/home/admin/satnogs-client-ansible/roles/satnogs-setup/tasks/main.yml’: line 2, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
My understanding of how the satnogs software works is really low, but is it a python virtual environment that’s running as a systemd service? I was wondering if we could just have the python virtual environment running from the docker container instead as its entrypoint?
Also wondering for the satnogs setup, did you need the gui or could it just be controlled by the config file?
I image there will be reasons it not that simple but the way I was picturing it was you use a base image for example Debian, then convert the ansible scripts into dockerfile run commands and create a dockerfile. This could be running on a pipeline which uploads to dockerhub on changes for each update. The advantage of this, is all the users would need to do is have docker installed on their machine and do a “docker pull satnogs” then a “docker run --device=/dev/ttyUSB0 satnogs”. They would need have the satnogs config file updated with their own contents which could be done as volume share.
Like I said its not going to be that simple but that advantage could be that is its super easy for people to get up and running and it reduces the complexity needing to run ansible on machines which may have incorrect dependencies etc.
Haven’t tried it on Raspbian, only on PC. The main idea is to test/use satnogs on a PC without affecting existing SDR tools already installed (later it could be used to automate deployement tests in the CI/CD pipeline, as well as testing various upgrade path from older to current satnogs version).
I have to try it on raspbian.
I’ll also try a fresh deployement, as i currently only updated my running instance, not tried a fresh deploy with the evolution of satnogs-client-ansible. Will do that asap.
From your error message it seems that raspbian is not set as an ansible target yet. Could probably easily be added.
From my understanding it depends also on other services for rotator control for example. I’m also still pretty new on satnogs so there is a lot to learn for me as well.
For the moment i used the GUI. Could be a later improvement to ‘map’ the config into the container and configure it with satnogs-client in a batch cli mode.
Just tested a fresh deployement and indeed it doesn’t seem to work anymore. Tried it on stable and master branch.
There seems to be a regression in deploying to PC currently. Reason more to try to integrate deployment test in the CI/CD pipeline
