Oakmini クラウドMac · クイックスタート

購入から初回ビルドまで、クラウドMacのワークフローを始める

この入門ガイドは、Oakminiを初めて使う開発者とCI/CDエンジニア向けです。専用Mac mini物理ノードを選び、SSHまたはVNCで接続し、Apple Siliconのツールチェーンを復元して再現可能なビルドを実行し、self-hosted runnerを既存のパイプラインに接続します。

01 構成を選択 機種、期間、ノード、ストレージ
02 ノードに接続 SSHまたはVNC
03 ワークフローを検証 ビルド、成果物、runner
クラウドMacの開発ワークスペース
oakmini-bootstrap connected
$ uname -m
arm64
$ sw_vers -productVersion
macOS ready
$ system_profiler SPHardwareDataType
Chip: Apple M4
$ xcodebuild -version
Xcode toolchain detected
$ git --version
git ready
✓ environment baseline recorded
準備

開始前に6つの条件を確認

互換性、リージョン、期間、権限を先に明確にすると、接続後に依存関係のアーキテクチャ不一致や容量不足、パイプラインのリポジトリ権限不足に気づく事態を防げます。以下の結果はプロジェクトの移行記録に保存してください。

10~20分

Apple Silicon互換性

依存関係が arm64 バージョンを提供しているか確認します。特にバイナリツール、コンテナイメージ、ネイティブ拡張、古いスクリプトを確認してください。Intel環境のプロジェクトでは、置換または再コンパイルが必要なコンポーネントを先に洗い出します。

file ./your-binary対象アーキテクチャを確認

対象ノードのリージョン

シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部から選択します。対話操作のVNCは主な利用者に近い場所を優先し、無人ビルドはコードソース、成果物ストレージ、チームの所在地を考慮します。

ping / traceroute実際のオフィスネットワークから測定

利用期間とタスクの時間枠

日単位は短期検証、週単位は移行スプリント、月または四半期単位は継続開発や常駐runnerに適しています。準備、ビルド、確認、成果物のエクスポートまでの全体時間を見積もり、1回のタスク時間だけで判断しないでください。

day / week / month / quarter注文期間を混在させない

ストレージ容量

リポジトリ、依存キャッシュ、シミュレーターデータ、アーカイブ、エクスポート成果物を個別に見積もります。ビルドディレクトリには余裕を持たせ、依存解決やアーカイブ中の容量不足を防ぎます。長期タスクではキャッシュ削除の方針も定めます。

df -h接続後に再確認

リモート接続ツール

コマンドライン作業にはSSHクライアントと鍵を、macOSのGUIにはVNCクライアントを用意します。ローカルネットワークで接続が許可されていることを確認し、会社のファイアウォール、プロキシ、VPNが接続経路に与える影響を記録します。

ssh -Vまずローカルクライアントを確認

アカウントとプロジェクト権限

コードリポジトリの読み取り、依存関係ソースへのアクセス、CI runner登録、ビルド署名素材、成果物アップロードに必要な権限を確認します。タスク専用の認証情報を優先し、自動化には必要最小限の権限を設定します。

read / build / upload権限範囲を項目ごとに記録
開始前に基準記録を作成します。プロジェクトのアーキテクチャ要件、対象ノード、予定期間、ディスク容量、接続方法、必要権限、確認担当者を記載し、以降の各手順で参照します。
ステップ1 · 購入

負荷に合わせて機種を選び、期間とノードを決める

Oak CoreとOak Forgeはいずれも専用のMac mini物理ノードで、仮想マシンではありません。ピーク時のメモリ、同時ビルド数、ワーキングセットの大きさ、成果物の容量を基準に選び、曖昧な性能倍率だけで判断しないでください。

ポータルで構成を選ぶ
Oak Core
m4-16-256
個人開発と軽量ビルド
チップM4
メモリ16GB
ストレージ256GB SSD

単一プロジェクトのデバッグ、依存関係の検証、低並列の自動化、短期移行確認に適しています。リポジトリ、シミュレーター、アーカイブの使用量が大きい場合は、注文時にストレージを増設してください。

