Pourquoi une ferme Mac M4 inter-régions sollicite l’état Pulumi
Sans séparation stacks / environnements / verrous, preview et up rivalisent pour la même ligne objet. En parallèle, RTT WAN, plugins et APFS 1 To masquent des problèmes d’état et de baux si vous ne les instrumentez pas.
- Double écriture : deux
pulumi upsur une stack sans porte exclusive corrompent la carte des URN — verrouillage objet ou table de baux pour sérialiser. - Ruée sur les previews : fragmenter seulement par branche tout en réutilisant une stack provoque encore des collisions au
refresh; il faut une identité de stack ou des espaces éphémères par changement. - Falaises disque : caches de fournisseurs, workspaces de build et sidecars de checkpoint rivalisent avec DerivedData sur le même volume ; les seuils diffèrent entre 1 To et 2 To.
Croisez ce guide avec la matrice DNS scindé et registre d’artefacts : les agents Mac doivent résoudre de façon homogène l’endpoint objet privé et les noms de registre avant d’ajuster les timeouts de verrou.
Matrice maîtresse : état, bail, fragment CI, disque
Utilisez le tableau comme contrat transversal infra, CI et FinOps : les lignes sont des postures, les colonnes les réglages à aligner avant fusion.
| Posture | Chemin du fichier d’état | TTL de bail (logique) | Fragment CI (preview) | Disque (1 To / 2 To) |
|---|---|---|---|---|
| Staging mono-région | Un préfixe par org : pulumi/<org>/staging/<stack>.json ; pas de clés prod partagées. |
TTL court (minutes) : récupération rapide si un agent meurt en plein preview. | Fragment par id de pull request ou nom d’espace ; jamais deux PR sur une même stack. | 1 To suffit si les caches tournent chaque semaine ; 2 To si plusieurs monorepos partagent un hôte. |
| Prod inter-régions | Inclure region dans la clé ou des compartiments séparés par juridiction ; miroir lecture seule si la politique l’autorise. |
TTL couvre le plus long pulumi up plus marge ; alertes sur baux périmés. |
Preview dans chaque région qui exécutera des applies ; une voie de pipeline par stack pour les applies. | 2 To par défaut si l’hôte porte aussi des builds natifs lourds en parallèle de Pulumi. |
| Monorepo à fort churn | Stacks par projet (app, réseau, données) plutôt qu’une méga-stack pour réduire la durée de détention du verrou. | Privilégier des renouvellements fréquents plutôt qu’un TTL géant ; caler sur le p99 des applies. | Jobs matrice : un fragment par répertoire de stack ; la merge queue impose l’ordre. | 1 To impose une purge agressive du cache plugins ; 2 To donne de la marge pour des fragments parallèles. |
Chemin du fichier d’état : compartiments, préfixes et identité de stack
La clé objet est du blast radius : préfixe plat + mauvais PULUMI_BACKEND_URL = écritures croisées. Encodez org, env, région ; la réplication d’audit ne remplace pas l’isolation des écrivains. Sur Mac CI, URL backend via identifiants éphémères partagés par la flotte parallèle ; stacks par contexte borné pour des refresh courts et moins de contention sur les baux.
TTL de bail : verrous backend, renouvellements et récupération
Backend S3 : écritures conditionnelles ou objets de verrou ; souvent une ligne de bail à côté du blob. Le TTL couvre le plus long refresh/up légitime mais libère vite après crash. Jitter WAN côté Mac : corrélez logs acquire/renew/release avec l’id de build ; TTL court = retries, TTL long = up bloquant.
Alignez le réglage du TTL sur le planificateur décrit dans la matrice Nomad : affinité et verrous de build — Nomad ou la merge queue portent la sérialisation à échelle humaine, le stockage objet celle à échelle d’état.
Fragmentation CI : previews parallèles sans applies parallèles
Preview parallèle : OK par stack distincte ou workspace isolé vers sa propre URL d’état ; interdit : deux up sur une stack depuis deux régions. Une voie merge-queue / stack pour le mutatif ; illimité en lecture seule. Sur Mac mini M4, fragmentez par répertoire, couple compte+région, ou stack éphémère par change-id ; déclarez le mapping verrou dans le YAML de pipeline.
Si des sidecars SQLite ou des volumes partagés côtoient Pulumi sur le même hôte, lisez la matrice SQLite WAL sur volume partagé : des pics d’E/S checkpoint allongent les applies et tendent indirectement la fenêtre de bail.
Niveau disque : 1 To contre 2 To sur workers Mac chargés Pulumi
Cache plugins Pulumi, SDK langages et harnais de test conteneurisés atterrissent tous sur APFS. Servez-vous des bandes d’utilisation pour décider quand des hôtes 1 To restent viables et quand la finance doit valider du 2 To avant l’effondrement du débit.
| Bande d’utilisation | Action Mac M4 1 To | Action Mac M4 2 To | Note Pulumi / CI |
|---|---|---|---|
| < 70 % | Conserver le cache plugins par défaut ; faire tourner les vieux SDK mensuellement. | Autoriser des fragments de preview supplémentaires par hôte. | Élargir modestement la concurrence matrice reste raisonnable. |
| 70–80 % | Jaune : purger les versions de plugins ; plafonner les pulumi preview concurrents par agent. |
Jaune : revoir la rétention d’instantanés ; marge pour deux previews de stacks. | Surveiller l’allongement des baux si l’attente disque monte. |
| 80–90 % | Rouge : suspendre de nouvelles voies de fragment ; planifier l’extension ce sprint. | Rouge : geler les jobs sandbox destructifs jusqu’à retour de marge. | Risque de timeout d’apply au milieu du verrou ; n’étendre le TTL qu’après analyse de cause. |
| > 90 % | Arrêt dur : répertoires temporaires corrompus, extractions plugin en échec. | Arrêt dur : applies pouvant dépasser le TTL en attendant l’E/S. | Retirer l’hôte de la rotation CI jusqu’à sonde disque verte. |
Checklist d’acceptation fusion : preview, verrou, promotion
- Diff d’URL d’état : l’URL backend du job planifié correspond au préfixe canonique de la stack (pas de pointeur prod accidentel).
- Acquisition de verrou : verrou exclusif obtenu avant
pulumi upoudestroy; l’identité inclut l’id de run pipeline. - Parité des previews : même commit pour toutes les previews régionales ; digests ou fichiers de plan joints à la demande de fusion.
- Fusion sous verrou de build : promotion d’artefacts ou d’images sérialisée avec le même motif étroit que les builds natifs — voir couche Nomad +
flockdans le guide lié. - Prévol disque : l’agent signale un espace libre au-dessus du seuil jaune ; échec rapide sinon.
- Vérif post-apply : smokes et
pulumi stack outputen lecture seule dans chaque région consommatrice.
Synthèse : acheter de la capacité Mac M4 alignée sur votre histoire d’état
Si vous élargissez les pipelines Pulumi parallèles, l’achat doit suivre trois courbes : attente sur verrous dans le backend distant, profondeur de file des previews par région, et taux de remplissage APFS sur chaque Mac mini M4. Attente de verrous qui monte pendant que le CPU reste bas : vous êtes lié à l’état — investissez d’abord dans le découpage des stacks et la discipline de merge queue avant d’ajouter des nœuds. CPU et disque qui crèvent ensemble : des hôtes 2 To dans la bonne géographie battent souvent l’allongement aveugle des TTL.
Guide d’achat : partez des p99 mesurés pour apply et refresh, choisissez la classe disque avec la matrice 1 To / 2 To, puis dimensionnez le nombre de nœuds pour qu’une seule voie d’apply par stack garde une file saine sans partager un disque saturé. Associez les régions à un endpoint compatible S3 joignable avec un RTT stable ; l’apply inter-régions est un choix d’architecture, pas une valeur par défaut.
Parcourez les forfaits publics, ouvrez le centre d’aide pour les schémas d’accès, et passez par Achat lorsque vous êtes prêt à ajouter du métal dédié — comparaison des références sans mur de connexion obligatoire.
Ajouter des nœuds Mac mini M4 pour une CI chargée Pulumi
Alignez les paliers 1 To ou 2 To sur la matrice disque, conservez une voie d’apply par stack, et montez en runners lorsque les previews — pas les verrous — deviennent le goulet. Articles liés : Nomad et verrous de build, DNS scindé & registre, SQLite WAL sur volume partagé.