Jakie są powody, dla których Docker nie powinien być używany do baz danych?

Prowadzę dyskusję z przyjacielem na temat przypadków użycia Dockera . Jeden facet w zespole chce używać Dockera do wszystkiego - jak rodzaj uniwersalnego opakowania procesu unixowego. Drugi uważa, że ​​Docker powinien być używany tylko do aplikacji bezstanowych , takich jak Microservices i aplikacje w stylu AWS Lambda .

Opracowaliśmy dowód koncepcji dla obu. W naszym klastrze dokerów mamy udostępniony dysk, który jest montowany po zamontowaniu hosta Docker, a jeśli baza danych w kontenerze jest montowana, po prostu instaluje wolumin na dysku udostępnionym.

Mój przyjaciel nadal trzyma się swojej pozycji, mimo że pokazano mu przeciwne dowody. (Twierdzi również, że Docker zwiększa niepotrzebne ryzyko, zwiększając złożoność stosu.)

Staram się słuchać i rozumieć jego punkt widzenia, zarówno w akcie empatii, jak i lepszego rozumowania z nim. (Wszyscy dobrze sobie radzimy - więc jest to mieszanka dowcipu i poważnej dyskusji).

Pytanie, które kryje się za pytaniem, brzmi: czy bazy danych są bydłem ? Ten komentarz sugeruje, że dobra strategia automatycznego tworzenia kopii zapasowych i pobierania bazy danych jest nie do odróżnienia od serwera bydła.

Moje pytanie brzmi: z jakich powodów Docker nie powinien być używany do baz danych?

EDYCJA: Ludzie poprosili mnie o wyjaśnienie mojej terminologii. Zakładałem, że aplikacja bazy danych znajduje się w kontenerze, a pamięć jest w woluminie. Miałem na myśli to, że RDBMS znajduje się w kontenerze, a pamięć bazy danych znajduje się w woluminie.

Niektórzy komentatorzy sugerują, że sterowniki woluminu dokującego nie będą działać z danymi zapisanymi w bazie danych. (Lub coś w tym celu). Czy możesz to rozwinąć?

Kiedy ludzie mówią o prowadzeniu bazy danych w Dockerze, nie mają na myśli przechowywania danych w kontenerze; mówią o posiadaniu obrazu dokera z oprogramowaniem DB i montowaniu danych jako woluminu (wolumin powiązania, a nie wolumin kontenera).

Woluminy są istotną częścią Dockera i nie są czymś płatkowym lub po prostu dołączonym. Docker jest przeznaczony nie tylko dla bezpaństwowych (mikro) usług.

Żałuję, że nie mogę znaleźć technicznego powodu, aby nie uruchamiać bazy danych w Dockerze, więc niestety wybiorę drugą stronę argumentu i dlatego może nie dać ci odpowiedzi, której szukasz.

(Używam Oracle jako przykładu, ponieważ znam go, zarówno goły metal, jak i dokowany, oraz ponieważ jest to dość notoryczna bestia, ponieważ jest trochę trywialna w obsłudze, jeśli przejdziesz przez ustawienia domyślne.)

• Pakowanie samego oprogramowania DB w kontenerze daje zwykłe korzyści - posiadanie wszędzie tej samej wersji, unikanie problemów związanych z zależnością / biblioteką współdzieloną, możliwość rozkręcania dokładnie tej samej DB na laptopach programistów lub gdziekolwiek jest to potrzebne.
• Jest to snap się go uruchomić w dowolnym miejscu; aktualizacja jest trywialna i tak dalej. Obowiązują wszystkie korzyści Dockera. Na Dockerhub znajduje się obraz Oracle, który pozwala rozkręcić działającą bazę danych w ciągu minuty lub trzech (i oczywiście także dla innych).
• Ludzie przeprowadzili testy wydajności i nie znaleźli różnic we / wy między woluminami a gołym metalem ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / question / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container ).
• Pod maską nie jest tak, że Docker w jakiś sposób przechwytuje wszystkie wejścia / wyjścia. Po prostu staje się kreatywny dzięki standardowym narzędziom dla Linuksa (w tym przypadku łączenie opraw, mangling wewnętrznych tabel jądra, które w ogóle umożliwiają Docker-fu).
• Oczywiście nie oznacza to, że możesz uruchomić dwie instancje bazy danych i po prostu sprawić, by działały na tych samych plikach, ale nikt tego nie sugeruje. Docker nie zapewnia automatycznego, równoczesnego i magicznie wolnego od wyścigów dostępu do tomów i nigdy nie udawał, że to robi. Pozostałe świadczenia nadal obowiązują. Jeśli sama baza danych nie wykrywa takich konfliktów, lepiej dostarczyć skrypt CMD do obrazu, który odmawia rozkręcania drugiego pojemnika, gdy wolumin jest już w użyciu.
• Musisz być nieco bardziej ostrożny przy włączaniu / wyłączaniu kontenera (tak jak nie wyłączałbyś tylko czystego serwera DB), ale powinno to być całkiem łatwe do zarządzania.

