ノードの引き渡しからビルドのベースラインまで

クラウドMacを開発とCIのワークフローに接続する

まずリージョン、モデル、契約期間を選び、認証情報の強化、SSH検証、グラフィカルデスクトップの初期設定、初回Xcodeビルドを行います。各手順の状態を記録し、後から確認できるようにします。

ノード種別
専用Apple Silicon物理ノード
提供リージョン
SG · JP · KR · HK
達成目標
初回ビルドとCIテストジョブの成功
ORB / NODE COMMISSIONING RUNBOOK 01
選定 強化 接続 ビルド CI接続
対象ノード Apple Silicon / 専用物理マシン
リージョン
選択待ち
SSHキー
入力待ち
Xcodeベースライン
検証待ち
ランナー
登録待ち
引き渡し判定 すべてのチェック完了後に本番ジョブを実行
アドレス、認証情報、リアルタイムの利用状況はコンソールの表示を基準にします 365 DAYS
開始前のチェック

6項目を先に準備

モデル選びはチップだけでは決まりません。リージョン、アクセス方法、ツールチェーンのバージョン、チームの担当者が、開通後の最初の1時間を大きく左右します。

01

対象リージョン

シンガポール、日本(東京)、韓国(ソウル)、香港から、主要な開発者や成果物ストレージへの経路に適したリージョンを選びます。個人の所在地だけでなく、コードリポジトリや依存関係ソースへのネットワーク経路も考慮してください。

SG · JP · KR · HK
02

ノードモデル

軽量なビルドならOrb M4 16から開始できます。大規模な依存グラフや並列ジョブにはOrb M4 24、高メモリビルドやローカルAI実験にはOrb M4 Proを検討してください。

全3構成
03

契約期間

短期検証には日単位または週単位、安定したパイプラインには月単位または四半期単位が適しています。先に社内の受け入れ時期を記録してから更新を判断し、フォローされない一時注文に本番リリースを任せないようにします。

日 · 週 · 月 · 四半期
04

SSH公開鍵

このノード専用のEd25519公開鍵を用意し、秘密鍵は承認済みデバイスまたは管理下のキーシステムにのみ保存します。個人用の普段使いキーをチーム共有の認証情報としてコピーしないでください。

Ed25519推奨
05

チームアクセスリスト

ノード責任者、CI管理者、障害連絡先を明確にします。各メンバーに個別のキーを割り当て、追加・変更・失効の記録を残します。チーム全体で1つの認証情報を共有しないでください。

1人1認証情報
06

macOSツールチェーン

macOS、Xcode、コマンドラインツール、Ruby、Node、CocoaPods、依存関係管理ツールのバージョンを事前に固定します。要件をリポジトリに記載し、ノード初期化時に項目ごとに確認してください。

再現可能なバージョン管理
注文と引き渡し

3つの選択でノード構成を決める

コンソールにはモデルごとの選択可能なリージョンが表示されます。カタログの組み合わせは通常注文できますが、実際の空き状況はコンソールのリアルタイム表示を基準にしてください。

  1. 01

    3モデルから1つを選択

    Orb M4 16はM4、16GBメモリ、256GBストレージ。Orb M4 24はM4、24GBメモリ、512GBストレージ。Orb M4 ProはM4 Pro、64GBメモリ、2TBストレージです。

  2. 02

    リージョンと契約期間を選択

    リージョンはシンガポール、日本(東京)、韓国(ソウル)、香港から選択でき、期間は日、週、月、四半期から選べます。チーム内の資産記録にリージョンコードと更新時期を記載してください。

  3. 03

    注文内容を確認して引き渡し記録を待つ

    モデル、リージョン、期間、追加項目を確認して注文します。ノードアドレス、初期アクセス情報、サービス状態はコンソールに表示されます。未承認の経路で転送しないでください。

ノードの認証情報とセキュリティ

入口を先に絞り、その後で開発環境を導入

初期情報は最初の管理された接続の確立にのみ使用します。キーの検証、アクセス調整、復旧情報の記録が完了するまで、本番リポジトリや署名素材を持ち込まないでください。

FIRST ACCESS RECORD 初回ログイン後に実行

一時アクセスを監査可能な入口に変える

  • 引き渡し情報を確認 ノード番号、アドレス、ポート、リージョンが注文内容と一致することを確認し、結果をチームの資産リストに記録します。
  • 専用SSH公開鍵を書き込む 管理者、開発者、自動化ランナーに異なるキーを割り当て、人によるアクセスとCIアクセスで同じ秘密鍵を共有しないようにします。
  • アクセス設定を調整 キーによるログインが使えることを確認してから、一時認証情報の利用範囲を絞ります。変更するたびに、検証済みの復旧経路を1つ残してください。
  • 復旧情報を保存 ノード番号、承認済みメンバー、キーのフィンガープリント、復旧担当者、最終検証日時を記録し、復旧資料はノード本体とは分けて保存します。
認証情報の境界

人によるアクセスと自動化を分離

