Piku - Kendi Sunucunuzda Git Push ile Dağıtımı Mümkün Kılan Teknoloji

 (github.com/piku)
4 puan yazan GN⁺ 2024-06-10 | 1 yorum | WhatsApp'ta paylaş
  • Piku, Dokku'dan ilham alan bir araçtır ve küçük self-hosted sunucularda bile uygulamaları git push yöntemiyle dağıtmayı mümkün kılar
  • Heroku/CloudFoundry benzeri bir akışı hedefler, ancak o dönemde Dokku ARM üzerinde çalışmıyordu ve Docker da fazla ağır kalabildiği için daha basit bir dağıtım yöntemi amaçlandı
  • Dağıtım sırasında çalışma zamanını algılar, bağımlılıkları kurar, ardından Procfile dosyasını okuyup worker'ları uwsgi ile çalıştırır; Python, Node, Java, Clojure, Ruby ve Go ile ilgili işlemleri içerir
  • Tek bir host üzerinde birden çok uygulama bağımsız şekilde dağıtılabilir, yönetilebilir ve ölçeklenebilir; ayrıca sanal host, SSL, statik siteler, URL yolu eşleme ve backend yanıt önbellekleme desteği sunar
  • Python 3.10 ve üzeri ile Python, nginx, uwsgi ve SSH gerektirir; Debian ve Ubuntu LTS'in en güncel iki ana sürümünü desteklemeyi hedefleyen kararlı durumdaki bir projedir

Piku'nun çözdüğü sorun

  • Piku, kendi sunucunuzda git push ile dağıtım yapmanızı sağlayan bir araçtır
  • Dokku'dan ilham almıştır ve çok küçük sunucularda bile çalışmayı hedefler
  • Heroku/CloudFoundry benzeri bir dağıtım deneyimini birkaç ARM kart üzerinde kullanmak isteniyordu, ancak o dönemde Dokku ARM üzerinde çalışmıyordu ve Docker da bazı durumlarda gereğinden ağırdı; bu yüzden daha basit bir çözüme ihtiyaç vardı
  • Bugün hem ARM hem de Intel mimarilerinde host başına birden fazla uygulamayı dağıtabilir, yönetebilir ve birbirinden bağımsız ölçekleyebilir
  • Python, nginx ve uwsgi çalıştırabilen bulut sağlayıcılarında ve bare-metal ortamlarda çalışır

Kurulum ve proje durumu

  • Temel kurulum şu komutla yapılabilir
curl https://piku.github.io/get | sh
  • Kurulum belgelerinde cloud-init ve manuel kurulum dahil başka kurulum yöntemleri de bulunur
  • Proje STABLE durumda kabul edilir
    • Özellik seti büyük ölçüde tamamlanmıştır
    • Yeni dil çalışma zamanları eklendiğinde veya yeniden üretilebilir hatalar ortaya çıktığında güncellenir
  • Şu anda Python 3.10 ve üzeri gereklidir; testler de Python 3.10 ve üzeri sürümlerde yapılır
  • Destek hedefi, Debian ve Ubuntu LTS'in en güncel iki ana sürümüdür

Git Push tabanlı iş akışı

  • Piku, Heroku benzeri bir iş akışını destekler
  • Uygulama adını depo adı olarak kullanıp Piku sunucusunu işaret eden bir Git SSH remote'u oluşturursunuz
git remote add piku piku@yourserver:appname
  • Kodu push ederek dağıtım yaparsınız
git push piku master
  • Mevcut branch yerine başka bir branch push etmek için şu kullanım geçerlidir
git push piku release-branch-name
  • Dağıtım sürecinde Piku çalışma zamanını algılar, gerekli bağımlılıkları kurar ve gerekiyorsa derleme adımlarını yürütür
    • Python uygulamaları bağımlılıkları uygulama başına ayrı bir virtualenv içinde izole eder
    • Go uygulamaları uygulama başına ayrı bir GOPATH tanımlar
    • Node uygulamaları package.json içindeki girdileri node_modules içine kurar
    • Java uygulamaları pom.xml veya build.gradle dosyasına göre derlenir
    • Clojure uygulamaları leiningen ya da Clojure CLI ve deps.edn dosyasını kullanabilir
    • Ruby uygulamaları gem'leri izole bir klasöre bundle install ile kurar

