NEC Mark
WebOTX Manual V11.1 (第6版)

目次を表示

1.4. コンテナイメージの生成(Cloud Native Buildpacks を使用する場合)

Linux環境においてMavenプロジェクトのソースコードからWebOTX Application Server Express (フルプロファイルまたはマイクロサービスプロファイル)のコンテナイメージを生成する手順を説明します。

1.4.1. Cloud Native Buildpacksとは

Cloud Native Buildpacks(CNB)はアプリケーションのLinuxコンテナイメージを生成するための技術です。 CNBはLinuxコンテナ技術の標準化と普及を進めるCloud Native Computing Foundation(CNCF)が管理するプロジェクトの1つで、 CNBを使用することでLinuxコンテナの標準形式であるOCIに準拠したコンテナイメージを作成することができます。 また、従来のコンテナイメージ生成手法と比較すると次の特徴があります。

1.4.1.1. Cloud Native Buildpacksの構成

Cloud Native Buildpacks は Stack, Buildpack, Builderという3つのコンポーネントで構成されています。

Stackはbuild imageとrun imageと呼ばれる2種類のコンテナイメージをまとめた概念です。 build imageはコンテナイメージを生成する際の作業環境として使用されます。 このイメージから起動したコンテナの内部で、ソースコードのコンパイルやフレームワークのインストール作業などが実行されます。 run imageは生成されたコンテナイメージのベースイメージとして使用されます。 build imageでインストールしたフレームワークやコンパイルしたアプリはrun imageにコピーされて、コンテナイメージ化されます。

Buildpackはソースコードを実行可能な形式に変換するための処理全般を担います。 例えばJavaのソースコードを処理する場合は、コンパイルに必要なJDKのインストール、ビルドツールのMavenのインストールと実行、 ビルドしたアプリの実行に必要なフレームワークのインストール、コンテナを起動した際のエントリポイントのコマンドラインの設定、などを行います。

BuilderはStackとBuildpackをまとめた単位で、先程のStackとBuildpackを使用してソースコードからコンテナイメージを生成するまでの一連の作業を実施します。 このため、CNBでコンテナイメージを生成する際にはどのBuilderを使用するのかを指定する必要があります。

生成するコンテナイメージは、ベースイメージ(run image)とアプリケーションレイヤー、ビルドパックが生成するレイヤーにより構成されます。
これらを使用したコンテナイメージ生成の流れは、次の図のようになります。

CNB構成図
1.4.1.2. WebOTX連携

WebOTX Application Server Expressを使用したコンテナイメージを生成するために、WebOTX Application Server Expressをインストールするビルドパックとそのビルドパックを使用するビルダーを提供しています。
WebOTX Application Server Expressがインストールされたコンテナイメージ生成の流れは、次の図のようになります。

WebOTX連携構成図

1.4.2. ビルド環境要件

Cloud Native Buildpacksによるコンテナイメージの生成を行うには、コンテナエンジンとCNB準拠のツールのインストールが必要です。 WebOTXのビルダーでは以下のバージョンのソフトウェアにおいてコンテナイメージ生成の動作を検証しています。

1.4.2.1. コンテナ環境のインストール

コンテナイメージを作成するには、事前にコンテナエンジン (Docker または Podman)のインストールが必要です。
インストール方法および環境設定方法はOSおよびコンテナエンジンのドキュメントを参照してください。

Podmanを採用する場合は、Podmanインストール後にDocker互換APIサービスを起動します。 pack CLIはコンテナエンジンを操作する際に Docker API サービスを経由するため、この作業が必要になります。 

root> yum install -y podman-remote
root> podman system service --timeout=0 tcp:0.0.0.0:1234 &
root> export DOCKER_HOST=tcp://127.0.0.1:1234

Caution
上記の例では、podmanのコマンドを実行して直接サービスを起動していますが、コマンド「systemctl --user start podman.socket」で Systemd からも起動することが可能です。ただし、Systemdから起動した場合はプロキシサーバを経由させることができません。 プロキシサーバが必要な環境では、必ず「podman system service」コマンドでサービスを起動してください。

Memo
オプションを指定せずにDocker互換APIサービスを起動するとサービスはUnixソケットにバインドされます。 ただし、UnixソケットはSELinuxによりブロックされるため本手順ではSELinuxの影響を受けないTCPを使用します。

1.4.2.2. pack CLIのインストール

