Ky this article vazhdon materialin tonë të fundit Receta jonë është e destinuar për rastet kur funksionon një klaster i vjetër MongoDB (p.sh., nga 3 nyje dhe që 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ë këtë klaster në një prodhim të ri në Kubernetes?
Algoritmi i përgjithshëm i migrimit është i ngjashëm me atë të përshkruar në rastin e RabbitMQ.
Teoria
Është e rëndësishme të theksohet se për të pasur mundësi migruese, serverët me MongoDB dhe Kubernetes duhet të jenë në të njëjtën rrjet. Nyjet e klasterit MongoDB do të komunikojnë me njëri-tjetrin përmes IP-ve të 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ë nevojitet të kaloni rrugët për tek pod'ët dhe më pas të konfigurohen për të përdorur serverin DNS që funksionon në Kubernetes (ose të shkruani emrat e nevojshëm në
, megjithatë, në përgjithësi, është më mirë të evitoni një mundësi të tillë). /etc/hostsHapi tjetër është ngritja e klasterit MongoDB në pod'ët e 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ë ndryshe. Në ConfigMap duhet të eksploroni adresën e masterit MongoDB nga instalimi i vjetër: atëherë nyjet MongoDB, që ndodhen në pod'ët në K8s, do të fillojnë menjëherë sinkronizimin me të.
Pasi të ngrihen të gjitha pod'ët, do të formohet një klaster MongoDB nga 6 nyje:
Vini re se pod'ët do të ngrihen ngadalë, pasi çdo pod fillon njëri pas tjetrit, dhe gjatë nisjes, sinkronizon të dhënat me masterin.
Pas kësaj mund ta kaloni aplikacionin për të përdorur serverët e rinj MongoDB:
Dhe do të mbetet vetëm të fshini nyjet e vjetra nga klasteri MongoDB, pas së cilës transferimi mund të konsiderohet i përfunduar:
Këtë skemë ne shpesh e përdorim në prodhim dhe për lehtësi të përdorimit të saj e kemi realizuar në kuadër të modulit të
(kjo utilitet ne e njoftuam së fundmi Detajet:
Të provojmë në praktikë
Kërkesat
Klasteri MongoDB (mund të jetë i ndërtuar si në bare metal, ashtu edhe si një klaster i zakonshëm në Kubernetes nga Helm-chart-i zyrtar).
- Kluster Kubernetes (minikube është gjithashtu në rregull);
- Në shembullin e mëposhtëm, klasteri i vjetër me MongoDB do të quhet
mongo-old dhe do të vendoset në të njëjtin klaster Kubernetes, ku më vonë do të vendosim dhe të riun ( mongo-newPërgatitja e klasterit të vjetër).
1. Për shembull, për të demonstruar skemën e përshkruar në veprim, do të krijojmë një klaster "të vjetër" (dmth. për migrim) MongoDB direkt në Kubernetes (në realitet, ai mund të ndodhet dhe në serverë të veçantë jashtë K8s). Për këtë do të shkarkojmë Helm-chart-in:
helm fetch --untar stable/mongodb-replicaset
… dhe pak do ta redaktojmë, duke konfigurur autorizimin:auth: enabled: true adminUser: mongo adminPassword: pa33w0rd # metricsUser: metrics # metricsPassword: password # key: keycontent # existingKeySecret: # existingAdminSecret: # existingMetricsSecret:
Gjithashtu në mund të konfiguroni certifikatat dhe shumë të tjera. values.yaml 2. Do të instalojmë chart-in:
helm install . --name mongo-old --namespace mongo-old
Pas kësaj, do të nisët një instalim testues "të vjetër" të MongoDB:kubectl --namespace=mongo-old get pods
Do të hyjmë në pod me masterin e saj dhe do të krijojmë një bazë të dhënash teste: 
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, mësova se masteri ishte 
mongo-old-mongodb-replicaset-0 . Megjithatë, për një zgjidhje më të lehtë të kësaj çështjeje, pas instalimit të Helm-chart-it, shfaqet komanda se si të përcaktohetMASTER_POD . Në rastin tim (përnga 3 nyje) duket kështu: dhe do të vendoset në të njëjtin klaster Kubernetes, ku më vonë do të vendosim dhe të riun ( for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done
Kështu është përgatitur instalimi i vjetër i MongoDB, të dhënat e të cilit do të migrohen.Migrimi i klasterit MongoDB
Tani le të ngremë një instalim të ri të MongoDB, e cila do të ndodhet në Kubernetes dhe do të përdoret nga aplikacioni në prodhim.
: Vë në dukje se duhet të përdoret e njëjta version i MongoDB si më parë. Në të kundërt, ka rrezik të keni probleme kompatibiliteti.
NBNë përputhje me seksionin e mëparshëm (ku simulonim instalimin e "vjetër" të MongoDB), do të marrim Helm-chart-in e përmendur më parë (me komandën
helm fetch ) dhe do të konfigurim autorizimin, si dhe parametrat e tjerë, nëse janë të përdorura. Përveç kësaj, do të korrigjojmë skedarin) и настроим авторизацию, а также другие параметры, если они используются. Кроме того, исправим файл init/on-start.sh, duke përkohësisht duke shtuar në të në rreshtin 165 adresën e masterit, e marrë në hapin e mëparshëm (ose e njohur për ju nga instalimi i MongoDB në servera të veçanta):
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-newPo presim që të fillojnë të gjitha pod-et (nëse të dhënat janë të shumta, fillimi mund të zgjasë për orë të tëra):
Tani bëjmë exec në podin 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ë, i përbërë nga 6 node.
Tani është e mundur të kalojmë 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 heqim rreshtin e shtuar nga ne:
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'Tani shkojmë te masteri i vjetër i klasterit dhe "rrëzojmë" atë — kështu në klaster do të emërohet një master i ri. Hyjmë në pod 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 node-ve dhe ndryshojmë masterin:
cfg = rs.conf()
cfg.members[5].priority = 2
rs.reconfig(cfg)
rs.stepDown(120)Node-i aktual ka ndaluar të jetë master — do të bëhen zgjedhje për një të ri. Duke qenë se ne e kemi ndryshuar prioritetin, node-i që na nevojitet do të bëhet master.
NB: Në mënyrë të parër, të gjithë node-t e MongoDB kanë prioritetin e barabartë me 1. Më lart, ne e rrisim prioritetin në 2 për node-in që na nevojitet. Kështu, një master i zakonshëm me siguri bëhet anëtar i klasterit të ri. Më shumë rreth mënyrave se si funksionojnë këto mekanizma në MongoDB mund të lexoni në .
Do të çaktivizojmë instalimin e vjetër të MongoDB, pas së cilës do të hyjmë te masteri i ri dhe do të eliminojmë node-t e vjetër:
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 kaluam me sukses nga klasteri i vjetër i MongoDB në të ri!
Përfundimet
Schemi e përshkruar është e përshtatshme për pothuajse të gjitha rastet kur është e nevojshme të transferoni MongoDB ose thjesht të zhvendoseni në një klaster të ri.
Ndoshta detaji kryesor gjatë transferit është nevoja për të kaluar IP adresat e pod-eve të reja në serverat e instalimit të vjetër të MongoDB, nëse ajo ndodhet jashtë K8s, dhe emërtimin e saktë në DNS (ose /etc/hosts). Në këtë shembull, këto hapa nuk ishin të nevojshme, pasi migrimi ndodhi midis hapësirave të ndryshme të emërtimeve të të njëjtit klaster Kubernetes.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
