8 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Để quản lý các dịch vụ homelab, tác giả gắn quyền truy cập Git vào OpenCode Web UI và thiết lập luồng để GitOps triển khai các thay đổi do AI tạo ra sau khi PR được xem xét
  • Khoảng 12 stack docker compose được chuyển sang Arcane để quản lý bằng GitOps, đồng thời tận dụng công cụ AI cho việc bảo trì dịch vụ
  • Trước đây, mỗi lần cập nhật container phải mất vài giờ để đọc ghi chú phát hành, kiểm tra thay đổi phá vỡ tương thích và xác minh thủ công, nhưng giờ chỉ cần vài phút để đọc bản tóm tắt ghi chú phát hành, giúp nâng cấp phiên bản dễ hơn và an toàn hơn
  • OpenCode chạy như một máy chủ, cung cấp terminal, trình duyệt tệp, Git diff và git worktree, đồng bộ các phiên làm việc lập trình liên tục trên nhiều thiết bị
  • AI không thể truy cập trực tiếp vào các dịch vụ thực tế mà chỉ có thể đẩy lên các nhánh Git, nhờ đó tạo ra cấu trúc ngăn mã chưa được kiểm duyệt bị triển khai

Luồng quản lý homelab

  • Tác giả cấp quyền truy cập Git cho OpenCode Web UI để việc quản lý homelab trở nên dễ dàng hơn; khi OpenCode đẩy thay đổi lên Git, con người sẽ phê duyệt PR rồi sau đó GitOps triển khai thay đổi
  • OpenCode chạy như một máy chủ, và các phiên lập trình liên tục được đồng bộ trên nhiều thiết bị
  • Các dịch vụ đang được quản lý gồm khoảng 12 stack docker compose, gần đây đã được chuyển sang Arcane để quản lý và triển khai bằng GitOps
  • Trường hợp sử dụng đầu tiên của công cụ AI là cập nhật container
    • Trước đây, phải tìm ghi chú phát hành của từng dịch vụ, kiểm tra các thay đổi phá vỡ tương thích, chạy cập nhật và xác minh thủ công sự cố của từng dịch vụ
    • Quy trình này mất vài giờ, nhưng giờ chỉ cần vài phút để đọc bản tóm tắt ghi chú phát hành, giúp nâng cấp phiên bản dễ hơn và an toàn hơn
    • Tác giả cũng dùng AI để thêm healthcheck cho hầu hết container, nhờ đó có thể phát hiện sự cố nhanh hơn

OpenCode

  • Tác giả chủ yếu dùng Claude Code, nhưng vì các nhà cung cấp AI đang làm giảm giá trị cho khách hàng thông qua giới hạn token nên bắt đầu tìm các lựa chọn khác
  • Công cụ mong muốn là một môi trường lập trình không bị khóa vào một nhà cung cấp cụ thể và được các plugin chính hỗ trợ
  • Sau khi thử nhiều môi trường lập trình, tác giả chọn OpenCode, và đây là công cụ ưng ý nhất trong số các lựa chọn đã thử
  • Việc OpenCode có web server và web UI tích hợp đã trở thành điểm khởi đầu cho ý tưởng về một nền tảng phát triển AI cho homelab

Nền tảng phát triển AI

  • Tác giả tạo một VM đơn giản trên host Truenas với các công cụ phát triển cơ bản và thêm web server OpenCode dưới dạng systemd unit
  • Môi trường này cung cấp terminal tích hợp, trình duyệt tệp, Git diff và hỗ trợ git worktree để có thể quản lý đồng thời nhiều phiên lập trình
  • Web UI trên di động của OpenCode gây ấn tượng rất tốt nhờ popup hỏi-đáp
  • Trên máy chủ Git, tác giả cấp một người dùng chuyên dụng và khóa SSH chuyên dụng cho OpenCode
    • OpenCode có thể clone dự án và đẩy nhánh
    • Không thể đẩy trực tiếp lên nhánh triển khai
  • Workflow đặt AI trước bước duyệt PR; OpenCode tạo thay đổi rồi con người tự merge trực tiếp trong PR
    • Cấu trúc này ngăn mã chưa được kiểm duyệt bị triển khai
  • VM có thể truy cập Internet và máy chủ Git, nhưng không thể truy cập các dịch vụ thực tế
    • Vì phạm vi ảnh hưởng nhỏ, tác giả cho rằng vẫn ổn khi cấp quyền root trên VM cho OpenCode trong trường hợp cần cài công cụ build hoặc phụ thuộc phục vụ kiểm thử
  • Cấu trúc này có thể mở rộng thành một nền tảng phát triển production dành cho lập trình viên dưới dạng container tạm thời, với các công cụ cài sẵn, guardrail truy cập và nhật ký kiểm toán
  • Cấu hình hiện tại vẫn cung cấp các chức năng cần thiết mà không có quá nhiều thành phần

