[B! docker] コンテナのベストプラクティスに対しておこがましくも言ってみる

oisux マルチステージの例はキャッシュは外からマウントしてるので毎回ダウンロードはしないだろうし、レイヤーの理解も怪しそうだしで、物申す割に余り調べきれてないなという感想/diveでイメージの構造を眺めると良いかも

2023/12/03 リンク

ledsun Javaならマルチステージビルドしないで、コンテナ外でビルドしたjarをコピーすればよい。それはそう

2023/12/02 リンク

prograti Java17ならjlinkを使うのはどうですかね？ https://snyk.io/jp/blog/jlink-create-docker-images-spring-boot-java/

2023/12/03 リンク

yabu_kyu 「今回、Dockerのベストプラクティスに個人的な意見を言ってみましたが」最初に書いて欲しかった

2023/12/03 リンク

diveintounlimit “大事なのはベストプラクティスで達成したい目的を満たせてるか”これは本当にそう。

2023/12/03 リンク

h3poteto distrolessはephemeral containerでデバッグしろというのがベストプラクティスなのでは．tagがlatestしかないのは確かに思うところはあるけど，入っているものが最小だからそこを気にするなということなのかね．

2023/12/03 リンク

reggino アルペンのくだり分かるわ、脳死でアルペン系入れる人、運用大変なの分かりますか？って感じ。まぁいいけど。どうとでもなるし。

2023/12/03 リンク

unmarshal Goでもクロスコンパイラ恩恵でバイナリだけコピーしてる! 個人的にdocker buildはCI上ではなくローカルで良いかな。（早いし結果は一緒だし。）本番はシェル入れない方が良い気がして、開発と同じじゃなくても良いのでは？

2023/12/03 リンク

コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita

最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラク... 最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発マルチステージ・ビルドを使うマルチステージビルドの目的公式ドキュメントには、下記のように記載があります。マルチステージ・ビルドは、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて