Cleaning up after Docker – Commands

Cleaning up after Docker – Commands

After playing around with Docker these last few months something that I find annoying is these unused containers and images taking up valuable disk space.

Here are some commands that will help you clean this all up:

Kill all running containers:
$ docker kill $(docker ps -q)

Delete all stopped containers (including data-only containers):
$ docker rm $(docker ps -a -q)

Alternative to previous: Delete old docker containers that have been running in the past (weeks, hours, months, etc…). Vary the word after ‘grep’ to target the containers you want to remove – example: use ‘months’, ‘weeks’, ‘hours’, ‘minutes’, etc… depending on the age of the container that are running. Use docker ps -a to check this first.

$ docker ps -a | grep 'hours' | awk '{print $1}' | xargs --no-run-if-empty docker rm

$ docker ps -a | grep 'weeks' | awk '{print $1}' | xargs --no-run-if-empty docker rm

Delete all ‘untagged/dangling’ (<none>) images:
$ docker rmi $(docker images -q -f dangling=true)

Delete ALL images (be careful with this):
$ docker rmi $(docker images -q)

Enjoy Docker!

Checking for an open / listening port

Checking for an open / listening port….

I’ve had many occasions dealing with network administrators asking them for ports to be open on the firewall so outside users can connect and communicate with various web services. For example, when putting a tomcat site up on port 8080 (this could easily be port 80, 443 or any other port for that matter). I needed the network admin to open port 8080 on the firewall to the outside world…

At that point, if I still could not connect to the website, I needed a way to debug. My first question was always, ‘did he open the port?’, and ‘is the website listening on the correct port 8080?’

How do I really know if the port is open / listening?? How do we know for sure if the firewall rule was done properly and working?

Well here’s a trick I learned using telnet which is readily available on most machines, Windows, Mac, Linux, Red Hat, etc….

At any command prompt type:
# telnet <fill-in-the-ip-address-or-dn-name-here> 8080

<fill-in-the-ip-address-or-dn-name-here> should be the ip address or the domain name of the server that you are testing connectivity to.

For example:

telnet_1

You will receive a different response depending on the host’s operating system you’re typing the telnet command on. Also, the response will vary depending on if the port is open or close and there is a service listening on the port.

In Windows, a response like this means the port is open and listening on the targeted server and port:

telnet_2

After the telnet command the screen will go blank if the port is open / listening.

In Unix / Linux the response will look like this if the target port is open and listening:

telnet_4

In both Windows and Unix style operating systems, if the port is not listening the response will look something like this:

telnet_3

In other words, there really won’t be any response. It will just freeze at the ‘Connecting to’ xxx.xxx.xxx.xxx line.

Enjoy!

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!

Stop uBuntu from asking for your sudo password

If you’re like me and are tired of having to enter your sudo password each and every time you run a sudo command please find the steps below to ease your frustrations on this matter.

Please note, this is not recommended for public access computers or work computers. This is a nice modification for home uBuntu systems.

Launch a terminal window. I use putty remotely or uBuntu terminal locally.

$ sudo visudo

visudo is a command used to edit the config for sudo.

Go to the bottom of the config file and add this:

username ALL=NOPASSWD: ALL

username’ should be replaced with the username of the user you want to allow a passwordless sudo. So if the user is reuben, you would enter:

reuben ALL=NOPASSWD: ALL

Save and exit – log out and log back in as the user and test out the passwordless sudo access.

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