docker session 7 networking

Use this title slide only with an image

Docker Part 7 NetworkingDawood Sayyed/GLDS February 10 , 2016 Internal

© 2015 SAP SE or an SAP affiliate company. All rights reserved. 2Internal

Container Networking Basics

$ docker run –d –P jpetazzo/web

• Docker will download the image from the Docker Hub.

• -d tells Docker to run the image in the background.

• -P tells Docker to make this service reachable from other computers.

(-P is the short version of --publish-all.)

But, how do we connect to our web server now?


Finding our web server port

$ docker ps

• The web server is running on port 8000 inside the container.

• That port is exposed on port 49153 on our Docker host.

We will explain the why’s and how’s of this port mapping.

But first, let's make sure that everything works properly.


Connecting to your web server (GUI) and (CLI)

Point your browser to the IP address of your Docker host, on the port shown by

docker ps

YOU WILL SEE ………..WEB SERVER

$ curl localhost:49153


Docker networking model

• We are out of IPv4 addresses.

• Containers cannot have public IPv4 addresses.

• They have private addresses.

• Services have to be exposed port by port.

• Ports have to be mapped to avoid conflicts.


Finding the web server port

Parsing the output of docker ps would be painful.

There is a command to help us:

$ docker port <containerID> 8000


Plumbing containers into your infrastructure

There are (at least) three ways to integrate containers in your network.

• Start the container, letting Docker allocate a public port for it.

Then retrieve that port number and feed it to your configuration.

• Pick a fixed port number in advance, when you generate your configuration.

Then start your container by setting the port numbers manually.

• Use an overlay network, connecting your containers with e.g. VLANs, tunnels...


Finding the container’s IP address

$ docker inspect –format ‘{{ .NetworkSettting.IPAddress }}’ <yourcontainerID>

We can use the docker inspect command to find the IP address of the container

• docker inspect is an advanced command, that can retrieve a ton of

information about our containers.

• Here, we provide it with a format string to extract exactly the private IP address

of the container.


Pinging our container

We can test connectivity to the container using the IP address we've just discovered.

Let's see this now by using the ping tool.

$ ping <ipAddress>


Manual allocation of port

If you want to set port numbers yourself, no problem:

This time, we are running our container in the foreground.(That way, we can kill it easily with ^C.)

• We mapped port 80 on the host, to port 8000 in the container.

$ docker run –t -p 80:8080 jpetazzo/web


Finding our IP

1) docker inspect --format '{{ .NetworkSettings.IPAddress }}' 15cf0c684910

2) docker inspect --format '{{ .NetworkSettings.IPAddress }}' $(docker ps –q)

3) docker exec -it 15cf0c684910 bash

ip add | grep global

4) docker exec -it $(docker ps -l -q) ip a


Exposing a Container Port on the Host


Understand Docker Containers Networks

To build web applications that act in concert but do so securely, use the Docker networks feature.

Networks, by definition, provide complete isolation for containers. So, it is important to have control over the networks your applications run on.

Docker container networks give you that control.

Default Network

Default networking behavior that Docker Engine delivers natively. It describes the type of networks created by default and how to create your own, user-defined networks. It also describes the resources required to create networks on a single host or across a cluster of hosts.


Default Networks

When you install Docker, it creates three networks automatically.

$ docker network ls

$ ifconfig

Host : The host network adds a container on the hosts network stack. You’ll find the network configuration inside the container is identical to the host.

None : The none network adds a container to a container-specific network stack. That container lacks a network interface .

$ docker attach nonenetcontainer


Defaults Networks Bridge in details

Bridge : Represent the docker0 network present in all docker installations.

With the exception of the bridge network, you really don’t need to interact with these default networks. While you can list and inspect them, you cannot remove them. They are required by your Docker installation. However, you can add your own user-defined networks and these you can remove when you no longer need them. Before you learn more about creating your own networks, it is worth looking at the default bridge network a bit.

The default bridge network is present on all Docker hosts. The docker network inspect command returns information about a network:

$ docker network inspect bridge



The Engine automatically creates a Subnet and Gateway to the network. The docker run command automatically adds new containers to this network.

$ docker run –itd --name=container1 busybox

$ docker run –itd --name=container2 busybox

$ docker network inspect bridge



The docker network inspect command above shows all the connected containers and their network resources on a given network. Containers in this default network are able to communicate with each other using IP addresses. Docker does not support automatic service discovery on the default bridge network. If you want to communicate with container names in this default bridge network, you must connect the containers via the legacy docker run --link option.

$ docker attach container1

$ ifconfig

$ping –w3 ipaddress

Then use ping for about 3 seconds to test the connectivity of the containers on this bridge network.



Finally, use the cat command to check the container1 network configuration:

$ cat /etc/hosts

