-
Notifications
You must be signed in to change notification settings - Fork 119
/
Dockerfile_mamba
113 lines (91 loc) · 5.03 KB
/
Dockerfile_mamba
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### Thank you for using this Dockerfile template! #####
##### This is an outline for the flow of building a docker image. #####
##### The docker image is built to the 'app' stage on dockerhub/quay. #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### Step 1. Set up the base image in the first stage. #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### Conda can be a useful packaging manager that handles the #####
##### installation of tools and their dependencies. Generally, images #####
##### built via this method are larger, and may have file ownership #####
##### errors - which is why we generally recommend attempting to build #####
##### from source first. #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
# 'FROM' defines the base docker image. This command has to come first in the file
# The 'as' keyword lets you name the folowing stage. The production image uses everything to the 'app' stage.
FROM mambaorg/micromamba:1.4.9 as app
# List all software versions are ARGs near the top of the dockerfile
# 'ARG' sets environment variables during the build stage
# 'ARG' variables are ONLY available during image build, they do not persist in the final image
ARG SOFTWARENAME_VERSION="1.0.4"
# build and run as root users since micromamba image has 'mambauser' set as the $USER
USER root
# set workdir to default for building; set to /data at the end
WORKDIR /
# 'LABEL' instructions tag the image with metadata that might be important to the user
LABEL base.image="mambaorg/micromamba:1.4.9"
LABEL dockerfile.version="1"
LABEL software="SOFTWARENAME"
LABEL software.version="${SOFTWARENAME_VERSION}"
LABEL description="This software does X, Y, AND Z!"
LABEL website="https://github.com/StaPH-B/docker-builds"
LABEL license="https://github.com/StaPH-B/docker-builds/blob/master/LICENSE"
LABEL maintainer="FirstName LastName"
LABEL maintainer.email="[email protected]"
# 'RUN' executes code during the build
# Install dependencies via apt-get or yum if using a centos or fedora base
RUN apt-get update && apt-get install -y --no-install-recommends \
dependency_a \
dependency_b \
dependency_c && \
apt-get autoclean && rm -rf /var/lib/apt/lists/*
# Example apt-get command for commonly-missing dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
wget \
ca-certificates \
procps && \
apt-get autoclean && rm -rf /var/lib/apt/lists/*
# Install your desired software into the base conda/micromamba environment, pinning the version
# clean up conda garbage
# make /data to use as a working directory
RUN micromamba install --name base -c conda-forge -c bioconda -c defaults SOFTWARENAME=${SOFTWARENAME_VERSION} && \
micromamba clean -a -y && \
mkdir /data
# 'ENV' instructions set environment variables that persist from the build into the resulting image
# set the environment, add base conda/micromamba bin directory into path
# set locale settings to UTF-8
ENV PATH="/opt/conda/bin/:${PATH}" \
LC_ALL=C.UTF-8
# 'CMD' instructions set a default command when the container is run. This is typically 'tool --help.'
CMD [ "tool", "--help" ]
# set final working directory to /data
WORKDIR /data
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
##### Step 2. Set up the testing stage. #####
##### The docker image is built to the 'test' stage before merging, but #####
##### the test stage (or any stage after 'app') will be lost. #####
##### ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- #####
# A second FROM insruction creates a new stage
# new base for testing
FROM app as test
# so that conda/micromamba env is active when running below commands
ENV ENV_NAME="base"
ARG MAMBA_DOCKERFILE_ACTIVATE=1
# set working directory so that all test inputs & outputs are kept in /test
WORKDIR /test
# print help and version info; check dependencies (not all software has these options available)
# Mostly this ensures the tool of choice is in path and is executable
RUN softwarename --help && \
softwarename --check && \
softwarename --version
# Run the program's internal tests if available, for example with SPAdes:
RUN spades.py --test
# Option 1: write your own tests in a bash script in the same directory as your Dockerfile and copy them:
COPY my_tests.sh .
RUN bash my_tests.sh
# Option 2: write below common usage cases, for example with tb-profiler:
RUN wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/ERR166/009/ERR1664619/ERR1664619_1.fastq.gz && \
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/ERR166/009/ERR1664619/ERR1664619_2.fastq.gz && \
tb-profiler profile -1 ERR1664619_1.fastq.gz -2 ERR1664619_2.fastq.gz -t 4 -p ERR1664619 --txt