Belajar Samba - Samba di Docker/Kubernetes

#Pendahuluan

Selama 18 episode, Samba berjalan di atas server "telanjang". Episode 19 menyentuh realitas infrastruktur modern: container dan Kubernetes. Menjalankan Samba di container bukan sekadar gaya — ia memberi reproducibility (konfigurasi di image, bukan di mesin) dan orkestrasi. Tapi Samba adalah layanan stateful: data dan config harus hidup di luar container. Memahami di mana "state" itu berada adalah inti episode ini.

#Samba di Docker

#Image yang Tersedia

Dua image community yang paling populer:

• linuxserver/samba: image berbasis Alpine dengan environment variables (USER, PASS, SHARE) — cocok untuk NAS sederhana.
• dperson/samba: image fleksibel dengan argumen baris perintah (-u user -p pass -s "share;/path;yes;no;no") — mudah di-script.

Keduanya menyediakan smbd + nmbd siap pakai. Contoh dengan dperson/samba:

docker run -d --name samba \
  -p 445:445 -p 139:139 \
  -v /srv/data:/data \
  -v samba-config:/config \
  dperson/samba -u arman -p S3curePass! \
    -s "data;/data;yes;no;no"

Bedah penting:

• -p 445:445 -p 139:139: expose port SMB dari container ke host.
• -v /srv/data:/data: data berbagi file diletakkan di volume host — data tetap ada meski container dihapus.
• -v samba-config:/config: konfigurasi dan state Samba (misal passdb.tdb) di volume bernama.
• -u arman -p ... -s "...": argumen dperson untuk user, password, dan definisi share.

#Samba di Kubernetes

#StatefulSet: Pilihan Tepat

Layanan stateful dengan identitas stabil — nama, hostname, dan storage yang tetap — adalah definisi kasus penggunaan StatefulSet (bukan Deployment, yang stateless dan identitasnya bisa berubah). Skeleton manifest:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: samba
spec:
  serviceName: samba
  replicas: 1
  selector:
    matchLabels: { app: samba }
  template:
    metadata:
      labels: { app: samba }
    spec:
      containers:
        - name: samba
          image: dperson/samba:latest
          ports:
            - containerPort: 445
              name: smb
          volumeMounts:
            - name: data
              mountPath: /data
            - name: config
              mountPath: /config
          args:
            - -u
            - arman
            - -p
            - $(SAMBA_PASS)
          env:
            - name: SAMBA_PASS
              valueFrom:
                secretKeyRef: { name: samba-secret, key: password }
  volumeClaimTemplates:
    - metadata: { name: data }
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests: { storage: 100Gi }
    - metadata: { name: config }
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests: { storage: 1Gi }

Poin penting di manifest ini:

• volumeClaimTemplates membuat PVC terpisah per pod — storage dijamin persisten, dibuat otomatis saat pod dilahirkan.
• Password diambil dari Secret (valueFrom), bukan hardcode di manifest — kebiasaan keamanan yang wajib.
• Dua volume: data (isi share) dan config (state Samba) — keduanya persisten.

#Service: Mengekspos Samba

Samba harus bisa dijangkau klien lewat IP yang stabil — pakai Service dengan port SMB:

apiVersion: v1
kind: Service
metadata:
  name: samba
spec:
  selector: { app: samba }
  ports:
    - name: smb
      port: 445
      targetPort: 445
      protocol: TCP
  type: LoadBalancer

LoadBalancer memberi satu IP eksternal (misal dari MetalLB/cloud LB) yang meneruskan ke pod Samba. Klien cukup tahu \\<IP>\share — sama seperti memakai server fisik.

#Pola yang Benar dan Perangkapnya

#Pola Stateless Container, Stateful Storage

Ringkasan pola yang benar:

• Container = proses Samba yang reproducible (image + args).
• State = data share (/data) dan config/user DB (/config) di volume persisten.
• Konfigurasi dinamis lewat env/secret, bukan edit manual di container.
• Service yang stabil (LoadBalancer/NodePort) mengekspos port 445/139.

#Perangkap Umum

• State di container: user dan password hilang saat pod restart — selalu volume (lihat Callout di atas).
• replicas > 1 untuk HA palsu: multi-pod Samba standalone = konflik lock; gunakan CTDB + RWX bila benar-benar butuh scale.
• Kubernetes probe salah: Samba tidak punya endpoint HTTP; readinessProbe bisa memakai tcpSocket pada 445, bukan httpGet.
• Image :latest: tag latest tidak reproducible; pin versi image di production.
• NetBIOS di cluster: nmbd dan broadcast NetBIOS tidak berjalan baik di overlay network Kubernetes — klien modern via DNS/445 saja.

#Pitfall Khusus Kubernetes

Selain pola di atas, perhatikan:

• hostNetwork vs Service: memakai hostNetwork: true menghindari konversi IP (SNAT) yang bisa memutus koneksi SMB lama, tapi mengikat pod ke satu node. Untuk produksi sederhana, Service + MTU yang benar biasanya cukup.
• MTU mismatch: overlay network dengan MTU berbeda dari storage/klien bisa menyebabkan koneksi SMB lambat — samakan MTU jumbo di seluruh path.
• Backup volume: StatefulSet tidak mem-backup data; pastikan PVC di-backup (misal via snapshot atau Velero — seri learn-velero).

#Penutup

Inti yang harus dibawa pulang:

• Image linuxserver/samba dan dperson/samba menjalankan Samba dengan mudah; state harus di volume, bukan layer container.
• Kubernetes memakai StatefulSet (identitas + storage stabil) dan Service LoadBalancer untuk expose port SMB.
• Password dari Secret; jangan hardcode di manifest.
• replicas > 1 tanpa CTDB adalah HA palsu — konflik lock, bukan ketahanan.
• Pin image version dan siapkan backup PVC sejak awal.

Di episode 20 selanjutnya kita akan membahas performance & monitoring — tuning aio read size, use sendfile, NIC bond, pemantauan dengan smbstatus dan Prometheus node_exporter, serta analisis log. Samba yang cepat dan terpantau adalah Samba yang layak produksi!