mcpField
D
docker-build-deploy

docker-build-deploy

github.com/wu529778790クラウド・DevOps41.0k 回インストール5 週間前に更新
リポジトリ

docker-build-deploy について

docker-build-deploy は、Docker イメージのビルド、GHCR へのプッシュ、サーバーへのデプロイを行う GitHub Actions ワークフローを生成するスキルです。Node.js プロジェクトをデプロイする開発者向けで、最適化した Dockerfile も作成できます。

主な機能

  1. 01Node.js プロジェクトの検出
  2. 02最適化された Dockerfile の生成
  3. 03GHCR ビルド・プッシュ用ワークフローの作成
  4. 04SSH によるサーバーデプロイ
  5. 05ポートと env ファイルの設定
  6. 06GitHub Secrets 設定の案内

活用シーン

  1. 01Node.js プロジェクトのコンテナデプロイ設定
  2. 02イメージの GHCR への自動ビルドとプッシュ
  3. 03SSH 経由でサーバーへイメージをデプロイ
  4. 04デプロイへのヘルスチェックと非 root 実行の追加

インストール

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

$npx skills add https://github.com/wu529778790/shenzjd-skills --skill docker-build-deploy

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

同梱ファイル

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

README.md
templates/
docker-deploy.yml
Dockerfile.nodejs

詳細

Docker のビルドとデプロイ

Docker のビルド、GHCR へのプッシュ、サーバーへのデプロイを行う GitHub Actions ワークフローをワンステップで生成します。

概要

Docker CI/CD ワークフロー全体を自動生成します。イメージのビルド → GHCR へのプッシュ → サーバーへの SSH デプロイを行います。最適化された Dockerfile（マルチステージビルド、非 root ユーザー、ヘルスチェック）と GitHub Actions ワークフローテンプレートが含まれています。

使用する場面

  • プロジェクトをコンテナ化してデプロイしたい場合
  • Docker イメージを自動的にビルドする GitHub Actions が必要な場合
  • Docker、GHCR、コンテナのデプロイ、CI/CD について言及している場合
  • /docker-build-deploy を入力した場合
  • 継続的デプロイのパイプラインを設定したい場合
  • コンテナレジストリにイメージをプッシュしたい場合
  • SSH 経由でリモートサーバーへのデプロイを自動化したい場合
  • 既存の Dockerfile をマルチステージビルドで最適化したい場合
  • コンテナのデプロイにヘルスチェックを追加したい場合

使用しない場面：

  • Dockerfile の作成だけを希望している場合
  • Kubernetes でデプロイする場合（別のワークフローを使用します。kubectl または Helm をご検討ください）
  • GitHub Actions を使用していない場合（GitLab CI、CircleCI などをご検討ください）
  • AWS ECS/EKS、Google Cloud Run、Azure Container Instances にデプロイしたい場合（別のワークフローを使用します）

基本パターン

ステップ 1：情報を収集する

対話形式で次の情報を尋ねます。port（コンテナ内のポート。デフォルトは 3000）、host_port（外部に公開するポート。デフォルトは port と同じ）、env_file（サーバー上の env ファイルのパス。任意）。

プロジェクトの種類を自動検出します。package.json があれば Node.js と判定します（現在サポートしているプロジェクトの種類はこれだけです）。既存の Dockerfile がある場合は生成をスキップします。

ステップ 2：Dockerfile を生成する（必要な場合）

最適化された Node.js 用 Dockerfile を生成します。マルチステージビルド、非 root ユーザー、ヘルスチェックを含みます。テンプレートは templates/Dockerfile.nodejs を参照してください。

ステップ 3：ワークフローを生成する

templates/docker-deploy.yml からワークフローを生成し、{{PORT}}（コンテナのポート）、{{HOST_PORT}}（外部ポート）、{{ENV_FILE}} の各変数を置換します。

build-and-push ジョブ： GHCR にログイン → Buildx でビルド → プッシュ（タグ：latest + sha）→ GHA キャッシュ

deploy ジョブ： SSH 接続 → イメージをプル → 古いコンテナを停止 → 新しいコンテナを起動（env ファイルに対応）→ 古いイメージをクリーンアップ

ステップ 4：Secrets の設定を案内する

GitHub Settings → Secrets で DEPLOY_HOST、DEPLOY_USER、DEPLOY_SSH_KEY（サーバーの秘密鍵）を設定する必要があることをユーザーに伝えます。

セキュリティ：パスワードではなく SSH key を使用します（パスワードログインは総当たり攻撃のリスクがあり、CI に平文で保存されます）。サーバーがパスワード認証のみをサポートしている場合は、password: ${{ secrets.DEPLOY_PASSWORD }} に変更できますが、おすすめしません。

クイックリファレンス

/docker-build-deploy
/docker-build-deploy --port 8080
/docker-build-deploy --port 8080 --env-file /opt/app/.env
パラメーター説明デフォルト値
--portコンテナ内のアプリケーションポート3000
--host-portサーバーで外部に公開するポート--port と同じ
--env-fileサーバー上の env ファイルのパス空

よくある間違い

間違い正しい方法理由
latest のみのタグを使用するlatest と ${{ github.sha }} の両方をタグ付けするロールバックが容易になります
packages: write 権限を設定しないpermissions: packages: write を宣言するGHCR へのプッシュに必要です
deploy でコンテナの存在を確認しない先に docker stop と docker rm を実行するポートの競合を防ぎます
古いイメージをクリーンアップしないデプロイ後に docker image prune -f を実行するディスク容量を確保します
Dockerfile で root として実行するUSER node または非 root ユーザーを追加するコンテナセキュリティのベストプラクティスです
Secrets を workflow にハードコードする${{ secrets.XXX }} を使用して参照するシークレットが漏えいするリスクがあります
Docker BuildKit のキャッシュを設定しないGitHub Actions のキャッシュを使うように cache-from / cache-to を設定する毎回すべてをビルドすると時間がかかりすぎます
ビルド失敗後のロールバックを処理しないデプロイ後にヘルスチェックを検証するデプロイに失敗すると、誤ったバージョンが公開される可能性があります
パスワードで SSH デプロイするSSH key（DEPLOY_SSH_KEY）を使用するパスワード総当たり攻撃のリスクが高いためです
サーバーのアーキテクチャと異なるプラットフォームを指定するサーバーのアーキテクチャに合わせて linux/amd64 または linux/arm64 を指定する。マルチプラットフォームビルドの場合は linux/amd64,linux/arm64 と記述する対象アーキテクチャが一致しないと、実行に失敗します

コメント

Markdown 対応