OpenLibertyのベースイメージを操作して、features.shやconfigure.shの保存場所を探してみる

# 概要
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上のコンテナイメージは[こちら](https://openliberty.io/docs/latest/container-images.html)から確認できます。）

しかし、OpenLibertyでOCP上にアプリをデプロイする際、今回のようにベースイメージ名に `kernel-slim`が入っている場合は、Libertyフィーチャーに必要なファイルが同梱されていないようです。（[参考](https://qiita.com/babatch324/items/38d0bfdd18ebdb5bd906#%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89)）

そのため、以下のようにContainerfile上でfeatures.sh を実行するよう記述しました。

```Containerfile
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がダウンロードされ、コンテナイメージに組み込まれるようになりました。

```server.xml
（省略）
    <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上で指定していますが、これらのファイルはローカルのプロジェクト内には見当たりません。

ローカルにないということは、ベースイメージ内にこれらのファイルが存在しているのでは？と考え、ベースイメージを直接操作して確認してみることにしました。

# ベースイメージを操作してみる
[こちらの記事](https://tech-lab.sios.jp/archives/27666#kontenano_bash_wo_qi_dongshite_zhi_jie_cao_zuosuru)を参考にして、コンテナ内でbashを起動して操作を行います。

まずは、ベースイメージをローカルに取得します。
```sh
% podman pull icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
```

指定したイメージが無事に取得できていることを確認します。
```sh
% 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
```

次に、コンテナを実行します。
```sh
% podman run -d icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
```

完了したら、`podman ps`で実行できているか確認します。

```sh
% 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に切り替わります。

```sh
% podman exec -it <CONTAINER ID> /bin/bash
```

カレントディレクトのファイルを表示すると、コンテナを操作できていることが確認できます。

```sh
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が存在しているのか確認してみます。

```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/というディレクトリに存在していたようです。

環境変数を確認してみると、このディレクトリにパスが通っていることも確認できました。

```sh
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のディレクトリを確認しました。
個人的にはこれまで何も考えずに使っていたベースイメージの中身を見るというのが面白い体験でした。