Nazywam się Petr Zaitsev, jestem dyrektorem generalnym, założycielem i chcę Ci powiedzieć:
- jak przeszliśmy od rozwiązań open source do bazy danych jako usługi;
- jakie istnieją podejścia do wdrażania baz danych w chmurze;
- jak Kubernetes może zastąpić DBaaS, eliminując zależność od dostawcy i zachowując prostotę DBMS jako usługi.
Artykuł został przygotowany na podstawie raportu @Databases Meetup autorstwa Mail.ru Cloud Solutions & Tarantool. Jeśli nie chcesz czytać, możesz obejrzeć:
Jak przeszliśmy od oprogramowania open source do bazy danych jako usługi w chmurze
Pracuję w open source od końca lat 90-tych. Dwadzieścia lat temu korzystanie z open source, jakim są bazy danych, nie było takie proste. Trzeba było pobrać kod źródłowy, załatać go, skompilować i dopiero potem używać.
Oprogramowanie open source przeszło następnie szereg uproszczeń:
- źródła Tar.gz i INSTALL, które należało skompilować;
- pakiety z zależnościami takimi jak .deb i .rpm, gdzie wystarczy zainstalować zestaw pakietów;
- repozytoria pakietów, takie jak APT i YUM, z którymi instalacja odbywa się automatycznie;
- rozwiązania takie jak Docker i Snap, które umożliwiają odbieranie pakietów poprzez instalację bez zewnętrznych zależności.
W rezultacie korzystanie z oprogramowania open source staje się łatwiejsze, a także obniża się bariera wejścia na rynek tego typu aplikacji.
Jednocześnie, w odróżnieniu od sytuacji 20 lat temu, kiedy każdy był ekspertem od montażu, obecnie większość programistów nie może budować narzędzi, z których korzysta, ze źródeł.
Właściwie nie jest to złe, ponieważ:
- Możemy używać bardziej złożonego, ale bardziej przyjaznego dla użytkownika oprogramowania. Na przykład przeglądarka jest wygodna w użyciu, ale zawiera wiele komponentów typu open source i tworzenie jej od zera jest niewygodne.
- Więcej osób może zostać twórcami oprogramowania typu open source i innego, firmy korzystają z większej liczby programów, a zapotrzebowanie na nie jest większe.
Minusem jest to, że kolejny krok w kierunku uproszczeń wiąże się z wykorzystaniem rozwiązań chmurowych, a to prowadzi do pewnego uzależnienia od dostawcy, czyli związania się z jednym dostawcą. My korzystamy z prostych rozwiązań, a dostawcy korzystają z komponentów open source, ale tak naprawdę są przybici do jednej z dużych chmur. Oznacza to, że najłatwiejszym i najszybszym sposobem wdrożenia oprogramowania open source (i oprogramowania z nim zgodnego) jest chmura przy użyciu zastrzeżonego interfejsu API.
Jeśli chodzi o bazy danych w chmurze, istnieją dwa podejścia:
- Zmontuj infrastrukturę bazy danych, jak w zwykłym centrum danych. Oznacza to, że weź standardowe elementy składowe: obliczenia, pamięć masową itd., zainstaluj na nich Linuksa i bazę danych, a następnie skonfiguruj je.
- Skorzystaj z Database as a Service, gdzie dostawca oferuje gotową bazę danych w chmurze.
DBaaS jest obecnie szybko rozwijającym się rynkiem, ponieważ umożliwia programistom bezpośrednią pracę z bazami danych i minimalizuje rutynową pracę. Dostawca zobowiązuje się zapewnić wysoką dostępność i łatwe skalowanie, łatanie baz danych, tworzenie kopii zapasowych i dostrajanie wydajności.
Dwa typy Database as a Service oparte na open source oraz alternatywa w postaci Kubernetesa
Istnieją dwa typy bazy danych jako usługi dla otwartych baz danych:
- Standardowy produkt typu open source w pakiecie administracyjnym ułatwiającym wdrażanie i zarządzanie.
- Zaawansowane rozwiązanie komercyjne z różnymi dodatkami, kompatybilne z open source.
Obie opcje ograniczają możliwość migracji pomiędzy chmurami oraz zmniejszają przenośność danych i aplikacji. Na przykład, pomimo faktu, że różne typy chmur obsługują zasadniczo ten sam standard MySQL, istnieją między nimi znaczne różnice: w działaniu, wydajności, tworzeniu kopii zapasowych i tak dalej. Migracja z jednej chmury do drugiej może być wyzwaniem, szczególnie w przypadku złożonych aplikacji.
I tu pojawia się pytanie – czy można uzyskać wygodę Bazy Danych jako Usługi, ale jako prostego rozwiązania open source?
Zła wiadomość jest taka, że niestety nie ma jeszcze takich rozwiązań na rynku. Dobra wiadomość jest taka, że istnieje Kubernetes, który pozwala na wdrożenie takich rozwiązań.
Kubernetes to system operacyjny dla chmury lub centrum danych, który umożliwia wdrażanie aplikacji i zarządzanie nią na wielu serwerach w klastrze, a nie na jednym hoście.
Teraz Kubernetes jest liderem w kategorii tego typu oprogramowania. Było wiele różnych rozwiązań tego typu problemów, ale stało się to standardem. Wiele firm, które kiedyś skupiały się na rozwiązaniach alternatywnych, obecnie skupia się na dostosowaniu swoich produktów do obsługi Kubernetesa.
Dodatkowo Kubernetes to uniwersalne rozwiązanie, które wspierane jest w chmurach prywatnych, publicznych i hybrydowych wielu dostawców np.: AWS, Google Cloud, Microsoft Azure, .
Jak Kubernetes współpracuje z bazami danych
Kubernetes został pierwotnie zaprojektowany dla aplikacji bezstanowych, które przetwarzają dane, ale niczego nie przechowują, takich jak mikrousługi lub aplikacje internetowe. Bazy danych znajdują się na drugim końcu spektrum, to znaczy są aplikacjami stanowymi. Kubernetes nie był pierwotnie przeznaczony do takich zastosowań.
Istnieją jednak funkcje, które pojawiły się ostatnio w Kubernetesie, które umożliwiają korzystanie z baz danych i innych aplikacji stanowych:
- Koncepcja StatefulSet to cały szereg prymitywów do przetwarzania zdarzeń dotyczących zatrzymywania pracy podów i implementowania Graceful Shutdown (przewidywalnego zamykania aplikacji).
- Woluminy trwałe to magazyny danych powiązane z podami, obiektami zarządzania Kubernetes.
- Operator Framework – czyli możliwość tworzenia komponentów do zarządzania bazami danych i innymi aplikacjami stanowymi rozproszonymi po wielu węzłach.
Już teraz w chmurach publicznych funkcjonują duże bazy danych jako usługa, których backendem jest Kubernetes np.: CockroachCloud, InfluxDB, PlanetScale. Oznacza to, że baza danych na Kubernetesie to nie tylko coś, co jest teoretycznie możliwe, ale także coś, co sprawdza się w praktyce.
Percona oferuje dwa rozwiązania typu open source dla Kubernetes:
- Operator Kubernetes dla serwera Percona dla MongoDB.
- Kubernetes Operator dla XtraDB CLUSTER to usługa kompatybilna z MySQL, zapewniająca wysoką dostępność i spójność. Możesz także użyć pojedynczego węzła, jeśli nie jest wymagana wysoka dostępność, na przykład dla bazy danych deweloperów.
Użytkowników Kubernetesa można podzielić na dwie grupy. Część osób korzysta bezpośrednio z Operatorów Kubernetes – są to głównie zaawansowani użytkownicy, którzy dobrze rozumieją, jak działa ta technologia. Inni uruchamiają go na backendie – takich użytkowników interesuje coś w rodzaju Database as a Service, nie chcą zagłębiać się w niuanse Kubernetesa. Dla drugiej grupy użytkowników mamy kolejne rozwiązanie open source – Percona DBaaS CLI Tool. Jest to eksperymentalne rozwiązanie dla tych, którzy chcą uzyskać DBaaS typu open source oparty na Kubernetesie bez głębokiego zrozumienia tej technologii.
Jak uruchomić DBaaS firmy Percona w Google Kubernetes Engine
Google Kubernetes Engine moim zdaniem jest jedną z najbardziej funkcjonalnych implementacji technologii Kubernetes. Jest dostępna w wielu regionach świata i posiada proste i wygodne narzędzie wiersza poleceń (SDK), które pozwala na tworzenie skryptów zamiast ręcznego zarządzania platformą.
Aby nasz DBaaS działał, potrzebujemy następujących komponentów:
- Kubectl.
- Pakiet SDK Google Cloud.
- Percona DBaaS CLI.
Zainstaluj kubectl
Instalujemy pakiet dla Twojego systemu operacyjnego, przyjrzymy się przykładowi Ubuntu. Więcej szczegółów .
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
Instalowanie pakietu SDK Google Cloud
W ten sam sposób instalujemy pakiet oprogramowania. Więcej szczegółów .
# Add the Cloud SDK distribution URI as a package source
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg]
http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
# Import the Google Cloud Platform public key
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
# Update the package list and install the Cloud SDK
sudo apt-get update && sudo apt-get install google-cloud-sdk
Instalowanie interfejsu Percona DBaaS CLI
Zainstaluj z repozytoriów Percona. Narzędzie Percona DBaaS CLI Tool jest nadal produktem eksperymentalnym, dlatego znajduje się w repozytorium eksperymentalnym, które należy włączyć osobno, nawet jeśli masz już zainstalowane repozytoria Percona.
Szczegółowo .
Algorytm instalacji:
- Skonfiguruj repozytoria Percona za pomocą narzędzia percona-release. Najpierw musisz pobrać i zainstalować oficjalny pakiet wydania percona z Percona:
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb sudo dpkg -i percona-release_latest.generic_all.deb - Włącz komponent repozytorium narzędzi eksperymentalnych w następujący sposób:
sudo percona-release enable tools experimental - Zainstaluj pakiet percona-dbaas-cli:
sudo apt-get update sudo apt-get install percona-dbaas-cli
Konfigurowanie działania komponentów
Więcej o ustawieniach .
Najpierw musisz zalogować się na swoje konto Google. Co więcej, Google Cloud pozwala jednemu użytkownikowi mieć wiele niezależnych projektów, dlatego musisz określić działający projekt za pomocą kodu dla tego projektu:
gcloud auth login
gcloud config set project hidden-brace-236921
Następnie tworzymy klaster. Na potrzeby demonstracji utworzyłem klaster Kubernetes składający się tylko z trzech węzłów - to minimum wymagane do zapewnienia wysokiej dostępności:
gcloud container clusters create --zone us-central1-a your-cluster-name --cluster-version 1.15 --num-nodes=3
Poniższe polecenie kubectl nadaje pożądane uprawnienia naszemu obecnemu użytkownikowi:
kubectl create clusterrolebinding cluster-admin-binding-$USER
--clusterrole=cluster-admin --user=$(gcloud config get-value core/account)Następnie tworzymy przestrzeń nazw i aktywujemy ją. Przestrzeń nazw, z grubsza mówiąc, również przypomina projekt lub środowisko, ale już znajduje się w klastrze Kubernetes. Jest niezależny od projektów Google Cloud:
kubectl create namespace my-namespace
kubectl config set-context --current --namespace=my-namespace
Uruchamianie klastra
Po wykonaniu tych kilku kroków możemy uruchomić klaster z trzema węzłami za pomocą tego prostego polecenia:
# percona-dbaas mysql create-db example
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: example
Resource Endpoint: example-proxysql.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: Nt9YZquajW7nfVXTTrP
Status: ready
Jak połączyć się z klastrem
Domyślnie jest dostępny tylko w Kubernetesie. Oznacza to, że nie jest on dostępny z tego serwera, z którego uruchomiłeś polecenie „Utwórz”. Aby udostępnić go np. do testów z klientem należy przekierować port poprzez Port Mapping:
kubectl port-forward svc/example-proxysql 3306:3306 $Następnie łączymy Twojego klienta MySQL:
mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP
Zaawansowane polecenia zarządzania klastrami
Baza danych na publicznym adresie IP
Jeśli potrzebujesz bardziej trwałego rozwiązania w zakresie dostępności klastra, możesz uzyskać zewnętrzny adres IP. W takim przypadku baza danych będzie dostępna z dowolnego miejsca. Jest to mniej bezpieczne, ale często wygodniejsze. W przypadku zewnętrznego adresu IP używamy następującego polecenia:
# percona-dbaas mysql create-db exposed
--options="proxysql.serviceType=LoadBalancer"
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: exposed
Resource Endpoint: 104.154.133.197
Port: 3306
User: root
Pass: k0QVxTr8EVfgyCLYse
Status: ready
To access database please run the following command:
mysql -h 104.154.133.197 -P 3306 -uroot -pk0QVxTr8EVfgyCLYse
Jawnie ustaw hasło
Zamiast losowego generowania hasła przez system, możesz ustawić hasło jawnie:
# percona-dbaas mysql create-db withpw --password=mypassword
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: withpw
Resource Endpoint: withpw-proxysql.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: mypassword
Status: ready
Pokazuję dane wyjściowe skryptów w formacie czytelnym dla człowieka, ale obsługiwany jest również format JSON.
Wyłączanie wysokiej dostępności
Za pomocą następującego polecenia możesz wyłączyć wysoką dostępność w celu wdrożenia pojedynczego węzła:
# percona-dbaas mysql create-db singlenode
--options="proxysql.enabled=false, allowUnsafeConfigurations=true,pxc.size=1"
Starting ......................................... [done]
Database started successfully, connection details are below:
Provider: k8s
Engine: pxc
Resource Name: singlenode
Resource Endpoint: singlenode-pxc.my-namespace.pxc.svc.local
Port: 3306
User: root
Pass: 22VqFD96mvRnmPMGg
Status: ready
Jest to rozwiązanie do zadań testowych, które pozwala na jak najszybsze i najłatwiejsze uruchomienie MySQL, przetestowanie go, a następnie zamknięcie lub wykorzystanie do celów programistycznych.
Narzędzie Percona DBaaS CLI pomaga uzyskać rozwiązanie podobne do DBaaS na platformie Kubernetes. Jednocześnie cały czas pracujemy nad jego funkcjonalnością i użytecznością.
Raport ten został po raz pierwszy zaprezentowany o godz przez Mail.ru Cloud Solutions i Tarantool. Patrzeć inne występy i subskrybuj ogłoszenia o wydarzeniach na Telegramie .
Co jeszcze przeczytać na ten temat:
Źródło: www.habr.com