Running Websphere Liberty Profile in a Docker Container
5 min read
Running Websphere Liberty Profile in a Docker Container
I will be demonstrating how to set up a Websphere Liberty Profile (WLP) application server inside of a Docker container. The end result will be one command that runs a custom Docker image with WLP installed and a sample application deployed on it.
Things required for this demonstration:
Now that we have collected all of our resources, we can begin to build our custom Docker image, using a Dockerfile.
The Dockerfile
First, we will select an existing Docker image to use as a starting place. A simple one is Ubuntu 12.04, so the first line of our Dockerfile will read:
FROM ubuntu:12.04
The next step will be to add the required files for this Docker image. This will be the WLP .jar files, the JAXWSEJBSample.jar file. So your next portion of your Dockerfile will look like this:
Now we can include the steps for installing the WLP .jar files and priming our Docker image for running. This will simply be the commands you would run in Linux to install WLP, per the documentation. So the next chunk of your Dockerfile should look like this:
We first update our packages to ensure that the components we require for the Java Runtime Environment are there. Then we install the default JRE and proceed to run the specified .jar files. The last command is per the documentation on running the jpaSample.jar file.
So, just a few finishing touches to our Dockerfile and then we can move on to the next step:
In just two lines, we have a lot going on. The first line exposes the container’s ports. We expose 9080 because that is the port that WLP uses. The second line defines the command that will be run when the Docker image is run in a container. We have placed the command from the documentation on our sample application as the command to run when our container starts.
Putting it all together
Now that we have all our resources in addition to our Dockerfile sitting in our working directory, we can get to actually running some Docker commands. We will start by building the image we just defined with our Dockerfile.
The -t flag allows us to tag our successfully built image with a name. Typically I use the pattern of name/appname. So for instance, alex/wlp. You will see all of the steps defined in our Dockerfile begin to run in the terminal. Once we get the message saying “Successfully built $containerID”. Now we can run our built container using the command docker run
. However, we have two choices at this point, which are to explicitly publish our container’s exposed ports to specified ports on the host machine, or to publish all of our exposed ports to ports determined by Docker. I’ll show both, starting with explicitly publishing our container’s exposed ports:
This command uses the -p flag in order to publish our container’s exposed port 9080 to the host machine’s port of 1930. Meaning that when you hit the host machine’s IP address at port 1930, you will actually be hitting port 9080 on our container. The alternative, which publishes all exposed ports, is as follows:
In order to find out which exposed ports have been published to which host machine ports, we first retrieve the container ID using the docker ps
command, which allows you to see currently running containers. Once we have the container ID, we can run the docker port
command in order to find out the mapping. An example usage in this case would be:
Now that we have run our container, we can check if everything is set up correctly. You should see something similar to the following lines printed in your terminal:
pushing your Docker image
Once you have built and tagged your image, you may want to have access to it on other machines. You can do this by pushing your image to the Docker repository. To do so, you must register a Docker account, and then tag your image with your_username/image_name. Once you have the image tagged with the same name as the account name you created, you can run the command
However, since our Docker container runs proprietary code (WLP), we cannot push it to the public repository. I will show you how to create a private repository that runs on your local machine. Docker has recently made this very simple. In fact, you can run a container that has a docker-registry running in it. Invoke the container with
After Docker pulls the image and runs it in a container, you’ll see gunicorn give you a success message. Now you can push your image to your local repository. First we must tag our image properly, with a tag following the pattern of localhost:5000/project_name. We can achieve that with the following command:
We use localhost:5000 because that is the port we published with the previous run command. If you do not include the port, Docker will treat localhost as a username, such as alex/wlp. Now that the image is properly tagged, we can run
and we should see output similar to this:
A warning about disk space
Docker currently leaves images and containers (even after you have killed a container) on your hard drive, and over time, these old images and containers will fill up your hard disk. I have found two commands online that clean out the old containers and images; I have put them in the following script that I run when I am done working to clean out my hard drive.