2016-03-29 11 views
10

Czy to możliwe, aby ponownie użyć zmiennych środowiskowych, które są dzielone pomiędzy wielu pojemników, aby uniknąć powielania, jak pokazano w poniższym przykładzie:Ponowne wykorzystanie zmiennych środowiskowych w doker-redagowania yml

version: '2' 

services: 

    db: 
    image: example/db 
    ports: 
     - "8443:8443" 
    container_name: db 
    hostname: db 
    environment: 
     - USER_NAME = admin 
     - USER_PASSWORD = admin 

svc: 
    image: example/svc 
    depends_on: 
    - db 
    ports: 
    - "9443:9443" 
    container_name: svc 
    hostname: svc 
    environment: 
    - DB_URL = https://db:8443 
    - DB_USER_NAME = admin 
    - DB_USER_PASSWORD = admin 
+0

Oto obecne rozwiązanie w lokalu: https://github.com/axibase/axibase-collector/blob/ master/docker-bundle.md –

Odpowiedz

20

Można użyć dyrektywy extends, aby wiele kontenerów dziedziczyło konfigurację environment z opisu usługi podstawowej. Na przykład, umieścić następujące informacje w pliku o nazwie base.yml:

version: '2' 

services: 
    base: 
    environment: 
     DB_URL: https://db:8443 
     DB_USER_NAME: admin 
     DB_USER_PASSWORD: admin 

Następnie w docker-compose.yml:

version: '2' 

services: 
    container1: 
    image: alpine 
    command: sh -c "env; sleep 900" 
    extends: 
     file: base.yml 
     service: base 

    container2: 
    image: alpine 
    command: sh -c "env; sleep 900" 
    extends: 
     file: base.yml 
     service: base 
    environment: 
     ANOTHERVAR: this is a test 

Następnie wewnątrz container1, widać:

DB_URL=https://db:8443 
DB_USER_NAME=admin 
DB_USER_PASSWORD=admin 

i wewnątrz container2 zobaczysz:

DB_URL=https://db:8443 
DB_USER_NAME=admin 
DB_USER_PASSWORD=admin 
ANOTHERVAR=this is a test 

Oczywiście można używać extends do celów innych niż dyrektywa environment; to świetny sposób na uniknięcie duplikacji podczas korzystania z funkcji dokowania.

+0

'extends' działa dobrze w moim przypadku użycia. Jest to lepsze niż zmienne lokalne, ponieważ usuwa zależność od konkretnego użytkownika. Inną rzeczą, którą mogę zrobić z 'extends' jest określenie wspólnych etykiet kontenerów. –

+0

oh naprawdę, 'extends', jak mógłbym tęsknić, dzięki człowieku :) –

+0

czy mogę" wydłużyć "więcej niż jedną usługę? lub z więcej niż jednego pliku na usługę? – pkyeck

1

Można odwołać lokalnego środowiska zmienne z pliku do tworzenia dokowanego. Zakładając, co pan chce zrobić to USER_NAME taka sama jak DB_USER_NAME:

Döcker-compose.yml

version: '2' 

services: 
    db: 
    image: example/db 
    ports: 
     - "8443:8443" 
    container_name: db 
    hostname: db 
    environment: 
     - USER_NAME = ${USERNAME} 
     - USER_PASSWORD = ${PASSWORD} 

svc: 
    image: example/svc 
    depends_on: 
    - db 
    ports: 
    - "9443:9443" 
    container_name: svc 
    hostname: svc 
    environment: 
    - DB_URL = https://db:8443 
    - DB_USER_NAME = ${USERNAME} 
    - DB_USER_PASSWORD = ${PASSWORD} 

Następnie uruchom Döcker-komponować jak:

$ USERNAME="admin" PASSWORD="admin" docker-compose up 

przemian , w przypadku czegoś bardziej stałego i łatwiejszego do wpisania cyklicznie:

$ printf '%s\n%s\n' 'export USERNAME="admin"' 'export PASSWORD="admin"' >> ~/.bash_profile 
$ source ~/.bash_profile 
$ docker-compose up 
2

Opcja extends może być przyjemna, ale zawiera not supported w pliku 3.x. Innym sposobem postępowania jest dyrektywa env_file.

doker-compose.yml:

version: '3.2' 
services: 
    some_service: 
    image: someimage 
    env_file: 
     - 'variables.env' 

variables.env:

VARIABLE=some_value 
ANOTHER_VARIABLE=another_value 
Powiązane problemy