कंटेनर के बिना भी ध्यान देने लायक Traefik रिवर्स प्रॉक्सी और लोड बैलेंसर

 (j6b72.de)
3 पॉइंट द्वारा GN⁺ 2024-05-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Traefik कंटेनर environment में लोकप्रिय है, लेकिन इसे single Go executable के रूप में deploy किया जा सकता है, इसलिए container engine के बिना भी इसे reverse proxy के तौर पर चलाया जा सकता है
  • यह nginx/caddy/apache2 जैसी file को सीधे serve करने वाली श्रृंखला के बजाय HAProxy के करीब proxy है, और request forwarding, response return और header adjustment पर केंद्रित है
  • Docker label इस्तेमाल न करने पर भी इसे configuration file provider से configure किया जा सकता है, और static configuration व dynamic configuration को अलग करके router, service और middleware manage किए जाते हैं
  • TLS Passthrough और HAProxy के PROXY protocol input/output को support करता है, लेकिन PROXY protocol को target service का भी support करना जरूरी है; apache2 और nginx इसे support करते हैं
  • authentication integration और user agent/IP blocking के लिए सिर्फ built-in features पर्याप्त नहीं हो सकते, इसलिए ForwardAuth, oauth2-proxy और third-party plugins के management burden को भी साथ में आंकना चाहिए

कंटेनर के बाहर भी इस्तेमाल हो सकने वाला Traefik

  • Traefik पिछले कुछ वर्षों में home-lab YouTube space में लोकप्रिय हुआ है, और इसे मुख्य रूप से Docker या Kubernetes जैसी container infrastructure के साथ पेश किया जाता है
  • feature nature के लिहाज से यह nginx/caddy/apache2 की तुलना में HAProxy के अधिक करीब है
    • requests को services तक forward करता है और responses लौटाता है
    • headers और request/response के कुछ हिस्सों को modify कर सकता है
    • file serving support नहीं करता
  • container environment में Traefik को भी container के रूप में run करके Docker socket mount किया जा सकता है, जिससे यह दूसरे containers को automatically detect कर सकता है
    • proxy behavior को container के Docker labels से configure किया जा सकता है
    • नया container detect होने पर Let’s Encrypt TLS certificate automatically request करके service को expose किया जा सकता है

single binary और systemd deployment

  • Traefik Go में लिखा गया है और single executable file के रूप में compile होता है
  • binary distribution Traefik installation docs से मिल सकता है
  • container engine के बिना Traefik खुद और target services, दोनों को run किया जा सकता है
  • systemd service unit का example Traefik repository में है
  • real operations में configuration files के अलावा अलग user बनाना और configuration file permissions set करना भी जरूरी होता है

configuration file आधारित setup

  • container इस्तेमाल न करने पर Docker labels use नहीं किए जा सकते, लेकिन Traefik को file provider से configure किया जा सकता है
  • configuration मोटे तौर पर दो हिस्सों में बंटती है
    • static configuration: Let’s Encrypt जैसे certificate providers और Traefik जिस port पर listen करता है, वे entrypoints रखती है
    • dynamic configuration: routers, services और middlewares रखती है
  • Traefik filesystem events detect करके dynamic configuration को hot reload कर सकता है
  • documentation core concepts और configuration examples हर तरीके के अनुसार देती है
  • certificate provider, entrypoint, router, service, middleware जैसे terms Traefik documentation में जल्दी देखे जा सकते हैं

configuration के बाद behavior और debugging

  • configuration सही न होने पर Traefik warnings दिखाता है
  • default logs बहुत ज्यादा नहीं होते, लेकिन request किस path से गुजर रही है, यह समझना आसान होता है
  • एक user experience के मुताबिक initial configuration जल्दी खत्म हो गई और कोई arbitrary समस्या नहीं आई

