Traefik کے ساتھ 1 Compose فائل میں 5 ایپس

ایک IP، پانچ ایپس، ایک port 443

آپ کے VPS کا ایک public IPv4 address اور ایک TCP port 443 ہے۔ آپ اسی سرور پر Gitea، اپنی ایپ کی staging copy، ایک internal dashboard، ایک status page اور ایک webhook receiver چلانا چاہتے ہیں۔ پانچ hostnames، ایک ہی server۔ Reverse proxy وہ process ہے جو :80 اور :443 ports اپنے پاس رکھتا ہے، ہر request میں موجود Host header پڑھتا ہے، اور request کو درست container تک پہنچاتا ہے۔ Traefik یہ کام کرتا ہے۔ یہ آپ کی جانب سے کبھی دستی طور پر certbot چلائے بغیر ہر hostname کے لیے certificate حاصل اور renew بھی کرتا ہے۔ Nginx اور Caddy بھی انہی پانچ hostnames کے لیے TLS termination بخوبی کر سکتے ہیں۔ اس لیے اگر انتخاب ابھی باقی ہے تو سب کچھ کسی ایک proxy سے منسلک کرنے سے پہلے certificate handling اور ہر ایپ کی configuration cost کے لحاظ سے تینوں proxies کا موازنہ کرنا مفید ہوگا۔

Traefik اور nginx server {} block میں بنیادی فرق یہ ہے کہ ان کی configuration کہاں سے آتی ہے۔ Nginx میں آپ file edit کرکے reload کرتے ہیں، جبکہ certificate lifecycle الگ کام رہتا ہے۔ یہی وہ workflow ہے جس پر آپ عمل کرتے ہیں جب آپ nginx پر certbot کے ذریعے Let's Encrypt certificates جاری کرتے ہیں، جہاں renewal timer مکمل طور پر web server سے باہر موجود ہوتا ہے۔ Traefik کا Docker provider Docker event stream کو monitor کرتا ہے اور آپ کے containers سے labels پڑھتا ہے۔ Host() rule label کے ساتھ container start کریں تو وہ ایک second کے اندر routable ہو جاتا ہے؛ اسے stop کریں تو route ختم ہو جاتا ہے۔ یہی اس طریقے کا خطرہ بھی ہے۔ Labels میں موجود configuration بیک وقت پانچ جگہوں پر پھیلی ہوتی ہے، اور غلط label خاموشی سے اثر انداز نہیں ہوتی۔ Container صرف route نہیں ہوتا، اور Traefik کوئی پیغام بھی نہیں دیتا۔

چار بنیادی اصطلاحات

• Entrypoints وہ listening sockets ہیں۔ آپ دو entrypoints متعین کریں گے: web، :80 پر، اور websecure، :443 پر۔
• Routers درخواست (Host(...)) سے مطابقت کرتے ہیں اور اسے کسی service سے منسلک کرتے ہیں۔ Certificates ہر router کے لیے tls.certresolver کے ذریعے طلب کیے جاتے ہیں۔
• Services backend ہوتی ہیں: ایک container اور وہ port جس پر container Docker network کے اندر listening کرتا ہے۔
• Middlewares router اور service کے درمیان کام کرتے ہیں: basic auth، IP allow-lists، header rewrites اور redirects۔

یہ چار اصطلاحات Traefik میں ان کاموں کے نام ہیں جنہیں آپ بصورتِ دیگر دستی طور پر لکھتے۔ router ایک server_name ہوتا ہے، service ایک proxy_pass target ہوتی ہے، اور middlewares وہ header اور auth directives ہوتے ہیں جو آپ خود اس وقت متعین کرتے ہیں جب آپ nginx reverse proxy server block کو سطر بہ سطر بناتے ہیں۔

Static configuration، یعنی entrypoints، providers اور ACME، Traefik کی command line یا traefik.yml میں فراہم کی جاتی ہے، اور اسے تبدیل کرنے کے لیے Traefik کو restart کرنا پڑتا ہے۔ Dynamic configuration، یعنی routers، services اور middlewares، container labels سے آتی ہے اور hot-reload ہو جاتی ہے۔ دونوں کو خلط ملط کرنا عموماً اس مسئلے کی وجہ بنتا ہے کہ "میرا flag کوئی اثر نہیں کر رہا"۔

Compose فائل

