Creating a Docker Image

This guide will teach you how to create and configure a Docker image for a custom service in the Panel.

Assumptions

This tutorial uses examples from our core:java-glibc docker image, which can be found on Github. This tutorial also assumes some knowledge of Docker, we suggest reading up if this all looks foreign to you.

Creating the Dockerfile

The most important part of this process is to create the Dockerfile that will be used by the Daemon. Due to heavy restrictions on server containers, you must setup this file in a specific manner.

We try to make use of Alpine Linux as much as possible for our images in order to keep their size down.

# ----------------------------------
# Pterodactyl Core Dockerfile
# Environment: Java (glibc support)
# Minimum Panel Version: 0.6.0
# ----------------------------------
FROM frolvlad/alpine-oraclejdk8:cleaned

MAINTAINER Pterodactyl Software, <support@pterodactyl.io>

RUN apk update \
    && apk upgrade \
    && apk add --no-cache --update curl ca-certificates openssl git tar bash \
    && adduser -D -h /home/container container

USER container
ENV  USER container
ENV  HOME /home/container

WORKDIR /home/container

COPY ./entrypoint.sh /entrypoint.sh

CMD ["/bin/bash", "/entrypoint.sh"]

Lets walk through the Dockerfile above. The first thing you'll notice is the FROM declaration.

FROM frolvlad/alpine-oraclejdk8:cleaned

In this case, we are using frolvlad/alpine-oraclejdk8 which provides us with Java 8 including glibc support which is necessary for certain Minecraft software.

Installing Dependencies

The next thing we do is install the dependencies we will need using Alpine's package manager: apk. You'll notice some specific flags that keep the container small, including --no-cache, as well as everything being contained in a single RUN block.

Creating a Container User

Within this RUN block, you'll notice the useradd command.

adduser -D -h /home/container container

All Pterodactyl containers must have a user named container, and the user home must be /home/container.

After we create that user, we then define the default container USER as well as a few ENV settings to be applied to things running within the container.

Work Directory & Entrypoint

One of the last things we do is define a WORKDIR which is where everything else will be executed. The WORKDIR must be set the /home/container.

Finally, we need to copy our ENTRYPOINT script into the docker image root. This is done using COPY, after which we define the command to be used when the container is started using CMD. The CMD line should always point to the entrypoint.sh file.

COPY ./entrypoint.sh /entrypoint.sh
CMD ["/bin/bash", "/entrypoint.sh"]

Entrypoint Script

In order to complete this Dockerfile, we will need an entrypoint.sh file which tells Docker how to run this specific server type.

These entrypoint files are actually fairly abstracted, and the Daemon will pass in the start command as an environment variable before processing it and then executing the command.

#!/bin/bash
sleep 5

cd /home/container

# Output Current Java Version
java -version

# Replace Startup Variables
MODIFIED_STARTUP=`eval echo $(echo ${STARTUP} | sed -e 's/{{/${/g' -e 's/}}/}/g')`
echo ":/home/container$ ${MODIFIED_STARTUP}"

# Run the Server
${MODIFIED_STARTUP}

Lets walk though this file. At the top, you'll notice sleep 5. This is not required, but ensures the Daemon has enough time to connect to the container and get everything queued up for display on the user's screen. You can likely reduce this to sleep 2 or remove it entirely.

The second command, cd /home/container, simply ensures we are in the correct directory when running the rest of the commands. We then follow that up with java -version to output this information to end-users, but that is not necessary.

Modifying the Startup Command

The most significant part of this file is the MODIFIED_STARTUP environment variable. What we are doing in this case is parsing the environment STARTUP that is passed into the container by the Daemon. In most cases, this variable looks something like the example below:

STARTUP="java -Xms128M -Xmx{{SERVER_MEMORY}}M -jar {{SERVER_JARFILE}}"

You'll notice some placeholders there, specifically {{SERVER_MEMORY}} and `{{SERVER_JARFILE}}. These both refer to other environment variables being passed in, and they look something like the example below.

SERVER_MEMORY=1024
SERVER_JARFILE=server.jar

There are a host of different environment variables, and they change depending on the specific service option configuration. However, that is not necessarily anything to worry about here.

MODIFIED_STARTUP=`eval echo $(echo ${STARTUP} | sed -e 's/{{/${/g' -e 's/}}/}/g')`

The command above simply evaluates the STARTUP environment variable, and then replaces anything surrounded in curly braces ({{EXAMPLE}}) with a matching environment variable (such as EXAMPLE). Thus, our STARTUP command:

java -Xms128M -Xmx{{SERVER_MEMORY}}M -jar {{SERVER_JARFILE}}

Becomes:

java -Xms128M -Xmx1024M -jar server.jar

Run the Command

The last step is to run this modified startup command, which is done with the line ${MODIFIED_STARTUP}.