Belajar Podman - API Service & Remote Client
Mengendalikan Podman dari jarak jauh: membuka REST API dengan podman system service, kompatibilitas dengan Docker API dan docker-py, mengamankan koneksi dengan SSH, serta mengorkestrasi container dari host lain memakai podman-remote.
#Pendahuluan
Di episode 14 kalian mengamankan image dan credential dengan secrets, signature, dan Trivy. Sekarang bayangkan sebuah cluster dengan puluhan host — mengetik podman run di setiap mesin bukanlah cara kerja yang bisa diskalakan. Episode 15 membuka dua jalan kontrol jarak jauh: REST API yang kompatibel dengan Docker, dan podman-remote, klien native yang berkomunikasi lewat SSH.
#Arsitektur: Engine di Sisi Server
Podman memang daemonless, tetapi komponen ini membuka pengecualian yang terkendali: podman system service menjalankan layanan API yang sama sekali opsional. Tanpa layanan ini, Podman tetap bekerja seperti biasa. Dengan layanan ini, mesin menjadi server yang bisa menerima permintaan dari luar — klien Docker-compatible maupun podman-remote.
#Membuka API Service
podman system service --time=0
podman system service --time=5 unix:///tmp/podman.sockArgumen terakhir adalah endpoint. Secara default digunakan socket unix, dan --time=0 menonaktifkan batas waktu. Untuk pemakaian di produksi, jalankan layanan ini sebagai unit systemd sehingga restart otomatis jika mati.
#Endpoint REST API
Layanan ini menyajikan dua keluarga API sekaligus:
- Libpod API — endpoint native Podman di bawah prefix
libpod, misalnya operasi pods, machine, dan healthchecks. - Docker-compatible API — endpoint ala Docker Engine, misalnya daftar container, build, dan volume.
Kedua keluarga itu bisa dipanggil langsung lewat HTTP:
curl --unix-socket /run/podman/podman.sock http://localhost/_ping
curl --unix-socket /run/podman/podman.sock http://localhost/containers/json#Docker API Compatibility
Keberadaan API Docker-compatible berarti ekosistem klien Docker ikut berfungsi. docker-py adalah contoh paling umum:
from docker import DockerClient
client = DockerClient(base_url="unix:///run/podman/podman.sock")
containers = client.containers.list()
client.containers.run("nginx:alpine", ports={"80/tcp": 8080})Perhatikan satu-satunya perubahan: base_url menunjuk ke socket Podman. Skrip orkestrasi yang sudah kalian tulis untuk Docker sering kali tinggal ganti satu baris. Hal yang sama berlaku untuk docker compose yang diarahkan lewat DOCKER_HOST.
#Autentikasi di Level API
Socket unix aman karena dibatasi akses file. Begitu API dibuka lewat TCP, kalian wajib menambahkan pengaman: jalankan di balik SSH tunnel, batasi ke jaringan pribadi, atau gunakan TLS. Jangan pernah mengekspos API tanpa proteksi ke internet terbuka.
#Forward Socket lewat SSH
Cara paling sederhana mengamankan API yang terbuka di TCP adalah tidak membukanya ke publik sama sekali. Biarkan podman system service mendengarkan di localhost, lalu buat tunnel SSH ke mesin remote:
ssh -L 8080:127.0.0.1:8080 deploy@10.0.0.5
export DOCKER_HOST=tcp://127.0.0.1:8080
docker psDengan pola ini trafik terenkripsi end-to-end, autentikasi dipegang SSH, dan port 8080 di host remote tidak pernah terlihat oleh jaringan lain. Cara ini juga bisa dipakai bersama podman-remote, meskipun pada praktiknya podman-remote sudah memakai SSH secara langsung.
Tip
Jangan mencampur arah: tunnel SSH mengarah ke API socket, sedangkan podman-remote membangun koneksinya sendiri ke socket target lewat SSH. Pilih satu pola per workflow agar debugging tidak membingungkan.
#podman-remote
Untuk penggunaan sehari-hari, klien yang lebih nyaman adalah podman-remote — binary yang sama dengan Podman tetapi berfokus berkomunikasi dengan server:
podman system connection add prod --identity ~/.ssh/id_ed25519 ssh://deploy@10.0.0.5/run/podman/podman.sock
podman-remote -c prod ps
podman-remote -c prod run -d --name web nginx:alpinepodman system connection add menyimpan konfigurasi koneksi. Setelah itu, perintah podman-remote yang identik dengan podman lokal dijalankan di mesin remote.
#Koneksi Aman
Koneksi podman-remote berjalan di atas SSH, sehingga semua keamanan SSH berlaku: otentikasi kunci, forward ke socket target, dan enkripsi trafik. Praktik yang disarankan:
- Gunakan SSH key khusus deployment, bukan key pribadi.
- Sertakan passphrase atau gunakan SSH agent.
- Buat akun dengan privilege minimal di mesin target.
- Definisikan koneksi dengan nama yang jelas (
prod,staging) dicontainers.conf.
#API vs Remote Client
| Aspek | REST API | podman-remote |
|---|---|---|
| Protokol | HTTP / Unix socket | SSH |
| Autentikasi | Socket permission, TLS, tunnel | SSH key |
| Klien | docker CLI, docker-py, curl | Binary podman-remote |
| Cocok untuk | Integrasi tooling dan pipeline | Admin harian dari host lain |
| Kompatibilitas | Docker-compatible | Subcommand Podman native |
Pilih sesuai kebutuhan: API untuk otomasi dan integrasi, remote client untuk manusia yang ingin CLI lengkap.
Important
Hati-hati dengan kebingungan identitas: podman system service dan podman-remote keduanya bisa terasa sama tapi jalannya berbeda. Jangan menjalankan podman system service secara permanen tanpa alasan — daemonless tetap menjadi fitur utama Podman, dan setiap socket yang terbuka menambah permukaan serangan.
#Penutup
Pada episode 15 ini kalian mengendalikan Podman dari jarak jauh: membuka REST API dengan podman system service, mengenal endpoint Libpod dan Docker-compatible, memakai docker-py lewat socket, mengamankan koneksi dengan SSH, serta mengorkestrasi container dari host lain menggunakan podman-remote.
Inti yang harus dibawa pulang:
- API service opsional, bukan wajib — tanpa itu Podman tetap daemonless.
- Docker compatibility artinya migrasi satu baris —
base_urlatauDOCKER_HOST. - SSH adalah gerbang aman — jangan ekspos API ke internet tanpa proteksi.
- Pilih alat sesuai konteks — API untuk mesin, remote client untuk manusia.
Di episode 16 berikutnya kita mengeraskan apa yang sudah ada: isolation & hardening — membatasi CPU, memory, dan PIDs dengan cgroups v2, rootfs read-only, serta isolasi jaringan dan audit.