Piku - Công nghệ cho phép triển khai bằng Git Push trên máy chủ tự quản

 (github.com/piku)
4 điểm bởi GN⁺ 2024-06-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • Piku là một công cụ lấy cảm hứng từ Dokku, cho phép triển khai ứng dụng theo cách git push ngay cả trên các máy chủ tự quản nhỏ
  • Hướng tới quy trình giống Heroku/CloudFoundry, nhưng vào thời điểm đó Dokku không chạy trên ARM và Docker đôi khi là quá mức cần thiết, nên mục tiêu là một cách triển khai đơn giản hơn
  • Khi triển khai, công cụ sẽ nhận diện runtime, cài đặt phụ thuộc, sau đó đọc Procfile và chạy worker bằng uwsgi, bao gồm xử lý cho Python, Node, Java, Clojure, Ruby và Go
  • Có thể triển khai, quản lý và scale nhiều ứng dụng độc lập trên một host duy nhất, đồng thời hỗ trợ virtual host, SSL, trang tĩnh, ánh xạ đường dẫn URL và cache phản hồi backend
  • Yêu cầu Python 3.10 trở lên cùng Python, nginx, uwsgi, SSH, và là một dự án ở trạng thái ổn định với mục tiêu hỗ trợ hai phiên bản chính Debian và Ubuntu LTS mới nhất

Vấn đề mà Piku giải quyết

  • Piku là công cụ cho phép triển khai bằng git push trên máy chủ tự quản
  • Được lấy cảm hứng từ Dokku và hướng tới mục tiêu hoạt động được cả trên các máy chủ rất nhỏ
  • Muốn có trải nghiệm triển khai tương tự Heroku/CloudFoundry trên vài bo mạch ARM, nhưng khi đó Dokku không chạy trên ARM và có lúc Docker là quá nặng, nên cần một giải pháp đơn giản hơn
  • Hiện nay có thể triển khai, quản lý và scale độc lập nhiều ứng dụng trên mỗi host ở cả kiến trúc ARM lẫn Intel
  • Hoạt động trên các nhà cung cấp cloud và môi trường bare metal có thể chạy Python, nginx, uwsgi

Cài đặt và trạng thái dự án

  • Có thể cài đặt cơ bản bằng lệnh sau
curl https://piku.github.io/get | sh
  • Tài liệu cài đặt cũng có các cách cài khác, bao gồm cloud-init và cài đặt thủ công
  • Dự án được xem là ở trạng thái STABLE
    • Bộ tính năng gần như đã hoàn thiện
    • Sẽ được cập nhật khi có thêm runtime ngôn ngữ mới hoặc xuất hiện lỗi có thể tái hiện
  • Hiện tại yêu cầu Python 3.10 trở lên, và việc kiểm thử cũng nhắm tới Python 3.10 trở lên
  • Mục tiêu hỗ trợ là hai phiên bản chính Debian và Ubuntu LTS mới nhất

Quy trình dựa trên Git Push

  • Piku hỗ trợ quy trình tương tự Heroku
  • Dùng tên ứng dụng làm tên kho chứa để tạo Git SSH remote trỏ tới máy chủ Piku
git remote add piku piku@yourserver:appname
  • Push mã nguồn để triển khai
git push piku master
  • Nếu muốn push một nhánh khác thay vì nhánh hiện tại, dùng như sau
git push piku release-branch-name
  • Trong quá trình triển khai, Piku sẽ nhận diện runtime, cài các phụ thuộc cần thiết và thực hiện build nếu cần
    • Ứng dụng Python tách phụ thuộc bằng virtualenv riêng cho từng ứng dụng
    • Ứng dụng Go định nghĩa GOPATH riêng cho từng ứng dụng
    • Ứng dụng Node cài các mục trong package.json vào node_modules
    • Ứng dụng Java build theo pom.xml hoặc build.gradle
    • Ứng dụng Clojure có thể dùng leiningen hoặc Clojure CLI và tệp deps.edn
    • Ứng dụng Ruby chạy bundle install gem vào thư mục cách ly

