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.