あと 3 ヶ月の命(になる予定)の img.azyobuzi.net の旧版を Docker 化した https://github.com/azyobuzin/img.azyobuzi.net/compare/fd2a85dbda4eb0344083d5273752c2066ac08cf9...4ba1af4f7a85e0f4040ff413ea41b7b722de52c3
あと 3 ヶ月の命(になる予定)の img.azyobuzi.net の旧版を Docker 化した https://github.com/azyobuzin/img.azyobuzi.net/compare/fd2a85dbda4eb0344083d5273752c2066ac08cf9...4ba1af4f7a85e0f4040ff413ea41b7b722de52c3
Docker Compose なんていつ使うんだ、寿命同じコンテナ複数作るなって言ってきたけど、 img.azyobuzi.net v3 (C#) と img.azyobuzi.net v2 (Python) を両方同じ寿命で動かす必要が発生しているのでやっぱり必要でした
アプリケーション + DB ならそもそも DB のほうが寿命が長いので、プロダクションで compose するのはおかしいだろというのが根底にある
クソデカコンテナを作れと言ってるわけではなく、お前それ本当に同列に扱うべきものか???と思うものが多い。 DB なんて複数アプリで共有することもあるんだから
最初の発言に戻ると、言いたいことは、 Docker Compose は寿命が同じものに使うべきで、そんなもの存在しないだろと思っていたけれど、あったわ、という話
本当なら DB だけじゃなくてライブラリ群だって共有したほうがいいしシステムのパッケージシステムはそのようになってるはずなんだけど,みなさんそれよりも product ごとに isolation と portablity を選ばれておられるので,DB だって今更だよなとか思っている
うちの Nextcloud も Docker Hub の nextcloud イメージなので、 Apache にリバースプロキシしていて無駄なことやってるんだった……
Nextcloud、 PHP が噛まない静的ファイルを配信しないといけないので、そのためにコンテナ内のファイルへアクセスする穴をあけるか、コンテナ内に HTTP サーバーを立てるかの 2 択を迫られて、楽な方に負けた
ホストマシンに直接展開は、特定のバージョンの Mono じゃないと動かない(調査して直せ)、とか未だに Python 2 (書き直せ)とか、そういう案件(自分のせい)のせいで、どのパッケージが使用中なのか把握するのが大変になった経験から、もう嫌だと思ってる
local volume は docker volume inspect でパス取れるけど、コンテナ自体のルートのパスは inspect で取れないから厳しい
メモリ 1GB マシンにどれだけ詰められるかバトルなので、 kube-apiserver にメモリ 200MB 持っていかれる時点でダメ
docker-compose.yml を書く前に、まず YAML の構文把握してなかった。適当に読めてしまうせいで適当に書きがち
docker-compose.yml の expose ってやつ、何に対応するんだ?指定しなくてもアクセスできてしまうんだが
expose、書かなくても Dockerfile で EXPOSE に書いたのがすでに公開されてるっぽい。 iptables では、 expose したポートに対して ACCEPT が追加されてる
Azure VM Insights を展開してるせいなのか、それとも img.azyobuzi.net の DNS が浸透してアクセスが集中してるせいなのか、どっちだ