La soluzione DOCKER:
Sembra che docker-compose 1.5+ abbia abilitato la sostituzione delle variabili: https://github.com/docker/compose/releases
L'ultima Docker Compose ti consente di accedere alle variabili di ambiente dal tuo file di composizione. Quindi puoi generare le variabili di ambiente, quindi eseguire Compose in questo modo:
set -a
source .my-env
docker-compose up -d
Quindi puoi fare riferimento alle variabili in docker-compose.yml usando $ {VARIABLE}, in questo modo:
db:
image: "postgres:${POSTGRES_VERSION}"
Ed ecco ulteriori informazioni dai documenti, prese qui: https://docs.docker.com/compose/compose-file/#variable-substitution
Quando si esegue docker-compose con questa configurazione, Compose cerca la variabile d'ambiente POSTGRES_VERSION nella shell e ne sostituisce il valore. In questo esempio, Compose risolve l'immagine in postgres: 9.3 prima di eseguire la configurazione.
Se non viene impostata una variabile di ambiente, Componi sostituisce con una stringa vuota. Nell'esempio sopra, se POSTGRES_VERSION non è impostato, il valore per l'opzione image è postgres :.
Sono supportate la sintassi $ VARIABLE e $ {VARIABLE}. Le funzionalità estese in stile shell, come $ {VARIABLE-default} e $ {VARIABLE / foo / bar}, non sono supportate.
Se è necessario inserire un valore letterale in un valore di configurazione, utilizzare un doppio simbolo del dollaro ($$).
E credo che questa funzione sia stata aggiunta in questa richiesta pull: https://github.com/docker/compose/pull/1765
La soluzione BASH:
Ho notato che la gente ha problemi con il supporto delle variabili d'ambiente di Docker. Invece di gestire le variabili di ambiente in Docker, torniamo alle basi, come bash! Ecco un metodo più flessibile che utilizza uno script bash e un .envfile.
Un file .env di esempio:
EXAMPLE_URL=http://example.com
# Note that the variable below is commented out and will not be used:
# EXAMPLE_URL=http://example2.com
SECRET_KEY=ABDFWEDFSADFWWEFSFSDFM
# You can even define the compose file in an env variable like so:
COMPOSE_CONFIG=my-compose-file.yml
# You can define other compose files, and just comment them out
# when not needed:
# COMPOSE_CONFIG=another-compose-file.yml
quindi esegui questo script bash nella stessa directory, che dovrebbe distribuire tutto correttamente:
#!/bin/bash
docker rm -f `docker ps -aq -f name=myproject_*`
set -a
source .env
cat ${COMPOSE_CONFIG} | envsubst | docker-compose -f - -p "myproject" up -d
Basta fare riferimento alle variabili env nel file di composizione con la solita sintassi bash (cioè ${SECRET_KEY}per inserire il SECRET_KEYdal .envfile).
Nota che COMPOSE_CONFIGè definito nel mio .envfile e usato nel mio script bash, ma puoi semplicemente sostituirlo {$COMPOSE_CONFIG}con my-compose-file.ymlin nello script bash.
Nota anche che ho etichettato questa distribuzione nominando tutti i miei contenitori con il prefisso "myproject". Puoi usare qualsiasi nome tu voglia, ma aiuta a identificare i tuoi contenitori in modo da poterli facilmente consultare in seguito. Supponendo che i contenitori siano apolidi, come dovrebbero essere, questo script rimuoverà e ridistribuirà rapidamente i contenitori in base ai parametri del file .env e al file YAML di composizione.
Aggiornamento
Poiché questa risposta sembra piuttosto popolare, ho scritto un post sul blog che descrive il mio flusso di lavoro di distribuzione Docker in modo più approfondito: http://lukeswart.net/2016/03/lets-deploy-part-1/ Questo potrebbe essere utile quando aggiungi maggiore complessità per una configurazione di distribuzione, come config nginx, LetsEncrypt certs e contenitori collegati.