ローカル開発用Docker環境をDocker DesktopからOrbstackに変えてみた。【序】
先般の記事にした通り、ローカル開発環境においてもしっかりLinuxが見えていて、CUIで自由に操作できないと気持ち悪いという性癖により、長らくVagrantやUTMを使用してRHEL系のCentOS〜RockyLinux上で開発してきたのだけれど、最近になってようやくLaravelやらReact+NextJSなんかも触り始めたり、いろんな環境を作る必要性なんかもあって、もしやDockerの方が楽なんじゃないかと思い始めました。
ほんで、LAMP環境についてはdocker-compose-lampというのを使ってみた。超速で環境構築できた。スゲーww
ほんで、環境を丸ごとGithubのプライベートリポジトリにpushするようにしたので、Mac miniと環境やデータを共有するのも楽になった。
ということで、やっっっっっっっとDockerの良さを体感するに至ったわけだが(今更感ハンパない…)、なんだかんだ調べていると、Docker Desktopというこのアプリケーションがすこぶるクソらしい。いや自分自身はそんな感じはしないんだけど、CPUやメモリといったリソースの使い方がクソらしく、まあとにかく重いらしい。
ほんで、ふと偶然みた記事で「マジで、Mac OSでDocker動かすことにこだわるなら、せめてDocker DesktopやめてOrbstackかColima使えよ。」 とかいうコメントがあり、Redditのこんな記事が紹介してあったので日本語に翻訳して読んでみた結果、Orbstackというツールに興味が出てきた。
そういうわけで、ChatGPTに相談してみた結果、docker-compose-lamp.ymlはおそらくそのまま使えるらしいし、他のやりたいことも問題なくできそうなのでやってみることにします。
以下、相談内容を最後にまとめてもらったものを貼って今回はサヨナラ。
ローカル開発環境構築に関する検討メモ
Orbstack の導入について
- Orbstack は Docker Desktop の代替として利用可能。
- Docker Desktop よりも軽量・高速でリソース効率が良い。
- 新規構築で既存データを引き継ぐ必要がなければ、デメリットは特にない。
- 今後のローカル開発環境は Orbstack ベースで構築する方針が良さそう。
外部SSDへのデータ保存
-
案件のソースコード(
www/
以下)を外部SSDに置くことは可能。シンボリックリンクでの運用
-
複数のマシンで統一パスを保つために、シンボリックリンクを利用するのが便利。
-
例:
ln -s /Volumes/SSD/lamp ~/lamp
こうすればどの Mac でも
~/lamp/docker-compose-lamp/www
でアクセスできる。
注意点
-
ディスク名の固定
- macOS は
/Volumes/<ディスク名>
にマウントする。 - ディスク名が変わるとリンク切れになるため、開発用 SSD の名前は固定しておく。
- 同名ディスクを複数接続すると
SSD 1
のように変わるので注意。
- macOS は
-
フォーマット形式
- Mac 専用なら APFS 推奨。
- exFAT は Windows 互換性はあるがパーミッションが曖昧になる。
-
ユーザー権限
- 複数の Mac で使う場合、ユーザー名が異なるとファイル所有者が変わることがある。
-
必要に応じて以下で調整する:
chown -R $(whoami) ~/lamp chmod -R 777 ~/lamp
複数 Mac での利用
- 外部 SSD を共有し、シンボリックリンクを揃えれば どの Mac でも同じ環境で開発可能。
-
想定運用フロー:
- SSD を
/Volumes/DevSSD
に接続。 -
各 Mac で
ln -s /Volumes/DevSSD/lamp ~/lamp
を実行。
- docker-compose やスクリプトは
~/lamp
を参照するので、環境差異を気にせず使える。
- SSD を
monorepo での案件管理
- 1つの LAMP 環境の
/var/www/html/
配下に複数案件を置く想定なら monorepo 一択。 - 案件ごとに別リポジトリにする必要はなく、LAMP環境も含めて1つのリポジトリで管理する。
ディレクトリ構成例
docker-compose-lamp/ ← このリポジトリ1つで全部管理
├─ docker-compose.yml
├─ config/
│ └─ vhosts/
├─ www/ ← 案件を全部ここに置く
│ ├─ projectA/
│ │ └─ public\_html/
│ ├─ projectB/
│ │ └─ public\_html/
│ └─ projectC/
│ └─ public\_html/
└─ scripts/
└─ new-project.sh
Git 管理方針
-
管理対象にするもの
docker-compose.yml
config/
(vhost 設定など)scripts/
(新規案件スクリプト)- 各案件のソースコード(
www/projectX/public_html
)
-
Git で除外するもの
- WordPress コアファイル(
wp core download
で再取得可能) - アップロードファイル(
wp-content/uploads
) - Composer / npm などの依存ディレクトリ(
vendor/
,node_modules/
)
例:
www/.gitignore
- WordPress コアファイル(
*/public_html/wp
*/public_html/wp-content/uploads
*/public_html/vendor
*/public_html/node_modules
---
## メリット
- **シンプルな構成**: 1つのリポジトリで環境と案件をまとめて管理可能。
- **複数Macで統一環境**: git + 外部SSDリンクで環境差分を減らせる。
- **スクリプトで自動化**: ./new-project.sh foo wp
のように即案件追加可能。
---
## 次に考えること(今後の課題)
- 本番環境へのデプロイ方法(丸ごと rsync / 個別案件ごと / CI/CD 導入 など)
- データベースの扱い(init.sql で初期化するか、dump を git 管理するか)
ディスカッション
コメント一覧
まだ、コメントがありません