$19.5/日$52.5/週$97.3/月$264.7/四半期
注文項目 選択肢 選定基準 確認結果
請求期間 日、週、月、四半期 環境準備、タスク実行、確認、成果物のエクスポートをカバー 注文に表示された開始・終了範囲が計画と一致
ノード シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部 利用者、コードソース、成果物の保存先間の実ネットワーク経路 リージョン名が基準記録と一致
ストレージ増設 +1TB SSD または +2TB SSD リポジトリ、依存キャッシュ、作業ディレクトリ、アーカイブ、成果物の合計容量 クリーンアップと一時ファイル用の空きを確保
並列化オプション Thunderbolt 5並列接続(1台あたり) 計画済みのマルチノードワークフローでのみ選択 台数とトポロジーを1台ずつ確認
決済条件:対応する決済方法はUSDT-TRC20とVisa / Mastercard / Amex(Stripe)のみです。すべての注文はUSDで決済されます。利用可能なゲートウェイはポータルの表示に従います。
ステップ2 · 接続

ホストの状態を確認してSSHまたはVNCセッションを開始

ポータルで現在のホスト状態、アドレス、ポート、認証情報の説明を確認します。古い注文やローカルの履歴からパラメータを推測しないでください。コマンドライン作業にはSSH、GUIにはVNCを使用します。

SSH baseline first-session.sh
ssh -p <PORT> <USER>@<HOST>

hostname
sw_vers
uname -m
system_profiler SPHardwareDataType
df -h
systemsetup -gettimezone
date

出力を移行記録に保存します。少なくともホスト名、macOSバージョン、arm64 アーキテクチャ、チップモデル、ディスク容量、タイムゾーン、現在時刻を確認できる状態にします。

  1. 01

    ポータルの状態を確認

    ホストが接続可能な状態であることを確認します。状態が変化中の場合はポータルの更新を待ち、認証情報で連続再試行しないでください。

  2. 02

    接続パラメータをコピー

    ホストアドレス、ポート、ユーザー名、接続方式を項目ごとに確認します。鍵ファイルは管理対象のデバイスにのみ保存してください。

  3. 03

    ホストフィンガープリントを確認

    初回SSH接続時にフィンガープリントを記録します。以後、異常な変更があれば接続を停止し、コンソールのチケットで確認してください。

  4. 04

    GUIセッションを確立

    VNCでは現在のネットワークに適した解像度と画質で接続し、キーボード配列、クリップボード設定、スリープ設定を確認します。

識別情報hostname注文と一致
システムsw_vers完全なバージョンを記録
ハードウェアarm64 / M4選択した構成を確認
リソースdf -h空き容量を確認
ステップ3 · 環境

ツールチェーンを決められた順序で復元し、バージョン一覧を作成

まず再確認可能な基盤環境を作り、その後でプロジェクトの依存関係をインストールします。旧マシンのユーザーディレクトリ全体をコピーせず、アーキテクチャ差異や不要なキャッシュを減らすため、一覧、設定、ロックファイルを優先して移行します。

L1

Homebrewとコマンドライン基盤

ソフトウェア一覧を復元して診断を実行し、インストール先とシェル環境を確認します。Apple Siliconで一般的なパスがスクリプトのハードコードと一致するか、必要なら置換されているか確認します。

brew bundle check && brew doctor
L2

Gitとリポジトリ設定

コミットのユーザー情報、改行設定、認証情報の取得方法を設定します。まず読み取り専用のテストリポジトリを取得してネットワークと権限を確認し、その後に本番プロジェクトを扱います。

git config --list --show-origin
L3

言語ランタイム

ロックファイルに従ってRuby、Node.js、Pythonなどのバージョンを復元します。バージョンマネージャー、グローバルツール、プロジェクト単位のバージョンを記録し、「最新版」という表現に依存しないでください。

ruby -v; node -v; python3 --version
L4

Xcodeツールチェーン

選択中のDeveloperディレクトリ、Xcodeバージョン、SDK、コマンドラインツールを確認します。複数プロジェクトで異なるバージョンが必要な場合は、切り替え手順をパイプラインに明示的に記録します。

xcode-select -p; xcodebuild -version
L5

プロジェクトの依存関係

リポジトリのロックファイルから依存関係を復元し、完全な解決ログを保存します。依存関係のネイティブ拡張をコンパイルする場合は、出力アーキテクチャが arm64であることを確認します。

