ここリアごとの管理者
鯖缶のひとをフォローしがち。
HTLでエアリプ会話するの好きがち。
その他の生息地
@yuba@misskey.io
@yuba@nemudaru.uk
@yuba@misskey.04.si
@yuba@nagisa.town
@yuba@misskey.systems
docker-composeコマンドを叩くcronデーモンも、dockerコンテナ内で動かせないと思ってる。
でも、これが意外なところで引っかかってうまくいかないの。
ホストボリュームをマウントするよう書いているんだけど、マウント元は相対ディレクトリで書いてるわけ。これはまあ可搬性のために普通のことだ思う
volume:
- ./conf:/conf
みたいに。
ところが、このdocker-composeをホストから見た場合とコンテナ内から見た場合とで意味が変わってしまう。
コンテナ内から見るとこの相対ディレクトリはたとえば /app/conf のことだと見えて、そうdockerエンジンに指示しちゃう。
ところがdockerエンジンのいる外の世界ではそのconfってディレクトリがあるのは /home/yuba/app/conf だったりするわけ。で、docker エンジンがマウント失敗する。
docker-compose実行時にcomposeファイルのある基準ディレクトリが環境変数として取れれば、それを引き回してなんとかできそうなんだけど、ないかなそういうの。
$PWD が使えるって記事もたくさん引っかかるんだけど、これはあくまでdocker composeを実行したときのカレントディレクトリを一部のシェルが好意で入れてくれてるだけだしなあ
dockerでDBとかアプリケーションを動かすとき、データファイルは
なんでこんなこと聞いたかっていうと、これまでだいたいホストマシンのディレクトリをマウントして使ってきたんだけど、どうもdockerの思想としてはそんなことせずに名前付きボリュームで完結することを意図してるんじゃない? という気がしてきて⋯
たとえばホストディレクトリマウントだとオーナーユーザーIDとかだいたいおかしくなるし。
This account is not set to public on notestock.
dockerで本番サーバーを運用するなんてお遊びの個人サイトだから、完璧なソリューションを求めるとこじゃないとは思いますけどね
事業レベルなら当然、dockerじゃなくてk8sなりECSなりよね。ECSならEFSをマウントだろうし、k8sは⋯なんなんだ、たぶん似たようなストレージ領域があるんでしょ?
This account is not set to public on notestock.
dockerでDBとかアプリケーションを動かすとき、データファイルは
This account is not set to public on notestock.
https://matsuand.github.io/docs.docker.jp.onthefly/storage/bind-mounts/
今から新たに Docker アプリケーションを開発しようとする場合は、これにかわって 名前つきボリューム の利用を考えてみてください。
これか!
This account is not set to public on notestock.