Piku - เทคโนโลยีที่ทำให้สามารถดีพลอยด้วย Git Push บนเซิร์ฟเวอร์ของตัวเองได้

 (github.com/piku)
4 คะแนน โดย GN⁺ 2024-06-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Piku เป็นเครื่องมือที่ได้แรงบันดาลใจจาก Dokku ซึ่งทำให้สามารถดีพลอยแอปพลิเคชันแบบ git push ได้แม้บนเซิร์ฟเวอร์ขนาดเล็กของตัวเอง
  • มุ่งไปที่แนวทางแบบ Heroku/CloudFoundry แต่ในเวลานั้น Dokku ยังทำงานบน ARM ไม่ได้ และ Docker ก็อาจจะเกินความจำเป็น จึงตั้งเป้าเป็น วิธีดีพลอยที่เรียบง่ายกว่า
  • ระหว่างการดีพลอย ระบบจะตรวจจับรันไทม์ ติดตั้ง dependency แล้วอ่าน Procfile เพื่อรัน worker ด้วย uwsgi โดยครอบคลุมการจัดการที่เกี่ยวข้องกับ Python, Node, Java, Clojure, Ruby และ Go
  • สามารถดีพลอย จัดการ และสเกลหลายแอปอย่างอิสระบนโฮสต์เดียวได้ พร้อมรองรับ virtual host, SSL, เว็บไซต์แบบสแตติก, การแมปพาธ URL และการแคชการตอบสนองของแบ็กเอนด์
  • ต้องใช้ Python 3.10 ขึ้นไป รวมถึง Python, nginx, uwsgi และ SSH และเป็นโปรเจ็กต์ในสถานะ เสถียร ที่มุ่งรองรับ Debian และ Ubuntu LTS รุ่นหลักล่าสุด 2 รุ่น

ปัญหาที่ Piku แก้ไข

  • Piku เป็นเครื่องมือที่ช่วยให้ดีพลอยแบบ git push บนเซิร์ฟเวอร์ของตัวเองได้
  • ได้แรงบันดาลใจจาก Dokku และตั้งเป้าให้ทำงานได้แม้บนเซิร์ฟเวอร์ขนาดเล็กมาก
  • ต้องการประสบการณ์ดีพลอยคล้าย Heroku/CloudFoundry บนบอร์ด ARM ไม่กี่เครื่อง แต่ในเวลานั้น Dokku ยังทำงานบน ARM ไม่ได้ และบางครั้ง Docker ก็เกินความจำเป็น จึงต้องการทางออกที่เรียบง่ายกว่า
  • ปัจจุบันสามารถดีพลอย จัดการ และสเกลแอปพลิเคชันหลายตัวต่อโฮสต์ได้อย่างอิสระ ทั้งบนสถาปัตยกรรม ARM และ Intel
  • ทำงานได้ทั้งบนผู้ให้บริการคลาวด์และสภาพแวดล้อมแบบ bare metal ที่สามารถรัน Python, nginx และ uwsgi ได้

การติดตั้งและสถานะของโปรเจ็กต์

  • การติดตั้งพื้นฐานทำได้ด้วยคำสั่งต่อไปนี้
curl https://piku.github.io/get | sh
  • เอกสารการติดตั้ง ยังมีวิธีติดตั้งอื่น รวมถึง cloud-init และการติดตั้งด้วยตนเอง
  • โปรเจ็กต์นี้ถือว่าอยู่ในสถานะ STABLE
    • ชุดความสามารถเกือบสมบูรณ์แล้ว
    • จะมีการอัปเดตเมื่อมีการเพิ่ม language runtime ใหม่หรือเกิดบั๊กที่ทำซ้ำได้
  • ปัจจุบันต้องใช้ Python 3.10 ขึ้นไป และการทดสอบก็ทำกับ Python 3.10 ขึ้นไปเช่นกัน
  • เป้าหมายการรองรับคือ Debian และ Ubuntu LTS รุ่นหลักล่าสุด 2 รุ่น

เวิร์กโฟลว์แบบ Git Push

  • Piku รองรับ เวิร์กโฟลว์ที่คล้าย Heroku
  • ใช้ชื่อแอปเป็นชื่อรีโพซิทอรีเพื่อสร้าง Git SSH remote ที่ชี้ไปยังเซิร์ฟเวอร์ Piku
git remote add piku piku@yourserver:appname
  • พุชโค้ดเพื่อดีพลอย
git push piku master
  • หากต้องการพุชสาขาอื่นที่ไม่ใช่สาขาปัจจุบัน ให้ใช้แบบนี้
