Réponses:
Vous pouvez transmettre des variables d'environnement à vos conteneurs avec l' -e
indicateur.
Un exemple tiré 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ù elle sera affichée ps
, etc., vous -e
pouvez extraire la valeur de l'environnement actuel si vous la donnez sans =
:
sudo PASSWORD='foo' docker run [...] -e PASSWORD [...]
Si vous avez de nombreuses 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 attend que chaque ligne soit au format VAR = VAL, imitant l'argument passé à --env. Les lignes de commentaires doivent uniquement être préfixées avec #
export PASSWORD=foo
place et la variable sera transmise en docker run
tant que variable d'environnement, ce qui rendra le docker run -e PASSWORD
travail.
Vous pouvez passer en utilisant des -e
paramètres avec la docker run ..
commande 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 l'exécutez.
Pour ce faire plus sûr, vous pouvez écrire vos informations d' identification dans un fichier de configuration et faire docker run
avec --env-file
comme mentionné ici . Ensuite, vous pouvez contrôler l'accès à ce fichier de configuration afin que les autres personnes ayant accès à cette machine ne voient pas vos informations d'identification.
--env-file
, lorsque vous utilisez --env
vos valeurs env seront citées / échappées avec la sémantique standard de tout shell que vous utilisez, mais lors de l'utilisation --env-file
des valeurs que vous obtiendrez à l'intérieur de votre conteneur sera différente. La commande docker run lit simplement le fichier, effectue une analyse très basique et transmet les valeurs au conteneur, ce n'est pas équivalent à la façon dont votre shell se comporte. Juste un petit truc à savoir si vous convertissez un tas d' --env
entrées en un --env-file
.
Si vous utilisez 'docker-compose' comme méthode pour faire tourner vos conteneurs, il existe en fait un moyen utile de passer une variable d'environnement définie sur votre serveur au conteneur Docker.
Dans votre docker-compose.yml
fichier, disons que vous faites tourner un conteneur hapi-js de base et que le code ressemble à:
hapi_server:
container_name: hapi_server
image: node_image
expose:
- "3000"
Supposons que le serveur local sur lequel se trouve votre projet Docker possède une variable d'environnement nommée 'NODE_DB_CONNECT' que vous souhaitez transmettre à votre conteneur hapi-js et que vous souhaitez que son nouveau nom soit 'HAPI_DB_CONNECT'. Ensuite, dans le docker-compose.yml
fichier, vous passeriez la variable d'environnement local au conteneur et le renommeriez 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 de base de données dans n'importe quel fichier de votre conteneur!
En utilisant docker-compose
, vous pouvez hériter des variables env dans docker-compose.yml et ensuite tout Dockerfile appelé par docker-compose
pour construire des images. Ceci est utile lorsque la Dockerfile
RUN
commande doit exécuter des commandes spécifiques à l'environnement.
(votre shell existe RAILS_ENV=development
déjà 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 de variables d'environnement dans les fichiers ou les commandes docker-compose
build
/ up
:
docker-compose build
docker-compose up
Utilisation -e
valeur ou --env pour définir les variables d'environnement (par défaut []).
Un exemple tiré 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, avant chaque variable d'environnement, utilisez l' -e
indicateur.
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.
Si vous devez configurer de nombreuses variables, utilisez le --env-file
indicateur
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/
ubuntu bash
? Cela s'applique-t-il aux images créées avec ubuntu comme image de base ou à chaque image?
-e
arguments il y a longtemps! Je ne peux même pas commencer à comprendre pourquoi ils ont rendu cela nécessaire ...
Il existe un bon hack pour diriger les variables d'environnement de la machine hôte vers un conteneur Docker:
env > env_file && docker run --env-file env_file image_name
Utilisez cette technique très soigneusement, car
env > env_file
elle videra TOUTES les variables ENV de la machine hôteenv_file
et les rendra accessibles dans le conteneur en cours d'exécution.
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 de blog Comment gérer les secrets pour les applications basées sur Amazon EC2 Container Service en utilisant Amazon S3 et Docker .
Si vous avez les variables d'environnement env.sh
localement et que vous souhaitez les configurer au démarrage du conteneur, vous pouvez essayer
COPY env.sh /env.sh
COPY <filename>.jar /<filename>.jar
ENTRYPOINT ["/bin/bash" , "-c", "source /env.sh && printenv && java -jar /<filename>.jar"]
Cette commande démarrerait le conteneur avec un shell bash (je veux un shell bash car source
c'est une commande bash), source le env.sh
fichier (qui définit les variables d'environnement) et exécute le fichier jar.
Le env.sh
ressemble à ça,
#!/bin/bash
export FOO="BAR"
export DB_NAME="DATABASE_NAME"
J'ai ajouté la printenv
commande uniquement pour tester le fonctionnement de la commande source réelle. Vous devez probablement le supprimer lorsque vous confirmez que la commande source fonctionne correctement ou que les variables d'environnement apparaissent dans vos journaux Docker.
--env-file
argument à une docker run
commande. Par exemple, si vous déployez une application à l'aide du moteur d'application Google et que l'application s'exécutant à l'intérieur du conteneur nécessite des variables d'environnement définies dans le conteneur Docker, vous n'avez pas d'approche directe pour définir les variables d'environnement car vous n'avez pas le contrôle sur la docker run
commande . Dans un tel cas, vous pourriez avoir un script qui déchiffre les variables env à l'aide de disons, KMS, et les ajoute à celui env.sh
qui peut être obtenu pour définir les variables env.
.
(dot) disponible dans regular sh
au lieu de source
. ( source
est le même que .
)
Utiliser jq pour convertir l'env en JSON:
env_as_json=`jq -c -n env`
docker run -e HOST_ENV="$env_as_json" <image>
cela nécessite jq version 1.6 ou plus récente
cela pust l'hôte env comme json, essentiellement comme dans Dockerfile:
ENV HOST_ENV (all env from the host as json)
docker run -e HOST_ENV="$env_as_json" <image>
? : ? Dans mon cas, Docker ne semble pas résoudre les variables ou les sous-coquilles ( ${}
ou $()
) lorsqu'il est passé en tant qu'arguments de docker. Par exemple: A=123 docker run --rm -it -e HE="$A" ubuntu
puis à l'intérieur de ce conteneur: root@947c89c79397:/# echo $HE root@947c89c79397:/#
.... La HE
variable ne le fait pas.
nous pouvons également héberger la variable d'environnement de la machine en utilisant l'option -e et $:
docker run -it -e MG_HOST=$MG_HOST -e MG_USER=$MG_USER -e MG_PASS=$MG_PASS -e MG_AUTH=$MG_AUTH -e MG_DB=$MG_DB -t image_tag_name_and_version
En utilisant cette méthode, définissez la variable env automatiquement avec votre prénom dans mon cas (MG_HOST, MG_USER)
Si vous utilisez python, vous pouvez accéder à ces variables d'environnement dans docker en
import os
host,username,password,auth,database=os.environ.get('MG_HOST'),os.environ.get('MG_USER'),os.environ.get('MG_PASS'),os.environ.get('MG_AUTH'),os.environ.get('MG_DB')
docker run --rm -it --env-file <(bash -c 'env | grep <your env data>')
Est un moyen de récupérer les données stockées dans un .env
et de les transmettre à Docker, sans que rien ne soit stocké de manière non sécurisée (vous ne pouvez donc pas simplement regarder docker history
et saisir des clés.
Supposons que vous ayez un tas de trucs AWS .env
:
AWS_ACCESS_KEY: xxxxxxx
AWS_SECRET: xxxxxx
AWS_REGION: xxxxxx
l'exécution de docker avec `` `docker run --rm -it --env-file <(bash -c 'env | grep AWS_') récupérera tout et le passera en toute sécurité pour être accessible à partir du conteneur.