gistfile1.txt

Hope:

`--opt encrypted` flag ~ an optional which enables an additional layer of  encryption in the overlay driver for vxlan traffic between containers on  different nodes
`--subnet` flag  ~ specifies the subnet for use with the overlay network. When  you don't specify a subnet, the swarm manager automatically chooses a subnet and  assigns it to the network.
 Note - Before you attach a service to the network, the network only extends to manager  nodes

ingress - This is the overlay network on which all exposed ports exist. As explained below, ingress ports are numbered from 30000 through 32000 (user configurable range) and follow a node port model in which each service has the same port on every node in the cluster.
docker_gwbridge - This is the default gateway network. It is the only network with connectivity to the outside.
[user-defined overlay] - This is the overlay network that the user has specified that the container should be on. In the example above, it is mynetwork. Note that a container can be on multiple user-defined overlays.






Slide:1


Docker 1.12 was announced last Dockercon and it brought lots of exciting 

features. One of the feature enhancement was Swarm rightly integrated into Docker 

Engine. What it means is if you install Docker 1.12 you already get Swarm rightly 

integrated into the engine.

But the major BIG news was Swarm Mode. Swarm Mode is an orchestration engine 

which Docker Team built but interestingly they kept it optional. Prior to 1.12, 

community has been depending upon use external DCSes such as etcd or Consul to 

store cluster metadata for orchestration enablement. But with 1.12, you dont need 

those 3rd party tools. Everythings comes out of the box.

Basically When you run the Engine in swarm mode, you orchestrate services. Not 

only this, Swarm Mode does enablement for orchestration + Schduling + Cluster 

Management + Security - all in one release.

Thanks to Swarmkit - a technical foundation where all orchestration engine has 

been development. 
Swarmkit is not Docker specific..is a general purpose library or kit.
Nothinng in swarmkits binds to schedule docker container
You can schedule anything..processes in machine..
You can schedule unikernels..you can schedule VMs..
Docker team built swarmkit with a goal that appro services into docker itself..
Community will find other interesting use cases
They want to do with it.



Additional to that, we have 3 new APIs been introduced - 
docker swarm, docker node and docker service. 
Docker swarm purely provides capability to build up cluster nodes whereas docker 

nodes handles node management, promotion, demotion capabilities.

What I am going to talk in this session is all about docker service and the 

service discovery aspects.

Service is a new concept which is introduced in Docker 1.12.
The idea is you declare a desired state of your application and the swarm engine 

will enforce that desired
state. We will talk in detail on this topic.

Docker 1.12 comes with out-of-the-box capabilities for multi-container and 

multi-host app deployments, with networking and security built in. This means 

that with Docker 1.12 alone, you can deploy a highly available application to a 

Swarm cluster without needing to roll your own orchestration tools or spend a ton 

of hours trying to configure external orchestrators and network managers.
All of the orchestration features in 1.12 are backwards compatible. If you’re 

already an orchestration expert and have implemented your own solution, nothing 

will change. All of the extra orchestration features are opt-in.

Docker 1.12 is an optional feature set that involves turning on a capability 

known as swarm mode. A swarm is a decentralized and highly available group of 

Docker nodes. Each node is a self-contained orchestration subsystem that has all 

the inherent capabilities needed to create a pool of common resources to schedule 

Dockerized services.

==========================
Let's talk about evolution of Service Discovery.

Service discovery is not at all a new concept. It was firstly introduced under 

1.9 but it lacked a scability.

Service discovery in Docker 1.9 purely relied on updating the container's 

/etc/hosts file.  
When a container is run connected to a new Docker 1.9 user-defined network (e.g., 

docker run --net user-net ...), the /etc/hosts files of all other containers 

connected to that network are updated with a mapping between the new container's 

IP address and its hostname.

But This resulted in issues like corrupted /etc/hosts file in some cases. 

With Docker 1.10, we had embedded DNS for the first time.
Docker daemon will act as a embedded DNS server for all the containers in a host. 

From the container point of view nameserver will be available at the loopback 

address. When the container is launched the loopback address will be the only 

nameserver populated in /etc/resolv.conf file. DNS queries from the container 

will be handled by the Docker process.

[The embedded DNS server will be enabled for all user created networks. 

/etc/hosts file will not be updated for containers on those networks. Only 

exception is the containers in the default bridge network (docker0 bridge) with 

the link option which will continue to use /etc/hosts file. This is to provide 

backward compatibility for apps relying on that behavior.]

