mcpField
S
setup

setup

github.com/coderクラウド・DevOps14135 回インストール1 日前に更新
リポジトリ

setup について

Coder のインストールと初回セットアップを案内するスキルです。CLI や Web UI の操作を自分で調べずに環境を整えたい人向けで、要件確認、管理者作成、初期ワークスペース構築まで扱い、危険な変更には確認を求めます。

主な機能

  1. 01デプロイ要件の確認
  2. 02Coder のインストールと起動
  3. 03最初の管理者の作成
  4. 04スターターテンプレートの登録
  5. 05初期ワークスペースの構築
  6. 06危険な操作前の確認

活用シーン

  1. 01Coder のデモ環境を構築
  2. 02チームまたは本番環境を準備
  3. 03管理者と初期ワークスペースを作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/coder/skills --skill setup

インストール後、Claude Code で/setupを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
coder-agents.md
first-user-github-device.md
troubleshooting.md
scripts/
github-device-fetch.sh
github-device-poll.sh

詳細

セットアップ

ユーザーに CLI や Web UI を学んでもらうことなく、Coder をインストールし、初回セットアップを完了します。

信頼できる情報源

トピック固有の詳細を使用する前に、最新の上流ドキュメントを確認してください。

製品の詳細の大半はこのスキルではなく、上流ドキュメントに記載されています。インストール方法、Helm の値、TLS、ワイルドカードドメイン、テンプレート、OIDC、OAuth、外部プロビジョナー、アップグレード、バックアップ、テレメトリー、Premium の機能については、ドキュメントを参照してください。ドキュメントの参照はユーザーから明示的に求められた場合を除き、ユーザー自身に任せず、内容を確認して対応してください。

このスキルでは、インストールの流れ、ユーザーとのやり取りのルール、セットアップ固有の注意点のみを扱います。

ユーザーとのやり取り

ユーザーが求めているのは、Coder の解説ではなく、動作する Coder のデプロイです。メッセージは短く、簡潔にしてください。

  • 構造化された選択ツールを使う場合を除き、一度に尋ねるのは一つの判断事項にしてください。
  • 妥当なデフォルトを優先し、確認を求めてください。
  • ユーザーが初めての場合は、Coder の概念を説明してから名称を伝えてください。
  • ユーザー向けの質問や引き継ぎでは、フラグ、環境変数、設定キー、生ログ、ドキュメントの URL を出さないでください。
  • ユーザーに「スキル」や「セットアップスキル」と言わないでください。
  • 次のステップとして CLI の操作手順をユーザーに渡さないでください。追加作業を平易な言葉で提案してください。

説明に使える言い換え:

  • アクセス URL:Coder を使うときに開く Web アドレスです。
  • ワイルドカード URL:ワークスペース内のアプリに、それぞれ専用のサブドメインを割り当てる DNS です。
  • ワークスペース:一人のための一つの開発環境です。
  • テンプレート:Coder がワークスペースを作成するためのレシピです。
  • オーナー:最初の管理者アカウントです。
  • 外部認証:ワークスペースから GitHub、GitLab などにサインインし、非公開リポジトリをクローンできるようにすることです。

ユーザーが実装の詳細を尋ねた場合は、そのターンでは技術的に回答し、その後は平易な言葉に戻してください。

ワークフロー

各フェーズには終了条件があります。システムパッケージのインストール、ポートの開放、kubeconfig の上書き、ボリュームの削除、既存の Coder の状態の置き換えなど、破壊的な操作を行う前に確認してください。

1. 状況を把握する

ホストを調査する前に、次の5項目について回答を得てください。

  1. Coder を使ったことがありますか?
  2. クイックスタート/デモですか、それとも長期的なチーム向けデプロイですか?
  3. Coder の実行場所はどこですか?Docker、Kubernetes/Helm、ホストへの直接インストール、それ以外のどれですか?
  4. 最初の管理者は GitHub でサインインしますか、それともメールアドレスとパスワードでサインインしますか?
  5. セットアップでスターター開発環境を用意し、最初のワークスペースを作成しますか?

利用可能な場合は、ランナーの構造化質問ツールを使ってください。一度に4つの質問までしか対応していない場合は、最初の4つをまとめて尋ね、ワークスペースについては2回目に尋ねてください。構造化質問ツールがない場合は、5つの質問を簡潔なチャットメッセージ1つにまとめてください。

回答を受け取ったら、ユーザーに見せずに調査します。

uname -sm
command -v apt-get dnf yum apk brew zypper pacman 2>/dev/null
docker version --format '{{.Server.Version}}' 2>/dev/null
kubectl config current-context 2>/dev/null
helm version --short 2>/dev/null
coder --version 2>/dev/null
systemctl is-active coder 2>/dev/null
test -f "$HOME/.config/coderv2/url" && cat "$HOME/.config/coderv2/url"
env | grep -E '^(CODER_AGENT_TOKEN|CODER_WORKSPACE_NAME)=' || true

次に、短い計画を段落1つで示し、システムに変更を加える前に「はい/いいえ」で確認してください。

