Reverse proxy dan load balancer Traefik yang patut diperhatikan meski tanpa kontainer

• Traefik terkenal di lingkungan kontainer, tetapi karena dapat didistribusikan sebagai satu file executable Go, ia juga bisa dioperasikan sebagai reverse proxy tanpa mesin kontainer
• Dibanding keluarga nginx/caddy/apache2 yang menyajikan file secara langsung, Traefik lebih merupakan proxy yang mirip HAProxy, dengan fokus pada penerusan request, pengembalian response, dan penyesuaian header
• Tanpa memakai label Docker pun, Traefik dapat dikonfigurasi dengan provider file konfigurasi, serta mengelola router, service, dan middleware dengan memisahkan konfigurasi statis dan dinamis
• Mendukung TLS Passthrough serta input/output PROXY protocol milik HAProxy, tetapi PROXY protocol juga harus didukung oleh service tujuan; apache2 dan nginx mendukungnya
• Integrasi autentikasi serta pemblokiran user agent dan IP bisa jadi kurang memadai dengan fitur bawaan saja, sehingga beban pengelolaan ForwardAuth, oauth2-proxy, dan plugin pihak ketiga juga perlu dipertimbangkan

---

Traefik yang bisa dipakai di luar kontainer

• Dalam beberapa tahun terakhir, Traefik populer di ranah YouTube home-lab, dan terutama diperkenalkan bersama infrastruktur kontainer seperti Docker atau Kubernetes
• Sifat fiturnya lebih dekat ke HAProxy daripada nginx/caddy/apache2
  • Meneruskan request ke service dan mengembalikan response
  • Dapat memodifikasi header serta sebagian request/response
  • Tidak mendukung penyajian file
• Di lingkungan kontainer, Traefik juga bisa dijalankan sebagai kontainer dan melakukan mount socket Docker untuk mendeteksi kontainer lain secara otomatis
  • Perilaku proxy dapat dikonfigurasi lewat label Docker pada kontainer
  • Saat mendeteksi kontainer baru, Traefik dapat otomatis meminta sertifikat TLS Let’s Encrypt dan mempublikasikan service

Deployment sebagai binary tunggal dan systemd

• Traefik ditulis dalam Go dan dikompilasi menjadi satu file executable
• Distribusi binary dapat diunduh dari dokumentasi instalasi Traefik
• Tanpa mesin kontainer pun, Traefik sendiri dan semua service tujuan dapat dijalankan
• Contoh unit service systemd tersedia di repositori Traefik
• Dalam operasional nyata, selain file konfigurasi, perlu juga membuat user terpisah dan mengatur permission file konfigurasi

Konfigurasi berbasis file konfigurasi

• Jika tidak memakai kontainer, label Docker tidak dapat digunakan, tetapi Traefik bisa dikonfigurasi dengan provider file
• Konfigurasi secara garis besar dibagi menjadi dua bagian
  • Konfigurasi statis: berisi penyedia sertifikat seperti Let’s Encrypt dan entrypoint, yaitu port tempat Traefik menerima koneksi
  • Konfigurasi dinamis: berisi router, service, dan middleware
• Traefik dapat mendeteksi event filesystem dan melakukan hot reload konfigurasi dinamis
• Dokumentasinya menyediakan konsep inti dan contoh konfigurasi sesuai masing-masing metode
• Istilah seperti certificate provider, entrypoint, router, service, dan middleware dapat dicek cepat di dokumentasi Traefik

Perilaku setelah konfigurasi dan debugging

• Saat konfigurasi tidak sesuai, Traefik menampilkan peringatan
• Log bawaan tidak terlalu banyak, tetapi cukup mudah memahami jalur yang dilalui request
• Ada pengalaman pengguna bahwa konfigurasi awal selesai cepat dan tidak mengalami masalah acak

TLS Passthrough dan PROXY protocol

• Traefik mendukung TLS Passthrough
  • Traffic dapat diteruskan ke web service yang menyediakan sertifikat TLS sendiri tanpa menghentikan TLS di proxy
  • Konfigurasi yang membuat service meminta langsung sertifikat Let’s Encrypt melalui Traefik juga dimungkinkan
  • Proxy tidak dapat melihat isi yang diteruskan
