mcpField
R
render-docker

render-docker

github.com/render-ossクラウド・DevOps90397 回インストール今日更新
リポジトリ

render-docker について

render-docker は、Render で Docker サービスをデプロイする開発者向けのスキルです。イメージのビルドと取得、Blueprint 設定、レジストリ認証情報、セキュリティ、デプロイ方法を扱います。

主な機能

  1. 01runtime: docker と runtime: image の設定
  2. 02Dockerfile のパスとビルドコンテキストの指定
  3. 03プライベートレジストリ認証情報の利用
  4. 04マルチステージビルドとシークレットの指針
  5. 05レイヤーキャッシュとイメージ内容の最適化
  6. 06Render のデプロイ動作の確認

活用シーン

  1. 01Blueprint で Render の Docker 実行方式を選択
  2. 02プライベートなベースまたは事前ビルド済みイメージの設定
  3. 03ビルド用シークレットのイメージレイヤーへの混入防止
  4. 04イメージの縮小とビルドキャッシュの改善

インストール

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

$npx skills add https://github.com/render-oss/skills --skill render-docker

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

同梱ファイル

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

references/
deployments.md
dockerfile-patterns.md
optimization-guide.md
registry-setup.md

詳細

Render の Docker デプロイ

Render は Docker のビルドに BuildKit を使用します。カスタムランタイムをサポートするすべてのコンピューティングサービスでは、runtime: docker（リポジトリ内の Dockerfile からビルド）または runtime: image（ビルド済みイメージをプル。Render 上で Dockerfile のビルドは行いません）を使用できます。より詳しいパターンとコピーして使えるテンプレートは references/ にあります。

使用する場面

  • Render サービス用の Dockerfile の作成またはデバッグ
  • Blueprint で runtime: docker と runtime: image のどちらを使うかの選択
  • プライベートベースイメージまたはビルド済みイメージとレジストリ認証情報の設定
  • マルチステージビルド、ビルド引数、シークレット、レイヤーキャッシュ
  • Render 上のコンテナーイメージのパフォーマンスとセキュリティの強化

Blueprint の作成全般については、render-blueprints を参照してください。デプロイのエンドツーエンドの手順については、render-deploy を参照してください。

ビルド済みまたは事前ビルド済みのイメージをデプロイする前に、現在のトリガー、ライフサイクル、ヘルスチェック、シグナルの動作について references/deployments.md をお読みください。

Render の Docker ビルド

  • Render での Docker ビルドには BuildKit が使用されます。
  • runtime: docker：Render は、dockerfilePath、dockerContext、および任意の dockerCommand（イメージの CMD を上書き）を使用して、リポジトリからイメージをビルドします。
  • runtime: image：Render は image.url をプルします。リポジトリを使ったイメージのビルドは行いません。レジストリがプライベートの場合は、image.creds.fromRegistryCreds.name を設定してください。

Blueprint の設定

フィールド役割
dockerfilePathDockerfile へのパス（デフォルトは ./Dockerfile）
dockerContextビルドコンテキストのディレクトリ（デーモンに送信する内容）
dockerCommandイメージのビルド後にコンテナーの CMD を上書きします
image.urlruntime: image 用のイメージ参照（registry/repo:tag または digest）
image.credsプライベートなビルド済みイメージ用の、ダッシュボードに保存された認証情報の参照
registryCredentialruntime: docker で使用するプライベートベースイメージ用の、ダッシュボードに保存された認証情報の参照

設定例（値は説明用です）：

services:
  - type: web
    name: api
    runtime: docker
    region: oregon
    plan: starter
    dockerfilePath: ./Dockerfile
    dockerContext: .
    dockerCommand: node server.js
    envVars:
      - key: PORT
        value: 10000

runtime: image の場合は、以下の レジストリ設定に従って image.url と、必要に応じて image.creds を設定してください。

マルチステージビルド

本番環境での使用を推奨します。 コンパイルと依存関係のインストールには builder ステージを使用し、成果物とランタイムファイルのみをコピーする最小限の runner ステージを用意します。メリットは次のとおりです。

  • イメージが小さくなり、プルが高速になります
  • 最終イメージに含まれるツールとシークレットが減り、攻撃対象領域が小さくなります
  • ビルド時の依存関係と実行時の依存関係を明確に分離できます

言語別のテンプレートについては、references/dockerfile-patterns.md を参照してください。

ビルド引数とシークレット

重要： シークレットを ARG で渡さないでください。 ビルド引数はイメージのレイヤーに保存され、イメージの履歴または中間レイヤーから復元される可能性があります。

  • アプリケーションのシークレットには、ランタイム環境変数（Render の環境変数／シークレットファイル）を優先して使用してください。
  • ビルド時のシークレット（プライベートパッケージフィードなど）には、ARG ではなく Docker BuildKit のシークレットマウント（RUN --mount=type=secret,...）を使用してください。