対応方針:

  • クイックスタート/デモ:デフォルトでは、組み込みの *.try.coder.app トンネルを使います。
  • 本番/チーム向け:ドメイン、HTTPS の方針、Postgres の選択、ワイルドカードの希望、サービスマネージャーを確認します。計画を提案する前に、最新のインストールおよび管理者セットアップのドキュメントを確認してください。
  • Docker、Kubernetes/Helm、ホストへの直接インストールは自動化できます。
  • Rancher、OpenShift、クラウドマーケットプレイス、エアギャップ環境へのインストールでは、記憶に頼った手順ではなく、最新のドキュメントに従ってください。
  • ホストへの直接インストールでも、Docker があれば Docker スターターを用意できます。有効な kube コンテキストがない場合は、Kubernetes を選ばないでください。
  • ヘッドレスモードでは、元の依頼を承認と見なし、デフォルトでメールアドレスとパスワードによるサインインを選択します。本番環境に必要な情報が不足している場合は、速やかに中止してください。

以前のクイックスタートの状態が残っていて、ユーザーが本番環境へ移行する場合は、それを停止するか確認してください。PID、compose、systemd、Helm のハンドルを使用し、無差別な pkill coder は決して使わないでください。

2. インストール

インストールする前に、このシェルがすでに Coder ワークスペース内にあるか確認します。

test -n "${CODER_AGENT_TOKEN-}${CODER_WORKSPACE_NAME-}"

ワークスペース内にある場合、ユーザーがネストした Coder を明示的に希望していない限り、ホストへのインストールは行わないでください。スコープを限定したディレクトリでの Docker compose や、別のクラスタコンテキストに対する Helm は許容されます。

直接インストールする場合は、正式なインストーラーを使用します。

curl -fsSL https://coder.com/install.sh | sh

ユーザー領域にインストールする場合は、次のようにします。

curl -fsSL https://coder.com/install.sh \
  | sh -s -- --method standalone --prefix "$HOME/.local"
export PATH="$HOME/.local/bin:$PATH"

Docker compose と Helm については、最新の上流インストールページを読み、その手順を適用します。本番環境では、ユーザーが別の指定をしていない限り、安定版リリースを優先します。coder --version でフェーズを確認します。

3. 起動

生成ファイル用の状態ディレクトリを1つ作成します。

STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/coder-install"
mkdir -p "$STATE_DIR"

ホストで直接起動するクイックスタートは次のとおりです。

nohup coder server > "$STATE_DIR/server.log" 2>&1 &
echo $! > "$STATE_DIR/server.pid"

クイックスタートのトンネルにはアクセス URL を渡さないでください。View the Web UI: の後にあるサーバーログの行を解析し、/healthz が応答するまで待ちます。トンネルを初期化できない場合は、http://localhost:7080 を使い、--http-address 0.0.0.0:7080 を指定して再起動します。ワークスペースコンテナは、ホストのループバックアドレスのみにバインドされた状態では接続できません。

Docker compose、systemd、Helm では、それぞれのスーパーバイザーにプロセスとログを管理させます。本番環境では、最新のドキュメントをもとにマニフェストまたはサービス環境を設定し、公開 URL に対する /healthz の応答を待ちます。設定している場合は、ワイルドカード DNS を確認します。

4. 管理者を作成する

最初のユーザーが Owner になります。

ログインする前に、既存の CLI セッションを保護します。デフォルトの設定が別の実在するデプロイメントを指している場合に限り、分離した CODER_CONFIG_DIR を設定します。

default_dir="${XDG_CONFIG_HOME:-$HOME/.config}/coderv2"
if [ -f "$default_dir/url" ]; then
  existing="$(cat "$default_dir/url")"
  case "$existing" in
    "$ACCESS_URL"|"") : ;;
    *)
      export CODER_CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/coderv2-quickstart"
      export CODER_CACHE_DIRECTORY="${XDG_CACHE_HOME:-$HOME/.cache}/coderv2-quickstart"
      mkdir -p "$CODER_CONFIG_DIR" "$CODER_CACHE_DIRECTORY"
      ;;
  esac
fi

新規デプロイメントでは、利用できる場合は GitHub デバイスフローを優先します。/api/v2/users/authmethods と /api/v2/users/oauth2/github/device を確認します。どちらかがデバイスフローを利用できないと示す場合は、メールアドレスとパスワードに切り替えます。

デバイスフローは、次の3つの手順に分けて実行します。

  1. scripts/github-device-fetch.sh を実行します。
  2. チャットでユーザーに認証 URL とコードを伝え、確認を待ちます。
  3. scripts/github-device-poll.sh を実行します。

取得とポーリングを1回のシェル呼び出しにまとめないでください。ツールランナーは通常、ポーリングが終了するまで標準出力をバッファリングします。フローに失敗した場合、またはプロトコルの詳細が必要な場合に限り、 references/first-user-github-device.md を読みます。

メールアドレスとパスワードを使用する場合は、強力なパスワードを生成して環境変数経由で渡し、上流のエンタープライズトライアルのプロンプトを必ず無効にします。

export CODER_FIRST_USER_PASSWORD="$PASSWORD"
coder login "$ACCESS_URL" \
  --first-user-email "$EMAIL" \
  --first-user-username "$USERNAME" \
  --first-user-full-name "$FULL_NAME" \
  --first-user-trial=false
