Dockerfile – RUN rm not working! ex: ‘RUN rm -rf /usr/local/tomcat/webapps/ROOT’

Dockerfile – RUN rm not working! – I was going completely bananas trying to find out why a simple Dockerfile command wasn’t working.

Here is my example Dockerfile:

FROM tomcat:9
LABEL maintainer "reuben_xxx@xxx.edu"
COPY tomcat-users.xml /usr/local/tomcat/conf/
COPY server.xml /usr/local/tomcat/conf/
COPY web.xml /usr/local/tomcat/conf/
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF
COPY ROOT.war /usr/local/tomcat/webapps/
RUN rm -rf /usr/local/tomcat/webapps/ROOT
RUN rm -rf /usr/local/tomcat/webapps/docs
RUN rm -rf /usr/local/tomcat/webapps/examples

These last three lines, were failing during the build, as shown here:

$ docker build -t app_name .

Sending build context to Docker daemon 52.55MB
Step 1/10 : FROM tomcat:9
9: Pulling from library/tomcat
9f0706ba7422: Pull complete
d3942a742d22: Pull complete

Step 7/10 : COPY ROOT.war /usr/local/tomcat/webapps/
---> 485815d97f89
Removing intermediate container 5ef00497c970
Step 8/10 : RUN rm -rf /usr/local/tomcat/webapps/ROOT
---> Running in 61594cd2432e
rm: cannot remove ‘/usr/local/tomcat/webapps/ROOT/WEB-INF’: Directory not empty
The command '/bin/sh -c rm -rf /usr/local/tomcat/webapps/ROOT' returned a non-zero code: 1

After some heavy google digging, which turned up a false report that this was a docker bug, I found the answer by typing docker info on the command line. Notice the warning message at the bottom of the output.

$ docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 7
Server Version: 17.05.0-ce
...
WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
Reformat the filesystem with ftype=1 to enable d_type support.
Running without d_type support will not be supported in future releases.

I ran the same Dockerfile build on a system where the file system supported d_type and the Dockerfile build worked fine. The rm (remove) command worked without error.

Before getting too deep into docker, you should ensure your filesystem supports d_type – use OverlayFS storage driver.

The file system should be formatted with ftype=1 or d_type=true. Docker will not support running without d_type support in future releases.

Feel the breeze!
Reuben

Link docker containers via their internal ip address

There could come a time when you’ll need to link two or more docker containers. For example, you have a database and a web-service running in separate docker containers. The web-service needs data from the database to serve up its services to a third container which is running a tomcat website. This is known as a ‘micro service application architecture‘.

Let’s link docker containers!

Here’s a simple example of two containers  – one being able to see the other over their own private internal network.

First, let’s spin up a postgres database container in daemon mode (back ground process (-d) ). Let’s name the database container ‘database’.

# docker run -d --name database postgres:latest

postgres

Let’s check to ensure it’s running:

# docker ps

db_running

Yay! There it is…
Now let’s inspect the database container and see the container’s ip address:

# docker inspect database |grep IPAddress

db_ip

As you can see, the database container’s ip address is 172.17.0.10.

Now let’s spin up another container, this time a make believe web-service container running on uBuntu and enter into a bash shell within that container. We will link the web-service container to the database container with the ‘–link’ argument of docker:

# docker run -it --name webservice --link database:db ubuntu:14.04 bash

ubuntu_con

As you can see, I now have a bash shell prompt inside the ‘web-service’ container.

If we check the /etc/hosts file inside the web-service container, we’ll see an entry to the postgres database container. This was automatically added because we used the ‘–link’ argument when we spun up the web-service container.

# cat /etc/hosts

etc_hosts

Please notice the last entry in the /etc/hosts file. You’ll see 172.17.0.10, the database container ip address – cool! This entry will allow the web-services container to communicate with the database container.

The ‘db’ to the right of the database container’s ip address is the alias we assigned in the ‘–link database:db’ argument when we ran the web-service container. ‘database‘ is the our docker name of the postgres container and ‘db‘ is the local alias name we assigned.

Let’s check out the web-service container’s ip address is:

# ifconfig -a |grep inet

web_ip

You’ll notice the web-service container ip address is 172.17.0.12.

OK, let’s try to ping the database container from the web-services container:

# ping 172.17.0.10

ping

As you can see, the web-services container can see the database container!

Hooray, they can see each other!

The web-service container will be able to access the database container.

Eureka!

bash into a running docker container

First off, what the heck is Docker? It’s amazing, that’s what it is…
Check it out – you won’t be sorry…

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications, whether on laptops, data center VMs, or the cloud.

There are several reasons why you might want a bash shell command prompt in a running docker container. One is of course to modify the container and then commit it to a new image.

$ sudo docker exec -i -t 6c3c89dc97d9 bash #by ID
or
$ sudo docker exec -i -t loving_dianne bash #by Name

bash

to exit back to your local-host command prompt:

$ exit