Comment transmettre des variables d’environnement aux conteneurs Docker?

Vous pouvez transmettre des variables d’environnement à vos conteneurs avec l’indicateur -e .

Un exemple d’un script de démarrage:

 sudo docker run -d -t -i -e REDIS_NAMESPACE='staging' \ -e POSTGRES_ENV_POSTGRES_PASSWORD='foo' \ -e POSTGRES_ENV_POSTGRES_USER='bar' \ -e POSTGRES_ENV_DB_NAME='mysite_staging' \ -e POSTGRES_PORT_5432_TCP_ADDR='docker-db-1.hidden.us-east-1.rds.amazonaws.com' \ -e SITE_URL='staging.mysite.com' \ -p 80:80 \ --link redis:redis \ --name container_name dockerhub_id/image_name 

Ou, si vous ne voulez pas avoir la valeur sur la ligne de commande où il sera affiché par ps , etc., -e peut extraire la valeur de l’environnement actuel si vous le donnez simplement sans le = :

 sudo PASSWORD='foo' docker run [...] -e PASSWORD [...] 

Si vous avez beaucoup de variables d’environnement et surtout si elles sont censées être secrètes, vous pouvez utiliser un fichier env :

 $ docker run --env-file ./env.list ubuntu bash 

L’indicateur –env-file prend un nom de fichier comme argument et s’attend à ce que chaque ligne soit au format VAR = VAL, imitant l’argument passé à –env. Les lignes de commentaires ne doivent être précédées que du préfixe #

Vous pouvez passer à l’aide des parameters -e avec la commande docker run .. comme mentionné ici et comme mentionné par @errata.
Cependant, l’inconvénient possible de cette approche est que vos informations d’identification seront affichées dans la liste des processus, où vous les exécuterez.
Pour le rendre plus sûr, vous pouvez écrire vos informations d’identification dans un fichier de configuration et docker run avec --env-file comme indiqué ici . Vous pouvez ensuite contrôler l’access à ce fichier de configuration afin que les autres utilisateurs ayant access à cette machine ne puissent pas voir vos informations d’identification.

Si vous utilisez ‘docker-compose’ comme méthode pour faire apparaître vos conteneurs, il existe un moyen utile de transmettre une variable d’environnement définie sur votre serveur au conteneur Docker.

Dans votre fichier docker-compose.yml , supposons que vous développiez un conteneur hapi-js de base et que le code ressemble à ceci:

 hapi_server: container_name: hapi_server image: node_image expose: - "3000" 

Supposons que le serveur local sur lequel se trouve votre projet docker dispose d’une variable d’environnement nommée ‘NODE_DB_CONNECT’ que vous souhaitez transmettre à votre conteneur hapi-js et que vous souhaitiez que son nouveau nom soit ‘HAPI_DB_CONNECT’. Ensuite, dans le fichier docker-compose.yml , vous docker-compose.yml la variable d’environnement local au conteneur et vous le renommez comme suit:

 hapi_server: container_name: hapi_server image: node_image environment: - HAPI_DB_CONNECT=${NODE_DB_CONNECT} expose: - "3000" 

J’espère que cela vous aidera à éviter de coder en dur une chaîne de connexion à une firebase database dans n’importe quel fichier de votre conteneur!

Utilisez la valeur -e ou –env pour définir les variables d’environnement (default []).

Un exemple d’un script de démarrage:

  docker run -e myhost='localhost' -it busybox sh 

Si vous souhaitez utiliser plusieurs environnements à partir de la ligne de commande, utilisez l’indicateur -e avant chaque variable d’environnement.

Exemple:

  sudo docker run -d -t -i -e NAMESPACE='staging' -e PASSWORD='foo' busybox sh 

Remarque: Assurez-vous de mettre le nom du conteneur après la variable d’environnement, pas avant cela.

Si vous devez configurer de nombreuses variables, utilisez l’ --env-file

Par exemple,

  $ docker run --env-file ./my_env ubuntu bash 

Pour toute autre aide, consultez l’aide de Docker:

  $ docker run --help 

Documentation officielle: https://docs.docker.com/compose/environment-variables/

En utilisant docker-compose , l’exemple ci-dessous montre comment vous pouvez hériter des variables d’environnement shell à la fois dans docker-compose.yml et dans chaque fichier Dockerfile appelé par docker-compose pour construire des images. J’ai trouvé cela utile, disons, dans la commande Dockerfile RUN je dois exécuter des commandes spécifiques à l’environnement.

(votre shell a RAILS_ENV=development déjà existant dans l’environnement)

docker-compose.yml :

 version: '3.1' services: my-service: build: #$RAILS_ENV is referencing the shell environment RAILS_ENV variable #and passing it to the Dockerfile ARG RAILS_ENV #the syntax below ensures that the RAILS_ENV arg will default to #production if empty. #note that is dockerfile: is not specified it assumes file name: Dockerfile context: . args: - RAILS_ENV=${RAILS_ENV:-production} environment: - RAILS_ENV=${RAILS_ENV:-production} 

Dockerfile :

 FROM ruby:2.3.4 #give ARG RAILS_ENV a default value = production ARG RAILS_ENV=production #assign the $RAILS_ENV arg to the RAILS_ENV ENV so that it can be accessed #by the subsequent RUN call within the container ENV RAILS_ENV $RAILS_ENV #the subsequent RUN call accesses the RAILS_ENV ENV variable within the container RUN if [ "$RAILS_ENV" = "production" ] ; then echo "production env"; else echo "non-production env: $RAILS_ENV"; fi 

De cette façon, je n’ai pas besoin de spécifier les variables d’environnement dans les fichiers ou up commandes de build / up docker-compose :

 docker-compose build docker-compose up 

Pour Amazon AWS ECS / ECR, vous devez gérer vos variables d’environnement (en particulier les secrets ) via un compartiment S3 privé. Voir l’article sur le blog Comment gérer les secrets des applications basées sur des services de conteneur Amazon EC2 à l’aide d’Amazon S3 et de Docker .

Une autre méthode consiste à utiliser les pouvoirs de /usr/bin/env :

 docker run ubuntu env DEBUG=1 path/to/script.sh 

Si vous avez les variables d’environnement dans un env.sh localement et que vous voulez le configurer au démarrage du conteneur, vous pouvez essayer

 COPY env.sh /env.sh COPY .jar /.jar ENTRYPOINT ["/bin/bash" , "-c", "source /env.sh && printenv && java -jar /.jar"] 

Cette commande démarre le conteneur avec un shell bash (je veux un shell bash car source est une commande bash), source le fichier env.sh (qui définit les variables d’environnement) et exécute le fichier jar.

L’ env.sh ressemble à ceci,

 #!/bin/bash export FOO="BAR" export DB_NAME="DATABASE_NAME" 

J’ai ajouté la commande printenv uniquement pour tester le fonctionnement de la commande source. Vous devriez probablement le supprimer lorsque vous confirmez que la commande source fonctionne correctement ou que les variables d’environnement apparaissent dans les journaux de votre menu fixe.