Une expérience pour utiliser GitHub Actions comme plan de contrôle pour un PaaS

Une union inattendue : Git et la plateforme

Le monde du DevOps repose sur l’automatisation. Nous scénarisons les déploiements, gérons l'infrastructure en tant que code et nous efforçons de rendre chaque processus reproductible et fiable. Au cœur de cette démarche pour d’innombrables équipes de développement se trouve GitHub, la plateforme omniprésente pour la collaboration en matière de code. Mais et si sa puissance pouvait être étendue au-delà du contrôle de version et du CI/CD ? C'est l'histoire d'une expérience visant à repousser les limites des actions GitHub, en le transformant d'un orchestrateur de construction et de test en un système nerveux central (le plan de contrôle) pour une plate-forme entière en tant que service (PaaS).

Redéfinir le plan de contrôle

Traditionnellement, un plan de contrôle PaaS est un logiciel complexe et sur mesure. Il s'agit d'une autorité centrale qui reçoit des commandes (déployer ceci, faire évoluer cela) et orchestre l'infrastructure sous-jacente pour y parvenir. Il gère le provisionnement, la mise en réseau, la sécurité et la gestion du cycle de vie. En construire un est une entreprise d’ingénierie importante. L'hypothèse de notre expérience était simple : pourrions-nous exploiter le flux de travail existant, puissant et familier de GitHub Actions pour effectuer ces mêmes tâches ? Au lieu d'écrire un plan de contrôle monolithique, nous utiliserions des fichiers YAML, des requêtes d'extraction et le robuste écosystème événementiel de GitHub pour gérer notre plate-forme.

« L'outil le plus puissant est celui que votre équipe sait déjà utiliser. En utilisant GitHub Actions comme plan de contrôle, nous n'avons pas eu besoin de créer une interface utilisateur ou d'enseigner de nouveaux concepts ; nous avons étendu le workflow existant centré sur Git que les développeurs adorent.

Architecture du PaaS piloté par GitHub

L'architecture était centrée sur le traitement des déclarations d'infrastructure et des configurations d'applications comme du code dans un référentiel. Le flux de travail d'un développeur pour déployer un nouveau microservice, par exemple, ressemblerait à ceci :

Un développeur crée un nouveau répertoire pour son service et ajoute un fichier « mewayz.app.yaml » définissant ses besoins : CPU, mémoire, variables d'environnement et domaine.

Ils valident ce fichier et ouvrent une Pull Request. L’acte même d’ouvrir le PR déclenche un workflow GitHub Actions.

Le workflow, agissant comme plan de contrôle, analyse le fichier YAML, valide la configuration et effectue un essai à sec des modifications de l'infrastructure.

Une fois le PR fusionné, un workflow de déploiement distinct est déclenché. Ce workflow contient la logique permettant de communiquer avec diverses API cloud (Kubernetes, AWS, etc.) pour réellement provisionner les ressources nécessaires et déployer le service.

Le workflow commente ensuite la validation avec un lien en direct vers le service nouvellement déployé, bouclant ainsi la boucle.

Cette approche s'intègre parfaitement à la philosophie Mewayz de modularité et d'expérience de développement. L'état de l'ensemble de la plateforme était contrôlé par les versions, vérifiable et suivait le même processus de révision collaborative que le code de l'application lui-même.

Leçons de la frontière

L’expérience a été un succès retentissant en prouvant la faisabilité. Nous avons réalisé un PaaS entièrement fonctionnel, piloté par Git-ops, où chaque modification était traçable et réversible. Cependant, cela a également révélé des considérations importantes. La gestion d’état complexe repousse parfois les limites de ce qui est élégant dans un fichier YAML. Bien que GitHub Actions soit incroyablement évolutif, pour les plates-formes à grande échelle, le temps de mise en file d'attente et d'exécution des flux de travail pourrait devenir un goulot d'étranglement par rapport à une API de plan de contrôle dédiée à faible latence. La sécurité était primordiale ; nous avons dû gérer méticuleusement les secrets et les autorisations pour garantir que le coureur GitHub Action disposait de l'accès minimum exact requis pour effectuer ses tâches, un concept parfaitement aligné sur les principes de sécurité dès la conception de Mewayz.

Un aperçu d'un avenir centré sur Git

Cette expérience démontre que les outils que nous utilisons pour la collaboration et le CI/CD sont suffisamment puissants pour être réutilisés dans la base même de nos plateformes. Il brouille la frontière entre le développement d'une application et la gestion de l'environnement sur lequel elle s'exécute, en les unifiant sous un seul

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.