2 poin oleh GN⁺ 2025-03-25 | 1 komentar | Bagikan ke WhatsApp
  • Karena Podman tidak memiliki daemon, dibutuhkan pihak eksekusi yang dapat menaikkan kontainer secara andal setelah server boot, dan Quadlet menyelesaikannya dengan pendekatan file layanan systemd
  • Metode lama podman generate systemd mengharuskan pembuatan kontainer dan file layanan dilakukan terpisah, dan setiap kali file yang dihasilkan diubah, muncul beban penyuntingan manual
  • Quadlet menempatkan pengaturan [Container], [Service], dan [Install] bersama dalam file .container di ~/.config/containers/systemd, sehingga opsi Podman dan perilaku systemd dapat dikelola di satu tempat
  • Pada Podman rootless, agar bisa mulai otomatis saat boot dibutuhkan WantedBy=default.target dan mengaktifkan linger, sementara multi-user.target tidak didefinisikan dalam mode pengguna
  • Dengan memanfaatkan AutoUpdate=registry, dependensi systemd, pengelompokan file per direktori, hingga alat konversi podlet, Quadlet sangat cocok untuk pengoperasian Podman rootless·daemonless

Mengapa Quadlet dibutuhkan

  • Quadlet adalah cara untuk menjalankan kontainer Podman seperti layanan systemd
    • Kontainer dapat dijalankan di latar belakang
    • Kontainer dapat dimulai otomatis setelah server reboot
  • Menjalankan kontainer Podman di bawah systemd sendiri bukan hal baru
    • Sebelumnya digunakan perintah podman generate systemd
    • Perintah ini sekarang menampilkan peringatan deprecation yang menyarankan migrasi ke Quadlet
  • Karena Podman berarsitektur daemonless, dibutuhkan pihak eksekusi yang dapat memulai kontainer tanpa daemon

Ketidaknyamanan metode lama podman generate systemd

  • Metode lama mengharuskan pembuatan kontainer terlebih dulu dengan podman create
    • Contoh kontainer menggunakan image docker.io/library/postgres:16
    • Mencakup -p 5432:5432, mount volume, variabel lingkungan POSTGRES_PASSWORD, dan label io.containers.autoupdate=registry
  • Setelah itu dijalankan podman generate systemd test-db -fn --new untuk membuat file container-test-db.service
  • File layanan yang dihasilkan ditempatkan di ~/.config/systemd/user lalu diaktifkan dan dijalankan dengan perintah berikut
    • systemctl --user enable --now container-test-db
  • Alur ini membuat Anda harus berulang kali melakukan pembuatan kontainer, pembuatan file layanan, pemindahan file bila perlu, dan pengaktifan layanan
  • Jika perintah pembuatan kontainer menjadi panjang, Anda perlu mengelola skrip shell terpisah agar bisa dijalankan lagi nanti
  • Jika ingin menyesuaikan file layanan systemd yang dihasilkan, Anda harus melakukan modifikasi manual setiap kali

Struktur file Quadlet

  • Dalam pendekatan Quadlet, buat direktori ~/.config/containers/systemd lalu letakkan file .container di dalamnya
  • Contoh file test-db.container mencakup elemen berikut
    • [Container]
      • Image=docker.io/library/postgres:16
      • AutoUpdate=registry
      • PublishPort=5432:5432
      • Volume=%h/volumes/test-db:/var/lib/postgresql/data:Z
      • Environment=POSTGRES_PASSWORD=CHANGE_ME
    • [Service]
      • Restart=always
    • [Install]
      • WantedBy=default.target
  • File .container adalah file layanan systemd biasa, tetapi menyertakan seksi [Container] khusus
  • Banyak opsi di [Container] berpadanan dengan opsi baris perintah yang digunakan di podman create
    • Image: image dan tag yang akan digunakan
    • AutoUpdate=registry: berpadanan dengan --label "io.containers.autoupdate=registry"
    • PublishPort: berpadanan dengan -p
    • Volume: berpadanan dengan -v
    • Environment: berpadanan dengan -e
  • Untuk direktori home pengguna, gunakan penentu systemd %h alih-alih ~
  • Restart=always di [Service] membuat kontainer selalu dijalankan ulang kecuali dihentikan secara manual
  • WantedBy=default.target di [Install] membuat kontainer dimulai otomatis saat boot

