アドレスには到達するがセッションに入れない
まずノードのアドレス、ポート、ユーザー名、認証情報を確認し、次にローカルネットワークの制限、クライアントの暗号化設定、セッション状態を確認します。古い認証情報を繰り返し試さないでください。
接続チェックの手順を開くここでは、専用物理Macノードの接続、Xcodeビルド、CI/CD runner、ストレージ、ノードネットワーク、請求を扱います。まず基本確認を順番に行い、解決しない場合は注文、環境、マスキング済みログをまとめて送信し、確認の往復を減らします。
ネットワーク、システムバージョン、ビルド設定を同時に変更しないでください。一度に1つの変数だけを変え、元のエラー文と発生時刻を残すことで、接続、環境、プロジェクトのどの層の問題か判断できます。
まずノードのアドレス、ポート、ユーザー名、認証情報を確認し、次にローカルネットワークの制限、クライアントの暗号化設定、セッション状態を確認します。古い認証情報を繰り返し試さないでください。
接続チェックの手順を開く失敗した段階を記録し、ディスク容量、XcodeとSDKのバージョン、依存関係のロックファイル、署名素材、完全なビルドログを確認します。最初に発生した実際のエラーを優先して残してください。
ビルド診断の手順を見るrunnerのサービスプロセス、登録状態、ラベルの一致、作業ディレクトリの権限、同時実行数の上限を確認します。プラットフォーム上でオンラインでも、現在のジョブのラベルに必ず一致するとは限りません。
runner設定を確認するソースコード、依存関係キャッシュ、DerivedData、アーカイブ、納品成果物の使用量を分けて確認します。必要なファイルを先に書き出し、ディレクトリ単位で整理してください。用途を確認できないデータを直接削除しないでください。
ストレージに関するよくある質問を見る現在のノード、リポジトリのホスティングリージョン、主な作業者の所在地、大容量ファイルの転送方向を記録してから移行を検討します。移行前にコードとビルド成果物の独立したコピーを必ず用意してください。
ノードとネットワークを比較する注文番号、選択した構成、請求期間、支払い方法、コンソール上の表示状態を準備します。送信するのは取引IDだけにし、カード情報全体や秘密鍵は送らないでください。
コンソールから請求の問い合わせを送る初めてノードに入ったら、まず接続とセキュリティを確認し、その後で開発環境を設定します。これにより、システムの問題とプロジェクト依存関係の問題を分けて、後から再現しやすくなります。
注文に対応するノード、サーバーアドレス、ポート、ユーザー名、仮の認証情報を確認します。接続情報は現在の承認済みメンバーだけが使用し、チャット履歴や公開ドキュメントで転送しないでください。
完了条件:安定してセッションを確立し、注文に対応するノードに接続していることを確認できる。初回アクセス後に仮の認証情報を更新し、チームの権限ポリシーに沿ったシステムアカウントを作成します。管理者操作は、ツールのインストールやサービスの調整が必要なメンバーだけに許可してください。
完了条件:仮の認証情報を使わず、日常用アカウントと管理用アカウントの用途を分けている。macOSのバージョン、チップ、空きディスク容量、Xcodeのバージョン、コマンドラインツールのパス、ターゲットSDKを記録します。チーム独自のビルド・運用手順書にこれらの情報を記載してください。
完了条件:同じバージョン情報で、ローカルとクラウドのビルド差異を説明できる。プロジェクトのロックファイルに従って依存関係をインストールし、専用のキャッシュディレクトリを設定してからself-hosted runnerを登録します。初回ジョブは同時実行数を低く設定し、署名、アーカイブ、アップロードの経路を検証してください。
完了条件:最小構成のビルドジョブを繰り返し実行でき、完全なログが残る。まず確実にビルドできるコミットを1つ取得し、依存関係のインストール、コンパイル、アーカイブだけを実行します。成功を確認してから、並列ジョブ、キャッシュの復元、デリバリー手順を追加してください。
接続前の準備を確認するビルドの問題は通常、容量、署名、バージョン、依存関係、ログ、同時実行の6層に分かれます。各層の確認後に同じコミットを再実行し、結果が変わったかを記録してください。
システムボリュームの空き容量、DerivedData、依存関係キャッシュ、アーカイブディレクトリ、エクスポート成果物を分けて確認します。容量不足の場合は必要な成果物を先に保存し、ディレクトリ単位で整理してください。
プロジェクトで選択したチーム、証明書の有効状態、プロビジョニングプロファイルの対象、Bundle Identifierが一致していることを確認します。ログや問い合わせに署名用秘密鍵を添付しないでください。
実際にビルドを実行したXcodeのパスを記録し、コマンドラインツールが別のバージョンを指していないこと、プロジェクトが必要とするターゲットSDKが存在することを確認します。
ロックファイルと照合して、キャッシュが古くなっていないか確認します。まずキャッシュを復元しないクリーンビルドを試し、成功したら依存関係キャッシュを1つずつ戻して不一致の原因を特定します。
実行コマンド、終了コード、最初に発生した実際のエラーを保存します。最後の画面だけでは前段の失敗を見落としやすいため、ジョブ開始から終了までのマスキング済みログを添付してください。
同時実行数を1ジョブまで下げて再現し、メモリ、ディスク、ネットワークの使用量を確認します。単独では成功して並列実行で失敗する場合は、同時実行数を段階的に増やして安定する上限を探します。
6層すべてを確認しても特定できない場合は、失敗したコミットの識別子、実行コマンド、環境バージョン、終了コード、マスキング済みログを送信してください。
ビルド問題の問い合わせを送る専用物理ノードはself-hosted runnerに適していますが、安定運用には明確な登録ポリシー、ラベル、サービス管理、キャッシュ範囲、権限制御が必要です。
各ノードに一意のrunner名を付け、所属リポジトリまたは組織、登録範囲、作業ディレクトリ、サービスアカウントを記録します。ノードを移行する際は、先に古い登録を取り消してください。
ラベルには、チップアーキテクチャ、Xcodeのメジャーバージョン、ノードリージョン、用途など、安定した事実を表します。一時的なプロジェクト名を、管理しにくいラベルの組み合わせにしないでください。
runnerを管理対象サービスとして実行し、起動方法とログの場所を記録します。システム再起動後にサービスが自動復旧することを確認し、最小ジョブを1つテストしてください。
依存関係、DerivedData、アーカイブを別々のディレクトリで管理し、削除のしきい値を設定します。キャッシュは高速化のためのものであり、プロジェクトの唯一のコピーや長期保管用リポジトリにしないでください。
日常のビルドアカウントには、ジョブに必要なディレクトリとコマンドの権限だけを付与します。ツールのインストール、システム設定の変更、サービス管理時のみ管理者権限を使用してください。
サービスプロセス → 登録の有効性 → ラベルの一致 → 作業ディレクトリの権限 → 外部接続 → プラットフォームのジョブキュー。
問い合わせで用語を統一すると、物理ノード、リモートセッション、runner、ビルドキャッシュを同じ障害対象として混同せずに済みます。
VMArmでは、シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部の5つのノードリージョンを提供しています。リモート操作、リポジトリ取得、依存関係のダウンロード、成果物のアップロード方向を総合的に比較してください。
東南アジアのチームや、主要サービスが東南アジアにあるリポジトリ・デリバリーチェーンに適しています。
日本および東アジアのチームに適しており、リモートデスクトップ操作とリージョン内のビルドリソースへのアクセスを両立できます。
韓国および北東アジア方面の開発メンバー、依存関係ミラー、デリバリーフローに適しています。
華南および東南アジアの協業チームに適しています。選択前に、リポジトリとリモートセッションの経路を同時にテストしてください。
北米西海岸のチームや、主要リポジトリ、依存関係ソース、デリバリーシステムが北米にあるプロジェクトに適しています。
| 確認対象 | 測定方法 | 記録する内容 | 判断のポイント |
|---|---|---|---|
| リモートセッション | 業務時間帯とオフピーク時間帯に接続と操作性をそれぞれテストする | ローカルネットワーク、ノード、クライアントバージョン、発生時刻 | 継続的な異常か、特定時間帯の変動か |
| コードリポジトリ | 同じリポジトリと同じコミットで、クローン、取得、サブモジュールをテストする | リポジトリのリージョン、所要時間、失敗コマンド、終了コード | 接続確立が遅いのか、大容量ファイルの転送が遅いのか |
| 依存関係のダウンロード | キャッシュを無効にして依存関係の完全な解決を1回実行する | 依存関係ソース、パッケージマネージャーのバージョン、失敗したパッケージ、再試行回数 | 特定の依存関係ソースだけの異常か、帯域幅全体の異常か |
| 成果物のアップロード | 同じサイズのマスキング済みテストファイルで転送を比較する | ファイルサイズ、対象リージョン、開始・終了時刻 | 上り回線、対象サービス、ファイルサイズの影響 |
問い合わせの目的は問題の存在を証明することではなく、同じ注文、同じノード、同じ時刻、同じ失敗手順を特定できるようにすることです。
対応する構成、請求期間、納品記録を確認するために使用します。
シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部のいずれかを明記します。
タイムゾーンを含む時刻を示し、問題が再現するかどうかも説明します。
メジャーバージョン名だけでなく、macOSの完全なバージョンを記載します。
実際にコマンドラインツールが指しているバージョンとパスも記載します。
正常な状態から開始し、実際のクリックまたはコマンドの順序に沿って段階的に説明します。
エラーのコンテキストと終了コードを残し、トークン、秘密鍵、その他の機密情報を削除します。
ログイン後に対象の注文を選択して問題を送信します。注文とノードのコンテキストがそろうため、接続、ビルド、移行、請求の問題に適しています。
コンソールへ移動まだ注文していない場合は、用途、希望構成、同時ビルド数、希望リージョン、利用開始予定時期をお知らせください。
お問い合わせ方法を見る送信前にアクセストークン、署名用秘密鍵、支払い情報全体などの機密情報を削除してください。データの取り扱いを確認する場合は、プライバシーポリシーをお読みください。
対応順序は影響範囲と再現性によって決まります。サポートではノードの納品、接続、環境、注文の問題を扱います。プロジェクトのビジネスロジックはプロジェクト管理者が確認してください。
接続不能、ビルド全体の停止、一部ジョブの異常、一般的な相談のいずれかで影響範囲を判断し、実行可能な代替経路があるか確認します。
注文番号、ノード、時刻、環境、ログを受け取ったことを確認します。必要情報が不足している場合は、補足が必要な項目を明示します。
現在確認している層、除外済みの項目、次の検証手順、ユーザーに実行してもらうテストを説明し、情報が増えない手順の繰り返しを避けます。
問題が復旧し、根本原因と回避方法を説明できた場合、またはプロジェクト設定の問題と確認し実行可能な確認方法を提示した場合、問い合わせは完了手続きに進みます。
VMArm M4 CoreまたはVMArm M4 Plusを選び、シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部からノードを選択してください。実際の利用可能状況はコンソールのリアルタイム表示に従います。