Contents


Refactor existing monolithic applications to microservices one bite at a time, Part 2

Migrating the cloud application

Comments

Content series:

This content is part # of # in the series: Refactor existing monolithic applications to microservices one bite at a time, Part 2

Stay tuned for additional content in this series.

This content is part of the series:Refactor existing monolithic applications to microservices one bite at a time, Part 2

Stay tuned for additional content in this series.

Part 1 in this series showed how to migrate the Daytrader3 application from IBM® WebSphere® Application Server Liberty 8.5.5.0 to the latest version of Liberty server. Now, in Part 2, you migrate the Daytrader3 application that is running in an on-premises Liberty 17.0.0.2 server to the cloud platforms of IBM Cloud private (with Docker and Kubernetes) and IBM Cloud Public (with Cloud Foundry). This tutorial examines the necessary code changes that are required to cloud-enable the Daytrader3 application. You also configure and deploy the application on each platform.

Fidelity is mostly maintained between an on-premises and cloud-based Liberty run time. However, because of the dynamic nature of the cloud environment (for example, non-static IP or host name and transient file systems), you must adapt a traditionally more static on-premises application. This tutorial also demonstrates some of the tools, configurations, and methods that are used in deploying an application into the cloud.

To continue with Part 2, you must have completed the steps in Part 1 of this series. This part depends on the workspace and WebSphere Liberty server that you created in Part 1. If you did not complete these steps, you can download the final copy of the workspace and configured server from Part 1 before you continue with Part 2.

Prerequisites

1

Set up the development environment

If you need to deploy the DayTrader application to IBM Cloud Public (Cloud Foundry), follow the instructions to download and install the IBM Cloud CLI.

If you need to deploy the DayTrader application to Docker containers and IBM Cloud Private, you must have access to an IBM Cloud Private environment. We use Docker Community Edition (CE) to create and manage Docker images locally. Download and install Docker CE for your operating system. If you are using older versions of macOS® or Microsoft® Windows®, you might need to use Docker Toolbox and create your own Docker machine.

In Part 1, you created a set of DayTrader projects and have the necessary workspace and Liberty server configuration. If you downloaded the Part1Finish.zip file from GitHub, you need to import these projects:

  1. Import the DayTrader projects from the downloaded ZIP file:
    1. From the Eclipse menu, select File -> Import.
    2. In the Import window, expand General, and select Existing Projects into Workspace. Click Next. The import wizard
      The import wizard
  2. In the Import Projects window, click Browse, and locate and select the downloaded ZIP file for Part 1, which includes the daytrader3-ee6, dt-ejb, Rest, and web projects. Click Finish to begin importing the projects into the workspace. Import the existing projects into the workspace
    Import the existing projects into the workspace

    After the project import is completed, the workspace migration process might begin.

  3. In the Workspace Migration window, select all four projects (daytrader3-ee6, dt-ejb, Rest, and web), and click Next. Workspace Migration window
    Workspace Migration window
  4. In the Undefined Server Runtime window, make sure that the new WLP-17.0.0.2 server runtime is selected for all of the projects. Click Next. Define the new server runtime
    Define the new server runtime
  5. Click Finish to complete the workspace migration.

You have now imported the projects from Part 1, and you can continue with your migration to the cloud.

2

Run the WebSphere Application Server Migration Toolkit

