Others

要点

Docker Compose の compose.yaml でサービス名を付ける際は、HTTP での接続先となるコンテナのサービス名には app や dev といったトップレベルドメイン（TLD）として実在する文字列を使わないほうが安全です。

具体的な対策

HTTP で接続するサービス（コンテナ）には、ハイフン（-）を用いて複数の単語を組み合わせた名前をつけるのが、簡単な解決策です。

• 避けるべきサービス名の例：app, dev
• 推奨されるサービス名の例：rails-app, web-server

なぜエラーになるのか

Docker Compose のネットワーク内では、サービス名で名前解決をして他コンテナへアクセスできます。そのため、Selenium コンテナ内のブラウザから http://app/ のようにアクセスする設定にすることがあります。

しかしブラウザは、その app を Docker 内部の名前としてではなく、通常のホスト名として扱います。 app や dev は実在の TLD であり、しかも HSTS（HTTP Strict Transport Security）を強制する対象なので、ブラウザは http://app/ を https://app/ に書き換えます。 接続先が HTTPS 非対応なら、結果として ERR_SSL_PROTOCOL_ERROR や Are you trying to open an SSL connection to a non-SSL Puma? のようなエラーになります。

一方、rails-app のように、TLD と一致しない名前にすれば、HSTS 強制の対象から外れ、HTTPS に書き換えられないため、エラーを防ぐことができます。

背景：何が起きているか

Docker の compose.yaml の services で定義したサービス名は、Docker ネットワーク内で他コンテナへアクセスする際のホスト名として使えます。ここでのホスト名とは、http://example.com/ の example.com に当たります。

サービス名にドット（.）が含まれていない場合、単一ラベルのホスト名となり、ブラウザはその名前を TLD として扱います。例えば、app というサービス名は、app という TLD のみからなるホスト名として認識されます。

TLD のみのホスト名のうち、app や dev は HSTS 強制の対象となっており、HSTS プレロードリストなどの仕組みにより、HTTPS 接続が強制されます。そのため、http://app/ という HTTP での接続になるよう設定しても、ブラウザは強制的に https://app/ という HTTPS での接続へと書き換えて接続しようとします。

結果、app や dev のような HSTS が強制される名前を持つサービス（コンテナ）に対して、Selenium コンテナ内のブラウザは、HTTP で接続するよう設定されていても、HTTPS で接続してしまいます。 さらに、接続される側のコンテナが HTTPS に対応していない場合、接続がエラーとなります。

このように、E2E テストやシステムテストでは「ブラウザがどう解釈するか」は無視できない事項です。 コンテナ間疎通の都合だけで名前を決めるのではなく、ブラウザが特殊な扱いをする名前ではないか、という観点も持っておくとトラブルを減らせます。

注意点

• TLD、及び、HSTS が強制されるホスト名は追加が続いています。そのため、将来のトラブルを防ぐ観点では、現状でトラブルになる名前だけでなく、今後トラブルになりそうな名前全般を避けたほうが無難だと考えられます。
• HSTS はホスト名ベースで効き、ポート番号では回避できません。つまり http://app:3000/ のような URL でもエラーになり得ます。
• ホスト名にドットを含めることは、本件の SSL エラーの確実な回避策とはなりません。なぜなら、HSTS 強制の対象となっているホスト名としては、TLD のみのホスト名だけではなく、facebook.com や www.amazon.com といったドットを含むホスト名も多数存在するためです。

接続エラーに遭遇した状況

compose.yaml において、selenium/standalone-chromium イメージの Selenium コンテナからサービス名が app のコンテナへ HTTP で接続する設定をしたところ、以下のエラーが発生しました。

2026-03-25 05:37:53 +0000 HTTP parse error, malformed request: #<Puma::HttpParserError: Invalid HTTP format, parsing fails. Are you trying to open an SSL connection to a non-SSL Puma?>
[Screenshot Image]: /x/tmp/screenshots/failures_test_should_destroy_Article.png
E

Error:
ArticlesTest#test_should_destroy_Article:
Selenium::WebDriver::Error::UnknownError: unknown error: net::ERR_SSL_PROTOCOL_ERROR
  (Session info: chrome=145.0.7632.109)
    test/system/articles_test.rb:38:in 'block in <class:ArticlesTest>'

