Sitemap

The DEFINITIVE GUIDE

Basic Networking with Docker

4 min readSep 15, 2024

--

Press enter or click to view image in full size
Photo by Albert Stoynov on Unsplash

This article is the complex portion of a project I previously released titled, “Containerized Web Application Deployment”. The advanced portion, “Docker Hub”, dove into the basics of using Docker Hub as an image repository.

The complex portion of this project will require us to:

  1. Create a new Docker network.
  2. Run the container using the new network.
  3. Use the CLI to verify the container is using the new network and not the bridge network.

Prerequisites

Let’s get started!

By default, each container is connected to a private virtual network called “bridge”. Each network will utilize a NAT firewall on the host IP to route out to the internet. Let’s see what networks are available.

Get Damion Raymond’s stories in your inbox

Join Medium for free to get updates from this writer.

Type the following command:

docker network ls

As you can see below, we have three networks running.

  • bridge
  • host
  • none
Press enter or click to view image in full size
List docker networks

The container we created earlier was attached to the bridge network by default when it was started. To verify that our image is running on the bridge network we can execute the following command:

docker container inspect bridge 

This will display details of the bridge network in JSON format. As you can see. Below that our running container titled, “stoic_elbakyan”, is listed under the Containers section in the network details.

Press enter or click to view image in full size
docker network inspect bridge

Create a New Docker Network

To create a new docker network, execute the following command:

docker network create <name_of_network>

After executing the above command, we can use the following command to list our new network:

docker network ls

As you can see below, we can verify that our new network, “my_new_net” was indeed created using a default bridge driver after we utilized the list command.

Press enter or click to view image in full size

Run the Container Using the New Network

Before we run our container using the new network, we must first disconnect it from the default network using the <disconnect> command.

docker network disconnet <network_name> <container_name>

If we look below, we can see that there are no containers listed in the default bridge network. To inspect the bridge network, execute the <inspect> command:

docker network inspect bridge
Press enter or click to view image in full size

To connect our container to our new network, we will utilize the <connect> command as seen below:

docker network connect <new_network_name> <container_name>

Verify Container is Attached to the New Network via the CLI

Use the <inspect> command to list the new network details and verify that the container is attached.

docker network inspect <new_network_name>

You can see below that our new network named, “my_new_net”, has the previous container we detached from the default network and attached to it.

Press enter or click to view image in full size

I didn’t need to stop the running container to attach it to the new network. If you refreshed your EC2 instance’s public IPv4 address in your web browser, you should see your customized webpage if you are accessing the same port that was published in the image currently running. In my project, I opened port 8080 on my EC2 instance.

Press enter or click to view image in full size
Custom web page on port 8080

Summary

In this article, we’ve discussed how to create new docker networks, how to connect and disconnect containers from different networks, and we’ve learned how to inspect the network details. We’ve only scratched the surface of networking in Docker. Stay tuned for more tips.

Remember to stop your EC2 instance to avoid any billing overages.

As always, I hope this project was valuable to you and if you want to connect, you can find me on LinkedIn, and here’s also a link to my GitHub.

--

--

Written by Damion Raymond

Nuclear Medicine technologist transitioning into a Cloud DevOps Engineer role.