33 पॉइंट द्वारा GN⁺ 2025-06-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक ऐसा ओपन सोर्स प्लेटफ़ॉर्म जो अकेले डेवलपर के लिए भी Kubernetes का इस्तेमाल आसान बनाता है, और मौजूदा Heroku जैसी सरलता देता है
    • Docker और Docker Compose वातावरण में चलता है, और साधारण कमांड से इंस्टॉल व रन किया जा सकता है
  • इसे पुराने startup अनुभवों में सामने आई अनपेक्षित IT लागत वृद्धि की समस्या को हल करने के लिए विकसित किया गया
  • जटिल फीचर्स के बजाय Ingress, Services, Deployments, Pods, CronJobs जैसे केवल मुख्य तत्वों को ही उजागर करके सरलता पर ज़ोर देता है
  • Helm के ज़रिए लगभग सभी ओपन सोर्स ऐप्स डिप्लॉय किए जा सकते हैं, और YAML कॉन्फ़िगरेशन डाउनलोड करके Canine से बाहर निकलना भी संभव है
  • अकाउंट, डिप्लॉयमेंट, डैशबोर्ड जैसी वे सुविधाएँ भी पूरी करता है जो Kubernetes में डिफ़ॉल्ट रूप से नहीं होतीं, इसलिए यह छोटे टीमों के लिए उपयुक्त डेवलपमेंट प्लेटफ़ॉर्म बनने का लक्ष्य रखता है

अवलोकन

  • Canine एक ओपन सोर्स Kubernetes डिप्लॉयमेंट प्लेटफ़ॉर्म है, जिसे Heroku की तरह आसानी से ऐप डिप्लॉय करने के लिए डिज़ाइन किया गया है
  • यह अपने Kubernetes cluster पर चलता है, और ज़रूरत पड़ने पर YAML कॉन्फ़िगरेशन डाउनलोड करके decentralized ऑपरेशन भी संभव बनाता है
  • Ingress, Services, Deployments, Pods, CronJobs जैसे सिर्फ़ मुख्य resources को उजागर करके सरल और सहज उपयोग अनुभव देता है

समस्या की समझ: जटिल संरचना और तेज़ी से बढ़ती लागत

  • पुराने startup संचालन अनुभव में IT लागत उम्मीद से कहीं तेज़ बढ़ी
  • लागत मुख्य रूप से संगठनात्मक जटिलता और जुड़े हुए सेवाओं की संख्या बढ़ने के साथ बढ़ती थी, और कई बार इसका सर्वर या compute उपयोग से सीधा संबंध नहीं था
  • नीचे दिए गए third-party tools के जमा होने से IT लागत में तेज़ उछाल आया:
    • Looker, Redshift, Databricks, DBT Cloud, FiveTran जैसे डेटा टूल
    • Datadog, New Relic, Sentry जैसे monitoring टूल
    • Google Maps API, AWS जैसे infrastructure टूल
  • कुछ को ओपन सोर्स से बदला जा सकता था, लेकिन monitoring, health check, alerting जैसी ऑपरेशनल infrastructure तैयार करने का बोझ होने के कारण अपनाने में हिचक थी

Kubernetes की संभावनाएँ और सीमाएँ

  • Kubernetes एक ऐसा प्लेटफ़ॉर्म है जो single node से लेकर हज़ारों cluster तक scale हो सकता है, और लगभग हर cloud में मानक रूप से उपलब्ध है
  • लेकिन शुरुआती उपयोगकर्ताओं और छोटी टीमों के लिए इसे अक्सर जटिल और आसानी से टूट सकने वाली प्रणाली माना जाता है
  • खासकर CoreDNS delete जैसी गलती से पूरा cluster काम करना बंद कर सकता है
  • जब लागत और ऑपरेशन की जटिलता जमा होती जाती है, तो पहले से abstracted PaaS ही उल्टा बाधा बन सकता है