To detach from a container1 and leave it running use CTRL-p CTRL-q.Then, attach to container2 and repeat these three commands.

The default docker0 bridge network supports the use of port mapping and docker run --link to allow communications between containers in the docker0 network. These techniques are cumbersome to set up and prone to error. While they are still available to you as techniques, it is better to avoid them and define your own bridge networks instead.


User-defined networks

Can create your own user-defined networks that better isolate containers. Docker provides some default network drivers for creating these networks. You can create a new bridge network or overlay network.

You can create multiple networks. You can add containers to more than one network. Containers can only communicate within networks but not across networks.

A container attached to two networks can communicate with member containers in either network. When a container is connected to multiple networks, its external connectivity is provided via the first non-internal network, in lexical order.


A bridge network

The easiest user-defined network to create is a bridge network. This network is similar to the historical, default docker0 network. There are some added features and some old features that aren’t available.

$ docker network create –driver bridge isolated_nw

$ docker network inspect isolated_nw

$ docker network ls

$ docker run --network=isolated_nw –itd --name=container3 busybox



Docker Networking

The containers you launch into this network must reside on the same Docker host. Each container in the network can immediately communicate with other containers in the network. Though, the network itself isolates the containers from external networks.


Docker Networking

Within a user-defined bridge network, linking is not supported. You can expose and publish container ports on containers in this network. This is useful if you want to make a portion of the bridge network available to an outside network.


Overlay Network

A bridge network is useful in cases where you want to run a relatively small network on a single host. You can, however, create significantly larger networks by creating an overlay network. Docker’s overlay network driver supports multi-host networking natively out-of-the-box. This support is accomplished with the help of libnetwork, a built-in VXLAN-based overlay network driver, and Docker’s libkv library.The overlay network requires a valid key-value store service. Currently, Docker’s libkv supports Consul, Etcd, and ZooKeeper (Distributed store). Before creating a network you must install and configure your chosen key-value store service. The Docker hosts that you intend to network and the service must be able to communicate. Each host in the network must run a Docker Engine instance. The easiest way to provision the hosts are with Docker Machine.


Ports

Your key-value store service may require additional ports. Check your vendor’s documentation and open any required ports.

Once you have several machines provisioned, you can use Docker Swarm to quickly form them into a swarm which includes a discovery service as well.

To create an overlay network, you configure options on the daemon on each Docker Engine for use with overlay network. There are three options to set: check the second diagram


Ports Configuration between hosts


Create an overlay network on one of the machines in the Swarm

$ docker network create –driver overlay my-multi-host-network

$ docker run -itd --network=my-multi-host-network busybox


Working with networking commands

$ docker network create

$ docker network connect

$ docker network ls

$ docker network rm

$ docker network disconnect

$ docker network inspect


Commands

$ docker network create simple-network

$ docker network inspect simple-network


Getting started with Overlay Networks

Unlike bridge networks, overlay networks require some pre-existing conditions before you can create one.

These conditions are:

Access to a key-value store. Engine supports Consul, Etcd, and ZooKeeper (Distributed store) key-value stores.

A cluster of hosts with connectivity to the key-value store.

A properly configured Engine daemon on each host in the swarm.



The dockerd options that support the overlay network are:

--cluster-store

--cluster-store-opt

--cluster-advertise



It is also a good idea, though not required, that you install Docker Swarm to manage the cluster. Swarm provides sophisticated discovery and server management that can assist your implementation.

When you create a network, Engine creates a non-overlapping subnetwork for the network by default. You can override this default and specify a subnetwork directly using the --subnet option. On a bridge network you can only specify a single subnet. An overlay network supports multiple subnets.

Note : It is highly recommended to use the --subnet option while creating a network. If the --subnet is not specified, the docker daemon automatically chooses and assigns a subnet for the network and it could overlap with another subnet in your infrastructure that is not managed by docker. Such overlaps can cause connectivity issues or failures when containers are connected to that network.

Be sure that your subnetworks do not overlap. If they do, the network create fails and Engine returns an error.


Specify subnet /gateway /ip-range /aux-address

$ docker network create -d overlay \

--subnet=192.168.0.0/16 \

--subnet=192.170.0.0/16 \

--gateway=192.168.0.100 \

--gateway=192.170.0.100 \

--ip-range=192.168.1.0/24 \

--aux-address a=192.168.1.5 --aux-address b=192.168.1.6 \

--aux-address a=192.170.1.5 --aux-address b=192.170.1.6 \

my-multihost-network



When creating a custom network, the default network driver (i.e. bridge) has additional options that can be passed. The following are those options and the equivalent docker daemon flags used for docker0 bridge:

The following arguments can be passed to docker network create for any network driver.

For example, now let’s use -o or --opt options to specify an IP address binding when publishing ports:

$ docker network create -o "com.docker.network.bridge.host_binding_ipv4"="172.23.0.1" my-network


