macOSの画面共有で接続
ローカルのmacOSで「画面共有」を開き、案内されたデスクトップのアドレスとポートを入力します。Finderの「移動」→「サーバへ接続」から、案内されたVNCアドレスを入力する方法もあります。
デスクトップ用の認証情報は、SSH用と異なる場合があります。コンソールに表示された該当項目を使い、SSH秘密鍵をVNCパスワードとして使わないでください。
SSH・VNCの認証情報は納品時にご案内します。コマンドラインでビルドし、リモートデスクトップで署名を確認。専用の物理Macを1台まるごと利用できます。仮想マシンではありません。
すでにノードをお持ちですか?まずアドレス、SSHポート、ユーザー名、デスクトップへの接続方法を控えてから、以下の手順に進んでください。
ローカル環境でキーを生成し、公開鍵をクラウド上のユーザーに登録して、ノードに固定の別名を設定します。以降のrsync、Fastlane、Runnerも同じ接続を使えます。
次の 192.0.2.10 はドキュメント用の例示アドレス、macbuild は例示ユーザー名、22 は例示用のSSHポートです。すべてコンソールで案内された値に置き換えてください。秘密鍵、パスワード、接続情報一式をチケットに貼り付けないでください。
ローカル環境で実行します。専用のファイル名を使えば、既存のデフォルトキーを上書きせずに認証を取り消せます。対話形式のプロンプトでパスフレーズを設定してください。自動化環境には、管理されたシークレット管理手段でアクセス権を付与し、秘密鍵をリポジトリに保存しないでください。
ssh-keygen -t ed25519 -f ~/.ssh/xcr_build -C "xcr-build"
ssh-add ~/.ssh/xcr_build
ls -l ~/.ssh/xcr_build.pub
ファイル名の末尾が .pub なら公開鍵で、ノードに登録できます。拡張子のないファイルは秘密鍵です。ローカル環境またはアクセス管理されたCIのシークレットストアに保管してください。
ローカル環境に ssh-copy-id がインストールされている場合は、案内されたユーザー名とポートを指定して公開鍵を登録します。初回接続時にはホストフィンガープリントが表示されます。案内された情報と照合してください。信頼できるフィンガープリントがない場合は、コンソールのチケットで確認し、検証を省略しないでください。
ssh-copy-id -i ~/.ssh/xcr_build.pub -p 22 macbuild@192.0.2.10
ssh -i ~/.ssh/xcr_build -p 22 macbuild@192.0.2.10
macOSのローカル環境には、 ssh-copy-idが標準でインストールされていない場合があります。納品環境でパスワード認証が許可されていれば、次の標準SSHコマンドを使えます。鍵認証のみの場合は、納品時の手順に従って公開鍵を登録し、パスワードを繰り返し試さないでください。
cat ~/.ssh/xcr_build.pub | ssh -p 22 macbuild@192.0.2.10 \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ノードの再インストール後にホスト鍵の変更が表示された場合は、再インストール記録と新しいフィンガープリントを確認してから、ローカルの記録を更新してください。ホスト検証を無効にするオプションで異常を隠さないでください。
次の設定をローカルの ~/.ssh/configに追加します。エイリアスを使えばノードのアドレスを覚える必要はありません。アドレスが変わっても、変更するのはここだけ。スクリプトでは引き続き xcr-buildを使えます。
Host xcr-build
HostName 192.0.2.10
User macbuild
Port 22
IdentityFile ~/.ssh/xcr_build
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3
読み取り専用の確認コマンドを実行し、実際のOSバージョン、選択中のXcode、ディスク容量を確認します。環境を確認してから依存関係をインストールしたりRunnerを登録したりすれば、誤ったバージョンがパイプラインに入るのを防げます。
ssh xcr-build
sw_vers
xcode-select -p
xcodebuild -version
df -h "$HOME"
署名証明書の初期設定、Keychainのアクセス権確認、Xcodeの設定確認には、コマンドを試行錯誤するよりリモートデスクトップが便利です。確認が終わったら、安定した手順をコマンドラインに戻しましょう。
ローカルのmacOSで「画面共有」を開き、案内されたデスクトップのアドレスとポートを入力します。Finderの「移動」→「サーバへ接続」から、案内されたVNCアドレスを入力する方法もあります。
デスクトップ用の認証情報は、SSH用と異なる場合があります。コンソールに表示された該当項目を使い、SSH秘密鍵をVNCパスワードとして使わないでください。
その他のOSでは、案内された認証方式に対応するVNCクライアントを使用できます。ホスト、ポート、認証情報を入力してください。インターネット上にデスクトップサービスを直接公開しないでください。
納品時の案内でSSH経由のノード上のローカルVNCサービスへの接続が許可されている場合は、トンネルを作成できます。次の例は、リモートサービスが 127.0.0.1:5900 で待ち受けている場合に限り使用できます。実際のポートは案内された値を指定してください。
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:5901:127.0.0.1:5900 xcr-build
このターミナルを開いたまま、ローカルのVNCクライアントから 127.0.0.1:5901に接続します。ローカルポートはループバックアドレスにのみバインドされます。デスクトップの利用を終えたら、Control-Cでトンネルを閉じてください。
Xcodeが起動し、想定したバージョンが選択されていること。ビルドユーザーが署名証明書と秘密鍵にアクセスできること。プロビジョニングプロファイルのBundle Identifier、Team、エクスポート方法がプロジェクトと一致すること。証明書のパスワードをスクリーンショットに写さないでください。
データ、ツールチェーン、CI連携の順で移行します。同じソースコードのコミットで手動アーカイブを1回成功させてから、Runnerに切り替えてください。Xcode、依存関係のバージョン、署名方針を同時に変更しないでください。
ソースコードとロックファイルは専用の作業ディレクトリに置きます。まずrsyncをドライランし、転送先を確認してください。ユーザーディレクトリ全体をそのまま同期したり、証明書、秘密鍵、ローカル環境ファイルまでアップロードしたりしないでください。
DerivedDataは再生成できるキャッシュです。Xcodeのバージョン、依存関係、ソース環境に互換性がある場合に限り再利用してください。パスやモジュールキャッシュに問題があれば、まず削除してクリーンビルドします。
「 xcode-select -p 」と「 xcodebuild -version 」でバージョンを確認します。切り替える場合は、ノードに実在するXcodeのパスを指定し、プロジェクトが必要とするSDKも確認してください。
Podfile.lock、Package.resolved、Gemfile.lockを保持します。プロジェクトで固定された環境に従ってCocoaPods、SPM、Fastlaneを実行してください。証明書とプロビジョニングプロファイルは個別に読み込み、秘密鍵へのアクセス権を確認します。
GitHubまたはGitLabのプロジェクトでセルフホストRunnerの登録情報を作成し、各プラットフォームのmacOS向け手順に沿ってインストールします。登録トークンは管理された設定作業にのみ使い、リポジトリやビルドログに記載しないでください。
Runnerに用途とツールチェーンを示すラベルを付けます。例: macos、ios-build。署名タスクを実行できるのは、まず信頼できるブランチのみに制限します。初期の同時実行数を抑え、メモリ、ディスク、ジョブログを見ながら調整してください。
rsync -avzn --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/
rsync -avz --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/
1つ目のコマンドには -nが付いており、変更予定を表示するだけです。内容を確認してから2つ目を実行してください。例では --deleteを使っていないため、初回移行時にリモートのファイルを誤って削除しません。プロジェクトに別のキー保管用ディレクトリがある場合は、事前に除外ルールを追加してください。
ソースコードのコミット、Xcodeのバージョン、依存関係のロックファイル、Scheme、エクスポート設定、Runnerのラベル、成果物の保存先を記録します。キャッシュをコピーするか決める前に、クリーンビルドと増分ビルドをそれぞれ検証してください。このページのコマンド例は性能テストではなく、ビルド時間を保証するものでもありません。
問題が起きたら、接続プロトコル、実行環境、ビルドキャッシュを切り分けてください。「マシンに接続できない」だけでなく、どの段階で失敗したかを正確に伝えると、原因を特定しやすくなります。
3つのマシンタイプで、全6拠点を利用できます。リモートデスクトップを対話的に使うなら、まず主な利用者に近い拠点を候補にし、リポジトリ、依存関係のダウンロード、成果物のアップロード経路も確認してください。チームのタイムゾーンは候補を絞る参考にはなりますが、実際のネットワーク検証の代わりにはなりません。
SG · UTC+8
東南アジアの平日日中に主な作業時間があるチームに適しています。まずローカル環境からノードへのデスクトップ操作を試し、依存関係のダウンロードと成果物のアップロードも確認してください。
JP · UTC+9
日本の営業時間を中心に協業するチームに適しています。GUIでのデバッグが必要なメンバーに先に接続を確認してもらい、自動化タスクの実行時間を設定してください。
KR · UTC+9
韓国の営業時間を中心に開発するチームに適しています。社内ネットワークから案内されたポートにアクセスできるか、長時間のSSHセッションが安定するかを確認してください。
HK · UTC+8
華南地域とその周辺のチームが主に協業する時間帯に適しています。デスクトップの応答、コードの取得、キャッシュの転送をそれぞれ検証してください。1回のpingだけで判断しないでください。
US-E · UTC−5 / UTC−4
北米東部の営業時間に適しており、時差のあるチームにも候補になります。現地では夏時間が適用されるため、タスクの引き継ぎ時は時刻だけでなくタイムゾーンも明記してください。
US-W · UTC−8 / UTC−7
北米西海岸の営業時間に適しています。時差のあるチームでは、夜間のアーカイブを別地域の日中のコミット作業につなげられます。ただし、署名タスクの同時実行数は管理してください。
ノードは365日、年間を通じて稼働しています。実際の稼働状況はコンソールのリアルタイム表示をご確認ください。接続の問題を調べる際は、ノード、マシンタイプ、使用プロトコル、エラーの原文、再現手順をコンソールのチケットでお知らせください。認証情報だけを伏せ、原因の特定に役立つエラー情報は残してください。
初回接続は5分を目安に、ホストの確認、SSH接続、デスクトップの起動まで進めましょう。ネットワークと認証の設定を確認してから、ビルド環境を移行してください。パイプライン全体の検証は、プロジェクトごとに計画が必要です。
1日あたり$21.7から。お支払いはUSDT-TRC20とVisa / Mastercard / Amex(Stripe)に対応しています。米ドルで決済されます。実際に利用できる決済手段は、バックエンドの応答をご確認ください。