docker-compose Docker containers को संभालने का एक टूल है, जो जटिल application deployment समस्याओं को हल करता है, लेकिन आम उपयोगकर्ताओं के लिए आसान self-hosting के लिए काफ़ी नहीं है
- SQL database, local cache, durable storage, service discovery, और resource management जैसी अवधारणाओं को शामिल करने वाले higher-level abstraction की ज़रूरत है
Docker की भूमिका
- Docker एक ऐसा टूल है जिसने containerization को लोकप्रिय बनाया, और host system की तुलना एक जहाज़ से की जा सकती है.
- इसमें hardware, operating system, और container runtime होते हैं, और containers runtime के भीतर चलते हैं तथा database या web server जैसी अन्य services से communicate करते हैं.
Docker-compose की भूमिका
docker-compose साथ काम करने वाले containers के समूह को परिभाषित करने का टूल है, जो self-hosted applications की deployment को आसान बनाता है.
- लेकिन यह standardized interface को तोड़ देता है और उन समस्याओं को फिर से पैदा करता है जिन्हें containers मूल रूप से हल करने के लिए बनाए गए थे.
- उदाहरण: Pihole
- Pihole एक DNS server है, जिसके लिए जटिल
docker-compose file की आवश्यकता होती है.
- इसमें container name, image, port, environment variables, volume, अतिरिक्त सुविधाएँ, restart policy आदि को configure करना पड़ता है.
- इस तरह की जटिल configuration उपयोगकर्ता को खुद संभालनी पड़ती है, और यही Docker Compose की कमी है
- उदाहरण: Jitsi Meet
- Jitsi Meet एक जटिल software है, जो 4 containers, 7 volumes, 9 ports, और 200 से अधिक environment settings वाली
docker-compose configuration बनाता है.
- उदाहरण: अन्य लोकप्रिय self-hosted applications में भी ऐसी ही समस्याएँ हैं
- Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX जैसी कई applications हैं, और हर एक की
docker-compose configuration दर्जनों से लेकर सैकड़ों docker commands की जगह लेती है.
- हर application अपना अलग database, cache, और HTTP handler शामिल कर सकती है, जिससे resources का दोहराव और बर्बादी होती है.
समस्याएँ
docker-compose बहुत ज़्यादा flexible और low-level है, और abstraction की गलत layer पर काम करता है.
- हर application के पास अपना HTTP processing process, cache, या database होता है. Database backup की ज़िम्मेदारी system operator पर होती है.
- उदाहरण: Reverse HTTP proxy
- Reverse HTTP proxy एक ऐसा program है जो आने वाले HTTP requests को दूसरे program तक पहुँचाता है. हर program को तय करना पड़ता है कि उसमें web server शामिल हो या नहीं.
- web server शामिल होने पर
- web server शामिल करने पर program काम करेगा, लेकिन वह केवल किसी विशेष port पर ही चलेगा, और कई containers होने पर ports को remap करना पड़ेगा.
- web server शामिल न होने पर
- web server शामिल न करने पर resources की बर्बादी नहीं होती, लेकिन management interface के बिना application को configure करना पड़ता है.
- DNS
- web interface का एक address होता है, और अगर TLS चाहिए तो एक नाम भी चाहिए. अगर एक ही host पर कई services चल रही हों, तो requests को domain name या path के आधार पर route करना पड़ता है.
- ports
docker-compose ports को expose और remap करने देता है, लेकिन व्यवहार में जटिल networking configuration को support करना पड़ता है.
- उदाहरण: database
- जब container delete होता है, तो database में files के सभी बदलाव भी हट जाते हैं. Database container को database content सुरक्षित रखने के लिए volume जोड़ना पड़ता है.
- N+1=2 या उससे अधिक
- database backup के लिए offsite backup चाहिए. अगर हर service अपना अलग database server process bundle करे, तो computing resources की बर्बादी होती है.
समाधान
- abstraction की एक higher layer पर जाकर semantics जोड़ी जानी चाहिए, जो database, reverse web proxy, cache, static web assets जैसी container types के बीच अंतर कर सके.
- semantics का उदाहरण
- एक नया configuration format लाया जाए, जिसमें application name, build, HTTPS reverse proxy, और cache service निर्दिष्ट की जा सके.
- समाधान #1
- हर program reverse proxy का अनुरोध करे, जिससे duplication और waste रोका जा सके. Reverse proxy DNS name दे और सभी paths को program तक forward करे.
- समाधान #1.5
- एक database section जोड़ा जाए, जिससे SQL standard का पालन करने वाले database का अनुरोध किया जा सके, और program "full" permissions की अपेक्षा करे.
- ports के लिए समाधान
- हर program को अपना अलग IPv6 address मिले ताकि वह standard port numbers का उपयोग कर सके. Security के लिए firewall का उपयोग करके केवल reverse proxy को ही ports तक पहुँच दी जाए.
Tealok - एक नया container runtime
- Tealok एक नया container runtime है, जो higher-level abstraction और standardized interface प्रदान करता है.
- यह TLS certificates, reverse proxy setup, DNS records, backup management आदि को अपने-आप संभालता है.
- यह IPv6 का उपयोग करता है ताकि हर container का अपना स्वतंत्र IP address हो और वह standard port numbers का उपयोग कर सके.
- application developers बिना जटिल configuration के standard interface के माध्यम से applications deploy कर सकते हैं.
- operators के लिए यह consistent best practices, कम resource waste, और कम management burden प्रदान करता है.
- developers के लिए यह deployment को सरल बनाता है और निर्णय लेने का बोझ घटाता है.
- उपयोगकर्ताओं को data ownership और cloud computing से स्वतंत्रता सुनिश्चित हो सकती है.
6 टिप्पणियां
tealok में जाकर देखा तो यह अभी ऐसा नहीं लगता कि कोई व्यवहार्य विकल्प बन सके।
काश, इसमें runtime को भी हटा दिया गया होता।
मुझे अब भी लगता है कि
docker-composeका इस्तेमाल करके production जैसी स्थिति बनाकर उसमें जाना ज़रूरी है, लेकिन...अपने ही किसी खास environment के अनुभव के आधार पर यह कहना कि वह गलत है, इसलिए हमने कुछ नया बना दिया... इससे सहमत होना मुश्किल है.. हाहाहा
यह थोड़ा गलतफहमी पैदा कर सकने वाली बात है हाहाहा...
मैंने तो सिर्फ़ शीर्षक देखकर ही सोचा था, 'अरे, development environment में इस्तेमाल होने वाली चीज़ वाकई ज़्यादा पसंद नहीं आती....' हाहाहा
मुझे लगता है कि
docker composeको लेख में बताए गए जैसे उद्देश्य के लिए इस्तेमाल करने की कोशिश करना शुरू से ही गलत तरीका है।मैं आपकी बात से कुछ हद तक सहमत हूँ, लेकिन मुझे नहीं लगता कि उनका approach गलत था.
उनके लिए जो environment संभव था, उसमें शायद वही सबसे अच्छा विकल्प रहा होगा :)
Hacker News राय
पोर्ट mapping और data volume backup की समस्या के लिए सरल समाधान मौजूद हैं
docker-composeफ़ाइल इस्तेमाल करके environment के हिसाब से अलग configuration परिभाषित की जा सकती हैनिजी सर्वर पर Docker का उपयोग करके self-hosting करने वाले व्यक्ति के रूप में, Docker configuration की लचीलापन को सकारात्मक रूप से देखा गया
macvlannetwork का उपयोग करके हर container को एक unique IP और MAC address दिया जाता हैdocker-composeका उपयोग मुख्य रूप से development या निजी उपयोग के लिए होता है, और V2, V1 से अलग Docker में integrated plugin हैproduction environment में Kubernetes का उपयोग करना बेहतर है, जबकि
docker-composelocal development के लिए उपयुक्त हैdocker-composeछोटे पैमाने की self-hosting के लिए बना एक product है, जिसका लक्ष्य वे लोग हैं जिनकी technical background नहीं हैDocker को control करने वाला program लिखना सोच से अधिक सरल है, और Python script का उपयोग करके समस्याएँ हल की जा सकती हैं
canine.shका उपयोग करके Kubernetes cluster को Heroku जितना आसान बनाने पर काम चल रहा हैTealok द्वारा
docker-composeके एक alternative पर काम किया जाना दिलचस्प हैऐसा माना जाता है कि
docker-compose, Kubernetes, और Helm abstraction layer के रूप में गलत हैंइस दावे पर उलझन महसूस होती है कि
docker-composeabstraction layer के रूप में गलत है