# The Good Practices

We strongly recommend you to go through [the good Practices of Docker](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) 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 Edgegap.

## Versioning

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:

{% hint style="warning" %}
For ARM CPU (Mac M1, M2, etc.) users, add `--platform linux/amd64`  option to your build command.
{% endhint %}

```bash
docker build -t repo/example .
```

The output will give to this build the tag **latest**

The following does the same output:

```bash
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.

Example:

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

Edgegap 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).

```bash
#!/bin/bash

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

docker build -t my-repo/example:$1 .

docker tag my-repo/example:$1 registry.edgegap.com/my-repo/example:$1
docker push registry.edgegap.com/my-repo/example:$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**

```bash
# From your CI/CD Pipeline or manually

./docker-build.sh 2021.01.29.1234
```

### Why

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 Edgegap but the Edge won't pull the new *version* your tag since it is the same.

If you never use [semantic versioning](https://semver.org/), Edgegap hardly suggest you read about it and apply this to your build versioning!


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.edgegap.com/docs/tools-and-integrations/container/good-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.