23.0.0.2-betaでLiberty InstantOnの新しい機能強化が行われました

Thomas Watson and 浅田かおり (翻訳) 2023年2月21日

発表 , ベータ , 開発者経験 , パフォーマンスの向上 ,

他言語版へのリンク: English ,

この記事は、Liberty InstantOnがまだベータ版だったときに公開されました。Liberty InstantOnは、Liberty 23.0.0.6リリースの時点でベータ版から移行しました。Liberty InstantOnの最新情報は、Open LibertyドキュメントのOpen Liberty InstantOnによるコンテナ化アプリケーションの高速起動を参照してください。

この記事では、私たちのオリジナルの InstantOn 記事、クラウド・ネイティブ Java アプリケーション用の Liberty InstantOn 始動の同じプロジェクト設定を使用しています。この記事の例を参考にしたい場合は、まずその記事の説明を読み、それに従ってください。

次のセクションでは、23.0.0.2ベータリリースに含まれるLiberty InstantOnの改善点について説明します。

フィーチャー・チェックポイントフェーズの削除

当初、InstantOnベータ版では、起動中にチェックポイントが発生する3つのフェーズが用意されていました。

features - これはチェックポイントが発生する最も早い段階です。チェックポイントは、設定されたすべての Open Liberty 機能が開始された後に発生しますが、インストールされたアプリケーションの処理が行われる前に発生します。
beforeAppStart - チェックポイントは、設定されたアプリケーションのメタデータを処理した後に行われます。アプリケーションに、アプリケーションの起動の一部として実行されるコンポーネントがある場合、チェックポイントはアプリケーションのコードを実行する前に実行されます。
afterAppStart - これはチェックポイントが発生する最後のフェーズで、アプリケーションインスタンスをリストアする際に最速の起動時間を提供する可能性があります。チェックポイントは、設定されたすべてのアプリケーションが開始されたと報告された後に行われます。このフェーズは、アプリケーションの受信要求をリッスンするためのポートを開く前に行われます。

これら3つのオプションのうち、features フェーズはアプリケーションの起動時間を改善するという点で、最も価値が低いものです。アプリケーションのデプロイで beforeAppStart よりも features を使いたいシナリオは非常に限られており、Liberty InstantOn の良いユースケースとは言えません。23.0.0.2-beta では、features チェックポイントフェーズは削除されました。この変更により、チェックポイントの選択肢は beforeAppStart と afterAppStart の2つだけになりました。

チェックポイントとリストアに必要なLinuxの機能セットを削減

criu がプロセスのチェックポイントを取得してリストアするためには、criu バイナリに追加の Linux機能を付与する必要があります。特に、Open Liberty 22.0.0.11-beta では、 checkpoint_restore, net_admin, sys_ptrace 機能を付与する必要がありました。

Open Liberty 23.0.0.2-beta では、プロセスのチェックポイントとリストアの両方で net_admin 機能をつけることが不要になりました。また、Liberty InstantOn でアプリケーションを実行するときに、プロセスのリストアで sys_ptrace が不要になりました。この変更は改善されました。net_admin と sys_ptrace 機能は、アプリケーションをクラウドにデプロイするときに受け入れられないかもしれない、幅広い機能のセットを付与します。23.0.0.2-beta では、setpcap 機能の要件が導入されました。この機能の使用方法については、次のセクションで説明します。

InstantOnによるコンテナイメージのビルドの簡略化

Liberty InstantOnベータイメージには、チェックポイントサーバープロセスを持つアプリケーションコンテナイメージを構築するための前提条件が含まれています。アプリケーションは、Liberty InstantOnベータイメージをベースとして、チェックポイントプロセスを持つ独自のアプリケーションコンテナイメージを作成できます。22.0.0.11-beta では、これは 3 段階のプロセスでした。

アプリケーションコンテナイメージをビルドする。
アプリケーションコンテナを実行し、アプリケーションをチェックポイントする。
チェックポイント処理を行ったアプリケーションコンテナを、新しいコンテナイメージにコミットする。

