Skip to main content

The Good Practices

We strongly recommend you to go through the good Practices of Docker to help you learn the best way to optimize your container and its security.

Here are some tips to optimize your container to work perfectly with Arbitrium.


Versioning on your container build is an essential aspect of a container's life since a lot of environments will not pull the image again if the tag is already present on the machine.

The Tag latest#

By default, when you run the build command:

docker build -t repo/example .

The output will give to this build the tag latest

The following does the same output:

docker build -t repo/example:latest .

But keep in mind, latest is only a tag like any other and does not always represent your latest build.


docker build -t repo/example:latest .
# do some modification to your code
docker build -t repo/example:0.1 .

Arbitrium will NOT update your tag latest and version 0.1 will be ahead with the new code.

Example for Tagging#

We recommend bumping or changing your version on every image build to ensure proper usage and avoid caching the old version in the system. Suppose you are already using a system to do semantic versioning or bumping the version on every compilation. In that case, you can make the process of automatically tagging your Docker build pretty easy.

Example of Bash Script to build your Dockerfile with a matching version you pass the argument.

This example will build with the given version, tag to the repository, and push it (Do not forget to login first if you are using a private Repository).

if [[ $# -ne 1 ]] ; then
echo 'No Argument Provided, Please specify the version you want to build this Image. --> example: ./ 0.0.1'
exit 1
docker build -t edgegap/example:$1 .
docker tag edgegap/example:$1$1
docker push$1

With this script, you can now use your App build version to call it correctly.

Example: You build your new Game Server Version 2021.01.29.1234

# From your CI/CD Pipeline or manually
./ 2021.01.29.1234


The main reason to bump a tag every build is to prevent caching in the Edge.

To be able to boot the server in a matter of seconds, we pre-pull the image and only multiply the number of instances on demand. We can't guarantee the frequency of Pull Policy since we only pull it if the image is not already present on the Edge.

So basically using latest tag or any persistent tag might cause you trouble to fix or debug since you are going to update the build and deploy it on Arbitrium but the Edge won't pull the new version your tag since it is the same.

If you never use semantic versioning, Edgegap hardly suggest you read about it and apply this to your build versioning!