बजट VPS पर Docker चलाना

छोटे VPS पर Docker आख़िर क्यों

Docker के पक्ष में दलील का मशीन के आकार से कोई लेना-देना नहीं है। रीप्रोड्यूसिबल डिप्लॉय का मतलब है कि जो इमेज आपने टेस्ट की, ठीक वही बाइट-दर-बाइट प्रोडक्शन में चलती है; रोलबैक बस पिछला टैग शुरू करने जितना है; और जो कंटेनर आपके लैपटॉप पर चलता है, वही प्रोडक्शन में भी बिल्कुल वैसा ही चलता है।

छोटे VPS पर ये खूबियाँ और भी ज़्यादा मायने रखती हैं, कम नहीं। जब संसाधन तंग हों तो आप कोई रहस्य अफ़ोर्ड नहीं कर सकते — 'मेरी मशीन पर तो चलता है' वाली डिबगिंग ठीक वही समय और मेमोरी खाती है जो आपके पास है ही नहीं। एक इमेज, हर जगह — और समस्याओं की यह पूरी श्रेणी खत्म।

मेमोरी ही असली बजट है

बजट VPS पर सबसे पहले खत्म होने वाला संसाधन RAM है, और जब तक आप रोकेंगे नहीं, Docker खुशी-खुशी एक कंटेनर को बाकी सबकी मेमोरी खाने देगा। हर कंटेनर पर साफ़ मेमोरी लिमिट लगाएँ, ताकि कोई लीक पूरे जमे हुए सर्वर की जगह सिर्फ़ एक रीस्टार्ट हुई सर्विस बनकर रह जाए।

सेफ़्टी नेट के तौर पर थोड़ा-सा स्वैप जोड़ें — उस पर चलने के लिए नहीं, बल्कि छोटे उछाल झेलने के लिए, ताकि कर्नेल बेतरतीब प्रोसेस न मारने लगे। और slim या alpine इमेज चुनें: छोटी बेस इमेज यानी कम मेमोरी, तेज़ पुल और छोटी अटैक सरफ़ेस।

• हर कंटेनर पर --memory लिमिट सेट करें
• हल्की (slim) बेस इमेज इस्तेमाल करें
• हर कंटेनर में एक ही प्रोसेस रखें

पूरे स्टैक के लिए Compose

आपके ऐप और उसके रिवर्स प्रॉक्सी को बताने वाली एक docker-compose.yml पूरे स्टैक को एक ऐसी फ़ाइल बना देती है जिसे आप पढ़ सकते हैं, वर्ज़न कर सकते हैं और दोबारा खड़ा कर सकते हैं। सर्वर को शून्य से वापस लाना आधे-याद रस्म-रिवाज की जगह एक कमांड का काम बन जाता है।

फ़ाइल को उबाऊ और स्पष्ट रखें: पिन किए हुए इमेज टैग, रीस्टार्ट पॉलिसी, मेमोरी लिमिट। सर्वर पर जो कुछ भी चलता है, वह इसी एक फ़ाइल में दिखना चाहिए — जो Compose में नहीं है, वह है ही नहीं।

services:
  app:
    image: ghcr.io/you/app:latest
    restart: unless-stopped
    mem_limit: 512m

डेटाबेस को कंटेनर से बाहर रखें

छोटी मशीन पर Docker के अंदर PostgreSQL या MySQL चलाना वह जगह है जहाँ बजट सेटअप दम तोड़ते हैं। डेटाबेस को स्थिर मेमोरी, सधा हुआ स्टोरेज और असली बैकअप चाहिए — ठीक वही चीज़ें जिनका वादा RAM के लिए लड़ते कंटेनरों वाला छोटा VPS नहीं कर सकता। किसी राइट के बीच एक OOM किल हुई, और आप उम्मीद के भरोसे रिस्टोर कर रहे हैं।

इसकी जगह मैनेज्ड डेटाबेस इस्तेमाल करें और VPS को वही करने दें जिसमें वह अच्छा है: आपका स्टेटलेस ऐप चलाना। स्टेट की जगह कहीं और है — Anested Cloud पर मैनेज्ड PostgreSQL, MySQL और MongoDB फ्री टियर से शुरू होते हैं, और आपके कंटेनरों को बस एक कनेक्शन स्ट्रिंग मिलती है।

बिना डाउनटाइम के ड्रामे वाले अपडेट

अपडेट का रूटीन छोटा है: नई इमेज पुल करें, सर्विस रीस्टार्ट करें, और आगे बढ़ने से पहले हेल्थ चेक से पक्का कर लें कि नया कंटेनर सच में जवाब दे रहा है। अगर नहीं देता, तो पिछला टैग रीस्टार्ट करना ही आपका रोलबैक है — सेकंडों का काम, पूरी शाम का नहीं।

बड़े बदलावों से पहले — नए मेजर वर्ज़न, Compose फ़ाइल का पुनर्लेखन — पहले VPS का स्नैपशॉट लें। यह सबसे सस्ता बीमा है: अपग्रेड बिगड़ जाए तो आप पूरी मशीन को छूने से ठीक पहले वाले पल पर वापस ले आते हैं।