4 poin oleh GN⁺ 2024-06-10 | 1 komentar | Bagikan ke WhatsApp
  • Piku adalah alat yang terinspirasi dari Dokku, memungkinkan deployment aplikasi dengan metode git push bahkan di server kecil milik sendiri
  • Mengarah pada alur seperti Heroku/CloudFoundry, tetapi saat itu Dokku belum berjalan di ARM dan Docker juga bisa terasa berlebihan, sehingga Piku menargetkan cara deployment yang lebih sederhana
  • Saat deployment, Piku mendeteksi runtime, menginstal dependensi, lalu membaca Procfile untuk menjalankan worker dengan uwsgi, serta mencakup penanganan terkait Python, Node, Java, Clojure, Ruby, dan Go
  • Dapat men-deploy, mengelola, dan melakukan scaling beberapa aplikasi secara independen pada satu host, serta mendukung virtual host, SSL, situs statis, pemetaan path URL, dan caching respons backend
  • Membutuhkan Python 3.10 atau lebih baru, Python, nginx, uwsgi, dan SSH; proyek ini berstatus stabil dengan target dukungan untuk dua versi mayor terbaru Debian dan Ubuntu LTS

Masalah yang diselesaikan Piku

  • Piku adalah alat yang memungkinkan deployment git push di server sendiri
  • Terinspirasi dari Dokku, dan bertujuan untuk berjalan bahkan di server yang sangat kecil
  • Pengembang ingin menggunakan pengalaman deployment yang mirip Heroku/CloudFoundry pada beberapa board ARM, tetapi saat itu Dokku tidak berjalan di ARM dan Docker terkadang berlebihan, sehingga dibutuhkan solusi yang lebih sederhana
  • Saat ini Piku dapat men-deploy, mengelola, dan melakukan scaling independen untuk beberapa aplikasi per host pada arsitektur ARM maupun Intel
  • Berjalan di penyedia cloud dan lingkungan bare metal yang dapat menjalankan Python, nginx, dan uwsgi

Instalasi dan status proyek

  • Instalasi dasar dapat dilakukan dengan perintah berikut
curl https://piku.github.io/get | sh
  • Dokumentasi instalasi juga mencakup metode instalasi lain, termasuk cloud-init dan instalasi manual
  • Proyek ini dianggap berstatus STABLE
    • Set fiturnya hampir selesai
    • Diperbarui saat runtime bahasa baru ditambahkan atau muncul bug yang dapat direproduksi
  • Saat ini membutuhkan Python 3.10 atau lebih baru, dan target pengujiannya juga Python 3.10 atau lebih baru
  • Target dukungannya adalah dua versi mayor terbaru Debian dan Ubuntu LTS

Workflow berbasis Git Push

  • Piku mendukung workflow yang mirip Heroku
  • Buat remote Git SSH yang mengarah ke server Piku, dengan nama aplikasi sebagai nama repositori
git remote add piku piku@yourserver:appname
  • Push kode untuk melakukan deployment
git push piku master
  • Untuk melakukan push branch selain branch saat ini, gunakan seperti berikut
git push piku release-branch-name
  • Dalam proses deployment, Piku mendeteksi runtime, menginstal dependensi yang diperlukan, dan menjalankan build yang dibutuhkan
    • Aplikasi Python memisahkan dependensi dengan virtualenv per aplikasi
    • Aplikasi Go mendefinisikan GOPATH terpisah per aplikasi
    • Aplikasi Node menginstal entri dalam package.json ke node_modules
    • Aplikasi Java dibangun berdasarkan pom.xml atau build.gradle
    • Aplikasi Clojure dapat menggunakan leiningen atau Clojure CLI dan file deps.edn
    • Aplikasi Ruby menjalankan bundle install gem ke folder terisolasi

