A solução DOCKER:
Parece que o docker-compose 1.5+ ativou a substituição de variáveis: https://github.com/docker/compose/releases
O último Docker Compose permite acessar variáveis de ambiente do seu arquivo de composição. Assim, você pode originar suas variáveis de ambiente e executar o Compose da seguinte maneira:
set -a
source .my-env
docker-compose up -d
Em seguida, você pode fazer referência às variáveis no docker-compose.yml usando $ {VARIABLE}, da seguinte maneira:
db:
image: "postgres:${POSTGRES_VERSION}"
E aqui estão mais informações dos documentos, obtidas aqui: https://docs.docker.com/compose/compose-file/#variable-substitution
Quando você executa o docker-compose com essa configuração, o Compose procura a variável de ambiente POSTGRES_VERSION no shell e substitui seu valor. Nesse exemplo, o Compose resolve a imagem para o postgres: 9.3 antes de executar a configuração.
Se uma variável de ambiente não estiver configurada, Redigir substituirá por uma sequência vazia. No exemplo acima, se POSTGRES_VERSION não estiver definido, o valor da opção de imagem será postgres :.
A sintaxe $ VARIABLE e $ {VARIABLE} são suportadas. Recursos estendidos no estilo de shell, como $ {VARIABLE-default} e $ {VARIABLE / foo / bar}, não são suportados.
Se você precisar colocar um cifrão literal em um valor de configuração, use um cifrão duplo ($$).
E acredito que esse recurso foi adicionado a esta solicitação de recebimento : https://github.com/docker/compose/pull/1765
A solução BASH:
Percebo que as pessoas têm problemas com o suporte a variáveis de ambiente do Docker. Em vez de lidar com variáveis de ambiente no Docker, vamos voltar ao básico, como o bash! Aqui está um método mais flexível usando um script bash e um .envarquivo.
Um arquivo .env de exemplo:
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
em seguida, execute este script bash no mesmo diretório, que deve implantar tudo corretamente:
#!/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 referenciar suas variáveis env no seu arquivo de composição com a sintaxe bash usual (ou seja, ${SECRET_KEY}para inserir a SECRET_KEYdo .envarquivo).
Observe que o arquivo COMPOSE_CONFIGé definido no meu .envarquivo e usado no meu script bash, mas você pode facilmente substituí {$COMPOSE_CONFIG}-lo pelo my-compose-file.ymlscript bash.
Observe também que eu rotulei essa implantação nomeando todos os meus contêineres com o prefixo "myproject". Você pode usar qualquer nome que desejar, mas ajuda a identificar seus contêineres, para que você possa referenciá-los facilmente mais tarde. Supondo que seus contêineres sejam sem estado, como deveriam ser, esse script removerá e reimplementará rapidamente seus contêineres de acordo com os parâmetros de arquivo .env e seu arquivo YAML de composição.
Atualização
Como essa resposta parece bastante popular, escrevi uma postagem no blog que descreve meu fluxo de trabalho de implantação do Docker com mais profundidade: http://lukeswart.net/2016/03/lets-deploy-part-1/ Isso pode ser útil quando você adiciona mais complexidade em uma configuração de implantação, como configurações nginx, certificados LetsEncrypt e contêineres vinculados.