ایک مشترکہ Docker network، جس کا نام proxy ہے، بنیادی ڈھانچہ فراہم کرتا ہے۔ Traefik کسی container تک اسی وقت پہنچ سکتا ہے جب دونوں اسی network پر موجود ہوں۔

name: edge

networks:
  proxy:
    name: proxy

services:
  traefik:
    image: traefik:v3.5
    restart: unless-stopped
    command:
      - --providers.docker=true
      - --providers.docker.exposedByDefault=false
      - --providers.docker.network=proxy
      - --entryPoints.web.address=:80
      - --entryPoints.websecure.address=:443
      - --entryPoints.web.http.redirections.entryPoint.to=websecure
      - --entryPoints.web.http.redirections.entryPoint.scheme=https
      - --certificatesresolvers.le.acme.email=you@example.com
      - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json
      - --certificatesresolvers.le.acme.tlschallenge=true
      # while you iterate, point at staging so a mistake costs nothing:
      # - --certificatesresolvers.le.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory
      - --api.dashboard=true
      - --log.level=INFO
      - --accesslog=true
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.dashboard.rule=Host(`traefik.example.com`)
      - traefik.http.routers.dashboard.entrypoints=websecure
      - traefik.http.routers.dashboard.tls.certresolver=le
      - traefik.http.routers.dashboard.service=api@internal
      - traefik.http.routers.dashboard.middlewares=dashboard-auth
      - traefik.http.middlewares.dashboard-auth.basicauth.users=admin:$$apr1$$REPLACE$$THIS

  gitea:
    image: gitea/gitea:1  # major-only pin keeps this demo copy-pasteable; pin an exact release in production
    restart: unless-stopped
    volumes:
      - ./gitea:/data
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.gitea.rule=Host(`git.example.com`)
      - traefik.http.routers.gitea.entrypoints=websecure
      - traefik.http.routers.gitea.tls.certresolver=le
      - traefik.http.services.gitea.loadbalancer.server.port=3000

پہلے docker compose up -d، پھر docker compose logs -f traefik۔ ہر اضافی ایپ، gitea block کی ایک نقل ہوتی ہے، جس میں اپنا router name، اپنا Host() اور اپنا داخلی port ہوتا ہے۔ Docker میں TLS اور backups کے ساتھ چلنے والی Nextcloud installation بھی اسی طریقے سے شامل کی جا سکتی ہے۔ اس کے published ports ہٹا دیں، اسے proxy سے attach کریں، اور hostname اور certificate کو router labels کے ذریعے manage ہونے دیں۔

اس حصے کی پانچ تفصیلات خاص اہمیت رکھتی ہیں۔

exposedByDefault=false کے باعث کوئی container اس وقت تک Traefik کو نظر نہیں آتا جب تک اس پر traefik.enable=true موجود نہ ہو۔ اسے شامل نہ کرنے پر آپ کے شروع کیے گئے ہر container کے لیے route generate ہو جائے گا، حتیٰ کہ وہ عارضی postgres بھی جسے آپ نے کسی چیز کی جانچ کے لیے چلایا تھا۔

providers.docker.network=proxy Traefik کو بتاتا ہے کہ جب کوئی container متعدد networks سے attached ہو تو کون سا network استعمال کرنا ہے۔ اسے چھوڑنے پر Traefik غلط container IP منتخب کر سکتا ہے، جس کا نتیجہ 502 ہوتا ہے اور یہ application fault جیسا دکھائی دیتا ہے۔

loadbalancer.server.port=3000 container کے اندر والا port ہے؛ Gitea وہاں 3000 پر listen کرتا ہے۔ غور کریں کہ کوئی app container port publish نہیں کرتا؛ صرف Traefik port publish کرتا ہے۔

web entrypoint پر redirect، plaintext requests کو HTTPS کی طرف 308 میں تبدیل کرتا ہے۔ Port 80 پھر بھی کھلا رہتا ہے: ACME HTTP challenge کے لیے اس کی ضرورت ہوتی ہے، اور ان صارفین کے لیے بھی جو hostname بغیر scheme کے درج کرتے ہیں۔

Basic-auth hash میں موجود دگنا $$ Compose escaping ہے، کوئی typographical error نہیں۔ اسے htpasswd -nbB admin 'your-password' کے ذریعے generate کریں، جو apache2-utils package میں شامل ہے، پھر ہر $ کو دگنا کریں۔