Çalışma modeli ve yapılandırma

  • Piku, Procfile dosyasını okuyup ilgili worker'ları uwsgi üzerinden çalıştırır
  • uwsgi, genel amaçlı bir süreç yöneticisi olarak kullanılır
  • İsteğe bağlı olarak bir release worker tanımlanabilir; bu worker uygulama dağıtımı sırasında bir kez çalıştırılır
  • Uygulama ayarlarını uzaktan değiştirebilir veya worker süreçlerini artırıp azaltabilirsiniz
    • config:set ile uygulama ayarlarını değiştirirsiniz
    • ps:scale ile worker süreçlerini ölçeklersiniz
  • ENV dosyası uygulama yapılandırmasını ve nginx yapılandırmasını içerebilir
  • static worker türü kullanılarak gh-pages tarzı statik siteler de dağıtılabilir
    • Kök yol parametre olarak verilir
    • git push sonrasında sunucuda işlem yapan release görevleri de çalıştırılabilir

Sanal host, SSL, statik yollar

  • Piku, sanal hostları tam olarak destekler
    • Aynı VPS üzerinde birden fazla uygulama barındırılabilir
    • DNS alias kullanılarak uygulamalara farklı host adlarıyla erişilebilir
  • SSL'yi etkinleştirmek için özel sertifikalar ayarlayabilir veya Let's Encrypt sertifikaları alabilirsiniz
  • LAN içinde macOS, iOS ve Linux istemcilerinden erişiyorsanız, piku/avahi-aliases kullanarak aynı IP için farklı hostları Avahi/mDNS/Bonjour üzerinden duyurabilirsiniz
  • Statik sitelere ek olarak belirli URL prefix'leri doğrudan dosya sistemi yollarına eşlenebilir
  • Uygulama yükünü azaltmak için backend yanıtlarını önbelleğe alma desteği de vardır
  • Statik yol ve önbellekleme özellikleri ENV dosyasındaki değerlerle yapılandırılır

Desteklenen platformlar ve çalışma zamanları

  • Piku, Python, nginx, uwsgi ve SSH bulunan POSIX benzeri ortamlarda çalışacak şekilde tasarlanmıştır
  • Dağıtım örnekleri arasında Linux, FreeBSD, Cygwin ve Windows Subsystem for Linux yer alır
  • Geliştirme 256MB Raspberry Pi Model B üzerinde başladı ve bugün de bu donanımda kararlı biçimde çalışıyor
  • Başlıca kullanım amacı, Intel ve ARM CPU'lu bulut sunucularında uygulama çalıştıran bir mikro PaaS olmaktır
  • Hedef platformlar Debian ve Ubuntu Linux'tur
  • Şu anda Python, Node, Clojure ve Java uygulamalarını destekler; Go gibi bazı diller üzerinde de çalışmalar sürmektedir
  • Genel ilke olarak, shell üzerinden çağrılabiliyorsa Piku içinde de çalıştırılabilir

