Running fMRIPrep via Docker containers¶
For every new version of fMRIPrep that is released, a corresponding Docker image is generated. The Docker image becomes a container when the execution engine loads the image and adds an extra layer that makes it runnable. In order to run fMRIPrep Docker images, the Docker Engine must be installed (see Docker (recommended for PC/laptop and commercial Cloud)).
If you used fMRIPrep via Docker in the past, you might need to pull down a more recent version of the image:
$ docker pull nipreps/fmriprep:<latest-version>
You can run fMRIPrep interacting directly with the Docker Engine via the docker run command line, or you can use a lightweight wrapper we created for convenience.
Running fMRIPrep with the
Before starting, make sure you
have the wrapper installed.
When you run
fmriprep-docker, it will generate a Docker command line for you,
print it out for reporting purposes, and then execute it without further action
$ fmriprep-docker /path/to/data/dir /path/to/output/dir participant RUNNING: docker run --rm -it -v /path/to/data/dir:/data:ro \ -v /path/to_output/dir:/out nipreps/fmriprep:20.2.0 \ /data /out participant ...
fmriprep-docker accepts all of the typical options for fMRIPrep (see Usage Notes),
automatically translating directories into Docker mount points.
We have published a step-by-step tutorial
illustrating how to run
This tutorial also provides valuable troubleshooting insights and advice on
what to do after fMRIPrep has run.
Running fMRIPrep directly interacting with the Docker Engine¶
If you need a finer control over the container execution, or you feel comfortable with the Docker Engine, avoiding the extra software layer of the wrapper might be a good decision.
Accessing filesystems in the host within the container.
Containers are confined in a sandbox, so they can’t access the host in any ways unless
you explicitly prescribe acceptable accesses to the host.
The Docker Engine provides mounting filesystems into the container with the
and the following syntax:
where the trailing
:ro specifies that the mount is read-only.
The mount permissions modifiers can be omitted, which means the mount will have read-write
In general, you’ll want to at least provide two mount-points: one set in read-only mode
for the input data and one read/write to store the outputs.
Potentially, you’ll want to provide one or two more mount-points: one for the working
directory, in case you need to debug some issue or reuse pre-cached results; and
a TemplateFlow folder to preempt the download of your favorite templates in every
Running containers as a user.
By default, Docker will run the container as root.
Some share systems my limit this feature and only allow running containers as a user.
When the container is run as root, files written out to filesystems mounted from the
host will have the user id
1000 by default.
In other words, you’ll need to be able to run as root in the host to change permissions
or manage these files.
Alternatively, running as a user allows preempting these permissions issues.
It is possible to run as a user with the
In general, we will want to use the same user ID as the running user in the host to
ensure the ownership of files written during the container execution.
Therefore, you will generally run the container with
-u $( id -u ).
You may also invoke
$ docker run -ti --rm \ -v path/to/data:/data:ro \ -v path/to/output:/out \ nipreps/fmriprep:<latest-version> \ /data /out/out \ participant
$ docker run -ti --rm \ -v $HOME/ds005:/data:ro \ -v $HOME/ds005/derivatives:/out \ -v $HOME/tmp/ds005-workdir:/work \ nipreps/fmriprep:<latest-version> \ /data /out/fmriprep-<latest-version> \ participant \ -w /work
Once the Docker Engine arguments are written, the remainder of the command line follows
the Usage Notes.
In other words, the first section of the command line is all equivalent to the
executable in a bare-metal installation:
$ docker run -ti --rm \ | These lines -v $HOME/ds005:/data:ro \ | are equivalent -v $HOME/ds005/derivatives:/out \ | to the fmriprep -v $HOME/tmp/ds005-workdir:/work \ | executable. nipreps/fmriprep:<latest-version> \ | \ /data /out/fmriprep-<latest-version> \ | These lines participant \ | correspond to -w /work | fmriprep arguments.