Menjelajahi ‘Podman’, Alternatif Docker yang Lebih Aman

 (betterstack.com)
6 poin oleh GN⁺ 2024-01-14 | 1 komentar | Bagikan ke WhatsApp
  • Podman memberikan pengalaman menjalankan container yang mirip dengan Docker, tetapi berbeda dari sisi keamanan dan audit trail karena berjalan tanpa daemon
  • Docker memakai struktur client-server yang berpusat pada Docker daemon, sedangkan Podman membuat container langsung dari sesi pengguna sehingga pelacakan pengguna yang menjalankan menjadi lebih jelas
  • Karena mengikuti standar OCI, Podman dapat menjalankan image seperti hello-world, caddy, wordpress, dan mysql:5.7 dari Docker Hub, dan dalam banyak kasus perintah docker bisa diganti dengan podman
  • Nama image pendek tidak secara otomatis menjadikan Docker Hub sebagai default seperti Docker, sehingga diperlukan salah satu dari nama image lengkap, alias, atau pengaturan unqualified-search-registries
  • Konfigurasi multi-container dapat ditangani dengan Podman Compose, pods, dan manifest Kubernetes, tetapi Podman tidak memiliki orkestrasi produksi bawaan seperti Docker Swarm sehingga perlu memakai sistem eksternal seperti Kubernetes

Titik Perbedaan Podman dan Docker

  • Podman adalah engine container open source yang bertujuan menjadi alternatif Docker yang lebih aman dan ringan
  • Podman menjalankan container tanpa daemon yang terus berjalan, dengan struktur di mana pengguna mengelola container secara langsung
  • Arah keamanan bawaannya berfokus pada rootless container, user namespace, dan penggunaan capability kernel yang lebih hati-hati
  • Karena kompatibilitasnya tinggi dengan image dan sistem perintah Docker, Podman menjadi pilihan praktis bagi developer dan administrator sistem yang mencari alternatif Docker

Arsitektur dan Audit Trail

  • Docker menggunakan model client-server, dan permintaan menjalankan container diteruskan dari Docker client ke Docker daemon
    • Proses container menjadi child process dari Docker daemon, bukan dari sesi pengguna
    • Saat auditd, sistem Linux Audit, mendeteksi event proses container, audit user ID dapat ditampilkan sebagai unset, bukan ID pengguna sebenarnya
    • Dalam struktur ini, aktivitas berbahaya sulit dikaitkan dengan pengguna tertentu
  • Podman menggunakan arsitektur daemonless
    • Setiap container dibuat langsung melalui sesi login pengguna
    • Data proses container mempertahankan informasi pengguna
    • auditd dapat mendeteksi dan mencatat dengan tepat ID pengguna yang memulai proses container tertentu
  • Bergantung pada image, kecepatan startup container Podman bisa hingga 50% lebih cepat daripada Docker

Manajemen Siklus Hidup Container

  • Karena Podman tidak memiliki daemon, cara manajemen siklus hidup container juga berbeda dari Docker
  • Di Linux, Podman sangat bergantung pada Systemd
    • Untuk menerapkan kebijakan restart pada container yang ditentukan dengan flag --restart always, Podman menggunakan layanan systemd bernama podman-restart
    • Layanan ini otomatis memulai kembali container yang ditentukan setelah sistem reboot
  • Podman juga menyediakan perintah untuk membuat file layanan Systemd dari container yang sedang berjalan
    • Jika container ditempatkan di bawah pengelolaan systemd, proses start, stop, dan pemeriksaan menjadi lebih mudah
  • Docker menangani pekerjaan semacam ini di dalam daemon