The WebSphere Application Server Migration Toolkit Eclipse plug-in analyzes source code and configuration files for known migration issues. In this step, you use the migration tool to look for known issues when migrating from Liberty to IBM Cloud Public or Docker:

  1. Open the DayTrader application workspace in Eclipse.
  2. Run the WebSphere Application Server Migration Toolkit. Click Run -> Analysis.
  3. In the Software Analyzer Configurations window, select Software Analyzer in the left column, and then, click the New icon (first icon on the left side above the filter box. In the right pane, for Name, enter a suitable name for the configuration. On the Scope tab, click Analyze entire workspace. Create, manage, and                     run configurations - Scope tab
    Create, manage, and run configurations - Scope tab
  4. On the Rules tab, for Rule Sets, select Cloud Application Migration, and then click Set. Create, manage, and                     run configurations - Rules tab
    Create, manage, and run configurations - Rules tab

    Important: If you are following the steps for both IBM Cloud Public and Cloud Private migration, perform the analysis only for IBM Cloud Public. The IBM Cloud Public results are a superset of the Docker results, and the final code modification that is required for both are the same.

  5. In the Rule set configuration window, to migrate to IBM Cloud Public for Cloud Foundry, make the following changes:
    1. For Target application server, select Liberty.
    2. For Target cloud runtime, select IBM Cloud Instant Runtimes (Cloud Foundry).
    3. For Target Java version, select IBM Java 8.
    4. Click OK.

    To migrate to IBM Cloud Private for Docker, make the following changes:

    1. For Target application server, select Liberty.
    2. For Target cloud runtime, select Docker (IBM Containers).
    3. For Target Java version, select IBM Java8.
    4. Click OK.
  6. Back in the Software Analyzer Configurations window, click Apply to save the changes, and then click Analyze to initiate the analysis.Rules selection
    Rules selection

When the analysis is complete, the Software Analyzer Results window shows the XML File Review, File Review, and Java Code Review tabs.

Software Analyzer Results window
Software Analyzer Results window
3

Resolve Java code, JSP code, XML file, and file problems

To resolve Java code review problems, in the Software Analyzer Results panel, on the Java Code Review tab, expand the Cloud migration tree. As shown in the following figure, you see the Java code issues for specific code files.

Java code issue details
Java code issue details

Double-click the files that are listed in the tree to jump to the code where the migration issue is detected. You can also select Help -> Show Contextual Help to open the Help window and view an explanation of the migration issue. For more information about the issue and recommended solutions, click the Detailed Help link.

Migration issue detail help
Migration issue detail help

The following sections help you to understand each of the migration issues that are identified by the scanner. You can then implement the recommended solution to migrate the application for cloud deployment. These solutions encompass scan results for both IBM Cloud Public (Cloud Foundry) and Docker migration issues. Where applicable, a different analysis is explained, and solutions are specified for each platform.

Migration rule: Validate the URL host and port for cloud access

The Validate the URL host and port for cloud access rule warns you that a Java string literal is in the code that includes a host and a port. If that host and port are on an external system, you might experience connectivity issues. The affected platforms are IBM Cloud Public (Cloud Foundry) and IBM Cloud Private (Docker/Kubernetes).

Analysis

If you double-click the PingServlet2PDF.java file in the Java Code Review pane to open the file, you see the URL http://localhost:9080/daytrader/WAS_V7_64-bit_performance.pdf. This URL references a PDF that is internal to the application. This PDF will move to the cloud with the Daytrader3 application. However, the URL will be different in the cloud. Therefore, you need to make some coding changes.

Solution

To solve this problem, change the code to the correct URL, or even better, externalize the URL and look it up from the application. By using the latter option, you can change the URL without changing the application source code. You have the following options to externalize the URL:

  • Define the URL in the system environment variable, and read it by using the System.getenv() property.
    • IBM Cloud Public (Cloud Foundry). You can set environment variables by using the manifest.yml file during deployment. Alternatively, you can set it post-deployment by using the bx cf set-env command.
    • Docker. You can set the environment variables by using the -e or -env option on the docker run command. Alternatively, you can use the --env-file option on the docker run command with an env.list file. For more information, see the docker run command reference.
    • IBM Cloud Private. You can set the environment variables by using the Kubernetes administrative console (shown later in this tutorial) or the kubectl CLI. For information about using the kubectl CLI, see the examples in Define Environment Variables for a Container and Expose Pod Information to Containers Through Environment Variables.
  • Define the URL in the jvm.options file, and read it by using the System.getProperty() property.
  • Define the URL in the Java Naming and Directory Interface (JNDI) env-entry in the server.xml file, and look it up by using the JNDI.
  • Define the URL in a properties file in the ${server.config.dir}/resources folder, add references to the properties file in the server.xml file, and load the properties from the class path by using the Class.getResourcesStream() property.

The best practice is for the application to read an environment variable, which you can accomplish by using the option to define a URL in the system environment variable. We describe the YAML (.yml) file construction for Cloud Foundry later in Step 4. We only externalize the endpoint and context root portion of the URL because the actual PDF file location within the application itself will be constant regardless of where we deploy to.

To implement the code change for the first option (to define the URL in the system environment variable), in Eclipse:

  1. In Enterprise Explorer, open the /Java Resources/src/com.ibm.websphere.samples.daytrader.web.prims/PingServlet2PDF.java file if it is not already opened.
  2. Change the following line of code in the doGet() method:
     String fileURL = "http://localhost:9080/daytrader/WAS_V7_64-bit_performance.pdf")

    Change it as shown here:

     String fileURL = System.getenv("DAYTRADER3_CONTEXT_ROOT_URL") + "/WAS_V7_64-bit_performance.pdf";
  3. Save and close the file.