• Pemilihan virtual host umumnya dilakukan dengan header HTTP Host, tetapi pada TLS Passthrough header tersebut berada di dalam body terenkripsi sehingga tidak dapat digunakan
• Host tujuan dipilih dengan SNI(Server Name Indication) pada TLS, dan Traefik serta berbagai web server/proxy menggunakan cara ini
• PROXY protocol milik HAProxy juga didukung untuk input/output
  • Ini adalah cara meneruskan informasi yang hilang ketika pengguna terlebih dahulu mencapai proxy ke service tujuan
  • Dinilai lebih mudah ditangani dari sisi keamanan dibanding header X-Forwarded-... yang lama
  • Service tujuan juga harus mendukung PROXY protocol
  • apache2 dan nginx mendukungnya, dan daftar service yang mendukungnya juga terus bertambah

Kekurangan yang tersisa dalam integrasi autentikasi

• Di nginx, Vouch Proxy dapat digunakan untuk melindungi sebagian service dengan Azure AD, yang sekarang menjadi Microsoft Entra authentication
• Traefik mendukung ForwardAuth yang mirip dengan metode autentikasi nginx
• Vouch Proxy belum berjalan di Traefik dan issue terkait masih terbuka
• Menjalankan instance Keycloak sendiri dan mengintegrasikannya dengan AAD untuk digunakan pada ForwardAuth memungkinkan, tetapi beban konfigurasi awal, menjaga keamanan, dan update cukup besar
• traefik-forward-auth sering direkomendasikan, tetapi dinilai sulit digunakan karena update terakhirnya pada Juni 2020 dan membutuhkan update dependency
• Pengalaman sebelumnya dengan oauth2-proxy kurang baik, dan jika menaruh proxy lagi di belakang proxy, konfigurasi HTTP/2・HTTP/3, timeout, ukuran body, dan WebSocket harus disesuaikan di setiap proxy perantara sehingga kemungkinan error meningkat
• Menurut update 2024-05-06, oauth2-proxy juga dapat diintegrasikan melalui HTTP API
  • Mendukung auth_request nginx
  • Mendukung ForwardAuth Traefik
  • Cara ini tampak sebagai pilihan yang mendekati konfigurasi yang diinginkan

Pemblokiran user agent dan IP

• Ada situasi ketika service internal tidak ingin diarsipkan di archive.org
• robots.txt dan header serupa tidak efektif untuk memblokir Archive.org; cara memblokir crawler adalah memblokir user agent archive.org_bot atau memblokir rentang IP
• Untuk memblokir user agent atau alamat IP di Traefik, diperlukan plugin pihak ketiga, bukan fitur bawaan
  • Plugin pemblokiran user agent
  • Plugin deny IP
• Plugin pihak ketiga perlu diperhatikan saat update dan dapat menciptakan kerentanan keamanan, sehingga kurang disukai
• Dengan middleware IPAllowList, dimungkinkan mengizinkan semua IP selain IP yang ingin diblokir
  • Perhitungan rentang IP juga memungkinkan
  • Tidak lebih buruk daripada memblokir langsung, tetapi kurang elegan karena sulit mengetahui rentang mana yang diblokir hanya dengan melihat subnet yang tersisa

Struktur contoh konfigurasi

• Contohnya dibagi menjadi /etc/traefik/traefik.yml dan /etc/traefik/dynamic.yml
• Konfigurasi statis mengatur hal berikut
  • Entrypoint :80 dan :443
  • Redirect endpoint HTTP ke HTTPS tanpa pengecualian
  • Penerbitan sertifikat Let’s Encrypt dengan TLS challenge
  • Pemantauan file konfigurasi dinamis /etc/traefik/dynamic.yml
• Konfigurasi dinamis mencakup hal berikut
  • Routing TCP TLS Passthrough untuk cloud.xx.xyz
  • Penerusan ke service 10.33.1.2:4433 pada host lain
  • Aktivasi PROXY protocol version 2
  • Proxy untuk git.xx.xyz ke lokal http://127.0.0.1:3000 setelah penghentian TLS
  • Middleware yang me-redirect https://xx.xyz/redirmepls ke https://google.com
  • Middleware yang menambahkan header X-Robots-Tag: noindex, nofollow, nosnippet, noarchive

[GN⁺]

Komentar Hacker News

