その他

リリースの概要

• 新コマンド 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の設定で利用されています。

PostgreSQLに関した練習やテスト、実験などを行うときにPostgreSQLが動いている一時的な環境が欲しくなるときがあります。 PostgreSQLイメージとPodmanを利用すると、特定バージョンのPostgreSQLに関する一通りの操作ができる一時的なコンテナ環境を用意することが出来ます。

以下にコンテナ環境の作成、利用、削除の流れと方法を示します。

コンテナ環境の作成

以下の3つのコマンドを実行することで、PostgreSQLのコンテナ環境を作成し、クライアント側のコンテナのbash環境に入ることが出来ます。

なお、コマンド内の「16」のところはPostgreSQLのメジャーバージョンに相当しますので、ご利用になりたいバージョンの数に変更してください。 また、-v "$PWD":/x -w /xのオプションにより、ホストOSのカレントディレクトリにコンテナ内からもアクセス出来る状態でbashが立ち上がります。 したがって、実験などに利用したいファイルをカレントディレクトリに置いてから以下のコマンドを実行すればコンテナ内でもそのファイルを利用できますし、 コンテナ内で/xのディレクトリに作成したファイルはコンテナ環境を終了した後もホストOSのカレントディレクトリに残ります。

podman pod create --name tmp_pg
podman run --name tmp_pg-server --pod tmp_pg -e POSTGRES_PASSWORD=postgres -d postgres:16
podman run -it --rm -v "$PWD":/x -w /x --name tmp_pg-bash --pod tmp_pg postgres:16 bash

以下のようなプロンプトが表示されていれば成功です。クライアント側のコンテナのbash環境に入れました。

root@tmp_pg:/x#

クライアント側のコンテナのbash環境の利用

このbash環境では、psqlなどのPostgreSQLのコマンドを一通り利用することが出来ます。以下に例を示します。

PostgreSQLのターミナルを開く例：

psql -h localhost -U postgres -d postgres

バックアップファイルを作成する例：

pg_dump -Fc -h localhost -U postgres -d postgres -f backup.dump

バックアップファイルをリストアする例：

pg_restore --clean -h localhost -U postgres -d postgres backup.dump

クライアントのコンテナを終了しそのbash環境から退出する場合はexitコマンドで抜けられます。 また、退出後にもう一度クライアントを使いたくなった場合は、後述のコンテナ環境全体の削除をまだしていなければ、 以下の3つめのコマンドだけ実行すれば、クライアントのコンテナをもう一度作成しそのbash環境に入ることが出来ます。

podman run -it --rm -v "$PWD":/x -w /x --name tmp_pg-bash --pod tmp_pg postgres:16 bash

コンテナ環境全体の削除

以下のコマンドで、コンテナ環境全体の停止と削除が実行できます。

podman pod stop tmp_pg && podman pod rm tmp_pg