This page is an updated version of the original Docker builds announcement

Docker builds

These are TurnKey builds optimized to run as docker containers, supporting automatic download via the docker public index.

All TurnKey appliances are available on the Docker Hub (generously provided by Docker, Inc), which streamlines deployment. For example:

docker pull turnkeylinux/core-14.2
docker run -i -t -d turnkeylinux/core-14.2

Docker containers can be run in the foreground or the background, so we've tried our best to support all use cases with regards to initialization (aka. inithooks) - secret regeneration, setting of passwords, application configuration, etc. 

Depending on your use case, we recommend two options:

Option 1: Initialization via ssh (interactive)

On first login, you will be prompted to initialize the appliance.

CID=$(docker run -i -t -d turnkeylinux/core-14.2)
CIP=$(docker inspect --format='{{.NetworkSettings.IPAddress}}' $CID)
docker logs $CID | grep "Random initial root password"
ssh root@$CIP

Option 2: Create new image with preseeded values (non-interactive)

The appliance will initialize itself with the provided configuration.  Once initialized, the configuration will be deleted. For more information see inithooks.

mkdir /root/wordpress

cat > /root/wordpress/inithooks.conf <<EOF
export ROOT_PASS=secretrootpass
export DB_PASS=secretmysqlpass
export APP_PASS=secretadminwppass

cat > /root/wordpress/Dockerfile <<EOF
FROM turnkeylinux/wordpress-14.2
ADD inithooks.conf /etc/inithooks.conf

docker build -t wordpress-14.2 /root/wordpress
docker run -i -t -d wordpress-14.2


Pre-configured run command

Docker is designed for "application or process" containers - for example, running mysql, and only mysql. Docker short-circuits /sbin/init so you can't really "boot" a container like in vanilla LXC.

To work around this, we've included /usr/sbin/ (default run command) which will start all services and drop to a shell. When the shell is exited, the services will be stopped. For this reason, SSH is recommended for regular console usage.

STDIN and TTY options required

The -i and -t options are required to attach STDIN and allocate a TTY to the container. There have been moves by Docker to allow this to be pre-configured but we haven't yet looked deeper into that and are not up to date on hte current state of play.

Pre-configured to expose ports

All TurnKey Docker appliances are configured to expose their custom services. This means that the host can access the services, but they are not exposed to the network.

Exposing ports to the network needs to be done at runtime (docs), for example:

# bind port 80 on the host to the container's port 80
docker run -i -t -d -p 80:80 turnkeylinux/lamp-14.2

Or to use an alternate host port:

# bind port 8080 on the host to the container's port 80
docker run -i -t -d -p turnkeylinux/lamp-14.2

Skipping security updates on first boot

During development I added support to to override the default SEC_UPDATES value to speed up my testing. I was going to remove this support or leave it undocumented, but decided others might find it useful when testing (and only in testing).

docker run -i -t -d -e SEC_UPDATES=SKIP turnkeylinux/openldap-14.2


Patrice Lazareff's picture

Hello, When calling a container from a docker-compose file (image: turnkeylinux/lamp-14.2) it starts well and stops immediately as I guess the shell called by is automatically exited by docker-compose. Any way around this, or am I missing something ? Kind regards, p@T
Jeremy Davis's picture

FWIW, it's probably best to post in the forums, rather than comment on docs. There is no easy way for me to see unanswered doc comments, so if I miss the initial notification in my inbox, the post will go answered (as happened to you here).

I'm not really sure why docker compose doesn't work as expected. Personally I'm not very familiar with Docker at all, let alone with docker compose. So I'm probably not much immediate help.

My guess is that you are correct. But how that might be addressed, I'm not really sure, sorry.

My hope is that it will be resolved when we finally move to our new appliance model (based on containers rather than a monolithic server). Then we will be building proper containers (rather than the hacky way we currently build them).

Having said that, that won't be happening anytime soon. So in the meantime, I've lodged it as a bug and will try to address it once we have our next release of appliance ISOs published (i.e. before we release the v15.0 Docker builds).

Bernhard Seebass's picture

docker stop <container> does not properly stop "turnkeylinux/core-14.2": the trap as defined in is not executed. Docker version 17.09.1-ce  running on Linux (OpenSuSE Tumbleweed) Here is a modified version of that worked for me (use sleep instead su and exit on recieving signal):

# not recommended, useful for testing though...
if [ -n "$SEC_UPDATES" ]; then

run-parts -a start /etc/rc2.d
trap "run-parts -a stop /etc/rc2.d; exit 0" INT TERM EXIT


if [ -x /root/.profile.d/turnkey-init-fence ]; then

WARNING: The container requires initialization (performed on first login).
This can be performed from the host as follows:

    CID=\$(docker ps -l -q)
    CIP=\$(docker inspect --format='{{.NetworkSettings.IPAddress}}' \$CID)
    docker logs \$CID | grep "Random initial root password"
    ssh root@\$CIP

#WARNING: Exiting this shell will stop the container.
#For regular console usage, SSH is recommended.


while true
    # wait for SIGINT, SIGTERM or SIGEXIT (see trap above)
    # signal is only recieved while not sleeping, therefore use a short sleep period
    sleep 0.5

Jeremy Davis's picture

And extra brownie points for the fix/workaround! :)

FWIW, I've open an issue on our tracker, so this doesn't get forgotten for our upcoming release.