Software AG Products 10.7 | Administering Integration Server | Using Integration Server with Docker | Building the Docker Image for an Integration Server Instance
 
Building the Docker Image for an Integration Server Instance
Building a Docker image for Integration Server consists of:
*Creating a Dockerfile for the Integration Server instance. This Dockerfile contains system (Wm*) packages and core functionality.
*Building a base Docker image for Integration Server using the Dockerfile with the core functionality and system packages.
*Creating a Dockerfile with the base image created in the step above for custom packages to include in the Integration Server image.
*Building a Docker image for Integration Server image using the custom packages Dockerfile. The resulting Docker image contains core functionality, system packages, and custom packages.
Note:
If you use automatic package deployment, you do not need to create an image for custom packages. Instead, create the base image and an image containing the Default package. Then use the automatic package deployment feature to add packages to the Microservices Runtime or Integration Server running in a Docker container. For more information about automatic package deployment, see .
Before building an Integration Server image to use with Docker containers, make sure to complete the prerequisites listed in Prerequisites for Building a Docker Image.
For information, including prerequisites, about using an Integration Server running in a Docker container as the local development server for the local service development feature in , see webMethods Service Development Help.
Note:
The Dockerfile created by Integration Server contains metadata about the Integration Server instance used for the image in the Dockerfile. The metadata appears as a Label in the Dockerfile and includes the name, product version, product build number, and primary port of the instance.
*To create a Docker image for Integration Server
1. Go to the Software AG_directory\IntegrationServer\docker directory.
2. Create a Dockerfile for the core of an Integration Server instance using one of the commands below. The Dockerfile is created in Software AG_directory.
*Create a Dockerfile that specifies your choice of JDK or JRE and as many Wm packages as you want to include (that is, system packages and hosted product packages, such as Trading Networks Server) by running the createDockerFile command below. The file is stored in the Software AG directory.
is_container.sh/bat createDockerfile [optional arguments]
Argument
Description

-Dimage.name= baseImageName
Optional. Base image such as ubuntu or centos:8.
Default: centos:8
For an Integration Server running on Windows, the -Dimage.name parameter should be set as follows:
-Dimage.name=mcr.microsoft.com/windows/servercore:YourOsImageTag
Where YourOsImageTag is the tag for the Windows image created for the OS version on which Integration Server runs.

-Dinstance.name= instance_ name
Optional. Integration Server instance to include in the image.
Default: default (The instance named default.)

-Dport.list= ports
Optional. Comma-separated list of the ports on the instance to expose in the image.
Default: Integration Server uses the port numbers assigned to the primary, diagnostic, and default secure port.

-Dpackage.list= Wm packages
Optional. Comma-separated list of Wm packages on the instance to include in the image.
Default: all (this includes all of the Wm packages and the Default package)

-Dinclude.jdk={true|false}
Optional. Whether to include the Integration Server JDK (true) or JRE (false) in the image.
Default: true

-Dfile.name= Dockerfile_name
Optional. Filename for the generated Dockerfile.
Default: Dockerfile_IS

-Dtarget.configuration=
configuration_name
Optional. Target configuration of Integration Server for which the Dockerfile is being created.
Default: There is no default value for this parameter.
If the Dockerfile is for an Integration Server that will be used as the local development server, specify: localdev
For more information about using an Integration Server running in a Docker container as the local development server for the local service development feature in , see webMethods Service Development Help.
If the Dockerfile is for an Integration Server that will be used with OpenShift, specify: OpenShift
When -Dtarget.configration=OpenShift, the is_container.bat/sh script creates a root group that has read, write, and execute permissions. This is needed because OpenShift runs Docker containers using an arbitrarily assigned user ID. To support running of the container by an arbitrary user, a root group needs to own the directories and files that might be written to by the processes in the Docker image, the root group must have read/write access to the directories and files, and the root group must have execute permissions to the files that can be executed.
If the Dockerfile is for an Integration Server instance that will be lifted and shifted into Integration Cloud, set to: wmcloud
When this parameter is set to wmcloud, the is_container script overwrites the default truststore provided with Integration Server with the truststore required by Integration Cloud.

