Docker - pytania uczącego się

Witajcie, od jakiegoś już czasu uczę się Dockera, Docker Swarma i trochę Kubernetesa. Nie mam dostępu ani doświadczenia z produkcyjnymi środowiskami więc ciężko mi sobie wyobrazić pewne sytuacje i architektury.

1. Docker Swarm jest rozwiązaniem skalowalnym i zapewniającym load balncing aplikacji. Meczy mnie jeden temat, otóż aplikację często generują dane. Jeśli nie są to dane użytkowników to są to będą to logi i inne. Dajmy na to, że mamy dwie repliki np nginx na dwóch różnych nodach gdzie logi są wrzucone na volumeny dockerowe. Jeden z nodów pada i jest nie dostępny, generuje się druga replika na działającym nodzie. Ale gdzie się podziały dane ?

2. Bazy dane często są skalowane bo potrzebują dużo zasobów i muszą być wolnodostępne i podobna kwestia do z danymi ? Każda replika mysql będzie miała dane składowane u siebie lokalnie na nodzie. Ale dane muszą być spójne i jednorodne? Workery muszą korzystać z jednego źródła danych.

Nie znam się to się wypowiem.

1. Volumeny do tego właśnie służą, żeby dane 'zostawały' pomimo zabicia kontenerów. Tzn. jeśli kontener padł, dane znajdują sie w volumie i tak. Jak wstanie, dalej bedzie mial te same dane (chyba, ze przy wstawaniu je usuwa czy cos, ale to juz inna sprawa).
2. W sumie to samo (jeśli dobrze rozumiem). Możesz więcej niż jednemu kontenerowi przypisac ten sam katalog jako volume. Czyli 2 bazy danych moga uzywac tych samych danych. Chociaz nie wiem na ile jest to bezpieczne, z bazami tak nie robilem akurat...

ad.1
Gdy ostatnio się orientowałem, nikt poważny nie przyznawał się do używania docker swarm. Nie ucz nie przydatnej technologii. Jedynym skalowalnym rozwiązaniem opartym o dockera (między innymi) jest AWS ECS. Tam logi ogarnia Ci jakiś kolejny, kompatybilny z ECS serwis, który serwuje Ci do nich dostęp np. przez ELKa/kibane, a z poziomu aplikacji wysyłasz jak na sysloga.

ad.2
Dane są trzymane na stałych serwerach/dyskach. Konteneryzujesz tylko samą aplikacje. Replikowanie danych na kolejne dyski w produkcyjnym klastrze z odpowiednią redundancją to proces nietrywialny i powolny, dlatego nie powinien odbywać się bez nadzoru.

Swarmów nie używałem akurat nawet. I nie rozumiem hejtu na dockera... Dla mnie jest przydatny, pomijajac nawet projekty, to kiedy potrzebujesz na szybko bazy danych, srodowiska, cokolwiek to masz. Wlasciwie akurat Kibane tez postawilem na dockerze, po prostu volume ma wspolny z logami innych kontenerow i tyle.

Bazy danych na dockerach w środowisku produkcyjnym to zły pomysł. Niestety jeśli chodzi o skalowanie baz danych to tutaj musisz wybrać pomiędzy spojnoscia a dostępnością danych. Tkzw. CAP Theorem https://en.m.wikipedia.org/wiki/CAP_theorem. Zależnie od wyboru system budujesz w opraciu o założenie ostatecznej spójności (eventual consistency) lub transakcyjnosci. W bardzo dużych systemach wybiera się to pierwsze ponieważ systemy transakcyjne sa zbyt wolne i nie przynoszą oczekiwanych korzyści. Dodam tylko ze moja wiedza jest czysto teoretyczna. Nie budowalem nigdy systemu opertego o eventual consistency i skalowalne bazy danych. Ogólnie temat jest szeroki i projektpwanie takich rozwiazan wymaga duzego doswiadczenia i rzeczywistej potrzeby. W dużej większości systemów nie jest to pptrzebne.

1. Nie używasz do tego voluminów ani Docker Swarma ani Kubernetsów. Robisz to używając zewnętrznego serwisu jak S3. A jeśli chcesz składować samemu to najlepiej jest zbudować sobie jakiś block storage i do niego podpiąć np. Minio lub użyć jakiegoś gotowego object storage. Co do logów to też nie składujesz ich lokalnie tylko masz jakiś scentralizowany skład logów jak Graylog2 czy ELK i tam wysyłasz wszystkie logi.
2. Bazy danych ZAWSZE (na produkcji) trzymasz na osobnych maszynach, które jedyne czym się zajmują się tylko i wyłącznie DB. Mogą sobie pożerać tam RAM do woli i nic nie będzie stało im na przeszkodzie.