certificate اور acme.json کا مسئلہ

tlschallenge=true سے TLS-ALPN-01 منتخب ہوتا ہے: Let's Encrypt آپ کے box پر 443 کے ذریعے connect کرتا ہے، اور Traefik TLS handshake کے اندر challenge کا جواب دیتا ہے۔ متبادل HTTP-01 ہے، جو port 80 پر کام کرتا ہے۔ Traefik کی command: فہرست میں tlschallenge والی سطر کو ان دو سطروں سے بدل دیں:

      - --certificatesresolvers.le.acme.httpchallenge=true
      - --certificatesresolvers.le.acme.httpchallenge.entrypoint=web

دونوں طریقے کام کرتے ہیں۔ دونوں کے لیے ضروری ہے کہ hostname کا public DNS پہلے ہی آپ کے VPS کی طرف اشارہ کر رہا ہو، certificate authority اس نام کو resolve کر سکے اور بیرونی نیٹ ورک سے connect کر سکے۔ پہلے A (اور AAAA) record بنائیں، dig +short git.example.com سے تصدیق کریں، پھر Traefik شروع کریں۔

اب اس مسئلے کی بات کرتے ہیں جو لوگوں کا پورا شام کا وقت لے لیتا ہے۔ Traefik اپنا ACME account key اور جاری کیے گئے تمام certificates ایک acme.json میں محفوظ کرتا ہے۔ اگر اس file کو group یا world کے لیے پڑھنے کی اجازت حاصل ہو تو Traefik اس سے ملتی جلتی سطر دکھا کر رک جاتا ہے:

error: unable to get ACME account: permissions 644 for /letsencrypt/acme.json are too open, please use 600

درست حل وہی ہے جو اوپر دیا گیا ہے: directory کو bind-mount کریں اور Traefik کو درست mode کے ساتھ file خود بنانے دیں۔ اگر آپ نے acme.json کو touch کے ذریعے بنایا تھا تو آپ کے umask نے اس کا mode 644 کر دیا۔ اسے host پر درست کریں:

chmod 600 ./letsencrypt/acme.json
docker compose restart traefik

اس directory کا backup اپنی app volumes کے ساتھ رکھیں۔ اسے کھو دینا قابل تلافی ہے، certificates دوبارہ جاری ہو جائیں گے، لیکن ایک ہی وقت میں پانچ hostnames کے لیے دوبارہ certificates جاری کرنے سے rate limits لاگو ہو سکتی ہیں۔

ترقی کے دوران staging CA استعمال کریں۔ caserver والی سطر کو uncomment کریں، تمام routes کے کام کرنے کی تصدیق کریں، پھر اسے comment out کریں اور acme.json حذف کریں تاکہ production certificates نئے سرے سے طلب کیے جائیں۔ Production Let's Encrypt ایک جیسے hostnames کے مجموعے کے لیے ہر ہفتے زیادہ سے زیادہ پانچ duplicate certificates جاری کرتا ہے، اور ایک ہی نام کے لیے بار بار ناکام validations کو محدود کرتا ہے۔ Staging غیر معتبر certificates جاری کرتا ہے، اس لیے browser warning دکھاتا ہے۔ یہ warning اس بات کی علامت ہے کہ عمل کامیاب رہا، جبکہ staging کی limits کہیں زیادہ نرم ہیں۔

ڈیش بورڈ ایک کنٹرول سطح ہے، محض ڈیمو نہیں

زیادہ تر quickstarts --api.insecure=true سیٹ کرتے ہیں، جس سے ڈیش بورڈ port 8080 پر کسی authentication کے بغیر دستیاب ہو جاتا ہے۔ public IP والے سرور پر اس طرح آپ کی routing topology، hostnames، middleware names اور backend ports ہر scan کرنے والے کو معلوم ہو سکتے ہیں۔

اوپر موجود traefik سروس کے labels متبادل طریقہ دکھاتے ہیں: ڈیش بورڈ کو کسی بھی دوسری ایپ کی طرح حقیقی hostname پر، TLS کے ذریعے اور basicauth کے پیچھے route کیا جاتا ہے۔ service=api@internal router کو Traefik کے built-in API سے منسلک کرتا ہے۔ اسے مزید محفوظ بنانے کے لیے IP allow-list کو بائیں سے دائیں chain کریں۔ اگر آپ کا office address dynamic ہے تو range کو اسی VPS پر self-host کیے گئے WireGuard VPN کے ذریعے فراہم کردہ subnet پر سیٹ کریں، اور ڈیش بورڈ تک صرف tunnel کے ذریعے رسائی حاصل کریں:

