Docker Compose Saja Tidak Cukup

 (blog.tealok.tech)
3 poin oleh GN⁺ 2024-11-15 | 6 komentar | Bagikan ke WhatsApp
  • docker-compose adalah alat untuk mengelola kontainer Docker yang memang menyelesaikan masalah deployment aplikasi yang kompleks, tetapi tidak cukup untuk self-hosting sederhana bagi pasar massal
  • Diperlukan abstraksi tingkat lebih tinggi yang mencakup konsep seperti database SQL, cache lokal, penyimpanan persisten, service discovery, dan manajemen sumber daya

Peran Docker

  • Docker adalah alat yang memopulerkan kontainerisasi, dan sistem host dapat diibaratkan sebagai sebuah kapal.
  • Ada perangkat keras, sistem operasi, dan container runtime, lalu kontainer berjalan di dalam runtime tersebut dan berkomunikasi dengan layanan lain seperti database atau web server.

Peran Docker-compose

  • docker-compose adalah alat untuk menentukan kelompok kontainer yang bekerja bersama, sehingga memudahkan deployment aplikasi self-hosting.
  • Namun, alat ini merusak antarmuka yang terstandarisasi dan memunculkan kembali masalah yang tadinya diselesaikan oleh kontainer.
  • Contoh: Pihole
    • Pihole adalah server DNS yang memerlukan file docker-compose yang kompleks.
    • Pengguna harus mengatur nama kontainer, image, port, variabel lingkungan, volume, fitur tambahan, kebijakan restart, dan lain-lain.
    • Konfigurasi yang kompleks harus dikelola langsung oleh pengguna, dan ini menjadi kekurangan Docker Compose
  • Contoh: Jitsi Meet
    • Jitsi Meet adalah perangkat lunak yang kompleks, dan menghasilkan konfigurasi docker-compose yang mencakup 4 kontainer, 7 volume, 9 port, dan lebih dari 200 pengaturan environment.
  • Contoh: aplikasi self-hosting populer lainnya juga mengalami masalah serupa
    • Ada berbagai aplikasi seperti Authentik, Nextcloud, Immich, Jellyfin, dan Paperless NGX, dan setiap konfigurasi docker-compose masing-masing menggantikan puluhan hingga ratusan perintah docker.
    • Setiap aplikasi dapat menyertakan database, cache, dan HTTP handler sendiri, yang pada akhirnya menyebabkan penggunaan sumber daya yang duplikatif.

Masalahnya

  • docker-compose terlalu fleksibel, terlalu rinci, dan bekerja pada lapisan abstraksi yang keliru.
  • Setiap aplikasi memiliki proses penanganan HTTP, cache, atau database sendiri. Backup database menjadi tanggung jawab operator sistem.
  • Contoh: reverse HTTP proxy
    • Reverse HTTP proxy adalah program yang meneruskan permintaan HTTP masuk ke program lain. Setiap program harus memutuskan sendiri apakah akan menyertakan web server atau tidak.
    • Menyertakan web server
      • Jika web server disertakan, program akan berjalan, tetapi hanya pada port tertentu, dan jika ada banyak kontainer maka port harus dipetakan ulang.
    • Tidak menyertakan web server
      • Jika web server tidak disertakan, sumber daya tidak terbuang, tetapi aplikasi harus dikonfigurasi tanpa antarmuka administrasi.
    • DNS
      • Antarmuka web memiliki alamat, dan jika ingin menggunakan TLS maka diperlukan nama. Jika beberapa layanan dijalankan pada satu host, permintaan harus dirutekan berdasarkan nama domain atau path.
    • Port
      • docker-compose memungkinkan eksposur dan pemetaan ulang port, tetapi pada praktiknya yang dibutuhkan adalah dukungan untuk konfigurasi jaringan yang kompleks.
  • Contoh: database
    • Pada database, semua perubahan file akan dihapus saat kontainer dihapus. Kontainer database harus menambahkan volume untuk menyimpan isi database.
    • N+1=2 atau lebih
      • Untuk membackup database, diperlukan backup offsite. Jika setiap layanan membundel proses server database terpisah, sumber daya komputasi akan terbuang.

Solusi

  • Berpindah ke lapisan abstraksi yang lebih tinggi dan menambahkan semantik yang membedakan jenis kontainer seperti database, reverse web proxy, cache, aset web statis, dan lainnya.
  • Contoh semantik
    • Memperkenalkan format konfigurasi baru untuk menentukan nama aplikasi, build, HTTPS reverse proxy, dan layanan cache.
  • Solusi #1
    • Setiap program dapat meminta reverse proxy, sehingga duplikasi dan pemborosan bisa dicegah. Reverse proxy menyediakan nama DNS dan meneruskan semua path ke program tersebut.
  • Solusi #1.5
    • Menambahkan bagian database untuk meminta database yang mematuhi standar SQL, sementara program mengharapkan hak akses "penuh".
  • Solusi untuk port
    • Setiap program mendapatkan alamat IPv6 sendiri sehingga dapat memakai nomor port standar. Demi keamanan, firewall digunakan agar hanya reverse proxy yang dapat mengakses port tersebut.

