PULUMI_HOME und npm, Leitplanken für parallele Züge mit Timeout und Retry sowie ein Abnahme- und Rollback-Muster rund um das Lockfile. Vertiefung zu anderen IaC-/Paketpfaden: Terraform-Registry-/Mirror-Matrix (HCL-Ökosystem) und Yarn-Berry-/PnP-Registry-Matrix für Node-Monorepos.
Strukturierte Daten: Auf dieser Seite sind BlogPosting und BreadcrumbList als JSON-LD hinterlegt.
Auswahlprämissen & Risiko-Checkliste
Auf gemieteten Remote-Mac-Buildern verschmelzen 2026 typischerweise drei Downloadpfade: npm zieht @pulumi/*-Pakete und ggf. Hilfsbibliotheken, die Pulumi-CLI lädt sprach- und cloud-spezifische Plugins in den Home-Baum, und Ihr Unternehmens-HTTP-Proxy begrenzt gleichzeitig Sockets und TLS-Inspection. Wer nur „mehr Parallelität“ dreht, ohne Lockfile-Disziplin, erzeugt flackernde Builds: mal grün, mal ein Minor-Drift – auditierbar ist das nicht.
Im Gegensatz zu reinen Container-Builds ist der dominante Risikofaktor oft nicht die M4-CPU, sondern WAN-Jitter, 429-Antworten vom öffentlichen npm registry und ein gemeinsam genutzter SSD-Cache unter PULUMI_HOME. Für multinationale Teams kommen Zeitzonen, unterschiedliche DNS-Auflösungen und regionale Spiegel dazu – dieselbe Pipeline verhält sich in EU und APAC dann messbar anders.
npm install statt npm ci auf Merge-Branches → nicht reproduzierbare Provider-Minor-Versionen.PULUMI_HOME: parallele Jobs schreiben in dieselbe Plugin-Struktur → sporadische Korruption oder „Plugin nicht gefunden“.registry.npmjs.org, CI über Firmen-Spiegel – Hash- und Metadaten-Pfade weichen ab.Registry- & Cache-Verzeichnis-Parametertabelle
Die folgende Matrix fasst die wichtigsten Schalter zusammen, die Sie in Runbooks und Pipeline-Templates dokumentieren sollten. Pfade beziehen sich auf ein Arbeitsverzeichnis ${CI_PROJECT_DIR} bzw. ${GITHUB_WORKSPACE}; passen Sie Präfixe an Ihren Orchestrator an.
| Parameter | Zweck | Empfehlung Remote-Mac (2026) |
|---|---|---|
PULUMI_HOME |
Plugin-Cache, Credentials-Hilfen, CLI-Zustand | Pro Job z. B. ${WORKSPACE}/.pulumi-home-${CI_JOB_ID} – vermeidet Querzugriffe auf APFS. |
npm config set registry … |
Ziel-npm registry für @pulumi/* |
Öffentlich oder Firmen-Spiegel; identisch zu lokalen .npmrc-Werten im Repo. |
maxsockets |
Obergrenze gleichzeitiger TCP-Verbindungen npm | 8–15 auf geteilten Runnern; senken bei 429-Stürmen. |
fetch-retries / fetch-retry-mintimeout / fetch-retry-maxtimeout |
npm-seitige Wiederholungen | 5 / 20000 ms / 120000 ms als Ausgangspunkt für grenzüberschreitende Links. |
fetch-timeout |
Harte Obergrenze pro Anfrage | 300000 ms (5 min) nur wenn Proxy-Logs sonst zu früh abbrechen; sonst 120000 ms testen. |
package-lock.json |
Lockfile-Wahrheit für npm-Provider | Immer committen; CI nur npm ci; PR-Gate auf Lock-Diff bei Version-Bumps. |
Kopierbar: Umgebung, npm-Limits, isoliertes PULUMI_HOME
# Grenz-CI / bash – vor npm ci und pulumi
export PULUMI_HOME="${PULUMI_HOME:-${CI_PROJECT_DIR}/.pulumi-home-${CI_JOB_ID:-local}}"
mkdir -p "$PULUMI_HOME"
# npm: Parallelität & Retry (User-Config nur für diesen Job)
export NPM_CONFIG_MAXSOCKETS="${NPM_CONFIG_MAXSOCKETS:-12}"
export NPM_CONFIG_FETCH_RETRIES="${NPM_CONFIG_FETCH_RETRIES:-5}"
export NPM_CONFIG_FETCH_RETRY_MINTIMEOUT="${NPM_CONFIG_FETCH_RETRY_MINTIMEOUT:-20000}"
export NPM_CONFIG_FETCH_RETRY_MAXTIMEOUT="${NPM_CONFIG_FETCH_RETRY_MAXTIMEOUT:-120000}"
export NPM_CONFIG_FETCH_TIMEOUT="${NPM_CONFIG_FETCH_TIMEOUT:-300000}"
# optional: Firmen-Registry (Beispiel-URL ersetzen)
# npm config set registry "https://npm.acme.example/" --location=user
npm ci --prefer-offline --no-audit --no-fundTLS-Inspection: Setzen Sie NODE_EXTRA_CA_CERTS auf die interne CA-Datei, wenn der Proxy TLS aufbricht – sonst scheitert npm ci mit kryptischen UNABLE_TO_GET_ISSUER_CERT-Fehlern, während Browser und Docker „funktionieren“.
Für Artefakt- und OCI-lastige Nachbarjobs auf derselben Maschine lohnt der Abgleich mit der ORAS-/OCI-Pull-Matrix (gemeinsame SSD-Watermarks), ohne die Pulumi-Logik zu wiederholen.
Parallele Züge & Fehler-Backoff
Die Pulumi-Engine startet mehrere Plugin-Operationen nacheinander oder parallel, während npm seinerseits viele kleine GETs bündelt. Ohne globales Budget feuern Dutzend Pipelines gleichzeitig in dieselbe Region des npm registry – die klassische 429-Spirale. Begrenzen Sie daher Pipeline-Parallelität (Orchestrator-Slots) und npm-maxsockets gemeinsam; messen Sie eine Woche lang p95 und 429-Rate.
| Profil | Gleichzeitige Pulumi-Jobs / Host | NPM_CONFIG_MAXSOCKETS |
CLI-/Plugin-Retry (äußere Schleife) |
|---|---|---|---|
| Konservativ | 1 | 8 | 5 Versuche, Sleep 2→4→8→16 s + Jitter, Cap Gesamt ~6 min |
| Ausgewogen | 2 | 12 | 6 Versuche, Cap einzelner Sleep 60 s |
| Aggressiv | 3+ | 15 (nur mit eigenem Spiegel) | Nur mit dediziertem Runner und Monitoring |
# Äußere Retry-Hülle um pulumi preview (nicht-interaktiv)
set -euo pipefail
max=6
delay=2
n=1
until pulumi preview --non-interactive --stack "${PULUMI_STACK_NAME}"; do
if [ "$n" -ge "$max" ]; then echo "pulumi preview failed after $n attempts" >&2; exit 1; fi
jitter=$((RANDOM % 5))
sleep $((delay + jitter))
delay=$((delay * 2))
if [ "$delay" -gt 60 ]; then delay=60; fi
n=$((n + 1))
doneKoppeln Sie diese Schleife mit Metriken (Dauer, Exit-Code, letzte HTTP-Meldung aus npm-Debug), damit Sie echte WAN-Probleme von fehlerhaften Stack-Konfigurationen trennen.
Kurz-FAQ:
Muss das öffentliche npm-Registry überhaupt erreichbar sein? Wenn alle @pulumi/*-Artefakte und transitive Abhängigkeiten vollständig in Ihrem Spiegel liegen, nein – dann blockieren Sie ausgehende Zugriffe und testen Sie mit npm ping nur den Spiegel. Sobald jedoch ein Paket fehlt, führt ein harter Block zu kryptischen Fehlern; whitelisten Sie lieber explizite Upstream-Pfade oder pflegen Sie einen vollständigen Offline-Spiegel.
Reicht package-lock.json allein für reproduzierbare Plugins? Es fixiert npm-Seite; Pulumi kann zusätzlich binäre Plugins nachziehen. Versionieren Sie daher auch CLI- und Stack-Hinweise (Docker-Image-Tags, pulumi version im Log) und prüfen Sie nach preview, ob die erwarteten Binär-Hashes zu Ihrer Baseline passen.
Abnahmefälle & Rollback
Abnahme (mergefähig): (1) npm ci ohne Lockfile-Änderung; (2) pulumi preview --non-interactive mit festem Stack und gesetzem PULUMI_ACCESS_TOKEN aus dem Secret-Store; (3) optional git diff --exit-code package-lock.json nach dem Lauf – jede Änderung bricht den Job; (4) Prüfling: erwartete Plugin-Versionen aus package.json/Pulumi.yaml-Hinweisen stimmen mit dem tatsächlich geladenen Plugin überein (über Logs oder pulumi plugin ls).
Rollback: Bei fehlgeschlagenem Preview zuerst das isolierte PULUMI_HOME-Verzeichnis des Jobs verwerfen und den Lauf wiederholen – das beseitigt halb entpackte Plugins. Bleibt der Fehler, kehren Sie zum letzten grünen Commit mit unverändertem Lockfile zurück und stufen Sie die npm-Registry temporär auf den konservativen Pfad (weniger Parallelität, höhere Retries). Dokumentieren Sie jede Änderung an Spiegel-URLs im gleichen Change wie Infrastructure-Code, damit grenzüberschreitende Teams nicht „stille“ Abweichungen produzieren.
Fazit
Stabiles Pulumi auf Remote Mac mit npm registry und grenzüberschreitenden Pfaden ist 2026 vor allem Konfigurations- und Messdisziplin: eigenes PULUMI_HOME, festes Lockfile, begrenzte Sockets und eine äußere Retry-Hülle schlagen rohe Kernzahl. Kombinieren Sie das mit einem klar gewählten Runner-Standort und ausreichend APFS-Reserve – dann skalieren Sie Jobs, nicht Zufallsfehler.
Öffentliche Informationen: Preise, Kaufen, Hilfe-Center, das Technische Blog und die Startseite. Für dauerhafte Apple-Silicon-CI mit planbarer I/O-Last: passendes Miet-Paket wählen und einen Node-Standort wählen, der Ihrer Registry-Region und Compliance-Vorgaben entspricht – so bleiben npm- und Plugin-Züge wiederholbar statt tageszeitabhängig.
Remote-Mac-CI für Pulumi & npm
M4-Leistung, isolierte Caches und nachvollziehbare Pull-Pfade. Pläne und Hilfe – ohne Login-Pflicht.