Usage of docker containers in Kitware/trame/docker

[earlsioson]

Greetings,

I'm a new user of Paraview/VTK/trame and I'm trying to run one of the trame docker images published on docker hub. I'm running it on a google cloud compute engine vm with an NVIDIA Tesla T4 gpu. I've configured the machine with the nvidia-container-toolkit.

Running the command...

sudo docker run --gpus all --rm nvidia/cuda:9.0-base nvidia-smi

yields...

From looking at the github workflow action, I'm guessing I need to use the kitware/trame:glvnd tag per https://github.com/Kitware/trame/blob/master/.github/workflows/docker.yml#L84

When running it I get this error...

ERROR: The deploy directory must be mounted into the container at /deploy

I've tried to trace back what is required by reading through the docker scripts directory and see I need to have a server and setup directory in a mounted deploy directory.

My questions are:

• Can someone point me to an example of what should be in the setup and server directories?
• Am I using the correct image tag, kitware/trame:glvnd, for my machine?

We would like to eventually deploy an app to our Google Cloud Kuberenetes Engine cluster but want to use the Google Cloud Compute Engine virtual machine as a tool for learning how to use Paraview/VTK/trame.

[jourdain]

Hi @earlsioson ,

The base image that you are using is indeed a good one to enable remote rendering with ParaView/EGL. But the "trame" images are generic in the sense they only provide the infrastructure to deploy "trame app(s)" into the cloud (Python3 + web routing). They don't even have trame in them. Basically they rely on a mounted directory (/deploy) to provide the actual "trame app(s)" as a virtual environment.

To get started in how to build/deploy a trame app using such image, you will need to create a "trame application" using our cookiecutter. In doing so, you will get a /bundles/docker/* directory with an example of a ./setup/ directory that get used to build the ./server -> /deploy expected directory. You can refer to the /bundles/docker/scripts/* to see how to build and run using that side directory or just create an image on top that to bundle such directory inside a new image. You can also look at the one we did for the new visualizer too.

We are definitely lacking doc on that docker topic, but we are also trying to make it straight forward using the cookiecutter.

Anyhow, I hope that help you getting started.

A side note:
pywebvue 2.9.15 and 2.10.0 are currently breaking the local rendering used within the cookiecutter. If you want to try with the default example generated by the cookiecutter you should force pywebvue==2.9.14 for now.

[jourdain]

Basically the server does not have X and the default build is using X to create the GL context. That works fine on a "desktop" machine but not on an headless machine.

[earlsioson]

Thanks again @jourdain. Our VM has an nvidia tesla T4 and does have the nvidia drivers installed. We also have the paraview-egl binaries installed in an /opt/paraview directory and the pvpython trame/examples/ParaView/ContourGeometry/RemoteRendering.py example does work on the host machine. Will we have to copy those binaries into the trame:glvnd image when using the generated trame-app from cookiecutter?

[jourdain]

Just look at the visualizer docker again. That would be something like that. I haven't tested yet the latest changes I made in visualizer just yet. will work / might work

[jourdain]

Basically use pvpython instead of python in the launcher and import paraview.web.venv in your code.

[earlsioson]

@jourdain that helped. I think we can use paraview-visualizer as a starting point. In the visualizer repo I created a PR that merges the latest scripts from cookiecutter output and tweaked for paraview-visualizer in case you wanted to merge into master. I tested it on our vm with the nvidia tesla t4 gpu. Kitware/paraview-visualizer#3