Bitta VPS’da prodakshnda Docker Compose: qanday to‘g‘ri qilish kerak

Compose’ni prodakshnda ishlatsa bo‘ladimi

Ha. Kichik va o‘rta loyihalar uchun Docker Compose’li bitta VPS — oddiy va ishonchli variant: butun infratuzilma bitta faylda tasvirlangan, uni qayta yaratish va ko‘chirish oson. Asosiysi — «noutbukdagidek» ishga tushirmaslik, balki bir nechta majburiy bandni bajarish.

Qayta ishga tushirish siyosati

Busiz konteyner qulagandan yoki server qayta yuklangandan keyin ko‘tarilmaydi.

services:
  app:
    image: registry.example.com/app:1.4.2
    restart: unless-stopped

• unless-stopped — konteynerni qo‘lda to‘xtatmagan bo‘lsangiz, doim qayta ishga tushiradi. Standart sifatida yaxshi tanlov.
• always — Docker qayta ishga tushganda qo‘lda to‘xtatilganlarni ham ko‘taradi.
• on-failure — faqat noldan farqli chiqish kodida.

Docker’ning o‘zi ham yuklanishda ishga tushishini tekshiring: systemctl enable docker.

Maxfiy ma’lumotlar va env-fayllar

Parollarni docker-compose.ymlda va Git’da saqlamang. Ularni .env yoki alohida faylga chiqaring:

services:
  app:
    env_file: .env.production

Maxfiy ma’lumotlar fayliga 600 huquqlari beriladi va u .gitignorega qo‘shiladi. Repozitoriyda bo‘sh qiymatli .env.example saqlang, shunda qaysi o‘zgaruvchilar kerakligi ko‘rinib turadi.

Healthcheck

restart faqat jarayon qulashiga javob beradi. Agar ilova osilib qolgan, lekin jarayon tirik bo‘lsa, healthcheck yordam beradi:

services:
  app:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
  worker:
    depends_on:
      db:
        condition: service_healthy

E’tibor bering: Swarm’siz oddiy Docker’da unhealthy holatining o‘zi konteynerni qayta ishga tushirmaydi. U depends_on, monitoring va o‘z skriptlaringiz uchun kerak. Obrazda curl bo‘lishi lozim — yoki boshqa tekshiruvdan foydalaning.

Loglar rotatsiyasi

Standart bo‘yicha json-file drayveri loglarni cheklovsiz yozadi va bir kun disk to‘lib qoladi. Limit qo‘ying:

x-logging: &logging
  driver: json-file
  options:
    max-size: "10m"
    max-file: "5"

services:
  app:
    logging: *logging

Xuddi shuni /etc/docker/daemon.jsonda global ham belgilash mumkin, lekin bu faqat yangi konteynerlarga tatbiq etiladi.

Reverse proxy va HTTPS

Ilova portini tashqariga ochmang. Tashqariga faqat reverse proxy’ning 80 va 443 portlari qaraydi, ilova esa faqat Compose’ning ichki tarmog‘ida mavjud.

Variantlar:

Agar baribir debag uchun port kerak bo‘lsa, uni localhost’ga bog‘lang: "127.0.0.1:3000:3000". Docker o‘zining iptables qoidalarini yozishini va ochilgan port UFW’ni chetlab o‘tishi mumkinligini unutmang.

Uzoq to‘xtashsiz yangilash

latest emas, aniq tegli obrazlardan foydalaning — shunda nima ishlayotgani tushunarli va orqaga qaytish oson.

Yangilash tartibi:

docker compose pull app
docker compose up -d app
docker image prune -f

Avval eski konteyner ishlab turganda yangi obraz yuklab olinadi, keyin konteyner qayta yaratiladi — to‘xtash ilovaning ishga tushish vaqtiga qisqaradi. Agar bu ham muhim bo‘lsa, proksi ortida ikkita nusxa ishga tushiring va ularni navbat bilan yangilang. Ma’lumotlar bazasi migratsiyalarini orqaga mos qiling, shunda kodning eski va yangi versiyalari bitta sxema bilan ishlay oladi.

Tomlarning zaxira nusxalari

Ma’lumotlar volume’larda saqlanadi va ular disk yoki server ishdan chiqsa, saqlanib qolmaydi.

• Ma’lumotlar bazasini ishlab turgan BD fayllarini nusxalash orqali emas, standart vositalar (pg_dump, mysqldump) bilan zaxiralang.
• Tomlardagi fayllarni arxivlang va server tashqarisiga — obyekt omboriga yoki boshqa mashinaga yuboring.
• Zaxiralashni jadval bo‘yicha (cron yoki systemd timer) ishga tushiring va xatolarni kuzating.
• Vaqti-vaqti bilan toza serverda tiklashni tekshiring: tekshirilmagan zaxira — bu zaxira emas, umid.

Bitta server qachon yetmay qoladi

Bir nechta server yoki orkestrator haqida o‘ylash vaqti keldi, agar:

• texnik xizmat yoki uskuna nosozligida to‘xtash qabul qilib bo‘lmaydigan bo‘lsa;
• yuklamani VPS’ni vertikal kattalashtirish bilan ko‘tarib bo‘lmasa;
• alohida servislarni mustaqil masshtablash kerak bo‘lsa;
• jamoa o‘zgarishlarni tez-tez chiqarsa va kanareyka relizlari kerak bo‘lsa.

Oraliq qadam — ma’lumotlar bazasini boshqariladigan servisga chiqarish, ilovani esa balanslovchi ortidagi ikkita serverda ishga tushirish.