file ./path/to/native-extension
環境一覧 environment-baseline.txt
date
hostname
sw_vers
uname -m
xcode-select -p
xcodebuild -version
git --version
brew --version
brew list --versions
ruby -v
node -v
python3 --version
df -h

一覧はプロジェクトと一緒に管理

  • 「インストール完了」だけでなく、コマンドの出力を記録する。
  • 依存関係のロックファイルとパッケージマネージャーの一覧を保存する。
  • 手動設定が必要なパスと権限を記載する。
  • Xcodeバージョンの切り替えコマンドを明記する。
  • パスワード、トークン、署名素材を一覧に記載しない。
初回ビルド

最小テストプロジェクトから実行し、実際のパイプラインへ進む

初回ビルドの目的は最短時間ではなく、依存解決、署名権限、出力先、ログが再現可能であることの確認です。まず固定コミットでテストし、成功後に完全なプロジェクトへ広げます。

01

入力を固定

指定したコミットまたはタグを取得し、サブモジュール、プライベート依存関係、大容量ファイルを確認します。リポジトリのコミットハッシュを記録し、テスト中に入力が変わらないようにします。

git rev-parse HEAD
02

依存関係を解決

ロックファイルから依存関係を復元し、標準出力と標準エラーをログに書き込みます。アーキテクチャ問題が起きたら、まず該当するバイナリを特定し、環境全体を何度も削除しないでください。

command 2>&1 | tee dependency.log
03

署名権限を確認

ビルドプロセスがタスクに必要な署名素材と設定ファイルを読み取れることを確認します。自動化アカウントには対象プロジェクトとビルド手順に必要な権限だけを付与します。

security find-identity -v -p codesigning
04

出力先を指定

DerivedData、アーカイブ、テスト結果、エクスポート成果物を明確なディレクトリに置き、他のタスクと管理されていない一時パスを共有しないようにします。

mkdir -p build logs artifacts
05

完全なログを保存

ログには少なくともコミット、Xcodeバージョン、SDK、コマンド、開始時刻、終了時刻、終了コードを含めます。アップロード前に機密項目をマスキングします。

echo "$?" > logs/exit-code.txt
06

もう一度実行

同じコミットと設定で再実行し、依存関係、パス、権限が初回セッションの一時操作に依存しないことを確認します。2回の結果を説明・比較できる状態にします。

./scripts/verify-build.sh
xcodebuild \
  -project Example.xcodeproj \
  -scheme Example \
  -configuration Release \
  -derivedDataPath ./build/DerivedData \
  build 2>&1 | tee ./logs/first-build.log
成功条件

コマンドの終了コードが0で、ログから固定コミットとツールチェーンのバージョンを特定でき、出力先に想定した成果物があり、再実行が未記録の手動操作に依存しないこと。

移行ロードマップ

移行をデータ、ツールチェーン、CIの3経路に分ける

3つの経路は並行して準備できますが、固定リポジトリ、ツールチェーンのバージョン、runnerタグという共通基準に必ず合流させ、再現可能な検証タスクを実行します。

DATA

データ

説明可能なデータだけを移行し、追跡できない過去の状態は持ち込みません。

  1. リポジトリ固定コミットをクローンし、サブモジュールと大容量ファイルを確認します。
  2. キャッシュパッケージマネージャーとプロジェクトのバージョン別に分け、期限切れのキャッシュは移行しません。
  3. 作業ディレクトリソース、テンポラリ、ログ、最終成果物を分けます。
  4. 検証ポイントgit status / checksum / df -h
TOOL

ツールチェーン

一覧からツールを復元し、バージョン出力で結果を確認します。

  1. Homebrewソフトウェア一覧を復元して診断を実行します。
  2. ランタイムプロジェクトファイルに従ってRuby、Node.js、Pythonなどのバージョンをインストールします。
  3. Xcode選択パス、バージョン、SDK、ビルドスキームを確認します。
  4. 検証ポイントbrew doctor / xcodebuild -version
CI

CI接続