Mô hình vận hành và cấu hình

  • Piku đọc Procfile và chạy các worker liên quan thông qua uwsgi
  • uwsgi được dùng như một trình quản lý tiến trình đa dụng
  • Có thể tùy chọn chỉ định worker release, worker này sẽ chạy một lần khi triển khai ứng dụng
  • Có thể thay đổi cấu hình ứng dụng từ xa hoặc tăng giảm số lượng tiến trình worker
    • Dùng config:set để thay đổi cấu hình ứng dụng
    • Dùng ps:scale để scale tiến trình worker
  • Tệp ENV có thể chứa cấu hình ứng dụng và cấu hình nginx
  • Nếu dùng kiểu worker static, cũng có thể triển khai trang tĩnh theo kiểu gh-pages
    • Chỉ định đường dẫn gốc bằng tham số
    • Cũng có thể chạy tác vụ release để xử lý trên máy chủ sau git push

Virtual host, SSL, đường dẫn tĩnh

  • Piku hỗ trợ đầy đủ virtual host
    • Có thể host nhiều ứng dụng trên cùng một VPS
    • Có thể dùng DNS alias để truy cập ứng dụng bằng các hostname khác nhau
  • Để bật SSL, có thể cấu hình chứng chỉ riêng hoặc lấy chứng chỉ từ Let's Encrypt
  • Nếu truy cập trong LAN từ các client macOS, iOS, Linux, có thể dùng piku/avahi-aliases để công bố các host khác nhau trên cùng một IP qua Avahi/mDNS/Bonjour
  • Ngoài trang tĩnh, còn có thể ánh xạ trực tiếp một URL prefix cụ thể tới đường dẫn filesystem
  • Cũng hỗ trợ cache phản hồi backend để giảm tải cho ứng dụng
  • Tính năng đường dẫn tĩnh và cache được cấu hình bằng các giá trị trong tệp ENV

Nền tảng và runtime được hỗ trợ

  • Piku được thiết kế để hoạt động trên môi trường giống POSIX có Python, nginx, uwsgi, SSH
  • Các trường hợp triển khai bao gồm Linux, FreeBSD, Cygwin, Windows Subsystem for Linux
  • Việc phát triển bắt đầu trên Raspberry Pi Model B 256MB, và hiện vẫn chạy ổn định trên thiết bị đó
  • Trường hợp sử dụng chính là một micro PaaS để chạy ứng dụng trên máy chủ cloud dùng CPU Intel và ARM
  • Nền tảng mục tiêu là Debian và Ubuntu Linux
  • Hiện hỗ trợ ứng dụng Python, Node, Clojure, Java, và một số ngôn ngữ như Go cũng đang được thực hiện
  • Theo nguyên tắc chung, nếu có thể gọi từ shell thì có thể chạy bên trong Piku