TLS Passthrough और PROXY protocol

  • Traefik TLS Passthrough support करता है
    • proxy पर TLS terminate किए बिना, अपने TLS certificate देने वाली web service तक traffic forward किया जा सकता है
    • ऐसी configuration भी संभव है जिसमें service Traefik से होकर Let’s Encrypt certificate सीधे request करे
    • proxy forwarded content को देख नहीं सकता
  • सामान्य virtual host selection HTTP Host header से होता है, लेकिन TLS Passthrough में यह header encrypted body के अंदर होता है, इसलिए इसे इस्तेमाल नहीं किया जा सकता
  • target host चुनने के लिए TLS का SNI(Server Name Indication) इस्तेमाल होता है, और Traefik तथा कई web servers/proxies इसी तरीके का उपयोग करते हैं
  • HAProxy का PROXY protocol भी input/output support करता है
    • यह वह तरीका है जिससे user के पहले proxy तक पहुंचने पर गायब हो जाने वाली जानकारी target service तक पहुंचाई जाती है
    • इसे पुराने X-Forwarded-... headers की तुलना में security के लिहाज से संभालना आसान माना जाता है
    • target service को भी PROXY protocol support करना चाहिए
    • apache2 और nginx support करते हैं, और supported services की list भी बढ़ रही है

authentication integration में बची कमी

  • nginx में Vouch Proxy इस्तेमाल करके कुछ services को Azure AD, अब Microsoft Entra authentication, से protect करने वाला setup संभव है
  • Traefik nginx के authentication method जैसी ForwardAuth support करता है
  • Vouch Proxy अभी Traefik में काम नहीं करता और संबंधित issue खुला है
  • Keycloak instance खुद operate करके उसे AAD के साथ integrate कर ForwardAuth में use किया जा सकता है, लेकिन initial setup और security maintenance/updates का burden बड़ा है
  • traefik-forward-auth अक्सर recommend होता है, लेकिन आखिरी update June 2020 में हुआ था और dependencies updates की जरूरत है, इसलिए इसे इस्तेमाल करना कठिन माना गया
  • oauth2-proxy के साथ पुराना experience अच्छा नहीं था, और proxy के पीछे एक और proxy रखने पर HTTP/2, HTTP/3, timeouts, body size, WebSocket settings को हर intermediate proxy पर match करना पड़ता है, जिससे errors की संभावना बढ़ती है
  • 2024-05-06 update के अनुसार oauth2-proxy को HTTP API से भी integrate किया जा सकता है
    • nginx का auth_request support करता है
    • Traefik का ForwardAuth support करता है
    • यह तरीका desired configuration के करीब विकल्प लगता है

user agent और IP blocking

  • ऐसी स्थितियां होती हैं जहां internal service का archive.org पर archive होना नहीं चाहिए
  • robots.txt और similar headers Archive.org blocking में effective नहीं हैं, और crawler blocking के तरीके archive.org_bot user agent blocking या IP range blocking हैं
  • Traefik में user agent या IP address block करने के लिए built-in feature नहीं, बल्कि third-party plugin की जरूरत होती है
    • user agent blocking plugin
    • deny IP plugin
  • third-party plugins पर updates के समय ध्यान देना पड़ता है और ये security vulnerabilities पैदा कर सकते हैं, इसलिए इन्हें prefer नहीं किया जाता
  • IPAllowList middleware से block किए जाने वाले IPs को छोड़कर बाकी को allow करने का तरीका संभव है
    • IP range calculation भी संभव है
    • यह direct blocking से खराब नहीं है, लेकिन सिर्फ बचे हुए subnets देखकर यह जानना कठिन है कि कौन-सी range block की गई है, इसलिए यह elegant नहीं है

