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/