3 पॉइंट द्वारा GN⁺ 2024-11-15 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 टिप्पणियां

 
luminance 2024-11-15

tealok में जाकर देखा तो यह अभी ऐसा नहीं लगता कि कोई व्यवहार्य विकल्प बन सके।

 
savvykang 2024-11-15

काश, इसमें runtime को भी हटा दिया गया होता।

 
tujuc 2024-11-15

मुझे अब भी लगता है कि docker-compose का इस्तेमाल करके production जैसी स्थिति बनाकर उसमें जाना ज़रूरी है, लेकिन...

अपने ही किसी खास environment के अनुभव के आधार पर यह कहना कि वह गलत है, इसलिए हमने कुछ नया बना दिया... इससे सहमत होना मुश्किल है.. हाहाहा

यह थोड़ा गलतफहमी पैदा कर सकने वाली बात है हाहाहा...

मैंने तो सिर्फ़ शीर्षक देखकर ही सोचा था, 'अरे, development environment में इस्तेमाल होने वाली चीज़ वाकई ज़्यादा पसंद नहीं आती....' हाहाहा

 
ilbanin00 2024-11-15

मुझे लगता है कि docker compose को लेख में बताए गए जैसे उद्देश्य के लिए इस्तेमाल करने की कोशिश करना शुरू से ही गलत तरीका है।

 
tujuc 2024-11-15

मैं आपकी बात से कुछ हद तक सहमत हूँ, लेकिन मुझे नहीं लगता कि उनका approach गलत था.
उनके लिए जो environment संभव था, उसमें शायद वही सबसे अच्छा विकल्प रहा होगा :)

 
GN⁺ 2024-11-15
Hacker News राय
  • पोर्ट mapping और data volume backup की समस्या के लिए सरल समाधान मौजूद हैं

    • development environment के लिए अलग docker-compose फ़ाइल इस्तेमाल करके environment के हिसाब से अलग configuration परिभाषित की जा सकती है
    • backup के लिए एक सरल Bash script लिखकर उसे S3 पर upload किया जा सकता है
  • निजी सर्वर पर Docker का उपयोग करके self-hosting करने वाले व्यक्ति के रूप में, Docker configuration की लचीलापन को सकारात्मक रूप से देखा गया

    • शुरुआती setup में समय लगा, लेकिन उसके बाद इसे आसानी से manage किया जा सका
    • नई service जोड़ने में लगभग समय नहीं लगता, और security के लिए हर service के लिए non-root user बनाया जाता है
    • macvlan network का उपयोग करके हर container को एक unique IP और MAC address दिया जाता है
    • Nginx Proxy Manager का उपयोग करके reverse proxy manage किया जाता है, और database के रूप में कई instances चलाने पर भी कोई समस्या नहीं होती
  • docker-compose का उपयोग मुख्य रूप से development या निजी उपयोग के लिए होता है, और V2, V1 से अलग Docker में integrated plugin है

  • production environment में Kubernetes का उपयोग करना बेहतर है, जबकि docker-compose local development के लिए उपयुक्त है

  • docker-compose छोटे पैमाने की self-hosting के लिए बना एक product है, जिसका लक्ष्य वे लोग हैं जिनकी technical background नहीं है

    • TOML में बदलने से self-hosting आसान हो जाएगी, इस पर संदेह है
  • Docker को control करने वाला program लिखना सोच से अधिक सरल है, और Python script का उपयोग करके समस्याएँ हल की जा सकती हैं

  • canine.sh का उपयोग करके Kubernetes cluster को Heroku जितना आसान बनाने पर काम चल रहा है

    • इसे निजी projects में इस्तेमाल किया जा रहा है, और कम लागत में कई apps host किए जा सकते हैं
  • Tealok द्वारा docker-compose के एक alternative पर काम किया जाना दिलचस्प है

  • ऐसा माना जाता है कि docker-compose, Kubernetes, और Helm abstraction layer के रूप में गलत हैं

    • container execution और communication के अलग-अलग तरीकों को विकसित करने के कई प्रयास हो रहे हैं
  • इस दावे पर उलझन महसूस होती है कि docker-compose abstraction layer के रूप में गलत है

    • लगता है कि किसी खास समस्या को हल करने के लिए एक high-level interface की अपेक्षा की जा रही है
    • duplicate instances बनने की समस्या अधिकांश applications में कोई बड़ी समस्या नहीं है
    • applications को किसी खास तरीके से design करने के लिए मजबूर करना केवल कुछ विशेष परिस्थितियों में ही अच्छा काम करेगा