원클릭으로 Manus에서 모든 스킬 실행

conoha-cli

스타2

포크0

업데이트2026년 5월 9일 14:27

ConoHa VPS3 CLIによるインフラ構築スキル。サーバー作成、アプリデプロイ、 Kubernetesクラスター、OpenStackプラットフォーム、Slurmクラスターの構築を支援。 FigmaデザインからWebアプリを生成してデプロイすることも可能。「ConoHaでサーバーを作って」「k8sクラスターを構築して」「アプリをデプロイして」「Figmaからデプロイ」「デザインからアプリを作って」などのリクエストでトリガー。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

crowdy

crowdy/conoha-cli-skill

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

ConoHa CLI スキル

ConoHa VPS3 CLIを使ったインフラ構築ガイド。

前提条件

conoha-cli がインストール済みであること
conoha auth login で認証済みであること
SSHキーペアが登録済みであること（conoha keypair create <name>）

非TTY環境（Windows等）での注意事項

Windows（Windows Server 2019等）やCI/CD環境など、TTYが利用できない環境では対話的なプロンプトが動作しない。以下のルールに従うこと：

--no-input フラグを付与する — すべてのコマンドにグローバルフラグ --no-input を付けることで、対話プロンプトを無効化できる。CI/CDパイプラインでは環境変数 CONOHA_NO_INPUT=1 を設定する方が便利な場合がある
必須パラメータをすべてフラグで指定する — 省略すると対話的プロンプトが発生しエラーになる（例: interactive selection requires a TTY）
conoha server create では --flavor、--image、--key-name、--security-group を必ず指定する — --security-group は repeatable。最低限 SSH 到達可能な SG を含めること。一般的には default + IPv4v6-SSH (proxy モードを使うなら IPv4v6-Web も追加)。default 単独では SSH 22 が届かないケースが多い。SG を省略すると --no-input 下で selection required but --no-input is set または silent fail (exit 0) になる (crowdy/conoha-cli#155)
conoha app サブコマンドでは --app-name を必ず指定する — 省略するとアプリ名の入力プロンプトが発生する。値は DNS-1123 ラベル (小文字英数とハイフン、英数で開始/終了、^[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?$, 1–63 文字) とすること。例: my-app ✅ / my_app ❌ / MyApp ❌
※ 現行 CLI は app init/deploy 時に DNS-1123 で値を弾く (crowdy/conoha-cli#124)。旧バージョンで作成された underscore/大文字を含むアプリは app destroy で /opt/conoha/<name> の作業ディレクトリが残留する既知の不具合があったため (crowdy/conoha-cli#119)、レガシー名のアプリを片付ける場合のみ app destroy 後に手動で同パスを確認・削除する
確認プロンプトが出るコマンドには --yes フラグで確認をスキップする（環境変数: CONOHA_YES=1）。対象は破壊的コマンド (server delete、app destroy、app stop) に加えて server create 自体 — boot volume を新規作成する確認プロンプトが出るため --yes がないと confirmation required but --no-input is set; use --yes to auto-confirm で失敗する (この時 boot volume は orphan として残るので注意、後述の「在庫切れリトライ」参照)。app restart / app rollback は確認プロンプトを出さないため --yes は不要 (指定しても no-op)
アプリの既存モードと異なる --proxy / --no-proxy を指定するとモード不一致エラーで停止する — 切り替えたい場合は conoha app destroy --yes → 反対モードで init し直す

# 非TTY環境での例
conoha server create --name my-server --flavor <ID> --image <ID> --key-name <キー名> \
  --security-group default --security-group IPv4v6-SSH \
  --no-input --yes --wait
conoha app deploy my-server --app-name myapp --no-input

# CI/CDパイプラインでは環境変数でまとめて設定可能
export CONOHA_NO_INPUT=1
export CONOHA_YES=1

基本操作

サーバー管理

コマンド	説明
`conoha server list`	サーバー一覧を表示する
`conoha server create --name <名前> --flavor <ID> --image <ID> --key-name <キー名> --security-group <SG名>`	サーバーを作成する (`--security-group` は repeatable、SSH 用 SG を必ず含める)
`conoha server create ... --volume <既存ボリュームID>`	既存 boot volume を再利用してサーバーを作成する (`--image` も CLI 上必須なので作成元と同じ ID を渡す)
`conoha server create ... --wait`	サーバー作成完了まで待機する
`conoha server show <ID\|名前>`	サーバー詳細を表示する
`conoha server delete <ID\|名前> --yes`	サーバーを削除する (boot volume は残る — `volume list` で確認し個別に削除するか、下記 `--delete-boot-volume` を使う)
`conoha server delete <ID\|名前> --delete-boot-volume --yes --wait`	サーバーと boot volume を一括削除する (推奨。残し忘れによる quota 圧迫を防ぐ)
`conoha server add-security-group <ID\|名前> --name <SG名> --yes` (alias `add-sg`)	既存サーバーに SG を後付けする (SSH 不通時の救済に有効)
`conoha server remove-security-group <ID\|名前> --name <SG名> --yes` (alias `remove-sg`)	サーバーから SG を取り外す
`conoha server deploy <ID\|名前> --script <ファイル> --env KEY=VALUE`	スクリプトをSSH経由で実行する

フレーバー・イメージ

コマンド	説明
`conoha flavor list`	利用可能なフレーバー一覧を表示する
`conoha image list`	利用可能なイメージ一覧を表示する

ボリューム

コマンド	説明
`conoha volume list`	ボリューム一覧を表示する (orphan の boot volume 確認に使う)
`conoha volume show <ID>`	ボリューム詳細を表示する
`conoha volume delete <ID> --yes`	ボリュームを削除する (server delete 時に残った boot volume の救済)

ネットワーク

コマンド	説明
`conoha network list`	ネットワーク一覧を表示する
`conoha network create --name <名前>`	プライベートネットワークを作成する
`conoha network subnet create --network-id <ID> --cidr <CIDR>`	サブネットを作成する
`conoha network sg list`	セキュリティグループ一覧を表示する
`conoha network sg create --name <名前>`	セキュリティグループを作成する
`conoha network sgr create --security-group-id <ID> --direction ingress --protocol tcp --port-min <ポート> --port-max <ポート> --remote-ip <CIDR>`	セキュリティグループルールを追加する

キーペア

コマンド	説明
`conoha keypair list`	キーペア一覧を表示する
`conoha keypair create <名前>`	キーペアを作成する

アプリデプロイ

conoha app は 2 つのデプロイモードを提供する：

proxy モード (既定) — conoha-proxy 経由の blue/green デプロイ。ドメイン + Let's Encrypt TLS、conoha.yml 必須、事前に conoha proxy boot が必要。
no-proxy モード (--no-proxy) — フラット単一スロット。conoha.yml / proxy / DNS 不要。テスト・内部 VPS・非 HTTP サービス・ホビー用途に適する。

conoha app init がサーバーに .conoha-mode マーカーを書き込み、以降の lifecycle コマンドは自動的に同じモードで動作する。--proxy / --no-proxy フラグはマーカーを上書きするが、不一致ならエラーになる。

コマンド	説明
`conoha app init <server>`	proxy モードで初期化 (conoha.yml と `conoha proxy boot` 済み前提)
`conoha app init <server> --app-name <app> --no-proxy`	no-proxy モードで初期化 (Docker / Compose が入っていることを検証。インストールはしない)
`conoha app deploy <server>`	カレントディレクトリをデプロイ (モードはマーカーから自動判別)
`conoha app deploy <server> --slot <id>`	slot ID を固定 (proxy モード)
`conoha app rollback <server>`	前 slot へ即時ロールバック (proxy モードのみ、drain 窓内)
`conoha app status <server> --app-name <app>`	コンテナ状態を表示
`conoha app logs <server> --app-name <app> --follow`	ログをストリーミング
`conoha app logs <server> --app-name <app> --service <svc>`	特定サービスのログ
`conoha app stop <server> --app-name <app>`	コンテナを停止
`conoha app restart <server> --app-name <app>`	コンテナを再起動
`conoha app destroy <server> --app-name <app> --yes`	アプリをサーバーから完全削除 (非対話)
`conoha app reset <server> --app-name <app> --yes`	`destroy` + `init` + `deploy` を 1 SSH セッションで連続実行 (再デプロイ用、v0.5.6 以降)。`app env set` で投入した値は `destroy` で消えるため、必要なら直前に export して再投入する
`conoha app list <server>`	サーバー上のデプロイ済みアプリ一覧
`conoha app env set <server> --app-name <app> KEY=VALUE`	サーバー側永続環境変数を設定
`conoha app env list/get/unset`	環境変数の一覧・取得・削除

注意: app env はサーバー側 /opt/conoha/<app>.env.server に書き込むが、現状その値が実際にコンテナに反映されるのは no-proxy モードのデプロイ時のみ。proxy モードでは warning: app env has no effect on proxy-mode deployed slots; see #94 for the redesign が出る (crowdy/conoha-cli#94 予定)。proxy モードの環境変数は当面 compose 側の environment: / env_file: で渡す。

モード切り替えは destroy → 反対モードで init。同一 VPS で <app-name> が異なれば 2 モードを並列で共存可。

選択指針:

ドメイン + HTTPS が必要 / 本番公開 → proxy
docker compose up -d --build 相当で十分 / DNS 未取得 / 社内・検証・ホビー → no-proxy

レシピ一覧

ユーザーのリクエストに応じて、該当するレシピファイルを読み込んで手順を実行する。

レシピ	用途	ファイル
シングルサーバーアプリ	Docker Composeアプリのデプロイ	recipes/single-server-app.md
シングルサーバースクリプト	カスタムスクリプトによるセットアップ	recipes/single-server-script.md
Kubernetesクラスター	k3sによるマルチノードk8sクラスター	recipes/k8s-cluster.md
OpenStackプラットフォーム	DevStackによるOpenStack環境	recipes/openstack-platform.md
Slurmクラスター	HPCジョブスケジューラクラスター	recipes/slurm-cluster.md
FigmaデザインからWebアプリ	FigmaデザインからReactコード生成・デプロイ	recipes/figma-to-deploy.md
リリーススモーク	post-merge / pre-tag の e2e 検証 (実 VPS)	recipes/release-smoke.md
Issue 最小再現	ユーザー報告バグの再現と診断ログ収集	recipes/issue-repro.md

イメージ別 known-issues

ConoHa の各イメージには CLI が知っておくべきデフォルト挙動の差がある。同じコマンドでもイメージ次第で挙動が変わるので、選んだ image_id ごとに以下を確認する。

イメージ	注意点	影響
`vmi-docker-29.2-ubuntu-24.04-amd64`	UFW が `policy DROP` で SSH のみ allow / kernel default `net.ipv4.ip_unprivileged_port_start=1024`	`proxy boot` が `bind: permission denied` で crash-loop / 外部から 80,443 が unreachable。CLI v0.6.x 以降は BootScript が両方を自動修正するが、旧版や独自イメージでは手動対応が必要

新しいイメージで動作させる時は最初に ad-hoc な実 VPS スモーク で UFW / sysctl / TOFU のクラスを確認すること。スモーク手順は recipes/release-smoke.md に codify されている。

共通パターン

マルチサーバー作成

複数サーバーを作成する場合、命名規則を統一する：

# 例: k8sクラスター
conoha server create --name k8s-master-1 --flavor <ID> --image <ID> --key-name <キー名> --security-group <SG名> --wait
conoha server create --name k8s-worker-1 --flavor <ID> --image <ID> --key-name <キー名> --security-group <SG名> --wait
conoha server create --name k8s-worker-2 --flavor <ID> --image <ID> --key-name <キー名> --security-group <SG名> --wait

セキュリティグループの事前準備

クラスター構築前に必要なポートを開放するセキュリティグループを作成する：

# セキュリティグループ作成
conoha network sg create --name <クラスター名>-sg

# 必要なルールを追加（例: SSH + クラスター固有ポート）
conoha network sgr create --security-group-id <SG-ID> --direction ingress --protocol tcp --port-min 22 --port-max 22 --remote-ip 0.0.0.0/0

SSH 到達性を担保する SG attach パターン

conoha server create --security-group default だけで作成すると default SG のインバウンドが極めて制限的なため SSH (22) すら届かないケースが頻発する。作成時に必要な SG をすべて attach するのが基本：

conoha server create --name <名前> --flavor <ID> --image <ID> --key-name <キー名> \
  --security-group default \
  --security-group IPv4v6-SSH \
  --security-group IPv4v6-Web \
  --no-input --yes --wait

既に作成済みで SSH が届かない場合は VPS を消さずに後付け で復旧できる：

conoha server add-sg <ID|名前> --name IPv4v6-SSH --yes
conoha server add-sg <ID|名前> --name IPv4v6-Web --yes

在庫切れリトライと既存ボリュームの再利用

conoha server create は ConoHa3 側で「No compute resource in stock」となった場合に HTTP 500 を返す (特に L4 GPU フレーバーで発生しやすい)。この API はサーバー作成前に boot volume を先に作る仕様のため、失敗時には boot volume だけが orphan として残る：

boot volume 3a156cca-... was created but server creation failed.
You can delete it with: conoha volume delete 3a156cca-...
API error (HTTP 500): {"code": 500, "error": "No compute resource in stock."}

このボリュームは捨てずに --volume <既存ボリュームID> で次のリトライに渡せる：

# 在庫が戻ったら、同じ image ID と組み合わせて再試行する
conoha server create \
  --name <名前> \
  --flavor <ID> \
  --image <作成元と同じ image ID> \
  --volume <既存ボリュームID> \
  --key-name <キー名> \
  --security-group default --security-group IPv4v6-SSH \
  --no-input --yes --wait

ポイント:

リトライ毎に新規ボリュームを作る必要がなく、orphan のクリーンアップも不要
同じフレーバーが在庫切れでも、別のフレーバー (例: より大きいプラン) で同じボリュームを再利用してサーバー作成できる場合がある
不要になった orphan は conoha volume delete <ID> --yes で個別に削除する
L4 flavor は GPU 専用ネットワーク (ext-gpu-v4v6-*) に自動割り当てされるため --network 指定は不要

デプロイスクリプト実行順序

マルチサーバー構成では以下の順序で実行する：

全ノード共通の初期設定スクリプトを実行する
マスター/コントローラーノードのセットアップスクリプトを実行する
マスターからジョイン情報（トークン等）を取得する
ワーカー/コンピュートノードのセットアップスクリプトを実行する（ジョイン情報を--envで渡す）

# 1. 全ノード共通
conoha server deploy <各ノード> --script common-setup.sh

# 2. マスターセットアップ
conoha server deploy <マスター> --script master-setup.sh

# 3. ジョイン情報取得（SSH経由）
TOKEN=$(ssh root@<マスターIP> "取得コマンド")

# 4. ワーカーセットアップ
conoha server deploy <ワーカー> --script worker-setup.sh --env JOIN_TOKEN=$TOKEN

問題報告

conoha-cli の使用中に異常な動作や予期しないエラーを発見した場合、gh コマンドが利用可能であれば GitHub Issue を自動登録する：

gh issue create --repo crowdy/conoha-cli --title "<エラーの要約>" --body "<再現手順と詳細>"

再現手順、実行したコマンド、エラーメッセージを含める
可能であれば conoha-cli のバージョン（conoha version）も記載する

name