なお、サービス名を app から rails-app に変更したところ、無事意図したとおりに動くようになりました。 HSTS 強制の対象となる TLD（app）との一致を回避した結果、ブラウザが HTTPS へ強制的に書き換えなくなったためと考えられます。

参考資料

• .devドメインと.appドメインがHTTPSを強制する仕組み： https://qiita.com/tomoyk/items/187aa6723e80e1bba675
• Google Chrome implementing HSTS breaks dockerized application testing: https://medium.com/@alex.skrypnyk/google-chrome-implementing-hsts-breaks-dockerized-application-testing-55120e6d67bc

リリースの概要

• 新コマンド pmrails-new-plus : アプリの作成・gem のインストール・.gitignore の更新を1ステップで自動化します。
• プロジェクトローカルなruntimeディレクトリ .pmrails/var/ : gem・キャッシュ・設定ファイルなどをプロジェクトごとに隔離して管理するようになりました。
• SELinux / Fedora Immutable サポート : 全コマンドに Podmanの --userns=keep-id オプションを追加しました。

アップデート時の注意：ランタイムディレクトリ変更のため、pmbundle installの再実行が必要です。

リリースノートと変更履歴はGitHubで確認できます： https://github.com/wakairo/pmrails/releases/tag/v1.1.0

Codex（OpenAIのコーディング・エージェント）をdevcontainer（開発用コンテナ）の中に閉じ込めて動かすのは、 セキュリティの確保もできて、なかなか良いアイデアなのではと思いました。 ところが、vscodeで実際に試してみたところ、Codexのセキュリティの仕組みと絡んで、不都合な挙動があったので、 このやり方は公式にサポートされるまでは様子見が良いかなと今は思っています。

確認したこと

まずvscodeでdevcontainerを起動しました。 設定ファイル.devcontainer/devcontainer.jsonの中身は以下の通りです。

{
        "name": "Ruby",
        "image": "mcr.microsoft.com/devcontainers/ruby:3-3.4"
}

次に、Codex拡張をインストールしました。 その次に、Codexにソースファイルの一部を変更する指示を出したところ、 apply_patchが上手くいかないのでsedなどを代わりに使うという返答で、 変更前後のdiffが見づらい形になりました。

なお、devcontainerの設定で指定するimageは以下の2つも試しましたが、 同じ現象に遭遇しましたので、特定のイメージでのみ発生する現象ではありません。

• ruby:3.4（Rubyの公式イメージ）
• ghcr.io/openai/codex-universal:latest（OpenAIが公開している参考Dockerイメージ）

apply_patchが失敗する背景

Codexが言うには、apply_patchはbwrapという一種のコンテナの中で動かす仕組みらしく、 devcontainerというコンテナの中でbwrapというコンテナを動かす、 つまり、コンテナの中でコンテナを動かすのに失敗しているらしいです。 具体的には、devcontainerの中でbwrapのコンテナのために新しいnamespaceを作ろうとして、 permissionの問題に遭遇しているとのこと。

Codexがbwrapを使うのはセキュリティを高めるためだと思いますので、 安易な設定変更などでapply_patchを出来るようにするのは、 セキュリティ上のリスクがあると見ています。

基本はダブルクォーテーション付きの"$@"

シェルスクリプトに渡された全ての引数を、そのシェルスクリプト内で別のコマンドに引き渡す場合は"$@"を使います。 例えば、以下のように記述します。

grep -n cat "$@" | sed "s/cat/__CAT__/g" | tee -a ~/foo.log

"$*"や$@（ダブルクォーテーションなし）を使うと、'foo bar'のようなスペースを含む引数がスペースで分割されて壊れてしまいます。

shコマンドに渡すときはsh -c '..."$@"...' -- "$@"

1つの実行コマンドしか受け付けないsudoやssh、docker runなどで、 複数コマンドの実行などの複雑な処理を行いたいときに活躍するのがsh -c '...'です。

シェルスクリプト内でsh -c '...'にすべての引数を渡したいときは、sh -c '..."$@"...' -- "$@"と記述します。 例えば、以下のように記述します。

