Elo,
no więc mamy kilkadziesiąt różnych kontenerów z różnymi usługami, oddzielonymi i oddzielnie zarządzanymi -- a życie jest dobre.
Na dole drzewka mieszkają sobie jakieś kontenery z mysql czy innym neo4j, nad nimi php-fpmy i django, wyżej jakiś nginx, a nad nginxem kontener co to musi mieć dostęp po www do jakiejś usługi na przykład. To wszystko rzecz jasna połączone, i zarządzane przez docker-compose.
Zrestartowanie kontenera z mysql gdzieś na dole oznacza zerwanie linków i koniecznośc restartowania wszystkich kontenerów linkujących do niego, oraz linkujących do tychże kontnerów, i tak dalej -- czyli w najgorszym wypadku ~50 kontenerów na trzech poziomach:
mysql -> php-fpm/django -> nginx -> nad nginxem
To zajmuje czas i oznacza downtime, le fu-.
Oczywiście mogę sobie ręcznie przepiąć iptablesy i inne /etc/hostsy, ale to też le fu-.
Więc pytanie do wymiataczy dockerowych, których mam nadzieję mamy na tej liście: jak żyć, panie premierze? W sensie, what is the best practice jeśli idzie o restartowanie linked containers? Bo na pewno się jakoś da. Tylko jak?
On 2015-08-19 15:48, rysiek wrote:
Elo,
no więc mamy kilkadziesiąt różnych kontenerów z różnymi usługami, oddzielonymi i oddzielnie zarządzanymi -- a życie jest dobre.
Na dole drzewka mieszkają sobie jakieś kontenery z mysql czy innym neo4j, nad nimi php-fpmy i django, wyżej jakiś nginx, a nad nginxem kontener co to musi mieć dostęp po www do jakiejś usługi na przykład. To wszystko rzecz jasna połączone, i zarządzane przez docker-compose.
Zrestartowanie kontenera z mysql gdzieś na dole oznacza zerwanie linków i koniecznośc restartowania wszystkich kontenerów linkujących do niego, oraz linkujących do tychże kontnerów, i tak dalej -- czyli w najgorszym wypadku ~50 kontenerów na trzech poziomach:
mysql -> php-fpm/django -> nginx -> nad nginxem
To zajmuje czas i oznacza downtime, le fu-.
Oczywiście mogę sobie ręcznie przepiąć iptablesy i inne /etc/hostsy, ale to też le fu-.
Więc pytanie do wymiataczy dockerowych, których mam nadzieję mamy na tej liście: jak żyć, panie premierze? W sensie, what is the best practice jeśli idzie o restartowanie linked containers? Bo na pewno się jakoś da. Tylko jak?
Z serii nie wiem to się wypowiem, ale czy nie byłoby najlepiej zachować kontener istniejący, przelinkować wyższe gałęzie drzewa na nowy, zklonowany, a potem zrobić merge baz jeśli jest taka potrzeba?
Wtedy unikasz downtime, i jesteś pewien że wszystkie dane zostają zachowane, jeśli mysql w kontenerze jest update'owany przez procesy wyżej w drzewie.
Also, your docker, you have to show me it.
On Thu, Aug 20, 2015 at 7:39 PM spin@hackerspace.pl wrote:
On 2015-08-19 15:48, rysiek wrote:
Elo,
no więc mamy kilkadziesiąt różnych kontenerów z różnymi usługami, oddzielonymi i oddzielnie zarządzanymi -- a życie jest dobre.
Na dole drzewka mieszkają sobie jakieś kontenery z mysql czy innym neo4j, nad nimi php-fpmy i django, wyżej jakiś nginx, a nad nginxem kontener co to musi mieć dostęp po www do jakiejś usługi na przykład. To wszystko rzecz jasna połączone, i zarządzane przez docker-compose.
Zrestartowanie kontenera z mysql gdzieś na dole oznacza zerwanie linków i koniecznośc restartowania wszystkich kontenerów linkujących do niego, oraz linkujących do tychże kontnerów, i tak dalej -- czyli w najgorszym wypadku ~50 kontenerów na trzech poziomach:
mysql -> php-fpm/django -> nginx -> nad nginxem
To zajmuje czas i oznacza downtime, le fu-.
Oczywiście mogę sobie ręcznie przepiąć iptablesy i inne /etc/hostsy, ale to też le fu-.
Więc pytanie do wymiataczy dockerowych, których mam nadzieję mamy na tej liście: jak żyć, panie premierze? W sensie, what is the best practice jeśli idzie o restartowanie linked containers? Bo na pewno się jakoś da. Tylko jak?
Czekaj, ale jaki jest problem? Że nie masz śledzenia zależności między kontenerami, czy że nie masz redundantnej / umiejącej retry infrastruktury? W sensie, czemu niby php-fpm ma się restartować jeśli restartujesz nginx? Przekręcisz nginx, socket padnie, otworzy się nowy, done. Przekręcisz mysql, socket padnie, otworzy się nowy, done. Pewnie chcesz gdzieś frontend przekierować podczas takich operacji i poblokować nowe połączenia, ale nie czuję czemu tutaj są jakieś zależności wymagające restartów.
Dnia czwartek, 20 sierpnia 2015 20:38:43 spin@hackerspace.pl pisze:
Z serii nie wiem to się wypowiem, ale czy nie byłoby najlepiej zachować kontener istniejący, przelinkować wyższe gałęzie drzewa na nowy, zklonowany, a potem zrobić merge baz jeśli jest taka potrzeba?
Spin, serio, nie mam pojęcia, o czym tu do mnie mówisz. Jakiego drzewa, jakie klonowanie?
Dnia czwartek, 20 sierpnia 2015 22:51:56 Tomasz Dubrownik pisze:
Czekaj, ale jaki jest problem? Że nie masz śledzenia zależności między kontenerami, czy że nie masz redundantnej / umiejącej retry infrastruktury? W sensie, czemu niby php-fpm ma się restartować jeśli restartujesz nginx?
Nie. Że jak przekręcę php-fpm, to muszę przekręcić nginxa, inaczej nginx robi wycieczkę do Bad Gateway Internet Resort.
Przekręcisz nginx, socket padnie, otworzy się nowy, done. Przekręcisz mysql, socket padnie, otworzy się nowy, done. Pewnie chcesz gdzieś frontend przekierować podczas takich operacji i poblokować nowe połączenia, ale nie czuję czemu tutaj są jakieś zależności wymagające restartów.
Nie chodzi o zależności php-fpma, chodzi o to, że php-fpm jest zależnością nginxa; po restarcie (znaczy, po wywaleniu i stworzeniu od zera, a to jest niestety AFAIK konieczne jeśli chcemy przebudować kontener) php-fpm, nginx "gubi" linkę do swojej zależności (bo zmienia się IP tejże, na przykład), i robi wielkie oczy jak przychodzi żądanie kierowane na ten php-fpm.
Let me demonstrate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ curl -kI https://owncloud.example.com/ HTTP/1.1 200 OK (...)
// restartujemy (znaczy, zatrzymujemy, wyprtalamy, odpalamy od zera), bo np. // przebudowaliśmy kontener
# docker-compose stop owncloud Stopping serverconfig_owncloud_1...
# docker-compose rm owncloud Going to remove serverconfig_owncloud_1 Are you sure? [yN] y Removing serverconfig_owncloud_1...
# docker-compose up -d --no-recreate owncloud Creating serverconfig_owncloud_1...
// chodzą? // chodzą.
# docker-compose ps | egrep '(nginx|owncloud)' serverconfig_nginx_1 /run.sh Up serverconfig_owncloud_1 /bin/bash /var/lib/php5/start Up
// widzą się? // nopenopenope
$ curl -kI https://owncloud.occrp.org/ HTTP/1.1 502 Bad Gateway
// przekręcamy nginxa
# docker-compose stop nginx Stopping serverconfig_nginx_1...
# docker-compose rm nginx Going to remove serverconfig_nginx_1 Are you sure? [yN] y Removing serverconfig_nginx_1...
# docker-compose up -d --no-recreate nginx Creating serverconfig_nginx_1...
// działa? // działa.
$ curl -kI https://owncloud.occrp.org/ HTTP/1.1 200 OK
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fun fact: podczas przekręcania ownclouda zmienia się jego adres IP. Jeśli ręcznie (czy jakimś sedem) uaktualnię adres IP ownclouda w /etc/hosts w kontenerze nginxa, wsio hula -- ale tylko jeśli *nie* używam dockera z `--icc=false`.
Rzecz jasna, chcę używać dockera z --icc=false.
Generalnie chodzi o to, bym nie musiał przekręcać nginxa po przekręceniu php-fpm. Chwilowy downtime jednego z kilkudziesięciu (don't get me started) kontenerów php-fpm to *nie* jest problem, ale chwilowy downtime nginxa (przez którego wszystkie zapytania do wszystkich kontenerów idą) -- to już jest le fu-.
Miałem ten sam problem jakiś czasu temu. Może już to jakoś poprawili, ale wtedy uznałem że linki są niedopracowane (tak jak większość dockera...), i zrobiłem wszystko wystawiając usługi na adresie IP hosta w bridgu dockerowym.
Każda usługa ma swój stały port na bridgu, każdy konsument ma ten adres IP i port whardkowoane/przekazane przez env var/przekazane przez configmount. Jak usługa padnie a konsument próbuje się do niej dobić, to tak samo będzie refused jak w przypadku linków. Jednak, jak usługa wstanie znowu, to wstanie na tym samym porcie i wszystko będzie cacy.
Brzydkie, ale co zrobicz.
Yo,
Dnia piątek, 21 sierpnia 2015 11:57:34 Sergiusz Bazański pisze:
Miałem ten sam problem jakiś czasu temu. Może już to jakoś poprawili, ale wtedy uznałem że linki są niedopracowane (tak jak większość dockera...), i zrobiłem wszystko wystawiając usługi na adresie IP hosta w bridgu dockerowym.
Rozwiązanie A -- na to nie wpadłem.
Dnia piątek, 21 sierpnia 2015 10:00:41 Tomasz Dubrownik pisze:
Christ almighty why.
Bikoz docker. A ja nie wziąłem się za statyczne adresy IP w dockerze (jeszcze).
Rozwiązanie B -- statyczne IP. ACK. To nawet może zadziałać.
Jeślibyś tak totalnie okrutnie chciał mieć dynamiczny magiczny konfig nginxa (really? why.), to binduj go po IP i regeneruj i reloaduj mu konfigi z zewnątrz kiedy kręcisz php-fpm.
Wiesz, nginx -s reload jest fajne and all, ale to nie chodzi o ograniczenia *nginxa*, a o ograniczenia *dockera*. Jak zmieni się IP, link jest stale i choćbyś nie wiem ile kręcił nginxem, lolnope.
Ale totalnie nie miałbyś tego problemu, gdyby kontenery miały well defined contact points, na przykład statyczne IP albo hostname + DNS.
Trudat.
(teraz czcza spekulacja) a nie da się jednego file socketa wyeksportować do kilku kontenerów? Na fBSD z jailami się da i to całkiem w porządku rozwiązanie tego problemu - bindujesz po file socketach i w ogóle nie masz problemów z myśleniem o sieci. Rzecz jasna useless jeśli to jest >1 maszyna.
Da się, i to jest...
Rozwiązanie C -- o którym myślę, ale które wymagać będzie sporo roboty.
To nie kręć kontenera, tylko reloaduj nginx.
Again, problemem nie jest nginx, a docker, który nie umie w ponowne podłączenie zlinkowanych kontenerów, gdy zostają kopnięte.
No nic, tego się generalnie obawiałem -- linki nie są w dockerze dopracowane, trzeba albo zrobić zewnętrzny discovery, albo zrobić wszystko na unix socketach, albo static IP FTW.
Dziękba.
On 21 August 2015 12:15:48 CEST, rysiek rysiek@hackerspace.pl wrote:
Yo,
Dnia piątek, 21 sierpnia 2015 11:57:34 Sergiusz Bazański pisze:
Miałem ten sam problem jakiś czasu temu. Może już to jakoś poprawili, ale wtedy uznałem że linki są niedopracowane (tak jak większość dockera...), i zrobiłem wszystko wystawiając usługi na adresie IP
hosta
w bridgu dockerowym.
Rozwiązanie A -- na to nie wpadłem.
Dnia piątek, 21 sierpnia 2015 10:00:41 Tomasz Dubrownik pisze:
Christ almighty why.
Bikoz docker. A ja nie wziąłem się za statyczne adresy IP w dockerze (jeszcze).
Rozwiązanie B -- statyczne IP. ACK. To nawet może zadziałać.
Jeślibyś tak totalnie okrutnie chciał mieć dynamiczny magiczny konfig
nginxa
(really? why.), to binduj go po IP i regeneruj i reloaduj mu konfigi
z
zewnątrz kiedy kręcisz php-fpm.
Wiesz, nginx -s reload jest fajne and all, ale to nie chodzi o ograniczenia *nginxa*, a o ograniczenia *dockera*. Jak zmieni się IP, link jest stale i choćbyś nie wiem ile kręcił nginxem, lolnope.
Ale totalnie nie miałbyś tego problemu, gdyby kontenery miały well
defined
contact points, na przykład statyczne IP albo hostname + DNS.
Trudat.
(teraz czcza spekulacja) a nie da się jednego file socketa
wyeksportować do
kilku kontenerów? Na fBSD z jailami się da i to całkiem w porządku rozwiązanie tego problemu - bindujesz po file socketach i w ogóle nie
masz
problemów z myśleniem o sieci. Rzecz jasna useless jeśli to jest >1
maszyna.
Da się, i to jest...
Rozwiązanie C -- o którym myślę, ale które wymagać będzie sporo roboty.
To nie kręć kontenera, tylko reloaduj nginx.
Again, problemem nie jest nginx, a docker, który nie umie w ponowne podłączenie zlinkowanych kontenerów, gdy zostają kopnięte.
No nic, tego się generalnie obawiałem -- linki nie są w dockerze dopracowane, trzeba albo zrobić zewnętrzny discovery, albo zrobić wszystko na unix socketach, albo static IP FTW.
Dziękba.
Co do discovery to obejrzyj sobie https://consul.io/
Co do discovery to obejrzyj sobie https://consul.io/
web-frontend.service.consul. 0 IN A 10.0.3.83 …0…
wait what
https://github.com/hashicorp/consul/blob/9bbe09fb43c33a79f93d76bee54992ea3d5...
"By default, this is "0s", so all node lookups are served with a 0 TTL value."
sure, what can go wrong, that sounds like a sensible default :)
On Fri, Aug 21, 2015 at 10:45 AM rysiek rysiek@hackerspace.pl wrote:
Dnia czwartek, 20 sierpnia 2015 20:38:43 spin@hackerspace.pl pisze:
Z serii nie wiem to się wypowiem, ale czy nie byłoby najlepiej zachować kontener istniejący, przelinkować wyższe gałęzie drzewa na nowy, zklonowany, a potem zrobić merge baz jeśli jest taka potrzeba?
Spin, serio, nie mam pojęcia, o czym tu do mnie mówisz. Jakiego drzewa, jakie klonowanie?
Dnia czwartek, 20 sierpnia 2015 22:51:56 Tomasz Dubrownik pisze:
Czekaj, ale jaki jest problem? Że nie masz śledzenia zależności między kontenerami, czy że nie masz redundantnej / umiejącej retry
infrastruktury?
W sensie, czemu niby php-fpm ma się restartować jeśli restartujesz nginx?
Nie. Że jak przekręcę php-fpm, to muszę przekręcić nginxa, inaczej nginx robi wycieczkę do Bad Gateway Internet Resort.
Przekręcisz nginx, socket padnie, otworzy się nowy, done. Przekręcisz mysql, socket padnie, otworzy się nowy, done. Pewnie chcesz gdzieś
frontend
przekierować podczas takich operacji i poblokować nowe połączenia, ale
nie
czuję czemu tutaj są jakieś zależności wymagające restartów.
Nie chodzi o zależności php-fpma, chodzi o to, że php-fpm jest zależnością nginxa; po restarcie (znaczy, po wywaleniu i stworzeniu od zera, a to jest niestety AFAIK konieczne jeśli chcemy przebudować kontener) php-fpm, nginx "gubi" linkę do swojej zależności (bo zmienia się IP tejże, na przykład), i robi wielkie oczy jak przychodzi żądanie kierowane na ten php-fpm.
Let me demonstrate.
$ curl -kI https://owncloud.example.com/ HTTP/1.1 200 OK (...)
// restartujemy (znaczy, zatrzymujemy, wyprtalamy, odpalamy od zera), bo np. // przebudowaliśmy kontener
# docker-compose stop owncloud Stopping serverconfig_owncloud_1...
# docker-compose rm owncloud Going to remove serverconfig_owncloud_1 Are you sure? [yN] y Removing serverconfig_owncloud_1...
# docker-compose up -d --no-recreate owncloud Creating serverconfig_owncloud_1...
// chodzą? // chodzą.
# docker-compose ps | egrep '(nginx|owncloud)' serverconfig_nginx_1 /run.sh Up serverconfig_owncloud_1 /bin/bash /var/lib/php5/start Up
// widzą się? // nopenopenope
$ curl -kI https://owncloud.occrp.org/ HTTP/1.1 502 Bad Gateway
Where are the errologs, Lebowski?
Fun fact: podczas przekręcania ownclouda zmienia się jego adres IP.
Christ almighty why. Also wiązanie usług przez hostname z bindowaniem IP w */etc/hosts w kliencie* to hardkorowo zły pomysł. Jeśli nie możesz w statyczne IP (but why?), powinieneś mieć jakiś prawdziwy DNS, bo inaczej wpadasz właśnie w takie bagienko, jak to, że pomimo faktu, że nginx umie bez problemu poradzić sobie z kopniętym backendem, to nagle ma implicit zależność na jego runtime state, do którego nie ma mieć dostępu by design - bo w tej wersji adres socketa to jest runtime state, a nie statyczna konfiguracja. Jeślibyś tak totalnie okrutnie chciał mieć dynamiczny magiczny konfig nginxa (really? why.), to binduj go po IP i regeneruj i reloaduj mu konfigi z zewnątrz kiedy kręcisz php-fpm. Ale totalnie nie miałbyś tego problemu, gdyby kontenery miały well defined contact points, na przykład statyczne IP albo hostname + DNS.
(teraz czcza spekulacja) a nie da się jednego file socketa wyeksportować do kilku kontenerów? Na fBSD z jailami się da i to całkiem w porządku rozwiązanie tego problemu - bindujesz po file socketach i w ogóle nie masz problemów z myśleniem o sieci. Rzecz jasna useless jeśli to jest >1 maszyna.
Generalnie chodzi o to, bym nie musiał przekręcać nginxa po przekręceniu
php-fpm. Chwilowy downtime jednego z kilkudziesięciu (don't get me started) kontenerów php-fpm to *nie* jest problem, ale chwilowy downtime nginxa (przez którego wszystkie zapytania do wszystkich kontenerów idą) -- to już jest le fu-.
To nie kręć kontenera, tylko reloaduj nginx. Ale j/w, lepiej po prostu nie mieć tego problemu albo ustalając once and for all gdzie stoi dana usługa na sztywno, albo (jeśli bardzo bardzo bardzo musisz, ale prawie na pewno nie musisz, bo kilkadziesiąt usług to nie jest dużo) wyrzucając discovery do osobnego, niezależnego kontenera, w którym postawisz sobie jakiś malutki DNS. Wtedy kręcenie fpm wymusi kręcenie/reload DNS, ale nginx po prostu odkryje nowy adres be konieczności explicit reloadu. Still, mocno sugerowałbym nie babranie się w to, skoro i tak musisz konfigurować każdy vhost z osobna na nginx, to konfigurowanie go na statyczne adresy nie powinno być dużo boleśniejsze.
-
rysiek -
Sergiusz Bazański -
spin＠hackerspace.pl -
Tomasz Dubrownik -
viq