Each container is attached to a network through a specific endpoint. As a reminder, each network object represents a layer 2 broadcast domain with a layer 3 subnet as shown below. Let’s take a look at the network configuration of each container. $ sudo docker run -tid -name docker2 microsoft/mssql-toolsģf2ba669591a1889068240041332f02faf970e3adc85619adbf952d5c135d3f4ĬONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESģf2ba669591a microsoft/mssql-tools "/bin/sh -c /bin/bash" 7 seconds ago Up 6 seconds docker2ħ7b501fe29af microsoft/mssql-tools "/bin/sh -c /bin/bash" 11 seconds ago Up 10 seconds docker1 IP masquerading and IP forwarding is enabled on my Docker host. My 2 containers can communicate together because they are sitting on the same network bridge and they are also able to communicate with my database server through the NAT mechanism. The below picture shows some network details that I will explain later in this blog post. Let’s have a deeper look on it with a very simple example concerning one docker engine that includes two containers based on microsoft/mssql-tools each and one outside SQL Server that runs on the top of Hyper-V virtual machine. But did you wonder what is exactly a bridge on Docker world? By default, each container created without any network specification (and any Docker engine setting customization) will have one network interface sitting on the docker0 bridge with an IP from 172.17.0.0/16 CIDR or whichever CIDR you have configured docker to use. It is probably the case of my latest customer with only 5 SQL Server containers on the top of one Docker engine. For simple Docker infrastructures (without orchestrators like Swarm or Kubernetes) Docker bridges seem to be predominant with either Docker0 bridges or user-defined bridges.įor very limited Docker topologies, default network settings will be probably sufficient with Docker0 bridge. I spent some times to study and to discuss with customers about implemented network topologies in their context. So, in this context we may use different Docker network topologies.
#Docker network rm free#
That’s my guess but feel free to comment with your thoughts! I always keep in mind the repetitive customer question: is Docker ready for production and for databases? Connecting to a non-containerized SQL Server environment may make sense here at least to speed containers adoption. I’m not saying docker is not designed for mission critical scenarios but let’s say that fear of unknown things, as virtualization before, is still predominant, at least for this kind of scenario. In this blog post I want to focus on the first use case in terms of networks.Ĭonnecting to an outside SQL Server (from a docker perspective) is probably an intermediate solution for many customers who already deal with mission-critical environments implying very restrictive high-availability scenarios and when very high performance is required as well. Use case 2 – SQL Server containers and virtualized applications Use case 1 – Containerized apps and virtualized SQL Server environments Indeed, my new customer implemented a Docker infrastructure exclusively based on SQL Server containers whereas the older one already containerized its applications that were connected to an external and non-containerized SQL Server environment. The interesting point here is I was able to compare with a previous customer who used docker containers for a while in a completely different way. We discussed with him about lot of architecture scenarios. It was definitely a very interesting day with a lot of customer experience and feedbacks. A couple of days ago, I was in a customer shop that already implemented SQL Server 2017 on Linux as Docker containers.
#Docker network rm series#
Let’s continue with this blog post series about SQL Server and Docker.