Pilihan Orkestrasi

  • Dalam pengembangan lokal, pengguna Docker biasanya mendefinisikan dan mengelola aplikasi multi-container dengan Docker Compose
  • Podman tidak mendukung file Compose secara bawaan, tetapi menyediakan Podman Compose sebagai alternatif yang kompatibel
    • Umumnya bekerja dengan file docker-compose.yml yang sudah ada
    • Pengguna yang terbiasa dengan Docker Compose dapat terus memakai file Compose yang ada
  • Cara native di Podman adalah menggunakan pods
    • Ini adalah konsep yang diambil dari Kubernetes
    • Beberapa container dapat dikelola seperti satu unit
  • Untuk deployment produksi, Podman tidak memiliki alat orkestrasi bawaan seperti Docker Swarm
    • Dalam kasus ini, sistem orkestrasi eksternal seperti Kubernetes menjadi alternatif
    • Kubernetes dapat diintegrasikan dengan Podman, tetapi mungkin memerlukan konfigurasi dan pengaturan tambahan agar berjalan dengan benar

Default Keamanan

  • Risiko besar dalam keamanan container adalah situasi ketika host system dikompromikan akibat container escape
  • Podman dirancang untuk menyediakan pengaturan keamanan bawaan yang lebih kuat daripada Docker
    • rootless container
    • user namespace
    • profil seccomp
  • Docker juga dapat memakai rootless container, user namespace, dan profil seccomp, tetapi biasanya tidak aktif secara default dan sering memerlukan pengaturan tambahan
  • Konfigurasi default Podman menjalankan rootless container di dalam user namespace yang terisolasi untuk membatasi dampak dari potensi escape
  • Pengaturan default Docker menjalankan proses container sebagai root, sehingga risikonya lebih tinggi jika terjadi escape
  • Default capability juga berbeda
    • Podman secara default memulai container dengan 11 capability
    • Docker menggunakan 14 capability dengan default yang lebih permisif
  • Kedua tool dapat dikonfigurasi dengan keamanan yang kuat, tetapi Podman umumnya membutuhkan upaya lebih sedikit untuk mencapai kondisi tersebut

Perbedaan Mencolok dalam Perbandingan Fitur

  • Podman mendukung arsitektur daemonless dan integrasi Systemd
  • Container dapat dikelompokkan ke dalam pods, dan Podman juga dapat menangani Kubernetes YAML
  • Docker mendukung Docker Swarm, sedangkan Podman tidak
  • Sebagian besar fitur lainnya dapat dianggap kurang lebih setara di kedua sisi

Instalasi dan Lingkungan Eksekusi

  • Podman dapat berjalan di sistem operasi utama seperti Docker
    • macOS
    • Windows
    • distribusi Linux utama
  • Perbedaan pentingnya adalah Podman berjalan secara native di Linux, tetapi memerlukan virtual machine di Windows dan macOS
  • Contoh mengasumsikan distribusi Linux berbasis Debian, yaitu Ubuntu, Mint, dan Debian
  • Untuk menginstal Podman terbaru, diperlukan distribusi yang relatif baru
    • Versi mayor Podman terbaru pada saat penulisan adalah 4.x
    • Ubuntu 22.04 LTS masih terikat pada Podman 3.x
    • Contoh menggunakan Ubuntu 23.10 sebagai acuan
  • Setelah instalasi, contoh output adalah podman version 4.3.1, yang mengonfirmasi bahwa perintah podman dapat dijalankan secara lokal

Menjalankan Image Docker dan Kompatibilitas OCI

  • Podman dapat menjalankan image hello-world yang dibangun dengan tool ekosistem Docker
  • Kompatibilitas ini dimungkinkan karena Docker dan Podman sama-sama mengikuti standar OCI(Open Container Initiative)
    • OCI mendefinisikan spesifikasi format image dan spesifikasi runtime
    • Ini memungkinkan berbagai container runtime saling interoperabel
  • Sebagian besar image dan container Docker dari Docker Hub dapat digunakan di Podman
  • Workload yang sudah ada dapat dipindahkan ke Podman tanpa perubahan, atau library image dari Docker Hub dapat dimanfaatkan
  • Meski output hello-world menampilkan “Hello from Docker!”, yang sebenarnya menjalankannya adalah Podman
    • Docker client maupun Docker daemon tidak terlibat dalam proses eksekusi

