Using Docker Bind Mounts with GLUE
Making Imports and Exports Map to a Local Project Directory
Overview
Practical use of a GLUE resource typically involves importing data into the project or exporting results for downstream analysis. When GLUE is run via Docker, interaction with the container filesystem becomes unavoidable.
Docker containers execute in an isolated filesystem environment, deliberately separated from the host machine in order to provide portability and reproducibility.
This post explains how Docker directory binding works in this context, and how to configure a GLUE container so that imports and exports map cleanly onto a local project directory.
The focus here is not on Docker in general, but specifically on the small amount of Docker configuration required to make GLUE behave as expected when reading from and writing to disk.
The container filesystem boundary
By design, a Docker container has its own isolated filesystem. Files created inside the container exist only for the lifetime of that container unless an explicit connection to the host filesystem is made.
As a result:
Files exported by GLUE inside a container will not automatically appear on the host machine.
When the container exits, any files written to its internal filesystem are discarded.
Bind mounts: the mechanism Docker provides
Docker exposes host directories to containers using bind mounts, specified with the -v option.
The general form is:
-v <host-path>:<container-path>This instructs Docker to make a directory on the host filesystem available at a specified location inside the container.
From the container’s perspective, the mounted directory behaves like a normal directory. From the host’s perspective, files written by the container appear immediately in the corresponding location.
A concrete GLUE example
Assume a GLUE project lives in the following directory on the host machine:
/Users/rob/hcv-glueFrom within that directory, the following command runs GLUE with a bind mount:
docker run --rm -it \
--name gluetools \
--link gluetools-mysql \
-v "$(pwd):/work" \
-w /work \
cvrbioinformatics/gluetools:latestAfter shell expansion, Docker interprets the volume argument as:
-v /Users/rob/hcv-glue:/workThis establishes the following mapping:
Host filesystem: /Users/rob/hcv-glue/
Container filesystem: /work
The two paths now refer to the same directory.
Working directory configuration
The -w option specifies the container’s working directory:
-w /workThis causes the container to start with /work as the current directory. In practice, this is equivalent to running cd /work immediately after the container starts.
This detail matters because GLUE frequently uses relative file paths in import and export commands.
Effect on GLUE exports
With the configuration above, a GLUE export such as:
export fasta fileName exports/my_alignment.fastawrites to:
/work/exports/my_alignment.fastaOn the host filesystem, this corresponds to:
/Users/rob/hcv-glue/exports/my_alignment.fastaThe exported file persists after the container exits and is available for downstream analysis using host tools.
What happens without a bind mount
If GLUE is run in Docker without a bind mount:
Exported files are written only to the container filesystem.
These files are lost when the container exits.
Paths such as
/workmay not exist at all.
This behaviour is expected and consistent with Docker’s isolation model.
Practical rule of thumb
When using GLUE via Docker:
Any file that should persist outside the container must be written inside a mounted directory.
In the examples above, that directory is /work, but any container path may be used as long as it is bound to a host directory.
Why this matters for GLUE workflows
Once directory binding is configured correctly:
GLUE can be used interchangeably in interactive and scripted workflows.
Export paths are predictable and stable.
Commands can be shared or documented without embedding machine-specific absolute paths.
Dockerised GLUE behaves much like a native installation from the perspective of file I/O.
This configuration step is therefore foundational for reproducible and portable GLUE-based analyses.
 | A guest post by
|