Ky kjo artikull vazhdon materialin tonë të fundit dhe i është kushtuar MongoDB. Duke qenë se ne shërbejmë shumë klasterë Kubernetes dhe MongoDB, arritëm në nevojën natyrore për të migruar të dhënat nga një instalim në tjetrin dhe për ta bërë këtë pa ndalesë. Skenarët kryesorë janë të njëjtë: transferimi i MongoDB nga një server virtual/fizik në Kubernetes ose transferimi i MongoDB brenda një klasteri të vetëm Kubernetes (nga një hapësirë emri në tjetrën).
Receta jonë është e destinuar për rastet kur funksionon një klaster i vjetër MongoDB (p.sh., nga 3 nyje dhe ndodhet ose tashmë në K8s, ose në serverë të vjetër), me të cilin punon një aplikacion i vendosur në Kubernetes:
Si do ta transferojmë një klaster të tillë në prodhim të ri në Kubernetes?
Teoria
Algoritmi i përgjithshëm i migrimit është i ngjashëm me atë të përshkruar në situatën me RabbitMQ.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se pĂ«r tĂ« mundĂ«suar zhvendosjen, serverĂ«t me MongoDB dhe Kubernetes duhet tĂ« jenĂ« nĂ« njĂ« rrjet tĂ« njĂ«jtĂ«. Nyjet e klasterit MongoDB do tĂ« komunikojnĂ« me njĂ«ra-tjetrĂ«n pĂ«rmes IP-sĂ« sĂ« serverĂ«ve tĂ« vjetĂ«r (ku ndodhen instalimet e vjetra tĂ« MongoDB) dhe pĂ«rmes emrave DNS tĂ« podâave me MongoDB nĂ« K8s. Prandaj, nĂ« serverĂ«t fizikĂ« (me instalimet e vjetra) do tĂ« jetĂ« e nevojshme tĂ« krijoni rute drejt podâave, dhe pastaj t'i configure pĂ«r tĂ« pĂ«rdorur serverin DNS qĂ« punon nĂ« Kubernetes (ose tĂ« shkruani emrat e nevojshĂ«m nĂ« /etc/hosts, megjithatĂ«, nĂ« pĂ«rgjithĂ«si, kjo mundĂ«si duhet tĂ« evitohesh.
Hapi tjetĂ«r Ă«shtĂ« ngritja e klasterit MongoDB nĂ« podâave Kubernetes. NĂ« rastin tonĂ«, klasteri i DB pĂ«rbĂ«het nga 3 nyje dhe çdo nyje ndodhet nĂ« njĂ« pod tĂ« veçantĂ« K8s â megjithatĂ«, numri i tyre mund tĂ« jetĂ« edhe ndryshe. NĂ« ConfigMap duhet tĂ« specifikohet adresa e masterit tĂ« MongoDB nga instalimi i vjetĂ«r: kĂ«shtu qĂ« nyjet MongoDB, tĂ« cilat ndodhen nĂ« podâave nĂ« K8s, do tĂ« fillojnĂ« menjĂ«herĂ« sinkronizimin me tĂ«.
Pas ngritjes sĂ« tĂ« gjitha podâave, do tĂ« formohet njĂ« klaster MongoDB nga 6 nyje:
Kujdes, duke pasur parasysh se podâave do tâu duhen shumĂ« kohĂ« pĂ«r t'u ngritur, sepse çdo pod nis njĂ«ri pas tjetrit dhe gjatĂ« ngritjes sinkronizon tĂ« dhĂ«nat me masterin.
Pas kësaj, është e mundur të kalojmë aplikacionin në përdorimin e serverëve të rinj të MongoDB:
Dhe mbetet vetëm të fshijmë nyjet e vjetra nga klasteri MongoDB, pas së cilës zhvendosja mund të konsiderohet e përfunduar:
Këtë skemë e përdorim shpesh në prodhim dhe për lehtësinë e përdorimit të saj e kemi realizuar në kuadër të modulit të (këtë utilitet ne ), e cila lejon shpërndarjen e konfigurimeve standarde të MongoDB në shumë klasterë. Publikimin e moduleve tona e planifikojmë ta kryejmë së shpejti, ndërsa për tani paraqesim udhëzime të veçanta, me të cilat mund të provoni zgjidhjen që ofrohet në veprim dhe pa përdorimin e addon-operator.
Provojmë në praktikë
KĂ«rkesat
Të dhënat:
- Kluster Kubernetes (i përshtatshëm edhe për minikube);
- Kluster MongoDB (mund të jetë i vendosur në bare metal, ose i krijuar si një kluster i zakonshëm në Kubernetes nga Helm-chart-i zyrtar).
Në shembullin e përshkruar më poshtë, klusteri i vjetër me MongoDB do të quhet mongo-old dhe do të instalohet në të njëjtin kluster Kubernetes, ku më pas do të instalojmë edhe të riun (mongo-new).
Përgatitja e klusterit të vjetër
1. Për shembull, për të demonstruar skemën e përshkruar në veprim, do të krijojmë klusterin e "vjetër" (dmth, nën migrim) MongoDB direkt në Kubernetes (në realitet ai mund të jetë edhe në servera të veçantë jashtë K8s). Për këtë, do të shkarkojmë Helm-chart-in:
helm fetch --untar stable/mongodb-replicaset⊠dhe do ta redaktojmë pak, duke e konfiguruar autorizimin:
auth:
enabled: true
adminUser: mongo
adminPassword: pa33w0rd
# metricsUser: metrics
# metricsPassword: password
# key: keycontent
# existingKeySecret:
# existingAdminSecret:
# exisitingMetricsSecret: Gjithashtu në values.yaml mund të konfigurohen certifikatat dhe shumë gjëra të tjera.
2. Do të instalojmë chart-in:
helm install . --name mongo-old --namespace mongo-oldPas kësaj do të nisë instalimi testues i "vjetër" të MongoDB:
kubectl --namespace=mongo-old get pods 
Do të hyjmë në pod-in me master-in e saj dhe do të krijojmë një bazë testuese:
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')
use music
db.artists.insert({ artistname: "The Tea Party" })
show dbs 
Duke hyrë në pod të ndryshëm, kam zbuluar se master-i është mongo-old-mongodb-replicaset-0. Megjithatë, për një zgjidhje më të lehtë, pas instalimit të Helm-chart-it jepet komanda se si të përcaktohet MASTER_POD. Në rastin tim (për mongo-old nga 3 nyje) duket kështu:
for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; doneKështu, përgatitja e instalimit të vjetër të MongoDB, të dhënat e të cilit do të transferohen, është gati.
Migrimi i klusterit MongoDB
Tani do të vendosim një instalim të ri të MongoDB, i cili do të jetë në Kubernetes dhe do të përdoret nga aplikacioni në produkcion.
NB: Vërej se duhet të përdoret e njëjta version i MongoDB, siç ishte më parë. Në të kundërt, ka rrezik të kemi probleme me përputhshmërinë.
Në mënyrë analogjike me seksionin e mëparshëm (ku imituam instalimin «e vjetër» të MongoDB), do të marrim Helm-chart të përmendur më parë (me komandën helm fetch) dhe do të konfiguroni autorizimin, si dhe parametrat e tjerë, nëse përdoren. Për më tepër, do të përmirësojmë skedarin init/on-start.sh, duke shtuar përkohësisht në rreshtin 165 adresën e masterit, e cila u mor në fazën e mëparshme (ose që e dini nga instalimi i MongoDB në serverë të veçantë):
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'Jemi gati për të krijuar një instalim të ri të MongoDB:
helm install . --name mongo-new --namespace mongo-newPritni derisa të fillojnë të gjitha podët (nëse të dhënat janë të shumta, hapja e tyre mund të zgjasë orë):
Tani po bëjmë exec në pod-in e ri dhe shohim listën e bazave:
kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo 
Dy klasterë MongoDB janë bashkuar në një, duke përbërë 6 nyje.
Tani është e mundur të kaloni aplikacionin në klasterin e ri, por për të përfunduar migrimin kanë mbetur disa hapa.
Nga skedari init/on-start.sh në instalimin e ri i heqim rreshtin e shtuar nga ne:
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'Tani hyjmĂ« nĂ« masterin e vjetĂ«r tĂ« klasterit dhe «rrĂ«zojmë» atĂ« â pastaj nĂ« klaster do tĂ« caktohet njĂ« master i ri. HynĂ« nĂ« pod-in me masterin e MongoDB:
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')Pas kësaj, ndryshojmë prioritetet e nyjave dhe ndryshojmë masterin:
cfg = rs.conf()
cfg.members[5].priority = 2
rs.reconfig(cfg)
rs.stepDown(120)Nyja aktuale ka ndaluar sĂ« qeni master â do tĂ« zhvillohen zgjedhje pĂ«r njĂ« tĂ« ri. Duke qenĂ« se ne ndryshuam prioritetet, nyja qĂ« na nevojitet do tĂ« bĂ«het master.
NB: Me default, të gjitha nyjat e MongoDB kanë prioritet 1. Më lart e rritëm prioritetin e nyjës që na nevojitet deri në 2. Kështu, masteri i përgjithshëm bëhet patjetër një anëtar i klasterit të ri. Më shumë rreth këtyre mekanizmave në MongoDB mund të lexoni në .
Do të çaktivizojmë instalimin e vjetër të MongoDB, pas së cilës do të hyjmë në masterin e ri dhe do të fshijmë nyjat e vjetra:
rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")Pas kësaj, migrimi mund të konsiderohet i përfunduar: ne u kaluam me sukses nga klasteri i vjetër i MongoDB në të riun!
PĂ«rfundime
Schema e përshkruar i përshtatet praktikisht të gjitha rasteve kur duhet të transferoni MongoDB ose thjesht të zhvendoseni në një klaster të ri.
Një nga detajet kryesore gjatë migrimit është nevoja për të kaluar IP-të e podëve të rinj në serverët e instalimit të vjetër të MongoDB, nëse ai ndodhet jashtë K8s, dhe emërtimi i saktë i tyre në DNS (ose /etc/hosts). Në këtë shembull, këto hapa nuk ishin të nevojshëm, sepse migrimi ndodhi ndërmjet hapësirave të ndryshme emri në të njëjtin Kubernetes cluster.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
