Eksperyment mający na celu wykorzystanie akcji GitHub jako płaszczyzny kontrolnej dla PaaS

Nieoczekiwany związek: Git i platforma

Świat DevOps opiera się na automatyzacji. Skryptujemy wdrożenia, zarządzamy infrastrukturą jak kod i staramy się, aby każdy proces był powtarzalny i niezawodny. Sercem tego rozwiązania dla niezliczonych zespołów programistów jest GitHub, wszechobecna platforma do współpracy nad kodem. Ale co by było, gdyby jego możliwości można było rozszerzyć poza kontrolę wersji i CI/CD? Oto historia eksperymentu mającego na celu przesunięcie granic GitHub Actions i przekształcenie go z orkiestratora budującego i testującego w centralny układ nerwowy — płaszczyznę sterowania — dla całej platformy jako usługi (PaaS).

Nowa definicja płaszczyzny sterowania

Tradycyjnie płaszczyzna kontroli PaaS jest złożonym, dostosowanym do indywidualnych potrzeb oprogramowaniem. Jest to organ centralny, który otrzymuje polecenia (wdróż to, skaluj tamto) i koordynuje podstawową infrastrukturę, aby to urzeczywistnić. Zajmuje się udostępnianiem, siecią, bezpieczeństwem i zarządzaniem cyklem życia. Budowa takiego obiektu jest znaczącym przedsięwzięciem inżynieryjnym. Hipoteza naszego eksperymentu była prosta: czy moglibyśmy wykorzystać istniejący, wydajny i znajomy przepływ pracy GitHub Actions do wykonania tych samych zadań? Zamiast pisać monolityczną płaszczyznę kontroli, do zarządzania naszą platformą użylibyśmy plików YAML, żądań ściągnięcia i solidnego ekosystemu GitHub sterowanego zdarzeniami.

„Najpotężniejsze narzędzie to to, które Twój zespół już wie, jak używać. Wykorzystując GitHub Actions jako naszą płaszczyznę kontroli, nie musieliśmy tworzyć interfejsu użytkownika ani uczyć nowych koncepcji; rozszerzyliśmy istniejący przepływ pracy skoncentrowany na Git, który tak uwielbiają programiści”.

Architektowanie PaaS opartego na GitHubie

Architektura skupiała się na traktowaniu deklaracji infrastruktury i konfiguracji aplikacji jako kodu w repozytorium. Na przykład przepływ pracy programisty związany z wdrożeniem nowej mikrousługi będzie wyglądał następująco:

Programista tworzy nowy katalog dla swojej usługi i dodaje plik `mewayz.app.yaml` określający jej potrzeby: procesor, pamięć, zmienne środowiskowe i domena.

Zatwierdzają ten plik i otwierają żądanie ściągnięcia. Sam fakt otwarcia PR uruchamia przepływ pracy GitHub Actions.

Przepływ pracy, pełniący rolę płaszczyzny kontroli, analizuje plik YAML, sprawdza poprawność konfiguracji i wykonuje próbę zmian w infrastrukturze.

Po połączeniu żądania ściągnięcia uruchamiany jest oddzielny przepływ pracy dotyczący wdrażania. Ten przepływ pracy zawiera logikę komunikacji z różnymi interfejsami API w chmurze (Kubernetes, AWS itp.), aby faktycznie udostępnić niezbędne zasoby i wdrożyć usługę.

Następnie przepływ pracy komentuje zatwierdzenie aktywnym łączem do nowo wdrożonej usługi, zamykając pętlę.

Podejście to płynnie integruje się z filozofią Mewayz dotyczącą modułowości i doświadczenia programistów. Stan całej platformy był kontrolowany pod kątem wersji, podlegał audytowi i podlegał temu samemu procesowi wspólnego przeglądu, co sam kod aplikacji.

Lekcje z pogranicza

Eksperyment okazał się ogromnym sukcesem i udowodnił wykonalność. Osiągnęliśmy w pełni funkcjonalny PaaS oparty na Git-ops, w którym każda zmiana była identyfikowalna i odwracalna. Jednakże ujawniło również ważne kwestie. Złożone zarządzanie stanem czasami przesuwało granice elegancji w pliku YAML. Chociaż GitHub Actions jest niezwykle skalowalny, w przypadku platform o dużej skali czas oczekiwania w kolejce i wykonywania przepływów pracy może stać się wąskim gardłem w porównaniu z dedykowanym interfejsem API płaszczyzny kontrolnej o niskim opóźnieniu. Bezpieczeństwo było najważniejsze; musieliśmy skrupulatnie zarządzać tajemnicami i uprawnieniami, aby mieć pewność, że moduł uruchamiający GitHub Action miał dokładnie minimalny dostęp wymagany do wykonywania swoich obowiązków — koncepcja doskonale zgodna z zasadami bezpiecznego projektowania firmy Mewayz.

Spojrzenie w przyszłość zorientowaną na Git

Ten eksperyment pokazuje, że narzędzia, których używamy do współpracy i CI/CD, są wystarczająco wydajne, aby można je było ponownie wykorzystać w samych podstawach naszych platform. Zaciera granicę pomiędzy tworzeniem aplikacji a zarządzaniem środowiskiem, w którym działa, jednocząc je w ramach jednego

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.