Archive for 9月, 2019

Laradockでホストマシンの変更が反映されない場合の対策

by codechord. 0 Comments

自分は、MacOSで、Laradockを使って開発環境を構築している。
その際に、ホストマシンの更新内容がコンテナ内に反映されず、悩まされた。

自分のようにハマったような例もあまりみかけず。
一応動作することが確認したので、その経緯・設定を書き残しておきます。
(詳しくは把握できていないのでご了承)

laradock/.envの次の行が原因とおもわれるのだが、

laradock/.env

# You may add flags to the path `:cached`, `:delegated`. When using Docker Sync add `:nocopy`
APP_CODE_CONTAINER_FLAG=:cached

次のようにいずれの設定に切り替えたとしても、状況は改善されなかった。

APP_CODE_CONTAINER_FLAG=:delegated
APP_CODE_CONTAINER_FLAG=:nocopy

最終的には、設定を解除すると正常に動作するようになった。

APP_CODE_CONTAINER_FLAG=

なお、ぐぐってみると、同期が遅い。というケースはあるようで、その場合はdocker-syncを使いrsyncの仕組みで同期すると早いとあります。
また、公式ドキュメントによると、docker-composeコマンドを使うのではなく、「laradock/sync.sh」コマンドにて起動するとdocker-syncが起動すると書かれています。
sync.shも、難しいことがかかれているわけではないので、見てみるとよいですが「laradock/sync.sh」、次のような処理になっています。

$ ./sync.sh up ~~~
▼実際の処理
$ docker-sync start
$ docker-compose up -d ~~~~~
$ ./sync.sh down
▼実際の処理
$ docker-compose stop
$ docker-sync stop

起動前にはdocker-syncを開始して、終了時にはdocker-syncを止めると、それだけですね。
ただ、ちょっと気になっているのは、終了時、「docker-compose down」しているのではなく、「docker-compose stop」している点。downだと、コンテナまで削除してくれるけど、stopだとサービスを停止するだけで、コンテナはのこったままになる。
コミットログを辿ってみると、意図的に、docker-compose downではなく、docker-compose stopしているよう。

Don't use docker-compose down to stop containers

This delete containers and volume too. 
Use docker-compose stop who only stop containers

うーーん、意図がわからない。

リファレンス本にもLaradockの事は触れられています。ただ、詳細にまでは触れられていないですね。