mcpField
T
templates

templates

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

templates について

templates は、Terraform でワークスペースを構成する Coder テンプレートの作成・更新を支援するスキルです。スターターの選択から編集、検証、公開、テストまでを案内します。

主な機能

  1. 01公式スターターの選択と雛形作成
  2. 02Terraform テンプレートのパラメーターとリソースの編集
  3. 03テンプレートのローカル検証
  4. 04テンプレートバージョンの作成・更新
  5. 05テンプレートからワークスペースをテスト

活用シーン

  1. 01クラウドやコンテナー向けのワークスペーステンプレートを作成
  2. 02ユーザーが選べるワークスペースパラメーターを追加
  3. 03既存の Coder テンプレートを更新・検証
  4. 04ワークスペースを作成してテンプレートをテスト

インストール

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

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

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

同梱ファイルagents/openai.yaml

詳細

テンプレート

Coder テンプレートを作成または更新します。テンプレートは Coder が実行してワークスペースを構築する Terraform コードです。1 つのテンプレートで複数のワークスペースを作成できます。

信頼できる情報源

トピック固有の操作を行う前に、最新の上流ドキュメントを確認してください。

このスキルでは、作成ワークフロー、ユーザーとのやり取りに関するルール、およびテンプレート固有の注意点をいくつか扱います。

ユーザーとのやり取り

ユーザーが求めているのは、Terraform の入門講座ではなく、使えるワークスペースです。

  • ユーザーのインフラストラクチャに適したスターターを既定で選び、確認だけを求めてください。
  • 何かを書き込む前に、予定しているツリー（テンプレート名、ファイル、パラメーター）を提示してください。確認は「はい」か「いいえ」の一度だけ求めてください。
  • チャットでクラウド認証情報を求めないでください。デプロイ環境のプロビジョナー認証を使用し、それが設定されていない場合に限り、そのことを伝えてください。

ワークフロー

1. スターターを選ぶ

ユーザーの意図に合わせて、https://registry.coder.com/templates にある公式スターターを選びます。

  • docker、docker-devcontainer、docker-rstudio：コンテナーホスト。
  • kubernetes、kubernetes-devcontainer、kubernetes-envbox：K8s クラスター。
  • aws-linux、aws-windows、aws-devcontainer：AWS EC2。
  • gcp-linux、gcp-windows、gcp-vm-container、gcp-devcontainer：GCP Compute Engine。
  • azure-linux、azure-windows：Azure VM。
  • digitalocean-linux：DigitalOcean Droplets。
  • incus：LXD/Incus コンテナー。
  • nomad-docker：Nomad 駆動の Docker。
  • scratch：上級者向けの空のテンプレートのみ。

選んだスターターをひな形として展開します。

TEMPLATE_DIR="$(mktemp -d)/$TEMPLATE_NAME"
coder templates init --id "$STARTER_ID" "$TEMPLATE_DIR"

ユーザーが編集を希望する既存のテンプレートがある場合は、代わりに pull します。

TEMPLATE_DIR="$(mktemp -d)/$TEMPLATE_NAME"
coder templates pull "$TEMPLATE_NAME" "$TEMPLATE_DIR"
2. テンプレートの構造を理解する

すべての Coder テンプレートには、main.tf に次の構成要素があります。

  • terraform ブロック：必須プロバイダー（常に coder/coder と、インフラストラクチャプロバイダー）。
  • data "coder_workspace" "me" と data "coder_workspace_owner" "me"：start_count を含むワークスペースのコンテキスト。
  • data "coder_parameter" ブロック：ワークスペース作成時のユーザー入力。
  • 1 つの coder_agent リソース：ワークスペース内で実行されるエージェント。
  • coder_app リソース：VS Code、JetBrains、Jupyter などのアプリを開くダッシュボードボタン。
  • インフラストラクチャリソース：スターターに応じて、docker_container、kubernetes_deployment、aws_instance など。
  • オプションの module ブロック：registry.coder.com の Coder モジュール。
3. 変更する

ユーザーが求めた変更を適用します。よくあるパターンは次のとおりです。

  • coder_parameter を追加します。再ビルド時に値を変更できるようにする場合は、mutable = true を設定します。正規表現や範囲の制約には validation ブロックを使用します。列挙型には option ブロックを使用します。
  • https://registry.coder.com/modules からモジュールを追加します。モジュール固有の構文については、modules スキルまたはモジュールの README を参照してください。
  • ワークスペースの所有者をキーとする専用のボリュームリソースを使ってデータを永続化します。コンテナーや VM のファイルシステムが再ビルド後も保持されることを前提にしないでください。
  • ワークスペースの停止時に破棄するリソースには、count = data.coder_workspace.me.start_count を設定します。

シークレットを terraform.tfvars に保存したり、プレーンな --variable で渡したりしないでください。Coder のシークレット変数または外部プロビジョナーを使用してください。

4. ローカルで検証する
cd "$TEMPLATE_DIR"
terraform init
terraform fmt
terraform validate
5. Push する

初回の push：

coder templates create "$TEMPLATE_NAME" -d "$TEMPLATE_DIR" --yes

既存のテンプレートを更新する場合：

coder templates push "$TEMPLATE_NAME" -d "$TEMPLATE_DIR" --yes
coder templates versions list "$TEMPLATE_NAME"

push 時に --activate を指定するか、push 後に coder templates versions promote を実行して、新しいバージョンを有効化します。

6. テストする

新しいバージョンからワークスペースを 1 つ作成します。

coder create "$WORKSPACE_NAME" \
  --template "$TEMPLATE_NAME" \
  --yes

必須パラメーターはすべて明示的に渡してください。適切な値がないリストパラメーターには [] を使用します。列挙型には最初の選択肢を使用します。デフォルト値では対応できない場合に限り、ユーザーに確認してください。