Migration rule: Capture log information

The Capture log information rule detects the use of Apache Commons Logging. It warns you that any log messages that are written to the local file system might be lost because the local file system is short lived. The rule applies if the application is running. The rule no longer applies if the application stops. The impacted platform is IBM Cloud Public (Cloud Foundry).

Analysis

The Daytrader3 application uses the default simple logger. It writes log messages to SYSERR. IBM Cloud logging automatically collects messages that are written to SYSERR.

Solution

The Capture log information rule reports a false positive. Therefore, no changes are required.

Migration rule: HTTP session persistence

The problem or potential problem with the HTTP session persistence rule is that HTTP sessions are not persisted or replicated in cloud platforms. This migration rule impacts IBM Cloud Public (Cloud Foundry).

Analysis

Local sessions impact the ability to fail over without losing your session. If the Daytrader3 application requires HTTP session persistence, you can configure it to use the SessionCache service or a relational database service to store the session data.

Solution

The application does not require distributed sessions. You can ignore this problem.

Migration rule: Two-phase commit transactions

The two-phase commit transactions rule warns you that the application is using two-phase commit. It also warns you that the transaction log file becomes lost if the transaction log is written to the local file system. The impacted platform is IBM Cloud Public (Cloud Foundry).

Analysis

A lost transaction log impacts the ability to recover the database. If the Daytrader3 application requires transaction recovery after failures, you can configure it to write its transaction log file to a relational database instead of the local filesystem. For more information, see the Liberty: storing transaction log file in a relational database topic in the WebSphere Application Server for z/OS Liberty documentation in IBM Knowledge Center.

Solution

This application is designed to re-populate the tables before each run. Therefore, this application does not require a more durable database. For that reason, you can safely ignore this problem.

Migration rule: Java Message Service and message-driven beans

The Java Message Service (JMS) and message-driven bean (MDB) rule warns you that the application is using a messaging provider that might be left on-premises. In this case, you might need to move the messaging provider to the cloud or establish a connection from the cloud to the messaging provider. The impacted platforms are IBM Cloud Public (Cloud Foundry) and IBM Cloud Private (Docker/Kubernetes).

Analysis

The Daytrader3 application runs the JMS provider in the same Liberty container as the application. The application connects to the messaging engine over API calls. In this configuration, you do not need to resolve any connectivity issues when the messaging provider is moved to the cloud.

Also, the Daytrader3 application stores the messages in the local file system of the Liberty container. When the container stops, the message store is removed, and the messages are lost. If the DayTrader application needs a more durable message store, you can configure it to use IBM MQ Light or some other messaging provider.

Solution

You can reset DayTrader before each run so that this problem does not impact the intended use of the application. Therefore, you can safely ignore this problem.

Migration rule: Database

The Database migration rule warns about a potential connectivity issue to a remote database server. If the database is not moved with the application, you must change the server configuration and resolve the connectivity issues. The impacted platforms are IBM Cloud Public (Cloud Foundry) and IBM Cloud Private (Docker/Kubernetes).

Analysis

The Daytrader3 application uses the Derby embedded database. Therefore, the database server runs in the same Liberty container as the application. You do not have any connectivity issues to resolve.

Also, the Derby contents of the database are stored under the Liberty server's config folder. This folder exists only if the application is running. If the application stops, you lose that folder and the database that is in it. If the Daytrader3 application needs a more durable database, you can configure it to use DashDB or similar database.

Solution

The application is designed to re-populate the tables before each run. This problem does not impact the intended usage of the application. So, it can be safely ignored.

