A Docker image for qvis about qvis

[rmarx]

Hello Maxime,

Thanks for opening the issue.

I am wondering what you are asking here -exactly-.
If you are asking about dockerfiles / a list of commands to (semi-)robustly get a qvis build working, those can be found at https://github.com/quiclog/qvis-server/tree/master/system/docker_setup. Those are the docker files used for the live qvis.edm.uhasselt.be version.

If you are asking about me maintaining a docker hub image, I would love to hear the rationale for that.
If you have a custom qvis with some changes, the official docker-hub image wouldn't help anyway.
If you're just using the "official" qvis, you can just use the live version at qvis.edm.uhasselt.be (which is less hassle?)
The main argument I can see is because you don't want to upload potentially sensitive pcaps to the qvis live server for transformation, but I'm not sure that's the case here.

I'm also not entirely sure what you mean by "while still beeing able to consult server side logs for debugging traces maybe".

In short, while I -can- certainly do this, it is currently not at the top of my (long) TODO list for qvis/qlog.
I'd love to hear some additional arguments for needing a local build so I can sell it to myself to make this a higher priority ;)

To make tracking easier: this is related to #27

[mpiraux]

Hello,

I wrote that a bit too early this morning I guess 😄

I was asked to help one of my colleague getting qvis installed and just thought "wouldn't it be simpler to docker pull qvis?".
I don't think he's planning to modify the code, just trying to make qlogs out of a modified TCP and TLS stack. In that case, wouldn't a local build more helpful to understand what may be wrong in a trace ?

I didn't even look for existing Dockerfiles, but those you pointed to looks sufficient.

On a side note, a Dockerfile that compiles and runs code that is shared with the container could also be helpful to speed up the setup of a development environment.

[rmarx]

Hey Maxime,

Extra debugging output for something with "experimental support" like TCP qlog (good to hear you guys are working on that btw!) is indeed a good use case, however not one that would be solved by a docker image I guess.

I personally use npm run serve instead of npm run build at https://github.com/quiclog/qvis-server/blob/master/system/docker_setup/qvis/dockerfile#L36
That enables "source maps" which means you can see the original TypeScript code directly in the browser, instead of the often strange compiled JavaScript + can set breakpoints properly in there as well.

It should be easy to use my examples to make a dockerfile that does that + mounts the local code via a docker volume (i.e., --volume=/local/dir:/srv/qvis instead of doing a pull from github). This is what I've done for many other projects and that works quite well indeed.

I'd suggest your colleague tries that for now and I'll keep a more general docker setup in mind when I have more cycles to spend. If they have problems in the meantime, feel free to reach out!

[mpiraux]

Thanks for your reply. Let's close this in the mean time.