Một thử nghiệm sử dụng GitHub Actions làm mặt phẳng điều khiển cho PaaS

Một sự kết hợp bất ngờ: Git và nền tảng

Thế giới DevOps được xây dựng dựa trên tự động hóa. Chúng tôi triển khai kịch bản, quản lý cơ sở hạ tầng dưới dạng mã và cố gắng làm cho mọi quy trình có thể lặp lại và đáng tin cậy. Trọng tâm của vô số nhóm phát triển là GitHub, nền tảng phổ biến để cộng tác mã. Nhưng điều gì sẽ xảy ra nếu sức mạnh của nó có thể được mở rộng ra ngoài khả năng kiểm soát phiên bản và CI/CD? Đây là câu chuyện về một thử nghiệm nhằm vượt qua các ranh giới của GitHub Actions, biến nó từ một bộ điều phối xây dựng và thử nghiệm thành hệ thống thần kinh trung ương—mặt phẳng điều khiển—cho toàn bộ Nền tảng dưới dạng Dịch vụ (PaaS).

Xác định lại mặt phẳng điều khiển

Theo truyền thống, mặt phẳng điều khiển PaaS là một phần mềm phức tạp, được thiết kế riêng. Đó là cơ quan trung ương nhận lệnh (triển khai cái này, mở rộng quy mô cái kia) và điều phối cơ sở hạ tầng cơ bản để thực hiện điều đó. Nó xử lý việc cung cấp, kết nối mạng, bảo mật và quản lý vòng đời. Xây dựng một công trình là một công việc kỹ thuật quan trọng. Giả thuyết trong thử nghiệm của chúng tôi rất đơn giản: liệu chúng tôi có thể tận dụng quy trình làm việc hiện có, mạnh mẽ và quen thuộc của GitHub Actions để thực hiện những nhiệm vụ tương tự này không? Thay vì viết một mặt phẳng điều khiển nguyên khối, chúng tôi sẽ sử dụng các tệp YAML, yêu cầu kéo và hệ sinh thái hướng sự kiện mạnh mẽ của GitHub để quản lý nền tảng của chúng tôi.

"Công cụ mạnh mẽ nhất là công cụ mà nhóm của bạn đã biết cách sử dụng. Bằng cách sử dụng GitHub Actions làm mặt phẳng điều khiển, chúng tôi không phải xây dựng giao diện người dùng hoặc dạy các khái niệm mới; chúng tôi đã mở rộng quy trình làm việc tập trung vào Git hiện có mà các nhà phát triển yêu thích."

Kiến trúc PaaS dựa trên GitHub

Kiến trúc tập trung vào việc xử lý các khai báo cơ sở hạ tầng và cấu hình ứng dụng dưới dạng mã trong kho lưu trữ. Ví dụ: quy trình làm việc của nhà phát triển để triển khai một vi dịch vụ mới sẽ như sau:

Nhà phát triển tạo một thư mục mới cho dịch vụ của họ và thêm tệp `mewayz.app.yaml` xác định nhu cầu của nó: CPU, bộ nhớ, biến môi trường và miền.

Họ cam kết tệp này và mở Yêu cầu kéo. Chính hành động mở PR sẽ kích hoạt quy trình làm việc của Hành động GitHub.

Quy trình công việc, đóng vai trò là mặt phẳng điều khiển, phân tích cú pháp tệp YAML, xác thực cấu hình và thực hiện chạy thử các thay đổi cơ sở hạ tầng.

Sau khi PR được hợp nhất, một quy trình triển khai riêng biệt sẽ được kích hoạt. Quy trình công việc này chứa logic để giao tiếp với nhiều API đám mây khác nhau (Kubernetes, AWS, v.v.) để thực sự cung cấp các tài nguyên cần thiết và triển khai dịch vụ.

Sau đó, quy trình làm việc sẽ nhận xét về cam kết bằng liên kết trực tiếp đến dịch vụ mới được triển khai, hoàn thành vòng lặp.

Cách tiếp cận này được tích hợp liền mạch với triết lý mô đun và trải nghiệm của nhà phát triển của Mewayz. Toàn bộ trạng thái của nền tảng được kiểm soát theo phiên bản, có thể kiểm tra được và tuân theo quy trình đánh giá cộng tác giống như chính mã ứng dụng.

