Aetheus Docs
EN FR
Application

Concepts

Aetheus gère deux choses habituellement réparties entre des outils séparés : les serveurs que vous possédez, et les déploiements qui tournent dessus. Tout le produit s'exprime avec la poignée d'objets ci-dessous.

Organisations, projets et permissions

Une organisation est le locataire de plus haut niveau. Tout autre objet appartient à exactement une organisation, et rien n'est partagé implicitement entre organisations.

Un projet regroupe tout ce qui concerne une application : ses dépôts Git, ses pipelines, ses environnements, ses releases et ses artefacts. La navigation quotidienne se fait presque toujours dans le périmètre d'un projet.

Les permissions se donnent par type de ressource et par ressource. Un utilisateur qui peut lire un projet n'obtient pas automatiquement le droit d'y lancer des pipelines ni de lire ses coffres.

Serveurs et agents

Un serveur est une machine qui vous appartient. Aetheus ne s'y connecte pas en SSH depuis le plan de contrôle : c'est un agent, installé sur la machine, qui interroge le backend pour recevoir du travail. Cette inversion est ce qui permet à un serveur derrière du NAT ou un pare-feu strict de participer, tant qu'il peut joindre l'API en HTTPS.

Les agents existent pour Linux et Windows. Ils s'installent depuis une archive téléchargée dans l'application, s'enregistrent avec un jeton à usage unique, puis tournent en unité systemd ou en service Windows. Une fois enregistré, un agent envoie des battements de cœur, collecte l'inventaire de l'hôte (services, disques, paquets, certificats) et exécute le travail de pipeline qui lui est assigné.

Un agent qui cesse d'émettre est marqué hors ligne. Le travail qui lui était destiné n'est pas perdu silencieusement : l'ordonnanceur sait attendre le retour d'un runner configuré plutôt que d'échouer l'exécution d'emblée.

Pipelines et exécutions

Un pipeline est un document YAML décrivant des étapes et des tâches. La définition est Git d'abord : elle vit dans le dépôt sous .pipeline/<slug>.yaml, et le backend la relit depuis le dépôt canonique à chaque lancement. Pousser une nouvelle définition suffit donc pour que la prochaine exécution l'utilise, sans étape de synchronisation.

Une exécution est un lancement du pipeline. Elle épingle la révision source qu'elle construit, résout ses variables une fois, puis distribue chaque étape à un agent éligible. Chaque exécution porte un numéro séquentiel propre au pipeline, exposé aux tâches sous BUILD_PIPELINE_RUNNUMBER. C'est un compteur de build, pas une version sémantique : il augmente à chaque lancement du pipeline, y compris ceux qui échouent ou sont annulés.

Artefacts et releases

Un artefact est un fichier, ou un ensemble de fichiers, qu'une étape produit et transmet aux étapes suivantes, voire à des exécutions ultérieures. Les artefacts sont stockés par le backend, rattachés à un projet, et soumis à un quota de stockage.

Une release acte qu'une révision précise a été publiée vers une cible. Elle référence l'exécution qui l'a produite, le commit dont elle est issue et les artefacts livrés, de sorte qu'un retour arrière vise un objet précis.

Environnements

Un environnement est une cible de déploiement nommée à l'intérieur d'un projet, par exemple recette ou production. Les environnements portent leurs propres contrôles : un pipeline qui déploie vers un environnement protégé peut être refusé avant même de s'exécuter si les conditions ne sont pas remplies.

Variables, bibliothèques de variables et coffres

Les tâches lisent des valeurs par substitution $(NOM). Ces valeurs viennent de trois endroits, par confidentialité croissante :

  • les variables de pipeline, déclarées dans le YAML lui-même. Adaptées à tout ce que vous acceptez de lire dans le dépôt : ports, URL publiques ;
  • les bibliothèques de variables, jeux de valeurs nommés et partagés entre pipelines. Un pipeline ne voit qu'une bibliothèque qu'il liste explicitement ; rien n'est appliqué implicitement ;
  • les coffres, pour les secrets. Les valeurs sont chiffrées au repos et injectées dans le processus de la tâche plutôt qu'écrites dans la définition. Un pipeline qui référence un coffre absent est refusé, plutôt qu'exécuté avec une valeur vide.

Qualité, analyse et supervision

Au-delà du déploiement, Aetheus collecte les résultats de tests, la couverture, les remontées de lint et les rapports d'analyse statique produits par les tâches, et les restitue par exécution et par projet. Des portes d'analyse peuvent bloquer une exécution quand un rapport franchit un seuil.

Côté infrastructure, les agents alimentent des tableaux de bord couvrant la santé de l'hôte, les services en cours, la croissance du stockage, l'expiration des certificats TLS et l'outillage de sécurité. C'est la moitié du produit qui continue de servir quand aucun pipeline ne tourne.

Pour aller plus loin