• Traefik lumayan bagus, tetapi mengalami masalah mengerikan yang sama seperti Ansible. Dokumentasi dan tulisan tentangnya banyak, tetapi justru sulit menemukan hal yang benar-benar dibutuhkan
  Saya sudah memakainya sejak v1, tetapi masih sering tersesat di dokumentasi dan jadi sangat frustrasi. Untuk proyek kecil saya cenderung memakai Caddy, karena dokumentasinya tidak seburuk Traefik
  Untuk para penulis dokumentasi teknis: dokumentasi yang berpusat pada contoh hanya bagus untuk pemula yang sekadar membaca sekilas. Bagi orang yang sudah akrab dengan produknya, yang dibutuhkan adalah dokumentasi referensi dan daftar yang lengkap, bukan penjelasan field yang tersebar di 10 halaman tutorial. Jangan hanya fokus pada prosedur onboarding; sesuaikan juga untuk orang yang memakai produk itu setiap hari
  Ini bagian yang paling mengganggu, alasan saya jadi sangat tidak suka Ansible, dan Traefik juga mirip walau tidak separah itu

  • Setuju. Akan bagus untuk semua orang kalau kerangka kerja dokumentasi seperti https://diataxis.fr lebih dikenal luas
  • Hal yang baru-baru ini membuat saya kesal dalam kategori ini adalah OpenTelemetry. Halamannya ribuan, tetapi hampir tidak ada petunjuk nyata tentang cara menyelesaikan alur kerja dasar yang umum
  • Salah satu masalah dari hal-hal yang bisa disebut bahasa keluarga interpreter YAML adalah bahwa YAML itu sendiri adalah sebuah bahasa, tetapi dokumentasi interpreter umumnya tidak mendokumentasikan bagian itu
    Mereka berasumsi Anda hanya akan melakukan tugas yang sangat sederhana pada struktur data yang sangat datar, padahal kenyataannya kebanyakan tidak begitu. Untuk benar-benar memakai bahasa seperti ini dengan baik, Anda harus memahami seluruh kumpulan aturan implisit tentang cara menulis YAML, tetapi dokumentasinya hampir tidak pernah menyinggung itu
    Ada dokumentasi konfigurasi spesifik untuk tiap modul, tetapi hampir tidak pernah jelas bagaimana memakai konfigurasi standar, bagaimana menangani data yang dikembalikan, atau menggabungkannya dengan sesuatu yang sedikit lebih kompleks. Rasanya seperti dilempari belasan contoh satu paragraf untuk tiap item seperti setumpuk bahan, lalu disuruh memanggang kue
    Di berbagai sistem interpreter YAML yang pernah saya pakai, pengalamannya hampir selalu sama; saya baru bisa menyelesaikan pekerjaan setelah melewati ratusan ribu baris YAML, tetapi dokumentasinya nyaris tidak lebih berguna dari sekadar daftar konfigurasi
  • Ansible memang membuat Anda terus-menerus membuka dokumentasi
    Meski begitu, saya menemukan alur kerja yang lumayan bagus dengan memakai ansible-doc, dan alias yang sering saya pakai adalah alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'
    Saya biasanya mulai dengan adls untuk mencari perintah yang relevan dengan cepat, lalu memeriksa dokumentasinya dengan ad, dan hampir selalu langsung lompat ke akhir (G) untuk melihat contohnya. Biasanya jawaban yang saya butuhkan ada di sana
    Menulis skrip Ansible sangat bergantung pada dokumentasi, jadi menurut saya seharusnya dalam keadaan default pun proses pencarian seperti ini didukung lebih baik, dan ada antarmuka yang memungkinkan pencarian cepat tanpa harus membuat banyak alias
  • Pydantic juga masuk kategori ini bagi saya. Pengelolanya berpendapat seharusnya hanya ada satu sumber informasi dan menolak membuat dokumentasi referensi API
    Tentu itu proyek mereka, tetapi setiap kali saya mencari satu metode dari sebuah objek, saya harus mengubek-ubek halaman prosa yang panjang. Kadang membaca source code malah lebih mudah

