Ma’lumotlar bazasini Docker va Kubernetes’da ishga tushirish kerakmi

Qisqacha javob

Ishlab chiqish va testlar uchun — ha: Docker’dagi baza soniyalar ichida hammaga bir xil versiyani beradi. Production uchun savol «konteynerlar baza ishga tushira oladimi» emas (oladi), balki «tungi soat uchda saqlash, bekaplar, failover va yangilanishlar bilan kim shug‘ullanadi» degani.

• Alohida DevOps muhandislari yo‘q: bulut provayderidan managed baza oling.
• Allaqachon Kubernetes’da ishlaysiz va uni yaxshi bilasiz: CloudNativePG kabi yetuk operator — oqilona tanlov.
• Oraliq variant: alohida virtual mashinadagi baza, ehtimol Docker’da, avtomatik va tekshirilgan bekaplar bilan.

Haqiqatan nima muhim

Saqlash tezligi. Bazalar disk kechikishlariga sezgir. Tarmoq tomlari qulay, lekin lokal NVMe disklardan sekinroq. Lokal tomlar tez, ammo pod’ni bitta node’ga bog‘laydi: node ishdan chiqsa, tiklash diskni qayta ulashga emas, replikatsiyaga bog‘liq bo‘ladi. Aniq storage class’ni o‘z yuklamangizda sinab ko‘ring.

Saqlanish. Ma’lumotlar konteynerning yoziladigan qatlamida emas, tomda turishi kerak. Kubernetes’da StatefulSet yoki PersistentVolumeClaim’li operatordan foydalaning va reclaim policy’ni claim o‘chirilganda ma’lumotlar jimgina o‘chib ketmaydigan qilib sozlang.

Bekaplar. Ham muntazam to‘liq nusxalar, ham point-in-time recovery uchun tranzaksiya jurnallarini uzluksiz arxivlash kerak, ular klasterdan tashqarida, masalan, obyekt omborida saqlanishi lozim. Hech qachon tiklanmagan bekap — bu bekap emas, umid: test tiklashlarni rejalashtiring.

Failover. Bazali bitta pod — yagona nosozlik nuqtasi. Yuqori mavjudlik uchun replikalar, liderni avtomatik tanlash va yangi primary’ga qayta ulanadigan mijozlar kerak. Bu o‘zingiz qurish uchun eng qiyin qism va operatorlar mavjudligining asosiy sababi.

Operator yetukligi. Operator DBA bilimlarini kodga aylantiradi: replikatsiya, failover, bekaplar, kichik yangilanishlar. PostgreSQL uchun bir nechta o‘rnashgan variant bor, jumladan CloudNativePG, Zalando’ning postgres-operator’i va Crunchy PGO; Percona MySQL, PostgreSQL va MongoDB uchun operatorlarni qo‘llab-quvvatlaydi. Loyiha faolligi, hujjatlar, yangilash va tiklash qanday ishlashi hamda jamoada kimdir uni production’da ishlatganmi — shularga qarang.

Resurslar. Memory requests va limits’ni ehtiyotkorlik bilan bering: konteyner xotira limitidan oshsa, u o‘ldiriladi, baza uchun bu esa qulash va tiklanish demak. Bazalarni shovqinli yuklamalar yoniga joylashtirmang.

Managed va self-hosted

Odamlar vaqti — eng ko‘p unutiladigan xarajat moddasi. Hisobda tejaydigan, lekin doimiy e’tibor talab qiladigan self-hosted klaster kamdan-kam arzonroq bo‘lib chiqadi.

Tanlash sxemasi

Jamoa hajmi bo‘yicha:

• DevOps’siz 1–5 dasturchi: managed baza. Docker Compose — faqat lokal ishlab chiqish va CI uchun.
• Bir-ikki DevOps muhandisi bor jamoa: standart holatda managed baza; self-hosted — muhim bo‘lmagan va ichki tizimlar uchun yoki ma’lumotlar ma’lum uskunada yoki ma’lum mamlakatda qolishi kerak bo‘lganda.
• Ko‘p servisli platforma jamoasi: Kubernetes’dagi operator o‘nlab bazalarni standartlashtirish imkonini beradi — runbook, monitoring va muntazam tiklash mashqlari bilan.

Yuklama bo‘yicha:

• Kechikishga sezgir, yozuvlari ko‘p OLTP: tez lokal saqlashli ajratilgan node’lar yoki kafolatlangan IOPS’li managed servis.
• Preview muhitlar, testlar, vaqtinchalik stendlar: Kubernetes’dagi baza ideal, ma’lumotlarga achinmaysiz.
• Keshlar va navbatlar (Redis va shunga o‘xshashlar): konteynerlarda ishga tushirish osonroq, ayniqsa ma’lumotlarni qayta tiklash mumkin bo‘lsa.
• Katta analitik yuklamalar: odatda ixtisoslashgan servislar yoki ajratilgan mashinalarda turadi.

Ko‘p uchraydigan xatolar

• Ma’lumotlar tomda emas, konteyner ichida saqlanadi.
• Serverda docker compose down -v nomlangan tomlarni ma’lumotlar bilan birga o‘chiradi.
• StatefulSet yoki operator o‘rniga bitta replikali Deployment.
• Bekaplar baza bilan bir klasterda yoki bir diskda turadi.
• Baza portlari internetga ochiq.