A nevem Petr Zaitsev, én vagyok a vezérigazgató, alapító és szeretném elmondani:
- hogyan jutottunk el a nyílt forráskódú megoldásoktól az Adatbázis mint szolgáltatásig;
- milyen megközelítések léteznek az adatbázisok felhőben történő telepítésére;
- hogyan tudja a Kubernetes helyettesíteni a DBaaS-t, megszüntetve a szállítói függőséget és megőrizve a DBMS mint szolgáltatás egyszerűségét.
A cikk a Mail.ru Cloud Solutions & Tarantool @Databases Meetup jelentése alapján készült. Ha nem akarsz olvasni, megnézheted:
Hogyan jutottunk el a nyílt forráskódtól az adatbázishoz, mint szolgáltatáshoz a felhőben
A 90-es évek vége óta nyílt forráskóddal dolgozom. Húsz évvel ezelőtt a nyílt forráskódú, például adatbázisok használata nem volt olyan egyszerű. Le kellett tölteni a forráskódot, foltozni, lefordítani és csak utána használni.
A nyílt forráskód ezután számos egyszerűsítésen ment keresztül:
- Tar.gz és INSTALL források, amelyeket le kellett fordítani;
- olyan függőségi csomagok, mint a .deb és .rpm, ahol csak csomagkészletet kell telepíteni;
- csomagtárolók, mint például az APT és a YUM, amelyekkel a telepítés automatikus;
- megoldások, például a Docker és a Snap, amelyek lehetővé teszik a csomagok telepítéssel történő fogadását külső függőségek nélkül.
Ennek eredményeként könnyebbé válik a nyílt forráskódú szoftverek használata, és csökken az ilyen alkalmazások fejlesztésébe való belépési korlát.
Ugyanakkor, ellentétben a 20 évvel ezelőtti helyzettel, amikor mindenki összeszerelési szakértő volt, most a legtöbb fejlesztő nem tudja forrásból megépíteni az általa használt eszközöket.
Valójában ez nem rossz, mert:
- Használhatunk bonyolultabb, de felhasználóbarátabb szoftvereket. Például egy böngésző kényelmesen használható, de számos nyílt forráskódú összetevőt tartalmaz, és kényelmetlen a nulláról építeni.
- Többen válhatnak nyílt forráskódú és egyéb szoftverek fejlesztőjévé, több szoftvert használnak a vállalkozások, és nagyobb az igény is rá.
Hátránya, hogy az egyszerűsítés következő lépése a felhőmegoldások használatához kapcsolódik, és ez bizonyos szállítói lock-inhez, azaz egy szállítóhoz való kötődéshez vezet. Mi egyszerű megoldásokat használunk, a szolgáltatók pedig nyílt forráskódú komponenseket, de valójában az egyik nagy felhőhöz szegeződnek. Vagyis a nyílt forráskód (és a vele kompatibilis szoftverek) telepítésének legegyszerűbb és leggyorsabb módja a felhőben, egy szabadalmaztatott API használatával.
Amikor a felhőben lévő adatbázisokról van szó, két megközelítés létezik:
- Állítsa össze az adatbázis-infrastruktúrát, mint egy hagyományos adatközpontban. Vagyis vegyünk szabványos építőelemeket: számítás, tárolás és így tovább, telepítsük rájuk a Linuxot és egy adatbázist, és konfiguráljuk őket.
- Használja az Adatbázist szolgáltatásként, ahol a szolgáltató kész adatbázist kínál a felhőn belül.
A DBaaS jelenleg gyorsan növekvő piac, mert lehetővé teszi a fejlesztők számára, hogy közvetlenül dolgozzanak adatbázisokkal, és minimálisra csökkenti a rutinmunkát. A szolgáltató vállalja, hogy biztosítja a magas rendelkezésre állást és az egyszerű méretezést, az adatbázis-foltozást, a biztonsági mentéseket és a teljesítményhangolást.
Kétféle adatbázis, mint szolgáltatás nyílt forráskódon és egy alternatíva a Kubernetes formájában
Az Adatbázis mint szolgáltatás kétféle nyílt adatbázisokhoz használható:
- Szabványos nyílt forráskódú termék adminisztrációs háttérrendszerbe csomagolva az egyszerű telepítés és kezelés érdekében.
- Fejlett kereskedelmi megoldás különféle kiegészítőkkel, kompatibilis a nyílt forráskóddal.
Mindkét lehetőség csökkenti a felhők közötti migráció lehetőségét, és csökkenti az adatok és alkalmazások hordozhatóságát. Például annak ellenére, hogy a különböző típusú felhők lényegében ugyanazt a szabványos MySQL-t támogatják, jelentős különbségek vannak közöttük: működésben, teljesítményben, biztonsági mentésben stb. Az egyik felhőről a másikra való migráció kihívást jelenthet, különösen összetett alkalmazások esetén.
És itt felvetődik a kérdés - elérhető-e az adatbázis kényelme szolgáltatásként, de egyszerű nyílt forráskódú megoldásként?
A rossz hír az, hogy sajnos ilyen megoldások még nincsenek a piacon. A jó hír az, hogy létezik a Kubernetes, amely lehetővé teszi az ilyen megoldások megvalósítását.
A Kubernetes egy olyan operációs rendszer a felhőhöz vagy adatközponthoz, amely lehetővé teszi egy alkalmazás telepítését és kezelését több kiszolgálón egy fürtben, nem pedig egyetlen gazdagépen.
Most a Kubernetes a vezető az ilyen szoftverek kategóriájában. Sokféle megoldás született az ilyen problémákra, de ez lett a standard. Sok vállalat, amely korábban az alternatív megoldásokra összpontosított, most arra összpontosít, hogy termékeit a Kubernetes támogatásához igazítsa.
Ezenkívül a Kubernetes egy univerzális megoldás, amelyet számos gyártó privát, nyilvános és hibrid felhői támogatnak, például: AWS, Google Cloud, Microsoft Azure, .
Hogyan működik a Kubernetes az adatbázisokkal
A Kubernetes eredetileg állapot nélküli alkalmazásokhoz készült, amelyek adatokat dolgoznak fel, de nem tárolnak semmit, például mikroszolgáltatásokhoz vagy webes alkalmazásokhoz. Az adatbázisok a spektrum másik végén vannak, vagyis állapotjelző alkalmazások. És a Kubernetes eredetileg nem ilyen alkalmazásokra készült.
Vannak azonban olyan szolgáltatások, amelyek a közelmúltban jelentek meg a Kubernetesben, amelyek lehetővé teszik adatbázisok és más állapotjelző alkalmazások használatát:
- A StatefulSet koncepció primitívek egész sorozata a pod-ok munkájának leállításával és a Graceful Shutdown (az alkalmazás kiszámítható leállítása) végrehajtásával kapcsolatos események feldolgozására.
- Az állandó kötetek olyan adattárolók, amelyek podokhoz, Kubernetes felügyeleti objektumokhoz vannak társítva.
- Operator Framework – azaz a sok csomópont között elosztott adatbázisok és egyéb állapotjelző alkalmazások kezelésére szolgáló összetevők létrehozásának képessége.
A nyilvános felhőkben már most is vannak nagy Databases as a Service, amelyek háttere a Kubernetes, például: CockroachCloud, InfluxDB, PlanetScale. Vagyis egy Kubernetes adatbázis nem csak elméletileg lehetséges, hanem a gyakorlatban is működik.
A Percona két nyílt forráskódú megoldást kínál a Kubernetes számára:
- Kubernetes Operator a Percona Server for MongoDB számára.
- A Kubernetes Operator for XtraDB CLUSTER egy olyan szolgáltatás, amely kompatibilis a MySQL-lel, és magas rendelkezésre állást és konzisztenciát biztosít. Használhat egyetlen csomópontot is, ha nincs szükség magas rendelkezésre állásra, például egy fejlesztői adatbázishoz.
A Kubernetes felhasználók két csoportra oszthatók. Vannak, akik közvetlenül használják a Kubernetes Operatorokat – ezek főként haladó felhasználók, akik jól ismerik a technológia működését. Mások a háttérrendszeren futtatják – az ilyen felhasználókat valami olyasmi érdekli, mint az Adatbázis mint szolgáltatás, nem akarnak belemenni a Kubernetes árnyalataiba. A felhasználók második csoportja számára van egy másik nyílt forráskódú megoldásunk - a Percona DBaaS CLI Tool. Ez egy kísérleti megoldás azok számára, akik Kubernetes alapú nyílt forráskódú DBaaS-t szeretnének beszerezni anélkül, hogy mélyen ismernék a technológiát.
A Percona DBaaS futtatása a Google Kubernetes Engine-en
A Google Kubernetes Engine véleményem szerint a Kubernetes technológia egyik legfunkcionálisabb megvalósítása. A világ számos régiójában elérhető, és rendelkezik egy egyszerű és kényelmes parancssori eszközzel (SDK), amely lehetővé teszi szkriptek létrehozását a platform manuális kezelése helyett.
A DBaaS működéséhez a következő összetevőkre van szükségünk:
- Kubectl.
- Google Cloud SDK.
- Percona DBaaS CLI.
Telepítse a kubectl
Telepítjük a csomagot az operációs rendszeréhez, megnézzük az Ubuntu példáját. További részletek .
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
A Google Cloud SDK telepítése
Ugyanígy telepítjük a szoftvercsomagot. További részletek .
# 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
A Percona DBaaS CLI telepítése
Telepítse a Percona tárolókból. A Percona DBaaS CLI Tool még csak kísérleti termék, ezért a kísérleti tárolóban található, amelyet külön engedélyezni kell, még akkor is, ha már telepítve vannak a Percona tárolók.
Több .
Telepítési algoritmus:
- Állítsa be a Percona adattárakat a Percona-release eszközzel. Először le kell töltenie és telepítenie kell a hivatalos Percona-release csomagot a Perconától:
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb sudo dpkg -i percona-release_latest.generic_all.deb - Engedélyezze a kísérleti eszköztár komponenst az alábbiak szerint:
sudo percona-release enable tools experimental - Telepítse a percona-dbaas-cli csomagot:
sudo apt-get update sudo apt-get install percona-dbaas-cli
Az alkatrészek működésének beállítása
Bővebben a beállításokról .
Először be kell jelentkeznie Google-fiókjába. Ezenkívül a Google Cloud lehetővé teszi egy felhasználónak több független projektet, ezért meg kell adnia egy működő projektet a projekt kódjával:
gcloud auth login
gcloud config set project hidden-brace-236921
Ezután létrehozunk egy klasztert. A demóhoz létrehoztam egy mindössze három csomópontból álló Kubernetes-fürtöt – ez a minimálisan szükséges a magas rendelkezésre álláshoz:
gcloud container clusters create --zone us-central1-a your-cluster-name --cluster-version 1.15 --num-nodes=3
A következő kubectl parancs megadja a kívánt jogosultságokat jelenlegi felhasználónknak:
kubectl create clusterrolebinding cluster-admin-binding-$USER
--clusterrole=cluster-admin --user=$(gcloud config get-value core/account)Ezután létrehozunk egy névteret, és aktiváljuk. A névtér nagyjából olyan, mint egy projekt vagy környezet, de már egy Kubernetes-fürtön belül van. Ez független a Google Cloud projektektől:
kubectl create namespace my-namespace
kubectl config set-context --current --namespace=my-namespace
A klaszter indítása
Miután elvégeztük ezt a néhány lépést, elindíthatunk egy három csomópontból álló klasztert ezzel az egyszerű paranccsal:
# 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
Hogyan csatlakozhatunk egy fürthöz
Alapértelmezés szerint csak a Kubernetesen belül érhető el. Vagyis nem érhető el erről a szerverről, amelyről a „Létrehozás” parancsot futtatta. Ahhoz, hogy elérhető legyen például egy klienssel végzett tesztekhez, továbbítania kell a portot a Port Mappingen keresztül:
kubectl port-forward svc/example-proxysql 3306:3306 $Ezután csatlakoztatjuk a MySQL klienst:
mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP
Speciális fürtkezelési parancsok
Nyilvános IP adatbázis
Ha tartósabb megoldást szeretne a fürt elérhetőségére, szerezhet külső IP-címet. Ebben az esetben az adatbázis bárhonnan elérhető lesz. Ez kevésbé biztonságos, de gyakran kényelmesebb. Külső IP esetén a következő parancsot használjuk:
# 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
Kifejezetten állítsa be a jelszót
Ahelyett, hogy a rendszer véletlenszerűen generálna jelszót, a jelszót kifejezetten beállíthatja:
# 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
A szkriptek kimenetét ember által olvasható formátumban jelenítem meg, de a JSON formátum is támogatott.
A magas rendelkezésre állás kikapcsolása
A következő paranccsal letilthatja a magas rendelkezésre állást egyetlen csomópont telepítéséhez:
# 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
Ez egy megoldás a tesztelési feladatokhoz, hogy a MySQL-t a lehető leggyorsabban és legegyszerűbben üzembe helyezze, tesztelje, majd leállítsa vagy fejlesztésre használja.
A Percona DBaaS CLI eszköz segít a DBaaS-szerű megoldás elérésében a Kubernetesen. Ugyanakkor továbbra is dolgozunk a funkcionalitásán és a használhatóságán.
Ezt a jelentést először a készítette: Mail.ru Cloud Solutions&Tarantool. Néz egyéb előadásokat, és iratkozzon fel a Telegram eseményhirdetéseire .
Mit érdemes még olvasni a témában:
Forrás: will.com