unset CODER_FIRST_USER_PASSWORD

生成した認証情報は、$STATE_DIR の下にモード 0600 で保存し、coder whoami と coder users list で確認します。

5. スターターテンプレートをプッシュする

選択したインフラストラクチャに合うスターターを選びます。ID や必須変数を決めつける前に、最新のテンプレートドキュメントを読みます。

TEMPLATE_DIR="$(mktemp -d)/$TEMPLATE_NAME"
coder templates init --id "$TEMPLATE_ID" "$TEMPLATE_DIR"
coder templates push "$TEMPLATE_NAME" -d "$TEMPLATE_DIR" --yes
coder templates list

シークレット以外の値には変数ファイルを使用します。シークレットを表示したり、terraform.tfvars に記載したり、プレーンな --variable 値として渡したりしないでください。認証情報をサーバーに置かないようにするには、Coder のシークレット変数のパターンか外部プロビジョナーを使用します。

6. ワークスペースをビルドする

ユーザーが最初のワークスペースを辞退した場合は、このフェーズをスキップします。

coder create を実行する前に、テンプレートをプルして data "coder_parameter" ブロックを確認します。

TEMPLATE_PULL="$(mktemp -d)/$TEMPLATE_NAME"
coder templates pull "$TEMPLATE_NAME" "$TEMPLATE_PULL"

必須パラメーターはすべて明示的に渡します。「なし」が明らかな必須リストパラメーターには [] を使用し、単純な単一選択の列挙型では最初の選択肢を使用します。妥当な値がない場合に限り、ユーザーに尋ねます。

coder create "$WORKSPACE_NAME" \
  --template "$TEMPLATE_NAME" \
  --parameter 'jetbrains_ides=[]' \
  --yes

ワークスペースエージェントが ready になるまで待ちます。ビルドが成功しただけでは不十分です。エージェントが connecting のままの場合は、 references/troubleshooting.md を読みます。

7. 引き継ぎ

最後に、次の内容を含む短い英語の文章を、装飾なしで記載してください。

  • ブラウザーの URL。
  • サインイン認証情報、または GitHub サインインが完了したことの確認。
  • セットアップでローカルファイルが書き込まれた場所。
  • 実際のスーパーバイザー(ホスト PID/ログ、Docker compose、systemd、または Helm)に対応するログコマンドを 1 つ、停止コマンドを 1 つだけ。
  • スターターワークスペースが作成されたかどうか。
  • Coder Agents のセットアップを申し出る一文。

ドキュメントの URL、生の上流 .md リンク、代替コマンドのプレースホルダー、ユーザーが試す CLI コマンドの一覧は含めないでください。

ユーザーが Coder Agents の申し出を受け入れた場合は、references/coder-agents.md を読み、その手順に従ってください。LLM API キーをチャットに貼り付けるよう求めず、シェルでキーをエクスポートして、環境変数から読み取るようにしてください。

安全対策

  • Docker を使うと決めつけないでください。Coder をどこで実行するか確認してください。
  • coder に対する一括プロセス終了は行わないでください。特に Coder ワークスペース内では行わないでください。
  • 明示的な許可なしに、破壊的なクリーンアップを実行しないでください。
  • 既存のログイン先が別の場所を指している場合を除き、CODER_CONFIG_DIR を分離しないでください。
  • トライアルや Premium への登録をユーザーに促さないでください。--first-user-trial=false を指定してください。
  • ユーザーに代わってテレメトリーを無効にしないでください。
  • /healthz の準備状況チェックを省略しないでください。
  • GitHub のデバイスフロー用 Cookie jar や env ファイルを残さないでください。
  • 管理者パスワード、OAuth シークレット、クラウド認証情報、LLM API キーを表示しないでください。

セットアップが停滞した場合は、最初から原因を診断する前に references/troubleshooting.md を読んでください。ワークスペースホストの保護、Docker ブリッジの到達性、NixOS のファイアウォールの動作、ARM での組み込み Postgres、Terraform インストーラーの署名エラー、Docker グループの更新、Caddy のリダイレクトループ、tailnet の DNS リバインド保護について説明しています。

同梱リソース

次のリソースは、該当する条件が発生した場合にのみ読み込んでください。

  • references/first-user-github-device.md: GitHub デバイスコードプロトコルとエラー。読み込む条件:デバイスサインインに失敗した場合、または詳細が必要な場合。
  • references/coder-agents.md: Coder Agents のプロバイダー/モデルのセットアップ。読み込む条件:ユーザーが Agents の申し出を受け入れた場合。
  • references/troubleshooting.md: 上流ドキュメントでは十分に扱われていない、セットアップ固有のエラー。読み込む条件:インストール、サーバー、テンプレート、またはワークスペースの準備が停滞した場合。
  • scripts/github-device-fetch.sh: GitHub デバイスコードを取得し、$STATE_DIR/github-device.* に書き込みます。
  • scripts/github-device-poll.sh: GitHub の完了をポーリングし、Coder セッションを書き込み、一時ファイルをクリーンアップします。

コメント