OpenRun: Deploy internal tools kiểu GitOps, không cần build server

Mình làm việc với khá nhiều team internal tools - từ dashboard analytics, admin panel, đến các công cụ automation nho nhỏ. Và có một vấn đề mà hầu như team nào cũng gặp: deploy mấy cái app này rất phiền. Không phải vì code khó, mà vì infrastructure xung quanh nó lằng nhằng - setup Nginx, cấu hình SSL, quản lý auth, rồi lại phải document lại cho người sau. Mỗi lần có app mới là lại một lần đau đầu.

OpenRun ra đời để giải quyết đúng cái pain point đó.

OpenRun là gì và tại sao nó khác với Coolify hay Dokku?

Nói ngắn gọn: OpenRun là một deployment platform cho internal tools, hoạt động theo mô hình declarative GitOps. Thay vì bạn phải SSH vào server rồi chạy lệnh, hay click click trên UI để tạo app - bạn chỉ cần commit một file config lên Git, OpenRun tự lo phần còn lại.

Cái này nghe quen quen phải không? Kiểu Kubernetes với manifest YAML ấy. Nhưng OpenRun đơn giản hơn nhiều và có thể chạy trên một con VPS bình thường mà không cần cả một cluster K8s.

Mình so sánh nhanh với các tool phổ biến khác:

Điểm mình thấy ấn tượng nhất là OpenRun tự implement web server - không phụ thuộc Nginx hay Traefik. Điều này cho phép nó làm được những thứ mà các tool khác không làm được, như scale app xuống zero khi không có traffic, hay inject OAuth vào bất kỳ app nào mà không cần app đó tự handle auth.

Cách hoạt động: Declarative hết, không click UI

Với OpenRun, mọi thứ đều là config file trong Git. Bạn muốn tạo app mới? Thêm file vào repo. Muốn update environment variable? Sửa file, commit, push. OpenRun sẽ detect thay đổi và apply.

Một app spec trông kiểu này:

1apiVersion: openrun.dev/v1
2kind: App
3metadata:
4  name: my-dashboard
5spec:
6  image: ghcr.io/myorg/dashboard:latest
7  domain: dashboard.internal.company.com
8  auth:
9    provider: google
10    allowedDomains:
11      - company.com
12  resources:
13    memory: 256Mi
14  scaleToZero:
15    enabled: true
16    idleTimeout: 15m

Commit cái này lên repo mà OpenRun đang watch, vài giây sau app của bạn đã running, có TLS, có Google OAuth, và sẽ tự scale xuống zero sau 15 phút không có request. Không cần làm gì thêm.

Theo kinh nghiệm của mình, cái workflow này đặc biệt hay khi team có nhiều người cùng manage internal tools. Thay vì phải hỏi nhau "app này config thế nào", "tại sao cái này lại dùng port 8080" - tất cả đều nằm trong Git, có history, có review process.

Setup ban đầu: Single-node trước, Kubernetes sau nếu cần

OpenRun có thể chạy trên Docker hoặc Podman trên một con server đơn giản. Đây là cách setup nhanh nhất:

Bước 1: Cài OpenRun

1# Download binary mới nhất
2curl -L https://github.com/openrundev/openrun/releases/latest/download/openrun_linux_amd64.tar.gz | tar xz
3sudo mv openrun /usr/local/bin/
4
5# Hoặc dùng Go install
6go install github.com/openrundev/openrun/cmd/openrun@latest

Bước 2: Init config

1openrun init --domain apps.yourdomain.com --email admin@yourdomain.com

Lệnh này tạo ra file config cơ bản, setup Let's Encrypt cho TLS, và chuẩn bị sẵn mọi thứ.

Bước 3: Trỏ Git repo

1openrun config set git.repo https://github.com/yourorg/internal-apps-config
2openrun config set git.branch main
3openrun start

Từ đây, bất cứ thứ gì bạn push lên repo đó, OpenRun sẽ tự apply. Không cần webhook phức tạp, không cần CI/CD riêng cho việc deploy.

Khi cần scale lên Kubernetes:

Cái này mình thấy cực kỳ thực dụng - bạn không cần thay đổi bất kỳ app config nào. Chỉ cần update OpenRun config để point sang K8s cluster:

1openrun config set runtime kubernetes
2openrun config set kubernetes.kubeconfig /path/to/kubeconfig
3openrun restart