開発者キーは対話的な調査に使い、ランナーキーにはパイプラインに必要な権限だけを付与します。メンバーがチームを離れたら該当する公開鍵を失効させ、全員共通の認証情報を交換する方法は避けてください。

個別フィンガープリントで追跡可能
復旧検証

変更前に復旧経路を確認

ネットワーク、SSH、グラフィカルセッションの設定を変更する前に、現在利用できるセッションを保持し、コンソールの復旧情報を2人目の担当者が確認済みであることを確かめます。

接続トラブルシューティングを見る
初回SSH接続

まずフィンガープリント、次にシステム状態を検証

ホストフィンガープリントの確認を省略しないでください。アドレスとポートはコンソールから取得し、信頼できるフィンガープリントをチームで確認済みの引き渡し記録と照合します。

ノード接続記録 実行待ち
# コンソールのアドレスを取得してから変数を設定
export NODE_HOST="ノードアドレス"
export NODE_PORT="22"

# 専用秘密鍵の権限を修正
chmod 600 ~/.ssh/orbvps_node

# ホストフィンガープリントを読み取り、表示後に引き渡し記録と照合
ssh-keyscan -p "$NODE_PORT" "$NODE_HOST" \
  | ssh-keygen -lf -

# 初回接続を開始
ssh -p "$NODE_PORT" \
  -i ~/.ssh/orbvps_node \
  nodeadmin@"$NODE_HOST"

# ログイン後にハードウェア、システム、ディスクの状態を確認
$ uname -m
arm64
$ sw_vers
$ sysctl -n machdep.cpu.brand_string
$ df -h /
$ uptime
SSH ACCEPTANCE 4 CHECKS
  1. フィンガープリント一致 スキャン結果が信頼できる引き渡し記録と一致する必要があります。一致しない場合は接続を停止し、コンソールのチケットで確認してください。
  2. キーの権限が正しい 秘密鍵の権限が広すぎると、SSHは読み込みを拒否します。現在のユーザーだけが読み書きできる権限に修正してください。
  3. アーキテクチャはarm64 ログイン後にプロセッサのアーキテクチャとチップ情報を確認し、誤ったホストでツールチェーンの導入を続けないようにします。
  4. ディスクと稼働時間を確認可能 ルートボリュームの空き容量、システムバージョン、稼働時間を記録し、後続のビルド障害調査の初期状態とします。
グラフィカルデスクトップの初期設定

VNCセッションを再現可能な作業環境に整える

グラフィカルデスクトップは、表示、システム環境設定、Xcode初回の対話設定に適しています。公開ページには接続認証情報を掲載せず、具体的なアドレスとアクセス情報は開通後に確認します。

DESKTOP BASELINE グラフィカルセッション受け入れチェック

各設定の完了後に一度ログアウトして再接続し、新しいセッションでも設定が有効であることを確認します。

01

表示と解像度

現在のネットワークと画面に適した解像度を選びます。文字が小さすぎる、または画面遅延が目立つ場合は、まず解像度を下げてからネットワーク経路を評価してください。

02

システム言語とタイムゾーン

チームで定めたシステム言語、地域形式、タイムゾーンを統一し、ビルドログ、日付出力、自動化スクリプトの一貫性を保ちます。

03

ロック画面ポリシー

ロック画面によって継続実行が必要なジョブが中断されないことを確認しつつ、未承認アクセスを制限します。対話セッションとCIジョブは分けて検証してください。

04

切断と再接続

グラフィカルセッションを一度意図的に切断し、再接続後にデスクトップ状態、解像度、実行中プロセスが想定どおりであることを確認します。

移行パス

ローカルMacから安定したクラウドビルドノードへ移行

移行は3段階で進めます。検証可能なデータを移し、ツールチェーンを固定し、最後にCIへ接続します。リポジトリ、依存関係、自動化設定を確認なしに一括コピーしないでください。

LOCAL
01

データとリポジトリを移行

必要なリポジトリ、依存関係ロックファイル、ビルドスクリプト、テストデータだけを移行します。一時キャッシュ、古い成果物、所有者不明のファイルを除外し、移行後にリポジトリ状態と重要ファイルのダイジェストを検証します。

  • デフォルトブランチとリモートアドレスを確認
  • サブモジュールと大容量ファイルの依存関係を確認
  • テストデータを匿名化
TOOLCHAIN
02

ツールチェーンを導入して固定

リポジトリの要件に従ってXcode、コマンドラインツール、依存関係管理ツールを導入します。実際のバージョン出力をベースライン記録に保存し、「最新版」で明確なバージョン番号を代用しないでください。

  • XcodeとSDKのバージョンを記録
  • ロックファイルから依存関係を復元
  • シェルとランタイムのパスを固定
CLOUD MAC
03

CIに接続してロールバックを検証

self-hosted runnerを登録したら、まず管理下のテストジョブを実行します。失敗ログ、キャッシュ削除、復旧手順が実行可能であることを確認してから、本番ブランチを段階的に接続します。

  • 専用ラベルでジョブ範囲を制限
  • キャッシュヒットと削除を検証
  • ランナーの停止とロールバックを訓練

