# Les bonnes pratiques

Nous vous recommandons vivement de parcourir [les bonnes pratiques de Docker](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) pour vous aider à apprendre la meilleure façon d'optimiser votre conteneur et sa sécurité.

Voici quelques conseils pour optimiser votre conteneur afin qu'il fonctionne parfaitement avec Edgegap.

## Gestion des versions

La gestion des versions de la construction de votre conteneur est un aspect essentiel de la vie d'un conteneur puisque de nombreux environnements ne retéléchargeront pas l'image si le tag est déjà présent sur la machine.

### Le tag *latest*

Par défaut, lorsque vous exécutez la commande build :

{% hint style="warning" %}
Pour les utilisateurs de CPU ARM (Mac M1, M2, etc.), ajoutez `--platform linux/amd64`  option à votre commande de build.
{% endhint %}

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

La sortie donnera à cette build le tag **latest**

Ce qui suit donne la même sortie :

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

Mais gardez à l'esprit, **latest** n'est qu'un tag comme un autre et ne représente pas toujours votre dernière build.

Exemple :

```bash
docker build -t repo/example:latest .
# effectuez quelques modifications dans votre code
docker build -t repo/example:0.1 .
```

Edgegap ne mettra PAS à jour votre tag **latest** et la version **0.1** sera en avance avec le nouveau code.

### Exemple pour le tagging

Nous recommandons d'augmenter ou de changer votre version à chaque build d'image afin d'assurer une utilisation correcte et d'éviter la mise en cache de l'ancienne version dans le système. Supposons que vous utilisiez déjà un système pour faire du versionnage sémantique ou augmenter la version à chaque compilation. Dans ce cas, vous pouvez rendre le processus de tagging automatique de votre build Docker assez simple.

Exemple de script Bash pour construire votre Dockerfile avec la version correspondante que vous passez en argument.

Cet exemple construira avec la version donnée, taggera le dépôt et le poussera (N'oubliez pas de vous connecter d'abord si vous utilisez un dépôt privé).

```bash
#!/bin/bash

if [[ $# -ne 1 ]] ; then
    echo 'Aucun argument fourni, veuillez spécifier la version que vous souhaitez construire pour cette image. --> exemple : ./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
```

Avec ce script, vous pouvez maintenant utiliser la version de build de votre application pour l'appeler correctement.

Exemple : Vous construisez votre nouvelle version de serveur de jeu **2021.01.29.1234**

```bash
# Depuis votre pipeline CI/CD ou manuellement

./docker-build.sh 2021.01.29.1234
```

### Pourquoi

La principale raison d'augmenter un tag à chaque build est d'empêcher la mise en cache au niveau de l'Edge.

Pour être capable de démarrer le serveur en quelques secondes, nous pré-téléchargeons l'image et ne multiplions le nombre d'instances que sur demande. Nous ne pouvons pas garantir la fréquence de la politique de pull puisque nous ne la téléchargeons que si l'image n'est pas déjà présente sur l'Edge.

Donc essentiellement en utilisant **latest** un tag ou tout tag persistant pourrait vous causer des problèmes pour corriger ou déboguer puisque vous allez mettre à jour la build et la déployer sur Edgegap mais l'Edge ne téléchargera pas la nouvelle *version* de votre tag puisqu'elle est la même.

Si vous n'utilisez jamais [le versionnage sémantique](https://semver.org/), Edgegap vous suggère vivement d'en lire davantage et d'appliquer cela à la gestion des versions de vos builds !


---

# 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.edgegap.com-fr/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.