最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません 発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。 補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発 マルチステージ・ビルドを使う マルチステージビルドの目的 公式ドキュメントには、下記のように記載があります。 マルチステージ・ビルド は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
CloudNative Days Tokyo 2019 1D3 セッションのスライドです。 #CNDT2019 #OSDT2019 #RoomD
これは、なにをしたくて書いたもの？ なにげなく、OpenJDKのDockerイメージを使ったりしていたのですが、1度、どんなイメージがあるのか調べてみようと $ docker search openjdk とか実行すると、わらわらと現れますしね。 ベースのイメージがどうなっているかとか、そのあたりとか見てみようかなと。 やらないこと 各種ディストリビューションのOpenJDK自体としての比較とか、なにを選んだらいいのか？みたいなことはやりません。 そのあたりの情報は、以下とかを見るとよいのではないでしょうか。 Introduction to Java 11: Support and JVM Features #jjug 最適な Java の Docker イメージを選びたい - k11i.biz 最適なOpenJDKディストリビューションの選び方 -How to choose the be
8u191でDocker対応がバックポートされたので、頭の整理と確認をしておいた。 ## まとめ Java 11使っておけばそもそも安心なんだけど、Java 8でも8u191以降を使えば安心。 ## 課題だったこと DockerでJavaを動かすときJavaが「そのコンテナに割り当てられたCPU・メモリ」じゃなくて「Dockerが動いてるHostのCPU・メモリ」を見てしまうことが課題だった。 ## Java 10以降 Java 10以降なら「そのコンテナに割り当てられたCPU・メモリ」を見る対応が入ってるから安心になった。 https://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#JDK-8146115 ## Java 8は？ Java 8で入ってた対応は8u131のこれ： Bug ID:
All slide content and descriptions are owned by their creators.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018/04/08追記： まとめにJava10に関する記載を追加しました。 2017/06/02追記： 調査内容をまとめて記載を大幅に更新しました。 2017/06/01追記： 記事の最後に「JDK8/9以降の本問題の取り組み」を追加しました。OpenJDK8の8u121.b34、8u131.b06で対処済みのようです（本当に修正されているかは別途確認する予定）。 どちらの対処版も2017年以降にリリースされているため、頻繁にJDK/JREを更新してない場合は確認しておくとよいです。 #まとめ (Java10以降) Java10では、
昨日のエントリーの続きです。 mike-neck.hatenadiary.com Gradle万能派の僕には、納得がいかなかったので、最後までやってみることにしました。 切り捨てたこと まず、分散テストは何が目的なのか考えると、テスト結果をマージすることが目的なので、以下のことは切り捨てました。 dockerの外でコンパイルしたクラスファイルの共有(昨日のドハマリその2により、共有してもコンパイルしてしまうので諦めた) srcディレクトリーの共有(Javaファイルを生成するタスクがある場合はsrcディレクトリーの共有をすると、各コンテナがJavaファイル生成を行ってしまうので、諦めた) 【2015/10/20 12:19追記】 つまり、コンパイル結果を共有しても再コンパイルされるので、buildディレクトリーの共有は諦めました この結果、妥協するのは次の点です。 各コンテナでソースコード生
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
