コマンド操作にはSSH、画面操作にはリモートデスクトップ、自動ビルドにはCI runnerを使います。3つの接続先は同じ専有物理ノードです。
ご利用中の方は、コンソールで注文に対応するインスタンスの詳細を開き、ホストアドレス、SSHポート、ユーザー名、提供条件を確認してください。この記事のホスト変数は、すべて実際のインスタンスの値に置き換えてください。
まずSSH接続を確認してから、デスクトップとパイプラインを設定しましょう。SSHならノードへの到達性や認証の問題もすばやく確認できます。
自分のPCで実行し、クラウドノードでは実行しないでください。鍵にパスフレーズを設定します。専用鍵がすでにある場合は再利用できますが、使用中のファイルを上書きしないでください。秘密鍵は常にローカルに保管し、ノードに登録するのは末尾が .pub の公開鍵だけです。
ssh-keygen -t ed25519 -f ~/.ssh/xcnode_ed25519 -C "xcnode-workstation"
ssh-add ~/.ssh/xcnode_ed25519もし ssh-add で認証エージェントに接続できないと表示されたら、ローカルのSSH agentが起動しているか確認してください。鍵のパスフレーズとリモートユーザーのパスワードは別のものです。
インスタンスの案内に従って3つの変数を設定してください。初回のパスワード認証が案内で許可されている場合に限り、 ssh-copy-idを使います。公開鍵を登録済みなら、そのままログインを試してください。初回接続ではホストフィンガープリントを確認し、確認プロンプトが表示されたという理由だけで未知のホストを受け入れないでください。
read -r -p "Host: " NODE_HOST
read -r -p "SSH port: " NODE_PORT
read -r -p "User: " NODE_USER
ssh-copy-id -i ~/.ssh/xcnode_ed25519.pub -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
ssh -i ~/.ssh/xcnode_ed25519 -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"以下の変数入力コマンドはBash用です。macOSのzshでは、まず bash を実行してから続けてください。初回の公開鍵登録がうまくいかない場合は、コンソールに表示された認証情報の管理手順を使うか、サポートチケットを送信してください。パスワードを何度も試さないでください。
ローカルの ~/.ssh/config に別名を設定します。以下の山括弧で囲まれた項目はインスタンスの値に置き換え、山括弧は残さないでください。Windows OpenSSHもユーザーディレクトリ内の .ssh/configを読み込みます。
Host xcnode-work
HostName <INSTANCE_HOST>
Port <SSH_PORT>
User <INSTANCE_USER>
IdentityFile ~/.ssh/xcnode_ed25519
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3ssh xcnode-work
uname -m
sysctl -n machdep.cpu.brand_string
xcode-select -p
xcodebuild -versionuname -m の実行結果は arm64です。チップ名が注文したモデルと一致するか確認してください。Xcodeのバージョンはノードに実際にインストールされているものを確認します。接続維持の設定だけではタスクは自動で再開されません。長時間のビルドにはrunnerや永続セッション管理ツールを使ってください。
まずローカルで ssh -Vを実行できるか確認してください。補助コマンドがなくても、ノードがSSHに対応していないとは限りません。
| ローカルOS | SSHクライアント | 公開鍵の登録 | 注意点 |
|---|---|---|---|
| macOS | ターミナルにOpenSSHが標準搭載 | ssh-copy-id 通常は別途インストールが必要です。提供時の案内に従って公開鍵を登録することもできます。 | デフォルトのシェルはzshの場合が多いため、Bash専用の入力構文をそのまま使わないでください。 |
| Windows | PowerShellでOpenSSH Clientを使用 | WSLで ssh-copy-idを使うか、コンソールで公開鍵を登録できます。 | PowerShellとWSLでは、ユーザーディレクトリも鍵ファイルも別々です。 |
| Linux | ディストリビューションのOpenSSHクライアントパッケージ | 通常は ssh-copy-idが含まれています。ない場合は、クライアントツールをインストールしてください。 | 秘密鍵の権限は 600、~/.ssh ディレクトリの権限は 700に設定します。 |
SSH接続を確認したら、画面共有サービスとグラフィカルセッションを確認します。ポートに接続できるだけで、デスクトップを使えるとは限りません。
ローカルのMacでは、標準搭載の「画面共有」アプリを使えます。VNCの一般的なサービス用ポートはTCP 5900ですが、実際のポート、認証方式、有効化の状況はインスタンスの提供案内で確認してください。
リモート側が5900を使用していることを確認したら、ローカルのターミナルでトンネルを作成し、そのターミナルを開いたままにします。ここではローカルポートに15900を使い、PC上のサービスとの競合を避けます。
ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 \
-o ExitOnForwardFailure=yes xcnode-work別のターミナルでクライアントを開きます。
open "vnc://127.0.0.1:15900"インスタンスの認証方式に対応したVNCクライアント（TigerVNCなど）を選んでください。同じ方法でSSHトンネルを作成し、クライアントの接続先に 127.0.0.1、ポートに 15900を入力します。
ポートの指定方法はクライアントによって異なります。ポート欄が独立しているものもあれば、完全なポート番号をダブルコロンで指定するものもあります。クライアントの説明に従い、ポートをディスプレイ番号と取り違えないでください。
macOSの画面共有は、汎用VNCクライアントと常に互換性があるわけではありません。認証に失敗した場合は、クライアントの対応状況と提供案内を確認してください。クライアントに合わせるために、ノードのアクセス保護を安易に弱めないでください。
初回接続では自動または低画質を選び、ディスプレイは1台だけ使ってください。大容量ファイルの転送や全画面の動画再生も同時に行わないようにします。文字が読みやすく、クリック操作が安定したら、解像度や色品質を少しずつ上げてください。SSHでファイルを速く転送できても、デスクトップの応答が速いとは限りません。
画面が真っ黒な場合は、トンネルが動作中か、接続先ポートが正しいか、画面共有が有効か、リモート側に利用可能なグラフィカルセッションがあるかを順に確認してください。セッションが競合する場合は、チーム内で利用時間を調整し、ビルド中のユーザーを強制ログアウトしないでください。
runnerはローカルPCではなく、クラウドMac上でタスクを実行します。まず対話形式のタスクでツールチェーンを確認し、その後サービスとして起動します。
プロジェクトまたは組織のrunner設定を開き、macOS ARM64を選択します。設定画面に表示される最新のダウンロード・検証コマンドでプログラムを準備してください。登録URLと短期トークンも同じ画面から取得します。
cd ~/actions-runner
read -r -p "Registration URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh --url "$RUNNER_URL" --token "$RUNNER_TOKEN" \
--name xcnode-work --labels xcnode,arm64
unset RUNNER_TOKEN
./run.sh以下の入力コマンドはBashで実行します。テストタスクを実行してrunnerがオンラインになり、ビルドが完了することを確認したら、フォアグラウンドのプロセスを停止してサービスをインストールします。
./svc.sh install
./svc.sh start
./svc.sh status別のアーキテクチャのマシンに割り当てられないよう、ワークフローでは明示的なラベルを指定します。
runs-on: [self-hosted, macOS, ARM64, xcnode]
steps:
- run: xcodebuild -version登録トークンは長期利用するプロジェクトシークレットではありません。リポジトリ、ビルド出力、サポートチケットの添付ファイルに記載しないでください。
プロジェクトまたはグループでrunnerを作成し、現在のプラットフォームの案内に従ってrunner認証トークンを取得します。macOS ARM64版をインストールしたら、実行ユーザーのグラフィカルセッション内のターミナルで登録してください。rootとしてプロジェクトのビルドを実行しないでください。
gitlab-runner registerインスタンスURLと認証トークンを入力し、 shell executorを選択します。runnerには xcnode と arm64 のタグを設定し、信頼できるプロジェクトのみに制限してください。
gitlab-runner install
gitlab-runner start
gitlab-runner statusまず最小限のテストタスクで環境を確認し、その後に署名やアーカイブの処理を追加します。
build-check:
tags: [xcnode, arm64]
script:
- uname -m
- xcode-select -p
- xcodebuild -versionShell executorからは実行ユーザーのファイルにアクセスできます。専有マシンでも、同じアカウントで実行される信頼できないタスクが自動的に隔離されるわけではありません。
macOSのユーザー単位のサービスは通常launchdで管理され、ユーザーセッションに依存する場合があります。サービスのインストール後は、プロセス、ログ、キューの状態を確認してください。チームで合意した時間に、再起動後の復旧もテストします。シミュレータや画面操作が必要なタスクでは、ログインセッションが要件を満たすかも確認してください。runnerがオンラインと表示されるだけでは不十分です。
まずは単一タスクから始め、プロジェクトの実際のピークメモリを記録してから並列数を増やします。キャッシュはプロジェクトとXcodeのバージョンごとに分け、ビルド成果物は別途アーカイブしてください。システムキーチェーンの署名情報を使う場合は、サービスユーザーのアクセス権も個別に確認します。ターミナルでビルドが成功しても、バックグラウンドビルドも成功するとは限りません。
シンガポール、東京、ソウル、香港では、それぞれ2種類のモデルを提供しています。在庫状況はコンソールでご確認ください。地理的な距離だけでなく、通信事業者の経路やチームの稼働時間も選定のポイントです。
東南アジアのチームは、まずシンガポールを候補にご検討ください。普段のオフィスネットワークでデスクトップ操作を試し、プロジェクトの取得と成果物のアップロード経路も確認しましょう。
日本や東アジアのチームは、まず東京を候補にご検討ください。時差が近くてもネットワークが速いとは限りません。混雑時と通常時の接続状況を比べてください。
韓国や北東アジアのチームは、まずソウルを候補にご検討ください。常時稼働するrunnerでは、コードリポジトリや依存関係の取得元への接続が安定しているかも重要です。
中国南部や東南アジアのチームは、まず香港を候補にご検討ください。異なるタイムゾーンのメンバーでデスクトップを共有する場合は、グラフィカルセッションの利用時間と終了時間を事前に決めておきましょう。
割り当て済みインスタンスの実際のホストアドレスを使ってテストしてください。ウェブサイトのドメインを測定して、ノードの測定結果の代わりにしないでください。以下のコマンドは、ノードの変数を設定したローカルのBashターミナルで実行します。
ping -c 20 "$NODE_HOST"
ssh -p "$NODE_PORT" "$NODE_USER@$NODE_HOST" 'uptime'Windows PowerShellでは ping -n 20 <INSTANCE_HOST>を使います。パケット損失と往復時間の範囲を記録し、実際にGitで取得するか、ビルド成果物を転送してみてください。ネットワークポリシーによってICMPが遮断されることがあります。pingに応答がなくても、実際のSSHポートは別途テストしてください。
チームが普段使うネットワークと時間帯で、テストを繰り返してください。この記事では一律の遅延時間を保証していません。結果は、その時点でのネットワーク経路の状況を示すものです。まだ契約していない場合は、テスト方法をサポート窓口にお問い合わせください。推測したノードアドレスは使用しないでください。
リソースの境界、接続プロトコル、タスクのスケジューリングを区別すると、問題の切り分けがスムーズになります。
唯一の接続をまだ検証できていない状態で、認証設定を変更しないでください。現在のセッションを維持し、別のターミナルから新しい鍵でログインできることを確認してから、ノードの設定を変更します。
現在のmacOSバージョンに対応するsshd設定と、読み込まれるファイルを確認してください。公開鍵認証を有効にし、パスワード認証とキーボードインタラクティブ認証を無効にします。ほかのファイルで上書きされる可能性がある項目を1つ変更するだけで済ませないでください。
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no設定を反映する前に、 sudo /usr/sbin/sshd -t で構文を確認し、インスタンスの案内に従って反映してください。
SSHは案内されたポートで接続します。リモートデスクトップにはローカルトンネルを使い、5900を公共ネットワークに直接公開しないでください。一時的なテストサービスは使用後に停止し、待ち受けアドレスとファイアウォールルールも確認してください。
lsof -nP -iTCP -sTCP:LISTENrunnerは通常、CIサービスに向けて接続します。そのため、管理用の受信ポートを追加で開放する必要はありません。
メンバーごとに公開鍵を分け、メンバーが離れたら該当する権限を削除してください。runnerが受け付けるのは信頼できるリポジトリのタスクに限定し、プロジェクトのシークレットはCIプラットフォームの保護変数で管理します。スクリプトやプロジェクトファイルには記載しないでください。
ホストフィンガープリントが変わった場合は、インスタンスが再インストールされたかを先に確認してください。ローカルの記録を削除して、そのまま接続を続けないでください。
サポートチケットには、機密情報を除いたログ、注文番号、失敗した手順のみを添付してください。秘密鍵、パスワード、登録トークンは送信しないでください。
モデルと契約期間を選び、インスタンスの認証情報を取得してください。まずSSH接続を確認し、リモートデスクトップとビルドキューを順に接続します。利用中のインスタンスで問題が起きた場合は、コンソールから機密情報を除いた調査記録を送信できます。