Nguyên tắc thiết kế

  • Coi trọng khả năng chạy trên thiết bị cấu hình thấp
  • Cần đủ dễ tiếp cận với lập trình viên hobby và cả trường học K-12
  • Hướng tới khoảng 1500 dòng mã dễ đọc
  • Ưu tiên phong cách mã theo hướng hàm
  • Mục tiêu là có ít phụ thuộc
  • Tuân theo 12 factor app
  • Coi trọng việc đơn giản hóa trải nghiệm người dùng
  • Mục tiêu là bao phủ 80% các trường hợp sử dụng phổ biến
  • Cung cấp giá trị mặc định hợp lý cho mọi tính năng
  • Tận dụng các gói phân phối của Raspbian, Debian, Ubuntu
    • Hỗ trợ Alpine và RHEL đang được thực hiện
  • Tận dụng các công cụ chuẩn như git, ssh, uwsgi, nginx
  • Duy trì tính tương thích ngược khi có thể

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-10
Ý kiến trên Hacker News

  • Vì thích piku nên tôi đã viết một hướng dẫn web app cho piku, và nó đã được đưa vào một repository trong tổ chức piku chính thức trên GitHub
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    Hướng dẫn này giải thích piku hoạt động nội bộ ra sao, đồng thời cũng cho thấy một ví dụ web app Python tối thiểu từ góc nhìn người dùng

    • Tài liệu piku mới nhìn thì đẹp, nhưng gần như vô dụng đối với người dùng mới muốn thử piku
      Nó có cảm giác như giả định rằng bạn đã biết hết những gì cần để chạy và dùng piku, nên tôi đã bỏ cuộc; hướng dẫn này lấp được khoảng trống đó
      Tuy nhiên, dù đã tìm khá lâu tôi vẫn không thấy tài liệu này, và nếu không có bình luận ở đây thì có lẽ tôi đã chẳng biết nó tồn tại
      Ít nhất nên liên kết tài liệu này thật nổi bật từ repository piku và trang chủ tài liệu; nếu được thì đưa toàn bộ vào trang chủ tài liệu càng tốt
      Xa hơn nữa, sẽ hữu ích hơn nhiều nếu bổ sung một hướng dẫn đầu-cuối từ một server bare metal mới cho đến custom domain và chứng chỉ SSL có thể truy cập công khai
      Dù các bước đó trông có vẻ không liên quan trực tiếp đến piku, điều người dùng mới thực sự muốn là đưa website của họ lên một nơi như Droplet 5 USD, và nhiều người vẫn chưa biết các bước ở giữa
      Chọn cách nào cũng được; ai quan tâm đến phương pháp thì thường đã biết mình thích cách nào rồi
      Tham khảo: ví dụ đầu-cuối phía Coolify ở đây: https://billyle.dev/posts/self-hosting-your-website-with-coo...
      Mục tiêu không phải chỉ là làm cho nó khả thi về mặt chức năng, mà là giúp nhiều người bắt đầu dễ dàng hơn, qua đó tăng mạnh tỷ lệ chấp nhận piku
    • Tôi thích việc nó giải thích “triển khai kiểu Heroku” là gì
      Trước đó tôi hoàn toàn không biết Heroku là gì, làm gì
    • Chỉ nhìn repository chính thức thì chưa đủ rõ, nhưng phần giải thích này rất hữu ích
      Nếu tôi hiểu đúng thì piku có cấu trúc là cài agent trên máy từ xa và cài commit hook trên máy local?
      Tôi tự hỏi liệu có thể giảm overhead bằng cách biến máy từ xa thành một Git remote repository đơn thuần, rồi để phía remote làm mọi việc khi push lên một branch cụ thể hay không
    • Hướng dẫn này giờ đã được liên kết từ trang chủ tài liệu

  • Trông có vẻ tốt, và Dokku cũng từng rất ổn định với tôi, nhưng nếu loại bỏ phụ thuộc Docker thì giờ bạn sẽ bị bó vào các lựa chọn mà hệ điều hành cung cấp
    Điều này không lý tưởng cho các ứng dụng có thể chạy nhiều năm không được bảo trì, và rồi bạn sẽ nhanh chóng gặp chuyện cần một phiên bản hệ điều hành cụ thể

    • Dù là một ngách khác với piku, tôi cũng khuyên dùng Dokku
      Tôi đã dùng Dokku để đưa các side project nhỏ lên VPS, nâng cấp qua 3–4 đời Ubuntu LTS mà không gặp vấn đề gì, mọi thứ chạy rất tốt
    • Có những lúc Docker là quá mức cần thiết, và thật vui khi có một công cụ dùng được mà không cần Docker
    • Có thể dùng piku cùng Docker. Tôi có vài Procfile đặt câu lệnh docker run, nhưng tất nhiên nó không được thiết kế cho mục đích đó
      Hầu hết các triển khai tôi từng thấy đều chạy trên các distro rất ổn định, thường là bản LTS, nên không cần nâng runtime mỗi 6 tháng; website của tôi cũng đã chạy trên piku qua hơn hai lần thay đổi Ubuntu LTS
      Chỉ cần đặt biến môi trường là cũng có thể dùng dễ dàng các thứ như pyenv, nvenv
      Hệ thống home automation của tôi giờ cần hai phiên bản Node khác nhau, và tôi đã cấu hình riêng cho từng app
    • Khi dùng những công cụ như vậy thì nên giải quyết địa ngục phụ thuộc bằng cách nào?
      Tôi hiểu thái độ “cứ thế là chạy” rất thanh lịch, và Docker không thể dùng ở mọi nơi vì overhead cả về kỹ thuật lẫn tinh thần; nhưng container hay ở chỗ có thể cô lập mọi thứ và cố định như thể đóng băng thời gian, để 5 năm sau vẫn “cứ thế là chạy”
      Trong workflow nhỏ của tôi, việc quản lý container dùng lazydocker, triển khai bằng push dùng workflow GitLab, còn build, push lên GitLab registry và chạy thì do một VPS nhỏ xử lý
      Hơi quá tay một chút, nên có lẽ chỉ cần kết hợp Dockerfile, compose.yml và docker compose build cũng làm được
      Tôi vẫn chưa sắp xếp xong phần mở rộng quy mô, nhưng may là hiện chưa cần; nếu cần thì có lẽ sẽ đổi từ Docker sang k8s, từ lazydocker sang k9s
      Tôi mới bước vào DevOps nên luôn hoan nghênh mọi góp ý
    • Tôi dùng docker compose + traefik
      Ít lớp trừu tượng kiểu ma thuật hơn nên với tôi nó tốt hơn Dokku

  • Không liên quan trực tiếp đến triển khai bằng git push, nhưng liên quan chặt chẽ đến trải nghiệm PaaS: nhóm của tôi đang preview Cloud Native Buildpacks(CNB), một đặc tả mở của CNCF
    Đây là Buildpacks nhắm đến OCI, nghĩa là bạn có thể tạo Docker image cục bộ bằng một công cụ build có khả năng phát hiện hỗ trợ ngôn ngữ và xử lý phù hợp, giống logic git push của Heroku
    Đây là hướng dẫn build ứng dụng Rails bằng buildpack do tôi duy trì: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    Nếu dùng thử, dù phản hồi tốt, xấu hay chỉ là bình thường, việc để lại trải nghiệm trong thảo luận được liên kết sẽ giúp chúng tôi cải thiện

  • Lần đầu tôi thấy piku
    Không biết vì sao, nhưng cảm giác triển khai được bắt đầu bằng git push như piku lúc nào cũng giống phép màu, và tôi thấy không thể đơn giản hơn thế
    Tình cờ hôm qua tôi vừa công bố mã nguồn mở một dự án cho Kubernetes trong cùng lĩnh vực, ở đây: https://github.com/pier-oliviert/sequencer
    Dù sao cũng chúc mừng, trông có vẻ hay

    • Nó hoạt động như phép màu, nhưng nếu muốn học thì tự làm cũng rất đơn giản
      Trên server, tạo Git repository bằng git init --bare rồi đặt git config receive.denyCurrentBranch updateInstead là được
      Sau đó có thể dùng Git hook, cụ thể hơn là hook push-to-checkout, để nhận phần upload, biên dịch và chạy
      Hook là một shell script đơn giản, dạng cơ bản nhất chỉ cần một biến thể như compile && install && systemctl restart service
      Sau đó khi clone repository về máy local, hook đã cấu hình sẽ chạy mỗi khi bạn push thay đổi
      git clone root@yourserver.com:/path/to/git/folder
    • Không biết có phải tôi đang bỏ sót điều gì hiển nhiên không, nhưng nếu sequencer giống Heroku/Dokku/piku thì tôi tò mò nó triển khai bằng Git như thế nào
      Theo mô tả thì có vẻ nó xử lý template Kubernetes và kubectl, chứ không phải triển khai bằng git push, vậy thì trông như một dự án ở lĩnh vực hoàn toàn khác

  • Có thể xem tài liệu piku mới được cải tổ ở đây: https://piku.github.io/

    • Đây có phải là hậu duệ của Dokku không? Tôi không biết là có dự án thứ hai

  • Commit đầu tiên là từ 8 năm trước sao?
    Giá mà tôi biết dự án này khoảng 18 tháng trước, khi tôi đang tìm cách triển khai lên Raspberry Pi với trải nghiệm phát triển giống Heroku, và piku có vẻ nhắm chính xác vào điều đó

    • Đúng vậy. Có vấn đề về độ hiện diện
      Tôi vừa thiết lập một VPS mới bằng CapRover, và trong khoảng một giờ tìm kiếm so sánh “PaaS tự host kiểu Heroku”, tôi thấy Dokku, CapRover, Coolify, Dokploy nhưng hoàn toàn không thấy piku

  • Tôi là maintainer kiêm đồng tác giả
    Nếu bạn thích công cụ triển khai đơn giản và tối giản, tôi cũng mong bạn xem https://github.com/rcarmo/ground-init, một cách tiếp cận cloud-init thực tế hơn nhiều

    • Chỉ nhìn README thì chưa thấy rõ câu trả lời vì sao nó không nên là cloud-init

  • Tôi tò mò liệu có cách nào xử lý triển khai không downtime không
    Ví dụ nếu một service Python đang chạy sau nginx trên cổng 8080 của một máy, piku sẽ chuyển sang instance mới trên cùng cổng đó như thế nào?

    • Hiện tại chỉ sau khi lần triển khai git push mới kết thúc thì tiến trình đang chạy mới bị dừng
      Việc xử lý socket và session phụ thuộc vào code được viết ra sao, dùng uwsgi hay tự chạy HTTP daemon
      Một trong những tính năng đã được hỗ trợ tùy chọn là dừng các instance không dùng và nhàn rỗi, rồi khởi động trễ khi có kết nối mới đi vào
    • Hơi lệch chủ đề một chút, nhưng nếu dùng systemd socket activation thì có thể triển khai không downtime

  • Tôi thích Epinio, thứ làm việc tương tự trên Kubernetes
    Nó được SUSE hỗ trợ, nhẹ hơn KNative — nền tảng của GCP Cloud Run chẳng hạn — nhưng vì dựa trên Kubernetes nên vẫn cần nhiều tài nguyên hơn Dokku hay piku
    Dù vậy, vì hệ sinh thái giải pháp trưởng thành rộng lớn nên tôi thích k8s hơn
    Có thể chạy tất cả trên một server đơn lẻ, chỉ là cần server lớn hơn một chút
    Hetzner CX42 mới có 8 vCPU, RAM 16GB, đĩa 160GB với giá €16,40/tháng, €0,0273/giờ là đủ, và nếu dùng dự án Kube Hetzner thì có thể thiết lập một cluster Kubernetes dựa trên MicroOS tự động cập nhật trong chưa đến 5 phút
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • Nếu “Epinio làm việc tương tự trên Kubernetes” thì thực ra chẳng phải nó gần như hoàn toàn không giống sao?
      Điểm cốt lõi của piku có vẻ là cung cấp trải nghiệm giống Heroku mà không cần Docker, kiến trúc thật sự đơn giản và chạy được cả trên ARM
      Tôi công nhận Kubernetes chạy trên ARM, nhưng theo hiểu biết của tôi Kubernetes đòi hỏi container dưới một hình thức nào đó, dù là Docker hay thứ khác, và kiến trúc của nó rõ ràng không bao giờ đơn giản vì những lý do hiển nhiên
      Hơn nữa tôi cũng không chắc Epinio có cho phép luồng git push hay không
      Tutorial khởi động nhanh có vẻ bảo dùng lệnh như epinio push manifest.yaml để triển khai ứng dụng, nên cũng không khớp với “trải nghiệm giống Heroku”
      Rốt cuộc tôi nghĩ điểm chung chỉ là xử lý triển khai mà thôi

  • Tôi thích cách tiếp cận tối giản nên sẽ thử dùng
    Cũng có vài thứ tương tự đáng xem
    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