Model eksekusi dan konfigurasi

  • Piku membaca Procfile dan menjalankan worker terkait melalui uwsgi
  • uwsgi digunakan sebagai process manager serbaguna
  • Secara opsional, worker release dapat ditentukan; worker ini dijalankan satu kali saat deployment aplikasi
  • Anda dapat mengubah konfigurasi aplikasi atau menambah dan mengurangi proses worker dari jarak jauh
    • config:set digunakan untuk mengubah konfigurasi aplikasi
    • ps:scale digunakan untuk melakukan scaling proses worker
  • File ENV dapat memuat konfigurasi aplikasi dan konfigurasi nginx
  • Dengan menggunakan tipe worker static, situs statis bergaya gh-pages juga dapat di-deploy
    • Tentukan path root sebagai argumen
    • Task release yang melakukan pemrosesan di server setelah git push juga dapat dijalankan

Virtual host, SSL, dan path statis

  • Piku sepenuhnya mendukung virtual host
    • Beberapa aplikasi dapat di-host pada VPS yang sama
    • Aplikasi dapat diakses dengan hostname berbeda menggunakan DNS alias
  • Untuk mengaktifkan SSL, Anda dapat mengatur sertifikat privat atau memperoleh sertifikat Let's Encrypt
  • Jika mengakses dari klien macOS, iOS, atau Linux di LAN, Anda dapat menggunakan piku/avahi-aliases untuk mengumumkan host yang berbeda untuk IP yang sama melalui Avahi/mDNS/Bonjour
  • Selain situs statis, prefix URL tertentu juga dapat dipetakan langsung ke path filesystem
  • Fitur untuk meng-cache respons backend guna mengurangi beban aplikasi juga didukung
  • Path statis dan fitur caching dikonfigurasi melalui nilai dalam file ENV

Platform dan runtime yang didukung

  • Piku dirancang untuk berjalan di lingkungan mirip POSIX yang memiliki Python, nginx, uwsgi, dan SSH
  • Contoh deployment mencakup Linux, FreeBSD, Cygwin, dan Windows Subsystem for Linux
  • Pengembangan dimulai di Raspberry Pi Model B dengan RAM 256MB, dan hingga kini masih berjalan stabil pada perangkat tersebut
  • Penggunaan utamanya adalah sebagai micro PaaS untuk menjalankan aplikasi di server cloud dengan CPU Intel maupun ARM
  • Platform targetnya adalah Debian dan Ubuntu Linux
  • Saat ini mendukung aplikasi Python, Node, Clojure, dan Java, sementara beberapa bahasa seperti Go juga sedang dikerjakan
  • Sebagai prinsip umum, jika sesuatu dapat dipanggil dari shell, maka itu dapat dijalankan di dalam Piku

Prinsip desain

  • Mengutamakan kemampuan berjalan di perangkat berspesifikasi rendah
  • Harus dapat diakses oleh developer hobi dan sekolah K-12
  • Menargetkan sekitar 1500 baris kode yang mudah dibaca
  • Lebih menyukai gaya kode fungsional
  • Bertujuan memiliki sedikit dependensi
  • Mengikuti 12 factor app
  • Mengutamakan penyederhanaan pengalaman pengguna
  • Bertujuan mencakup 80% kasus penggunaan umum
  • Menyediakan default yang masuk akal untuk semua fitur
  • Memanfaatkan paket distribusi dari Raspbian, Debian, dan Ubuntu
    • Dukungan Alpine dan RHEL sedang dikerjakan
  • Memanfaatkan alat standar seperti git, ssh, uwsgi, dan nginx
  • Menjaga kompatibilitas mundur bila memungkinkan