スケジューリングルールがこの専用物理ノードに明確に割り当てられるようにします。

  1. runnerを登録タスク専用の登録認証情報を使用し、サービスアカウントを記録します。
  2. タグを設定リージョン、アーキテクチャ、ツールチェーン、負荷タイプのタグを使用します。
  3. 検証を実行最小ビルドを実行し、マスキング済みのログとテスト成果物をアップロードします。
  4. 検証ポイントonline / matched / exit 0
MERGE GATE 3経路の合流条件
  • リポジトリのコミットが固定されている
  • 環境一覧が保存されている
  • runnerタグがタスクに一致する
  • 検証タスクの終了コードが0である
  • ログと成果物を指定ディレクトリからエクスポートできる
セキュリティの仕上げ

本番リポジトリに接続する前に認証情報と権限を絞り込む

環境が動作しても、長期利用に適しているとは限りません。初回ビルド後すぐに、初期認証情報、鍵の保管、リポジトリ範囲、スクリプト内の機密情報を確認してください。

最小権限の基準

  • 初期認証情報を変更し、古い認証情報が接続に使われていないことを確認する。
  • 個人の管理、自動ビルド、成果物アップロードには別々の認証情報を使う。
  • 秘密鍵は管理対象のデバイスまたは鍵ストレージにのみ保管し、厳格なファイル権限を設定する。
  • リポジトリへのアクセス範囲を実際のプロジェクトに限定し、無関係な組織やリポジトリの権限を付与しない。
  • 署名素材は署名を実行するプロセスとアカウントだけに公開する。
  • スクリプト、環境一覧、ログ、ビルド成果物にパスワード、秘密鍵、決済認証情報を書き込まない。
スクリプトを確認

コミット前に一般的な機密項目を検索し、シェル履歴、環境ファイル、CI設定、ログを確認します。平文の認証情報が見つかったら、先に無効化・交換してからファイル履歴を整理します。

SSH権限

秘密鍵のファイル権限を制限し、不要な公開鍵を削除します。自動接続には用途を識別できる鍵名と記録を設定します。

chmod 600 ~/.ssh/private_key
ログのマスキング

時刻、コマンド、バージョン、終了コード、エラースタックは残し、アクセストークン、秘密鍵の内容、署名素材の原文、その他認証に直接使える情報は削除します。

受け入れチェックリスト

7項目の結果で日常タスクへの投入可否を判断

受け入れ確認は「今のセッションで使えるか」ではなく、再現可能な結果に基づいて行います。セッションを切断して再接続し、クリーンなシェルから重要コマンドをもう一度実行してください。

7項目すべて合格
  1. 01

    リモート再接続

    SSHとVNCを明示的に切断し、保存済みの正しいパラメータで再接続します。ホストフィンガープリント、ユーザー名、ポート、GUIセッションが記録と一致することを確認します。

    再現可能
  2. 02

    依存関係のインストール

    ロックファイルから依存関係を復元し、コマンドの終了コードが0であること、ネイティブコンポーネントのアーキテクチャが正しいこと、インストールログが保存され機密情報を含まないことを確認します。

    追跡可能
  3. 03

    プロジェクトビルド

    固定コミットとツールチェーンのバージョンでビルドを完了し、出力先を明確にします。2回目の実行が未記録の手動操作に依存しないことを確認します。

    終了コード0
  4. 04

    成果物のエクスポート

    アーカイブ、テスト結果、その他の対象成果物を指定ディレクトリからエクスポートでき、ファイル名、バージョン、検証方法がチームの取り決めを満たすことを確認します。

    納品可能
  5. 05

    Runnerオンライン

    self-hosted runnerがオンラインで、タグが対象タスクに一致し、未承認プロジェクトのジョブを受け取らないことを確認します。

    タグ一致
  6. 06

    ログの保存

    環境基準、依存関係ログ、ビルドログ、終了コード、成果物パスをすべて保存し、機密項目をマスキングします。

    特定可能
  7. 07

    ポータル管理

    ポータルでホスト状態、注文情報、管理画面への入口を確認できます。すべてのノードは365日継続して稼働します。

    管理可能
再現可能な基準から始める

専用Mac miniを選び、初回ビルドを始める

ポータルで現在利用可能なノードを確認し、Oak CoreまたはOak Forge、請求期間、ストレージオプションを選択します。注文後、このページの手順に従って接続、ツールチェーンの復元、受け入れ確認を完了してください。