【テックブログ】バックエンドエンジニアがPCをM2Proに変更してみた

数ヶ月前に、勤務している会社でPCのリプレイス案内がきました。 ざっと、このようなリプレイスになります

  • 旧:MacBookProの15インチ(Intel CPU)
  • 新:MacBookProの14インチ(Apple Silicon)※ M2 Pro

今回は、Railsアプリのバックエンドを担当している場合に起こりうる影響を確認してみました。

Railsコンテナが、nokogiriのエラーで立ち上がらない問題

公式のRubyイメージを元にしてDockerfileを作成している場合、おそらくnokogiriでエラーが発生します。

$ docker-compose build --no-cache
(省略)
> ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:

直接の原因は、Rubyイメージにプリコンパイルされているnokogiriが参照したいファイルが足りていないからのようです。 ただもちろんこれは Apple Silicon に変更したからでしょう。

結論から言うと、bundle の platform を ruby に強制することで改善します。 自分はDockerfileの記述に下記を追加しました。

RUN bundle config set force_ruby_platform true 

bundle の platformは、特に指定しない限り、ホストPCのプラットフォームになります。 つまり、M2Proだと arm64-darwin-22 という名称のプラットフォームとして、bundle は動作します。 おそらくこのplatformだとインストールされないファイルがnokogiriには必要なのだと思われます。

docker-compose up できない問題

Railsアプリ、皆さんの開発環境ではどのデータベースを利用していますでしょうか?多くの方が MySQLPostgreSQL かと思います。

自分は MySQL を利用していて、docker-compose.yml ではmysql:8.0.28 を指定していました。 その環境で docker-compse up を実行した時に下記のエラーに遭遇しました。

docker-compose.ymlを下記のように修正し、MySQLは無事に立ち上がるようになりました。

$ docker-compose up
(省略)
> no matching manifest for linux/arm64/v8 in the manifest list entries

これは、mysql:8.0.28 のイメージに、AppleSilicon(arm64)に対応したものが存在しませんでした。というエラーです。 どうしてこのような動きになるかというと、イメージの取得はホストPCのプラットフォームに依存して行われるからです。 そのため、明示的にプラットフォームを指定する必要があります。

db:
    image: mysql:8.0.28
    platform: linux/x86_64 # 追加

その他トラブルシュート

もし改善されない場合、例えば Dockerfile がマルチステージビルド形式で記載されていて、記述が意図せz反映されていないなどを疑った方がいいかもしれません。

最後に

実は本業では Github Codespaces を利用しているため、PCリプレイスの影響は全くありませんでした(笑) M2 Proめちゃくちゃいいです。キーボードはタイプしやすいし、画面は綺麗で動作もサクサク。そして電池の持ちがすごいです!