Belajar Traefik - Middleware Fundamentals

#Pendahuluan

Middleware adalah salah satu fitur yang membuat Traefik begitu luwes. Bayangkan setiap request yang lewat sebagai pipa: middleware adalah saringan-saringan yang dipasang di sepanjang pipa itu, masing-masing mengubah atau memeriksa isi yang mengalir. Episode 8 memperkenalkan konsep dasar yang akan dipakai semua episode berikutnya di fase ini.

Pemahaman kuncinya ada dua: urutan eksekusi dan sifat dua arah. Middleware berjalan berurutan sesuai urutan pendaftarannya, dan karena middleware membungkus service, response dari backend juga melewati seluruh middleware yang sama. Kesalahan urutan sering kali menghasilkan perilaku yang sulit ditebak — mari kita bangun intuisi yang benar sejak awal.

#Konsep Middleware

#Request Chain dan Response Chain

Ketika request tiba, Traefik menjalankan middleware router secara berurutan: middleware pertama menerima request, memodifikasinya, meneruskannya ke middleware kedua, dan seterusnya sampai service. Ketika service menjawab, response mengalir ke arah sebaliknya melewati middleware yang sama, dalam urutan terbalik:

request :  m1 -> m2 -> m3 -> service
response:  m1 <- m2 <- m3 <- service

Konsekuensi penting: sebuah middleware melihat request di jalur masuk dan response di jalur keluar. Middleware headers misalnya bisa menambah header request di jalur masuk, lalu menambah header response di jalur keluar — keduanya dalam satu definisi.

#Tipe Middleware

• HTTP middlewares: memodifikasi request/response HTTP — sebagian besar episode fase ini.
• TCP middlewares: beroperasi pada level koneksi TCP, misalnya IPWhiteList untuk protokol non-HTTP.
• Plugin middlewares: middleware custom yang ditulis dalam Go — dibahas di episode 29.

#Menempelkan Middleware ke Router

#Named Middleware dan Chaining

Middleware didefinisikan sekali dengan nama, lalu dirujuk oleh router. Dalam Docker, definisi ditulis sebagai label, sedangkan penempelan dilakukan pada label router:

services:
  app:
    image: nginx:alpine
    labels:
      - traefik.enable=true
      - traefik.http.routers.app.rule=Host(`app.localhost`)
      - traefik.http.routers.app.middlewares=auth,headers,compress
      - traefik.http.middlewares.auth.basicauth.users=admin:$apr1$H6uskkkW$IgXLP6ewTrSuBkPqGkHpv5
      - traefik.http.middlewares.headers.headers.customresponseheaders.X-Custom=hello
      - traefik.http.middlewares.compress.compress=true

Router app menjalankan tiga middleware berurutan: auth (autentikasi), headers (tambahan header), lalu compress (kompresi). Urutan dalam daftar middlewares=auth,headers,compress menentukan urutan eksekusi — middleware paling kiri berjalan paling dulu.

#Urutan Eksekusi dan Praktiknya

#Mengapa Urutan Penting

Urutan menentukan hasil akhir. Dua contoh nyata:

• Autentikasi harus pertama: jika compress berjalan sebelum auth, Traefik membuang CPU untuk mengompresi request yang akhirnya ditolak. Letakkan middleware yang "memutuskan" (auth, rate limit) di posisi awal.
• Redirect sebelum modifikasi path: middleware redirectregex mengubah URL, sehingga middleware stripprefix yang menempel padanya bekerja berdasarkan URL baru, bukan lama.

Aturan praktis: decision middleware first, transformation middleware last. Autentikasi, rate limiting, dan circuit breaker sebaiknya berjalan lebih dulu daripada pengubahan header atau kompresi.

#Contoh Rantai Lengkap di File Provider

Struktur yang sama bisa ditulis di file provider (episode 19). Perhatikan bagaimana definisi middleware dipisah dari router, dan router hanya menyebut nama-namanya:

http:
  middlewares:
    api-protect:
      chain:
        middlewares:
          - api-rate
          - api-auth
          - api-headers
    api-rate:
      rateLimit:
        average: 100
        burst: 50
    api-auth:
      basicAuth:
        users:
          - "admin:$2y$05$0UvReaDF8s0BbQpqBFBp8e1gV6Q2Y0hH9o5QyTq3a4j7kLmZxS2C"
    api-headers:
      headers:
        customResponseHeaders:
          X-Content-Type-Options: "nosniff"
  routers:
    api:
      rule: "Host(`api.localhost`)"
      entrypoints:
        - web
      service: api-svc
      middlewares:
        - api-protect

Di sini api-protect adalah middleware tipe chain: sebuah wadah yang memuat tiga middleware lain dan menjalankannya sesuai urutan. Router hanya menyebut satu nama, yaitu api-protect, tetapi secara efektif menjalankan rate limiting, autentikasi, lalu penambahan header. Pola chain seperti ini sangat rapi untuk grup middleware yang dipakai bersama-sama.

#Inline vs Named

Semua contoh di atas memakai named middleware: didefinisikan lalu dirujuk. Ini memungkinkan reuse — middleware yang sama dipakai banyak router. Traefik juga mendukung middleware inline dalam beberapa konteks, namun named jauh lebih mudah dibaca dan dipelihara. Untuk semua episode berikutnya, kita konsisten memakai named middleware.

#Pola Umum Middleware

#Tiga Pola yang Sering Muncul

Sebagian besar konfigurasi produksi Traefik memakai tiga pola ini:

1. Authentication chain: basicauth atau forwardauth dipasang paling depan untuk melindungi resource.
2. Security headers: headers menambahkan X-Frame-Options, X-Content-Type-Options, dan Content-Security-Policy pada setiap response.
3. Request/response modification: stripprefix, addprefix, redirectregex menyesuaikan path dan URL sebelum mencapai backend.

Kita akan membedah pola pertama di episode 9, pola kedua di episode 10, dan pola ketiga di episode 11.

#Penutup

Inti yang harus dibawa pulang:

• Middleware membungkus service dan berjalan dua arah: request dan response.
• Urutan eksekusi mengikuti urutan pendaftaran pada router.
• Decision middleware seperti auth harus dijalankan paling awal.
• Named middleware memungkinkan reuse antar banyak router.
• Tipe middleware: HTTP, TCP, dan plugin.
• Tiga pola umum: authentication chain, security headers, dan path modification.

Di episode 9 selanjutnya kita akan membahas authentication middlewares — BasicAuth dengan htpasswd, DigestAuth, ForwardAuth dengan integrasi Authelia, Authentik, dan OAuth2 Proxy, serta IPWhiteList untuk membatasi akses berdasarkan alamat sumber. Autentikasi adalah tembok pertahanan pertama setiap layanan.