Systemd tak hanya untuk booting, tapi juga streaming

Ada banyak cara untuk memulai streaming video—entah dari kamera, file media, atau sumber lainnya. Dalam kasus kami, stream RTSP sudah tersedia dan berjalan. Tantangan sebenarnya? Kami perlu mendorong stream tersebut ke tujuan RTMP.

Proses streaming-nya sendiri sebenarnya cukup sederhana. Yang jadi PR adalah bagaimana kami mengelola sesi streaming tersebut: bagaimana memulainya, menghentikannya, memantau statusnya, dan memulihkannya jika terjadi gangguan. Kami ingin solusi yang sederhana, andal, dan mudah dirawat.

Menjelajahi pilihan untuk manajemen stream

Ada berbagai pendekatan dan alat yang bisa digunakan untuk mengelola proses streaming. Haruskah kami membangun sistem manajemen proses sendiri? Menggunakan container seperti Docker? Atau memanfaatkan sesuatu yang sudah tersedia dan terintegrasi dengan sistem? Beginilah cara kami menjelajahi beragam pilihan.

Option 1: Membangun Process Manager Sendiri

Bisa saja kami membangun manajer proses sendiri. Tapi, itu berarti menulis banyak kode untuk mengelola proses, restart, logging, dan sebagainya. Terlalu banyak usaha untuk kebutuhan kami yang sebenarnya cukup ringan. Jadi, opsi ini langsung kami coret.

Option 2: Menggunakan Containers, seperti Docker

Docker memang menarik. Ia menyediakan lingkungan yang terisolasi, logging yang lumayan, dan cukup mudah digunakan. Tapi, ada beberapa hal penting yang kami butuhkan namun tidak tersedia secara default, misalnya pengaturan waktu untuk proses atau restart otomatis saat crash. Tentu, bisa saja ditambal, tapi tetap saja: lebih banyak kerjaan.

Lagi pula, container itu punya overhead yang cukup besar. Untuk tugas ringan seperti meneruskan stream, rasanya terlalu berlebihan kalau harus memulai sebuah container penuh. Dengan systemd, kami cukup menjalankan proses biasa di sistem. Lebih cepat, lebih sederhana, dan langsung ke sasaran tanpa lapisan tambahan yang tidak perlu.

Option 3: Menggunakan Systemd Transient Units

Kalau Anda pengguna Linux, kemungkinan besar Anda sudah familiar dengan systemd. Bisa jadi Anda menyukainya, bisa juga sebaliknya. Tapi buat kami, ini justru solusi yang sangat pas.

Systemd adalah sistem yang mengatur booting Linux dan layanan-layanan di background. Tapi lebih dari itu, systemd ternyata bisa digunakan untuk mengelola proses dengan sangat rapi. Dan yang paling keren? Kita bisa membuat "transient units" secara dinamis tanpa perlu menulis file konfigurasi. Cukup panggil perintah; layanan langsung aktif.

Dari sisi teknis, systemd menggunakan komponen yang sama seperti container, misalnya cgroups, untuk mengatur penggunaan sumber daya. Ia juga dilengkapi fitur logging bawaan melalui journald, dan kita bisa atur berapa lama log disimpan.

Inilah kenapa kami memilih systemd:

• Timer: Kami bisa membatasi durasi stream berlangsung.
• Auto-Restarts: Kalau layanan crash, systemd langsung menghidupkannya kembali.
• Logging: Tanpa perlu konfigurasi tambahan, semuanya langsung terekam.

Meski ada yang bilang systemd terlalu kompleks, kami justru menyukainya karena kemampuannya yang fleksibel.

Arsitektur Layanan Streaming Kami

Desainnya sangat-amat sederhana:

• Permintaan stream masuk.
• Backend kami memanggil layanan systemd transient khusus untuk stream tersebut.
• Kalau terjadi crash? Tenang, systemd akan menyalakannya ulang secara otomatis.
• Batasan resource, seperti CPU atau RAM, bisa diatur agar satu stream tidak memonopoli sistem.
• Logging? Sudah langsung ditangani oleh systemd.

Dan karena systemd adalah bawaan hampir semua distro Linux, layanan kami berjalan cepat, ringan, dan native.

Kekurangan? Ada, Tapi Bisa Diakali

Tentu saja systemd tak sempurna. Ini sejumlah hal yang kami temui:

Hanya berlaku di satu server

Systemd memang hebat di satu mesin. Tapi ia tidak punya pengetahuan soal mesin lain. Jadi kalau Anda ingin scale ke banyak server, Anda harus buat logika itu sendiri. Platform seperti Kubernetes punya ini secara default—systemd tidak.

Konsekuensinya?

1. Scaling horizontal (multi-server) lebih rumit.
2. Kalau satu server down, pemulihan harus manual.

Alat manajemen terbatas

Systemd hanya menyediakan alat CLI dasar, seperti systemctl. Tidak ada API canggih atau dashboard grafis seperti yang dimiliki platform container. Jadi, kalau Anda ingin punya UI atau API monitoring, Anda harus bikin sendiri.

Artinya:

1. Perlu effort tambahan untuk membangun interface manajemen.
2. Beberapa automasi mungkin butuh scripting tambahan.

Apakah Anda bisa membangun setup yang skalabel dan multi-mesin dengan systemd? Bisa sekali! Tapi, jujur saja, bergulat dengan Kubernetes jadi terlihat lebih mudah.

Isolasi tidak sebagus container

Walau systemd menggunakan cgroups untuk mengatur sumber daya, ia tidak memberikan isolasi penuh seperti container. Tidak ada filesystem terpisah, network namespace, atau isolasi proses penuh. Buat Incentro, ini bukan jadi deal breaker karena kami tidak memerlukan sandboxing. Tapi, kalau Anda menemukan kode yang tidak bisa dipercaya atau ingin boundary yang lebih kuat antar proses, container adalah pilihan paling aman.

While systemd does use cgroups to manage resource usage, it doesn't provide full isolation like containers do. You don’t get separate filesystems, network namespaces, or full process isolation. For us, that wasn’t a dealbreaker; we didn’t need total sandboxing, but if you're running untrusted code or want stronger boundaries between processes, containers are the safer bet.

Maksudnya:

1. Proses masih bisa "melihat" atau mempengaruhi sistem utama.
2. Kurang ideal jika Anda menjalankan kode dari pihak ketiga atau workload yang tidak terpercaya.
3. Batas keamanan lebih lemah dibandingkan container.