New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADD: ubuntu 18.04 and centos 6.9 dockerfiles #1372

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@kaczmarj

kaczmarj commented Jun 25, 2018

Hello,

This PR proposes adding specifications to build MRtrix Docker images. Containerization will make installation easier for some users, especially on HPC.

Two Dockerfiles are included in this PR. The file Dockerfile is meant for users to build when they fork the project and is based on Ubuntu 18.04 (the latest stable, long term support release). This image includes support for the GUI components.

This Ubuntu 18.04 image would be built as follows:

$ git clone git@github.com:MRtrix3/mrtrix3.git
$ cd mrtrix3
$ docker build --tag=mrtrix3 .

The file Dockerfile.centos6 includes the compile-time dependencies of MRtrix3 on Centos 6.9. If MRtrix3 is compiled on that image, the binaries should work on Linux systems after 2010 (glibc newer than 2.12). I realize that MRtrix3 releases macOS and Windows binaries, and this image can be used to release static, non-gui Linux binaries.

The Centos 6.9 Docker image would built as follows

$ git clone git@github.com:MRtrix3/mrtrix3.git
$ cd mrtrix3
$ docker build --tag=mrtrix3-build -f Dockerfile.centos6 .
$ docker run --rm -it mrtrix3-build
[in-container]$ ./configure -nogui -static
[in-container]$ ./build
[in-container]$ cd ..
[in-container]$ tar czf mrtrix3.tar.gz mrtrix3

Thank you,
Jakub

@jdtournier

This comment has been minimized.

Member

jdtournier commented Jun 27, 2018

