Welcome to this lesson on container-to-container communication using Docker. In previous lessons, you learned how containers communicate with external services, like the internet, and directly with the host machine. Building on that foundation, we will now focus on establishing communication between the containers themselves. Understanding how to set up and facilitate container communication is crucial for developing applications that consist of multiple interdependent services. By the end of this lesson, you will know how to create a Docker network and connect containers to it, allowing them to communicate seamlessly within a defined environment.

To begin, let's create a user-defined network in Docker. User-defined networks provide greater flexibility and control compared to Docker's default bridge network. They allow containers to communicate with each other using container names as hostnames, which makes linking and managing containers much simpler.

To create a network, use the following command in your terminal:

This command creates a network named my_network. Docker assigns a unique subnet and gateway to this network, separate from Docker’s default networks, ensuring there is no interference. By using a user-defined network, containers can resolve each other by name, enhancing ease of communication.

For more details about this command, you can visit the official Docker network create documentation.

With our network set up, let's launch two containers and connect them to my_network. We will use lightweight Alpine Linux containers for this purpose. As a reminder, we perform this step to allow containers to communicate over the created network.

Here's how to launch the first container:

This command runs an Alpine Linux container named container1 and connects it to our defined network my_network. The container is set to run indefinitely (sleep infinity) so it remains active for our communication tests.

Now, let's launch the second container with the following command:

Similarly, this creates another Alpine container named container2, also connected to my_network. Both containers are now active and connected to the same network, allowing them to engage in inter-container communication.

Once both containers are active and connected to my_network, they can communicate using their assigned names as hostnames. For instance, if container1 wants to reach container2, it can do so by using the command ping container2. Docker's internal DNS resolution capabilities within a user-defined network allow containers to identify each other by name, facilitating seamless communication.

When container1 attempts to ping container2, a successful connection would display an output similar to the following:

This output confirms successful communication between the two containers over the established network, showcasing Docker's capacity for container intercommunication.

If you encounter issues where containers cannot reach each other, there are a few troubleshooting steps to consider:

1. Network Configuration: Ensure both containers are connected to the correct network. Misconfigured network settings can prevent communication.

2. Container Names: Make sure the container names used in communication commands match exactly those specified during container creation. Names are crucial for DNS resolution.

3. Container Status: Verify that both containers are running. If a container has stopped, restart it.

By addressing these common issues, you can effectively resolve most inter-container communication obstacles.

In this lesson, you've learned to set up inter-container communication by creating a user-defined network, launching containers with specified names, and confirming connectivity using the ping command. This knowledge is essential as you advance to more complex multi-container applications. In the upcoming practice exercises, you will further solidify these concepts by configuring and testing container communication in various scenarios. Take this opportunity to deepen your understanding of Docker networking, ensuring you're well-prepared for real-world container orchestration tasks.