Deployment note: Steps 4 and 5 in Part 2 explain how to run the DayTrader3 application. If you are running it on IBM Cloud Public with Cloud Foundry, complete Step 4. If you are running it on IBM Cloud Private with Docker/Kubernetes, complete Step 5. If you intend to run the DayTrader application on both IBM Cloud Public and IBM Cloud Private, complete both Steps 4 and 5.

4

Run DayTrader on IBM Cloud Public (Cloud Foundry)

This step explains how to deploy and run the DayTrader application on IBM Cloud Public (Cloud Foundry). You learn how to construct the deployable package; use the command interfaces; configure IBM Cloud Public (Cloud Foundry); and test, troubleshoot and manage the application on IBM Cloud Public (Cloud Foundry).

4a

Create the manifest.yml file

For a more consistent and reproducible deployment to the Cloud cloud environment, you create a manifest.yml to define the deployment configurations. For simplicity, the manifest.yml file is in the Eclipse project for the DayTrader application. Complete the following steps in Eclipse:

  1. Create a config folder in the daytrader3-ee6 EAR project.
  2. Right-click the config folder, and select New -> File.
  3. In the New File window, in the File name field, enter manifest.yml, and click Finish. Create the manifest.yml file
    Create the manifest.yml file
  4. Copy the following option values into the manifest.yml file. For more information about the various supported options on IBM Cloud, see the Application manifest topic in IBM Cloud Docs. You must deploy all applications to a unique subdomain that is defined by the host option. Select a unique host name, and enter it in the manifest.yml file (for example: daytrader-ee6-<initials>, daytrader-ee6-<first_last_name>).
                applications:
                - name: daytrader-ee6
                  memory:  512M 
                  disk_quota:  1024M 
                  instances:  1 
                  domain: mybluemix.net 
                  host: <unique_sub_domain>
                  disk_quota:  1024M 
                  env: 
                    DAYTRADER3_CONTEXT_ROOT_URL: "https://<unique_sub_domain>.mybluemix.net/daytrader"

    Notice the DAYTRADER3_CONTEXT_ROOT_URL environment variable that is set and how it corresponds to the host and domain name. The migrated code will use this new environment variable (see Migration rule: Validate the URL host and port for cloud access).

  5. Save and close the file.
4b

Export the deployable archive

Because the migration code changes, you must export a new deployable archive before you deploy the application into the cloud. Complete the following steps in Eclipse:

  1. In the Enterprise Explorer view, right-click the daytrader3-ee6 project, and select Export -> EAR file.
  2. Click Browse and navigate to %HOMEPATH%/wlp/usr/servers/Daytrader3Sample/
    dropins
    .
  3. In the EAR Export window, for Destination, select the existing daytrader3-ee6.ear file. Then, select Overwrite existing file, and click Finish.
Export the DayTrader EAR file
Export the DayTrader EAR file

This step replaces the previously deployed EAR file with a new archive and the code updates.

4c

Log in to IBM Cloud

  1. Open a DOS command window (Windows OS) or Terminal window (Linux, UNIX, or macOS).
  2. Connect to IBM Cloud Public (Cloud Foundry) by using the bx api command. Correct the endpoint URL for the IBM Cloud region you are on. (For more information, see the Regions topic in IBM Cloud Docs.)
    bx api https://api.ng.bluemix.net
  3. Log in to your IBM Cloud account with the bx login command:
    • If you are logging in with an IBMid, use the -u option:
      bx login -u <username> -o <organization> -s <space>
    • If you are logging in with a federated ID, use the -sso option:
      bx login -u <username> -o <organization> -s <space> -sso

    When prompted to complete the login, enter your account password.

4d

Deploy the app to IBM Cloud (Cloud Foundry)

You can deploy the app to IBM Cloud by using the bx cf push command:

bx cf push -f <manifest_path> -p <deployable_path>

For this application, the command looks like the following example:

bx cf push –f %WORKSPACE%/daytrader3-ee6/config/manifest.yml –p %HOMEPATH%/wlp/usr/servers/Daytrader3Sample

This command pushes the Liberty server directory, which includes the application and the database to IBM Cloud. You can deploy the application to IBM Cloud in other ways, but the server package helps to move the server and its application in a single command. For more information about these other options, see the Options for pushing Liberty apps in IBM Cloud Docs.