機密情報はすべて、ビルド引数ではなく、ランタイムまたは BuildKit のシークレットマウントとして扱ってください。

レジストリの設定

プライベートなベースイメージ（runtime: docker の場合）またはビルド済みイメージ（runtime: image の場合）には認証が必要です。

  • Render Dashboard の Registry Credentials に認証情報を保存します。
  • runtime: docker の場合、プライベートなベースイメージの認証情報を registryCredential.fromRegistryCreds.name で参照します。
  • runtime: image の場合、プライベートなビルド済みイメージの認証情報を image.creds.fromRegistryCreds.name で参照します。

一般的なレジストリ（Docker Hub、GHCR、ECR、Google Artifact Registry など）に対応しています。プロバイダーごとの手順については、references/registry-setup.md を参照してください。

ビルド済みイメージのサービスは、変更可能なレジストリタグの参照先が変わっても、自動的にはデプロイされません。新しいイメージを公開した後、Dashboard、サポートされている API、またはデプロイフックの仕組みを使って、手動でデプロイを開始してください。各デプロイで明確なアーティファクトを指定できるよう、変更できないタグまたはダイジェストを使用してください。トリガーと検証の手順全体については、references/deployments.md を参照してください。

レイヤーキャッシュ

  • Render はビルド間でDocker レイヤーをキャッシュします。変更頻度の低いレイヤーが先になるように、Dockerfile の命令の順序を調整してください（references/optimization-guide.md を参照）。
  • タグとキャッシュ： latest などの変更可能なタグは、古いキャッシュ済みイメージに解決されることがあります。ダイジェスト（repo/image@sha256:...）やバージョン固定（v1.2.3）など、変更できない参照を使用してください。

プラットフォーム固有の仕様

  • Render のビルド環境は linux/amd64 です。本番イメージでは、他のアーキテクチャを前提としないでください。
  • ポートのバインドはネイティブサービスと同じです。HTTP は 0.0.0.0:$PORT にバインドしてください（Render が PORT を設定します）。
  • ヘルスチェックでは、references/deployments.md に記載されているものと同じプラットフォーム動作が適用されます。
  • Render のシークレットファイルは /etc/secrets/ に配置されます。イメージ内で明示的にコピーまたはマウントしない限り、コンテナ内でリポジトリルートのシークレットパスに依存しないでください。

.dockerignore と起動コマンド

  • .dockerignore を常に整備し、node_modules、.git、.env、ビルド成果物、ログ、OS の不要ファイルを除外してください。これにより、コンテキストのアップロード時間を短縮し、ローカルファイルがレイヤーに漏れるのを防げます。一覧と理由については、references/optimization-guide.md を参照してください。
  • カスタム起動コマンド： 複数のシェル手順が必要な場合は、例のように単一のシェル形式を使用してください。/bin/sh -c 'set -e; ./migrate && exec node server.js'（アプリがシグナルを受け取り、適切にシャットダウンできるよう、exec の使用を推奨します）。

参考資料

ドキュメント内容
references/dockerfile-patterns.mdマルチステージテンプレート（Node、Python、Go、Ruby、Rust、静的サイト）
references/registry-setup.mdDocker Hub、GHCR、ECR、Artifact Registry、および Blueprint の設定
references/optimization-guide.mdレイヤーの順序、.dockerignore、BuildKit のキャッシュマウント、デバッグ
references/deployments.mdデプロイのトリガー、ライフサイクル、ヘルスチェック、シャットダウン、検証

関連スキル

  • render-deploy — デプロイの流れ、Blueprint と Dashboard の比較、運用手順
  • render-blueprints — render.yaml のスキーマ全体、設定、検証
  • render-web-services — Web サービスの動作、ヘルスチェック、HTTP のエッジケース

現在のドキュメントの取得

このスキルで最新の Render ドキュメントを参照するよう指示された場合は、次の手順に従ってください。

  1. 利用可能な URL 取得ツールまたは curl などの HTTP クライアントを使って、リンク先の Markdown ドキュメントを直接取得します。ウェブ検索の要約でドキュメントを代用しないでください。
  2. 取得が成功し、期待したドキュメントが返されたことを確認してから、内容を読みます。ファイルを保存したり、そのパスを表示したりするだけでは不十分です。
  3. リクエストに失敗した場合、またはツールで Markdown のレスポンスを読み取れない場合は、リンク先の HTML 版を開いて読みます。
  4. どちらの形式も取得できない場合は、最新の参照資料を利用できないことを明示し、スキル内のトピック固有の代替手順に従います。同梱のガイダンスは、変わらない制約に限って使用し、変更される可能性のあるプラットフォームの詳細を推測しないでください。

複数の参照資料が必要な場合は、それぞれにこの手順を適用し、確認できたドキュメントと、取得できなかったドキュメントを区別してください。

コメント

Markdown 対応