Pengaturan systemd yang diperlukan pada Podman rootless

  • Pada kontainer rootless, gunakan default.target alih-alih multi-user.target
    • multi-user.target tidak didefinisikan dalam mode pengguna systemd
    • Anda bisa memeriksanya dengan systemctl --user status multi-user.target
    • Dalam mode sistem, bisa diperiksa dengan systemctl status multi-user.target
  • Karena kontainer dijalankan sebagai layanan pengguna systemd, agar kontainer bisa mulai meski pengguna belum login, Anda perlu mengaktifkan linger
    • loginctl enable-linger
  • Jika membutuhkan start otomatis setelah server reboot, mengaktifkan linger adalah wajib
  • Agar systemd menemukan file layanan baru, jalankan perintah berikut
    • systemctl --user daemon-reload
  • Memulai kontainer dan memeriksa statusnya bisa dilakukan baik dari systemd maupun Podman
    • systemctl --user start test-db
    • systemctl --user status test-db
    • podman ps
  • Nama kontainer default berbentuk nama file layanan dengan awalan systemd-
    • Nama kontainer default untuk test-db.container adalah systemd-test-db
    • Ini adalah aturan penamaan untuk menghindari bentrokan
    • Anda dapat menentukannya sendiri dengan opsi ContainerName pada seksi [Container]

Keunggulan operasional Quadlet

  • Quadlet memungkinkan konfigurasi layanan kontainer dikelola dalam satu file
    • Tidak perlu lagi mengelola terpisah skrip pembuat file layanan dan file layanan hasil generasi seperti pada metode lama
  • Anda dapat memakai opsi yang tersedia pada seksi [Unit] dan [Service] milik systemd
    • Misalnya, Anda bisa menentukan perintah yang dijalankan sebelum kontainer dimulai dengan StartExecPre
    • Ini mengurangi kebutuhan untuk mengubah file hasil generasi secara manual di kemudian hari
  • Alih-alih menulis dan men-debug skrip shell, Anda bisa mengoperasikan kontainer dengan berfokus pada file konfigurasi
  • Dependensi antar-kontainer juga lebih mudah dinyatakan dengan cara systemd

Menyatakan dependensi antar-kontainer

  • Jika kontainer aplikasi bergantung pada kontainer database, hubungan itu bisa ditentukan lewat seksi [Unit] milik systemd
  • Kontainer OxiTraffic adalah contoh yang bergantung pada kontainer test-db
    • Tetapkan Requires=test-db.service di [Unit] agar aplikasi hanya dimulai ketika database dimulai
    • Tetapkan After=test-db.service agar kedua kontainer tidak dimulai secara paralel
  • Saat mereferensikan, yang dipakai adalah nama layanan, bukan nama file .container
    • test-db.container: nama file
    • test-db.service: nama layanan
    • systemd-test-db: nama kontainer default
  • Agar aplikasi bisa berkomunikasi dengan database, kedua kontainer perlu menambahkan opsi Network pada seksi [Container], tetapi pembahasan jaringan tidak dibahas di sini

Banyak file dan pengelompokan

  • Quadlet dapat disusun dengan file .container terpisah untuk setiap kontainer
  • Dibanding menaruh seluruh aplikasi multi-kontainer dalam satu file Docker Compose, file per kontainer dapat mengurangi beban kognitif
  • Jika file Docker Compose berisi ratusan baris dan puluhan kontainer, pemeliharaannya bisa menjadi sulit
  • Docker Compose juga mendukung pemisahan ke beberapa file
  • Quadlet dapat menempatkan file unit di dalam direktori di bawah ~/.config/containers/systemd
    • Dalam contoh, direktori oxitraffic dibuat agar file aplikasi dan database bisa diletakkan bersama

Pembaruan image

  • Jika AutoUpdate=registry disetel, Anda dapat memeriksa pembaruan image dengan podman auto-update
  • Jika ada image baru di registry yang kompatibel dengan tag yang sedang digunakan, Podman akan melakukan pull image lalu me-restart kontainer
  • Di Docker, untuk tujuan ini mungkin diperlukan alat seperti Watchtower, tetapi Podman menyediakan fungsi tersebut secara bawaan
  • Tag seperti latest bisa berisiko
    • Pada OxiTraffic, latest bisa saja memuat breaking change dari versi berikutnya
    • Jika memakai latest pada PostgreSQL, versi baru bisa naik ke major version berikutnya, padahal upgrade major PostgreSQL selalu memerlukan migrasi manual
  • Dalam operasional produksi, sebaiknya gunakan tag yang tidak akan berujung pada breaking change
  • Anda juga bisa menjalankan podman auto-update secara manual setiap beberapa hari untuk melihat apa yang berubah, lalu memeriksa apakah kontainer tetap berjalan normal sesudahnya

