Wstęp
Czy powinno się korzystać z Dockera w przypadku baz danych? Jedni mówią tak, jedni mówią nie. Komu więc wierzyć? Pozwól, że podzielę się moimi subiektywnymi przemyśleniami na ten temat.
Na pewno nie zastanawiasz się, czy baza danych uruchomiona w kontenerze to dobry pomysł, gdy mowa o środowisku developerskim. Po prostu, bierzesz gotowy obraz, uruchamiasz i korzystasz.
Jeżeli pracujesz nad wieloma projektami jednocześnie, lub często je zmieniasz, gdzie wraz ze zmianą projektu, często zmieniają się technologie (w tym baza danych) na pewno znasz to uczucie, ponownego setupu środowiska developerskiego. No bo co może być gorszego i bardziej nudnego, niż manualna instalacja i konfiguracja całego środowiska, w tym bazy danych. Nie wspominając już o zaśmiecaniu swojego systemu operacyjnego.
OK, a co z produkcją? Używanie bazy danych w Dockerze staje się mniej łatwym wyborem gdy mamy do czynienia z bardziej krytycznymi systemami. Koniec końców, wszystko zależy od Ciebie. I od Twoich potrzeb. Odpowiedz zatem sobie na podstawowe pytania:
- Jakie ryzyko jesteś w stanie podjąć?
- Czy w razie krytycznej sytuacji, masz obok kogoś kto będzie Ci w stanie pomóc z Twoim problemem?
- Jakie są benefity tego podejścia?
Niestety, ale część ludzi popada w skrajność, że Docker jest magicznym narzędziem, które można stosować wszędzie i do wszystkiego 🙂
Baza Danych w Dockerze w środowisku developerskim
W środowisku developerskim, nie ma nic, czym należało by się martwić. Nie masz przecież żadnych ważnych danych klienta, które możesz stracić. Jeśli cokolwiek pójdzie nie tak, ubijasz i stawiasz swoje środowisko na nowo. Proste, nie?
Jakie zalety w tym przypadku można wymieć?
- Możesz odtworzyć swoje środowisko praktycznie niezależnie od OS.
- Możesz pracować nad wieloma projektami jednocześnie, które opierają się o inne silniki/wersje bazy danych
- Nie zaśmiecasz swojego OS
- Masz zautomatyzowany proces (szczególnie dla nowych członków zespołu)
Mniejsze projekty
W przypadku mniejszych projektów, projektów wewnętrznych, czy projektów, które operują na tzw. danych “nie-krytycznych”, baza w Dockerze jest jak najbardziej OK. Drugi powód to projekty w których musisz wspierać wiele różnych silników w wielu wersjach, badź też musisz optymalizować koszty.
Aby móc spać spokojnie, należałoby jednak spełnić przynajmniej podstawowe warunki:
- Upewnij się, że dane są przechowywane w volume’ach.
- Skonfiguruj automatyczne backupy
- Spróbuj przywrócić dane na podstawie utworzonych backupów, by mieć pewność, że są tworzone w odpowiedni sposób.
Ale od czego zacząć? Od stworzenia pliku docker-compose.yml. Jest to bardzo wygodne i świetnie pasujące rozwiązanie dla mniejszych projektów. W najgorszym wypadku, przywrócisz bazę danych na podstawie backupów i po kłopocie 🙂
Przykład małej aplikacji
Oto przykład docker-compose.yml, gdzie mamy do czynienia z PostgreSQL podłączonym do aplikacji webowej.
Warto zaznaczyć, iż aplikacja nie jest “krytyczna” oraz ilość jej użytkowników to raczej dziesiątki. Jest to mały portal do rezerwacji wizyt. Aby zapewnić persystencję danych, wykorzystano tutaj volume.
Środowiska produkcyjne dla krytycznych systemów
Dla systemów zawierających dane “krytyczne”, środowisko produkcyjne powinno oznaczać STABILNOŚĆ. Im mniej skomplikowane, tym łatwiej się nim zarządza. Wymaga bezpieczeństwa i jak najwyższej dostępności. Zapewne każdy świadomy specjalista, nie chciałby wprowadzać dodatkowego niepotrzebnego ryzyka w rozwiązaniu, które tworzy. Zapewne każdy świadomy specjalista, nie chciałby któregoś piątku, tuż przed opuszczeniem biura, usłyszeć, że produkcja padła i trzeba zostać dłużej w pracy.
Baza danych w Dockerze na produkcji? Bywało różnie 🙂 Na szczęście dziwne błędy, które występowały w pierwszych wersjach Dockera (rok 2016),
powodujące uszkodzenie danych, są już przeszłością. Jednak nadal, baza danych w kontenerze, szczególnie w przypadku krytycznych aplikacji, będzie tylko dodatkową warstwą do zarządzania i potencjalnym powodem do zmartwień.
Decydując się na bazę w kontenerze, warto rozważyć wersję Docker Enterprise. W razie problemów – nie zostaniemy z nimi sami, gdyż wraz z wersją Docker Enterprise otrzymujemy support.
Więcej o różnicy pomiędzy Docker Community a Docker Enterprise znajdziesz TUTAJ
Słowo o Kubernetes
Pracujesz właśnie nad kolejnym CRUDem (niestety często też tak mam) i ciągle słyszysz o konteneryzacji, o orchestracji przy pomocy Kubernetes czy Docker Swarm oraz deploymencie na wielu maszynach. Myślisz sobie: “Fajnie byłoby móc pracować nad takim projektem, gdzie architektura oparta jest na mikroserwisach, a całość ogarnia Kubernetes. Brzmi nieźle, co?
Należy jednak pamiętać, że narzędzia do orchestracji zostały stworzone do BEZSTANOWYCH aplikacji. Bezstanowość oznacza, że dla całego ekosystemu, składającego się z kilku/kilkunastu komponentów, nie ma dużego znaczenia ile instancji danego komponentu “żyje”, bądź czy jedna z dziesięciu maszyn w naszym klastrze nagle padła.
Oczywiście powyższy przypadek NIE dotyczy baz danych! Baza danych najczęściej jest punktem krytycznym. Utrata danych może spowodować, że nasza aplikacja będzie bezużyteczna.
Ktoś może powiedzieć: “Ale Kubernetes posiada Stateful Sets czy Persistent Volumes, które mogą rozwiązać nasz problem”.
Ktoś inny powie: “Wystarczy mieć replikację bazy i po problemie”.
Owszem, nawet jeżeli powyższe są “lekarstwem”, Ty nadal musisz to zaprojektować i skonfigurować oraz upewnić się, że konfiguracja spełnia Twoje początkowe założenia.
Czy masz już swoją kopię darmowego e-booka?
“21 Praktycznych Przykładów Użycia Dockera Dla Developerów”
Przykłady, gdzie to się sprawdza
Są przypadki, w których rzeczywiście znalazło to swoje zastosowanie. Przykład firmy Zalando, które na swoje potrzeby stworzyło “operator” PostgreSQL oparty o K8s.
https://github.com/zalando/postgres-operator
Zasadnicza różnica jest taka, że mieli oni konkretny powód by to stworzyć oraz świadomych inżynierów odpowiadających za to.
Innym przykładem jest duźy gracz na rynku czyli OVH.
https://www.ovh.com/blog/web-hosting-how-do-our-databases-work
Ale znowu, jak w przypadku Zalando, mieli konkretny powód by tak postąpić. Chcieli usprawnić proces migracji danych z jednego data center do drugiego. Z pewnością mają też recovery-plan.
Dodatkowo, OVH przyznaje: “Running databases under Docker is not simple, but we have a few years’ experience”.
Powyższe zdanie, potwierdza, że decydując się na takie rozwiązanie trzeba znać ryzyko i mieć doświadczenie.
Podsumowanie
Docker doskonale spisuje się do uruchamiania baz danych w środowiskach developerskich. Sprawdzi się również, dla małych projektów, działających na pojedynczych hostach.
Czy powinno się stosowac bazy danych w Dockerze na produkcji w przypadku krytycznych systemów?
Dopóki nie masz konkretnego powodu oraz konkretnych korzyści z hostowania bazy danych w Dockerze – moja odpowiedż brzmi – NIE.
Są lepsze rozwiązania, jak na przykład bazy danych w chmurze. Obecnie, AWS czy Azure posiadają w swojej ofercie świetne rozwiązania. Dodatkowo z automatu otrzymujemy backupy czy podnoszenie wersji, nie wspominając o magicznym “suwaku” tj. o skalowaniu. Jeżeli z jakiś powodów nie możesz skorzystać z rozwiązań cloudowych i musisz wdrożyc swoją aplikacje on-premise, zastanów się dwa razy i przemyśl czy baza danych w Dockerze będzie mieć dla Ciebie jakąś wartość, czy też chcesz tylko to zrobić z uwagi na trend jaki obecnie panuje.
PS. Jeżeli artykuł Ci się spodobał, podziel się nim (odnośniki poniżej) w twoim ulubionym Social Media. Dzięki!
Bardzo dobry artykuł!
Podczas czytania, naszło mnie jedno pytanie czy jeśli jednak zdecydujemy się na postawienie bazy danych na docker. To czy musimy pamiętać wtedy o ograniczeniach jakie ma docker, chodzi mi o ograniczenia wielkości na dysku dla działającego obrazu. Czy jeśli np. baza danych będzie miała 100GB, 200GB to docker nadal będzie działać?
Cześć Bartek.
Dziękuje za komentarz.
Pytanie czy warto tak wielkie bazy danych 100GB i 200GB pchać do kontenera oraz jakie korzyści uzyskasz mając bazę w kontenerze?
Skoro mamy taką wielką bazę to mamy też duży system, dla którego pewnie te dane są krytyczne.
Osobiście, do póki nie miałbym konkretnego powodu, tak dużej bazy danych nie pchałbym do kontenera.
Jeżeli podmontujesz pliki bazy danych z kontenera do katalogu na hoście – to ograniczeniem jest wielkość Twojego dysku twardego 🙂
Cześć
Zaczynam dopiero moja przygode w dockerze. Uruchomilem kontener z baza ms sql serwer. i jak uruchomie moja apliakcje ktora laczy sie do tej bazy w dokerze, to wszystko dziala ok. jesli ta sama aplikacje wsadze do kontenera to apliakcja wywala sie ze nie widzi bazy danych. Jak probuje polaczyc sie z serwisu w dokerze do bazy ms sql na hoscie, to tez mi nie widzi bazy danych. Co robie zle ?
Cześć!
Najprawdopodobniej chodzi o DNS’y.
Podeślij proszę dokładną instrukcję w jaki sposób uruchamiasz bazę danych, a w jaki aplikację. Ważne jest też jaką wartość masz ustawioną w ConnectionStringu w aplikacji. Wtedy będę mógł coś doradzić. Napisz na [email protected]