Workflow

  • Luồng làm việc cơ bản bắt đầu từ bước lên kế hoạch tính năng hoặc cải tiến trong OpenCode
    • Kế hoạch bao gồm đặc tả, kế hoạch triển khai và tự rà soát
  • Khi có thể, các thay đổi sẽ được kiểm thử hoặc xác minh
  • Những phần chưa ưng ý sẽ được chỉnh sửa lặp lại cùng OpenCode
  • OpenCode đẩy thay đổi lên nhánh tính năng
  • Mở PR từ nhánh đó và nếu hài lòng thì merge PR
  • Sau khi merge, GitOps tiếp quản việc triển khai
    • Các thay đổi dịch vụ docker do Arcane xử lý
    • Các thay đổi cấu hình Home Assistant do plugin GitOps xử lý
    • Các thay đổi blog do Cloudflare Pages worker xử lý

Kết hợp Arcane GitOps và OpenCode

  • Tác giả đã chuyển các dịch vụ từ Truenas sang một dự án Arcane GitOps, với mục tiêu chính là quản lý toàn bộ các stack docker compose đang chạy trên Truenas bằng kho lưu trữ dựa trên Git
  • Khi thêm OpenCode vào cùng, cách làm này hoạt động tốt hơn mong đợi
  • Tác giả có thể cập nhật networking của toàn bộ container từ điện thoại, giúp việc quản lý cấu hình phân tán trở nên dễ dàng hơn nhiều
  • Trước đây, việc rà soát toàn bộ các stack compose và lần theo kết nối mạng mất vài giờ
  • Giờ đây chỉ cần chỉ định codebase và mục tiêu cho OpenCode, xem lại các thay đổi trong PR được tạo ra rồi merge

Hạn chế còn lại và kiểm soát truy cập

  • Khoảng trống lớn nhất hiện nay là phản hồi từ CI
  • Trên GitHub, coding agent có thể xem log của Actions để chẩn đoán bài kiểm thử thất bại, lỗi linter, stack trace và các thay đổi trong IaC plan
  • Cách này giúp duy trì vòng phản hồi nhanh ngay cả với những thay đổi mà unit test không bao quát được
  • Trên Forgejo, luồng này khó hơn nhiều
    • Forgejo Actions không công khai log job qua API công khai
    • Có API không được tài liệu hóa, nhưng tác giả không muốn xây dựng hệ thống dựa trên API đó
  • Cấu hình hiện tại cho phép AI tạo ra các thay đổi cho hạ tầng tại nhà từ bất kỳ thiết bị nào mà không thể truy cập trực tiếp vào các dịch vụ mục tiêu
  • Có thể bắt đầu thay đổi trên máy tính, rà soát PR trên điện thoại và để GitOps xử lý việc triển khai

