Rozwiązanie DOCKER:
Wygląda na to, że docker-compose 1.5+ ma włączone podstawianie zmiennych: https://github.com/docker/compose/releases
Najnowsza wersja Docker Compose umożliwia dostęp do zmiennych środowiskowych z pliku tworzenia. Możesz więc zdobyć swoje zmienne środowiskowe, a następnie uruchomić Compose w następujący sposób:
set -a
source .my-env
docker-compose up -d
Następnie możesz odwoływać się do zmiennych w docker-compose.yml za pomocą $ {VARIABLE}, w następujący sposób:
db:
image: "postgres:${POSTGRES_VERSION}"
A oto więcej informacji z dokumentów, pobranych tutaj: https://docs.docker.com/compose/compose-file/#variable-substitution
Po uruchomieniu docker-compose w tej konfiguracji Compose szuka w powłoce zmiennej środowiskowej POSTGRES_VERSION i zastępuje jej wartość. W tym przykładzie Compose przekształca obraz w postgres: 9.3 przed uruchomieniem konfiguracji.
Jeśli zmienna środowiskowa nie jest ustawiona, Utwórz zastępuje pustym ciągiem. W powyższym przykładzie, jeśli nie ustawiono POSTGRES_VERSION, wartością opcji obrazu jest postgres :.
Obsługiwana jest składnia $ VARIABLE i $ {VARIABLE}. Rozszerzone funkcje w stylu powłoki, takie jak $ {VARIABLE-default} i $ {VARIABLE / foo / bar}, nie są obsługiwane.
Jeśli chcesz wstawić dosłowny znak dolara w wartości konfiguracji, użyj podwójnego znaku dolara ($$).
I uważam, że ta funkcja została dodana w tym żądaniu ściągnięcia: https://github.com/docker/compose/pull/1765
Rozwiązanie BASH:
Zauważyłem, że ludzie mają problemy z obsługą zmiennych środowiskowych Dockera. Zamiast zajmować się zmiennymi środowiskowymi w Dockerze, wróćmy do podstaw, takich jak bash! Oto bardziej elastyczna metoda wykorzystująca skrypt bash i .envplik.
Przykładowy plik .env:
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
następnie uruchom ten skrypt bash w tym samym katalogu, który powinien wszystko poprawnie wdrożyć:
#!/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
Po prostu odwołaj się do zmiennych env w pliku tworzenia ze zwykłą składnią bash (tj. ${SECRET_KEY}Aby wstawić plik SECRET_KEYz .envpliku).
Zauważ, że COMPOSE_CONFIGjest zdefiniowany w moim .envpliku i używany w moim skrypcie bash, ale możesz łatwo zastąpić {$COMPOSE_CONFIG}go my-compose-file.ymlw skrypcie bash.
Zauważ też, że opisałem to wdrożenie, nazywając wszystkie moje kontenery przedrostkiem „myproject”. Możesz użyć dowolnej nazwy, ale pomaga to zidentyfikować pojemniki, dzięki czemu możesz łatwo do nich później sięgnąć. Zakładając, że twoje kontenery są bezstanowe, tak jak powinny, ten skrypt szybko usunie i ponownie wdroży twoje kontenery zgodnie z parametrami pliku .env i twoim plikiem YAML.
Aktualizacja
Ponieważ ta odpowiedź wydaje się dość popularna, napisałem post na blogu, który bardziej szczegółowo opisuje mój przepływ pracy wdrażania Dockera: http://lukeswart.net/2016/03/lets-deploy-part-1/ Może to być pomocne, gdy dodasz bardziej złożona konfiguracja wdrożenia, taka jak konfiguracje nginx, certyfikaty LetsEncrypt i połączone kontenery.