Cara Menangani Nama Image Pendek

  • Jika nama image lengkap tidak ditentukan, Docker menggunakan Docker Hub, yaitu docker.io, sebagai registry default
  • Podman tidak merekomendasikan penggunaan nama pendek dan tidak secara otomatis mengasumsikan registry default
  • hello-world memiliki alias di shortnames.conf, sehingga diinterpretasikan sebagai docker.io/library/hello-world
  • Jika image tanpa alias seperti caddy dijalankan dengan nama pendek, error berikut akan muncul
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Ada tiga cara untuk menyelesaikannya
    • Gunakan nama image lengkap, misalnya docker.io/library/caddy
    • Tambahkan bagian [aliases] di registries.conf dan definisikan alias sebagai "caddy"="docker.io/caddy"
    • Atur unqualified-search-registries=["docker.io"] agar nama pendek dicari di Docker Hub
  • Pengaturan per pengguna dapat ditempatkan di $HOME/.config/containers/registries.conf
    • File ini memiliki prioritas di atas /etc/containers/registries.conf
    • Karena dapat dikonfigurasi tanpa hak root, pendekatan ini lebih cocok dengan model rootless
  • Jika ingin memakai Podman seperti pengganti Docker, pengaturan unqualified-search-registries lebih nyaman dalam jangka panjang daripada alias

Menggunakan Private Registry

  • Podman dapat menggunakan private registry seperti Docker
  • Contoh yang memakai akun Docker Hub mengikuti alur berikut
    • Buat access token di Docker Hub
    • Atur deskripsi sebagai Podman tutorial dan izin sebagai Read & Write
    • Buat private repository
    • Login dengan podman login docker.io
  • Jika docker.io adalah item pertama unqualified-search-registries di registries.conf, registry dapat dihilangkan, tetapi praktik yang baik adalah menyebutkan registry secara eksplisit
  • Jika registry tidak diberikan, podman login gagal dengan error berikut
    • Error: no registries found in registries.conf, a registry must be provided
  • Setelah login, image hello-world dapat di-push ke private repository, image public lokal dapat dihapus, lalu container dapat dijalankan dari image private repository
  • Tanpa kredensial login yang valid, pull image private akan menghasilkan error akses ditolak dan autentikasi diperlukan
  • Perbedaan mencolok dalam penggunaan private registry hanyalah menggunakan podman alih-alih docker, dan Podman dapat digunakan bersama private registry yang umum dipakai

Menjalankan Multi-Container dengan Podman Compose

  • Saat perlu menjalankan beberapa container sebagai satu unit, Podman menyediakan beberapa pilihan
    • Podman Compose
    • pods
    • Kubernetes manifests
  • Contoh menggunakan Podman Compose untuk menjalankan WordPress dan MySQL
  • Podman Compose adalah tool berbasis komunitas yang mengimplementasikan Compose specification dan terintegrasi dengan Podman
  • Tool ini bergantung pada Python 3, dan pada contoh diinstal dengan pipx
    • Contoh output instalasi adalah podman-compose 1.0.6
    • Versi Podman yang digunakan adalah 4.3.1
  • Jika pipx diinstal ke $HOME/.local/bin, path tersebut mungkin belum ada di $PATH
    • Jalankan pipx ensurepath untuk menambahkan path
    • Anda perlu membuka terminal baru atau membaca ulang file konfigurasi shell

