8.4.3. Initial Setup of Nablarch batch Project for Container¶
The following is procedures of initial setup of the Nablarch batch project for container:
- Generating Nablarch batch project for container
- Confirm communications of Nablarch batch project
- Create a container image
- Run Container Image
8.4.3.1. Overview of the generated project¶
The overview of the project generated by this procedure is as follows.
| Item | Description |
|---|---|
| Project type | Maven project |
| Project composition | Single project composition |
| DB used | H2 Database Engine (embedded in the application) |
| What is included in the generated project? | The following is included in the generated project:
|
| [1] | Email send batch functions as a resident batch and sends mail to the SMTP server.
Sample component configuration file is present in src/main/resources/mail-sender-boot.xml.
Email send batch is not necessary when building the initial environment, but when it becomes necessary, use after reading the description of send email. |
For relationship with other projects and directories, see Maven Archetype Configuration.
8.4.3.2. Create blank project¶
Generate a blank project using the archetypes provided by Nablarch.
8.4.3.2.1. Execute the mvn command¶
Use Maven Archetype Plugin(external site) to generate a blank project.
Change the current directory to the directory where the blank project (can be any directory) is to be created, and place the following file.
After placing the file, specify the necessary parameters in the arguments and execute the bat file.
generateContainerNablarchBatchProject.bat 5u24 <<groupId>> <<artifactId>> <<version>> <<package(optional)>>
The parameters configured in the above command are as follows. If you want to change the version of Nablarch, change 5u24. Change the current directory to the directory where the blank project (can be any directory) is to be created.
| Input item | Description | Configuration example |
|---|---|---|
| groupId | Group ID (normally, enter the package name) | com.example |
| artifactId | Artifact ID | myapp-container-batch |
| version | Version number | 0.1.0 |
| package | Package (normally the same as group ID) | com.example |
Important
Item groupId and package are mapped to the Java package name. Use lowercase letters, numbers, and dots for these input values, and do not use hyphens.
If the command ends normally, a blank project is created under the current directory.
8.4.3.3. Communication confirmation¶
The communication confirmation mechanism and procedures are the same as for a normal Nablarch batch project. Thus, see Initial Setup of the Nablarch Batch Project.
Note
The artifact ID should be replaced with myapp-container-batch to specify the directory and command.
8.4.3.4. Create a container image¶
The blank project has a plugin named Jib (External sites) built in to create an image of a Docker container.
The jib: dockerBuild goal of this plugin can be executed to create a container image.
cd myapp-container-batch
mvn compile jib:dockerBuild
If the execution is successful, the log given below will be output to the console.
(omission)
[INFO] Built image to Docker daemon as myapp-container-batch, myapp-container-batch, myapp-container-batch:0.1.0
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
(Omitted)
Built Docker images are stored in a local repository. Can see the images stored in the local repository with the following command.
docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
myapp-container-batch 0.1.0 1cafd4108237 51 years ago 253MB
myapp-container-batch latest 1cafd4108237 51 years ago 253MB
Can see that there are 2 images registered: myapp-container-batch:0.1.0 and myapp-container-batch:latest .
As you can see, the blank project is configured to create the following two images by executing jib:dockerBuild.
${project.artifactId}:latest${project.artifactId}:${project.version}
OpenJDK image (External sites) is used as base image by default.
The base image can be changed with the jib.from.image property.
For example, if you want to use adoptopenjdk:11.0.11_9-jre-hotspot for your base image, you would write it in pom.xml .
<project>
<! -- Omitted ...-->
<properties>
<! -- Omitted ...-->
<jib.from.image>adoptopenjdk:11.0.11_9-jre-hotspot</jib.from.image>
</properties>
<! -- Omitted ...-->
</project>
Tip
In the blank project, the base image is specified with a Docker image tag. In this case, the latest version of the specified image will be selected. If a different version is selected than at the time of verification, it may affect the operation of the application. Therefore, it is recommended to specify the base image as a digest in order to specify exactly which version, after the test is completed.
An example of setting by digest is shown below.
<jib.from.image>adoptopenjdk@sha256:df316691a2c655de2f835a626f8611c74af67dad2cf92711f6608b54e5aa6c61</jib.from.image>
8.4.3.5. Run a container image¶
Once you have created a container image, you can run it with the following command.
8.4.3.5.1. On-demand batch¶
cd myapp-container-batch
docker run --rm -v %CD%\\h2:/h2 -v %CD%\\src\\main\\format:/var/nablarch/format -v %CD%\\work\\output:/var/nablarch/output --name myapp-container-batch myapp-container-batch:latest -diConfig classpath:batch-boot.xml -requestPath SampleBatch -userId batch_user
It works the same as for Communication confirmation (on-demand batch)). If the startup is successful, a log similar to Launching the on-demand batch application will be output to the console.
8.4.3.5.2. Messaging Using Tables as Queues¶
cd myapp-container-batch
docker run -it --rm -v %CD%\\h2:/h2 --name myapp-container-batch --rm myapp-container-batch:latest -diConfig classpath:resident-batch-boot.xml -requestPath SampleResiBatch -userId batch_user
It works the same as for Communication confirmation (messaging using tables as queues) . If the startup is successful, a log similar to Launching the application will be output to the console. It will go into standby mode, so force quit it with ctrl+c after confirming.
8.4.3.6. Supplementary notes¶
- About the commands to run the container image.
When the above command is executed, the container will be started, batch processing will be executed, and then the container will be terminated automatically. Also, -rm option is specified in order to make automatically container deleted when the container is ended.
The above command is an example of the case where SAMPLE.h2.db, which is included in the blank project beforehand, is used as the database. If you do not use SAMPLE.h2.db, you do not need to specify a volume (
-v) for%CD%\\h2:/h2.In addition to the above, in On-demand batch The blank project
./work/formatand./work/outputare mounted in a container.Even for Messaging Using Tables as Queues, the
-it optionof the docker command can be omitted, but the batch cannot be killed by ctrl+c from the docker host. In that case, exit the container with the following command.docker stop myapp-container-batch- About Docker
Running Docker assumes that you are using Docker Desktop (see Prerequisite). If you are using the Docker Toolbox, the volume specification in the above example will fail.
If you are using the Docker Toolbox, Docker is running in a VM on VirtualBox. Therefore, the path that can be specified on the host side of the volume is the path on the VM.
On Windows, by default
C:\Usersis mounted in/c/userson the VM. Thus, if you are using the Docker Toolbox, you must specify the volume as-v/c/users/path/to/project/h2:/usr/local/tomcat/h2.- About H2 and tools
- For information on the method of confirming the data of H2 and tools included in the blank project, see Initial Setup Procedure Supplementary Information.