Von grafischem Desktop und Terminalsitzungen bis zu unbeaufsichtigten Builds: Prüfen Sie Knoten, Zugangsdaten, Netzwerk und Toolchain stets in derselben Reihenfolge. Jede Bestellung umfasst einen dedizierten Apple-Silicon-Computer – keine virtuelle Maschine.
Der grafische Desktop eignet sich für visuelle Arbeiten, das Terminal für Entwicklung und Diagnose, Automatisierung für reproduzierbare Pipelines. Alle drei Varianten können parallel genutzt werden, müssen aber mit getrennten Berechtigungen und Zugangsdaten verwaltet werden.
Ideal für Xcode-Projektkonfiguration, Simulator-Debugging, den Import von Zertifikatsdateien, die visuelle Logprüfung und Remote-Arbeiten mit der vollständigen macOS-Oberfläche. Prüfen Sie bei der ersten Verbindung zunächst Skalierung, Tastaturbelegung, Zwischenablage und Dateitransferrechte.
Ideal für Abhängigkeitsinstallation, Repository-Synchronisierung, Build-Befehle, Logsammlung und Prozessprüfung. Prüfen Sie beim Verbinden den Host-Fingerprint, kopieren Sie private Schlüssel nicht in gemeinsam genutzte Verzeichnisse und verwenden Sie für Routineaufgaben ein separates Konto mit eingeschränkten Rechten.
Ideal für Continuous Integration, zeitgesteuerte Builds, Testausführung und Artefaktarchivierung. Verwenden Sie für den Runner ein eigenes Arbeitsverzeichnis, eine klar definierte Parallelität und begrenzten Schlüsselzugriff. Bereinigen Sie nach Abschluss temporäre Dateien und Logs mit möglicherweise sensiblen Angaben.
Beginnen Sie die Fehlersuche nicht mit wiederholten Verbindungsversuchen. Notieren Sie zuerst die in der Konsole angezeigten Knotendaten und prüfen Sie anschließend Ihre lokale Umgebung Schritt für Schritt. So liefern Sie auch bei einem Support-Ticket den vollständigen Kontext.
Nach jedem Wechsel von Knoten, Netzwerk oder Client erneut prüfen.
Stellen Sie zunächst die grundlegende Verbindung her und passen Sie danach Anzeige- und Übertragungsoptionen an. Ändern Sie immer nur eine Variable, damit sich bei Problemen Netzwerk, Client und Sitzungskonfiguration unterscheiden lassen.
Melden Sie sich in der Konsole an, öffnen Sie die entsprechende Instanz und kopieren Sie aktuelle Verbindungsadresse, Port und Benutzernamen. Verwenden Sie keine in alten Bestellungen gespeicherten Sitzungsdaten und erraten Sie die Adresse nicht anhand des Knotennamens.
Geben Sie die Verbindungsdaten in einem vertrauenswürdigen Netzwerk ein. Prüfen Sie bei der ersten Identitätsbestätigung die Instanzdaten. Beobachten Sie nach dem Öffnen des Desktops zunächst Tastatur- und Mauseingaben, bevor Sie große Downloads oder Builds starten.
Wählen Sie die Auflösung passend zu Bildschirm und Verbindungsqualität. Bei unscharfer Schrift passen Sie zuerst die Client-Skalierung an. Bei verzögerter Interaktion reduzieren Sie Bildgröße oder Bildwiederholrate und vergleichen anschließend die Reaktion.
Kopieren Sie zunächst einen Text ohne vertrauliche Informationen und übertragen Sie anschließend eine kleine Testdatei. Aktivieren Sie die bidirektionale Übertragung nur bei Client-Unterstützung und entsprechender Projektfreigabe. Deaktivieren Sie danach nicht benötigte Freigaben.
Die Oberfläche dient nur als Beispiel für eine Verbindungsprüfung. Maßgeblich sind die in der Konsole und im verwendeten Client angezeigte Adresse, Auflösung und verfügbaren Optionen.
Eine erfolgreiche SSH-Verbindung bedeutet nicht, dass die Pipeline bereits einsatzbereit ist. Toolversionen, Arbeitsverzeichnis, Ausführungsrechte, Cache-Strategie und Artefaktpfad müssen jeweils separat geprüft werden.
Verwenden Sie für den Remote-Knoten einen eigenen Schlüssel und laden Sie den privaten Schlüssel weder in ein Repository noch in Build-Caches oder gemeinsam genutzte Teamverzeichnisse. Vergleichen Sie beim ersten Verbindungsaufbau den vom Client angezeigten Host-Fingerprint mit den Konsolendaten. Bei Abweichungen Verbindung abbrechen und Knoten erneut prüfen.
chmod 600 ~/.ssh/hireamac_node
ssh-keygen -lf ~/.ssh/hireamac_node.pub
ssh -i ~/.ssh/hireamac_node build@node-address
uname -m
sw_vers
df -h
xcodebuild -versionIm Beispiel muss node-address durch die aktuelle, von der Konsole zurückgegebene Instanzadresse ersetzt werden. Schreiben Sie Adresse, privaten Schlüssel oder gültige Zugangsdaten niemals in öffentliche Skripte.
Führen Sie zunächst einen reproduzierbaren Build über ein normales Terminal aus und registrieren Sie erst danach den Runner. Prüfen Sie anschließend Aufgaben-Labels, Arbeitsverzeichnis, Shell-Umgebung und Parallelitätsgrenzen, damit die Warteschlange nur kompatible macOS-Aufgaben diesem Knoten zuweist.
mkdir -p ~/ci-workspace
cd ~/ci-workspace
git --version
xcrun --find xcodebuild
xcode-select -p
security find-identity -v
ps aux | grep runner
du -sh ~/ci-workspaceZertifikatsdateien, Signaturmaterial und Repository-Token sollten über einen kontrollierten Prozess eingespeist werden. Logs dürfen nur die für die Diagnose nötigen Felder enthalten. Prüfen Sie nach Abschluss temporäre Verzeichnisse, Derived Data und exportierte Artefakte.
Stellen Sie sicher, dass Shell, Git, Xcode-Kommandozeilentools und Build-Skripte auch in einer nicht interaktiven Umgebung ausführbar sind.
Verwenden Sie eindeutige Verzeichnisse für Repository, Cache, Logs und Artefakte, damit sich verschiedene Aufgaben nicht gegenseitig überschreiben.
Der Runner erhält nur die für die Aufgabe nötigen Rechte. Der Schlüsselzugriff darf nicht auf unabhängige Prozesse ausgeweitet werden.
Bewahren Sie Exit-Codes, Build-Phasen und bereinigte Logs auf, damit fehlgeschlagene Aufgaben erneut ausgeführt werden können.
Verlagern Sie nicht den gesamten Workflow auf einmal. Jede Route behält Eingaben, Prüfpunkte und Rückfallaktionen. Stabilisieren Sie eine Route, bevor Sie die nächste bearbeiten.
Projekt-Repository, Lockfiles für Abhängigkeiten, Testressourcen, Build-Skripte und zu erhaltende historische Artefakte. Ordnen Sie öffentlichen, internen und vertraulichen Inhalt zunächst getrennt zu.
Vergleichen Sie Dateianzahl, Prüfsummen, Verzeichnisrechte und Speicherbelegung. Laden Sie Abhängigkeiten erneut und stellen Sie sicher, dass sich das Projekt im neuen Verzeichnis öffnen und bauen lässt.
Bewahren Sie eine lokale schreibgeschützte Kopie und eine Migrationsliste auf. Löschen Sie bei fehlgeschlagener Prüfung die unvollständige Cloud-Kopie, korrigieren Sie den Übertragungsumfang und beginnen Sie erneut.
macOS-Anforderungen, Xcode- und Swift-Version, Lockfiles des Paketmanagers, Namen der Umgebungsvariablen und Build-Befehle. Übernehmen Sie keine unbekannten Altlasten aus lange gewachsenen Konfigurationen.
Dokumentieren Sie Systemarchitektur und Toolversionen, führen Sie einen sauberen Build und grundlegende Tests aus und vergleichen Sie Artefaktnamen, Signaturstatus, Exit-Code und erforderliche Logs.
Bewahren Sie Versionsliste und Installationsreihenfolge auf. Kehren Sie bei Versionskonflikten zur zuletzt geprüften Kombination zurück, statt auf dem Produktions-Build-Knoten unbekannte Abhängigkeiten fortlaufend zu installieren.
Runner-Konfiguration, Aufgaben-Labels, Parallelitätsstrategie, Arbeitsverzeichnis, Art der Zugangsdateninjektion, Cache-Verzeichnis und Regeln für den Artefaktexport.
Führen Sie zuerst eine einzelne Aufgabe aus und prüfen Sie anschließend aufeinanderfolgende Aufgaben sowie Wiederholungen nach Fehlern. Kontrollieren Sie nach Abschluss Prozesse, temporäre Dateien, Cache und Logs.
Pausieren Sie die Aufgaben-Labels des neuen Runners, damit die Warteschlange zum bisherigen Ausführungsknoten zurückkehrt. Exportieren Sie Fehlerlogs und bereinigen Sie unvollständige Arbeitsverzeichnisse.
Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und die US-Ostküste laufen 365 Tage im Jahr durchgehend. Die Verbindung hängt weiterhin von Standort, Anbieterroute, lokalem Netzwerk und Client-Einstellungen ab.
| Knoten | Regionscode | Zeitzone | Geeignete Workflows | Schwerpunkt der Verbindungsprüfung |
|---|---|---|---|---|
| Singapur | SG | UTC+8 | Remote-Entwicklung für Teams in Südostasien, regionale Builds und grenzüberschreitende Zusammenarbeit | Büro- und Ersatznetzwerk getrennt testen; Handshake, Eingabereaktion und Dateitransfer dokumentieren |
| Japan (Tokio) | JP | UTC+9 | Projekte für den japanischen Markt, iOS-Builds sowie Zusammenarbeit von Teams in Tokio und Umgebung | Lokale Anbieterroute prüfen und Stabilität von grafischer Desktop- und Terminalsitzung vergleichen |
| Südkorea (Seoul) | KR | UTC+9 | Entwicklung für koreanische Teams, Remote-Arbeit in Seoul und Continuous Integration | Kurze Sitzungen und lange Aufgaben nacheinander ausführen und Schwankungen zu bestimmten Zeiten beobachten |
| Hongkong | HK | UTC+8 | Grenzüberschreitende Zusammenarbeit in Asien, grafische Desktop-Arbeit und Aufgabenübergaben über mehrere Standorte | Proxy- und Unternehmensnetzwerkrichtlinien prüfen; zusätzliche Weiterleitungen vermeiden |
| US-Ostküste | US-E | UTC−5 / UTC−4 | Entwicklung, Build-Warteschlangen und Arbeit im Schichtbetrieb für Teams an der nordamerikanischen Ostküste | Zu den tatsächlichen Arbeitszeiten des Teams testen und grenzüberschreitende Route von der Leistung interner Aufgaben trennen |
Bei häufiger Interaktion mit dem grafischen Desktop sollten Entwicklerstandort und gewohntes Netzwerk ausschlaggebend sein. Wählen Sie den Remote-Arbeitsknoten nicht allein nach dem Standort des Kundenmarkts.
Testen Sie Verbindungsaufbau, fortlaufende Eingaben, Übertragung kleiner Dateien und lange Builds getrennt. Wiederholen Sie die Tests mindestens zu den üblichen Teamzeiten; ein Einzeltest steht nicht für die langfristige Verbindung.
Fixieren Sie nach der Knotenauswahl Clientversion, Auflösung und Netzwerkstrategie. Ändern Sie bei Schwankungen jeweils nur eine Bedingung und dokumentieren Sie die Ergebnisse vorher und nachher.
Ein dedizierter physischer Knoten reduziert Störungen durch gemeinsam genutzte Rechenressourcen. Zugangsdaten, Sitzungen, Projektdaten und Exporte müssen dennoch nach einem festen Ablauf verwaltet werden.
Rotieren Sie Zugangsdaten sofort bei Personalwechsel, Geräteverlust, ungewöhnlichen Anmeldungen oder offengelegten Zugangsdaten. Verwenden Sie für grafischen Desktop, SSH und CI-Runner getrennte Zugangsdaten, damit ein kompromittierter Zugang den Schaden nicht ausweitet.
Nutzen Sie für tägliche Builds kein Konto mit weitreichenden Rechten. Erhöhen Sie Rechte nur vorübergehend für Installationen oder Systemkonfigurationen und kehren Sie danach zur normalen Umgebung zurück.
Beenden Sie vor dem Verlassen des Arbeitsplatzes nicht mehr benötigte Terminals, Weiterleitungen und grafische Desktopsitzungen. Prüfen Sie nach Automatisierungsaufgaben, dass der Runner keine Unterprozesse hinterlassen hat und das Arbeitsverzeichnis nicht dauerhaft belegt.
Prüfen Sie Download-Ordner, Schreibtisch, Shell-Verlauf, temporäre Verzeichnisse, Build-Logs und Cache. Entfernen Sie nicht mehr benötigte Zertifikatsdateien, Tokenkopien, Debug-Pakete und Testressourcen mit Nutzerdaten.
Exportieren Sie rechtzeitig Quellcodeänderungen, Build-Artefakte, Logs, Konfigurationslisten und zu erhaltende Daten. Prüfen Sie anschließend in einer anderen Umgebung, ob das Archiv lesbar ist; der Knoten darf nicht als einzige Sicherung dienen.
Drei Apple-Silicon-Tarife mit dedizierten physischen Computern decken fünf Knoten in Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und an der US-Ostküste ab. Mieten Sie tage-, wochen-, monats- oder quartalsweise. Die aktuelle Verfügbarkeit zeigt die Konsole in Echtzeit.
Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe. Alle Bestellungen werden in US-Dollar (USD) abgerechnet; verfügbare Zahlungs-Gateways liefert die Backend-Schnittstelle.