Teraz, w zależności od okoliczności, mogą istnieć miękkie powody, aby tego nie robić:

• Na przykład Oracle (firma) z pewnością nie będzie cię wspierać, jeśli uruchomisz ich RDBMS w kontenerze Docker. Ale być może używasz dokowanych obrazów Oracle RDBMS tylko dla programistów i środowiska testowego, w którym w żadnym wypadku nie potrzebujesz ich wsparcia, rezerwując je na serwer produkcyjny od zera. (Ale nie zapomnij zapłacić licencji ...).
• Jeśli operatorzy nie znają Dockera, może być nieco łatwiej przypadkowo zabić wszystko, zniszczyć pliki danych itp.
• Jeśli masz już duże dedykowane metalowe maszyny DB, z dużą ilością bardzo szybkiej dedykowanej pamięci SAN i działające tak czy inaczej, to po prostu nie ma sensu używać Dockera do konteneryzacji tych zasobów, ponieważ nigdy nie po prostu rozkręcisz innego serwera, gdy tam będzie to 100 GB, a nawet TB danych. W końcu do produkcji RDBMS, taki jak Oracle, jest bardzo, bardzo zaawansowany we wszystkich aspektach replikacji, integralności danych, przełączania awaryjnego bez przestojów itp. Zauważ, że ten argument mówi tylko: „nie musisz przeprowadzać kontenera RDBMS”. Nie mówi „nie powinieneś tego robić” - być może chcesz to zrobić, ponieważ chcesz wdrażać aktualizacje oprogramowania baz danych za pośrednictwem kontenerów lub z innego powodu, jaki możesz sobie wyobrazić.

Więc proszę bardzo. Z całą pewnością dokuj swoje DB, przynajmniej dla deweloperów (którzy będą wiecznie wdzięczni) i środowisk testowych. Jeśli chodzi o produkcję, sprowadzi się ona do gustu, a tam przynajmniej wolałbym rozwiązanie, które najlepiej pasuje do wyspecjalizowanych DBA / Ops - jeśli mają dziesięciolecia doświadczenia w pracy z serwerami DB bez systemu metalowego, to zdecydowanie im zaufaj aby kontynuować. Ale jeśli jesteś startupem, który i tak ma całą IT w chmurze, to pojemnik Docker byłby tylko kolejnym kawałkiem cebuli na całym obrazie.

I napisał o tym w głębi , ale tutaj jest podsumowanie:

• Zapobieganie podziałowi mózgu (wybranie więcej niż jednego węzła głównego) wymaga rozwiązania. Niezastosowanie się do tego może być katastrofalne

• Nie ma gotowych do produkcji rozwiązań współużytkowanego przechowywania, które umożliwiłyby zamknięcie baz danych w jednym wystąpieniu i wywołanie w innym bez utraty wszystkich danych.

Kiedy powiesz, że dane są zamontowane w kontenerze dokowanym, czy nie byłoby bardziej poprawne stwierdzenie, że „baza danych” jest zamontowana w kontenerze dokowanym? Jeśli utrwalasz swoje dane poza kontenerem, to robisz „właściwą” rzecz, nie umieszczając bazy danych w kontenerze.

Jasne, idź do miasta, wkładając DBMS do kontenera i pozwalając mu zarządzać danymi, które przechowujesz na zewnątrz, osobiście uważam, że to po prostu dobry projekt, ponieważ utrzymuje czysty rozdział między logiką a danymi. Ale kiedy umieścisz je w kontenerze, potencjalnie bawisz się ogniem.

Chociaż sterowniki do przechowywania kontenerów przeszły długą drogę, osobiście nie jestem jeszcze skłonny do zanurzenia się i pozostawienia moich danych zaplątanych w kontenerze.