4e

Confirm the deployment

To confirm the deployment:

  1. Download the messages.log file by using the bx cf ssh command to confirm that the application started:
    bx cf ssh <appname> -c "cat logs/messages.log" > messages.log
  2. Confirm that the application is started by looking for the following message in the messages.log file:
    CWWKZ0001I: Application daytrader3-ee6 started in XX.XX seconds.

You must resolve any deployment problems, for example, if the application does not start or errors are in the messages.log file.

Resolve deployment problems

If you see the following message in the messages.log file, the Derby library is not found in the classpath. The original application added it to the /shared/resources directory in Liberty, which works on premises. However, that directory isn't pushed to IBM Cloud. Therefore, you receive the following ClassNotFoundException message:
DSRA4000E: A valid JDBC driver implementation class was not found for the jdbcDriver jdbcDriver[DerbyEmbedded] using the library DerbyLib

To fix this problem, in the Eclipse Enterprise Explorer view:

  1. Go to the /WLP-17.0.0.2/servers/Daytrader3Sample folder and create a new folder named resources. Then, click Finish. Server resources folder
    Server resources folder
  2. Go to the /WLP-17.0.0.2/shared/resources folder, right-click the data folder, and select Move.
  3. In the Choose destination for 'data' window, select /WLP-17.0.0.2/servers/Daytrader3Sample/resources, and then, click OK. Moving the DerbyDB data folder
    Moving the DerbyDB data folder
  4. Repeat steps 2 and 3 for the Daytrader3SampleDerbyLibs folder under the /WLP-17.0.0.2/servers/Daytrader3Sample/resources folder.
  5. Expand the /WLP-17.0.0.2/servers/Daytrader3Sample folder, and double-click the server.xml file.
  6. From the Eclipse menu, select Edit -> Find/Replace. In the Find/Replace window, in the Find field, enter {shared.resource.dir}, and in the Replace field, enter {server.config.dir}/resources. Then, click Replace All to modify all occurrences. Find/Replace window
    Find/Replace window
  7. Close the Find/Replace window. Then, save and close the server.xml file.

Redeploy the application on IBM Cloud

Repeat the instructions in steps 4c, 4d, and at the beginning of 4e to redeploy the server package to IBM Cloud Public (Cloud Foundry). You should no longer see ClassNotFoundExceptions in the messages.log file.

4f

Confirm that the application is working

  1. Run the application on IBM Cloud. Enter the following URL into the browser. Replace <unique_sub_domain> with the host name that you previously set in the YAML file:
    https://<unique_sub_domain>.mybluemix.net/daytrader/

    You should see the DayTrader home page (see Step 6 in Part 1).

  2. Run one more test to make sure that the change you made to externalize the URL is working. Enter the following URL. Again, replace <unique_sub_domain> with your own host name:
    https://<unique_sub_domain>.mybluemix.net/daytrader/servlet/PingServlet2PDF

    You should now see the PDF as shown in the following figure.

    The PingServlet2PDF                     file
    The PingServlet2PDF file

If the PDF is not displayed, resolve the runtime problems as explained in the following section.

To further test the IBM Cloud deployment of the DayTrader application, follow the instructions in "Step 6: Run the DayTrader application" in Part 1. If you receive any runtime errors, resolve them as explained next.

Resolve runtime problems

If you followed the instructions in this tutorial, you should not have any additional runtime problems to resolve at this point. However, if you find additional problems, you must collect troubleshooting data from IBM Cloud Public (Cloud Foundry):

At a minimum, download and review the messages.log file from IBM Cloud by using the bx command:

 bx cf ssh <appname> -c "cat logs/messages.log" > messages.log

See also the Collect troubleshooting data for WebSphere Liberty for Java on IBM Cloud tutorial from developerWorks.

You are now running the application on IBM Cloud Public with Cloud Foundry. If you also plan to run the DayTrader application on IBM Cloud Private with Docker/Kubernetes, continue with Step 5. Otherwise, you have completed deployment.

5

Run DayTrader on IBM Cloud Private (Docker/Kubernetes)