ビルドの完了までではなく、エージェントが ready になるまで待ちます。エージェントが connecting のままの場合、ワークスペースは使用できません。

7. 引き継ぎ

これがユーザーにとって初めてのテンプレートだった場合は、次の内容で締めくくります。

  • ダッシュボード内でテンプレートが保存されている場所。
  • coder ssh で接続できるワークスペース名を1つ。
  • 更新についての一文：main.tf を編集してから、 coder templates push を実行します。

よく使われるパラメーター

ユーザーからよく尋ねられるため、知っておくと便利です。

  • git_repo_url：ワークスペースの起動時にクローンする URL です。git-clone モジュールと組み合わせます。
  • region：プロバイダー固有のリージョン選択パラメーターです。対応する *-region モジュールと組み合わせます。
  • instance_type または node_size：option リストを指定する、プロバイダー固有のマシンサイズです。
  • dotfiles_uri：起動時に個人用 dotfiles リポジトリをクローンします。dotfiles モジュールと組み合わせます。
  • vscode_binary_version：code-server のバージョンを固定するための任意のパラメーターです。

variable と coder_parameter の使い分け

テンプレートのデプロイ全体を通じて固定され、管理者が設定するインフラストラクチャレベルの選択には、Terraform の variable（coder templates push の実行時に --variable で設定）を使用します。

  • ホストマシンの CPU アーキテクチャ（arch）
  • ストレージプールまたはボリュームグループ名
  • リモートホスト識別子またはクラスターエンドポイント

ワークスペースの作成時またはビルド時にワークスペースユーザーが選択する項目には、data "coder_parameter" を使用します。

  • OS イメージまたはディストリビューション
  • CPU 数、メモリ、ディスクサイズ
  • ワークスペースごとに異なることが妥当な値

インフラストラクチャの詳細を coder_parameter として公開しないでください。ユーザーがホストの CPU アーキテクチャやストレージプール名を知る必要はありません。

# Good: arch is an admin concern, not a user choice
variable "arch" {
  description = "CPU architecture of the VM host (amd64 or arm64). Set at template push time."
  type        = string
  default     = "amd64"
}

# Good: image is a user choice made per workspace
data "coder_parameter" "image" {
  name    = "image"
  type    = "string"
  default = "ubuntu/noble/cloud"
  option {
    name  = "Ubuntu 24.04 LTS"
    value = "ubuntu/noble/cloud"
  }
}

variable の値は push 時に渡します。

coder templates push my-template -d . --yes \
  --variable arch=arm64 \
  --variable storage_pool=fast-nvme

coder_agent の dir の設定

coder_agent の dir は任意で、デフォルト値は $HOME です。SSH セッションとウェブターミナルセッションの開始ディレクトリ、および組み込みの VS Code アプリが開くフォルダーを設定します。ユーザーがプロジェクトのチェックアウト先から作業を始める場合は設定し、それ以外の場合は省略します。

resource "coder_agent" "main" {
  arch = var.arch
  os   = "linux"
  dir  = "/home/${local.username}/project"
}
  • SFTP と scp は、相対パスおよび ~/ で始まるパスを dir を基準に解決するため、ファイル転送には絶対パスを使用してください。
  • Coder プロバイダーのバージョン 2.17 から 2.19 では、dir は非推奨として扱われ、$HOME 以外に設定すると警告が表示されます。バージョン 2.20.0 で非推奨扱いは削除されたため、この警告は無視してかまいません。
  • Coder Desktop のファイル同期は、macOS v0.8.4 以降および Windows v0.8.5 以降では、どの dir でも動作します。それ以前の Desktop バージョンでは、dir が $HOME 以外の場合にファイル同期を開始できません。

coder/registry へのテンプレートのコントリビュート

PR を作成する前に、コードスタイル、構成要件、PR レビューの完全なチェックリストについて、レジストリの AGENTS.md をお読みください。また、PR 本文の必須形式について、 PR テンプレート もお読みください。

AGENTS.md に記載されていない、テンプレート固有の追加事項：

  • テンプレートは registry/<namespace>/templates/<name>/ に配置し、main.tf と README.md を含めます。.tftest.hcl は不要です（テストが必要なのはモジュールのみです）。

  • PR タイトルの形式：feat(<namespace>/templates/<name>): <short description>（例：feat(bpmct/templates/incus-vm): add Incus VM template）。

  • ブランチを作成する前に、フォークの main を upstream と同期してください。 同期しないと、変更したファイルだけでなく、名前空間内に以前からあるすべてのファイルが新規追加として PR の差分に表示されます。

    gh api -X POST /repos/<your-username>/registry/merge-upstream \
  -f branch=main

  • bun fmt（terraform fmt と Prettier を実行）を実行し、push 前に差分が生じないことを確認してください。

セーフガード

  • terraform validate に合格していないテンプレートのバージョンを push しないでください。
  • 依存しているものがないと確認せずに、アクティブなテンプレートのバージョンをアーカイブまたは削除しないでください。
  • ユーザーがまだ試行錯誤している場合は、coder templates push に --activate を指定しないでください。新しいバージョンを先に確認したい場合があります。
  • クラウドの認証情報、OAuth シークレット、ワークスペーストークンを main.tf や terraform.tfvars に置かないでください。シークレット変数を使用してください。
  • Terraform をすでに作成したことがあるユーザー以外に、scratch を推奨しないでください。

バンドルされているリソース

このスキルには、テンプレートごとのレシピは含まれていません。プロバイダー固有の詳細については、registry.coder.com にある各テンプレートの README と、上流の Coder ドキュメントを参照してください。

コメント

Markdown 対応