Fediver

ただ使い方の違いとして、VMとコンテナは立ち上げる目的がちょっと違って、1ソフトウェア1コンテナで立ち上げましょうねみたいなところがあるので、たとえばVMでWebサーバー立ち上げるならそのVMにNginxとnodejsとPostgreSQLをインストールして⋯みたいなことをやるわけですが、Dockerでやるときは
Nginxコンテナ
nodejsコンテナ
PostgreSQLコンテナ
を別々に立ち上げるのがふつーだったりするわけですね

Dockerコンテナ = VM
Dockerイメージ = VMテンプレート

DockerをVMみたいなもんというアナロジーで入門するの、わりとアリだとおもってます。

なんでこんなもんDockerで動かしたんだ

Docker,マジで嫌いだわ

Docker,めんどくさい

面倒がって本番環境でdocker buildしてたのがまずかった

docker system prune -a --volumes

で37.19GB解放されて復活しました ​​

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

だから 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になったり様々

Dockerの莉ｮ諠ｳ繝槭す繝ｳ繧ｵ繝ｼ繝薙せ

WSLのDockerからホスト側のlocalhost叩くのクソめんどくて草

Misskeyの環境構築にDockerを使用していないので、ミドルウェアのサポートバージョン変更の度に徐々に歪みが出てくるな。どこかのタイミングでDocker環境へ移行したほうが良いかもしれない。

メモリは安定してる。
公式Dockerイメージだからjemalloc最初から入ってるもんね