git push piku release-branch-name
  • ระหว่างการดีพลอย Piku จะตรวจจับรันไทม์ ติดตั้ง dependency ที่จำเป็น และทำการ build ตามต้องการ
    • แอป Python จะแยก dependency ด้วย virtualenv รายแอป
    • แอป Go จะกำหนด GOPATH แยกต่อแอป
    • แอป Node จะติดตั้งรายการใน package.json ลงใน node_modules
    • แอป Java จะ build ตาม pom.xml หรือ build.gradle
    • แอป Clojure สามารถใช้ leiningen หรือ Clojure CLI และไฟล์ deps.edn ได้
    • แอป Ruby จะติดตั้ง gem ด้วย bundle install ลงในโฟลเดอร์ที่แยกออกมา

โมเดลการรันและการตั้งค่า

  • Piku อ่าน Procfile และรัน worker ที่เกี่ยวข้องผ่าน uwsgi
  • uwsgi ถูกใช้เป็น process manager แบบอเนกประสงค์
  • สามารถระบุ worker แบบ release เพิ่มเติมได้ โดย worker นี้จะรันหนึ่งครั้งเมื่อมีการดีพลอยแอป
  • สามารถเปลี่ยนการตั้งค่าแอปพลิเคชันหรือเพิ่มลดจำนวน worker process ได้จากระยะไกล
    • เปลี่ยนการตั้งค่าแอปพลิเคชันด้วย config:set
    • สเกล worker process ด้วย ps:scale
  • ไฟล์ ENV สามารถรวมทั้งการตั้งค่าแอปพลิเคชันและการตั้งค่า nginx ได้
  • หากใช้ worker type แบบ static ก็สามารถดีพลอยเว็บไซต์สแตติกสไตล์ gh-pages ได้เช่นกัน
    • ระบุพาธรากเป็นอาร์กิวเมนต์
    • ยังสามารถรันงาน release ที่ประมวลผลบนเซิร์ฟเวอร์หลัง git push ได้ด้วย

Virtual host, SSL และพาธสแตติก

  • Piku รองรับ virtual host อย่างสมบูรณ์
    • สามารถโฮสต์หลายแอปบน VPS เดียวกันได้
    • สามารถใช้ DNS alias เพื่อเข้าถึงแอปด้วยชื่อโฮสต์ที่ต่างกันได้
  • สำหรับการเปิดใช้ SSL สามารถตั้งค่าใบรับรองส่วนตัว หรือขอใบรับรองจาก Let's Encrypt ได้
  • หากเข้าถึงผ่าน LAN จากไคลเอนต์ macOS, iOS หรือ Linux สามารถใช้ piku/avahi-aliases เพื่อประกาศโฮสต์หลายชื่อบน IP เดียวกันผ่าน Avahi/mDNS/Bonjour ได้
  • นอกจากเว็บไซต์สแตติกแล้ว ยังสามารถแมป URL prefix เฉพาะเข้ากับพาธในระบบไฟล์ได้โดยตรง
  • ยังรองรับการแคชการตอบสนองของแบ็กเอนด์เพื่อลดภาระของแอปพลิเคชัน
  • ความสามารถด้านพาธสแตติกและการแคชตั้งค่าผ่านค่าในไฟล์ ENV

แพลตฟอร์มและรันไทม์ที่รองรับ

  • Piku ถูกออกแบบมาให้ทำงานบน สภาพแวดล้อมคล้าย POSIX ที่มี Python, nginx, uwsgi และ SSH
  • ตัวอย่างการนำไปใช้งานมีทั้ง Linux, FreeBSD, Cygwin, Windows Subsystem for Linux
  • การพัฒนาเริ่มต้นบน Raspberry Pi Model B ที่มี RAM 256MB และปัจจุบันก็ยังทำงานได้อย่างเสถียรบนอุปกรณ์นั้น
  • การใช้งานหลักคือเป็น micro PaaS สำหรับรันแอปบนคลาวด์เซิร์ฟเวอร์ที่ใช้ CPU Intel และ ARM
  • แพลตฟอร์มเป้าหมายคือ Debian และ Ubuntu Linux
  • ปัจจุบันรองรับแอป Python, Node, Clojure และ Java และกำลังดำเนินการกับภาษาอื่นบางตัว เช่น Go
  • ตามหลักทั่วไป หากเรียกใช้ได้จากเชลล์ ก็สามารถรันภายใน Piku ได้

หลักการออกแบบ

  • ให้ความสำคัญกับการทำงานบนอุปกรณ์สเปกต่ำ
  • ต้องเข้าถึงได้สำหรับนักพัฒนาแบบงานอดิเรกและโรงเรียนระดับ K-12
  • มุ่งไปที่โค้ดอ่านง่ายประมาณ 1500 บรรทัด
  • ชื่นชอบสไตล์โค้ดแบบฟังก์ชันนัล
  • ตั้งเป้าลด dependency ให้เหลือน้อย
  • ปฏิบัติตาม 12 factor app
  • ให้ความสำคัญกับการทำให้ประสบการณ์ผู้ใช้งานเรียบง่าย
  • ตั้งเป้าครอบคลุม 80% ของกรณีใช้งานทั่วไป
  • มีค่าเริ่มต้นที่เหมาะสมสำหรับทุกความสามารถ
  • ใช้แพ็กเกจจากดิสทริบิวชันของ Raspbian, Debian และ Ubuntu
    • การรองรับ Alpine และ RHEL อยู่ระหว่างดำเนินการ
  • ใช้เครื่องมือมาตรฐานอย่าง git, ssh, uwsgi, nginx
  • พยายามรักษา ความเข้ากันได้ย้อนหลัง เมื่อเป็นไปได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-10