Tasarım ilkeleri

  • Düşük donanımlı cihazlarda çalışmaya önem verir
  • Hobi geliştiriciler ve K-12 okulları için de erişilebilir olmalıdır
  • Yaklaşık 1500 satırlık okunabilir kod hedefler
  • Fonksiyonel kod stilini tercih eder
  • Az sayıda bağımlılık bulundurmayı amaçlar
  • 12 factor app yaklaşımını izler
  • Kullanıcı deneyimini basitleştirmeye önem verir
  • Yaygın kullanım senaryolarının %80'ini kapsamayı hedefler
  • Tüm özellikler için makul varsayılanlar sunar
  • Raspbian, Debian ve Ubuntu'nun dağıtım paketlerinden yararlanır
    • Alpine ve RHEL desteği üzerinde çalışılmaktadır
  • git, ssh, uwsgi, nginx gibi standart araçları kullanır
  • Mümkün olduğunda geriye dönük uyumluluğu korur

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-10
Hacker News yorumları

  • piku’yu sevdiğim için piku için bir web uygulaması öğreticisi yazdım; bu da resmi GitHub piku organizasyonunun deposuna girdi
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    piku’nun içeride nasıl çalıştığını açıklıyor ve kullanıcı açısından en minimal Python web uygulaması örneğini de gösteriyor

    • Yeni piku belgeleri görünüşte güzel ama piku’yu denemek isteyen yeni kullanıcı açısından neredeyse işe yaramazdı
      Belgeler, piku’yu çalıştırıp kullanmak için gereken her şeyi zaten bildiğinizi varsayıyor gibi geldiği için vazgeçmiştim; bu öğretici o boşluğu dolduruyor
      Ancak epey uzun aramama rağmen bu belgeyi bulamamıştım; buradaki yorum olmasaydı varlığından bile haberdar olmayacaktım
      En azından piku deposunda ve belge ana sayfasında bu belgeye görünür bir bağlantı verilmeli; mümkünse belge ana sayfasına bütünüyle dahil edilmesi daha iyi olur
      Daha da ileri gidip yeni bir bare-metal sunucudan herkese açık erişilebilen özel alan adı ve SSL sertifikasına kadar giden uçtan uca bir öğretici eklemek çok daha faydalı olur
      piku ile doğrudan ilgili olmayan adımlar gibi görünse de yeni kullanıcıların gerçekte istediği şey, 5 dolarlık bir Droplet gibi bir yere kendi sitelerini koymak; aradaki adımları çoğu zaman henüz bilmiyorlar
      Hangi yöntemin seçildiği önemli değil; yöntemi tartışacak kişiler zaten kendi tercih ettikleri yolu biliyordur
      Referans olarak Coolify tarafındaki uçtan uca örnek burada: https://billyle.dev/posts/self-hosting-your-website-with-coo...
      Amaç bunu işlevsel olarak mümkün kılmak değil, daha fazla kişinin kolayca başlamasını sağlayarak piku benimsenme oranını ciddi biçimde artırmak
    • “Heroku tarzı dağıtım nedir” kısmını açıklaması hoşuma gitti
      Heroku’nun ne olduğunu, ne yaptığını hiç bilmiyordum
    • Sadece resmi depoya bakınca yeterince açık değildi; açıklama yardımcı oldu
      Doğru anladıysam piku’nun yapısı, uzak makineye bir ajan kurmak ve yerel makineye commit hook’ları kurmak şeklinde mi?
      Uzak makineyi doğrudan bir Git uzak deposu yapıp, belirli bir branch’e push edildiğinde tüm işleri uzakta yaptırarak ek yük azaltılamaz mıydı diye düşündüm
    • Bu öğretici artık belge ana sayfasından bağlantılanıyor

  • Güzel görünüyor ve Dokku da benim için çok kararlıydı; ancak Docker bağımlılığını kaldırınca artık işletim sisteminin sunduğu seçeneklere bağlı kalıyorsunuz
    Yıllarca bakım görmeden çalışabilecek uygulamalar için ideal değil; sonunda belirli bir işletim sistemi sürümüne ihtiyaç duyduğunuz gerçeğiyle kısa sürede karşılaşıyorsunuz

    • piku’dan farklı bir niş ama Dokku’yu da öneririm
      Küçük yan projeleri VPS’e koymak için Dokku kurulumumu 3-4 Ubuntu LTS yükseltmesi boyunca güncelledim; sorunsuz şekilde iyi çalıştı
    • Bazen Docker fazla kaçıyor; Docker olmadan kullanılabilen bir aracın olması gerçekten sevindirici
    • piku ile Docker birlikte kullanılabilir. Procfile içine docker run ifadeleri koyduğum birkaç şey var; tabii bu kullanım için tasarlanmış değil
      Gördüğüm dağıtımların çoğu çok kararlı dağıtımlarda, genellikle LTS sürümlerinde çalışıyordu; bu yüzden runtime’ı 6 ayda bir yükseltmek gerekmiyordu. Benim web sitem de Ubuntu LTS iki kezden fazla değişirken piku üzerinde çalışmaya devam etti
      Ortam değişkenlerini ayarlayınca pyenv, nvenv gibi şeyler de kolayca kullanılabiliyor
      Ev otomasyon sisteminin artık iki farklı Node sürümüne ihtiyacı var; her uygulama için birer tane yapılandırdım
    • Böyle araçlar kullanırken bağımlılık cehennemi nasıl çözülebilir?
      “Sadece çalışır” yaklaşımı zarif ve Docker’ın teknik ve zihinsel ek yük nedeniyle her yerde kullanılamayacağını da anlıyorum; ama container’ların her şeyi izole edip zamanı durmuş gibi sabitleyebilmesi, 5 yıl sonra bile “sadece çalışır” halde kalmasını sağlaması hoşuma gidiyor
      Benim küçük workflow’umda container yönetimini lazydocker, push ile dağıtımı GitLab workflow’u, build ile GitLab registry’ye push’u ve çalıştırmayı da küçük bir VPS hallediyor
      Biraz fazla kaçıyor; Dockerfile ve compose.yml, docker compose build kombinasyonuyla da mümkün gibi
      Ölçeklemeyi henüz netleştirmedim ama şu an gerekmediği için şanslıyım; gerekirse Docker yerine k8s, lazydocker yerine k9s’ye geçerim gibi geliyor
      DevOps’a yeni girdim; önerilere her zaman açığım
    • Ben docker compose + traefik kullanıyorum
      Sihirli soyutlama daha az olduğu için bana Dokku’dan daha iyi geliyor

  • git push ile dağıtımla doğrudan ilgili değil ama PaaS deneyimiyle yakından bağlantılı olarak, içinde bulunduğum ekip CNCF’nin açık spesifikasyonu olan Cloud Native Buildpacks(CNB) için önizleme yapıyor
    Bunlar OCI’yi hedefleyen Buildpacks; yani Heroku’nun git push mantığı gibi dil desteğini algılayıp uygun şekilde işleyen bir build aracıyla yerelde Docker image’ları oluşturabileceğiniz anlamına geliyor
    Yönettiğim buildpack ile bir Rails uygulaması build etmeye yönelik öğretici burada: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    Denerseniz iyi, kötü ya da kayıtsız fark etmeksizin, bağlantılı tartışmaya deneyiminizi bırakmanız iyileştirmeye yardımcı olur

  • piku’yu ilk kez gördüm
    Nedenini bilmiyorum ama piku gibi git push ile dağıtımın başlaması hissi bana hep sihir gibi gelmiştir; bundan daha basiti olamaz diye düşünüyorum
    Tesadüfen dün aynı alandaki Kubernetes projemi açık kaynak olarak yayımladım, burada: https://github.com/pier-oliviert/sequencer
    Her neyse, tebrikler; iyi görünüyor

    • Sihir gibi çalışıyor ama öğrenmek istiyorsanız kendiniz yapmak da çok basit
      Sunucuda git init --bare ile bir Git deposu oluşturup git config receive.denyCurrentBranch updateInstead ayarını yapmanız yeterli
      Ardından Git hook’larıyla, daha özel olarak push-to-checkout hook’u ile yüklemeyi alabilir, derleyebilir ve çalıştırabilirsiniz
      Hook basit bir shell script’tir; en temel hâli compile && install && systemctl restart service gibi bir varyasyon olabilir
      Sonrasında depoyu yerelde klonlarsanız, değişiklikleri push ettiğinizde ayarladığınız hook çalışır
      git clone root@yourserver.com:/path/to/git/folder
    • Bariz bir şeyi mi kaçırıyorum bilmiyorum ama sequencer Heroku/Dokku/piku’ya benziyorsa Git ile dağıtımı nasıl yaptığını merak ediyorum
      Açıklamaya göre git push dağıtımı değil de Kubernetes şablonları ve kubectl ile uğraşıyor gibi; bu durumda tamamen farklı bir alandaki proje gibi görünüyor

  • Yenilenmiş piku belgelerini burada görebilirsiniz: https://piku.github.io/

    • Bu Dokku’nun devamı mı? İkinci bir proje olduğunu bilmiyordum

  • İlk commit 8 yıl önce miydi?
    Keşke bu projeden yaklaşık 18 ay önce haberim olsaydı; Raspberry Pi’ye Heroku benzeri bir geliştirme deneyimiyle dağıtım yapmanın yolunu arıyordum ve piku tam olarak bunu hedefliyor gibi görünüyor

    • Kesinlikle. Bir görünürlük sorunu var
      Az önce CapRover ile yeni bir VPS kurdum; “Heroku tarzı self-hosted PaaS” karşılaştırmalarını yaklaşık bir saat ararken Dokku, CapRover, Coolify, Dokploy gördüm ama piku’yu hiç görmedim

  • Bakımcısı ve ortak yazarıyım
    Basit ve minimal dağıtım araçlarını seviyorsanız, cloud-init’i çok daha gerçekçi ele alan https://github.com/rcarmo/ground-init’e de bakarsanız sevinirim

    • Sadece README’ye bakınca bunun neden cloud-init olmaması gerektiğinin cevabı pek görünmüyor

  • Kesintisiz dağıtımı nasıl ele aldığına dair bir yöntem olup olmadığını merak ediyorum
    Örneğin bir Python servisi tek bir makinede 8080 portunda nginx arkasında çalışıyorsa, piku aynı portta yeni instance’a nasıl geçiyor?

    • Şu anda yeni git push dağıtımı bittikten sonra çalışan süreci sonlandırıyor
      Soket ve oturum yönetimi, kodun nasıl yazıldığına, uwsgi kullanıp kullanmadığına ya da doğrudan HTTP daemon’u çalıştırıp çalıştırmadığına bağlı
      Halihazırda isteğe bağlı desteklenen özelliklerden biri, kullanılmayan ve boşta olan instance’ları sonlandırmak ve yeni bağlantı geldiğinde gecikmeli başlatmak
    • Konudan biraz sapıyor ama systemd socket activation kullanırsanız kesintisiz dağıtım yapabilirsiniz

  • Aynı işi Kubernetes üzerinde yapan Epinio’yu seviyorum
    SUSE tarafından destekleniyor; örneğin GCP Cloud Run’ın temeli olan KNative’den daha hafif, ama Kubernetes tabanlı olduğu için Dokku veya piku’ya kıyasla hâlâ daha fazla kaynağa ihtiyaç duyuyor
    Yine de olgun çözüm ekosistemi geniş olduğu için k8s’i daha çok tercih ediyorum
    Tek bir sunucuda da hepsi çalıştırılabilir; sadece biraz daha büyük bir sunucu gerekir
    Yeni Hetzner CX42; 8 vCPU, 16 GB RAM, 160 GB disk ile aylık €16.40, saatlik €0.0273; bu yeterli ve Kube Hetzner projesini kullanırsanız otomatik güncellenen MicroOS tabanlı bir Kubernetes cluster’ını 5 dakika içinde kurabilirsiniz
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • “Epinio aynı işi Kubernetes üzerinde yapıyor” deniyorsa, aslında bunun hiç de aynı şey olmadığı söylenemez mi?
      piku’nun özünün Docker olmadan Heroku benzeri bir deneyim sunmak, mimarisinin gerçekten basit olması ve ARM’de de çalışması olduğunu düşünüyorum
      Kubernetes’in ARM’de çalıştığını kabul ediyorum ama bildiğim kadarıyla Kubernetes, Docker olsun ya da başka bir şey, bir tür container gerektiriyor; mimarisi de bariz nedenlerle asla basit değil
      Ayrıca Epinio’nun git push akışını mümkün kılıp kılmadığından da emin değilim
      Hızlı başlangıç öğreticisi, uygulama dağıtımı için epinio push manifest.yaml gibi bir komut kullanılmasını söylüyor gibi; bu da “Heroku benzeri deneyim”e uymuyor
      Sonuçta ortak noktaları sadece dağıtımı ele almaları gibi geliyor

  • Minimal yaklaşımı hoşuma gitti, denemeyi planlıyorum
    Benzer şekilde bakılabilecek başka şeyler de var
    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