Terraform, aux côtés du reste
Le provider Hyperfluid décrit vos ressources dans les mêmes modules que le reste de votre infrastructure, liens de service compris
Un seul plan Terraform
GitOps, CLI et Terraform
Votre plateforme en YAML, en Terraform, ou en une commande.
Trois façons de piloter la plateforme, le même état déclaré
Décrivez vos ressources en YAML : un opérateur Kubernetes natif réconcilie vos manifestes Git vers le cluster, avec l'outillage GitOps déjà en place. Décrivez-les en Terraform avec le provider Hyperfluid, aux côtés du reste de votre infrastructure. Ou pilotez-les depuis le terminal avec hfctl, sans ouvrir la console.
Spécifications
- Opérateur
- Unique, natif Kubernetes
- CRDs
- 39 ressources custom
- Provider Terraform
- hyperfluid, ressources et data sources
- CLI
- hfctl, du terminal a la plateforme
- Outils GitOps
- Argo CD, Flux, kubectl
- Dérive
- Phase Drifted, colonnes détaillées
Cas d'usage
Tout depuis le terminal
hfctl crée un pipeline et suit son exécution, gère les agents, déclare les liens de service, interroge vos données, sans ouvrir la console
Une commande au lieu d'un écran
Déploiement multi-environnements
Les mêmes manifestes traversent dev, staging et production, seules les valeurs changent
Un dépôt, plusieurs environnements
Infrastructure as Code
L'historique Git porte le qui, le quoi et le quand de chaque changement de ressource
Chaque changement est un commit Git
Reconstruction depuis Git
Ce qui est déclaré se réapplique par resynchronisation, sans reprendre les étapes à la main
Infrastructure déclarative reconstructible
En action
La plateforme décrite dans Git
Une équipe plateforme veut que l'état de son cloud interne vive dans un dépôt Git, pas dans un historique de clics
- Déclarer les ressources en CRD Kubernetes : catalogues du moteur SQL, schémas et tables Iceberg, applications conteneurisées, bases managées
- Appliquer les manifestes avec l'outil déjà en place : Argo CD, Flux ou kubectl
- L'opérateur Hyperfluid réconcilie chaque CRD vers les ressources Kubernetes correspondantes
- La console lit le statut des CRD et affiche la phase de chaque ressource : Ready, Pending, Drifted ou Failed
L'état de la plateforme est décrit dans Git, la console en donne la lecture
Le retour arrière est un commit
Une équipe d'exploitation doit annuler un changement de configuration parti en production
- Identifier le commit qui a modifié le manifeste concerné
- Faire un git revert de ce commit et le pousser sur la branche suivie
- Le réconciliateur GitOps resynchronise les ressources sur l'état précédent
- L'opérateur ramène l'infrastructure vers l'état déclaré, la console affiche la phase de réconciliation
Le retour arrière passe par Git, sans intervention manuelle sur le cluster
L'origine de chaque table est visible
Un analyste BI ouvre le catalogue et doit distinguer ce qui est déclaré de ce qui a été créé à la main
- Dans le moteur SQL de la console, chaque schéma et chaque table Iceberg porte un badge d'origine
- Le badge distingue une ressource déclarée hors console, créée dans la console, produite par un pipeline, ou ad hoc sans CRD correspondant
- Si la table réelle s'écarte de sa déclaration, la phase passe à Drifted et la console détaille les colonnes manquantes ou en trop
- La correction se fait dans le manifeste versionné, l'opérateur réconcilie
L'écart entre le catalogue déclaré et le catalogue réel se lit dans la console
Infrastructure déclarative
Opérateur
Natif Kubernetes
Un opérateur unique et des ressources custom dans le groupe hyperfluid.nudibranches.tech, appliquées comme le reste de votre cluster.
Manifestes
Git fait référence
Catalogues, schémas et tables Iceberg, applications conteneurisées, bases managées : chaque ressource est un manifeste versionné.
Outillage
Argo CD, Flux, kubectl
Les CRDs s'appliquent avec l'outil déjà en place. Les champs impératifs, comme restartedAt sur une ContainerApp, sont documentés pour vos règles de diff-ignore.
Dérive
Signalée, jamais destructive
L'opérateur réconcilie en continu vers l'état déclaré. Sur une table Iceberg, l'écart passe en phase Drifted : l'ajout des colonnes manquantes est opt-in, aucune colonne n'est supprimée automatiquement.
Avantages clés
- Les ressources de la plateforme sont décrites dans des manifestes versionnés, pas dans un historique de clics
- L'opérateur réconcilie en continu les ressources vers l'état déclaré
- L'écart entre le déclaré et le réel est visible dans la console, avec le détail des colonnes en cause
- Le retour arrière est un git revert, sans manipulation manuelle du cluster
- Les CRDs s'appliquent avec l'outillage GitOps déjà en place, Argo CD, Flux ou kubectl
Prêt à automatiser vos déploiements ?
Découvrez comment GitOps peut transformer votre workflow infrastructure.