23.0.0.2-beta では、clone3 システムコールと checkpoint_restore 機能を持つカーネルバージョンで動作するシステムで、このプロセスが簡略化されています。これらのカーネル機能はカーネルバージョン 5.9 以降で利用可能で、コンテナ構築中にプロセスのチェックポイントを実行できるようになります。コンテナ構築時のプロセスチェックポイントを正常にリストアするためには、Linux の追加機能である setpcap を criu に付与する必要があります。setpcap` は、リストアされたプロセスの機能を削除する機能を criu に付与します。この機能は、ビルド時に実行されたチェックポイントプロセスの Linux 能力が、アプリケーションイメージを実行しているコンテナよりも低い場合に必要です。この状況を検出すると、criu はリストアされたプロセスに関連する Linux capabilities を、コンテナのビルド時に使用される減少したセットに一致させるためにドロップします。

コンテナのビルドステップ中にプロセスのチェックポイントを行うには、アプリケーションの Dockerfile を更新し、最後に RUN 命令を追加して、プロセスのチェックポイントを実行する必要があります。元の投稿にあるサンプルアプリケーションのプロジェクトを使用して、 Dockerfile の最後に RUN checkpoint.sh afterAppStart を追加します。

Dockerfile

FROM icr.io/appcafe/open-liberty:beta
ARG VERSION=1.0
ARG REVISION=SNAPSHOT
LABEL \
  org.opencontainers.image.authors="Your Name" \
  org.opencontainers.image.vendor="IBM" \
  org.opencontainers.image.url="local" \
  org.opencontainers.image.source="https://github.com/OpenLiberty/guide-getting-started" \
  org.opencontainers.image.version="$VERSION" \
  org.opencontainers.image.revision="$REVISION" \
  vendor="Open Liberty" \
  name="system" \
  version="$VERSION-$REVISION" \
  summary="The system microservice from the Getting Started guide" \
  description="This image contains the system microservice running with the Open Liberty runtime."

COPY --chown=1001:0 src/main/liberty/config/ /config/
COPY --chown=1001:0 target/*.war /config/apps/

RUN configure.sh
RUN checkpoint.sh afterAppStart

この設定は、アプリケーションコンテナイメージの最後のレイヤーとして、アプリケーションプロセスのチェックポイントを追加します。 checkpoint.sh スクリプトでは、 afterAppStart または beforeAppStart を指定して、スタートアップのどのフェーズでプロセスのチェックポイントを実行するかを指定することができます。podman では、 --add-cap と --security-opt オプションを使用することで、コンテナ構築時にチェックポイントを行うために必要な機能をコンテナ構築に付与することができます。これにより、アプリケーションのコンテナイメージのビルドは次のステップに短縮されます。

必要な機能が追加された podman ビルド

podman build \
   -t dev.local/getting-started-instanton \
   --cap-add=CHECKPOINT_RESTORE \
   --cap-add=SYS_PTRACE\
   --cap-add=SETPCAP \
   --security-opt seccomp=unconfined .

InstantOnでアプリケーションを実行する

ホスト OS のカーネルバージョンが 5.9+ の場合、 clone3 システムコールが criu によって使用されます。これにより、 ns_last_pid をマウントする必要がなくなります。23.0.0.2-beta では、以下のコマンドで getting-started-instanton コンテナを実行することができます。

ポッドマンの実行に限定機能追加

podman run \
  --rm \
  --cap-add=CHECKPOINT_RESTORE \
  --cap-add=SETPCAP \
  -p 9080:9080 \
  getting-started-instanton

23.0.0.2-beta では、Liberty InstantOn でアプリケーションコンテナを実行する際に、sys_ptrace または net_admin を追加する必要がなくなりました。 podman は実行中のコンテナにデフォルトで setpcap 機能を付与していることに注意してください。そのため、ほとんどの環境では明示的に --cap-add でこのケイパビリティを追加しなくても、コンテナを実行することができるでしょう。

次はどんなアップデートでしょう

ご覧のように、私たちはInstantOnのベータ版をより使いやすくするために改良を続けています。今後リリースされるベータ版では、AWSのようなパブリッククラウドへのInstantOnの導入方法など、さらなるアップデートを予定しています。ご要望やご提案があれば、ぜひお聞かせください。

すべてのブログ投稿を表示