会社の環境をMacからWindows移行して感じたこと

今までの環境の経緯
私は30歳を超えてからIT業界へジョブチェンジを果たしました。
そこで、5年ほどWindowsの環境で開発をしていました。
ちなみにその時にはDockerはありません。WSLもありませんでした。
よって、Macで環境を作りやすいのはMacといわれておりました。
実際に環境を作ることが難しい(コマンドで実行できずひとつづつ手順書に従って環境を作っていました。)と感じていました。
それから4年ほどMacで開発を行っていました。
開発の中ではDockerなども使用しております。
なぜWindowsにしたのか?
今の職場に入ってから一時期プライベートでもMacを使っていましたが、WSLが使えるようになってからWindowsに戻ってきました。
それからプライベートでは主にLinuxを使うようになりました。
Macは環境がすごく良くて素晴らしく感じています。
今の職場はMacとWindowsを選べるのでチャレンジングなことがしたいと感じでWindowsにしてみたということが今回のMacからWindowsに移行したことの経緯です。
MacとWindowsの比較
ここからMacからWindowsにしてみて、気になったことをまとめていきます。
ツールバーが上か下か
ツールバーおよびアプリケーションのツールバーがWindowsとMacでは違います。
Windowsは下にあって画面を見下ろす形になっていて、Macはすべて画面上部に表示されています。
キーマップの違い
私としてはこれが一番影響が大きかったです。
WindowsのWinキーの配置にMacのCmdキーが来ます。MacはCmdキーでコピペするので、間違えて押してWindowsのアプリケーション一覧が表示されてげんなりします。
また、Macで便利だったのはキーマップツールが便利でした。
私はキーボードがいくつもあるので、キーボードごとにキー配置を変えたい。
Macだと上記のツールが使えて便利です。私はCapslockキーをCtrlキーにしています。
キーボードで設定がある場合は変更不要なので、キーボードごとにできて便利です。
Windowsだとこれです。ほかにもありますが、キーボードごとに設定できるものがありません。
よって、Macでやっていたことができないということになります。
開発環境
開発環境で違うのはやはり、WindowsだとWSL2を使うことです。
WSL2を使うことで、Macと同じように環境を作ることができます。
よいところと悪いところがあり、
よいところとしては、環境を作って壊してということが容易であることです。
わるいところは、所有権などの管理が面倒になってしまいがちです。
もう一つはファイルシステムの違いから、WindowsからWSLへの読み書きは遅かったりします。
Docker
MacのDockerについては、DockerDesktop が会社で利用時は料金がかかってしまうようになり、Colimaなどが必須となりました。
Colimaが不安定でということもあったり、コンテナにつなぐときに遅かったりします。
WSL2上ではDockerDesktopを使用せずにDockerを立ち上げることが可能で、気持ちコンテナにつなぐときは早く感じます。
また、上記でも挙げた所有権でうまくいかないことがあります。
まとめ
いろいろと書きましたが、特に両社で違いを感じるのはAppleシリコンを搭載したMacの持つArm系CPUの電池持ちとかではないのではないかと考えています。
MacのIntelCPUからAppleシリコンへの移行時に、電池持ちなどが改善されたのでWindowsも今後の製品ラインナップでArm系のPCが増えそうなのでそちらに期待していきたいです。
とりあえず1年ほど使用してみて追加で感じたことがあれば記事にしていきたいと思います。
Discussion
所有権の問題については、
https://zenn.dev/tazzae999jp/articles/2c235cc6f0e84d
で、記載した、aclfull.shを作業してるユーザのホームディレクトリの直下に作成して
~/aclfull.sh /example/path/localGitDir
のように打ち込みます
/example/path/localGitDir
が、直下に、「.git」があるローカルフォルダで、かつ、
コンテナからバインドマウントしているフォルダなどのルート位置にあたるフォルダだとします
そしたら、今作業してるユーザについて、
/example/path/localGitDirの配下、末端まで、「POSIX ACL」でフルアクセス可能になります
root所有のファイルや、フォルダでも、変更や削除が問答無用でできるようになります。
この結果、コンテナ側で作業して所有者がrootになったがゆえに、
そのファイルや、フォルダを対象にした操作でパーミッションエラーになってしまうことがなくなります。
本当は、ホスト側の作業ユーザと同じUID、GIDをコンテナ側に作成し、それでログインして作業するようにするのが綺麗なのは、わかってますが、そうなってないDockerfileが連携されて作業することになったとき、(原因は、権限問題がおきないMacユーザが気にしないから)
この方法でやるのが一番、楽です。
この「POSIX ACL」での簡単解決方式を世の中に広めたいと思ってます
<原因は、権限問題がおきないMacユーザが気にしないから>
はどういうことかというと、osxfs, FUSE, virtioFSなどで、ファイル共有で
バインドマウントする際に、Docker for Macは、コンテナがroot所有でも
ホスト側は、一般ユーザ所有で見えるらしいです。だから、権限問題がおきず
それ前提で、rootでログインし作業することが前提のDockerfileしか作らず、
それをLinux、WSL2を使ってるチームメンバーに対しても連携してきやがるという意味です。
この話をMacユーザにしても、ぜんぜん、話通じませんので
「POSIX ACL」のやり方で凌ぐのが、一番楽です。
上記は、直でdocker composeを使う話ですが
Devcontainersの環境を作る場合は、.devcontainer/devcontainer.json
に、common-utilsを入れることで、rootユーザでログインするDockerfileに対して
UID、GID=1000,1000のユーザを作成し、パスワードなしでsudoが使えるようにして
UID、GID=1000,1000のユーザで、VS Codeがログインする設定にできます。
Ubuntuの初期ユーザはUID、GID=1000,1000で、おそらく作られ
それで作業してれば、ホストとコンテナが同じユーザで作業することになり、
所有者のズレがおきません。Macは作業ユーザが500番代ですが、コンテナが1000:1000の所有者に
なっても、Docker for Macのバインドマウントはホスト側は、500番代の所有者に見えるため
権限問題おきません。結果的に誰も困らないため、このような方式で1000:1000で
Devcontainer側で作業することをMicrosoftは推奨してるようです。
この話も広く世の中に知れ渡って欲しいです。