Oracle Linux - remove containers from Docker

In our examples we are running a Docker engine on an Oracle Linux host which we use to explain how you can work with Docker and containers. In this example post we do have the need to remove a number of stopped containers which are still present on our Docker engine. One way of doing application updates in a container manner is to use a mechanism to start containers with the newer version of your application and when started add them to the load balancing mechanism of your footprint and exclude the old version. As soon as the new version is receiving the requests you can stop de old containers. To ensure you can do a quick rollback it can be useful to have the old containers hanging around for some time. Other options are to do rolling upgrades in which you only have a partial update and only 50% of your containers are updated as well as other strategies for updating which become extremely easy when working with containers.

In this example we have a number of containers we want to remove a number of containers that are no longer running. We identify the containers by using the "docker ps" command as shown below in combination with a grep;

[root@localhost log]# docker ps -a|grep Exited
21600ca72b4e        oracle/nosql        "java -jar lib/kvstor"   12 hours ago        Exited (143) 12 hours ago                                  kvlite3
388910430cee        oracle/nosql        "java -jar lib/kvstor"   12 hours ago        Exited (143) 12 hours ago                                  kvlite2
d6c2e4d9431a        oracle/nosql        "java -jar lib/kvstor"   12 hours ago        Exited (143) 12 hours ago                                  kvlite
[root@localhost log]# 

now we know that we want to remove the above mentioned containers, not only stop them, also remove them. This can be done with docker rm. In the below example we remove only a single container with the "docker rm" command;

[root@localhost log]# docker rm 21600ca72b4e
21600ca72b4e
[root@localhost log]#

if we now check the number of containers with the state exit we will notice that only two are left and we have removed one from our Docker engine.

[root@localhost log]# docker ps -a|grep Exited
388910430cee        oracle/nosql        "java -jar lib/kvstor"   12 hours ago        Exited (143) 12 hours ago                                  kvlite2
d6c2e4d9431a        oracle/nosql        "java -jar lib/kvstor"   12 hours ago        Exited (143) 12 hours ago                                  kvlite
[root@localhost log]#

As shown in other examples, we can provide the docker command with a range of container ID's to take the same acton. The same is the case for the rm command which we can provide a number of container ID's and they will all be removed in a single action. This is shown in the example below;

[root@localhost log]# docker rm 388910430cee d6c2e4d9431a
388910430cee
d6c2e4d9431a
[root@localhost log]#

This results in our case in no results if we check for containers with the state Exited. This is shown in the example below:

[root@localhost log]# docker ps -a|grep Exited
[root@localhost log]#

Keeping container around on your Docker engine for some time when you do an application upgrade can be very good practice in case you need to be able to do an extreme fast rollback when things go wrong. However, keeping them around during an upgrade is no excuse of not doing housekeeping and keeping your IT footprint clean. This means that at one point in time you need to have a cleanup step in your rollout and deployment plan. The above example shows how to remove a container which is stopped. Other posts on this blog explain how to stop and again start containers when needed. Taking options like this in mind when creating a deployment and upgrade strategy can be vital to ensure a secure application upgrade with options to undertake a rollback extremely fast.