pack CLIのインストール方法および環境設定方法はCloud Native BuildpacksのPackコマンドのページを参照してください。

1.4.2.3. WebOTX Builderイメージの生成

Cloud Native BuildpacksでWebOTXのコンテナイメージを生成するには、WebOTX公式サイトで提供するCNB対応イメージ生成スクリプトを使用して WebOTX Builderを導入する必要があります。 なおCNB対応イメージ生成スクリプトの内部ではtarコマンドとgzipコマンドを使用しますので、予めこれらのコマンドをインストールしてください。

CNB対応イメージ生成スクリプトを実行することで、以下のコンテナイメージ(Stack, Buildpack, Builder)が登録されます。

分類イメージ名説明
Stackwebotx/build-image-ubi7-stack:latestUBI7対応のBuilderのベースイメージ
Stackwebotx/run-image-ubi7-stack:latestUBI7対応の生成するコンテナイメージのベースイメージ
Stackwebotx/build-image-ubi8-stack:latestUBI8対応のBuilderのベースイメージ
Stackwebotx/run-image-ubi8-stack:latestUBI8対応の生成するコンテナイメージのベースイメージ
Buildpackwebotx/certificates-bp:1.0.0CA証明書の登録
Buildpackwebotx/jdk-bp:1.0.0JDK環境の構築
Buildpackwebotx/maven-bp:1.0.0Maven環境の構築・Mavenプロジェクトのビルド
Buildpackwebotx/webotx-bp:1.0.0WebOTX Application Serverの構築・設定
Buildpackwebotx/webotx-uber-jar-bp:1.0.0マイクロサービスプロファイル版WebOTXの構築・設定
Builderwebotx/full-profile-ubi7-builder:11.10.00.00UBI7対応のフルプロファイル版ビルダー
Builderwebotx/full-profile-ubi8-builder:11.10.00.00UBI8対応のフルプロファイル版ビルダー
Builderwebotx/ms-profile-ubi7-builder:11.10.00.00UBI7対応のマイクロサービスプロファイル版ビルダー
Builderwebotx/ms-profile-ubi8-builder:11.10.00.00UBI8対応のマイクロサービスプロファイル版ビルダー

CNB対応イメージ生成スクリプトの使用手順を以下で説明します。

  1. ログイン名 root でログインします。 
    login: root
  2. CNB対応イメージ生成用スクリプトを配置したディレクトリに移動して、スクリプトを実行してください。 
    root> ./generate-cnb-images.sh
    また、CNB対応イメージファイルを指定し実行することができます。 
    root> ./generate-cnb-images.sh <tar.gzファイル>

    Memo
    スクリプト実行時にインターネット上から最新のRed Hat Universal Base Imageをダウンロードします。 インターネットアクセスにプロキシサーバを経由する環境では環境変数http_proxy、https_proxy、no_proxyにプロキシサーバの情報を指定してください。

    以下のメッセージが表示されたら生成完了です。CNB対応イメージ生成用スクリプトはここで終了します。 
    Building CNB images is successful.
  3. CNB対応イメージが生成されていることを確認します。 
    root> docker images
REPOSITORY                            TAG           IMAGE ID       CREATED        SIZE
webotx/build-image-ubi8-stack         latest        014f6c784954   42 years ago   226MB
webotx/run-image-ubi8-stack           latest        014f6c784954   42 years ago   226MB
webotx/build-image-ubi7-stack         latest        1133b5d715b7   42 years ago   225MB
webotx/run-image-ubi7-stack           latest        1133b5d715b7   42 years ago   225MB
webotx/webotx-bp                      1.0.0         1823d15bd95e   42 years ago   184MB
webotx/certificates-bp                1.0.0         44093fc8b851   42 years ago   7MB
webotx/ms-profile-ubi7-builder        11.10.00.00   d7516b85b975   42 years ago   261MB
webotx/ms-profile-ubi8-builder        11.10.00.00   9fe1c317a64f   42 years ago   262MB
webotx/webotx-uber-jar-bp             1.0.0         8e2c67f0ec18   42 years ago   3.38MB
webotx/jdk-bp                         1.0.0         d73f51e52e3f   42 years ago   5.68MB
webotx/maven-bp                       1.0.0         9cbc2e2cb43d   42 years ago   5.8MB
webotx/full-profile-ubi8-builder      11.10.00.00   de4b876a291e   42 years ago   442MB
webotx/full-profile-ubi7-builder      11.10.00.00   562d224ba913   42 years ago   441MB

1.4.3. コンテナイメージの生成

この節ではコンテナイメージ名やパスを以下のように表記します。

表記説明例
<source>アプリケーションソースコード(Mavenプロジェクト)のパス/home/guest/sample-app
<builder_image>Builderイメージ名webotx/full-profile-ubi8-builder:11.10.00.00
1.4.3.1. WebOTX Builderの選択

コンテナイメージを生成する前に使用する WebOTX Builder を決めます。

WebOTXが提供するBuilderの種類は以下の通りです。 Builderごとに生成するコンテナイメージのベースOSとプロファイルが異なるため、目的と用途に合わせて適切なBuilderを選択してください。

Builder生成イメージ
ベースOSプロファイル
webotx/full-profile-ubi8-builder:11.10.00.00Red Hat UBI 8フルプロファイル
webotx/full-profile-ubi7-builder:11.10.00.00Red Hat UBI 7フルプロファイル
webotx/ms-profile-ubi7-builder:11.10.00.00Red Hat UBI 8マイクロサービスプロファイル
webotx/ms-profile-ubi8-builder:11.10.00.00Red Hat UBI 7マイクロサービスプロファイル

使用するビルダーイメージを信頼済みビルダーとして登録します。 

root> pack config trusted-builders add <builder_image>

信頼済みビルダーとして登録されていることを確認するには、次のコマンドを実行します。 

root> pack config trusted-builders list
Trusted Builders:
  <builder_image>
1.4.3.2. コンテナイメージの生成

コンテナイメージを生成するには、次のように pack build コマンドを実行します。 

root> pack build <app_image> --path <source> --builder <builder_image>

各ビルドパックに対する設定は次節以降で説明する環境変数もしくはバインディングで指定します。

Caution
フルプロファイルのイメージを生成する場合は、ビルドしたアプリケーションを配備するために スクリプトファイル「post-start-domain.sh」に配備コマンドを記述して後述のバインディングで「additional-config」に渡す必要があることに注意してください。

1.4.3.3. 環境変数による設定

環境変数でビルドパックの設定を行う場合は pack build コマンドに --envオプションを使用します。
「--env <環境変数名>=<値>」をコンテナイメージ生成コマンドに付与します。
--env オプションは複数個を同時に指定することが可能です。
以下は、実行例です。 

root> pack build <app_image> --path <source> --builder <builder_image> \
        --env BP_ENABLE_RUNTIME_CERT_BINDING="false" \
        --env BP_MAVEN_CLEAR_M2_CACHE="true"

指定可能な環境変数は以下の通りです。

変数名 説明 既定値
BP_ENABLE_RUNTIME_CERT_BINDING バインディングで指定したCA証明書を生成したコンテナイメージで有効化するかを true/false で指定します。 ビルド環境だけでCA証明書が必要で、生成したコンテナイメージの実行環境ではCA証明書が不要な場合は false を指定してください。 true
BP_JDK_URL ソースコードのコンパイルとWebOTXの実行に使用する JDK インストーラの URL を指定します。 指定する JDK インストーラは tar.gz 形式で圧縮されており、解凍後のパスで <任意のフォルダ名>/bin/ 配下に javac コマンドが格納されている必要があります。 また、使用する JDK は予め用意したものをバインディングで指定することも可能です。 https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u312-b07/OpenJDK8U-jdk_x64_linux_hotspot_8u312b07.tar.gz
BP_MAVEN_URL ソースコードのコンパイルに使用する Maven インストーラの URL を指定します。 指定する Maven インストーラは tar.gz 形式で圧縮されており、解凍後のパスで <任意のフォルダ名>/bin/ 配下に mvn コマンドが格納されている必要があります。 また、使用する Maven は予め用意したものをバインディングで指定することも可能です。 https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.8.3/apache-maven-3.8.3-bin.tar.gz
BP_MAVEN_POM_FILE Mavenプロジェクト内のPOMファイル名を指定します。 pom.xml
BP_MAVEN_BUILD_ARGUMENTS ソースコードをコンパイルする際の mvn コマンドの引数を指定します。 なお、どのオプションを指定した場合でも必ず mvn コマンド実行時の引数にキーボード入力による確認を抑制する -B オプションが付与されます。 -Dmaven.test.skip=true package
BP_MAVEN_BUILT_ARTIFACT （マイクロサービスプロファイル限定）
Mavenビルド後の成果物のファイルパターンを指定します。生成するコンテナの容量削減のため、このパターンに合致しないファイルはコンテナイメージに格納されません。		 target/*.jar
BP_MAVEN_BUILT_MODULE （マイクロサービスプロファイル限定）
複数のmavenプロジェクトを含むソースコードの場合に、最終的なビルド成果物があるモジュール名を指定します。		 （空文字列）
BP_MAVEN_CLEAR_M2_CACHE キャッシュされているMavenのローカルリポジトリを削除するか true/false で指定します。 false の場合は前回ビルド時に作成されたキャッシュを削除せずにビルドを行います。 false
BP_WEBOTX_TIMEOUT_SECONDS （フルプロファイル限定）
WebOTXドメイン起動のタイムアウト時間(秒)を指定します。		 1800
1.4.3.4. バインディングによる設定

各ビルドパックの処理にてローカルマシンのディレクトリやファイルを共有して使用することができます。 CNBでは、この機能をバインディングと呼びます。 バインディングを使用し、各ビルドパックが必要とするソースコード以外のファイルやディレクトリを与えることができます。

バインディングによって共有したディレクトリは、コンテナ内の /platform/bindings 配下にマッピングされます。
WebOTXのビルダーで指定可能なバインディングは、以下の通りです。

ディレクトリ名 説明
certificates このディレクトリの直下にコンテナイメージ生成時や生成したコンテナイメージで使用するCA証明書を格納します。
jdk このディレクトリの直下にソースコードのコンパイルとWebOTXの実行に使用する JDK インストーラファイルを格納します。 指定する JDK インストーラは tar.gz 形式で圧縮されており、解凍後のパスで <任意のフォルダ名>/bin/ 配下に javac コマンドが格納されている必要があります。
maven(*1) このディレクトリの直下にMavenに関する以下の情報を格納します。
  • ソースコードのコンパイルに使用する Maven インストーラファイル
    指定する Maven インストーラは tar.gz 形式で圧縮されており、解凍後のパスで <任意のフォルダ名>/bin/ 配下に mvn コマンドが格納されている必要があります。
  • Mavenの設定ファイル（settings.xml, settings-security.xml）
  • Mavenローカルリポジトリ
    Mavenセントラルリポジトリなどアクセス可能なリモートリポジトリにビルドに必要なmavenアーティファクトが存在しない場合に使用します。
additional-config(*2) このディレクトリの直下にフルプロファイル版WebOTXの設定ファイルやアプリイメージ起動前に実行されるファイルを格納します。
格納するファイルに関する詳細は [ 構築・運用 > コンテナ型仮想化 > 追加構成 ] をご参照ください。

(*1) Mavenリポジトリは、/platform/bindings/maven/.m2/にバインディングします。
(*2) アプリイメージ起動前に実行されるファイルは、/platform/bindings/additional-config/preprocess.d/にバインディングします。

共有するディレクトリをバインディングする場合は、--volumeオプションを使用します。
「--volume <ローカルパス>:<コンテナ内パス>」をコンテナイメージ生成コマンドに付与します。
以下は、実行例です。 

root> pack build <app_image> --path <source> --builder <builder_image> \
        --volume /home/cnb/bindings:/platform/bindings \
        --volume /home/cnb/.m2:/platform/bindings/maven/.m2

Caution
SELinuxが有効な場合は、ディレクトリが正しく共有できない可能性があるため、 共有ディレクトリのラベルを変更する接尾辞「:Z」を指定します。
「--volume <ローカルパス>:<コンテナ内パス>:Z」をコンテナイメージ生成コマンドに付与します。

1.4.4. ライセンスの登録

WebOTXビルダーで生成したコンテナイメージには365日間利用可能なお試しライセンスが登録されていますが、 本番利用するには正規ライセンスを登録する必要があります。 正規ライセンスを登録するにはコンテナ起動時に環境変数 OTX_LICENSE にWebOTX Application Server Expressのライセンスキーを指定します。 

# docker run -it -d -e OTX_LICENSE=<ライセンスキー> <イメージ名>

また、以下のようにカンマ区切りで複数のライセンスキーを指定することも可能です。 

# docker run -it -d -e OTX_LICENSE=<ライセンスキー>,<ライセンスキー>,<ライセンスキー> <イメージ名>
Copyright (C) 1998 - 2023 NEC Corporation. All rights reserved.