In this step, you deploy and run the DayTrader application in IBM Cloud private (Docker/Kubernetes). Before you deploy to an IBM Cloud Private environment, you construct a Docker image for the DayTrader application and test it locally on the Docker engine. These Docker steps are compatible with all container engine platforms that are based on Docker (for example: Docker CE, Docker EE, and IBM Cloud Container Service). Then, you propagate the working Docker image into the IBM Cloud Private environment and expose it for public access.

IBM has published an official Liberty image for IBM WebSphere Application Server for Developers users who want to run their Liberty applications in Docker. You can customize the base WebSphere Liberty image in different ways to run the DayTrader application. In this case, you use a Dockerfile so that you can construct a customized image repeatedly with consistency. You see how to use the command interfaces, how to use the GUI administration consoles, and how to test and manage the application in Cloud Private.

5a

Prepare the source code

The code migration that is required for Docker is a subset of the code migration that is required for the IBM Cloud Public (Cloud Foundry). Therefore, if you completed Step 4, you can skip this preparation step. If you skipped Step 4, you must modify your deployable artifacts before you continue with the remaining steps in this section.

In the Eclipse Enterprise Explorer view:

  1. Go to the /WLP-17.0.0.2/servers/Daytrader3Sample folder, and create a new folder named resources. Server resources folder
    Server resources folder
  2. Go to the /WLP-17.0.0.2/shared/resources folder, right-click the data folder, and click Move.
  3. In the Choose destination for 'data' window, select /WLP-17.0.0.2/servers/Daytrader3Sample/resources, and click OK. Moving the DerbyDB data folder
    Moving the DerbyDB data folder
  4. Repeat steps 2 and 3 for the Daytrader3SampleDerbyLibs folder under the /WLP-17.0.0.2/servers/Daytrader3Sample/resources folder.
  5. Expand /WLP-17.0.0.2/servers/Daytrader3Sample, and double-click the server.xml file.
  6. From the Eclipse menu, select Edit -> Find/Replace. In the Find/Replace window, in the Find field, enter {shared.resource.dir}, and in the Replace with field, enter {server.config.dir}/resources. Then, click Replace All to modify all occurrences. Find and replace window
    Find and replace window
  7. Close the Find/Replace window. Then, save and close the server.xml file.

You are now ready to continue the deployment to Docker.

5b

Create a Dockerfile

A Dockerfile describes the commands that you must run to create a new Docker image with a particular set of configurations. To create a Dockerfile that specifies the configurations for the DayTrader Docker image in this tutorial:

  1. Create a config folder in the daytrader3-ee6 EAR project if it doesn't already exist.
  2. Right-click the config folder, and select New -> File.
  3. In the New File window, in the File name field, enter Dockerfile, and click Finish. Create the Dockerfile
    Create the Dockerfile
  4. If you are prompted to select an editor for the Dockerfile, select your preferred editor to use. The default Text Editor is enough for our purposes. Click OK. Dockerfile editor
    Dockerfile editor

    If the new Dockerfile does not open for editing, double-click it in the Enterprise Explorer tree to open it.

  5. Copy the following Dockerfile instructions into the file.
                FROM websphere-liberty:kernel
                COPY wlp/usr/servers/Daytrader3Sample/opt/ibm/wlp/usr/servers/defaultServer
                RUN installUtility install --acceptLicense defaultServer
    • The FROM instruction on the first line indicates to the Docker daemon that this new image will use the websphere-liberty:kernel image as the base image. This image consists of a Docker environment with a Liberty server and IBM JDK installed. For more information about the websphere-liberty image, see the websphere-liberty topic in the Docker hub.
    • The COPY instruction takes a source and a target path argument. The instruction here communicates to the Docker daemon to copy the entire Liberty server folder for the DayTrader sample application into the default Liberty server folder that is created in the websphere-liberty:kernel image. This step is the same as pushing the entire server package as done previously in the IBM Cloud deployment.
    • The RUN instruction starts the Liberty installUtility command to install all of the features that are specified in the server.xml file for defaultServer.
  6. Save and close the Dockerfile.
5c

Build a Docker image for the DayTrader application

  1. Compile all deployable artifacts, and copy them into the same directory. The Docker build refers to this location as the context path. This directory can be temporary or permanent depending on your build management process. For this tutorial, you create a temporary directory. Use your preferred file manager to create a directory at %DOCKERTMPPATH%.
  2. Create a nested folder structure of %DOCKERTMPPATH%/wlp/usr/servers. Create the Docker deployment folders
    Create the Docker deployment folders
  3. Copy the %HOMEPATH%/wlp/usr/servers/Daytrader3Sample directory into the %DOCKERTMPPATH%/wlp/usr/servers directory, which is the local DayTrader Liberty server that you configured and deployed to Cloud Foundry earlier in this tutorial. The resulting location of the Daytrader3Sample within the %DOCKERTMPPATH% directory matches the source path that is specified in the COPY instruction of the Dockerfile. Copied Daytrader3Sample server directory
    Copied Daytrader3Sample server directory
  4. Copy the Dockerfile that you created earlier into the %DOCKERTMPPATH% directory. Copied Dockerfile
    Copied Dockerfile
  5. Open a DOS command window (for Windows OS) or a Terminal window (for macOS, Linux OS, or UNIX OS), and go to the %DOCKERTMPPATH% directory.

    Run the following basic docker build command:

    docker build -t <tag_name>
                     <context_path>
    • The -t <tag_name> creates a tag for the custom image. Docker tags have many uses, but mostly for version clarifications and registry specification. Because the image is based on the websphere-liberty:kernel image, you set a tag here to clarify that the image is a customization for the DayTrader application that is deployed.
    • <context_path> is the root directory where you will obtain all source artifacts that are specified in the Dockerfile. The contents of the directory are sent to the Docker daemon recursively in the beginning of each build. In this case, the context path is %DOCKERTMPPATH%. Because you are running the Docker CLI from %DOCKERTMPPATH%, the docker build command looks similar to this example:
      docker build –t wlp-daytrader-ee6 .

    The output for the build process consists of downloading the websphere-liberty:kernel image, copying the files, and installing the required Liberty features. You see a message at the end of the build process similar to the following example.

    Docker build result
    Docker build result
  6. Run the docker images command to verify that the wlp-daytrader-ee6 image is available. You see that the websphere-liberty:kernel image is downloaded and also available. Docker images wlp-daytrader-ee6
    Docker images wlp-daytrader-ee6
  7. Verify that the newly built image is running in a container:
                docker run --name wlp-daytrader-ee6 \
                -p 9080:9080 \
                -e "DAYTRADER3_CONTEXT_ROOT_URL=http://localhost:9080/daytrader"  \
                -d wlp-daytrader-ee6

    Note the following parameters:

    • --name: The name you want to assign to the container.
    • -p: To publish a container port to a host port. In this case, port 9080 on the container is available to the host that is using port 9080.
    • -e: The environment variable is set into the operating system of the container. We set this variable because we externalized the host and context root of the DayTrader application into an environment variable when migrating the application.
    • -d: To detach the container to run in the background and print the container ID.
    Running the wlp-daytrader-ee6 container
    Running the wlp-daytrader-ee6 container
  8. Verify that the container is running:
                        docker ps –a
    The wlp-daytrader-ee6 container status
    The wlp-daytrader-ee6 container status
  9. Display the Docker container log file, which shows the Liberty server messages. Make sure that the DayTrader application started successfully.
    docker logs –f –-tail=all wlp-daytrader-ee6
    The wlp-daytrader-ee6 server log
    The wlp-daytrader-ee6 server log
  10. Press CTRL+C to exit the log tail session.
  11. Verify that you can access the home page of the DayTrader application in a browser by using the URL http://localhost:9080/daytrader.
  12. Verify the application by accessing the URL http://localhost:9080/daytrader/servlet/PingServlet2PDF. You should see the PingServlet2PDF file.
  13. After you verify that the DayTrader docker image is up and running successfully in Docker, stop the container:
    docker stop wlp-daytrader-ee6
5d

Add a DayTrader docker image to the Cloud Private registry

