対象のコメント

Railsの開発環境をコンテナ内に作るための PmRails v2.0 をリリースしました。

また、PmRailsと同等の開発スタイルをDockerで利用できる DkRails も新しく公開しました。

• PmRails — Podman版
• DkRails — Docker版

どちらも、ホスト環境にRubyやRailsをインストールせずにRailsを開発することを目的としたツールです。

PmRails v2.0

PmRails v1では、RailsをPodmanコンテナ内で実行するための比較的小さなツールとしてスタートしました。

v2では機能を大幅に拡張し、Railsアプリの新規作成から日常的な開発まで、より一通りの作業を扱えるようになりました。

主に次の3つの使い方ができます。

1. rails newだけをコンテナ内で実行する
2. 単一のRailsコンテナで開発する
3. Composeを使ってRails、DB、Seleniumなどを組み合わせて開発する

既存のRailsプロジェクトに対しては、pmrails-initで標準的な設定ファイルを生成できます。

Compose環境ではSQLite3に加え、PostgreSQL、MySQL、MariaDB系の構成や、Seleniumを使ったsystem testにも対応しています。

独自のDockerfileやCompose設定も利用できるため、簡単な構成から始めて、必要に応じてプロジェクト固有の環境へ拡張できます。

詳しい変更内容は以下にあります。

PmRails v2.0.0 Release

Docker版のDkRailsも公開

これまでPmRailsはPodmanを前提としていました。

今回、同じ考え方とほぼ同じ操作体系をDockerで利用できる DkRails を公開しました。

たとえば、

pmrails-cmpexe bin/rails test

に対応するDkRailsのコマンドは、

dkrails-cmpexe bin/rails test

です。

そのため、

PodmanならPmRails、DockerならDkRails

という形で、利用するコンテナ環境に応じて選べます。

DkRails v2.0.0 Release

AIを使った開発にも

最近では、Codexなどのcoding agentにコードの編集だけでなく、テストやRailsコマンドの実行まで任せる機会が増えてきました。

このとき、AIにホスト上のコマンド実行を広く許可するのではなく、Railsの実行をPmRails/DkRails経由に寄せるという使い方ができます。

たとえばCodexでは、.codex/rules/default.rulesに次のようなルールを書くことで、よく使うRailsコマンドだけを自動許可できます。

prefix_rule(
    pattern = [
        "pmrails-cmpexe",
        "bin/rails",
        ["test", "test:system", "routes", "zeitwerk:check"],
    ],
    decision = "allow",
    justification = "Allow common Rails development commands through PmRails.",
)

これにより、AIにはテストなどの日常的なRails操作を任せながら、その実行環境をコンテナ側に置くことができます。

一方、runnerやconsole、任意のRake taskなど、より広い操作能力を持つコマンドは、この例では自動許可していません。

もちろん、コンテナは完全なセキュリティsandboxではありません。bind mountされたファイルや、コンテナからアクセス可能なDB・ネットワークなどには影響できます。

それでも、

RailsはAIにかなり自由に触らせる。ただし、アプリケーションの実行場所はコンテナに寄せる。

という境界を自然に作れるのは、AIを使った開発でも便利だと感じています。

PmRails/DkRailsはAI専用のツールではありませんが、もともとRailsの実行環境をホストから分離するために作っていたことが、AI coding agentを使う上でも役立つ形になりました。

Links

• PmRails
• PmRails v2.0.0 Release
• DkRails
• DkRails v2.0.0 Release