Thanks for this, I'm sure it'll be appreciated by users out there (there's already one request on the forum). It's also been suggested before in #446, and we'd already agreed it would be good back then, so it's high time we did something about it...

Unfortunately, I'm not sufficiently familiar with docker to really review this, but hopefully some of the other team members will be happy to give it the thumbs-up. I'm personally all for this, with my only concern being one of ongoing support (since I'm not familiar enough with the technology to commit to maintaining it). Is this something you're happy to keep up to date when required...?

Strictly speaking, this should go into the dev branch, since it's not a bug fix as such. But since there is no scope for interaction with the existing code, I'd be happy to merge this to master directly, if everyone else agrees...?

@kaczmarj

This comment has been minimized.

kaczmarj commented Jun 27, 2018

@jdtournier - I would be happy to keep these Dockerfiles up to date.

@Lestropie Lestropie self-requested a review Jun 28, 2018

@Lestropie

This comment has been minimized.

Member

Lestropie commented Jun 28, 2018

Hi @kaczmarj,

Thanks for the PR. I've had a little experience with Docker now from developing my BIDS App, so I can help with getting this through; I just want to raise a couple of options, and I have a couple of other post-ISMRM priorities I need to churn through first.

  • I've not yet attempted to get UI elements working through a container, though I've at least seen it done. If it is indeed possible to run mrview inside the container (bearing in mind the OpenGL 3.3 requirement), then any additional instructions required for users to achieve this should be documented somewhere.

  • A couple of crucial processing functionalities in MRtrix3 are still just wrappers around commands provided in the FSL software package. Therefore without this software additionally being installed, those functionalities would be absent; most importantly, DWI motion / eddy / EPI distortion correction. It may be necessary to include FSL within the containers if they are to provide adequate standalone functionality.

  • While I'm not super-confident when it comes to version / tag marking for CI / automated deployment, I think this is something we would want to be 'on top of' before adding Dockerfiles to the repo. Most likely case here, we would want container tags as accessed on e.g. DockerHub to mirror the underlying MRtrix3 version.

  • Given the apparent purpose of the CentOS container, i.e. building static binaries, I think we'd be interested as to whether the GUI commands were omitted for simplicity or due to fundamental limitations. As part of the official release of the software, we would like to have a controlled environment in which to compile binaries for distribution via direct download (Edit: #902). A container seems a logical choice for this task, but I don't know whether or not this is in line with your intended design / use of this particular container.

  • If the Dockerfiles are included as part of the main MRtrix3 repository, they probably also need to be put through continuous integration testing. I've only done container-based CI testing via CircleCI, whereas MRtrix3 uses TravisCI, so this is something I'd need to look into further.

@maxpietsch

This comment has been minimized.

Member

maxpietsch commented Jun 28, 2018

@kaczmarj Thanks for the docker files! I am quite new to docker so bear with me if this is obvious. I tried to run mrview from the ubuntu image but can not get mrview to display. Host is ubuntu 16.04.

$ docker run -i --tty --rm -e DISPLAY=$DISPLAY mrtrix3
root@4d07dd525f36:/opt/mrtrix3# mrview
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.screen: QXcbConnection: Could not connect to display :1
Could not connect to any X display.

Also, I think the first line of your centos instructions should read docker build -f Dockerfile.centos6 --tag=mrtrix3-build . Otherwise it creates an ubuntu image.

@kaczmarj

This comment has been minimized.

kaczmarj commented Jun 28, 2018

@Lestropie - Here are my responses to each of your points.

I've not yet attempted to get UI elements working through a container, though I've at least seen it done. If it is indeed possible to run mrview inside the container (bearing in mind the OpenGL 3.3 requirement), then any additional instructions required for users to achieve this should be documented somewhere.

It can sometimes be tricky to run a GUI through a container. The following works on Linux (Debian testing). I was not able to get this to work on macOS. @maxpietsch - this should answer your question. (And thank you — I will make that edit to the docker build command)

$ xhost +local:root  # allow non-network local display connections
# When running the container, set the DISPLAY variable and mount the tmp X11 path.
$ docker run --rm -it \
    -v /tmp/.X11-unix:/tmp/.X11-unix:ro \
    -e DISPLAY=$DISPLAY \
    mrtrix_container mrview
$ xhost -local:root  # revert permissions

A couple of crucial processing functionalities in MRtrix3 are still just wrappers around commands provided in the FSL software package. Therefore without this software additionally being installed, those functionalities would be absent; most importantly, DWI motion / eddy / EPI distortion correction. It may be necessary to include FSL within the containers if they are to provide adequate standalone functionality.

I did not realize this. FSL can definitely be installed in the container. In this case, I would opt to use a NeuroDebian base Docker image, install FSL through NeuroDebian, and then compile MRtrix3.

While I'm not super-confident when it comes to version / tag marking for CI / automated deployment, I think this is something we would want to be 'on top of' before adding Dockerfiles to the repo. Most likely case here, we would want container tags as accessed on e.g. DockerHub to mirror the underlying MRtrix3 version.

Yes, it would be good for the tagged containers on DockerHub to mirror MRtrix3 version. But those containers do not have to be uploaded immediately. With a Dockerfile, users can build MRtrix3 without having to worry about dependencies for their system. Even better, in my opinion, one can checkout to any commit and build the project at that point.

Given the apparent purpose of the CentOS container, i.e. building static binaries, I think we'd be interested as to whether the GUI commands were omitted for simplicity or due to fundamental limitations. As part of the official release of the software, we would like to have a controlled environment in which to compile binaries for distribution via direct download (Edit: #902). A container seems a logical choice for this task, but I don't know whether or not this is in line with your intended design / use of this particular container.

I omitted the GUI components because I did not have time to delve into the Qt installation on Centos 6 (though here is Qt's documentation on this). I don't think there are any fundamental limitations. One consideration is that Qt might have to be statically compiled to be part of static MRtrix binaries. If that is not the case, we could include the Qt libraries in the release tarball. I believe FreeSurfer does this.

My intended use case of the Centos 6 container would be to compile MRtrix on an old system, so the binaries could be used on most current Linux distributions. In #902 I think there was talk of compiling several releases for different Linux distributions, but that might not be necessary.

If the Dockerfiles are included as part of the main MRtrix3 repository, they probably also need to be put through continuous integration testing. I've only done container-based CI testing via CircleCI, whereas MRtrix3 uses TravisCI, so this is something I'd need to look into further.

The containers can be built in TravisCI (they have good support for Docker). At the very least, CI can build the containers. But a more complete testing could include running MRtrix3's tests inside the container.

@maxpietsch

This comment has been minimized.

Member

maxpietsch commented Jun 29, 2018

mrview crashes on ubuntu 16.04 as host:

xhost +local:root
docker run --rm -it -v /tmp/.X11-unix:/tmp/.X11-unix:ro -e DISPLAY=$DISPLAY mrtrix3 mrview
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
No XVisualInfo for format QSurfaceFormat(version 3.3, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 0, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize 0, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(SingleBuffer), swapInterval 0, profile  QSurfaceFormat::OpenGLContextProfile(CoreProfile))
Falling back to using screens root_visual.
Could not initialize GLX

mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access
@kaczmarj

This comment has been minimized.

kaczmarj commented Jun 29, 2018

@Lestropie - maybe instead of statically compiling MRtrix3 in the CentOS 6 docker container, we dynamically compile and then package with package_mrtrix. Those binaries should work on most recent Linux distributions and would include the GUI dependencies. I can update Dockerfile.centos6 for that if it sounds like a good idea.

@maxpietsch - I'm not sure why that is happening. I will try to debug on Ubuntu 16.04.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment