概要
OpenLibertyでアプリをデプロイする際に、以下のような小さな気づきがあったので備忘録として残しておきます。
- 背景:OpenLibertyのContainerfileに記載する、"RUN features.sh"や"RUN configure.sh"について、これらのファイルがローカルには見当たらなかったのでどこに存在するのか調べてみた
- 方法:ベースイメージ(今回の場合は
kernel-slim-java17-openj9-ubi
)をローカルに取得し、コンテナ内でbashを起動して操作した - 結果:これらのファイルはローカルではなく、ベースイメージ内に存在していた
経緯
OpenLibertyでアプリをデプロイする際、ベースイメージとしてfull-java17-openj9-ubi
の代わりにkernel-slim-java17-openj9-ubi
を使用してみました。
(ちなみに、IBM Container Registry上のコンテナイメージはこちらから確認できます。)
しかし、OpenLibertyでOCP上にアプリをデプロイする際、今回のようにベースイメージ名に kernel-slim
が入っている場合は、Libertyフィーチャーに必要なファイルが同梱されていないようです。(参考)
そのため、以下のようにContainerfile上でfeatures.sh を実行するよう記述しました。
FROM icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
COPY --chown=1001:0 /src/main/liberty/config/server.xml /config/
RUN features.sh
COPY --chown=1001:0 target/liberty01.war /config/dropins/
RUN configure.sh
これによって、server.xml内の<featureManager>
タグで囲まれているpages-3.0がダウンロードされ、コンテナイメージに組み込まれるようになりました。
(省略)
<featureManager>
<feature>pages-3.0</feature>
</featureManager>
(省略)
ContainerfileにRUN features.sh
を記載しない場合は以下のようなエラーが表示されてアプリをデプロイできなかったのですが、上記の手順を実行したことでデプロイに成功するようになりました。
[ERROR ] CWWKF0001E: A feature definition could not be found for pages-3.0
疑問点
しかし、ここで1点疑問が生まれました。
features.sh
やconfigure.sh
をContainerfile上で指定していますが、これらのファイルはローカルのプロジェクト内には見当たりません。
ローカルにないということは、ベースイメージ内にこれらのファイルが存在しているのでは?と考え、ベースイメージを直接操作して確認してみることにしました。
ベースイメージを操作してみる
こちらの記事を参考にして、コンテナ内でbashを起動して操作を行います。
まずは、ベースイメージをローカルに取得します。
% podman pull icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
指定したイメージが無事に取得できていることを確認します。
% podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
icr.io/appcafe/open-liberty kernel-slim-java17-openj9-ubi d8efdfb2bdec About a minute ago 723 MB
次に、コンテナを実行します。
% podman run -d icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
完了したら、podman ps
で実行できているか確認します。
% podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d1e8df1e7dcc icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi /opt/ol/wlp/bin/s... 5 seconds ago Up 6 seconds 9080/tcp, 9443/tcp nifty_lichterman
最後に、以下のコマンドを実行することで、入力がコンテナを操作するbashに切り替わります。
% podman exec -it <CONTAINER ID> /bin/bash
カレントディレクトのファイルを表示すると、コンテナを操作できていることが確認できます。
bash-4.4$ ls
bin config etc home lib64 lib.index.cache logs media opt proc run srv tmp var
boot dev fixes lib liberty licenses lost+found mnt output root sbin sys usr
それでは、configure.shとfeatures.shが存在しているのか確認してみます。
bash-4.4$ which configure.sh
/opt/ol/helpers/build/configure.sh
bash-4.4$ which features.sh
/opt/ol/helpers/build/features.sh
bash-4.4$ ls /opt/ol/helpers/build/
checkpoint.sh configuration_snippets configure.sh features.sh infinispan-client-setup.sh pidplus.sh populate_scc.sh
どうやらこれらのファイルは、/opt/ol/helpers/build/というディレクトリに存在していたようです。
環境変数を確認してみると、このディレクトリにパスが通っていることも確認できました。
bash-4.4$ env
(省略)
PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/ol/wlp/bin:/opt/ol/helpers/build
(省略)
まとめ
ベースイメージとして使用していたコンテナイメージの中身を確認し、Containerfileで指定していたconfigure.shとfeatures.shのディレクトリを確認しました。
個人的にはこれまで何も考えずに使っていたベースイメージの中身を見るというのが面白い体験でした。