移行完了基準:同じコミットを、記録済みのツールチェーンを使ってローカルMacとクラウドMacでビルドし、主要テスト結果が一致し、ドキュメントに従って再デプロイできること。

初回ビルド

再確認できる成功ベースラインを作成

初回ビルドの目的は最短時間ではなく、ツールチェーン、依存関係、権限、出力先がすべて再現可能であることを証明することです。

  1. 01

    Xcodeのパスとバージョンを確認

    選択中のDeveloperディレクトリ、Xcodeバージョン、利用可能なSDKがプロジェクト要件と一致することを確認します。

  2. 02

    ライセンスを承認して依存関係を導入

    Xcodeのライセンスを承認した後、ロックファイルに厳密に従ってRuby、Node、CocoaPodsなどのプロジェクト依存関係を導入します。

  3. 03

    管理下のビルドを実行

    workspace、scheme、configurationを明示し、完全な標準出力を独立したログファイルに保存します。

  4. 04

    ベースライン記録を保存

    コミット番号、ツールチェーンのバージョン、開始・終了時刻、終了コード、成果物の場所を記録し、後続の変更比較に使用します。

初回ビルドベースライン コマンド例
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode <プロジェクト要件のバージョン>

$ sudo xcodebuild -license accept
$ bundle install
$ bundle exec pod install

$ mkdir -p build-logs
$ set -o pipefail
$ xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  clean build \
  | tee build-logs/first-success.log

** BUILD SUCCEEDED **
CI接続

ランナーが実行すべきジョブだけを受け取るようにする

self-hosted runnerの接続後は、専用ラベルとテストブランチで範囲を制限し、段階的に本番ビルドを開放します。

RUNNER PROFILE

ランナーID

名前
orb-m4-ci-01
ラベル
macos · arm64 · xcode
作業ディレクトリ
/Users/runner/work
並行実行ポリシー
単一ジョブから検証を開始
ACCESS POLICY

権限とキー

  • 専用ランナーユーザー 自動化ジョブで管理者の対話アカウントを長期利用しないでください。
  • 用途別にキーを分割 リポジトリの読み取り、成果物の書き込み、デプロイ操作には、それぞれ必要最小限の権限だけを付与します。
  • 機密値をリポジトリに書き込まない 管理されたCI変数から注入し、ログに完全な値が表示されないことを確認します。
CACHE CONTROL

キャッシュと復旧

  • キャッシュキーにバージョンを含める ロックファイルのダイジェスト、アーキテクチャ、ツールチェーンのバージョンをキャッシュキーに含めます。
  • クリーンビルドを可能にする 各パイプラインは、キャッシュを削除した後でも完全なビルドを1回完了できる必要があります。
  • 作業ディレクトリの増大を制限 DerivedData、アーカイブ、一時成果物の使用量を定期的に確認します。
CONTROLLED TEST JOB

予測可能なテストジョブを先に実行

ジョブでは環境情報の出力、依存関係の復元、ユニットテスト、リリースを伴わないビルドを1回だけ実行します。ラベルのルーティング、ログの完全性、キャッシュ削除、失敗時の停止を確認してから本番ブランチに接続してください。

期待終了コード
0 / 成功
必ず保存
ログ、コミット番号、成果物のダイジェスト
失敗時の対応
本番ジョブを停止し、ベースライン確認に戻る
稼働前チェック

6項目の状態をすべて明確にしてから本番ビルドを実行

以下のチェック結果をチームの運用マニュアルに記載します。ノードは365日稼働できますが、ビルドフローには明確なデータ、監視、対応責任が必要です。

バックアップ

リポジトリ、ビルド設定、キーの復旧情報、必要な成果物のコピーをノード外に保存し、復旧検証を1回完了しています。

復旧を検証済み

監視

少なくともディスク空き容量、ビルド終了コード、ジョブ待機時間、ランナーのオンライン状態を記録し、異常しきい値を定義します。

指標の担当者を設定済み

連絡先

主担当者と代替担当者の両方がノード記録、ビルドログ、コンソールチケットにアクセスでき、引き継ぎ経路も明記されています。

主・副連絡先を登録済み

更新時期

注文期間と社内確認時期を登録し、1人のメンバーの記憶に依存しないようにします。設定変更前に、現在のジョブへの影響を評価してください。

期間を登録済み

アクセスの失効

ユーザーキー、ランナーキー、対応する権限を一覧化し、他のメンバーに影響を与えず個別に失効できる状態にします。

項目ごとに1件の記録

障害時の連絡経路

ノード番号、発生時刻、再現手順、匿名化済みログをいつでも整理でき、承認済みメンバーがコンソールからチケットを送信できます。

資料をそのまま提出可能
デプロイの準備

検証可能なクラウドMacから始める

モデル、リージョン、期間を選び、開通後に本ガイドに沿って安全な接続、初回ビルド、CI受け入れを完了します。