sudo sh -c 'grep -n cat "$@" | sed "s/cat/__CAT__/g" | tee -a /var/log/foo.log' -- "$@"

先頭のいくつかの引数を取り出して残りを渡す場合（おまけ）

検索ワードのような「固定の引数」と、複数のファイルのような「可変長の引数」が混在しているケースです。 これらをまとめてsudoやssh、docker runなどに投げたい場合は、 -cオプションの文字列内でshiftを使います。

以下は、第一引数が検索文字列、第二引数がその検索文字列を置き換える先の文字列、 第三引数以降はこの検索と置換の対象となるファイル（複数個指定可）となっている例です。

sudo sh -c 'pattern="$1"; replace="$2"; shift 2;
            grep -n "$pattern" "$@" |
            sed "s/$pattern/$replace/g" |
            tee -a /var/log/foo.log' -- "$@"

ruby-version:が無いときのデフォルト動作では、まず.ruby-versionを読みに行くのですね。知りませんでした。

ちなみに少し調べてみたら、2020年のv1.3.0のときから既にそういう仕様のようですね。

それから、railsの新規アプリのGitHub Actionsの設定も現在はruby-version:を省略するようになっていますね。

setup-rubyのREADMEに以下の記述がありますので、 ruby-version:を設定ファイルにあえて書かないことで、.ruby-versionに設定することも可能です。

If the ruby-version input is not specified, .ruby-version is tried first, followed by .tool-versions, followed by mise.toml

設定ファイルをできるだけ簡潔にしたいなら書かない選択もありですし、逆に分かりやすさを重視するなら明示的に書くのも一案です。どちらを取るかは悩ましいところですね。

以下のコマンドの実行などで、Podに対応するKubernetes YAMLファイルを一度用意しておけば、

podman generate kube mypod -f=mypod.yaml 

replaceオプションを利用した以下のコマンドで1つで、PodとそのContainerの停止から削除、再生成までを一度に行えます。

podman play kube mypod.yaml --replace

Imageの更新について

Kubernetes YAMLファイル内でimagePullPolicy:を指定していないlatestタグのImageは、 replaceを利用した前述のコマンドの実行により、Imageの更新（pull）も併せて行われます。

latest以外のタグのImageが更新された形でPodを再生成したい場合は、 以下のコマンドでImageを更新してから、replaceを利用した前述のコマンドを実行します。

podman pull example/image:tag

参考情報

• https://docs.podman.io/en/latest/markdown/podman-kube-play.1.html#replace
• https://github.com/containers/podman/issues/4880
• https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting

PmRails 1.0.0をリリースしました。

PmRailsは、Ruby on Railsのアプリケーションのテストまたは開発をするためのツールセットです。 RailsやRailsが依存するものをローカル環境にインストールすることなく使用できます。 Podmanを活用し、Railsプロジェクトのための隔離されたコンテナ環境を作成します。

ご不明な点や質問などございましたら、このTopicにお気軽にお寄せ下さい。できる範囲で回答いたします。

BlueStacks 5を立ち上げてしばらく経つと動かしていたアプリが勝手にシャットダウンする現象に遭遇し困っていた。 ネットで少し調べてみて、「Google Playストア」アプリの「ストレージを消去」したところ、この現象が起きなくなった。 ちなみに、ストアアプリやシャットダウンしていた方のアプリでキャッシュ削除をしたりもしたので、 このキャッシュ削除の方が有効打になった可能性もある。以上ご参考まで。

バージョン

BlueStacks App Player 5.21.600.1019 P64

参考

https://www.reddit.com/r/BlueStacks/comments/1h6lqje/bluestacks_app_interface_freezing_and_google/

GitHub Actionsの設定ファイルでsetup-rubyを使う時に、 以下のようにruby-versionのところで.ruby-versionと指定すると、 GitHubレポジトリからチェックアウトされたプロジェクトの中にある .ruby-versionという名前のファイルで指定されているrubyのバージョンが GitHub Actionsのsetup-rubyで使われます。

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: .ruby-version
          bundler-cache: true

jobsが複数あって、同じバージョンで複数回setup-rubyをしているときなどには、バージョン記述の重複がなくなって有用だと思います。

（参考）

この指定方法は、railsの新規アプリのGitHub Actionsの設定で利用されています。