- traefik.http.middlewares.office.ipallowlist.sourcerange=10.0.0.7/32
- traefik.http.routers.dashboard.middlewares=office,dashboard-auth

ایک مشترکہ basicauth password اس وقت قابلِ دفاع نہیں رہتا جب پانچ ایپس کو اپنے الگ accounts درکار ہوں۔ اسی middleware slot میں forwardauth شامل کیا جا سکتا ہے، جو فیصلہ Authentik، ایک self-hosted single sign-on server کے سپرد کرتا ہے۔ یوں ڈیش بورڈ اور اس کے ساتھ موجود ہر route ایک ہی login کے پیچھے آ جاتے ہیں، جسے آپ ایک ہی مقام سے revoke کر سکتے ہیں۔

Docker socket کو root-level رسائی حاصل ہے

/var/run/docker.sock ایک API ہے جو ایسا container بنا سکتی ہے جس میں host سے / mount کیا جا سکتا ہے۔ اس تک رسائی machine پر root کے مساوی ہے، اور Traefik کو labels پڑھنے کے لیے اس کی ضرورت ہوتی ہے۔

Mount پر :ro برقرار رکھیں، لیکن واضح رہیں کہ اس سے کیا حاصل ہوتا ہے: یہ صرف socket file کو read-only بناتا ہے۔ اس سے Docker API کو بھیجی جانے والی POST requests نہیں رکتیں۔ حقیقی تخفیف یہ ہے کہ Traefik کو socket کبھی نہ دیں اور درمیان میں filtering proxy رکھیں:

  dockerproxy:
    image: tecnativa/docker-socket-proxy   # pin the current tag
    restart: unless-stopped
    environment:
      CONTAINERS: 1
      NETWORKS: 1
      POST: 0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - proxy

Traefik سے socket volume ہٹا دیں اور provider کو proxy کی طرف point کریں:

--providers.docker.endpoint=tcp://dockerproxy:2375

Traefik کو containers اور networks تک read access برقرار رہتی ہے، جبکہ وہ کوئی چیز create کرنے کی صلاحیت کھو دیتا ہے۔

فائر وال، ports، اور وہ rule جسے سب غلط سمجھتے ہیں

دو ports کھلے ہیں، اور SSH بھی:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Docker کے published ports ufw کو bypass کرتے ہیں۔ Docker اپنے iptables rules داخل کرتا ہے، جنہیں ufw کی chains سے پہلے evaluate کیا جاتا ہے۔ اس لیے ports: ["3000:3000"] کے ساتھ شروع کیا گیا container اس وقت بھی internet سے قابل رسائی رہتا ہے جب اسی port کے لیے ufw deny rule موجود ہو۔ اس کا دفاع firewall configuration نہیں بلکہ structural پابندی ہے: ports صرف Traefik سے publish کریں، اور ہر دوسرے container کو صرف networks: [proxy] دیں، اس کے علاوہ کچھ نہیں۔ اگر کسی سروس کو واقعی host تک رسائی درکار ہو تو اسے loopback، "127.0.0.1:3000:3000" پر bind کریں۔

خرابیوں کی تشخیص: وہ errors جو آپ واقعی دیکھیں گے

404 page not found، جسے Traefik نے serve کیا ہے۔ کسی router سے match نہیں ہوا۔ امکان کی ترتیب کے مطابق: container میں traefik.enable=true موجود نہیں، جبکہ exposedByDefault=false set ہے؛ Host() rule میں آپ کے درج کردہ نام سے match نہیں ہوتا؛ ایک label میں router کا نام دوسرے label کے router نام سے مختلف ہے (routers.gitea.rule اور routers.gitea.entrypoints ایک ہی لفظ ہونے چاہییں)؛ یا آپ نے hostname کو backticks کے بجائے quotes میں لکھا ہے۔ Traefik v3 کو matchers کے اندر backticks درکار ہوتے ہیں۔

