# Prise en charge de Dockerfile pour GitHub Actions Lors de la création d’une Dockerfile pour une action de conteneur Docker, vous devez savoir comment certaines instructions Docker interagissent avec GitHub Actions et le fichier de métadonnées d’une action. > \[!NOTE] > Les exécuteurs hébergés sur GitHub Enterprise Server ne sont pas pris en charge sur GitHub. ### Utilisateur Les actions Docker doivent être exécutées par l’utilisateur Docker par défaut (racine). N’utilisez pas l’instruction `USER` dans votre `Dockerfile`, car vous ne pouvez pas accéder au répertoire `GITHUB_WORKSPACE`. Pour plus d’informations, consultez « [Références des variables](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/variables#default-environment-variables) » et [USER reference](https://docs.docker.com/engine/reference/builder/#user) dans la documentation Docker. ### FROM La première instruction du fichier `Dockerfile` doit être `FROM`, qui sélectionne une image de base Docker. Pour plus d’informations, consultez [FROM reference](https://docs.docker.com/engine/reference/builder/#from) dans la documentation Docker. Voici quelques bonnes pratiques concernant la définition de l’argument `FROM` : * Il est recommandé d’utiliser des images Docker officielles. Par exemple, `python` ou `ruby`. * Utilisez une étiquette de version s’il en existe une, de préférence avec une version principale. Par exemple, utilisez `node:10` au lieu de `node:latest`. * Il est recommandé d’utiliser des images Docker basées sur le système d’exploitation [Debian](https://www.debian.org/). ### WORKDIR GitHub définit le chemin du répertoire de travail dans la variable d’environnement `GITHUB_WORKSPACE` . Il est recommandé de ne pas utiliser l’instruction `WORKDIR` dans votre `Dockerfile`. Avant l’exécution de l’action, GitHub montera le répertoire `GITHUB_WORKSPACE` à la place de tout ce qui se trouvait à cet emplacement dans l’image Docker et définira `GITHUB_WORKSPACE` comme répertoire de travail. Pour plus d’informations, consultez « [Références des variables](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/variables#default-environment-variables) » et [WORKDIR reference](https://docs.docker.com/engine/reference/builder/#workdir) dans la documentation Docker. ### Point d'entrée Si vous définissez `entrypoint` dans le fichier de métadonnées d’une action, cela remplacera le fichier `ENTRYPOINT` défini dans le `Dockerfile`. Pour plus d’informations, consultez « [Référence syntaxique des métadonnées](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsentrypoint) ». L’instruction Docker `ENTRYPOINT` peut avoir un format *shell* ou un format *exec*. La documentation Docker `ENTRYPOINT` recommande d’utiliser le format *exec* de l’instruction `ENTRYPOINT`. Pour plus d’informations sur les formats *exec* et *shell*, consultez la [ENTRYPOINT reference](https://docs.docker.com/engine/reference/builder/#entrypoint) dans la documentation Docker. Vous ne devez pas utiliser `WORKDIR` pour spécifier votre point d’entrée dans le Dockerfile. Au lieu de cela, vous devez utiliser un chemin absolu. Pour plus d’informations, consultez [WORKDIR](#workdir). Si vous configurez votre conteneur pour utiliser le format *exec* de l’instruction `ENTRYPOINT`, les `args` configurés dans le fichier de métadonnées de l’action ne s’exécuteront pas dans un interpréteur de commandes. Si les `args` de l’action contiennent une variable d’environnement, celle-ci ne sera pas substituée. Par exemple, l’utilisation du format *exec* suivant n’affiche pas la valeur stockée dans `$GITHUB_SHA`, mais affiche `"$GITHUB_SHA"` à la place. ```dockerfile ENTRYPOINT ["echo $GITHUB_SHA"] ``` Si vous souhaitez une substitution de variable, utilisez le format *shell* ou exécutez directement un interpréteur de commandes. Par exemple, à l’aide du format *exec* suivant, vous pouvez exécuter un interpréteur de commandes pour afficher la valeur stockée dans la variable d’environnement `GITHUB_SHA`. ```dockerfile ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"] ``` Pour fournir les `args` définis dans le fichier de métadonnées de l’action à un conteneur Docker qui utilise le format *exec* dans `ENTRYPOINT`, nous vous recommandons de créer un script shell nommé `entrypoint.sh` que vous appellerez à partir de l’instruction `ENTRYPOINT` : #### Exemple de *Dockerfile* ```dockerfile # Container image that runs your code FROM debian:9.5-slim # Copies your code file from your action repository to the filesystem path `/` of the container COPY entrypoint.sh /entrypoint.sh # Executes `entrypoint.sh` when the Docker container starts up ENTRYPOINT ["/entrypoint.sh"] ``` #### Exemple de fichier *entrypoint.sh* En utilisant l’exemple de Dockerfile ci-dessus, GitHub enverra le `args` configuré dans le fichier de métadonnées de l’action comme arguments à `entrypoint.sh`. Ajoutez le `#!/bin/sh`[shebang](https://en.wikipedia.org/wiki/Shebang_\(Unix\)) en haut du fichier `entrypoint.sh` pour utiliser explicitement l’interpréteur de commandes compatible [POSIX](https://en.wikipedia.org/wiki/POSIX) du système. ```shell #!/bin/sh # `$#` expands to the number of arguments and `$@` expands to the supplied `args` printf '%d args:' "$#" printf " '%s'" "$@" printf '\n' ``` Votre code doit être exécutable. Vérifiez que le fichier `entrypoint.sh` dispose d’autorisations `execute` avant de l’utiliser dans un workflow. Vous pouvez modifier l’autorisation à partir de votre terminal à l’aide de cette commande : ```shell chmod +x entrypoint.sh ``` Lorsqu’un script shell `ENTRYPOINT` n’est pas exécutable, vous recevez une erreur similaire à celle-ci : ```shell Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown ``` ### CMD Si vous définissez `args` dans le fichier de métadonnées de l’action, `args` remplacera l’instruction `CMD` spécifiée dans le fichier de métadonnées de l’action `Dockerfile`. Pour plus d’informations, consultez « [Référence syntaxique des métadonnées](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsargs) ». Si vous utilisez `CMD` dans votre `Dockerfile`application, suivez les instructions suivantes : 1. Documentez les arguments requis dans le fichier README de l’action et omettez-les de l’instruction `CMD`. 2. Utilisez les valeurs par défaut qui autorisent l’utilisation de l’action sans spécifier aucune valeur `args`. 3. Si l’action expose un indicateur `--help`, ou quelque chose de similaire, utilisez-le pour rendre votre action auto-documentée. ## Fonctionnalités Linux prises en charge GitHub Actions prend en charge les fonctionnalités Linux par défaut prises en charge par Docker. Il n’est pas possible d’ajouter ni de supprimer des fonctionnalités. Pour plus d’informations sur les fonctionnalités Linux par défaut qui sont prises en charge par Docker, consultez « [Capacités du noyau Linux](https://docs.docker.com/engine/security/#linux-kernel-capabilities) » dans la documentation Docker. Pour en savoir plus sur les fonctionnalités Linux, consultez « [Overview of Linux capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html) » dans les pages de manuel Linux.