This is the base image for all mosaicgreifswald/ images. Some scripts are predefined here that are useful for health checks, start order and version information. Each new layer should "register" for this so that the new attributes are known and can be used.
Registration is explained using the example of a simple database:
register \
--add-version="Database-Server:\$(/opt/database/bin/daemon -v)" \
--add-entrypoint="ENTRY_DB_CONFIG:/opt/database/config" \
--add-entrypoint="ENTRY_DB_DATADIR:/opt/database/data" \
--add-healthcheck-script="/opt/database/healthcheck.sh" \
--add-process="database:10:service:/opt/database/run.sh:/opt/database/started.sh"
Explanation
--add-version="NAME:VERSION" is used to announce a new tool and how its version can be queried. It is also possible to simply pass the version number directly or as a variable if it should not change in this image.--add-entrypoint="NAME:PATH" specifies a new entry point in the image that can be referenced at start-up via --volume "*:*" to exchange data with the host system.--add-healthcheck-script=SCRIPT is used to announce a bash script to be used for health checking the layer. The script to be executed may generate output, but must be terminated with exit code 1 if the corresponding layer is no longer functioning properly. Exit code 0 means "All is well".--add-process is needed to register a new process and must have the format NAME:ORDER:TYPE:RUN:STARTED, whereby the last segment is optional.
NAME is used to identify the process. The name can be used to filter processes and start or stop them individually.ORDER determines the start order, whereby a larger value means a later start. As a rough guide, databases should start with 10, app servers with 20 and tests from 30.TYPE the start type of the layer is defined, which can contain the characteristics action and service.TYPE has value action the RUN script is started and no further RUN scripts are executed until this one is finished.service as TYPE value starts the RUN script in the background. If the optional STARTED script is specified, this is used to check and wait when the services has started up correctly and then start the other RUN scripts.| Category | Variable | Available values or scheme | Default |
|---|---|---|---|
| Optimizing | TZ | <STRING> | Europe/Berlin |
| Optimizing | MOS_RUN_MODE | action | service | cascade | external | service |
| Processing | MOS_WAIT_FOR_PORTS | <HOST>:<PORT>:<TIMEOUT>:<SLEEP> | |
| Testing | MOS_SHUTDOWN_DELAY | <SECONDS> | |
| Processing | MOS_INCLUDE_PROCESSES | <REGEX> | |
| Processing | MOS_EXCLUDE_PROCESSES | <REGEX> |
The MOS_RUN_MODE, in contrast to the TYPE in the --add-run-script, does not affect the individual layer, but the behaviour in the whole image:
action will wait until all action-run-scripts are successful finished and then also stop the service-run-scriptsservice starts all run-scripts and tries to restart services if they quitcascade like service but also stops all other services as soon as a service endsexternal like service but does not restart an ended service nor does it stop the othersThe MOS_WAIT_FOR_PORTS variable holds a comma- or semicolon-separated list of endpoints in the form: host:port[:timeout]
host hostname or IP to checkport TCP port to connect totimeout (optional) seconds to wait before giving up (default 300)sleep (optional) seconds to sleep after successful connection (default 0)The MOS_SHUTDOWN_DELAY variable defines the duration, in seconds, after which all services should be gracefully terminated.
The MOS_INCLUDE_PROCESSES variable can contain a regular expression that includes one or more processes to be started by name.
The variable MOS_EXCLUDE_PROCESSES does exactly the opposite. It ignores processes that match the regular expression.
| Path | ref. ENV-Variable | Type | Purpose |
|---|---|---|---|
| /entrypoint-logs | ENTRY_LOGS | folder | All further layers can store their own log files here in subdirectories. |
| /entrypoint-help-and-usage | ENTRY_USAGE | folder | Here you will find README-files for each docker-image-layer, including examples. |
# build base-image
> cd mosaic-hgw/Docker/images/debian
> docker build --tag="mosaicgreifswald/debian" --file="Dockerfile.debian" .
# "versions" shows all installed tools and components, with their versions.
> docker run --rm mosaicgreifswald/debian:13 versions
last updated : 2026-07-20 10:27:17
Architecture : x86_64
Distribution : Debian GNU/Linux 13.6 (trixie)
# "entrypoints" lists all registered entrypoints.
> docker run --rm mosaicgreifswald/debian entrypoints
ENTRY_LOGS : /entrypoint-logs
| Date | Tags | Changes |
|---|---|---|
| 2026-07-20 | 13.6, 13, latest | Debian 13.6 "trixie" |
| 2026-05-20 | 13.5 (Dockerfile) | Debian 13.5 "trixie" |
| 2026-03-09 | 13.3 (Dockerfile) | Debian 13.3 "trixie" fixed signal-forwarding |
| 2026-03-03 | 13.3 (Dockerfile) | Debian 13.3 "trixie" fixed process-controlling |
| 2026-01-26 | 13.3 (Dockerfile) | Debian 13.3 "trixie" |
| 2025-12-10 | 13.2 | Debian 13.2 "trixie" |
| 2025-10-29 | 13.1 (Dockerfile) | Debian 13.1 "trixie" |
| 2025-07-22 | 12.11, 12 (Dockerfile) | added script to explore and copy additional files from image to host |
| 2025-07-07 | 12.11 (Dockerfile) | Debian 12.11 "bookworm" added ENV-Variable MOS_WAIT_FOR_PORTS |
| 2025-06-13 | 12.11 | Debian 12.11 "bookworm" |
| 2025-04-25 | 12.10 (Dockerfile) | Debian 12.10 "bookworm" improved process control |
| 2025-03-05 | 12.9 (Dockerfile) | Debian 12.9 "bookworm" added support for docker-parameter --user/-u |
| 2025-01-13 | 12.8 | Debian 12.8 "bookworm" |
| 2024-09-09 | 12.7 (Dockerfile) | Debian 12.7 "bookworm" |
| 2024-07-22 | 12.6 (Dockerfile) | Debian 12.6 "bookworm" |
| 2024-05-13 | 12.5 | Debian 12.5 "bookworm" |
| 2023-12-11 | 12.4 (Dockerfile) | Debian 12.4 "bookworm" |
| 2023-10-30 | 12.2 | Debian 12.2 "bookworm" |
| 2023-09-28 | 12.1 | Debian 12.1 "bookworm" |
| 2023-07-13 | 12.0 | Debian 12.0 "bookworm" |
| 2023-04-25 | 11.7, 11 (Dockerfile) | Debian 11.7 "bullseye" |
Content type
Image
Digest
sha256:2758d8c91…
Size
35.5 MB
Last updated
2 days ago
docker pull mosaicgreifswald/debian