The embedded DNS server in Docker is to resolve only the service names offered by 

Docker containers (local or across hosts). It can't replace any other local or 

non-local DNS servers used to resolve other services/host names in the cluster.  

Hence we saw External Service Discovery backend like consul, etcd or zookeeper 

became more popular.

Under docker 1.12, Service Discovery is rightly plumbed into $docker service top 

level constraint. This rightly fits into $docker service now as it is top level 

citizen now.
Its High available. Service Discovery now looks quite simple for operation team 

while it holds lots of complex iptables rules within to make this possible. I am 

going to touch upon those aspects too in the later part of the talk.


To make it quite simpler, under Docker 1.12, for the first time VIP based Service 

Discovery & LB concept was introduced. 

===============================================
Let's start with Service:

As we discussed, Service is a new top level constraint which has been added.

To support the new orchestration capabilities, this release adds a couple new 

commands to the Docker API. Instead of only controlling things at a container 

level via docker run my-image, you can now declare a desired state for a service 

using the command docker service — provided you’ve set up your hosts in a Swarm 

cluster.

Global Services:

Global Services:

Sometimes you want the container that runs on every machine in your cluster and 

when you add a new machine you want that container automatically added an 

service. Just like cadvisor, you ensure one copy of that run on that machine.


=======
From which network is it coming from? So the way we do it we hve DNS server 

embedded server. We opened a listener in the container itself. There is set of 

iptables rules ., there is /etc/resolv.conf 127.0.0.11. When resolver is trying 

to resolve..its just loopback address..not routed..we send it to UDP/TCP port in 

the docker daemon..to do that socket is created insude the namespace...when DNS 

gets this request...one it knows the context, it generate DNS response..



=====
Key Takeaways:

IF you want to build your own DNS, you can use DNS RR and 

Slide-Further:

slide:Service Definition
========================

A service is the definition of the tasks to execute on the worker nodes. It is the central structure of the swarm system and the primary root of user interaction with the swarm.
When you create a service, you specify which container image to use and which commands to execute inside running containers.
In the replicated services model, the swarm manager distributes a specific number of replica tasks among the nodes based upon the scale you set in the desired state.
For global services, the swarm runs one task for the service on every available node in the cluster.
A task carries a Docker container and the commands to run inside the container. It is the atomic scheduling unit of swarm. Manager nodes assign tasks to worker nodes according to the number of replicas set in the service scale. Once a task is assigned to a node, it cannot move to another node. It can only run on the assigned node or fail.

Slide: Service Disovery:
=========================

A service is now a first class citizen in Docker which allows replication, update of images and dynamic load-balancing




Slide: SD under Swarm Mode:
========================

By default, **service discovery** assigns a virtual IP address (VIP) and DNS+entry to each service in the swarm, making it available by its service name to+containers on the same network.+* You can configure the service to use DNS round-robin instead of a VIP.

Port `7946` TCP/UDP for container network discovery.+* Port `4789` UDP for the container overlay network.

For environments with multiple subdomains please read options ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains.The search list is currently limited to six domains with a total of 256 characters.

+You don't need to expose service-specific ports to make the service+available to other services on the same overlay network. The swarm's internal+load balancer automatically distributes requests to the service VIP among the+active tasks.


Services can be published using two modes: VIP and DNSRR.
With VIP, you get a virtual IP for the service, and an load balancer based on IPVS
(By the way, IPVS is totally awesome and if you want to learn more about it in the context of containers, I highly recommend this talk by @kobolog at DC15EU!)
With DNSRR, you get the former behavior (from Engine 1.11), where resolving the service yields the IP addresses of all the containers for this service
You change this with docker service create --endpoint-mode [VIP|DNSRR]


docker service inspect --format=='{{json .Spec.EndpointSpec}}' client={"Mode":"dnsrr"}

The behavior you are seeing expected. VIP based services use Linux IPVS load balancing to route to the backend containers. This works only for TCP/UDP protocols. When you use DNS-RR mode services don't have a VIP allocated. Instead service names resolves to one of the backend container IPs randomly.
For VIP based services the reason ping works on the local node is because the VIP is added a 2nd IP address on the overlay network interface. @mrjana @sfsmithcha In the documentation I think we should add a specific note about this.