Now that you have a DayTrader docker image that was tested in an on-premises Docker container, you continue to deploy it into an IBM Cloud Private environment. Tag and push the DayTrader Docker image that you created in the previous sections to the Cloud Private Docker registry:

  1. In a DOS command window (Window OS) or a Terminal window (macOS, Linux OS, or UNIX OS), log in to the Cloud Private Docker registry. Be sure to use a user with proper permissions.
    docker login <cloud_private_host:port>
    Log in to Cloud Private
    Log in to Cloud Private
  2. Tag the wlp-daytrader-ee6 image to the Cloud Private Docker registry:
    docker tag wlp-daytrader-ee6 <cloud_private_host:port>/default/wlp-daytrader-ee6
  3. Push the image to the Cloud Private Docker registry:
    docker push <cloud_private_host:port>/default/wlp-daytrader-ee6
    Push the image to Cloud Private
    Push the image to Cloud Private
  4. Log in to your Cloud Private console. In the upper-left corner, click the Menu icon, and select Infrastructure -> Images to verify that your image has loaded. Images list
    Images list
5e

Deploy the DayTrader application on Cloud Private

To deploy the Docker image of the DayTrader application by using the IBM Cloud Private console:

  1. In the upper-left corner, click the Menu icon, and select Workloads -> Applications.
  2. Click the Deploy Application button on the right side, above the application list. Deploy Application button
    Deploy Application button
  3. On the Deploy New Application page, on the General tab, enter a name for the application. In this example, we enter wlp-daytrader-ee6. Enter the application name
    Enter the application name
  4. On the Container Settings tab:
    1. Enter the container name and image. The image name must match an image in the Cloud Private Docker registry. In this case, the image is the one that you just tagged and pushed, and it must have the name of <cloud_private_host:port>/default/wlp-daytrader-ee6. Define the container settings
      Define the container settings
    2. Specify the ports that you want the container to expose to the proxy. Scroll down, and in the Container Port field, enter 80. Specify the container port
      Specify the container port
  5. On the Environment Variables tab, add a variable named DAYTRADER3_CONTEXT_ROOT_URL with the value http://localhost:9080/daytrader. Select the environment variables
    Select the environment variables
  6. Click Deploy in the lower right corner to begin the deployment.
5f

Configure the DayTrader application for external access

To access the application by using a browser with the proxy, configure External Access to generate a service for the application.

  1. In the Cloud Private console, from the Menu icon, select Workloads -> Applications. Notice that the wlp-daytrader-ee6 application is now listed and started.
  2. Click the Settings icon, and then click Expose. The Expose option
    The Expose option
  3. On the Expose Application page, under Expose method, select Ingress. Then, enter a TCP port mapping for http from port 80 to target port 9080. Click Expose to complete the service creation. The Expose Application page
    The Expose Application page
  4. Back in the Cloud Private Console, from the Menu icon, select Workloads -> Services. Notice that the wlp-daytrader-ee6 service is shown. The Services list
    The Services list
  5. Click the Menu icon, and select Workloads -> Applications. Click the wlp-daytrader-ee6 application to see the application details.
  6. On the application Overview page, scroll down to the Expose Details section. Click the access http link to open the Welcome to Liberty page for the Liberty server that is hosting the DayTrader application. The Application                     endpoint
    The Application endpoint
5g

Confirm that the application is working

Now that the custom DayTrader docker image is deployed and exposed in the IBM Cloud Private environment, you are ready to test the DayTrader application:

  1. To open the DayTrader application that is running in the IBM Cloud private environment, append the context path daytrader/ to the publicly exposed Liberty server URL. Verify that the DayTrader main page is reachable.
  2. Verify the application by appending servlet/PingServlet2PDF to the DayTrader application URL. You now see the PingServlet2PDF file.
  3. Follow the instructions in "Step 6: Run the DayTrader application" in Part 1 of this series to further test the IBM Cloud deployment of the DayTrader application.

You can download the final workspace for Part 2 from GitHub.

Conclusion

You have now migrated the on-premises version of the Daytrader3 application to a cloud environment. As part of this process, additional efforts were needed to augment the existing application code to accommodate the dynamic and transient natures of the cloud hosting solutions. You also created new deployment artifacts for the new cloud environments.

Now continue with Part 3 in this series, in which you automate the application build environment and continuous integration process.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Middleware, Cloud computing
ArticleID=1049837
ArticleTitle=Refactor existing monolithic applications to microservices one bite at a time, Part 2: Migrating the cloud application
publish-date=09192017