Docker support

[rkm]

Hi,

I'm interested in running BlueSky (simulation only / --headless) inside a docker container. Is this something that has been considered before? Would this be a useful contribution if I can get it working?

Thanks.

[herryklumper]

Hi Ruairidh, I did a first attempt some time ago but did not find the time to complete it. I believe that this would be a very interesting step. Would appreciate if you keep me posted. Kindest Regards, Herry Klumper +974 50560161

…

Op 27 nov. 2018 om 18:58 heeft Ruairidh MacLeod ***@***.***> het volgende geschreven: Hi, I'm interested in running BlueSky (simulation only / --headless) inside a docker container. Is this something that has been considered before? Would this be a useful contribution if I can get it working? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jooste]

Hi Ruairidh,

We haven't looked at this yet, but it could indeed be useful. Maybe also a nice way to distribute releases?

[rkm]

Hi,

I believe I have a working first version of this, although by no means a perfect solution! You're welcome to test it out: master...alan-turing-institute:docker_support. To run, first build and start the container:

> docker-compose build
> docker-compose up

Then connect to it:

> python BlueSky.py --client --docker

Things to note:

• Even when running with the --headless flag, QtGL/OpenGL still seem to be required by the navdatabase module. This causes issues since the docker container has no screen attached, which causes exceptions to be thrown as soon as OpenGL is imported and attempts to initialise itself. In a previous version of the Dockerfile, I got round this by setting ENV QT_QPA_PLATFORM=offscreen (ENV QT_DEBUG_PLUGINS=1 also helps when debugging), however the current combination of using the python:3.6 base image and installing python3-opengl through apt seems to fix this.

• Since the communication between the docker container and the host is through port mapping (in docker-compose.yaml), I've not been able to get the discovery handshake to work. I attempted also mapping the discovery port (11000) into the container, and this partially worked. The simulation seemed to receive the request from the client and send a response, however this is not received by the client. I suspect this is due to not having distinct client and server nodes which confuses the networking, although I'm maybe missing something obvious. My interim solution to this is to use the --docker command to force the client to connect with the default ports, which assumes the server is already running.

• Loading scenario files is currently broken, since the file paths are not translated from the host system to the docker one.

Not sure what you'd like to do going forward - I'm definitely interested in developing this into a usable state since it's a feature that would be very useful for my project.

[jooste]

Hi Ruairidh,

Sounds good! I'll have a look at the Qt dependency in navdb first, I don't think this is really necessary on the server side, in which case I can prevent the import when navdb is used there.

What do you mean with not having distinct client/server nodes? I'll try to look at this as well.

[jooste]

Ok, the latest commit should have removed the Qt import when running headless. I also managed to create and run a docker image. I'll play around with it some more :)

[jooste]

Ok, I googled around a bit, it seems there are issues with UDP broadcast messages from the docker image to the host. when I add "11000:11000/udp" to the list of ports in the docker-compose file I can receive UDP messages from the host to the docker image, but replies aren't received on the host.