1 komentar

 
GN⁺ 2024-06-10
Opini Hacker News
  • Saya menyukai piku, jadi saya menulis tutorial webapp untuk piku, dan itu masuk ke repositori organisasi piku resmi di GitHub
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    Tutorial ini menjelaskan bagaimana piku bekerja secara internal, dan dari sudut pandang pengguna juga menunjukkan contoh webapp Python yang minimal

    • Dokumentasi piku yang baru terlihat bagus, tetapi bagi pengguna baru yang ingin mencoba piku, hampir tidak berguna
      Rasanya dokumentasi itu mengasumsikan pembaca sudah tahu semua yang dibutuhkan untuk menjalankan dan memakai piku, jadi saya sempat menyerah; tutorial ini menutup celah itu
      Namun meski sudah cukup lama mencari, saya tidak menemukan dokumen ini, dan kalau bukan karena komentar di sini saya tidak akan tahu bahwa dokumen ini ada
      Setidaknya dokumen ini sebaiknya ditautkan dengan jelas dari repositori piku dan beranda dokumentasi, dan kalau memungkinkan lebih baik dimasukkan seluruhnya ke beranda dokumentasi
      Lebih jauh lagi, akan jauh lebih membantu jika ditambahkan tutorial end-to-end dari server bare metal baru sampai domain kustom dan sertifikat SSL yang bisa diakses publik
      Meski tampak seperti langkah yang tidak terkait langsung dengan piku, yang sebenarnya diinginkan pengguna baru adalah menaruh situs mereka di tempat seperti Droplet seharga $5, dan sering kali mereka belum tahu langkah-langkah di antaranya
      Metode apa pun tidak masalah; orang yang akan memperdebatkan metodenya biasanya sudah tahu cara yang mereka sukai
      Sebagai referensi, contoh end-to-end dari Coolify ada di sini: https://billyle.dev/posts/self-hosting-your-website-with-coo...
      Tujuannya bukan sekadar membuatnya secara fungsional mungkin, melainkan membuat lebih banyak orang bisa memulai dengan mudah sehingga tingkat adopsi piku meningkat besar
    • Bagus karena menjelaskan “apa itu deployment ala Heroku
      Saya sama sekali tidak tahu Heroku itu apa dan melakukan apa
    • Dari repositori resmi saja tidak cukup jelas, tetapi penjelasan ini membantu
      Kalau pemahaman saya benar, apakah piku memasang agen di mesin remote dan memasang commit hook di mesin lokal?
      Saya bertanya-tanya apakah overhead bisa dikurangi dengan menjadikan mesin remote sebagai repositori Git remote saja, lalu saat push ke branch tertentu semua pekerjaan dilakukan di remote
    • Tutorial ini sekarang ditautkan dari beranda dokumentasi
  • Kelihatannya bagus dan Dokku juga sangat stabil bagi saya, tetapi jika dependensi Docker dihilangkan, Anda kini terikat pada pilihan yang disediakan sistem operasi
    Ini tidak ideal untuk aplikasi yang mungkin berjalan bertahun-tahun tanpa pemeliharaan, dan pada akhirnya Anda akan segera berhadapan dengan kebutuhan versi sistem operasi tertentu

    • Ini ceruk yang berbeda dari piku, tetapi saya juga merekomendasikan Dokku
      Untuk menaikkan proyek sampingan kecil ke VPS, saya meng-upgrade instalasi Dokku melewati 3–4 rilis Ubuntu LTS, dan semuanya berjalan lancar tanpa masalah
    • Terkadang Docker terasa berlebihan, dan sangat menyenangkan ada alat yang bisa dipakai tanpa Docker
    • piku dan Docker bisa dipakai bersama. Saya punya beberapa Procfile yang berisi perintah docker run, meskipun tentu saja itu bukan tujuan desainnya
      Sebagian besar deployment yang saya lihat berjalan di distro yang sangat stabil, biasanya versi LTS, jadi runtime tidak perlu dinaikkan setiap 6 bulan, dan situs web saya sendiri terus berjalan di piku melewati lebih dari dua pergantian Ubuntu LTS
      Dengan hanya mengatur variabel lingkungan, hal seperti pyenv, nvenv juga mudah dipakai
      Sistem otomasi rumah saya sekarang membutuhkan dua versi Node berbeda, dan saya mengaturnya masing-masing per aplikasi
    • Saat memakai alat seperti ini, bagaimana cara mengatasi dependency hell?
      Sikap “pokoknya jalan” itu elegan, dan saya paham Docker tidak bisa dipakai di mana-mana karena overhead teknis dan mentalnya, tetapi container bagus karena bisa mengisolasi semuanya dan seolah membekukan waktu, sehingga 5 tahun kemudian pun tetap “pokoknya jalan”
      Dalam workflow kecil saya, manajemen container ditangani lazydocker, deployment via push ditangani workflow GitLab, sedangkan build, push ke registry GitLab, dan eksekusinya ditangani satu VPS kecil
      Memang agak berlebihan, jadi sepertinya kombinasi Dockerfile, compose.yml, dan docker compose build juga bisa
      Saya belum merapikan aspek scaling, tetapi untungnya saat ini belum perlu; kalau nanti perlu, sepertinya saya akan mengganti Docker dengan k8s dan lazydocker dengan k9s
      Saya baru masuk ke DevOps, jadi masukan apa pun selalu diterima
    • Saya memakai docker compose + traefik
      Karena lebih sedikit abstraksi magis, bagi saya ini lebih baik daripada Dokku
  • Ini tidak terkait langsung dengan deployment git push, tetapi sangat terkait dengan pengalaman PaaS: tim saya sedang melakukan pratinjau Cloud Native Buildpacks(CNB), spesifikasi terbuka dari CNCF
    Ini adalah Buildpacks yang menargetkan OCI, artinya Anda bisa membuat image Docker secara lokal dengan alat build yang mendeteksi dukungan bahasa dan menanganinya dengan tepat, seperti logika git push Heroku
    Tutorial untuk membangun aplikasi Rails dengan buildpack yang saya kelola ada di sini: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    Jika Anda mencobanya, baik kesannya positif, negatif, maupun biasa saja, meninggalkan pengalaman Anda di diskusi yang tertaut akan membantu kami memperbaikinya

  • Saya baru pertama kali melihat piku
    Entah kenapa, sensasi ketika deployment dimulai lewat git push seperti piku selalu terasa ajaib, dan rasanya tidak mungkin dibuat lebih sederhana dari ini
    Kebetulan kemarin saya baru merilis sebagai open source proyek untuk Kubernetes di area yang sama, ada di sini: https://github.com/pier-oliviert/sequencer
    Bagaimanapun, selamat, kelihatannya bagus

    • Cara kerjanya memang seperti sulap, tetapi kalau ingin mempelajarinya, membuatnya sendiri juga sangat sederhana
      Di server, buat repositori Git dengan git init --bare lalu atur git config receive.denyCurrentBranch updateInstead
      Setelah itu, dengan Git hook, lebih spesifiknya hook push-to-checkout, Anda bisa menerima unggahan, mengompilasi, dan menjalankannya
      Hook itu hanyalah skrip shell sederhana, dan bentuk paling dasarnya cukup variasi seperti compile && install && systemctl restart service
      Setelah itu, kalau Anda mengkloning repositori ke lokal, hook yang sudah disetel akan dijalankan saat Anda melakukan push perubahan
      git clone root@yourserver.com:/path/to/git/folder
    • Entah apakah saya melewatkan sesuatu yang jelas, tetapi kalau sequencer mirip dengan Heroku/Dokku/piku, saya penasaran bagaimana deployment dengan Git dilakukan
      Dari penjelasannya, sepertinya ini bukan deployment git push, melainkan menangani template Kubernetes dan kubectl, jadi terlihat seperti proyek di ranah yang sepenuhnya berbeda
  • Dokumentasi piku yang baru dirombak bisa dilihat di sini: https://piku.github.io/

    • Apakah ini penerus Dokku? Saya tidak tahu ada proyek kedua
  • Commit awalnya 8 tahun lalu?
    Andai saja saya tahu proyek ini sekitar 18 bulan lalu; waktu itu saya sedang mencari cara melakukan deployment ke Raspberry Pi dengan pengalaman pengembangan seperti Heroku, dan piku tampaknya memang menargetkan hal itu persis

    • Betul. Ada masalah visibilitas
      Saya baru saja menyiapkan VPS baru dengan CapRover, dan selama sekitar satu jam mencari perbandingan “PaaS self-hosted ala Heroku”, saya melihat Dokku, CapRover, Coolify, Dokploy, tetapi sama sekali tidak melihat piku
  • Saya maintainer sekaligus salah satu penulisnya
    Kalau Anda suka tool deployment yang sederhana dan minimal, mungkin juga menarik melihat https://github.com/rcarmo/ground-init, yang menangani cloud-init dengan cara yang jauh lebih realistis

    • Dari README saja, saya belum menemukan jawaban yang jelas mengapa ini tidak seharusnya cloud-init
  • Saya penasaran apakah ada cara untuk menangani deployment tanpa downtime
    Misalnya, kalau service Python berjalan di port 8080 pada satu mesin di belakang nginx, bagaimana piku beralih ke instance baru pada port yang sama?

    • Saat ini, proses yang sedang berjalan baru dihentikan setelah deployment git push yang baru selesai
      Penanganan socket dan sesi bergantung pada bagaimana kodenya dibuat, apakah memakai uwsgi atau menjalankan daemon HTTP sendiri
      Salah satu fitur yang sudah didukung secara opsional adalah menghentikan instance yang tidak digunakan dan idle, lalu melakukan lazy start saat ada koneksi baru masuk
    • Sedikit keluar topik, tetapi dengan aktivasi socket systemd, deployment tanpa downtime bisa dilakukan
  • Saya suka Epinio, yang melakukan hal serupa di atas Kubernetes
    Didukung oleh SUSE, dan misalnya lebih ringan daripada KNative yang menjadi dasar GCP Cloud Run, tetapi karena berbasis Kubernetes, tetap membutuhkan lebih banyak resource daripada Dokku atau piku
    Meski begitu, saya lebih memilih k8s karena ekosistem solusi matangnya luas
    Semuanya juga bisa dijalankan di satu server, hanya saja butuh server yang sedikit lebih besar
    Hetzner CX42 baru punya 8 vCPU, RAM 16GB, disk 160GB dengan harga €16,40 per bulan atau €0,0273 per jam, jadi sudah cukup, dan dengan proyek Kube Hetzner Anda bisa menyiapkan cluster Kubernetes berbasis MicroOS yang ter-update otomatis dalam waktu 5 menit
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • Kalau “Epinio melakukan hal yang sama di atas Kubernetes”, bukankah itu sebenarnya sama sekali bukan hal yang sama?
      Inti piku tampaknya adalah memberikan pengalaman seperti Heroku tanpa Docker, dengan arsitektur yang benar-benar sederhana, dan bisa berjalan di ARM
      Saya mengakui Kubernetes berjalan di ARM, tetapi setahu saya Kubernetes menuntut semacam container, entah Docker atau yang lain, dan arsitekturnya jelas tidak pernah sederhana karena alasan yang jelas
      Selain itu, saya juga tidak yakin Epinio memungkinkan alur git push
      Tutorial quick start sepertinya menyuruh memakai perintah seperti epinio push manifest.yaml untuk deployment aplikasi, jadi itu juga tidak cocok dengan “pengalaman seperti Heroku”
      Pada akhirnya, rasanya satu-satunya kesamaan hanyalah menangani deployment
  • Saya suka pendekatannya yang minimal, jadi berencana mencobanya
    Ada juga beberapa hal serupa yang layak dilihat
    https://kamal-deploy.org/
    https://github.com/basecamp/kamal
    https://dokku.com/
    https://github.com/dokku/dokku/
    https://clace.io/
    https://github.com/claceio/clace