Canine की विशेषताएँ

  • Kubernetes की केवल न्यूनतम आवश्यक सुविधाएँ उजागर करके सरलता और नियंत्रण क्षमता सुनिश्चित करता है
  • कमी वाले हिस्सों को नीचे की सुविधाओं से पूरा करता है:
    • अकाउंट प्रबंधन
    • डिप्लॉयमेंट प्रबंधन
    • सरल one-off script execution
    • metrics dashboard
  • सहज डिप्लॉयमेंट प्लेटफ़ॉर्म के ज़रिए शुरुआती उपयोगकर्ता भी Kubernetes वातावरण में आसानी से एप्लिकेशन डिप्लॉय कर सकते हैं
  • अगर सिर्फ़ Docker और Docker Compose तैयार हों, तो एक ही कमांड से इंस्टॉल और रन किया जा सकता है
  • Kubernetes की जटिल सेटिंग्स और maintenance का बोझ कम करने वाला UI-आधारित management environment देता है
  • Helm integration के ज़रिए Sentry जैसे ओपन सोर्स ऐप्स भी आसानी से डिप्लॉय किए जा सकते हैं
    • Helm का उपयोग करने पर ज़्यादातर लोकप्रिय ओपन सोर्स ऐप्स कुछ ही लाइनों की कमांड से डिप्लॉय किए जा सकते हैं
    • समर्थित सभी ऐप्स की सूची उपलब्ध है

migration और स्वतंत्रता

  • Canine मौजूदा Kubernetes के ऊपर इस्तेमाल होता है, इसलिए इससे बाहर निकलना भी आसान है
  • सारी कॉन्फ़िगरेशन YAML में डाउनलोड की जा सकती है, इसलिए बाद में किसी दूसरे प्लेटफ़ॉर्म पर माइग्रेट करना भी आसान है

महत्व और अंतर

  • सामान्य Kubernetes टूल्स की तुलना में शुरुआती उपयोगकर्ता के लिए अनुकूल UI और आसान इंस्टॉलेशन प्रक्रिया देता है
  • Kubernetes ecosystem में Heroku जैसा उपयोग अनुभव लाकर entry barrier को काफ़ी कम करता है
  • ओपन सोर्स आधारित होने के कारण लचीली scalability और community-केंद्रित सुधार संभव हैं
  • छोटी डेवलपमेंट टीमों या startups भी आसानी से Kubernetes के फ़ायदे उठा सकें, इस दृष्टि से इसका प्रभाव बड़ा हो सकता है
  • Apache 2.0 License के तहत स्वतंत्र उपयोग, वितरण और संशोधन संभव है