podman-compose dan alat migrasi

  • podman-compose adalah skrip Python untuk menjalankan file Compose dengan Podman
  • Alasan mengapa ini sulit dianggap sebagai alternatif Docker Compose jangka panjang adalah sebagai berikut
    • Ia merupakan lapisan terjemahan antara spesifikasi Compose dan Podman·systemd, dan tidak memungkinkan penggunaan seluruh fitur systemd
    • Proyek resmi Podman ditulis dalam bahasa terkompilasi seperti Rust atau Go
    • Commit terakhirnya 5 bulan lalu, sehingga tidak tampak dipelihara secara aktif
  • Quadlet lebih selaras dengan desain Podman yang rootless·daemonless
  • Jika ingin mencoba Quadlet dari file Compose, Anda bisa menggunakan podlet
    • Ini adalah alat Rust yang dapat membuat file Quadlet dari perintah Podman atau file Docker Compose

Bacaan lanjutan

1 komentar

 
GN⁺ 2025-03-25
Opini Hacker News
  • Quadlet adalah salah satu hal terbaik yang muncul dari Podman, dan sangat direkomendasikan bagi siapa pun yang penasaran dengan Podman atau ingin beralih ke workload berbasis container
    Container bisa disisipkan dan dikelola seperti layanan sistem biasa, tanpa perlu mempelajari lapisan orkestrasi terpisah agar semuanya berjalan bersama, atau bergantung pada resource non-container
    Cukup tulis unit systemd seperti yang sudah biasa digunakan, sementara pembaruan otomatis atau restart/notifikasi layanan saat gagal menjadi bonus tambahan
    Cara mencoba melakukan hal serupa dengan Docker biasanya berarti mengakali daemon Docker lewat perintah run raksasa, yang sering meninggalkan layanan dan container hantu; Quadlet jauh lebih rapi, dan konfigurasinya juga berada bersama lokasi unit systemd seperti /etc/systemd/, .config/systemd, /usr/local/lib/systemd, sehingga mudah dicadangkan
    Namun ini bukan jawaban untuk docker-compose dalam pengembangan lokal, dan tim Podman juga tampaknya tidak terlalu tertarik pada area itu
    Container pengguna bagus untuk infrastruktur pengujian lokal jangka panjang seperti database latar belakang, tetapi terlalu merepotkan untuk loop umum kompilasi → docker compose up → pengujian → docker compose down
    Jawaban realistisnya adalah Quadlet .kube (Kubernetes play) atau memakai docker compose terhadap socket Podman
    Saya sangat menyukainya sampai-sampai selama beberapa bulan terakhir membuat tool GitOps untuk mengelola Quadlet di waktu luang, dan ini terasa seperti cara yang tepat untuk mengelola server yang dikontainerisasi
    Penting bahwa [0] bukan podman-compose. Tulisan itu juga menyebut podman-compose kurang bagus dan kurang dikembangkan. Podman mengimplementasikan sebagian besar spesifikasi compose, sehingga dalam kebanyakan situasi Anda bisa memakai docker compose
    Kemungkinan besar orang-orang yang mencobanya saat RH pertama kali mulai mendorong Podman jadi pergi karena ketidakjelasan Podman 3 dan pengalaman buruk dengan podman-compose

    • Saya ingin mengikuti cara yang lebih dekat dengan gaya RH, jadi mencoba memakai Quadlet dan podlet, tetapi pengalaman berpindah dari docker compose di atas Podman sangat buruk
      Setelah mengubah berbagai flag, menaikkan versi, dan mengikuti alur saat podlet sendiri menyarankan beralih ke tool lain, semuanya berubah menjadi lubang kelinci tanpa akhir
      Pada akhirnya systemd saya hanya menjalankan podman compose up
      Saya penasaran apa keunggulan Quadlet dibandingkan membiarkan compose melakukan tugasnya
      Sebagai catatan, Podman berjalan sebagai pengguna saya, tanpa daemon sama sekali
    • Trik untuk pengembangan adalah mengaktifkan socket Podman, mengaktifkannya pada level pengguna jika memakai container rootless, lalu memakai docker-compose mandiri
    • Di Windows atau Mac, systemd tidak bisa dipakai, jadi pada akhirnya yang tersisa hanya podman compose
  • Baru-baru ini saya menemukan Quadlet dan membangun seluruh homelab berbasis atomic OS serta Quadlet rootless, dan saya sangat merekomendasikannya
    Aktivasi socket systemd juga memungkinkan; misalnya, Anda bisa membuat socket systemd http/https dan mengaktifkan Traefik secara otomatis, seperti ssh.socket dan podman.socket masing-masing mengaktifkan sshd.service dan podman.service
    Ini hampir seperti penyelamat, karena pada konfigurasi rootless praktis merupakan satu-satunya cara untuk mempertahankan IP asal. Podman/Docker rootless biasanya tidak dengan mudah mengizinkan pelestarian IP asal tanpa kelemahan besar
    https://github.com/savely-krasovsky/homelab

    • Penasaran berapa lama waktu yang dibutuhkan sampai Traefik aktif
  • Quadlet adalah alternatif yang baik untuk penggunaan docker compose yang “menjalankan semua container yang saling bergantung dalam lingkungan mirip produksi”
    Namun untuk kegunaan lain docker compose, yaitu sisi pengembangan, saya berharap bisa lebih baik
    docker compose bisa menjalankan bersama-sama database, Redis, OpenSearch, dependensi lain, proxy nginx, dan container pengembangan yang me-mount .:/app sebagai volume, mematikannya bersama-sama, serta memasukkan docker-compose.yml ke repositori
    Quadlet menyuruh semua file diletakkan di ~/.config/containers/systemd, jadi tidak lagi terisolasi per proyek, dan juga tidak nyaman untuk di-check-in dan dibagikan dengan developer lain. Selain itu, mereka juga harus memakai Podman
    Kebanyakan orang masih memakai Docker, dan di lingkungan pengembangan ter-hosting seperti Codespaces pun Docker disediakan
    Karena itu kami memakai docker compose dengan file YAML yang di-check-in. Karena saya memakai Podman, saya harus menambahkan :Z secara manual ke semua volume, tetapi Docker biasa tidak bisa menanganinya
    Akan bagus jika ada alternatif docker compose untuk pengembangan, tetapi Quadlet tampaknya tidak terlalu cocok

    • Dengan memakai podman-compose --in-pod=1 systemd -a create-unit, Anda bisa membuat service podman-compose@, lalu mendaftarkan file compose.yml bersama $name dengan podman-compose systemd -a register
      Dengan begitu pod berbasis file compose bisa dikelola sebagai podman-compose@$name.service, dan juga bekerja sepenuhnya rootless
    • Dalam kasus ini, yang dicari adalah Podman pod, dan saya akan mengorkestrasikan seluruhnya dengan Ansible lalu membagikan playbook Ansible kepada semua orang agar dijalankan secara lokal
    • systemd-run memungkinkan menjalankan service systemd sementara berdasarkan perintah arbitrer
      Jika diperlukan, ia membuat unit sementara yang rapi dan mengikuti aturan cakupan systemd, bahkan termasuk timer
      [1] https://www.freedesktop.org/software/systemd/man/systemd-run...
    • Menurut saya Quadlet pada umumnya lebih dekat untuk deployment. Jika mencari alternatif compose, lebih baik melihat Podman Kube Play[1]
      Formatnya mirip Kubernetes dengan beberapa fitur kemudahan tambahan seperti build container
      Jika menaruh file kube play di root proyek dan menjalankan podman kube play project.yaml --build, pod, volume, dan lainnya akan berjalan bersama
      File Quadlet berguna pada tahap deployment. Jika ingin mengunggah proyek ke VPS, Anda bisa memakai Kube Quadlet[2] bersama project.yaml yang sudah dimiliki
      [1] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      [2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • Perusahaan kami juga memakai docker-compose.yml untuk pengembangan, jadi saya paham rasa sakitnya
      Umumnya bekerja sangat baik, tetapi di OSX kadang bertingkah aneh karena VM perantara sialan itu
      Sesekali saya memeriksa kompatibilitas Podman, tetapi sekarang saya sudah menerima bahwa kompatibilitas penuh tidak mungkin karena filosofi rootless-nya terlalu berbeda
      Meski begitu, alat ini keren untuk produksi. Saya menjalankan beberapa proyek hobi di node bare-metal dengan service systemd buatan sendiri, dan saat ini memakai containerd mode pengguna
      Kalau ada waktu, mungkin saya akan mencoba memindahkannya
  • Menarik bahwa tulisan ini menyebut Podman-Compose “tidak dipelihara secara aktif” sambil menunjukkan commit terakhirnya 5 bulan lalu, lalu langsung merekomendasikan Podlet sebagai alternatif yang commit terakhirnya juga 5 bulan lalu
    Podlet bisa berguna, tetapi tidak mendukung banyak fitur Docker Compose dan tidak selalu mengonversi dengan rapi
    Khususnya, ia tidak mendukung fitur menumpuk beberapa file YAML seperti -f docker-compose.yml -f docker-compose.override.yml

    • Jika suka file compose, Anda bisa memakai aplikasi compose Docker[1] bersama Podman[2]
      Sepertinya CLI compose mengendalikan engine melalui socket, dan engine Podman serta Docker memiliki API yang hampir sama
      Saya memakai cara ini karena podman-compose tidak berjalan seperti yang diharapkan
      Docker-compose biasanya dipasang sebagai plugin klien docker, tetapi saya menggunakannya sebagai aplikasi mandiri agar bisa dipakai dengan Podman
      Untuk konfigurasi integrasi, saya juga lebih suka docker contexts daripada variabel lingkungan DOCKER_HOST
      Jika Quadlet murni saja belum cukup kuat, Quadlet[3] dan Podman biasa[4] juga mendukung eksekusi manifes Kubernetes secara terbatas
      Saya belum tahu bagaimana Podman menangani opsi restart pada file compose. Ini karena Podman tidak memiliki daemon pengawas
      Sebaliknya, saya tahu bahwa opsi healthcheck bergantung pada timer systemd
      Saat memakai Podman di Gentoo, distro yang bukan systemd, healthcheck otomatis tidak berjalan, tetapi ketika healthcheck dijalankan secara manual, sisa konfigurasinya berjalan sampai selesai
      [1] https://github.com/docker/compose
      [2] https://docs.podman.io/en/latest/markdown/podman-system-serv...
      [3] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
      [4] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
    • Agar adil, fitur Podlet memang tidak memerlukan pembaruan terus-menerus, sedangkan podman compose berbeda
      Podlet adalah alat bantu, dan dalam jangka panjang bekerja dengan Quadlet lebih baik
    • Tanggal commit memang tidak akurat untuk menunjukkan bahwa sesuatu sedang dipelihara, tetapi bisa menunjukkan bahwa sesuatu tidak dipelihara
      5 bulan bukan berarti tidak dipelihara; mungkin baru sekitar 2 tahun bisa begitu
      Tetap saja itu menambah kekhawatiran. Namun 5 bulan sama sekali bukan bukti bahwa proyek sedang dipelihara
      Ada banyak alasan repositori yang tidak dipelihara tetap diperbarui, dan hanya fitur arsip GitHub yang belakangan kurang bagus itu yang bisa mencegahnya
  • Beberapa tahun lalu, saat menginisialisasi ulang konfigurasi self-hosting, saya ingin mencoba sesuatu yang berbeda lalu memilih openSUSE MicroOS, dan akhirnya menjalankan kontainer Podman di bawah systemd/Quadlet; saya cukup puas dengan konfigurasi saat ini
    Kontainer diperbarui otomatis dengan alat bawaan Podman, sementara pemeriksaan log dan monitoring ditangani dengan alat systemd yang biasa dipakai
    Saat perlu mengubah sesuatu, meskipun lupa lokasi file konfigurasinya, mudah ditemukan, serta mudah dibaca dan diubah
    Rootless dan daemonless juga bagus
    Saya sempat mencoba beberapa hal, tetapi podman compose terasa kaku, saya senang itu dideprecate, dan jelas bahwa Quadlet adalah arah yang tepat
    Perlu diingat ada kurva belajar dan materinya lebih sedikit dibanding Docker
    Untuk pengembangan lokal, jika tujuannya menaikkan dan menurunkan stack beberapa layanan, saya tetap akan memilih Docker dan docker compose

    • Saya menjalankan Nextcloud dengan Fedora CoreOS di workstation lama yang murah
      Butuh waktu untuk menyesuaikan konfigurasi, tetapi saya sangat terkesan karena hampir tidak memerlukan pemeliharaan. Sejauh ini sama sekali tidak ada
      Orang yang ingin mencoba hal serupa bisa merujuk konfigurasi saya
      https://github.com/jeppester/coreos-nextcloud
    • Kombinasi Quadlet + MicroOS sangat kuat, begitu juga distro atomic lain seperti Fedora CoreOS
      Saya sedang memindahkan semua node secara bertahap ke MicroOS, dan di perusahaan juga mendorong MicroOS atau sesuatu yang serupa
      Kombinasi rollback otomatis pada OS dasar dengan konfigurasi kontainer deklaratif dan pembaruan otomatis terasa saling pas dengan sangat baik
  • Formatnya lebih jelas daripada podman generate systemd atau YAML Kubernetes, dan integrasi systemd-nya juga sangat bagus
    Hal yang menjengkelkan adalah upstream Podman tidak menyediakan repositori untuk Debian/Ubuntu
    Di Debian stable saya terjebak di 4.3.1 dan melewatkan banyak fitur baru, jadi akhirnya memutuskan kembali ke Docker compose

    • Saya menemui masalah yang sama saat mencoba memakai Quadlet di Raspberry Pi yang menjalankan Debian
      Solusi sementara yang disarankan adalah mengompilasi Podman sendiri atau memakai debian/testing
  • Saya sungguh berharap pendekatan baru ini membantu orang beralih dari Docker ke Podman
    Docker-Compose adalah alasan banyak orang ragu untuk beralih, termasuk saya
    Harus diakui, sebelum Quadlet, Podman belum punya jawaban yang benar-benar memadai
    Jika Docker-Compose membuat Anda ragu meninggalkan Docker, Podman dengan Quadlet adalah alternatif yang jauh lebih sepadan
    Anda mungkin tidak akan terlalu merindukan Docker seperti yang dibayangkan, dan Anda juga mendapat peningkatan keamanan lewat menjalankan container secara rootless

    • Saya tidak akan beralih sampai bisa memiliki beberapa lingkungan Quadlet yang independen
      Menaruh semuanya di ~/.config/quadlet/systemd bukan solusi
      Untuk pengembangan dan pengujian, hal ini wajib, dan saat ini Quadlet murni solusi deployment
  • Saya sangat menyukai Quadlet karena membuat container bisa digunakan seperti layanan sistem biasa
    Namun pengalaman pengguna container rootless tidak terlalu cocok dengan konseptualisasi seperti ini
    Biasanya layanan sistem berjalan sebagai pengguna sistem di sesi systemd sistem, tetapi layanan container rootless berada di sesi systemd pengguna milik pengguna sistem tersebut
    Akan menyenangkan jika Quadlet rootless bisa dijalankan di dalam sesi sistem

    • Saya penasaran apakah ada perbedaan praktis dibanding mengaktifkan user-linger dan menjalankannya secara rootless lewat systemd pengguna
      Saya selalu melakukannya seperti itu
    • Saya juga berharap Quadlet rootless bisa dijalankan di dalam sesi sistem
      Selain itu, akan bagus jika Quadlet rootless bisa dijalankan dengan opsi DynamicUser=
      DynamicUser= adalah cara yang sangat baik untuk membatasi izin layanan sistem, tetapi saat ini kurang cocok dengan Podman
  • Menarik melihat Quadlet di halaman depan Hacker News. Saya rasa proyek ini belum mendapat perhatian yang cukup
    Ygal dan Valentin dari proyek tersebut pernah mengirimkan tulisan tamu tentang cara menjalankan klien tunnel inlets. Mirip Ngrok/Cloudflared, tetapi di-self-host tanpa batasan SaaS
    https://inlets.dev/blog/2023/10/03/client-quadlet.html
    Mereka menggunakan [kube] alih-alih [container], sehingga bisa memakai YAML Kubernetes standar, dan hasilnya menjadi cukup portabel

  • Untuk yang berminat, saya baru-baru ini membuat template Ansible yang menunjukkan betapa mudahnya deployment Quadlet
    GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy