Fediver

強い言葉使ったけどあくまで個人的な思想なのでそれを他人に押し付けようとは思わない

だから docker compose と kubernetes の両方ある程度知った上で選ぶなら好きに任せる、触ってないけど難しそうで思考停止してるならもうちょっとk8sのこと知ってもいいと思うよ

RE: https://misskey.nokotaro.com/notes/819adc9c0769981222516a31

docker composeに頼るならそれこそ別にsystemdに頼っていーじゃんｗ

なお今は個人で使うコンテナベースのサービスは基本Railwayに移管した。
ただしRailwayだと最寄りのリージョンがシンガポールになるので、Misskeyのみデータローカライゼーションの観点から自宅サーバーでdocker composeしている（DBのバックアップ先はAWS S3）

んで高負荷時に水平/垂直スケールすると思うんだけど、docker composeでどこまでできるのか分かってない（もしk8sと同様にできるなら特に差は無い）

k8sなら少なくとも Deploymentの定義でレプリカ管理できて、LB的なところはService定義で負荷分散出来て、Pod Autoscalerで水平スケールできるけど…… もちろん逆(負荷が無くなったら不要Podが消える)も然り

例えばコンテナが死んだとき、docker composeあんま良く分からんけどrestart policyとか書いとくんですかねえ

k8sではPodのヘルスチェックをyamlで定義して自動監視、要件を満たさなかったら死んだものとしてトラフィックから外すようにして勝手にrestartするよ

間違えるので docker-compose から docker compose に alias 貼ってた時期があった

docker composeゴミなので基本使わないので

そのあとはもう何かこねくり回してdocker-composeになったりk8sになったり様々

​​だと2025.4.0にアプデしたあと以下のコマンド叩くと2025.3.1に戻せます

git stash
git checkout 2025.3.1
git submodule update --init
git stash pop
sudo docker compose build
sudo docker compose stop && sudo docker compose up -d

zabbixの検証環境をdocker composeで建てたらあっという間にできてらくらくちんちんだったが、zabbixサーバ自体のデータが取れてなくてあれれ？となり
調べた結果zabbix-agentを立ち上げてないだけだった　れあどめ読め案件でしたね

ちなみにdocker-compose.yamlは後方互換

正味docker compose up叩くだけなら非エンジニア向けの記事でもたまによくみるからハードル低くはある

Misskey をアップデートするときにメモリ不足で docker compose build がコケてしまったので、Misskey が一時止まってしまった。

とりあえず復旧できたので良かった。
久しぶりに Misskey アップデート！

docker compose up 一発でMisskeyと藍ちゃんと定期バックアップバッチが立ち上がるようにできたわけよ

docker-compose実行時にcomposeファイルのある基準ディレクトリが環境変数として取れれば、それを引き回してなんとかできそうなんだけど、ないかなそういうの。

$PWD が使えるって記事もたくさん引っかかるんだけど、これはあくまでdocker composeを実行したときのカレントディレクトリを一部のシェルが好意で入れてくれてるだけだしなあ

ホストボリュームをマウントするよう書いているんだけど、マウント元は相対ディレクトリで書いてるわけ。これはまあ可搬性のために普通のことだ思う

volume:
- ./conf:/conf

みたいに。

ところが、このdocker-composeをホストから見た場合とコンテナ内から見た場合とで意味が変わってしまう。

コンテナ内から見るとこの相対ディレクトリはたとえば /app/conf のことだと見えて、そうdockerエンジンに指示しちゃう。

ところがdockerエンジンのいる外の世界ではそのconfってディレクトリがあるのは /home/yuba/app/conf だったりするわけ。で、docker エンジンがマウント失敗する。

docker-composeコマンドを叩くcronデーモンも、dockerコンテナ内で動かせないと思ってる。

でも、これが意外なところで引っかかってうまくいかないの。

知らなかったそんなの……
せこせことdocker-compose.ymlに直してたけどcompose.yamlでいいんだね

The default path for a Compose file is compose.yaml (preferred) or compose.yml that is placed in the working directory.
Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility of earlier versions.
If both files exist, Compose prefers the canonical compose.yaml.compatibility of earlier versions. If both files exist, Compose prefers the canonical compose.yaml.

この藍ちゃんはdocker-composeで生かされているので、同じcompose内にいるlbとかwebとかdbとかのコンテナのことをMisskey本部だと思ってる、きっと

docker composeでもいいらしいが、まずもって何をやっているのか把握しないと