• Saya telah menggunakan Traefik di production selama 2 tahun. Dulu saya memakai NGINX, tetapi memutuskan pindah ke Traefik karena integrasi otomatis Let's Encrypt, dan saya menyesali keputusan itu
  Dokumentasi Traefik sulit dipahami oleh saya dan tim. Rewel, dan berperilaku aneh tanpa log yang memadai
  Misalnya, ketika mencoba membuat ulang sertifikat, kadang gagal secara intermittent lalu production down tanpa kejelasan kapan akan pulih. Saya sedang kembali ke NGINX

  • Dalam hal seperti ini, NixOS benar-benar sangat membantu. Anda bisa mengaturnya hanya dengan menambahkan beberapa baris ke configuration.nix, dan di balik layar menggunakan lego(1) dan letsencrypt
    security.acme = { acceptTerms = true; defaults.email = "[e-mail]"; 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"; };
    Konfigurasi dengan nginx sepertinya juga cukup mirip. https://github.com/go-acme/lego
  • Saya juga pindah dari NGINX ke Traefik karena dukungan bawaan untuk DNS challenge dan sertifikat wildcard. Saya menghabiskan berjam-jam untuk menerapkannya ke domain yang dipakai di kantor, dan meskipun menggunakan konfigurasi yang sama persis yang bekerja sempurna di rumah, di praktiknya tidak melakukan apa pun
    Registrar domain yang sama, API yang sama, pengaturan Docker yang sama, dan semua log sudah dinyalakan, tetapi tetap tidak ada informasi kenapa sertifikat tidak dibuat. Seolah-olah bahkan tidak pernah mencoba, lalu begitu saja kembali ke sertifikat default yang dibuat otomatis
    Setelah dua sesi troubleshooting dan beberapa jam mencari-cari, saya menyerah dan terpaksa menggunakan file sertifikat self-signed. Benar-benar membuat frustrasi karena tidak ada informasi sama sekali tentang kenapa gagal, lalu diam-diam berpindah ke perilaku fallback
    Secara keseluruhan, ini adalah masalah terbesar Traefik bagi saya. Saat berfungsi, Traefik sangat bagus, tetapi saat tidak berfungsi, selalu sulit untuk troubleshooting atau menemukan informasi yang dibutuhkan di dokumentasi. Di kantor, kami berencana mulai memakai Traefik di production sekitar akhir tahun, jadi saya berharap bisa lebih akrab dengan Traefik sebelum itu
  • Jika butuh API gateway, saya biasanya langsung memakai reverse proxy bawaan Go. Mudah diubah sesuai bentuk yang dibutuhkan, dan juga mudah menemukan library untuk tugas umum seperti CORS, rate limiting, dan retry
    Bagian terbaiknya adalah tidak ada bahasa konfigurasi. Tinggal pakai Go
  • Mungkin Anda sudah tahu, dan mungkin juga tidak cocok, tetapi ada cukup banyak kontainer pendamping Docker untuk mengotomatisasi sertifikat Let's Encrypt bagi kontainer Docker nginx
  • Saya juga mengalami banyak masalah serupa saat pertama kali memakai Traefik. Misalnya, saya menggunakan validasi TLS-01, dan kalau record DNS belum disiapkan sebelum konfigurasi diterapkan, itu sangat membuat stres. Rasanya juga sangat menjengkelkan karena jumlah log yang kurang memadai
    Belakangan saya mengetahui bahwa jika DNS tidak dikonfigurasi dengan benar, setelah upaya validasi gagal sebanyak N kali, Let's Encrypt akan menolak validasi TLS-01 lagi untuk sementara waktu, dan masalah yang Anda alami terdengar seperti jenis masalah itu
    Setelah pindah ke validasi DNS-01, pengalaman saya mendadak jadi jauh lebih baik. Anda juga bisa membuat sertifikat untuk layanan yang tidak diekspos secara publik, dan orkestrasi yang dibutuhkan jauh lebih sedikit dibanding metode TLS-01
    Jika penyedia DNS Anda normal, bahkan saat ada masalah pun kemungkinan besar Anda akan menerima error API sebelum Let's Encrypt memverifikasi record, dan status gagal akan terjadi jauh lebih awal daripada backoff kegagalan pemeriksaan dari Let's Encrypt. Sekarang saya hampir mantap hanya akan memakai validasi berbasis DNS-01 untuk Let's Encrypt, entah menggunakan Traefik, Caddy, Nginx, atau reverse proxy lain, dan jika memang harus memakai TLS-01, saya pasti akan memastikan sejak awal dengan Staging API bahwa semuanya sudah benar
    Sebagai catatan, jika Anda membuat sertifikat Let's Encrypt Staging di Traefik, tidak ada cara yang bagus untuk membatalkan sertifikat itu. Anda harus mengedit ACME JSON untuk menghapus sertifikat lalu me-restart Traefik agar perubahan diterapkan. Mungkin SIGHUP juga bisa, tapi saya belum mencobanya
    Secara keseluruhan ada banyak silent failure dan perilaku aneh, tetapi rasa sakit terbesar adalah karena error dari layanan dependensi menjadi tidak transparan

• Saya memakai Caddy ketimbang Traefik. Menurut saya, mengelola Caddyfile jauh lebih mudah daripada konfigurasi YAML Traefik, dan saya memelihara Caddyfile terpisah untuk deployment lokal, production, dan on-premise
  Ada banyak plugin yang bagus, dan kami memakai plugin coraza WAF untuk Caddy, yang berjalan dengan baik

  • Dalam setup self-hosting, saya pindah dari Traefik ke Caddy dan caddy-docker-proxy
    Semua fitur yang saya butuhkan ada, tetapi jauh lebih sederhana
    https://github.com/lucaslorentz/caddy-docker-proxy
  • Saya suka Caddy, tetapi saya juga berharap dokumentasi deployment production-nya lebih baik. Terutama ada terlalu banyak pertanyaan tanpa jawaban tentang praktik terbaik untuk storage dan manajemen konfigurasi
    Hal-hal seperti bagaimana storage lokal harus ditangani saat memakai storage eksternal. Katanya bisa diperlakukan sebagai stateless, tetapi mungkin juga tidak
    Pada akhirnya Anda hanya bisa berharap orang yang membuat modul yang dibutuhkan benar-benar paham. Di sana pun tidak ada standar dokumentasi. Maintainer perlu menahan modul acak yang menyediakan fungsi inti tetapi dokumentasinya nol, misalnya backend storage S3
  • Jika Anda tidak butuh trik kompleks seperti service discovery atau autoscaling, atau bisa menanganinya sendiri dengan skrip, silakan lewati Traefik, Docker Swarm, Kubernetes, dan sebagainya, lalu langsung pakai Caddy. Caddy benar-benar bisa melakukan sebagian besar hal dan melakukannya dengan baik

• Jika kebutuhannya sederhana seperti beberapa host Docker dan puluhan kontainer, rasanya sulit melihat alasan memakai Traefik dibanding nginx. Saya memakai https://github.com/NginxProxyManager/nginx-proxy-manager, jadi apakah Traefik benar-benar memberi keuntungan pada skala sekecil ini?

  • Menurut saya https://github.com/caddyserver adalah pilihan terbaik di sini. Ia menangani sertifikat SSL secara otomatis, sangat ringan, dan sintaks konfigurasinya sangat jelas
  • Saya suka hot reload di Traefik. Jika ingin menyembunyikan layanan, yaitu aplikasi yang diproksikan, menambahkan route baru, atau dalam istilah Traefik, router, atau menambahkan middleware seperti autentikasi dasar, pengalihan HTTPS, atau manipulasi header, cukup taruh file dan perubahan akan diterapkan otomatis. Tidak perlu memuat ulang Traefik atau virtual host-nya
    Sebenarnya saya juga tidak suka sintaks nginx dan Traefik terlihat lebih menarik. Awalnya saya masuk karena pembaruan Let's Encrypt dan kontainer, lalu terus memakainya karena cara konfigurasinya
  • Kalau konfigurasi yang sudah dimiliki bekerja dengan baik, menurut saya tidak ada manfaat yang cukup untuk mengganti
    Saya mungkin baru akan mempertimbangkan pindah saat membutuhkan fitur yang disediakan Traefik tetapi tidak ada di Nginx
  • Saya juga memakai NginxProxyManager dan punya 8 host, tapi saya masih belum melihat jawaban yang menjelaskan keuntungan caddyserver atau traefik dibanding NPM
  • Setuju. Konfigurasi Nginx itu mudah dan setelah sekali benar bisa langsung dilupakan. Lagi pula kebanyakan orang hanya menyalin-tempel dari konfigurasi lain yang sudah dimiliki
    Certbot ada di mana-mana dan mendukung lebih banyak skenario, jadi agak aneh kalau Let's Encrypt otomatis dijadikan nilai jual. Nilai jual Traefik dan Caddy tidak terasa bagi saya karena bukan membuatnya lebih mudah dibanding alternatif yang sudah didukung luas

• Beberapa minggu lalu saya memilih reverse proxy dan akhirnya memutuskan memakai Caddy karena kesederhanaannya. Meski begitu, penemuan kontainer otomatis dan referensi label di Traefik memang cukup bagus, dan Caddy juga punya plugin untuk melakukan hal yang sama
  Saya sudah membaca artikelnya, tetapi saya masih belum yakin apakah ada hal yang membuat Traefik lebih baik daripada Caddy untuk saya. Mungkin ada bagi orang lain, jadi saya ingin mendengar pendapatnya

• Fakta bahwa Traefik secara bawaan sudah dikonfigurasi di K3s juga patut diperhatikan. Berkat itu, K3s menjadi cara tercepat untuk menyalakan klaster K8s untuk pengujian, dan memungkinkan klaster diperlakukan seperti ternak
  Cukup tambahkan deployment dan layanan terkait sebagai NodePort, lalu Anda bisa mengakses aplikasi tanpa perlu memikirkan ingress controller
  Saya menyalakan klaster K3s dengan skrip shell, lalu menguji aplikasi yang ditentukan lewat argumen posisi saat dibutuhkan. Untuk itu saya memanfaatkan registry kontainer sementara dari ttl.sh. Ketika skrip yang sama selesai, klasternya juga dihapus

• Saya sedang mempertimbangkan memindahkan reverse proxy self-hosted saya ke Traefik. Berbeda dengan penulis, saya menjalankan workload yang dikontainerkan dengan Docker Compose, dan saat ini memakai Caddy bersama plugin caddy-docker-proxy yang sangat bagus
  Saat ini yang saya dapatkan adalah reverse proxy berbasis konfigurasi label Docker, deteksi otomatis workload baru, sertifikat TLS, dan konfigurasi DNS otomatis melalui plugin caddy-dynamicdns. Bahkan jika ISP memberi IP berbeda, saya tidak terlalu perlu khawatir kehilangan akses
  Namun setiap kali workload baru ditambahkan atau di-restart, seluruh Caddy ikut di-restart sehingga akses terputus sementara. Caddy tidak bisa menyerahkan koneksi yang sudah ada ke instans baru
  Selain itu, penggunaan sertifikat wildcard belum cukup sederhana. Saya memakai sertifikat wildcard karena tidak ingin semua workload terekspos ke dunia lewat log transparansi sertifikat, tetapi dengan begitu saya tidak bisa memakai sintaks Caddyfile sederhana yang menggunakan sertifikat per hostname. Saya tahu ini sedang dikerjakan di Caddy, tetapi untuk saat ini memang begitu
  Bagaimanapun, saya pernah memakai Traefik di lingkungan k8s dan hasilnya cukup baik, jadi saya berniat mencobanya juga untuk penggunaan pribadi. Meski begitu, saya harap hal ini tidak membuat orang jadi tidak mencoba Caddy. Caddy juga benar-benar bagus

  • Saya memakai Caddy untuk hal seperti host dengan tujuan tunggal, tetapi untuk masalah yang Anda gambarkan, saya 100% akan memilih Traefik. Saya benar-benar memakainya untuk ingress klaster k8s saya, dan di lingkungan pengembangan saya juga menjalankannya agar bisa memakai localtest.me bersama hostname
    Layak dicoba sekali. Keduanya hebat di ranah yang berbeda
  • Saya memakai rootless Docker Compose + Traefik. Alasannya, sertifikat wildcard benar-benar bisa dibuat tanpa rasa sakit. Saya memang memakai server DNS sendiri dan menggunakan RFC2136 DDNS untuk tantangan DNS Let's Encrypt
    Sebenarnya plugin tidak diperlukan. Saya punya satu playbook Ansible untuk menyiapkan semua ini di VM, termasuk membuat template file compose, dan playbook lain untuk menghapus semuanya dari server kecuali data dan mount. Untuk backup saya memakai skrip kustom dan restic, yang bisa mencadangkan file, beberapa DB, dan sebagainya ke berbagai lokasi
    Dulu saya pernah menerapkan k3s, tetapi sadar bahwa itu terlalu berlebihan dan terlalu rumit untuk self-hosting. Saya cuma ingin bisa deploy dengan cepat dan tidak perlu menangani sertifikat secara manual
  • Saya belum pernah memakai Caddy dan menggunakan Traefik, tetapi saya menemukannya lewat properti Docker untuk konfigurasi dan perpanjangan otomatis sertifikat TLS. Saya kurang tahu soal dynamic DNS dan tidak memakainya di Traefik. Kalau saya ingat dengan benar, menambah atau menghapus kontainer tidak memerlukan restart
  • Saya pernah memakai caddy-docker-proxy di production, dan saat memuat konfigurasi baru, Caddy tidak memutus koneksi
    Baru saja saya cek lagi secara lokal, dan itu bekerja dengan baik
  • Itu batasan yang sangat besar. Saya belum pernah mendengar reverse proxy yang harus restart dan memutus koneksi hanya untuk memperbarui konfigurasi. Biasanya itu justru salah satu hal pertama dan paling mendasar yang diperhatikan dalam desain server seperti itu

• Saya sudah banyak memakai Traefik, tetapi saya lelah harus mengelola label docker-compose, lapisan, dan begitu banyak baris hanya untuk menaruh satu reverse proxy. Lalu saya menemukan Caddy dan tidak pernah menoleh lagi
  Sepertinya saya memang bukan target pengguna Traefik. Yang saya butuhkan hanya reverse proxy dengan HTTPS aktif atau lapisan autentikasi dasar. Di Caddy, keduanya cukup satu baris, sangat ringkas, dan tidak ada lagi lapisan yang sampai sekarang masih tidak saya pahami

• Selama beberapa tahun saya memakai Traefik untuk semua self-hosting saya.
  Namun, penemuan dinamis dan fitur label Docker terlalu merepotkan, dan debugging-nya menyebalkan, jadi saya tinggalkan.
  Sebagai gantinya, saya membuat file konfigurasi statis dengan mesin templat. Hampir semua layanan hanya kombinasi host/target/port, jadi sangat mudah membuat bagian yang diperlukan, dan selain penanganan TLS, juga tidak ada middleware rumit. Penulis artikel yang ditautkan tampaknya juga memilih jalan yang sama.
  Konfigurasinya dibuat dengan skrip Ansible lalu disalin ke mesin tempat Traefik berjalan, dan Traefik memantau direktori tempat file itu berada lalu otomatis memuat ulang saat ada perubahan. Selama ini bekerja sangat baik.

• Kami memakai Traefik bersama container di production, dan hal yang paling saya sukai adalah konfigurasinya dibawa lewat label container. Jadi hampir tidak pernah perlu mengubah konfigurasi Traefik itu sendiri.
  Kekurangan terbesarnya adalah mencari tahu cara melafalkan namanya. Sepertinya dibaca seperti traffic biasa, tapi saya terus ingin menyebutnya seperti “trey-feek”.

  • Sangat setuju soal pendekatan label. Saat pertama kali menulisnya memang sedikit lebih sulit karena escaping dan verbositasnya, tetapi cakupan yang harus dilacak berkurang sangat besar.
    Menurut saya kombinasi Traefik dan Docker Compose adalah titik yang bagus untuk self-hosting skala kecil sebelum tumbuh cukup besar untuk pindah ke k8s, terutama jika jumlah server yang dimiliki lebih sedikit daripada jumlah server yang dipakai control plane highly available k8s.
  • Kami juga memakainya di production. Orang mungkin akan menertawakan ini, tetapi memberi nama yang terlihat keren dan unik di atas kertas namun sebenarnya mengerikan adalah kekurangan besar.
    Jumlah cemberut dan tawa yang saya terima dari rekan kerja sangat banyak, dan itu menghambat adopsi serta penggunaan produk.
    Kami menyebutnya “tray-feek” dan itu masih lumayan, tetapi saat berbicara dengan dukungan resmi, mereka bilang pengucapannya sama persis dengan “traffic” biasa. Jadi setiap kali membicarakan proxy itu, kalimatnya jadi seperti “traffic diterima oleh public load balancer, lalu native load balancing milik traffic mengirim traffic ke pod traffic.” Kedengarannya bodoh, dan memang bodoh.
  • Saya cukup mengucapkannya “traffic”. Saya tidak mau ikut campur dalam adu gengsi sialan mereka.
  • Menurut saya kekurangan terbesarnya adalah jika container tidak ada atau tidak sedang berjalan, maka Traefik tidak mengetahui container atau label tersebut.
    Kalau tidak begitu, akan lebih mudah melakukan hal-hal keren seperti halaman maintenance, atau menyalakan container pada permintaan pertama setelah dinonaktifkan.
    Jadi saya sedang berpikir untuk membuat plugin yang tahu lokasi penyimpanan file compose, lalu bisa membacanya langsung dari sana.
  • ae paling dekat dengan y atau hi. Jadi tebakan saya adalah Tryfik, atau kalau tidak Trayfik. Kalau fik bergaya Eropa, mungkin juga feek.