Contoh WordPress dan MySQL

  • Contoh mendefinisikan user, password, dan nama database di file .env, lalu mengonfigurasi layanan WordPress dan MySQL dengan docker-compose.yml
  • Saat podman-compose up -d dijalankan, Podman Compose menganalisis docker-compose.yml
  • Proses untuk layanan wordpress
    • Mencari external volume yang diperlukan dan membuatnya jika belum ada
    • Mencari network yang sesuai dan membuatnya jika belum ada
    • Menjalankan container wordpress
    • Jika image lokal tidak ada, mengambil wordpress:latest dari registry docker.io yang telah dikonfigurasi
  • Proses untuk layanan db
    • Membuat volume podman-tutorial_db
    • Memeriksa network yang sudah ada
    • Menjalankan container mysql:5.7
    • Jika image lokal tidak ada, mengambilnya dari Docker Hub
  • Setelah berjalan, halaman instalasi WordPress dapat dilihat di localhost:8080
  • Output podman ps menampilkan container wordpress dan db sedang berjalan
    • Port wordpress dipetakan sebagai 0.0.0.0:8080->80/tcp
    • db berjalan dengan image mysql:5.7
  • Daftar image menampilkan docker.io/library/wordpress:latest dan docker.io/library/mysql:5.7
  • Daftar network menampilkan network default podman dan network podman-tutorial_default yang dibuat oleh Podman Compose
    • podman-tutorial_default dibuat untuk memisahkan container yang didefinisikan di docker-compose.yml dari container lain di sistem yang sama
  • Daftar volume menampilkan podman-tutorial_db dan podman-tutorial_wordpress
  • podman-compose down menghentikan dan menghapus container, tetapi mempertahankan network dan volume
    • Gunakan podman volume rm untuk menghapus volume
    • Gunakan podman network rm untuk menghapus network
  • Perintahnya hampir sama dengan Docker dan Docker Compose; perbedaannya hanya mengetik podman dan podman-compose alih-alih docker dan docker-compose

