Login
Docker Ep 8: Tomcat: Exploring Docker Port Mapping and Logs
Caution: We are just starting from basics. Even if you don’t understand below concepts there is no problem.
In our previous adventures, we’ve dabbled in Docker’s mysterious arts, running containers, inspecting them, and even detaching them to roam in the background.
Today, we’re stepping up our game by diving into Docker port mapping and the powerful docker logs command. And what better companion for this journey than the Tomcat image, a trusty open-source web server that brings Java servlets to life?
Summoning the Tomcat Image
To begin, we need to summon our new ally: the Tomcat image. Tomcat is a legendary web server that, by default, operates on port 8080 within its container. But what if we want to make this web server accessible to the outside world through a different port? This is where Docker’s port mapping comes into play.
First, let’s visit the Docker Hub and search for the Tomcat image. Once there, we can see that Tomcat will run on port 8080 by default. We’ll need to expose this port and map it to a port on our host machine using the -p option.
Port Mapping: Connecting the Container to the World
Docker port mapping allows us to make the services inside our container accessible from the outside world by forwarding a host port to a container port. The syntax for port mapping is:
-p <host_port>:<container_port>
For example, let’s say we want to map port 8080 inside the container to port 8888 on our host machine. This means that when we access port 8888 on our host, we’ll actually be talking to port 8080 inside the Tomcat container.
Let’s see this in action.
Running Tomcat with Port Mapping
Fire up your Docker terminal, make sure the font size is nice and large, and enter the following command:
docker run -it -p 8888:8080 tomcat:8.0
Here’s what’s happening:
-itruns the container interactively.-p 8888:8080maps port 8080 inside the container to port 8888 on our host.tomcat:8.0specifies the Tomcat image and its version.
Now, sit back and relax (or maybe grab a coffee) as Docker pulls down the Tomcat image. It’s about 300 MB, so depending on your internet connection, this might take a moment.
Once the image is downloaded, Docker will spin up the container, and our Tomcat server will be ready to roll.
Accessing the Tomcat Server
With the Tomcat container up and running, we can access the Tomcat web server through our web browser. But first, we need to know where to find it.
If you’re running Docker on Linux, or using Docker for Mac or Windows, the host IP is simply localhost. If you’re using Docker Machine, you’ll need to grab the IP address of the Docker Machine.
Now, open up your browser, type in localhost:8888 (or your Docker Machine’s IP address followed by :8888), and hit Enter.
The Tomcat console page should greet you warmly.
Running Tomcat in Detached Mode
While running a container in the foreground is great for testing, in production, we typically want our containers to run in the background. For this, we use the -d flag to run the container in detached mode.
Let’s modify our previous command to run Tomcat in the background:
docker run -d -p 8888:8080 tomcat:8.0
After hitting Enter, Docker will return a long container ID, confirming that Tomcat is now running in the background, silently serving up Java servlets.
Checking Container Status with docker ps -a
Curious about the status of your Tomcat container? Use the docker ps -a command to list all the containers on your system, including those that have exited. This is a handy way to check if your container is still running or if it has quietly exited.
docker ps -a
Reading the Tea Leaves: docker logs
Sometimes, you want to peek into the inner workings of your running containers to see what they’re up to. This is where the docker logs command comes in. It lets you view the logs generated by your container, which can be incredibly useful for debugging or just keeping an eye on things.
Let’s say you want to check the logs of your running Tomcat container. You would run:
docker logs <container_id>
There is more on docker logs, we shall see later.