1 bình luận

 
Ý kiến Hacker News
  • Tôi vẫn đang tìm cách tích hợp AI phù hợp với môi trường của mình. Hiện tại chưa có sự tương tác giữa Forgejo và coding agent, và tôi cũng đã thử Forgejo Actions runner, nhưng việc quản lý ngữ cảnh khá mơ hồ
    Nội dung trong issue hay PR thì có thể lấy được, nhưng nếu qua lại nhiều lượt hoặc thảo luận chuyển từ issue sang PR thì rất nhanh bị loãng

  • Tôi cũng đang làm thứ tương tự, nhưng thay vì dùng máy chủ opencode thường trực, tôi dùng workflow chạy opencode bên trong Forgejo action runner: https://codeberg.org/dragonfyre13/forgejo-opencode
    Vẫn đang chỉnh sửa thêm, nhưng ý chính là gọi Opencode bằng /oc trong issue của Forgejo, rồi nó sẽ quay lại với một PR để xem xét

    • Tôi cũng đã thử cách tương tự với Claude Code và Forgejo, dưới dạng một ứng dụng nhỏ tách riêng chạy Claude trong Docker: https://github.com/smithy-ai/smithy-ai
  • Đôi khi tôi có cảm giác trong ngành công nghệ, rất nhiều người độc lập trải qua những điều gần như giống hệt nhau vào gần cùng một thời điểm, nhưng lại rất ít người thực sự viết ra hay chia sẻ
    Tôi cũng đang xây một hệ thống tương tự, nên đọc bài và bình luận này thấy vui vì mọi người đều đang đi qua cùng một quá trình

    • Không chỉ ngành công nghệ mới vậy, đây là hiện tượng khá phổ biến. Chúng ta không sáng tạo đến thế đâu
    • Tôi cũng đã làm cái này theo ba cách khác nhau, và còn thử e2b.dev nữa, đó là một dịch vụ tốt
      Vấn đề là chúng ta dành 99% thời gian để hack những thứ ngầu, và chỉ 1% để nói về nó. Cần nói nhiều hơn
    • Có lẽ vì dân công nghệ mong mọi thứ đều miễn phí
      Tôi đang nói chuyện với luật sư, gần hết giờ thì định hỏi thêm “một câu nữa”, nhưng luật sư bảo “hãy đặt thêm 30 phút rồi ta nói tiếp”. Đó là cách làm công bằng
  • Tôi đang tìm động lực để viết về AI lab của mình, và bài này chính là cú hích tôi cần
    Cấu hình của tôi cũng là ý tưởng tương tự nhưng dùng n8n/git/argo/k3s, chủ yếu cho các workflow tự động hóa mà Qwen hoặc Gemma4 có thể xử lý

  • Tôi tự hỏi có ai biết vì sao domain này lại bị Quad9 resolver chặn không. Quad9 đang lọc domain nên tôi không thể mở website
    Kết quả dig @9.9.9.9 rsgm.dev NS trả về EDE: 17 (Filtered)

    • Tôi đoán có thể vì đăng ký quá mới. Nó mới chỉ được đăng ký khoảng 8 tiếng, thời điểm tạo là 2026-06-15 14:01:25 UTC
  • Có hai lý do chính khiến tôi vẫn chưa dùng cấu hình này: tài nguyên phải cấp cho VM chạy opencode để build dự án, và việc test nhanh hơn
    Tôi chạy pi coding agent trực tiếp trên Mac, đồng thời cũng chạy cả một bộ phần mềm đầy đủ như redis, postgres, kratos. Khi coding agent chạy trên máy phát triển chính, tôi có thể build nhanh hơn, rồi chỉ rebuild và restart backend, sau đó test thay đổi ngay trên UI client để kiểm tra nhanh hơn

  • Tôi cũng đang làm gần như y hệt. Tôi chạy OpenCode trên Proxmox LXC, rồi thêm một lớp Kimaki phía trên để tích hợp Discord
    Thích hay không thì bạn vẫn có thể trò chuyện với codebase, và nếu hợp gu thì còn có cả tin nhắn thoại, khá là hay

  • Tuyệt vời. Home lab AI có vẻ sẽ rất thú vị
    Hiện tôi đang để Claude quản lý home lab của mình trên mọi thiết bị, và việc cài đặt cũng như bảo trì home lab đã chuyển từ “một cái bẫy mê hoặc trong nhiều năm nhưng không bao giờ chạy hẳn hoi và còn ngốn thời gian” thành “một ý tưởng thực sự tốt và giúp mở rộng năng lực của tôi”

    • Ngay cả khi dùng model mới nhất thì vẫn có vài phần nhỏ giúp tiết kiệm thời gian, nhưng nhìn chung thường phát sinh lượng debug khổng lồ do các vấn đề cấu hình tinh vi, nên tổng thể lại thành lỗ
      Nếu là tác vụ được chỉ định rất hẹp như “hãy tạo file docker compose” hay “cho tôi cấu hình NSD” thì ổn, nhưng ngay cả khi đó bạn vẫn phải biết cần công nghệ nền tảng nào và phải hỏi điều gì
  • Việc gắn quyền truy cập Git vào OpenCode Web UI để quản lý home lab dễ hơn, rồi để OpenCode push lên Git, tôi duyệt PR và GitOps triển khai thay đổi, nghe khá ổn
    Nhưng trước khi đọc, tôi đã tự hỏi liệu để làm tương tự có cần bỏ ra hàng nghìn đô la cho RAM và GPU hay không

    • Có thể là 0 đô. OpenCode chỉ là một harness, nên có thể kết nối với bất kỳ model nào được host online
  • Bên tôi cũng làm tương tự nhưng cho agent có thể mở PR, đồng thời dùng hệ thống ReARM để theo dõi metadata bản phát hành và agent session
    Gần đây chúng tôi còn ra mắt tùy chọn để agent theo dõi việc triển khai dựa trên Helm thông qua ReARM: https://docs.rearmhq.com/workflows/devops.html

    • Tôi chưa nhắc đến phần này, nhưng trong lúc viết bài thì nhận ra có thể dễ dàng thêm một skill gọi Forgejo PR API
      Tiếc là Forgejo không có CLI như GitHub