Tealok - container runtime baru

  • Tealok adalah container runtime baru yang menyediakan abstraksi lebih tinggi dan antarmuka yang terstandarisasi.
    • Sertifikat TLS, pengaturan reverse proxy, catatan DNS, manajemen backup, dan lainnya ditangani secara otomatis.
    • Dengan memanfaatkan IPv6, setiap kontainer memiliki alamat IP independen dan dapat menggunakan nomor port standar.
    • Pengembang aplikasi dapat melakukan deployment aplikasi melalui antarmuka standar tanpa konfigurasi yang rumit.
  • Bagi operator, ini memberikan praktik terbaik yang konsisten, mengurangi pemborosan sumber daya, dan meringankan beban pengelolaan.
  • Bagi pengembang, ini menyederhanakan cara deployment dan mengurangi beban pengambilan keputusan.
  • Pengguna dapat dijamin mendapatkan kepemilikan data dan kemandirian dari cloud computing.

Bacaan terkait

6 komentar

 
luminance 2024-11-15

Saya masuk ke tealok dan melihat kondisinya belum layak jadi alternatif, bukan?
 
savvykang 2024-11-15

Akan lebih bagus kalau runtime-nya juga dihapus.
 
tujuc 2024-11-15

Saya masih merasa tetap perlu memakai docker-compose untuk menyiapkan lingkungan operasional dan masuk ke sana, tetapi...

Sulit untuk setuju dengan gagasan, berdasarkan pengalaman di lingkungan khusus miliknya sendiri, bahwa itu salah lalu membuat sesuatu yang baru.. hahaha

Ini isi yang mudah disalahpahami hahaha...

Karena saat hanya melihat judulnya, saya sempat berpikir, 'Oh, memang tidak enak sekali kalau dipakai di lingkungan pengembangan....' hahaha
 
ilbanin00 2024-11-15

Saya rasa sejak awal sudah keliru jika mencoba menggunakan docker compose untuk tujuan seperti yang dibahas di artikel.
 
tujuc 2024-11-15

Saya agak setuju dengan perkataan Anda, tetapi saya rasa pendekatannya tidak salah.
Itu mungkin yang terbaik dalam lingkungan yang bisa mereka lakukan :)
 
GN⁺ 2024-11-15
Komentar Hacker News

  • Ada solusi sederhana untuk masalah pemetaan port dan backup volume data

    • Dengan menggunakan file docker-compose terpisah untuk lingkungan pengembangan, konfigurasi dapat didefinisikan berbeda untuk tiap lingkungan
    • Bisa menulis skrip Bash sederhana untuk backup lalu mengunggahnya ke S3

  • Sebagai orang yang melakukan self-hosting di server pribadi menggunakan Docker, saya menilai positif fleksibilitas konfigurasi Docker

    • Penyiapan awal memang memakan waktu, tetapi setelah itu menjadi mudah dikelola
    • Menambahkan layanan baru hampir tidak memerlukan waktu, dan untuk keamanan saya membuat pengguna non-root untuk tiap layanan
    • Menggunakan jaringan macvlan untuk memberi tiap container alamat IP dan MAC yang unik
    • Menggunakan Nginx Proxy Manager untuk mengelola reverse proxy, dan tidak ada masalah meski menjalankan beberapa instance sebagai basis data

  • docker-compose terutama digunakan untuk pengembangan atau penggunaan pribadi, dan V2 adalah plugin yang terintegrasi ke Docker, berbeda dari V1

  • Di lingkungan produksi, lebih baik menggunakan Kubernetes, sedangkan docker-compose cocok untuk pengembangan lokal

  • docker-compose adalah produk untuk self-hosting skala kecil, ditujukan bagi orang yang tidak memiliki latar belakang teknis

    • Saya ragu bahwa beralih ke TOML akan membuat self-hosting menjadi lebih mudah

  • Menulis program untuk mengendalikan Docker ternyata lebih sederhana daripada yang dibayangkan, dan masalahnya bisa diselesaikan dengan skrip Python

  • Sedang mengembangkan agar cluster Kubernetes bisa digunakan semudah Heroku dengan canine.sh

    • Sedang dipakai untuk proyek pribadi, dan dapat meng-host beberapa aplikasi dengan biaya murah

  • Menarik bahwa Tealok sedang mengembangkan alternatif untuk docker-compose

  • Saya menganggap docker-compose, Kubernetes, dan Helm sebagai lapisan abstraksi yang keliru

    • Ada banyak upaya untuk mengembangkan berbagai cara menjalankan dan menghubungkan container

  • Saya bingung dengan klaim bahwa docker-compose adalah lapisan abstraksi yang keliru

    • Tampaknya ada harapan akan antarmuka tingkat tinggi untuk menyelesaikan masalah tertentu
    • Masalah pembuatan instance duplikat bukan isu besar bagi sebagian besar aplikasi
    • Memaksa aplikasi dirancang dengan cara tertentu hanya akan bekerja baik dalam situasi tertentu