ความคิดเห็นบน Hacker News

  • ชอบ piku เลยเขียนบทแนะนำการทำเว็บแอปสำหรับ piku และตอนนี้มันถูกนำเข้าไปอยู่ในรีโพซิทอรีขององค์กร piku อย่างเป็นทางการบน GitHub แล้ว
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    อธิบายว่าภายใน piku ทำงานอย่างไร และยังแสดงตัวอย่าง เว็บแอป Python ขั้นต่ำจากมุมมองของผู้ใช้ด้วย

    • เอกสาร piku ใหม่ดูสวย แต่แทบไม่มีประโยชน์สำหรับผู้ใช้ใหม่ที่อยากลองใช้ piku
      รู้สึกเหมือนเอกสารสมมติว่าคุณรู้อยู่แล้วว่าต้องรู้อะไรบ้างเพื่อรันและใช้งาน piku เลยถอดใจไป แต่บทแนะนำนี้ช่วยเติมช่องว่างตรงนั้น
      อย่างไรก็ดี ถึงจะค้นหามาค่อนข้างนานก็ยังไม่เจอเอกสารนี้ และถ้าไม่ได้เห็นคอมเมนต์ที่นี่ก็คงไม่รู้เลยว่ามีอยู่
      อย่างน้อยควรลิงก์เอกสารนี้ให้เด่นจากรีโพซิทอรี piku และหน้าแรกของเอกสาร และถ้าเป็นไปได้ก็ควรรวมทั้งเอกสารนี้ไว้ในหน้าแรกของเอกสารเลย
      ยิ่งไปกว่านั้น ถ้าเพิ่มบทแนะนำแบบ end-to-end ตั้งแต่เซิร์ฟเวอร์ bare metal ใหม่ไปจนถึง โดเมนแบบกำหนดเองและใบรับรอง SSL ที่เข้าถึงได้จากสาธารณะ จะช่วยได้มากกว่านี้
      แม้จะดูเหมือนเป็นขั้นตอนที่ไม่เกี่ยวกับ piku โดยตรง แต่สิ่งที่ผู้ใช้ใหม่ต้องการจริง ๆ คือเอาเว็บไซต์ของตัวเองขึ้นไปไว้บนที่อย่าง Droplet ราคา $5 และหลายคนยังไม่รู้ขั้นตอนระหว่างทาง
      จะเลือกวิธีไหนก็ได้ และคนที่จะถกเรื่องวิธีก็คงรู้วิธีที่ตัวเองชอบอยู่แล้ว
      อ้างอิง ตัวอย่าง end-to-end ของฝั่ง Coolify อยู่ที่นี่: https://billyle.dev/posts/self-hosting-your-website-with-coo...
      เป้าหมายไม่ใช่แค่ทำให้ทำงานได้ในเชิงฟังก์ชัน แต่คือทำให้คนจำนวนมากขึ้นเริ่มต้นได้ง่าย เพื่อเพิ่ม อัตราการนำ piku ไปใช้ อย่างมาก
    • ดีที่อธิบายว่า “การ deploy แบบ Heroku” คืออะไร
      ไม่เคยรู้เลยว่า Heroku คืออะไรหรือทำอะไร
    • ดูจากรีโพซิทอรีทางการอย่างเดียวแล้วยังไม่ชัดเจนพอ คำอธิบายนี้ช่วยได้
      ถ้าเข้าใจถูก piku มีโครงสร้างแบบติดตั้ง agent บนเครื่อง remote และติดตั้ง commit hook บนเครื่อง local ใช่ไหม?
      คิดว่าถ้าทำให้เครื่อง remote เป็นแค่ Git remote repository แล้วให้ฝั่ง remote ทำงานทั้งหมดเมื่อ push ไปยัง branch ที่กำหนด น่าจะลด overhead ได้หรือเปล่า
    • ตอนนี้บทแนะนำนี้ถูกลิงก์จาก หน้าแรกของเอกสาร แล้ว

  • ดูดี และ Dokku ก็เสถียรมากสำหรับผม แต่ถ้าตัด dependency บน Docker ออก ตอนนี้คุณก็จะถูกผูกกับตัวเลือกที่ระบบปฏิบัติการมีให้
    ไม่เหมาะกับแอปที่อาจรันไปได้หลายปีโดยไม่ต้องดูแล และสุดท้ายไม่นานก็จะเจอว่าต้องใช้ระบบปฏิบัติการเวอร์ชันใดเวอร์ชันหนึ่ง

    • แม้จะเป็นคนละ niche กับ piku แต่ก็ขอแนะนำ Dokku
      ผมใช้ Dokku เพื่อนำโปรเจกต์เสริมเล็ก ๆ ขึ้น VPS และอัปเกรดการติดตั้งผ่าน Ubuntu LTS มา 3–4 รอบแล้ว ก็ยังทำงานได้ดีไม่มีปัญหา
    • บางครั้ง Docker ก็เกินความจำเป็น และดีใจจริง ๆ ที่มีเครื่องมือที่ใช้ได้โดยไม่ต้องมี Docker
    • ใช้ piku ร่วมกับ Docker ได้ ผมมีบางตัวที่ใส่คำสั่ง docker run ไว้ใน Procfile ด้วย แต่แน่นอนว่ามันไม่ได้ถูกออกแบบมาเพื่อการใช้งานแบบนั้น
      deployment ส่วนใหญ่ที่ผมเห็นอยู่บนดิสโทรที่เสถียรมาก ปกติเป็นเวอร์ชัน LTS เลยไม่จำเป็นต้องอัปเดตรันไทม์ทุก 6 เดือน และเว็บไซต์ของผมก็รันบน piku ต่อเนื่องมาตลอด แม้ Ubuntu LTS จะเปลี่ยนไปมากกว่าสองครั้งแล้ว
      แค่ตั้ง environment variable ก็ใช้ของอย่าง pyenv, nvenv ได้ง่าย
      ระบบ home automation ของผมตอนนี้ต้องใช้ Node version สองเวอร์ชันที่ต่างกัน และก็ตั้งค่าแยกไว้ต่อแอปแล้ว
    • เวลาใช้เครื่องมือแบบนี้จะแก้ dependency hell อย่างไรได้บ้าง?
      ท่าทีแบบ “มันก็แค่ใช้ได้” นั้นดูเรียบง่ายงดงาม และผมก็เข้าใจว่า Docker ใช้ไม่ได้ทุกที่เพราะมี overhead ทั้งทางเทคนิคและทางความคิด แต่สิ่งที่ดีของ container คือมันแยกทุกอย่างออกจากกันและตรึงไว้เหมือนหยุดเวลา ทำให้ผ่านไป 5 ปีก็ยัง “แค่ทำงานได้”
      ใน workflow เล็ก ๆ ของผม การจัดการ container ใช้ lazydocker, การ deploy ด้วย push ใช้ GitLab workflow, ส่วน build กับ push ไป GitLab registry และรัน ใช้ VPS เล็ก ๆ เครื่องเดียวจัดการ
      มันอาจจะเกินไปนิด และคิดว่าน่าจะทำได้ด้วยชุด Dockerfile, compose.yml, docker compose build ก็พอ
      ยังไม่ได้จัดการเรื่องการ scale ให้เรียบร้อย แต่ตอนนี้ยังไม่ต้องใช้ก็โชคดี และถ้าจำเป็นขึ้นมาก็คงเปลี่ยนจาก Docker เป็น k8s และจาก lazydocker เป็น k9s
      เพิ่งเข้ามาในสาย DevOps จึงยินดีรับคำแนะนำเสมอ
    • ผมใช้ docker compose + traefik
      มี abstraction แบบเวทมนตร์น้อยกว่า เลยเหมาะกับผมมากกว่า Dokku

  • แม้จะไม่เกี่ยวโดยตรงกับการ deploy ด้วย git push แต่เกี่ยวข้องอย่างใกล้ชิดกับประสบการณ์แบบ PaaS ทีมที่ผมอยู่กำลัง preview Cloud Native Buildpacks(CNB) ซึ่งเป็นสเปกเปิดของ CNCF
    นี่คือ Buildpacks ที่มุ่งเป้าไปยัง OCI หมายความว่าสามารถสร้าง Docker image ในเครื่องได้ด้วยเครื่องมือ build ที่ตรวจจับการรองรับภาษาแล้วจัดการให้อย่างเหมาะสม เหมือนตรรกะ git push ของ Heroku
    บทแนะนำการ build แอป Rails ด้วย buildpack ที่ผมดูแลอยู่ที่นี่: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    ถ้าได้ลองใช้ ไม่ว่าจะเป็นข้อดี ข้อเสีย หรือความรู้สึกเฉย ๆ การฝากประสบการณ์ไว้ใน discussion ที่ลิงก์ไว้จะช่วยให้ปรับปรุงได้

  • เพิ่งเห็น piku เป็นครั้งแรก
    ไม่รู้เหมือนกันว่าทำไม แต่ความรู้สึกที่การ deploy เริ่มด้วย git push แบบ piku นั้นดูเหมือนเวทมนตร์เสมอ และรู้สึกว่าไม่มีอะไรจะเรียบง่ายไปกว่านี้แล้ว
    พอดีเมื่อวานเพิ่งเปิดซอร์สโปรเจกต์สำหรับ Kubernetes ในขอบเขตเดียวกันไว้ อยู่ที่นี่: https://github.com/pier-oliviert/sequencer
    ยังไงก็ขอแสดงความยินดี ดูดีมาก

    • มันทำงานเหมือนเวทมนตร์ก็จริง แต่ถ้าอยากเรียนรู้ การทำเองก็เรียบง่ายมาก
      แค่สร้าง Git repository บนเซิร์ฟเวอร์ด้วย git init --bare แล้วตั้งค่า git config receive.denyCurrentBranch updateInstead
      จากนั้นก็ใช้ Git hook หรือให้เจาะจงคือ push-to-checkout hook เพื่อรับอัปโหลด คอมไพล์ และรันได้
      hook เป็นเชลล์สคริปต์ง่าย ๆ และรูปแบบพื้นฐานที่สุดก็เป็นตัวแปรอย่าง compile && install && systemctl restart service ก็พอ
      หลังจากนั้น เมื่อ clone repository มาที่เครื่อง local แล้ว push การเปลี่ยนแปลง hook ที่ตั้งไว้ก็จะถูกเรียกใช้
      git clone root@yourserver.com:/path/to/git/folder
    • ไม่แน่ใจว่าผมพลาดอะไรที่ชัดเจนไปหรือเปล่า แต่ถ้า sequencer คล้ายกับ Heroku/Dokku/piku ก็สงสัยว่าทำ deploy ด้วย Git อย่างไร
      จากคำอธิบายดูเหมือนจะจัดการ Kubernetes template กับ kubectl มากกว่าจะเป็นการ deploy ด้วย git push แบบนั้นก็เลยดูเป็นโปรเจกต์คนละแนวไปเลย

  • เอกสาร piku ที่ปรับปรุงใหม่ดูได้ที่นี่: https://piku.github.io/

    • นี่เป็นภาคต่อของ Dokku หรือเปล่า? ไม่รู้เลยว่ามีโปรเจกต์ที่สองด้วย

  • commit แรกสุดคือ 8 ปีก่อน เลยเหรอ?
    ถ้ารู้จักโปรเจกต์นี้เมื่อราว 18 เดือนก่อนก็คงดี ตอนนั้นกำลังหาวิธี deploy ลง Raspberry Pi ด้วยประสบการณ์พัฒนาแบบ Heroku และ piku ก็ดูเหมือนจะมุ่งเป้าทำสิ่งนั้นพอดี

    • ถูกต้อง มี ปัญหาเรื่องการมองเห็น
      เพิ่งตั้งค่า VPS ใหม่ด้วย CapRover ไป และระหว่างที่ค้นหาการเปรียบเทียบ “self-hosted PaaS แบบ Heroku” อยู่ประมาณหนึ่งชั่วโมง ก็เห็น Dokku, CapRover, Coolify, Dokploy แต่ไม่เห็น piku เลย

  • เป็น maintainer และผู้ร่วมเขียน
    ถ้าชอบเครื่องมือ deploy ที่เรียบง่ายและมินิมอล อยากให้ดู https://github.com/rcarmo/ground-init ด้วย ซึ่งจัดการ cloud-init ในเชิงใช้งานจริงมากกว่าเยอะ

    • ดูแค่ README แล้วยังไม่ค่อยเห็นคำตอบว่าทำไมถึงไม่ควรเป็น cloud-init

  • สงสัยว่ามีวิธีจัดการ zero-downtime deployment หรือไม่
    เช่น ถ้า service Python รันอยู่หลัง nginx บนพอร์ต 8080 ของเครื่องเดียว piku จะสลับไปยัง instance ใหม่บนพอร์ตเดียวกันได้อย่างไร?

    • ตอนนี้จะ terminate process ที่กำลังรันอยู่หลังจาก deploy ด้วย git push ชุดใหม่เสร็จแล้วเท่านั้น
      การจัดการ socket และ session จะขึ้นอยู่กับว่าโค้ดเป็นอย่างไร ใช้ uwsgi หรือเปิด HTTP daemon เอง
      หนึ่งในฟีเจอร์ที่รองรับแบบ optional อยู่แล้วคือการปิด instance ที่ไม่ได้ใช้งานและ idle instance แล้วค่อยเริ่มแบบหน่วงเวลาเมื่อมี connection ใหม่เข้ามา
    • อาจจะนอกประเด็นเล็กน้อย แต่ถ้าใช้ systemd socket activation ก็ทำ zero-downtime deployment ได้

  • ชอบ Epinio ที่ทำสิ่งเดียวกันบน Kubernetes
    SUSE สนับสนุนอยู่ และเบากว่า KNative ซึ่งเป็นพื้นฐานของ GCP Cloud Run เป็นต้น แต่เพราะยังอิง Kubernetes จึงยังต้องใช้ resource มากกว่า Dokku หรือ piku
    ถึงอย่างนั้นก็ยังชอบ k8s มากกว่า เพราะมี ecosystem ของโซลูชันที่成熟และกว้างกว่า
    รันทั้งหมดบนเซิร์ฟเวอร์เครื่องเดียวได้ เพียงแต่ต้องใช้เซิร์ฟเวอร์ที่ใหญ่ขึ้นเล็กน้อย
    Hetzner CX42 รุ่นใหม่มี 8 vCPU, RAM 16GB, ดิสก์ 160GB ราคาเดือนละ €16.40 หรือ €0.0273 ต่อชั่วโมง ก็เพียงพอแล้ว และถ้าใช้โปรเจกต์ Kube Hetzner ก็สามารถตั้งค่า Kubernetes cluster ที่ใช้ MicroOS พร้อมอัปเดตอัตโนมัติได้ภายใน 5 นาที
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • ถ้า “Epinio ทำสิ่งเดียวกันบน Kubernetes” จริง ๆ แล้วแทบจะไม่ใช่สิ่งเดียวกันเลยไม่ใช่หรือ?
      แก่นของ piku ดูจะอยู่ที่การให้ ประสบการณ์แบบ Heroku โดยไม่ใช้ Docker มีสถาปัตยกรรมที่เรียบง่ายจริง ๆ และทำงานบน ARM ได้
      ยอมรับว่า Kubernetes ทำงานบน ARM ได้ แต่เท่าที่รู้ Kubernetes ต้องการ container ในรูปแบบใดรูปแบบหนึ่ง ไม่ว่าจะเป็น Docker หรืออย่างอื่น และสถาปัตยกรรมก็ไม่มีทางเรียบง่ายด้วยเหตุผลที่ชัดเจน
      แถมยังไม่แน่ใจด้วยว่า Epinio ทำ flow แบบ git push ได้หรือไม่
      quick start tutorial ดูเหมือนจะให้ใช้คำสั่งอย่าง epinio push manifest.yaml สำหรับ deploy แอปพลิเคชัน ดังนั้นจึงไม่ตรงกับ “ประสบการณ์แบบ Heroku” ด้วย
      สุดท้ายแล้ว จุดร่วมก็คงมีแค่ จัดการการ deploy เท่านั้นหรือเปล่า

  • ชอบแนวทางแบบมินิมอล เลยว่าจะลองใช้ดู
    ยังมีตัวอื่น ๆ ที่น่าดูในแนวคล้ายกันด้วย
    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