Kriteria Pemilihan

  • Podman adalah alternatif Docker yang praktis untuk menjalankan workload container
  • Podman dapat melakukan sebagian besar hal yang dapat dilakukan Docker, dengan keunggulan tidak memerlukan daemon latar belakang
  • Podman juga menyediakan fitur yang tidak ada di Docker
    • Bekerja dengan file manifest Kubernetes
    • Menyusun container individual ke dalam pods
  • Jika membutuhkan solusi manajemen container yang lebih ringan dan aman, Podman bisa menjadi pilihan yang lebih baik
  • Jika memprioritaskan ekosistem yang kuat dan dukungan komunitas yang luas, Docker mungkin lebih cocok
  • Untuk bahan eksplorasi tambahan, lihat situs resmi Podman, dokumentasi, dan komunitas

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-14
Opini Hacker News

  • Saya dulu suka ketika Podman mendukung file unit systemd. Karena bukan hanya container, seluruh pod juga bisa dibuat auto-start dan auto-update lewat systemd
    Namun fitur itu dihapus dan mereka mulai mendorong Quadlet. Satu container bisa dilakukan dengan file unit, tetapi untuk pod harus memakai definisi klaster Kubernetes
    Selain itu, berbeda dari Docker, karena container mengikuti definisi SELinux, saya beberapa kali kerepotan karena tidak bisa mengakses direktori yang dipetakan
    Pada akhirnya saya tidak tahu Podman ini ingin kita melakukan apa. Apakah harus memakai Kubernetes? Apakah kita tidak boleh memetakan path logis dan harus membuat direktori khusus untuk semuanya?

    • Infrastruktur saya sudah didefinisikan dengan docker-compose.yml, lalu saya mengetahui bahwa podman-compose punya fitur yang dokumentasinya minim untuk membuat unit systemd
      Fitur ini tidak memakai fitur Podman yang kini sudah ditinggalkan, melainkan menulis file unit secara langsung, dan menurut saya jauh lebih mulus daripada cara Podman lama
      Untuk mengaktifkan fiturnya: $ podman-compose systemd -a create-unit, dan untuk mendaftarkan unit systemd: $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"
      Update ditangani dengan $ podman-compose pull lalu $ systemctl --user restart "podman-compose@$PROJECT_NAME". $PROJECT_NAME biasanya nama direktori
      Kalau ingin mengecek, kode sumber fiturnya ada di sini: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Saya masih memakai podman 4.3.1, tetapi sepertinya tidak ada alasan cara ini berhenti bekerja di versi-versi setelahnya
    • Pernyataan “berbeda dari Docker, container mengikuti definisi SELinux” justru adalah bug Docker. Jika sistem tidak disiapkan untuk SELinux, seharusnya dimatikan
      Dan file systemd yang dulu dibuat podman-generate-systemd pada akhirnya kurang lebih hanya menjalankan "podman start containername", jadi mudah juga ditulis sendiri. Hanya saja, berbeda dengan docker-compose dan semacamnya, container nyaris seperti black box
      Kelebihan Quadlet adalah definisi container dideklarasikan di file .container. Dulu orang menulis command line podman run secara manual ke unit systemd; dari sisi itu, Quadlet adalah peningkatan besar dan juga bisa menjadi alternatif docker-compose. Tentu ada plus-minusnya
    • Sebagai penggemar lama, saya setuju soal bagian ini
      Setiap kali hendak menjalankan podman generate systemd [...], saya kembali teringat bahwa transisi ini pernah terjadi
      Alasan saya tidak sering mengalaminya adalah karena saya membuat sendiri role Ansible yang menangani ini dengan cukup baik
      Tetap saja, kuat terasa bahwa Podman kehilangan arah. Karena mereka sudah menerima pemeliharaan file unit dan perancangan relasinya, saya hanya ingin mereka membiarkan kita memakai generator. Saya tidak peduli apakah Quadlet atau apa pun dikatakan lebih baik
    • Jika tidak ingin berurusan dengan SELinux, tambahkan ini ke containers.conf: [containers] label=false
      Kalau tidak menyukai level keamanan default Podman, biasanya ada cara untuk mematikannya
    • Baru-baru ini saya pindah ke NixOS, dan NixOS menjadikan systemd sebagai acuan untuk semuanya, termasuk container
      Model ini sangat intuitif, tetapi untuk menerapkannya pada Docker Compose perlu banyak migrasi manual
      Jadi saya membuat tool yang mengubah file Compose menjadi konfigurasi NixOS agar bisa ditafsirkan dan dikelola secara native: https://github.com/aksiksi/compose2nix

  • Ada kelebihan yang hampir tidak pernah disebut sebagai alasan kuat untuk memilih Podman dibanding Docker. Docker merusak konfigurasi jaringan
    Mencoba menjalankan Docker dan VM KVM dengan bridge secara bersamaan adalah mimpi buruk, sementara Podman jauh lebih cocok bahkan dengan konfigurasi default
    VPN juga sering rusak karena Docker, atau sebaliknya merusak Docker. Saya tidak terlalu tahu bagaimana networking Podman bekerja di dalamnya, tetapi setidaknya tampaknya dirancang dengan baik agar tidak mengganggu pekerjaan lain. Saya sama sekali tidak bisa mengatakan hal yang sama tentang Docker

    • Bagi saya, Buildah adalah fitur inti yang sebenarnya. Ia bisa bekerja baik dengan Docker, tetapi lebih dekat dengan keluarga tool yang sama dengan Podman
      Menurut saya Dockerfile itu sampah murni. Bahasa yang sudah ada sudah cukup, dan saya benar-benar tidak suka ketika “developer yang bosan” membuat DSL atau bahasa pemrograman baru. Apalagi kalau YAML; meski kasus ini bukan YAML, Dockerfile adalah contoh bagus kenapa kita harus berhenti melakukan hal seperti ini
      Alasannya terlihat jika melihat Buildah tanpa bud. Begitu use case sedikit saja keluar dari jalur standar, alih-alih DSL setengah matang yang menyebalkan, kita bisa memakai Bash, Fish, atau apa pun yang diinginkan
      Keputusan buruk seperti ini menjalar ke seluruh ekosistem Docker. DCS dan pengganti-penggantinya yang selalu belum selesai juga contohnya. Alih-alih memakai protokol tanda tangan yang sudah mapan seperti Cosign, mereka ingin membuat sistem rumit yang sulit diotomatisasi dan terutama menyulitkan rotasi kunci
    • Podman gratis. Docker juga gratis, tetapi menginstal Docker tanpa Docker Desktop itu merepotkan
    • Saya masih menjalankan Docker dan VM KVM dengan bridge sampai sekarang, dan semuanya berjalan baik-baik saja tanpa mimpi buruk. Agak aneh

  • Senang melihat Podman makin banyak dipakai. Terlalu banyak tool dibuat dengan asumsi pengguna menambahkan grup sudo docker, sehingga rusak pada konfigurasi Docker yang sadar keamanan yang tidak asal memberikan akses root

    • Selalu lucu bahwa masa depan canggih seperti serverless dan container pada akhirnya dibangun di atas fondasi menjalankan segala macam hal sebagai root

  • Sebagai engineer RHEL tersertifikasi, saya sudah menggunakan Podman selama beberapa tahun
    Sejujurnya, untuk penggunaan container pribadi, saya cukup menyukainya. Namun di tempat kerja, kami masih menyediakan Docker untuk para developer. Sejauh ini belum ada cara untuk menyediakan sesuatu bagi developer yang bisa menandingi kesederhanaan docker compose
    Saat membuat image container, kami juga memakai buildah di pipeline CI, tetapi dari sudut pandang pengguna akhir developer, docker compose masih dominan

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Karena masalah ini, saya hampir kena

    • Docker mengutak-atik iptables hanya dengan pengaturan dan instalasi default. Ini selalu menjadi sumber masalah, terutama saat ingin memakai nftables yang lebih baru
    • Karena pilihan default Docker yang tidak aman, salah satu container self-hosting pribadi dari proyek GitHub yang seharusnya hanya dipakai untuk VPN disusupi penambang kripto. Sampai sekarang masih menyebalkan
    • Kalau bicara soal masalah jaringan, pernah ada masalah besar ketika memori untuk perangkat jaringan habis dalam konfigurasi bertingkat, sehingga sistem harus direstart. Kalau bukan karena itu, ini akan menjadi alternatif lxc yang bagus; sayang sekali

  • Saya belum begitu paham mengapa Red Hat berinvestasi membuat alternatif Docker, tetapi hasilnya benar-benar saya suka.
    Podman melakukan hampir semua yang dilakukan Docker, sambil memiliki fitur tambahan seperti pod, atau dalam banyak kasus memakai pendekatan yang lebih baik, seperti proses pembuatan kontainer tanpa daemon.
    Masalah terbesar bagi developer umum mungkin Docker compose, tetapi jika memakai file compose sederhana, ada skrip podman-compose yang berupaya kompatibel dengan spesifikasi Docker compose.
    Ada juga cara memakai Podman sebagai backend untuk docker-compose [1]. Secara keseluruhan, pada 2024 saya tidak melihat alasan untuk memakai Docker di mesin Linux. Saya kurang tahu bagaimana Podman di macOS atau Windows.
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat awalnya bekerja sama dengan Docker untuk memperbaiki berbagai masalah yang pernah muncul, misalnya masalah kompatibilitas systemd pada kasus penggunaan tertentu, tetapi tidak banyak hasilnya.
      Jika digabungkan dengan fakta bahwa Docker dulu maupun sekarang punya sangat banyak masalah keamanan, dan kontainer serta image ala Docker sangat luas dipakai di kalangan developer, mereka mau tidak mau harus membuat implementasi sendiri yang lebih sesuai dengan nilai dan pendekatan RHEL.
      Misalnya, Docker bisa rootless, tetapi sampai sekarang tetap tidak menjadikannya default. Dalam lingkungan yang diperkeras, baik grup pengguna docker maupun cara menjalankan tanpa grup sulit diterima secara keamanan untuk banyak kasus penggunaan.
      Docker awal terlalu pasif dalam membuat kontainer non-privileged setidaknya memiliki isolasi minimal, dan bahkan setelah masalahnya diketahui, butuh waktu lama untuk memperbaikinya. Cara interaksinya dengan firewall dan aturan jaringan, serta SELinux, juga banyak bermasalah. Itulah mengapa larangan Docker tidak jarang ditemui di perusahaan yang memiliki administrator sistem Linux khusus yang mengutamakan keamanan.
    • Saya memakai Podman di Windows. Docker di Windows adalah rangkaian kekesalan dan frustrasi tanpa akhir.
      Sejak awal, semua dokumentasinya secara agresif mengarahkan ke instalasi GUI yang tidak ramah pengguna. Ia menjalankan proses berat saat boot, entah kenapa meminta pendaftaran akun cloud, lalu mengomel lagi bahwa produk yang disebut open source itu tidak boleh dipakai untuk kerja.
      Alternatif tidak didukung untuk memasang “hanya Docker command line” dibuat rumit tanpa perlu, dan terakhir kali saya mencobanya, sebagian besar VM WSL bahkan tidak mendukungnya dalam keadaan default.
      Sebaliknya, Podman cukup winget install podman lalu selesai dan tidak mengganggu. VM Podman hanya saya mulai saat perlu menjalankan kontainer, dan saat tidak diperlukan, sistem berjalan seperti sebelumnya.
      Jika perlu menjalankan sesuatu dengan file compose, ada podman-compose. Mungkin tidak bisa menangani konfigurasi yang aneh-aneh, tetapi untuk kebutuhan saya berjalan baik.
      Hal yang belum bisa dilakukan Podman dengan baik hanya integrasi VS Code, tetapi repotnya membuat Docker berjalan baik-baik di Windows jauh lebih menyebalkan daripada kehilangan beberapa shortcut VS Code, jadi itu bukan masalah.
      Saya merekomendasikan Podman sebagai solusi default kontainer di Windows. Alasan memakai Docker mungkin hanya jika perusahaan membayari biayanya, atau jika ada konfigurasi compose yang rumit; dalam kasus seperti itu, mungkin layak mempertimbangkan pindah ke Kubernetes.
    • Alasan Red Hat berinvestasi adalah karena Docker terlalu jauh dari cara kerja yang lazim di Linux.
      Docker melakukan hal-hal yang merusak sistem, bertahun-tahun kesulitan dengan rootless, dan tentu saja tidak ketinggalan vendor lock-in.
      Podman terbuka, mengikuti standar, dan cocok dengan Kubernetes. Upaya yang sudah dicurahkan developer ke Docker hanya karena lebih dulu muncul di pasar kontainer yang mudah dipakai benar-benar tidak masuk akal besarnya.
    • Saya berharap sudut pandang “tidak ada alasan memakai Docker di Linux” tidak menjadi pandangan mayoritas. Docker bukan RedHat/IBM.
      Jika Docker menghilang, RedHat bisa mendorong agenda perusahaannya sendiri dengan tangan yang lebih kuat.
      Podman memang punya kelebihan, tetapi dalam proses RedHat mencoba menggantikan semua hal dari Docker, ada juga bagian yang tidak dijalankan dengan baik.
      Jika melihat sejarah pendekatan RedHat terhadap ranah kontainer, ada sisi di mana mereka membuang waktu dan tenaga pada banyak proyek yang sebenarnya bisa mereka kontribusikan dan tingkatkan.
      RedHat bukan perusahaan yang punya agenda untuk melakukan hal yang benar bagi pelanggan, jadi kita perlu memikirkan apa yang kita inginkan dalam gambaran yang lebih besar.
    • Saya memakai Podman di macOS. Secara umum pengalamannya lebih baik daripada Docker, terutama dalam dukungan untuk versi macOS lama.
      Satu-satunya kekurangan besar Podman untuk macOS adalah tidak bisa memakai jaringan host dari kontainer. Namun jarang ada kebutuhan untuk memakai jaringan host dari kontainer.
      Namun jika Anda melakukan eksperimen terkait jaringan di dalam kontainer dan ingin mempertahankan hostname serta alamat IP yang sama dengan host, hal ini perlu diingat. Meski begitu, saya tetap memakai dengan mengakali batasan ini.

  • Saya suka pendekatan dan keputusan yang mengutamakan keamanan. Dari konfigurasi default sudah aman, dan saya juga suka bahwa ia bekerja dengan docker compose.
    Namun saya penasaran apakah jika Podman cukup populer, suatu saat mereka akan mengambil jalur sendiri dalam format perintah dan yml. Saat ini terlihat seperti alat yang bergantung pada Docker dan format file Docker compose.
    Saya berharap Podman punya alternatif Swarm. Saat ini, karena kurangnya orkestrasi, Kubernetes terasa seperti dipakai sebagai tongkat penopang.
    Jika sebuah tim mempertimbangkan keamanan dengan baik, rasanya mereka bisa membuat cara menjalankan kontainer dalam skala kecil secara masuk akal dan sederhana, tanpa harus menyelami Kubernetes yang sejak default-nya saja tidak aman seperti program doktoral. Sambil tetap mempertahankan kompatibilitas dengan format Docker compose.

  • Saya setuju bahwa container rootless dan namespace yang terisolasi adalah fitur keamanan yang penting. Namun, itu juga bisa dilakukan dengan Docker rootless dan tidak rumit. Tinggal atur saja seperti itu
    Saya pernah menulis artikel tentang menyiapkan Mastodon dengan docker rootless sambil menerapkan semua praktik terbaik yang saat ini memungkinkan [1]
    Keuntungan tetap memakai Docker adalah aksesibilitasnya lebih baik. Komunitas dan blognya lebih banyak, konfigurasi docker compose tersebar luas, dan lebih banyak orang di sekitar yang tahu cara memakainya
    Pada akhirnya, baik Podman maupun Docker menjalankan proses dalam namespace yang terisolasi di host
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Jangan salah paham. Podman itu bagus, dan belakangan ini saya memakainya sebagai pengganti Docker, tetapi awalnya saya mulai menggunakannya karena mengira itu sekadar pengganti Docker yang sederhana, lalu cukup kewalahan dengan pemetaan UID/GID, kebijakan SELinux, pengaturan DNS yang hilang, dan sebagainya
    Beberapa kali juga saya menjalankan system migrate untuk memperbaiki masalah, tetapi malah merusak seluruh konfigurasi. Ada sistem tersendiri terkait ACL keamanan, pemetaan ID, dan label
    Kalau menjalankan chmod -R di bawah folder home, kemungkinan semua container bisa mati
    Saya puas dengan hasilnya, tetapi itu jauh dari solusi yang “langsung jalan” seperti Docker. Sepertinya sudah banyak membaik sejak saya mulai memakainya

    • Saya mulai memakainya tahun ini, untuk mengisolasi beberapa lingkungan pengembangan dan mencegah npm mengakses seluruh mesin pengembangan dengan mudah
      Menurut saya, ini lebih mudah dipakai daripada Docker. Tampaknya sekarang sudah lebih baik daripada situasi yang dialami di atas

  • Dalam gambaran besar, Podman terasa seperti sesuatu yang esensial, seperti Linux pada masa lalu
    Meski sangat sedikit orang yang memakainya, keberadaannya saja membantu mencegah saudara-saudara proprietary software yang jauh lebih besar melakukan hal-hal mengerikan
    Yang saya maksud dengan “Linux pada masa lalu” bukan berarti Linux menjadi kurang penting, melainkan justru karena sekarang Linux makin esensial dan sentral

    • Kalau yang dimaksud dengan “saudara-saudara proprietary software yang jauh lebih besar” adalah Docker, itu agak ironis. Karena RedHat dan IBM juga melakukan cukup banyak hal buruk di ranah open source