-Dimage.createUser={true|false}
Optional. Sets a non-root user for the ownership of the files in the Docker image. When-Dimage.createUser is set to true, Integration Server creates a Docker image for which a sagadmin user has ownership of the files in the Docker image. The default value of the parameter is false.
Default: false
Note:
This option applies on operating systems other than Windows and requires Docker version 17.09 or higher.
Note:
If -Dtarget.configuration=OpenShift, the script sets -Dimage.createUser to false automatically.
*Create a Dockerfile that includes only a JRE and only the minimum system packages required for Integration Server to operate (WmRoot, WmPublic, and WmCloud) by running the createLeanDockerfile command below.
is_container.sh/bat createLeanDockerfile [optional arguments]
The optional arguments are -Dimage.name, -Dinstance.name, -Dport.list, -Dfile.name, -Dtarget.configuration, and -Dimage.createUser.
3. Build a Docker image with the core Dockerfile by running the build command below. The image is stored in the local Docker registry.
is_container.sh/bat build [optional arguments]
Argument
Description
-Dfile.name= Dockerfile_name
Optional. Filename of the Dockerfile to use to build the Docker image.
Default: Dockerfile_IS
-Dimage.name= Docker_ image_name
Optional. Name for the generated Docker image.
Default: is:micro
4. Create a Dockerfile that specifies the custom packages to include in the Docker image by running the createPackageDockerfile command below. The Dockerfile for the custom packages is stored in the Software AG_directory/ Integration Server_directory /instances/instance name/packages directory.
is_container.sh/bat createPackageDockerfile [optional arguments]
Argument
Description
-Dinstance.name= instance_name
Optional. Integration Server instance that includes the user-defined packages.
Default: default (The instance named default.)
-Dimage.name= Docker_image_name
Optional. Name of the core Integration Server image on which this image should be built.
Default: is:micro
-Dpackage.list= packages
Optional. Comma-separated list of the custom packages to include in the image.
Default: all
“all” indicates that the image for packages will include all the custom packages on the Integration Server instance. The Default package and packages beginning with “Wm” will not be included in the image.
Note:
Make sure to include any custom packages containing services that you want to expose to consumers when Integration Server runs in a Docker container in Integration Cloud. If you do not include a package that contains an exposed service a request for the service fails with a service not found error when Integration Cloud redirects the request to the Docker container.

-Dimage.createUser={true|false}
Optional. Sets a non-root user for the ownership of the files in the Docker image. When-Dimage.createUser is set to true, Integration Server creates a Docker image for which a sagadmin user has ownership of the files in the Docker image. The default value of the parameter is false.
Note:
This option applies on operating systems other than Windows and requires Docker version 17.09 or higher.
-Dfile.name= Dockerfile_name
Optional. Filename for the Dockerfile that contains the custom packages.
Default: Dockerfile_IS_Pkg
Note:
If you are using automatic package deployment you can skip the above step. Instead, once Microservices Runtime or Integration Server running in a Docker container, you can place custom packages in the folder on the HOST machine that is mapped to the autodeploy folder. For more information, see Developing Microservices with webMethods Microservices Runtime. .
5. Build the Docker image with the custom packages Dockerfile by running the buildPackage command below. The image is stored in the local Docker registry. The resulting Docker image contains custom packages, system packages, and the core Integration Server functionality.
is_container.sh/bat buildPackage [optional arguments]
Argument
Description
-Dfile.name= Dockerfile_name
Optional. Filename for the Dockerfile that contains the custom packages.
Default: Dockerfile_IS_Pkg
Docker build uses the file with the specified name located in the packages directory of the specified instance, specifically: Software AG_directory/ Integration Server_directory /instances/instance name/packages/
-Dimage.name= Docker_image_name
Optional. Name for the generated Docker image that contains the custom packages.
Default: is:microPkg
6. Optionally, based on your requirements, execute one or more of the following command line arguments:
*saveImage to save an Integration Server image to a file. For more information about saveImage, see Loading a Docker Image to an On-Premise Docker Registry.
*loadImage to load an image to a Docker registry. For more information about loadImage, see Pushing a Docker Image to an On-Premise Docker Registry
*pushImage to push an Integration Server image created for an on-premise Integration Server to the Integration Cloud or a Docker registry. For more information about pushing an image to a Docker registry or Integration Cloud, see Pushing a Docker Image to an On-Premise Docker Registry and Pushing the Docker Image to Integration Cloud