To make your container able to communicate with the outside world, whether another server or another Docker container, Docker provides different ways of configuring networking. Let's begin with the network types which are available for our containers.

There are three different network types Docker delivers out of the box. To list them, execute the docker network ls command:

$ docker network ls  

Docker will output the list of available networks containing the unique network identifier, its name, and a driver which powers it behind the scenes:

To have an overview of the differences between various network types, let's describe them now one by one.

The parent command for managing networks in Docker is docker network. You can list the whole command set using the docker network help command, as you can see in the following screenshot:

To have a detailed syntax and description of each option available for a specific command, use the -help switch for each of the commands. For example, to get the description of parameters available for docker network create, execute the docker network create -help.

Let's briefly describe each command available:

• $ docker network ls: This is the command we have been using previously, it simply lists networks available for your containers. It will output the network identifier, its name, the driver being used, and a scope of the network
• $ docker network create: Creates new network. The full syntax of the command is, docker network create [OPTIONS] NETWORK. We will use...

Let's create a network. We are going to call our network myNetwork. Execute the following command from the shell or command line:

$ docker network create myNetwork  

This is the simplest form of the command, and yet it will probably be used the most often. It takes a default driver (we haven't used any option to specify a driver, we will just use the default one, which is bridge). As the output, Docker will print out the identifier of the newly created network:

You will later use this identifier to refer to this network when connecting containers to it or inspecting the network's properties. The last parameter of the command is the network's name, which is a lot more convenient and easier to remember than the ID. The network name in our case is myNetwork. The docker network create command takes more parameters, as shown in...

Now we have our myNetwork ready, we can run the Docker container and attach it to the network. To launch containers, we are going to user the docker run --net=<NETWORK> option, where the <NETWORK> is the name of one of the default networks or the one you have created yourself. Let's run Apache Tomcat for example, which is an open source implementation of the Java Servlet and JavaServer pages technologies:

docker run -it --net=myNetwork tomcat  

It will take a while. The Docker engine will pull all of the Tomcat's image layers from the Docker Hub and then run the Tomcat container. There's another option to attach the network to the container, you can inform Docker that you would like the container to connect to the same network as other containers use. This way, instead of specifying a network explicitly, you just...

A common scenario is usually when you want your containerized application to accept incoming connections, either from other containers or from outside of Docker. It can be an application server listening on port 80 or a database accepting incoming requests.

An image can expose ports. Exposing ports means that your containerized application will listen on an exposed port. As an example, the Tomcat application server will listen on the port 8080 by default. All containers running on the same host and on the same network can communicate with Tomcat on this port. Exposing a port can be done in two ways. It can be either in the Dockerfile with the EXPOSE instruction (we will do this in the chapter about creating images later) or in the docker run command using the --expose option. Take this official Tomcat image Dockerfile fragment (note that it has...

As you remember from Chapter 1, Introduction to Docker, the Docker container filesystem is kind of temporary by default. If you start up a Docker image (that is, run the container), you'll end up with a read-write layer on top of the layers stack. You can create, modify, and delete files as you wish; if you commit the changes back into the image, they will become persisted. This is a great feature if you want to create a complete setup of your application in the image, altogether with all its environment. But, this is not very convenient when it comes to storing and retrieving data. The best option would be to separate the container life cycle and your application from the data. Ideally, you would probably want to keep these separate, so that the data generated (or being used) by your application is not destroyed or tied to the container life cycle and...

The basis of volume-related commands is docker volume. The commands are as follows:

• $docker volume create: Creates a volume
• $ docker volume inspect: Displays detailed information on one or more volumes
• $docker volume ls: Lists volumes
• $ docker volume rm: removes one or more volumes
• $ docker volume prune: removes all unused volumes, which is all volumes that are no longer mapped into any container

Similar to network-related commands, you can get the detailed description and all the possible options for each command if you execute it with the -help switch, for example: docker volume create -help. Let's begin with creating a volume.

As you remember from Chapter 1, Introduction to Docker, there's a settings screen in Docker for Windows or Docker for Mac, that allows us to specify which drives Docker can have access to. For a start, let's mark drive D in our Docker for Windows to make it available for Docker containers:

For the purpose of our volume examples, I've created a docker_volumes/volume1 directory on my D drive and created an empty data.txt file inside:

There are two ways to create volumes. The first one is to specify the -v option when running an image. Let's run the busybox image we already know and, at the same time, create a volume for our data:

$ docker run -v d:/docker_volumes/volume1:/volume -it busybox  

In the previous command, we have created a volume using the -v switch and instructed Docker that the host directory d:/docker_volumes/volume1 should...

The same as with creating volumes, there are two ways of removing a volume in Docker. Firstly, you can remove a volume by referencing a container's name and executing the docker rm -v command:

$ docker rm -v <containerName or ID>  

Docker will not warn you, when removing a container without providing the -v option, to delete its volumes. As a result, you will have dangling volumes—volumes that are no longer referenced by a container. As you remember, they are easy to get rid of using the docker volume prune command.

Another option to remove the volume is by using the docker volume rm command:

$ docker volume rm <volumeName or ID>  

If the volume happens to be in use by the container, Docker Engine will not allow you to delete it and will give you a warning message:

As you can see, creating, sharing, and removing volumes in Docker is not...

The same as with network driver plugins, volume plugins extend the capabilities of the Docker engine and enable integration with other types of storage. There are a ton of ready to use plugins available for free on the Internet; you can find a list on Docker's GitHub page. Some of them include:

• Docker volume driver for Azure file storage: This is a Docker volume driver which uses Azure file storage to mount file shares on the cloud to Docker containers as volumes. It uses the network file sharing (SMB/CIFS protocols) capabilities of Azure file storage. You can create Docker containers that can migrate from one host to another seamlessly or share volumes among multiple containers running on different hosts.
• IPFS: Open source volume plugin that allows the use of an IPFS filesystem as a volume. IPFS is a very interesting and promising storage system; it makes...

In this chapter, we have learned about Docker networking and storage volume features. We know how to differentiate between various network types, how to create a network, and expose and map network ports.

We've been through volume-related commands and can now create or remove a volume. In Chapter 3, Working with Microservices, we are going to focus on the software that we are going to deploy using Docker and Kubernetes, and later, Java microservices.