Commands

$ docker network create -o "com.docker.network.bridge.host_binding_ipv4"="172.23.0.1" my-network

$ docker run -d -P --name redis --network my-network redis

$ docker ps

You can connect containers dynamically to one or more networks. These networks can be backed the same or different network drivers. Once connected, the containers can communicate using another container’s IP address or name.

For overlay networks or custom plugins that support multi-host connectivity, containers connected to the same multi-host network but launched from different hosts can also communicate in this way.


Connecting Containers

$ docker run -itd --name=container1 busybox

$ docker run -itd --name=container2 busybox

$ docker network create -d bridge --subnet 172.25.0.0/16 isolated_nw

$ docker network connect isolated_nw container2



Creating two containers

You can see that the Engine automatically assigns an IP address to container2. Given we specified a --subnet when creating the network, Engine picked an address from that same subnet. Now, start a third container and connect it to the network on launch using the docker run command’s --network option:

$ docker run --network=isolated_nw --ip=172.25.3.3 -itd --name=container3 busybox

As you can see you were able to specify the ip address for your container. As long as the network to which the container is connecting was created with a user specified subnet, you will be able to select the IPv4 and/or IPv6 address(es) for your container when executing docker run and docker network connect commands by respectively passing the --ip and --ip6 flags for IPv4 and IPv6. The selected IP address is part of the container networking configuration and will be preserved across container reload. The feature is only available on user defined networks, because they guarantee their subnets configuration does not change across daemon reload.


Creating Container

$ docker inspect --format='' container3

Repeat this command for container2. If you have Python installed, you can pretty print the output.

$ docker inspect --format='' container2 | python -m json.tool

You should find container2 belongs to two networks. The bridge network which it joined by default when you launched it and the isolated_nw which you later connected it to.


Creating Container

In the case of container3, you connected it through docker run to the isolated_nw so that container is not connected to bridge.Use the docker attach command to connect to the running container2 and examine its networking stack:


If you look at the container’s network stack you should see two Ethernet interfaces, one for the default bridge network and one for the isolated_nw network.

$ ifconfig

On the isolated_nw which was user defined, the Docker embedded DNS server enables name resolution for other containers in the network. Inside of container2 it is possible to ping container3 by name.


Creating Container

$ ping -w 4 container3

This isn’t the case for the default bridge network. Both container2 and container1 are connected to the default bridge network. Docker does not support automatic service discovery on this network. For this reason, pinging container1 by name fails as you would expect based on the /etc/hosts file:

$ ping -w 4 container1

If you wanted you could connect container1 to container2 with the docker run --link command and that would enable the two containers to interact by name as well as IP.Detach from a container2 and leave it running using CTRL-p CTRL-q.


$ ping 172.17.0.2


Creating Container

The container2 still has full connectivity to the bridge network

$ ping container1

$ docker run -d --name redis_db --network multihost redis

$ docker rm -f redis_db

$ docker network disconnect -f multihost redis_db

$ docker run -d --name redis_db --network multihost redis


Remove a network

$ docker network disconnect isolated_nw container3

$ docker network rm isolated_nw

$ docker network ls


Custom network plugin

If you like, you can write your own network driver plugin. A network driver plugin makes use of Docker’s plugin infrastructure. In this infrastructure, a plugin is a process running on the same Docker host as the Docker daemon.Network plugins follow the same restrictions and installation rules as other plugins. All plugins make use of the plugin API. They have a lifecycle that encompasses installation, starting, stopping and activation.Once you have created and installed a custom network driver, you use it like the built-in network drivers. For example:You can inspect it, add containers to and from it, and so forth. Of course, different plugins may make use of different technologies or frameworks. Custom networks can include features not present in Docker’s default networks

$ docker network create –driver weave mynet


Docker embedded DNS server

Docker daemon runs an embedded DNS server to provide automatic service discovery for containers connected to user defined networks. Name resolution requests from the containers are handled first by the embedded DNS server. If the embedded DNS server is unable to resolve the request it will be forwarded to any external DNS servers configured for the container. To facilitate this when the container is created, only the embedded DNS server reachable at 127.0.0.11 will be listed in the container’s resolv.conf file. More information on embedded DNS server on user-defined networks can be found in the embedded DNS server in user-defined networks

What is Automatic service discovery ?

https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/


Links

Before the Docker network feature, you could use the Docker link feature to allow containers to discover each other. With the introduction of Docker networks, containers can be discovered by its name automatically. But you can still create links but they behave differently when used in the default docker0 bridge network compared to user-defined networks. For more information, please refer to Legacy Links for link feature in default bridge network and the linking containers in user-defined networks for links functionality in user-defined networks.


Multi-host networking

https://docs.docker.com/engine/userguide/networking/get-started-overlay/

docker session 7 networking

Documents