configuration example structure

  • example /etc/traefik/traefik.yml और /etc/traefik/dynamic.yml में बंटा है
  • static configuration निम्न को configure करती है
    • :80 और :443 entrypoints
    • HTTP endpoints को बिना exception HTTPS पर redirect करना
    • TLS challenge इस्तेमाल करके Let’s Encrypt certificate issuance
    • dynamic configuration file /etc/traefik/dynamic.yml को watch करना
  • dynamic configuration में निम्न setup शामिल है
    • cloud.xx.xyz के लिए TLS Passthrough TCP routing
    • किसी दूसरे host की 10.33.1.2:4433 service तक forward करना
    • PROXY protocol version 2 enable करना
    • git.xx.xyz के लिए local http://127.0.0.1:3000 पर TLS termination के बाद proxy करना
    • https://xx.xyz/redirmepls को https://google.com पर redirect करने वाला middleware
    • X-Robots-Tag: noindex, nofollow, nosnippet, noarchive header जोड़ने वाला middleware

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-06
Hacker News की राय

  • Traefik काफ़ी अच्छा है, लेकिन यह Ansible जैसी ही भयानक समस्या से जूझता है। docs और लेख बहुत हैं, पर असल में जो चाहिए वह मिल ही नहीं पाता
    मैं v1 से इसका इस्तेमाल कर रहा हूं, फिर भी docs में अक्सर रास्ता भटक जाता हूं और बहुत झुंझलाहट होती है। छोटे projects में मैं Caddy इस्तेमाल करना पसंद करता हूं, क्योंकि उसके docs Traefik जितने खराब नहीं हैं
    technical docs लिखने वालों से कहूं तो, example-focused docs सिर्फ़ सरसरी नज़र डालने वाले beginners के लिए अच्छे होते हैं। जो लोग product से परिचित हैं, उन्हें 10 tutorial pages में बिखरी field descriptions नहीं, बल्कि reference docs और complete lists चाहिए। सिर्फ़ onboarding process पर ध्यान न दें; उन लोगों के हिसाब से भी बनाएं जो रोज़ product इस्तेमाल करते हैं
    यही बात सबसे ज़्यादा खटकती है, और यही वजह है कि मुझे Ansible से इतनी चिढ़ हो गई; Traefik भी कुछ कम स्तर पर वैसा ही है

    • सहमत। https://diataxis.fr जैसे documentation frameworks अगर ज़्यादा व्यापक रूप से जाने जाएं तो सबके लिए मददगार होगा
    • इस category में हाल में जिसने परेशान किया वह OpenTelemetry है। हज़ारों pages हैं, फिर भी basic और common workflows को सच में कैसे पूरा करें, इस पर बहुत कम है
    • जिन्हें YAML interpreter परिवार की languages कहा जा सकता है, उनकी एक समस्या यह है कि YAML खुद एक language है, लेकिन interpreter docs आम तौर पर उस हिस्से को document नहीं करते
      वे मानकर चलते हैं कि बहुत सरल काम सिर्फ़ बहुत flat data structures पर किए जाएंगे, जबकि असल दुनिया में ज़्यादातर ऐसा नहीं होता। ऐसी languages को ठीक से इस्तेमाल करने के लिए YAML कैसे लिखना है, इस पर implicit rules का पूरा set समझना पड़ता है, लेकिन docs उसमें शायद ही मार्गदर्शन देते हैं
      हर module की अपनी configuration docs होती हैं, लेकिन standard configuration कैसे इस्तेमाल करें, returned data को कैसे handle करें या उसे थोड़ी भी complex चीज़ के साथ कैसे combine करें—यह लगभग कभी साफ़ नहीं होता। ऐसा लगता है जैसे हर item के लिए एक paragraph वाले दर्जनभर examples को ingredients के ढेर की तरह फेंक दिया गया हो और कहा गया हो कि अब cake bake करो
      मैंने जिन कई YAML interpreter systems का इस्तेमाल किया है, उनमें लगभग हमेशा यही अनुभव रहा। YAML की लाखों lines से गुज़रने के बाद ही काम निकालना आया, लेकिन docs की value configuration lists से ज़्यादा बहुत कम थी
    • Ansible सच में आपको बार-बार docs खोजने पर मजबूर करता है
      फिर भी ansible-doc इस्तेमाल करते हुए मुझे एक काफ़ी ठीक workflow मिला है, और मेरे अक्सर इस्तेमाल होने वाले aliases हैं alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'
      पहले adls से relevant commands जल्दी search करता हूं, फिर ad से docs देखता हूं, और लगभग हमेशा अंत में सीधे jump करके (G) examples देखता हूं। आमतौर पर वही जवाब वहीं मिल जाता है जिसकी ज़रूरत होती है
      Ansible scripts लिखना docs पर बहुत निर्भर है, इसलिए मेरा मानना है कि default state में भी इस lookup process को बेहतर support करना चाहिए और ऐसा interface देना चाहिए जिससे ढेर सारे aliases बनाए बिना जल्दी खोजा जा सके
    • Pydantic भी मेरे लिए इसी category में आता है। maintainer मानते हैं कि information का एक ही source होना चाहिए, इसलिए वे API reference docs बनाने से इनकार करते हैं
      बेशक यह उनका अपना project है, लेकिन किसी object का एक method ढूंढने के लिए हर बार लंबी prose pages खंगालनी पड़ती हैं। कभी-कभी तो source पढ़ लेना ही आसान होता है

  • प्रोडक्शन में Traefik को 2 साल तक इस्तेमाल किया है। पहले NGINX इस्तेमाल करता था, लेकिन automatic Let's Encrypt integration की वजह से Traefik पर जाने का फैसला किया, और उस फैसले का अफसोस है
    Traefik की documentation मुझे और मेरी टीम को ठीक से समझ नहीं आती। यह झंझट वाला है, और सही logs के बिना अजीब तरह से behave करता है
    उदाहरण के लिए, certificate दोबारा बनाने की कोशिश करें तो यह बीच-बीच में fail हो जाता है और production इस हालत में down हो जाता है कि पता नहीं कब recover होगा। अब वापस NGINX पर लौट रहे हैं

    • इस मामले में NixOS ने वाकई मदद की। configuration.nix में बस कुछ lines जोड़कर configure किया जा सकता है, और अंदर से यह lego(1) और letsencrypt इस्तेमाल करता है
      security.acme = { acceptTerms = true; defaults.email = "admin-email@provider.net"; certs."mydomain.example.com" = { domain = "*.mydomain.example.com"; dnsProvider = "cloudflare"; environmentFile = "/path/to/cloudflare/password"; }; };
      services.caddy.enable = true;
      services.caddy.virtualHosts."subdomain1.mydomain.example.com" = { extraConfig = '' reverse_proxy 127.0.0.1:1234 ''; useACMEHost = "mydomain.example.com"; };
      nginx से configure करना भी काफी मिलता-जुलता होगा। https://github.com/go-acme/lego
    • मैं भी DNS challenge और wildcard certificate के built-in support की वजह से NGINX से Traefik पर आया था। कंपनी में इस्तेमाल होने वाले domain पर लागू करने में कई घंटे लगाए, और घर पर पूरी तरह चलने वाली वही configuration इस्तेमाल करने के बावजूद असल में उसने कुछ भी नहीं किया
      वही domain registrar, वही API, वही Docker configuration थी, और logs भी सभी on थे, लेकिन certificate क्यों नहीं बन रहा था इसकी कोई जानकारी नहीं थी। ऐसा लगा जैसे उसने कोशिश तक नहीं की और बस generated default certificate पर वापस चला गया
      दो troubleshooting sessions और कई घंटों की searching के बाद हार माननी पड़ी और self-signed certificate file इस्तेमाल करनी पड़ी। क्यों नहीं चल रहा इसकी कोई जानकारी न होना, और चुपचाप fail होकर fallback behavior पर चले जाना वाकई परेशान करने वाला है
      कुल मिलाकर Traefik की सबसे बड़ी समस्या यही रही। जब चलता है तो शानदार है, लेकिन जब नहीं चलता, तो troubleshoot करना या documentation में जरूरी जानकारी ढूंढना हमेशा मुश्किल रहा। कंपनी में साल के अंत के आसपास production में Traefik इस्तेमाल करना शुरू करने की योजना है, इसलिए उम्मीद है उससे पहले Traefik से थोड़ी और जान-पहचान हो जाए
    • API gateway चाहिए हो तो मैं बस Go का built-in reverse proxy इस्तेमाल करता आया हूं। इसे जरूरत के हिसाब से आसानी से बदला जा सकता है, और CORS, request limiting, retry जैसी common चीजों के लिए libraries भी आसानी से मिल जाती हैं
      सबसे अच्छी बात यह है कि कोई configuration language नहीं है। बस Go इस्तेमाल करें
    • शायद आपको पहले से पता हो या यह आपके लिए fit न हुआ हो, लेकिन nginx Docker container के लिए Let's Encrypt certificates automate करने वाले काफी Docker helper containers मौजूद हैं
    • Traefik को पहली बार इस्तेमाल करते समय ऐसे ही कई issues झेले थे। उदाहरण के लिए, TLS-01 validation इस्तेमाल करते हुए अगर configuration apply करने से पहले DNS record set न किया हो तो बहुत stress होता था। logs कम होने की वजह से frustration भी वही थी
      बाद में पता चला कि DNS ठीक से set न हो तो validation attempt N बार fail होने के बाद Let's Encrypt कुछ समय तक TLS-01 validation दोबारा reject कर देता है, और आपकी समस्या भी कुछ इसी तरह की लगती है
      DNS-01 validation पर जाने के बाद experience अचानक काफी बेहतर हो गया। publicly expose न की गई services के certificates भी बनाए जा सकते हैं, और TLS-01 तरीके की तुलना में orchestration भी बहुत कम चाहिए
      DNS provider ठीक हो तो समस्या होने पर भी Let's Encrypt के record validate करने से पहले API error मिलने की संभावना ज्यादा होती है, और failure state Let's Encrypt के check-failure backoff से काफी पहले आ जाती है। अब Traefik, Caddy, Nginx या कोई और reverse proxy इस्तेमाल करूं, Let's Encrypt के लिए लगभग तय कर लिया है कि सिर्फ DNS-01 based validation इस्तेमाल करूंगा, और अगर TLS-01 इस्तेमाल करना ही पड़े तो Staging API से शुरुआत में ही यह जरूर verify करूंगा कि सब सही set हुआ है
      वैसे Traefik में Let's Encrypt Staging certificate बना लें तो उस certificate को invalidate करने का कोई अच्छा तरीका नहीं है। certificate हटाने के लिए ACME JSON में बदलाव करना पड़ता है और changes reflect कराने के लिए Traefik restart करना पड़ता है। SIGHUP से हो सकता है, लेकिन कोशिश नहीं की
      कुल मिलाकर अजीब silent failures और behaviors बहुत हैं, लेकिन सबसे बड़ा दर्द यह है कि dependent service errors को opaque बना देता है

  • Traefik के बजाय Caddy इस्तेमाल करता हूं। मेरे हिसाब से Traefik के YAML configuration की तुलना में Caddyfile manage करना कहीं आसान है, और local, production, on-premises deployments के लिए अलग-अलग Caddyfile maintain करता हूं
    अच्छे plugins भी बहुत हैं, और हम Caddy के लिए coraza WAF plugin इस्तेमाल करते हैं, जो अच्छी तरह काम करता है

    • self-hosting setup में Traefik से Caddy और caddy-docker-proxy पर चला गया
      जरूरी features सब हैं और यह कहीं ज्यादा simple है
      https://github.com/lucaslorentz/caddy-docker-proxy
    • Caddy पसंद है, लेकिन production deployment documentation और बेहतर होती तो अच्छा होता। खासकर storage और configuration management पर best practices को लेकर बहुत सारे unanswered questions हैं
      जैसे external storage इस्तेमाल करते समय local storage को कैसे handle किया जाए। कहा तो जाता है कि इसे stateless माना जा सकता है, लेकिन शायद ऐसा न हो
      आखिर में बस यह दुआ करनी पड़ती है कि जिस व्यक्ति ने जरूरी module बनाया है, उसे ठीक से पता हो। क्योंकि उस तरफ भी documentation standard नहीं है। maintainers को ऐसे random modules पर लगाम लगानी चाहिए जो core functionality देते हैं लेकिन documentation शून्य है, जैसे S3 storage backend
    • अगर service discovery या auto scaling जैसी complex चीजों की जरूरत नहीं है, या उन्हें खुद scripts से संभाल सकते हैं, तो Traefik, Docker Swarm, Kubernetes आदि को खुशी-खुशी छोड़कर बस Caddy इस्तेमाल करें। Caddy सच में ज्यादातर चीजें कर सकता है और अच्छी तरह करता है

  • अगर जरूरत बस कुछ Docker hosts और कुछ दर्जन containers जितनी साधारण है, तो सोचता हूं कि nginx के बजाय Traefik इस्तेमाल करने की वजह क्या होगी। मैं https://github.com/NginxProxyManager/nginx-proxy-manager इस्तेमाल करता हूं; इतने छोटे scale पर क्या Traefik कोई फायदा देगा?

    • यहां मेरे हिसाब से https://github.com/caddyserver सबसे अच्छा है। यह SSL certificates अपने-आप संभालता है, बहुत हल्का है, और इसकी config syntax बेहद साफ है
    • मुझे Traefik का hot reload पसंद है। अगर service, यानी proxied app को छिपाना हो, कोई नया route—Traefik की terminology में router—जोड़ना हो, या basic authentication, HTTPS redirect, header manipulation जैसे middleware जोड़ने हों, तो बस file डाल दीजिए और वह अपने-आप reflect हो जाता है। Traefik या उसके virtual hosts को reload करने की जरूरत नहीं पड़ती
      सच कहूं तो मुझे nginx syntax पसंद नहीं था और Traefik चमकदार लगा, यह भी वजह थी। Let's Encrypt renewal और containers की वजह से इसमें आया, और config करने के तरीके की वजह से इसे इस्तेमाल करता रहा
    • अगर आपकी मौजूदा setup अच्छी तरह काम कर रही है, तो मुझे नहीं लगता कि बदलने से कोई खास फायदा मिलेगा
      जब कभी Traefik की कोई ऐसी capability चाहिए हो जो Nginx में न हो, तभी migration पर विचार करूंगा
    • मैं भी NginxProxyManager इस्तेमाल करता हूं और मेरे पास 8 hosts हैं, लेकिन अभी तक ऐसा जवाब नहीं देखा जो समझाए कि caddyserver या traefik NPM की तुलना में क्या फायदा देते हैं
    • सहमत हूं। Nginx config आसान है और एक बार सेट हो जाए तो भूल सकते हैं। वैसे भी ज्यादातर मामलों में आप अपनी मौजूदा किसी दूसरी config से copy-paste ही करते हैं
      Certbot हर जगह मौजूद है और ज्यादा scenarios support करता है, ऐसे में automatic Let's Encrypt को selling point बताना भी थोड़ा अजीब लगता है। Traefik और Caddy का selling point यह नहीं है कि वे पहले से व्यापक रूप से supported alternatives से चीजों को ज्यादा आसान बना देते हैं, इसलिए मेरे लिए यह बात बहुत असरदार नहीं है

  • कुछ हफ्ते पहले reverse proxy चुन रहा था और आखिरकार simplicity की वजह से Caddy चुना। हालांकि Traefik की container auto-discovery और label references काफी अच्छी हैं, और Caddy में भी वही काम करने वाला plugin है
    लेख पढ़ा, लेकिन अभी भी मुझे यकीन नहीं है कि मेरे लिए Traefik, Caddy से बेहतर कैसे है। दूसरों के लिए हो सकता है, इसलिए राय सुनना चाहूंगा

  • यह भी ध्यान देने लायक है कि Traefik default रूप से K3s में configured रहता है। इसी वजह से K3s test के लिए K8s cluster सबसे जल्दी खड़ा करने का तरीका बन गया है, और clusters को cattle की तरह treat करना भी संभव बनाता है
    बस deployment और related services को NodePort के रूप में जोड़ दीजिए, और ingress controller की चिंता किए बिना app access कर सकते हैं
    मैं shell script से K3s cluster खड़ा करता हूं और जरूरत पड़ने पर positional argument में दिए गए app को test करता हूं। इस दौरान ttl.sh की temporary container registry का इस्तेमाल करता हूं। वही script खत्म होने पर cluster भी हटा देती है

  • self-hosting के लिए reverse proxy को Traefik पर ले जाने के बारे में सोच रहा हूं। लेखक के उलट, मैं Docker Compose से containerized workloads चलाता हूं, और अभी शानदार caddy-docker-proxy plugin के साथ Caddy इस्तेमाल कर रहा हूं
    फिलहाल मुझे Docker label-based config वाला reverse proxy, नए workloads की automatic detection, TLS certificates, और caddy-dynamicdns plugin के जरिए automatic DNS setup मिल रहा है। ISP कोई दूसरा IP दे दे तो भी access खोने की चिंता ज्यादा नहीं करनी पड़ती
    लेकिन जब भी नया workload जुड़ता है या restart होता है, पूरा Caddy restart हो जाता है और थोड़ी देर के लिए access टूट जाता है। Caddy मौजूदा connections को नए instance में pass नहीं कर पाता
    साथ ही wildcard certificates इस्तेमाल करना पर्याप्त रूप से simple नहीं है। मैं नहीं चाहता कि सभी workloads certificate transparency logs के जरिए दुनिया के सामने आ जाएं, इसलिए wildcard certificate इस्तेमाल करता हूं; लेकिन तब हर hostname के लिए certificate इस्तेमाल करने वाली simple Caddyfile syntax इस्तेमाल नहीं कर सकता। पता है कि Caddy में इस पर काम चल रहा है, पर फिलहाल स्थिति ऐसी ही है
    खैर, k8s environment में Traefik इस्तेमाल किया है और वह काफी ठीक लगा, इसलिए personal use के लिए भी एक बार आजमाने का सोच रहा हूं। मेरी इस बात की वजह से कोई Caddy try न करे, ऐसा नहीं होना चाहिए। Caddy भी सच में बहुत अच्छा है

    • single-purpose host जैसी जगहों पर मैं Caddy इस्तेमाल करता हूं, लेकिन आपने जो समस्या बताई है, उस पर मैं 100% Traefik लगाऊंगा। असल में अपने k8s cluster ingress में इसे इस्तेमाल कर रहा हूं, और development environment में localtest.me को hostnames के साथ इस्तेमाल करने के लिए चलाता हूं
      एक बार try करने लायक है। दोनों अलग-अलग क्षेत्रों में बेहतरीन हैं
    • मैं rootless Docker Compose + Traefik इस्तेमाल करता हूं। wildcard certificate सचमुच बिना दर्द के हो गया, यही वजह है। हालांकि मैं अपना DNS server इस्तेमाल करता हूं और Let's Encrypt DNS challenge के लिए RFC2136 DDNS इस्तेमाल करता हूं
      Plugin की असल में जरूरत नहीं है। मेरे पास एक Ansible playbook है जो VM पर यह सब setup करता है और compose file templates तक बनाता है, और एक दूसरी playbook है जो server से data और mounts को छोड़कर बाकी सब हटा देती है। backup के लिए files और कई DB आदि को कई locations पर backup करने वाले custom scripts और restic इस्तेमाल करता हूं
      पहले k3s deploy करता था, लेकिन self-hosting के लिए वह बहुत ज्यादा और जटिल है, यह समझ आया। मुझे बस जल्दी deploy करना है और certificates को खुद manage नहीं करना है
    • मैंने Caddy नहीं इस्तेमाल किया है और Traefik इस्तेमाल करता हूं; config और TLS certificate auto-renewal के लिए Docker properties discover करके use करता हूं। dynamic DNS के बारे में नहीं जानता और Traefik में इस्तेमाल नहीं करता। जहां तक याद है, containers add या remove करने पर restart की जरूरत नहीं थी
    • production में caddy-docker-proxy इस्तेमाल किया है, और नई config load करते समय Caddy ने connections drop नहीं किए
      अभी local पर check किया और यह ठीक काम करता है
    • यह तो बहुत बड़ी limitation है। config update करने के लिए restart करते हुए connections drop करने वाला reverse proxy पहली बार सुन रहा हूं। आमतौर पर ऐसे server design में सबसे पहले और सबसे basic चीजों में यही संभाली जाती है

  • Traefik काफी इस्तेमाल किया है, लेकिन सिर्फ एक reverse proxy रखने के लिए docker-compose labels, layers और ढेर सारी lines से जूझते-जूझते थक गया। फिर Caddy मिला और पीछे मुड़कर नहीं देखा
    शायद मैं Traefik का target user नहीं था। मुझे बस HTTPS enabled reverse proxy या basic authentication layer जैसी चीज चाहिए। Caddy में दोनों एक-एक line में हो जाते हैं, बहुत concise है, और ऐसी layers भी नहीं हैं जिन्हें मैं आज तक समझ नहीं पाया

  • कई सालों से अपनी पूरी self-hosting के लिए Traefik इस्तेमाल कर रहा हूँ
    हालांकि dynamic discovery और Docker labels वाले फीचर इतने पेचीदा और debug करने में इतने झुंझलाहट भरे थे कि उन्हें छोड़ दिया
    इसके बजाय template engine से static config file generate करता हूँ। लगभग सारी services host/target/port के combination वाली होती हैं, इसलिए संबंधित sections बनाना बहुत आसान है, और TLS handling के अलावा कोई जटिल middleware भी नहीं है। लिंक किए गए लेख के लेखक ने भी शायद यही रास्ता चुना है
    config को Ansible script से generate करके उस machine पर copy करता हूँ जहाँ Traefik चल रहा है, और Traefik उस file वाली directory को watch करता है और बदलाव होने पर अपने-आप reload कर लेता है। यह बहुत अच्छे से काम करता आया है

  • Production में containers के साथ Traefik इस्तेमाल कर रहा हूँ, और इसकी सबसे पसंदीदा बात यह है कि config container labels में रहता है। इसलिए Traefik config को खुद modify करने की जरूरत लगभग नहीं पड़ती
    सबसे बड़ा drawback यह पता लगाना है कि नाम को pronounce कैसे करना चाहिए। लगता तो है कि इसे सामान्य traffic की तरह ही पढ़ते हैं, लेकिन बार-बार “trey-feek” जैसा कुछ बोलने का मन करता है

    • labels वाले तरीके से काफी सहमत हूँ। पहली बार लिखते समय escaping और verbosity की वजह से यह थोड़ा ज्यादा कठिन होता है, लेकिन track करने वाली scope बहुत कम हो जाती है
      Traefik और Docker Compose का combination छोटे self-hosting setups के लिए, k8s तक बढ़ने से पहले, एक अच्छा sweet spot लगता है—खासकर जब servers की संख्या k8s high-availability control plane द्वारा इस्तेमाल किए जाने वाले servers से भी कम हो
    • हम भी इसे production में इस्तेमाल कर रहे हैं। लोग हँस सकते हैं, लेकिन कागज पर cool और अलग दिखने वाला, पर असल में भयानक नाम रखना बड़ा drawback है
      colleagues से मिली तिरछी नजरों और हँसी की मात्रा बहुत ज्यादा थी, और इससे product को अपनाने और इस्तेमाल करने में बाधा आई
      हम इसे “tray-feek” कहते थे और वह फिर भी ठीक था, लेकिन official support से बात की तो उन्होंने कहा कि इसे सामान्य “traffic” की तरह ही pronounce करते हैं। इसलिए उस proxy के बारे में बात करते समय हर बार ऐसे वाक्य बनते हैं: “public load balancer पर traffic receive होता है, और traffic की native load balancing traffic को traffic के pod में भेजती है।” यह बेवकूफी जैसा सुनाई देता है, और असल में बेवकूफी ही है
    • मैं तो बस इसे “traffic” ही pronounce करता हूँ। उनकी इस कमबख्त mind game में नहीं पड़ूँगा
    • मेरे हिसाब से सबसे बड़ा drawback यह है कि अगर container मौजूद नहीं है या running नहीं है, तो Traefik को उस container या labels के बारे में पता नहीं होता
      वरना maintenance page, inactive होने के बाद पहली request पर container को start करना जैसे अच्छे काम और आसानी से किए जा सकते थे
      इसलिए सोच रहा हूँ कि एक plugin बनाऊँ जो यह जानता हो कि compose files कहाँ रखी हैं और उन्हें वहाँ से सीधे पढ़ सके
    • ae सबसे ज्यादा y या hi के करीब है। इसलिए मेरा अनुमान Tryfik है, वरना Trayfik। अगर European-style fik हो तो feek भी हो सकता है