1 टिप्पणियां

 
GN⁺ 2025-06-18
Hacker News टिप्पणियाँ
  • मैं हमेशा अपने सर्वर पर “Heroku जैसा अनुभव” पाने के लिए बेहतर समाधान खोजता रहता हूँ, इसलिए इसे देखकर सच में खुशी हुई।
    Canine का Kubernetes दस्तावेज़ीकरण बहुत सुलभ है, और अब तक देखे गए दस्तावेज़ों में सबसे दोस्ताना लगा।
    दस्तावेज़ पढ़ते समय मेरे मन में सवाल आया: क्या Canine को Digital Ocean जैसी जगहों के managed K8s environment में भी इस्तेमाल किया जा सकता है? लेकिन पढ़ने के बाद लगा कि आपको K8s cluster खुद manage करना होगा।
    कुछ सवाल हैं:

    1. Hetzner में “Cluster” बनाते समय, क्या वह सचमुच कई machines पर फैला हुआ असली K8s cluster है, या सिर्फ एक मशीन का virtual विभाजन?
    2. अगर दूसरी servers पर install script चलाएँ, तो क्या वे cluster में join होकर pods को distribute करते हुए सचमुच distributed server setup बना देंगी?
    3. क्या पहले से मौजूद managed K8s पर Canine को जोड़कर deploy किया जा सकता है?
    • अभी Canine दो configurations सपोर्ट करता है:
      1. एक Hetzner VPS पर चलाना
      2. पहले से बने Kubernetes cluster पर इस्तेमाल करना
        आम तौर पर 1 का उपयोग staging/development apps के लिए, और 2 का production apps के लिए होता है।
        दूसरे मामले में, आप Digital Ocean जैसी जगहों पर node count manage करते हैं, और Kubernetes workloads को अपने-आप reschedule करता है तथा autoscaling का उपयोग किया जा सकता है।
        यही शायद आपके सवाल का मुख्य हिस्सा है: Hetzner environment में Canine खुद multi-node cluster बनाता है, यह सुविधा अभी समर्थित नहीं है।
        Hetzner के terraform से K8s cluster बनाने के विकल्प मौजूद हैं, लेकिन यह अभी Canine में built-in नहीं है।
        UI सुधार आदि के बाद इसमें रुचि है।
        फिलहाल या तो single VPS पर K3s install guide के साथ मदद की जाती है, या फिर यह मानकर चला जाता है कि cluster पहले से तैयार है।
        संदर्भ लिंक: terraform-hcloud-kube-hetzner
  • एक ऐसे व्यक्ति के रूप में जिसे लगता है कि ऐसे प्रोजेक्ट्स की सच में ज़रूरत है, मैं इसे समर्थन देना चाहता हूँ।
    आज अगर चुनना हो तो मैं शायद Canine या Dokploy पर विचार करूँगा (मुझे Docker Swarm भी कम आंका गया tech लगता है)।
    एक feedback: “आपको Canine क्यों नहीं इस्तेमाल करना चाहिए” सेक्शन ईमानदार होने की वजह से ताज़ा लग सकता था, लेकिन उसमें थोड़ा व्यंग्यात्मक लहजा है, जो असहज लगा।
    बेहतर होता अगर बस साफ़-साफ़ लिखा जाता कि आपको server खरीदना और manage करना होगा, downtime होने पर ज़िम्मेदारी आपकी होगी, और यह एक solo developer का शुरुआती-stage product है — यही वास्तविक कमियाँ हैं।

    • मुझे जानना है कि Docker Swarm की maintenance और support की स्थिति अभी क्या है।
      कुछ साल पहले मुझे लगा था कि मौजूदा Docker team ने इसका development रोक दिया है, इसलिए मैंने इसे track करना बंद कर दिया था।

    • इसे दूसरी landing pages से अलग दिखाने की कोशिश में मैंने ऐसा लिखा था, लेकिन वास्तविक उपयोगकर्ता feedback के लिए बहुत आभारी हूँ।
      मैं इसे फिर से सुधारने की कोशिश करूँगा।

  • दुनिया में मौजूद कई PaaS platforms को इकट्ठा करके manage करने वाली एक सूची साझा कर रहा हूँ।
    awesome-paas

    • मैं ऐसे ही lists में project submit करने के लिए देख रहा था, आपकी वजह से अब PR भेजने वाला हूँ।

    • dokku एक minimal PaaS platform है जिसे VPS पर चलाया जा सकता है, और dokku-scheduler-kubernetes भी मौजूद है।
      dokku-scheduler-kubernetes
      हालाँकि, Helm chart समर्थित नहीं है।
      cloud computing architecture की पूरी संरचना और कई तुलना लिंक भी व्यवस्थित किए गए हैं।
      Cloud computing architecture
      Cloud-computing comparison
      Category:Cloud_platforms
      awesome-selfhosted में serverless/FaaS भी है, जो awesome-sysadmin > PaaS की ओर लिंक करता है।
      awesome-selfhosted FaaS/Serverless

  • OP (लेखक) से एक सवाल।
    जानना चाहता हूँ कि आपको यह प्रोजेक्ट बनाने की प्रेरणा कहाँ से मिली।
    मेरे अंदर भी शुरू से अंत तक कुछ जटिल बनाने की इच्छा है, लेकिन मैंने अब तक सिर्फ API और React integration पर काम किया है।
    मैं जानना चाहता हूँ कि आपने एक जटिल विचार को कैसे यथार्थवादी कामों में बाँटा और उसे एक open source “Heroku alternative” प्रोजेक्ट तक पहुँचा दिया।
    मेरा Heroku का अनुभव लगभग नहीं है, इसलिए “क्या implement करना है” समझने के लिए मैं शायद pricing page वगैरह देखता — लेकिन डर है कि यह तरीका अप्रभावी न हो।

  • Kubernetes-आधारित Heroku alternative सुनकर जिज्ञासा हुई।
    लेकिन अगर इसे इस्तेमाल करने के लिए K8s या Helm chart जैसी चीज़ें जाननी हों, तो मेरे लिए यह वास्तव में Heroku alternative नहीं होगा।
    हाँ, मैं समझता हूँ कि operator के नज़रिए से यह echo hello जितना सरल लग सकता है।
    लेकिन जब मैं कुछ बहुत जल्दी deploy करना चाहता हूँ, तब मैं “Kubernetes” और “Helm chart” जैसे शब्दों के बारे में सोचना भी नहीं चाहता।

    • यही तो Canine का लक्ष्य था।
      उपयोगकर्ता को Kubernetes के अस्तित्व के बारे में भी जानने की ज़रूरत नहीं है, लेकिन वह उसके mature ecosystem का लाभ ले सकता है।
      और जब कभी अधिक शक्तिशाली features की ज़रूरत हो, तो Kubernetes API जैसी advanced capabilities को सीधे खोलकर इस्तेमाल करना भी संभव है।
  • एक छोटी-सी बात ध्यान देने लायक है।
    Kubernetes docker containers नहीं चलाता, बल्कि Open Container Initiative(OCI) specification के अनुरूप containers चलाता है।
    Docker एक trademark है।

    • एक और छोटी-सी टिप्पणी:
      Canine Kubernetes Crash Course में “10,000 servers support” बताया गया है,
      लेकिन आधिकारिक रूप से Kubernetes अधिकतम 5,000 nodes तक सपोर्ट होने की बात कहता है।
      Kubernetes आधिकारिक दस्तावेज़ देखें
      इससे कहीं बड़े clusters भी संभव हैं, लेकिन तब काफी भारी customization चाहिए होता है (जैसे पूरा API registry बदलना)।
      बेशक workload भी असर डालता है।
      Kubernetes अभी out-of-the-box बहुत बड़े clusters के लिए पूरी तरह तैयार नहीं है, लेकिन हर release के साथ बेहतर हो रहा है।

    • अगर docker ज़रूरी कहा जाए तो मुझे पसंद नहीं आता।
      आजकल मैं docker की जगह podman या containerd के साथ ज़्यादा काम करता हूँ।

  • यह प्रोजेक्ट बनाना बहुत मज़ेदार था, और मेरी ज़िंदगी का सबसे आनंददायक development अनुभव रहा।
    पूरे “tech stack” को एक हाथ में होने का एहसास शानदार है।
    Rails app, Canine infra, Raspberry pi server, यहाँ तक कि मेरा ISP भी।
    सब कुछ खुद manage करते हुए app deploy करने का अनुभव साझा कर रहा हूँ।

  • वेबसाइट पर license को 2024 MIT License बताया गया है,
    जबकि actual github पर apache license लिखा है।
    यहाँ साल सही है या नहीं, उससे ज़्यादा license का प्रकार महत्वपूर्ण अंतर लगता है।
    असल में लागू license कौन-सा है, यह जानना चाहता हूँ।

  • Self-hosting में मुझे docker और K8s के बीच का कोई मध्यवर्ती चरण चाहिए था, इसलिए मैंने कुछ मिलता-जुलता खुद भी खोजा था।
    Nomad पर भी विचार किया, लेकिन वह अभी भी dead simple docker से थोड़ा ज़्यादा जटिल लगा, और ecosystem भी उतना मज़बूत नहीं था।
    अंत में home server सिर्फ docker पर चलाया, और deploy के दौरान downtime स्वीकार कर लिया।
    production में Canine K8s को कितनी हद तक abstract करता है, यह जानना चाहता हूँ।
    क्या कभी अंदर तक झाँकने की ज़रूरत पड़ेगी? मैं K8s में नया हूँ, इसलिए सोचता हूँ कि क्या यह मध्य रास्ता सच में संभव है।

    • मैं भी Docker और Kubernetes के बीच की जगह वाला एक tool बना रहा हूँ।
      uncloud
      लक्ष्य है Docker-जैसा CLI और Docker Compose की multi-machine/production capabilities देना, लेकिन बिना operational control plane के चीज़ों को सरल बनाए रखना।
      अभी development में है, लेकिन लक्ष्य यह है कि हर layer पर क्या हो रहा है यह आसानी से समझ आए, और troubleshooting भी आसान हो।
  • यह concept सच में बहुत पसंद आया।
    K8s शानदार tech है, लेकिन उसकी complexity ही entry barrier है।
    सार्वजनिक सामग्री देखकर लगा कि आपने इसकी मूल प्रकृति को अच्छी तरह समझा है।
    खासकर self-hosting क्षेत्र में, जहाँ PVE, Microcloud, Cockpit जैसी solutions लोकप्रिय हैं, यह और भी उपयोगी लगती है।
    मेरे घर में एक खाली पड़ा N100 NUC है; अब Microcloud छोड़कर Canine टेस्ट करने का मन हो रहा है।

    • helm कभी-कभी झंझट वाला होता है।
      values.yaml बदलने के बाद कौन-सी values apply होती हैं और कौन-सी शुरू से set करनी पड़ती हैं, इसमें भ्रम होता है।
      कुछ helm installs में services इतनी ज़्यादा होती हैं कि समझना मुश्किल हो जाता है कि क्या और कब restart किया जा सकता है।
      दूसरी ओर, core kubernetes stateless jobs के लिए सच में बहुत सुखद अनुभव देता है।

    • आजकल K8s की “complexity” वाली बात कहाँ से आती है, यह मुझे समझ नहीं आता।
      पहले kubespray के साथ दो घंटे setup करने जैसी बातें होती थीं,
      लेकिन अब rke जैसे tools से सिर्फ एक yaml file और एक ssh key के साथ भी cluster बनाया जा सकता है।