[docker] zmienna srodowiskowa przekazana do .yml Opcje

[nospor]

Hej,
idzie w komendzie
docker-compose up -d
dodac jeszcze zmienna, ktora zostanie przekazana do budowanego pliku docker-compose.yml ?
Przyklad o co mi chodzi:
docker-compose up -d --env:usr=dev

a w pliku docker-compose.yml mam bede mial np. taki kod
extra_hosts:
- "$usr.jakasstrona.pl:162.242.195.82"

W wyniku czego /etc/hosts kontenera pojawi mi sie wpis
162.242.195.82 dev.jakasstrona.pl

edit: zmierzam do tego, ze chce przygotowac uniwersalne srodowisko dla naszego zepolu. Niestety kazdy z nas odpala jedna aplikacje pod wlasnymi adresami.
Ja pod:
nospor.blabla.pl
Kumpel pod:
nickkumpla.blabla.pl
itd

Chodzi o to, by tylko w komendzie docker-compose up -d podac jeszcze nasza nazwe i powstanie odpowiedni wpis w kontenerze.

[by_ikar]

Można w docker-compose.yml wykorzystać zmienne zapisane w sesji lub zapisane w .bashrc. Od wersji 1.5 w compose można wykorzystać zmienne bashowe: https://github.com/docker/compose/blob/1290...le-substitution

Jeżeli już tą zmienną usr masz zapisaną, to wystarczy że dodasz do swojej konfiguracji:

Kod

extra_hosts:
  - "$DOMAIN_USR.jakasstrona.pl:162.242.195.82"

Jeżeli nie, to musisz zrobić zarówno export (żeby wykorzystać w tej samej sesji terminala) jak i dorzucić do .bashrc tą zmienną, co by pomiędzy restartami maszyny mieć zapisane te dane. U mnie w firmie każde repo ma też install.sh w którym sobie wrzucamy takie rzeczy przy pierwszym odpaleniu kontenera. Możesz takie rzeczy wrzucić sobie w taki sposób:

Kod

usr="nospor"
sed -i '/DOMAIN_USR/d' ~/.bashrc
( echo "export DOMAIN_USR=\"$usr\""; echo ) >> ~/.bashrc
export DOMAIN_USR="$usr"

sed służy tutaj za wykasowanie tej linijki z bashrc jeżeli taka już istnieje, co by nie dorzucać ciągle tego samego przez pomyłkę. Ewentualnie jak nie chcecie sobie takich rzeczy eksportować możecie zrobić to tak:

Kod

DOMAIN_USR=nospor docker-compose up -d

Wtedy po prostu będziesz miał odczytaną tą zmienną jednorazowo, ale każdy restart będzie wiązać się z właśnie użyciem tej zmiennej przed samą komendą. No ale masz kilka wariantów

Ten post edytował by_ikar 7.02.2016, 12:18:59

[nospor]

Normalnie bajera
O to chodziło

To skoro juz tak dobrze idzie to jeszcze jednow temacie powiedzmy własnych konfigow:
Jak juz wiesz, stronki odpalane sa przez nospor.jakasstrona.pl i kazdy developer ma swoja stronke. W tym celu, do kontenera podmontowuje plik z konfiguracja hosta, ktory wyglada mniej wiecej tak:

Kod

server {
    listen 80;
    listen [::]:80;
    server_name nospor.jakasstrona.pl;
.....

Tez chcialbym aby ten konfig byl w GIT aby nikt sie nie zastanawial jak ma wygladac. No ale kazdy z developerow bedzie mial wlasny usr.jakasstrona.pl. I co z tym zrobic? Czy stworzyc N configow dla kazdego z devow (no ale przy jakiejkolwiek zmianie bede musial zmieniac w N plikach) czy moze inaczej? Idzie to tez jakos rozwiazac przez zmienne srodowiskowe?

[by_ikar]

Jeżeli chodzi o nginxa on niestety nie odczytuje zmiennych środowiskowych, więc są w sumie dwa wyjścia, dać wildcarda:

Kod

server_name *.jakasstrona.pl;

Dać wszystkie możliwe hosty:

Kod

server_name nospor.jakasstrona.pl blabla.jakasstrona.pl bleble.jakasstrona.pl;

Albo ujednolicić swoje hosty, tak żeby wszyscy mieli jednakowe. Co niestety wiąże się z przerobieniem konfiguracji na wszystkich stanowiskach, ale moim zdaniem jest to najbardziej sensowna opcja.

Swoją drogą widzę że wdrążyłeś dockera u siebie w firmie, jakie są twoje odczucia po tak krótkim czasie pracy na dockerze ?

[nospor]

wildcard - w pierwszej chwili - ok, tak, to moze zadzialac... ale jednak nie, sprawa bardziej skomplikowana.
ujednolicic - nie bardzo. W sumie mi to by i nawet pasowalo, ale oni tu taj pracuja od lat i w to akurat nie chce im sie wchrzaniac jako nowa osoba. I tak juz zadyme zrobilem z GITem
dac wszystkie mozliwe hosty - kurde, no jasne. Zamiast walic x plikow z tym samym, dac porostu wszystko w hostach w jednym konfigu. Normalnie albo jestes genialny albo ja niesamowicie zacmiony ostatnio

Swoją drogą widzę że wdrążyłeś dockera u siebie w firmie, jakie są twoje odczucia po tak krótkim czasie pracy na dockerze ?

Jeszcze nie wdrozylem. Narazie pracuje tylko ja i co chwile cos ulepszam w plikach konfiguracyjnych. Zanim cos wypuszcze wszystkim w devom w firmie, chce to wpierw dopiescic. Mamy tu takiego seniora co sie lubi do wszystkiego czepiac wiec chce mu dac jak najmniej powodow
Ale tak, osobiscie jestem zachwycony nowymi mozliwosciami. No i w porownaniu do vagrant dziala zauwazalnie szybciej - sam start jak i potem dzialanie juz samej aplikacji.

[by_ikar]

Genialny to może nie, bardziej doświadczony, dlatego że: na nginx (niemal wyłącznie) pracuje już od ~2 lat; podobny problem mieliśmy u siebie, dlatego że każde środowisko ma swoją domenę: domena.local (development); domena.dev (staging); domena.com (master); więc o ile są to tylko 3 hosty, to można wpisać je bezpośrednio właśnie jeden po drugim. Jeżeli będziesz miał tych hostów więcej, tzn subdomen, to albo wildcard, albo wyrażenie regularne (w tej sekcji też można go użyć). Z kolei zmienne wykorzystujemy do wczytywania certyfikatów ssl, bo kontener (tutum/haproxy) z którego korzystamy póki co nie ma możliwości dodania certyfikatu jako plik, jedynie jako string, więc na szybkiego przyszło mi do głowy ostatnie zmiany z docker-compose które ci zlinkowałem. Generalnie polecam raz w miesiącu przejrzeć każdego liba czy narzędzie z którego korzystamy, w calu zapoznania się z nowościami. Docker rozwija się w kosmicznym tempie, bo wielkie korporacje pompują w niego gigantyczne pieniądze, i się nie dziwię, bo narzędzie jest po prostu rewolucją.

Na prawdę polecam dodanie pliku sh który będzie zawiera wszystko potrzebne: instalacje dockera, composa, gita, budowanie obrazu kontenera, wrzucanie wpisów do /etc/hosts, startowanie kontenera etc w ten sposób cała migracja będzie bezbolesna bo wystarczy odpalić plik sh i gotowe.

Ten post edytował by_ikar 8.02.2016, 08:25:05

[nospor]

Tak, plik .sh juz mam. Jednak po tym temacie odchudził sie niesamowicie