コンテナで発生するコールドスタートの問題に関する論文を使って、いくつかの実験を行っています。私のテストアプリケーションは、openjdkイメージ上に構築されたSpring Bootアプリケーションです。コールドスタートの問題を解決するために最初にしたいことは、次のとおりです。
コンテナーを準備します。コンテナーには、openjdkと、springbootアプリが使用するライブラリーがあります。既存のコンテナーのipcとnetworknamespaceを使用して他のコンテナーを起動し、openjdkとこのコンテナーのライブラリーを使用してjarファイルを実行できるようにします。
これを達成する方法が正確にわかりませんか?ボリュームを使用してこれを達成できますか、それとも完全に異なるアプローチを探しているのですか?
別のメモでは、x個のコンテナーを実行したい場合は、x個の既存のコンテナーが実行されていることを確認します。これは、すべてのコンテナーが、操作する固有のライブラリコンテナーを持っていることを確認するためです。これでいいですか?
つまり、ipc/netを介して接続されている2番目のコンテナーを使用して、Spring Bootアプリケーションを高速化できる方法です。私の問題に役立つでしょう。
あなたがあなたの目標に到達しようとしているやり方は、コンテナ化の全体のポイントを無視します。
目標にしっかりと焦点を当てるために循環することがあります-「コールドスタートの問題を解決する」と「スプリングブートアプリケーションを高速化する」。
実際にJavaアプリケーションをネイティブバイナリにコンパイルすることを検討しましたか?
JVMの本質は、それぞれのホスト環境における相互運用性のJavaの機能をサポートすることです。コンテナーは本質的に相互運用性を本質的に解決するので、(JVMによる)解決の別のレイヤーはまったく関係ありません。
アプリケーションのネイティブコンパイルは、アプリケーションランタイムからJVMを除外するため、最終的にはコールドスタートの問題を解決します。 GraalVM
は、Javaアプリケーションのネイティブコンパイルを実行するために使用できるツールです。 GraalVMコンテナイメージ があります。アプリケーションコンテナの開発をサポートします。
以下は、ネイティブコンパイルされたJavaアプリケーションのDockerイメージの構築を示すサンプルDockerfile
です。
# Dockerfile
FROM Oracle/graalvm-ce AS builder
LABEL maintainer="Igwe Kalu <[email protected]>"
COPY HelloWorld.Java /app/HelloWorld.Java
RUN \
set -euxo pipefail \
&& gu install native-image \
&& cd /app \
&& javac HelloWorld.Java \
&& native-image HelloWorld
FROM debian:10.4-slim
COPY --from=builder /app/helloworld /app/helloworld
CMD [ "/app/helloworld" ]
# .dockerignore
**/*
!HelloWorld.Java
// HelloWorld.Java
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, Native Java World!");
}
}
イメージをビルドしてコンテナを実行します。
# Building...
docker build -t graalvm-demo-debian-v0 .
# Running...
docker run graalvm-demo-debian-v0:latest
## Prints
## Hello, Native Java World!
Springのヒント:GraalVMネイティブイメージビルダー機能 は、GralVMを使用したSpring Bootアプリケーションの構築をデモする記事です。