502 Bad Gateway۔ کسی router سے match ہوا، لیکن backend تک رسائی ممکن نہیں تھی۔ تقریباً ہمیشہ container proxy network پر موجود نہیں ہوتا؛ docker inspect -f '{{json .NetworkSettings.Networks}}' gitea چیک کریں۔ دوسری ممکنہ وجہ غلط loadbalancer.server.port ہے: آپ نے اسے published port دیا ہے، یا app کسی اور port پر listen کرتی ہے۔ log میں کوشش کی گئی destination درج ہوتی ہے: dial tcp 172.18.0.5:8080: connect: connection refused۔

browser warning دکھاتا ہے، اور certificate TRAEFIK DEFAULT CERT کے نام پر جاری ہوا ہے۔ اس hostname کے لیے کوئی certificate موجود نہیں، اس لیے Traefik نے اپنا self-signed placeholder serve کیا۔ ACME lines پڑھیں:

unable to obtain ACME certificate for domains "git.example.com" ...
acme: error: 400 ... DNS problem: NXDOMAIN looking up A for git.example.com

DNS ابھی اس server کی طرف point نہیں کر رہا۔ record درست کریں، TTL ختم ہونے کا انتظار کریں، پھر Traefik restart کریں۔

HTTP challenge پر Invalid response from http://git.example.com/.well-known/acme-challenge/...: باہر سے port 80، Traefik تک نہیں پہنچ رہا۔ عموماً وجہ VPS کے سامنے provider-level firewall ہوتی ہے، نہ کہ ufw۔

Certificates کبھی issue نہیں ہوتے، اور آپ کا DNS Cloudflare پر ہے جس میں orange cloud فعال ہے۔ Cloudflare اپنے edge پر TLS terminate کرتا ہے، اس لیے TLS-ALPN-01 اس کے ذریعے مکمل نہیں ہو سکتا۔ Certificate issue کرتے وقت record کو DNS-only پر set کریں، یا API token کے ساتھ DNS-01 challenge استعمال کریں۔ Wildcard certificates جاری کرنے والا واحد challenge بھی DNS-01 ہے۔

Redirect loop۔ Traefik کے سامنے موجود کوئی جزو پہلے ہی TLS terminate کر کے plaintext کو :80 پر forward کر رہا ہے؛ entrypoint redirect اسے دوبارہ HTTPS پر بھیج رہا ہے۔ دونوں redirects میں سے ایک ہٹا دیں۔

اسے مسلسل چلتا رکھنا

Docker کی unit کو boot پر فعال ہونا چاہیے (systemctl is-enabled docker)، اور restart: unless-stopped reboot کے بعد stack دوبارہ شروع کر دیتا ہے۔ واضح کنٹرول کے لیے ایک چھوٹی systemd unit چلائیں جو docker compose -f /srv/edge/compose.yml up -d استعمال کرے اور RemainAfterExit=yes کے ذریعے آپ کو systemctl status edge اور ترتیب کا اختیار دے۔

Traefik tag کو pin کریں (traefik:v3.5، latest کبھی نہیں)۔ v2 سے v3 کے upgrade میں rule syntax اور provider names تبدیل ہوئے، اور غیر زیرِ نگرانی latest ایسی configuration کو اطمینان سے دوبارہ load کر دے گا جسے وہ اب سمجھتا نہیں۔ Upgrade سوچ سمجھ کر کریں: migration notes پڑھیں، tag تبدیل کریں، docker compose up -d traefik، اور log monitor کریں۔ اگر آپ اب بھی v2 tag استعمال کر رہے ہیں تو Traefik v2 سے v3 کی migration guide ہر rename، compatibility mode اور ایسے rollback کا طریقہ بیان کرتی ہے جو آپ کے certificates برقرار رکھتا ہے۔

./letsencrypt اور ہر app کے data volume کا backup بنائیں۔ Traefik میں compose file سے دوبارہ بنانے کے قابل state کے علاوہ کوئی اور state موجود نہیں ہوتی۔

اسکیل بڑھانے پر کیا خراب ہوتا ہے

پہلی حد throughput نہیں بلکہ single box ہے: ایک VPS پر چلنے والا ایک Traefik پانچ ایپس کے لیے single point of failure ہے، اور acme.json flat-file storage استعمال کرتا ہے؛ اسے لکھنے والے دو Traefik instances اس storage کو corrupt کر دیں گے۔ اسکیل آؤٹ کرنے کے لیے certificate storage کو file سے باہر منتقل کرنا ہوگا، یا TLS termination کہیں اور کرنی ہوگی۔

دوسرا مسئلہ طویل مدت تک قائم رہنے والے connections ہیں۔ Server-sent events، بڑی uploads اور سست clients entrypoint کے response timeouts سے متاثر ہوتے ہیں؛ --entryPoints.websecure.transport.respondingTimeouts.readTimeout اور اس کے writeTimeout اور idleTimeout متعلقہ options اسی مقصد کے لیے ہیں۔ WebSockets بغیر کسی اضافی configuration کے گزر جاتے ہیں۔

تیسرا مسئلہ disk ہے۔ --accesslog=true stdout پر لکھتا ہے، اور Docker کا json-file driver اسے cap مقرر کیے بغیر ہمیشہ محفوظ رکھتا ہے۔ Traefik service پر logging.options.max-size مقرر کریں، یا access log کو file میں لکھ کر اسے rotate کریں۔

اس میں سے کسی کام کے لیے orchestrator ضروری نہیں۔ البتہ آپ کے اختیار میں ایک ایسا server ہونا چاہیے جس کا حقیقی IP ہو اور ports 80 اور 443 دنیا بھر سے کھلے ہوں۔ ایک چھوٹا single VPS ہی dependencies کی مکمل فہرست ہے۔

FAQ

کیا Traefik چلانے کے باوجود مجھے certbot کی ضرورت ہے؟

نہیں۔ Traefik کا ACME resolver ہر routed hostname کے لیے certificate طلب کرتا اور renew کرتا ہے، اور تمام certificates کو acme.json میں محفوظ کرتا ہے۔ جب nginx یا کوئی دوسرا server خود TLS terminate کرتا ہو تو certbot اب بھی درست tool ہے؛ ایک ہی hostnames کے لیے دونوں کو چلانے سے صرف Let's Encrypt کی rate limits ضائع ہوتی ہیں۔

Traefik کے ذریعے میرے container سے 404 کیوں موصول ہوتا ہے؟

Traefik کی طرف سے دیا گیا 404 اس بات کی علامت ہے کہ کسی router نے request match نہیں کی۔ تصدیق کریں کہ container میں traefik.enable=true موجود ہے (exposedByDefault=false set ہونے کے بعد یہ لازمی ہے)، Host() کی value آپ کے درج کیے گئے نام سے match کرتی ہے، اور اس app کے ہر label میں router کا نام یکساں ہے۔ Traefik v3 matcher کے اندر quotes کے بجائے backticks بھی چاہتا ہے۔

یہاں 404 اور 502 میں کیا فرق ہے؟

404 کا مطلب ہے کہ routing ہوئی ہی نہیں؛ 502 کا مطلب ہے کہ router نے match کیا، لیکن backend نے connection قبول نہیں کیا۔ 502 کی عام وجوہات میں ایسا container شامل ہے جو proxy network سے attached نہیں، اور ایسا loadbalancer.server.port جو published port کی طرف اشارہ کر رہا ہو، نہ کہ اس port کی طرف جس پر app container کے اندر listen کرتی ہے۔ Access log میں وہ exact address درج ہوتا ہے جس سے Traefik نے connection قائم کرنے کی کوشش کی۔

کیا Docker socket کو read-only mount کرنا کافی ہے؟

:ro flag socket file کو read-only بناتا ہے، اس کے پیچھے موجود API کو نہیں؛ POST requests اب بھی اسی کے ذریعے جاتی ہیں، اور Docker API تک رسائی host پر root کے مساوی ہے۔ زیادہ محفوظ طریقہ اوپر دکھایا گیا docker-socket-proxy container ہے، جو Traefik کو صرف containers اور networks کے بارے میں read operations فراہم کرتا ہے اور write operations کو مکمل طور پر روک دیتا ہے۔

کیا Traefik wildcard certificate جاری کر سکتا ہے؟

صرف DNS-01 challenge کے ذریعے، اور اس کے لیے آپ کے DNS provider کا API token درکار ہوتا ہے۔ TLS-ALPN-01 اور HTTP-01 ہر ایک صرف ایک hostname کی توثیق کرتے ہیں اور wildcard certificate جاری نہیں کر سکتے۔ جب Cloudflare جیسا CDN آپ کے VPS کے سامنے TLS terminate کرتا ہو اور باقی دونوں challenges مکمل نہ ہو سکیں، تو DNS-01 ہی درست طریقہ ہے۔