Các app spec vẫn y nguyên. OpenRun tự translate sang Kubernetes resources. Đây là điểm mà nhiều tool khác không làm được.

Auth và RBAC: Bảo mật internal tools đúng cách

Mình thấy đây là một trong những phần mạnh nhất của OpenRun. Internal tools thường bị bỏ qua về security vì "chỉ dùng nội bộ thôi mà". Nhưng thực tế thì internal tools thường có quyền truy cập vào data nhạy cảm nhất của công ty.

OpenRun support:

• OAuth 2.0 / OpenID Connect: Google, GitHub, GitLab, Okta, bất kỳ IdP nào support OIDC
• SAML: Cho các enterprise SSO như Azure AD, Okta
• Client Certificate: Cho các use case cần mTLS

Config auth cho một app:

1apiVersion: openrun.dev/v1
2kind: App
3metadata:
4  name: internal-admin
5spec:
6  image: myorg/admin-panel:v2.1.0
7  domain: admin.internal.com
8  auth:
9    provider: oidc
10    oidc:
11      issuerURL: https://accounts.google.com
12      clientID: ${GOOGLE_CLIENT_ID}
13      clientSecret: ${GOOGLE_CLIENT_SECRET}
14    allowedGroups:
15      - engineering-leads
16      - product-managers
17  rbac:
18    roles:
19      - name: viewer
20        allowedGroups: ["product-managers"]
21      - name: admin
22        allowedGroups: ["engineering-leads"]

Anh em lưu ý: OpenRun handle auth ở proxy layer - app của bạn không cần biết gì về OAuth hết. Request chỉ đến được app sau khi đã pass qua auth. Điều này có nghĩa là bạn có thể bảo vệ bất kỳ app nào, kể cả app bạn không có source code.

Blue-green deployment và atomic updates

Một feature khác mình thấy rất hay là staged deployment và atomic updates. Khi bạn update config, OpenRun không apply ngay lập tức - nó có thể deploy version mới song song với version cũ (blue-green), rồi switch traffic khi bạn ready.

Còn atomic updates thì đặc biệt hữu ích khi bạn có nhiều app phụ thuộc nhau. Ví dụ bạn update cả frontend lẫn backend API cùng lúc - OpenRun có thể đảm bảo cả hai được deploy thành công trước khi switch traffic, hoặc rollback cả hai nếu có lỗi.

1apiVersion: openrun.dev/v1
2kind: AppGroup
3metadata:
4  name: my-product-v2
5spec:
6  atomic: true  # Tất cả hoặc không có gì
7  apps:
8    - name: frontend
9      image: myorg/frontend:v2.0.0
10    - name: backend-api
11      image: myorg/api:v2.0.0
12    - name: worker
13      image: myorg/worker:v2.0.0

Theo kinh nghiệm của mình, cái atomic update này cứu mình nhiều lần khi deploy những thay đổi breaking API giữa frontend và backend.

Scale to zero: Tiết kiệm resource cho internal tools

Internal tools thường có traffic pattern rất thất thường - ban ngày dùng nhiều, ban đêm không ai dùng. OpenRun có thể scale app xuống zero container khi idle, và spin up lại khi có request mới (cold start thường chỉ vài giây với container đã được pull sẵn).

Với một team có 10-15 internal tools, feature này có thể giảm đáng kể resource usage, đặc biệt nếu bạn đang chạy trên K8s và trả tiền theo resource.

Khi nào nên dùng OpenRun?

Mình nghĩ OpenRun fit nhất cho các trường hợp sau:

• Team đang build nhiều internal tools (admin panels, dashboards, automation UIs) và muốn standardize cách deploy
• Bạn muốn GitOps workflow cho internal tools mà không muốn setup Argo CD hay Flux phức tạp
• Cần auth và RBAC mà không muốn implement trong từng app
• Bắt đầu với single server nhưng muốn option migrate lên K8s sau này mà không đau đầu

Nếu bạn chỉ có 1-2 app đơn giản và không cần auth phức tạp, Coolify hay Dokku vẫn là lựa chọn đơn giản hơn. Nhưng khi số lượng internal tools tăng lên, cái overhead của việc manage từng app thủ công sẽ đau hơn nhiều so với việc setup OpenRun một lần.

Project đang ở Apache-2.0 license, open source hoàn toàn. Với 839 stars và đang active development, mình nghĩ đây là một tool đáng để anh em thử nghiệm trong môi trường staging trước khi quyết định adopt cho production.