Bài học từ biên giới

Thí nghiệm đã thành công vang dội trong việc chứng minh tính khả thi. Chúng tôi đã đạt được một PaaS được điều khiển bằng Git-op với đầy đủ chức năng, trong đó mọi thay đổi đều có thể theo dõi và đảo ngược được. Tuy nhiên, nó cũng tiết lộ những cân nhắc quan trọng. Việc quản lý trạng thái phức tạp đôi khi đã đẩy xa ranh giới của những gì trang nhã trong tệp YAML. Mặc dù GitHub Actions có khả năng mở rộng đáng kinh ngạc, nhưng đối với các nền tảng quy mô lớn, thời gian xếp hàng và thực thi quy trình công việc có thể trở thành nút thắt cổ chai so với API mặt phẳng điều khiển chuyên dụng, có độ trễ thấp. An ninh là điều tối quan trọng; chúng tôi phải quản lý tỉ mỉ các bí mật và quyền để đảm bảo người chạy GitHub Action có quyền truy cập tối thiểu chính xác cần thiết để thực hiện nhiệm vụ của mình—một khái niệm hoàn toàn phù hợp với các nguyên tắc bảo mật theo thiết kế của Mewayz.

Cái nhìn thoáng qua về tương lai lấy Git làm trung tâm

Thử nghiệm này chứng minh rằng các công cụ chúng tôi sử dụng để cộng tác và CI/CD đủ mạnh để có thể tái sử dụng thành nền tảng nền tảng của chúng tôi. Nó xóa mờ ranh giới giữa việc phát triển một ứng dụng và quản lý môi trường mà nó chạy trên đó, thống nhất chúng dưới một hệ thống duy nhất.

Frequently Asked Questions

An Unexpected Union: Git and the Platform

The world of DevOps is built on automation. We script deployments, manage infrastructure as code, and strive to make every process repeatable and reliable. At the heart of this for countless development teams is GitHub, the ubiquitous platform for code collaboration. But what if its power could be extended beyond version control and CI/CD? This is the story of an experiment to push the boundaries of GitHub Actions, transforming it from a build-and-test orchestrator into the central nervous system—the control plane—for an entire Platform as a Service (PaaS).

Redefining the Control Plane

Traditionally, a PaaS control plane is a complex, bespoke piece of software. It's a central authority that receives commands (deploy this, scale that) and orchestrates the underlying infrastructure to make it happen. It handles provisioning, networking, security, and lifecycle management. Building one is a significant engineering undertaking. The hypothesis of our experiment was simple: could we leverage the existing, powerful, and familiar workflow of GitHub Actions to perform these same duties? Instead of writing a monolithic control plane, we would use YAML files, pull requests, and GitHub's robust event-driven ecosystem to manage our platform.

Architecting the GitHub-Driven PaaS

The architecture centered on treating infrastructure declarations and application configurations as code within a repository. A developer's workflow to deploy a new microservice, for instance, would look like this:

Lessons from the Frontier

The experiment was a resounding success in proving feasibility. We achieved a fully functional, Git-ops driven PaaS where every change was traceable and reversible. However, it also revealed important considerations. Complex state management sometimes pushed the boundaries of what was elegant in a YAML file. While GitHub Actions is incredibly scalable, for massive-scale platforms, the queueing and execution time of workflows could become a bottleneck compared to a dedicated, low-latency control plane API. Security was paramount; we had to meticulously manage secrets and permissions to ensure the GitHub Action runner had the exact minimum access required to perform its duties—a concept perfectly aligned with Mewayz's secure-by-design principles.

A Glimpse into a Git-Centric Future

This experiment demonstrates that the tools we use for collaboration and CI/CD are powerful enough to be repurposed into the very foundation of our platforms. It blurs the line between developing an application and managing the environment it runs on, unifying them under a single, Git-based workflow. For companies like Mewayz, which are building the next generation of business OS platforms, this exploration is invaluable. It challenges conventional architecture and opens doors to incredibly intuitive and integrated developer experiences. While it may not replace every custom control plane, it stands as a powerful testament to the idea that the best solution might already be in your toolkit.