Docker Swarm onwards

docker 2 class part2

Docker Swarm
https://docs.docker.com/engine/swarm/key-concepts/

Feature highlights
Cluster management integrated with Docker Engine: Use the Docker Engine CLI to create a swarm of Docker Engines where you can deploy application services. You don’t need additional orchestration software to create or manage a swarm.

Decentralized design: Instead of handling differentiation between node roles at deployment time, the Docker Engine handles any specialization at runtime. You can deploy both kinds of nodes, managers and workers, using the Docker Engine. This means you can build an entire swarm from a single disk image.

Declarative service model: Docker Engine uses a declarative approach to let you define the desired state of the various services in your application stack. For example, you might describe an application comprised of a web front end service with message queueing services and a database backend.

Scaling: For each service, you can declare the number of tasks you want to run. When you scale up or down, the swarm manager automatically adapts by adding or removing tasks to maintain the desired state.

Desired state reconciliation: The swarm manager node constantly monitors the cluster state and reconciles any differences between the actual state and your expressed desired state. For example, if you set up a service to run 10 replicas of a container, and a worker machine hosting two of those replicas crashes, the manager creates two new replicas to replace the replicas that crashed. The swarm manager assigns the new replicas to workers that are running and available.

Multi-host networking: You can specify an overlay network for your services. The swarm manager automatically assigns addresses to the containers on the overlay network when it initializes or updates the application.

Service discovery: Swarm manager nodes assign each service in the swarm a unique DNS name and load balances running containers. You can query every container running in the swarm through a DNS server embedded in the swarm.

Load balancing: You can expose the ports for services to an external load balancer. Internally, the swarm lets you specify how to distribute service containers between nodes.

Secure by default: Each node in the swarm enforces TLS mutual authentication and encryption to secure communications between itself and all other nodes. You have the option to use self-signed root certificates or certificates from a custom root CA.

Rolling updates: At rollout time you can apply service updates to nodes incrementally. The swarm manager lets you control the delay between service deployment to different sets of nodes. If anything goes wrong, you can roll back to a previous version of the service.

docker swarm init --advertise-address <Public IP of Manager Node>

from worker node:
docker swarm join --token SWMTKN-1-1llvq2peuyj0lljfvl5x6o31ycca42jyhbl7w661orpnh66zu1-8pk1pn3yjfgjqqtne1n87yi0b 34.238.43.1:2377

To Leave : 
docker swarm leave --force


To check node status:
docker node ls

docker info | grep -i swarm


if you lose command to join workder, run this on manager :
docker swarm join-token worker

##Service:

docker service create --replicas 2 --name helloworld alpine ping docker.com
docker ps
(both on leader and worker)
docker service ls (Leader)

 docker service ps helloworld (leader) 
 To see which nodes are running the service
 
 To Scale:
 docker service scale helloworld=5
  
 To remove : 
 docker service rm helloworld




 docker node promote NODE [NODE...]
 Promotes a node to manager. This command can only be executed on a manager node.

####Bridge Network
docker create --name my-nginx
--network my-net
--publish 8080:80
nginx:latest

docker network connect my-net my-nginx

docker network disconnect my-net my-nginx

Bridge
https://docs.docker.com/network/network-tutorial-standalone/

Host
Given that the container does not have its own IP-address when using host mode networking, port-mapping does not take effect, and the -p, --publish, -P, and --publish-all option are ignored, producing a warning instead:
https://docs.docker.com/network/network-tutorial-host/

Overlay
https://docs.docker.com/network/overlay/
When you initialize a swarm or join a Docker host to an existing swarm, two new networks are created on that Docker host:

• an overlay network called ingress, which handles the control and data traffic related to swarm services. When you create a swarm service and do not connect it to a user-defined overlay network, it connects to the ingress network by default.
• a bridge network called docker_gwbridge, which connects the individual Docker daemon to the other daemons participating in the swarm.
  https://docs.docker.com/network/network-tutorial-overlay/#walkthrough
  The docker_gwbridge connects the ingress network to the Docker host’s network interface so that traffic can flow to and from swarm managers and workers. If you create swarm services and do not specify a network, they are connected to the ingress network

IPVlan: IPvlan networks give users total control over both IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving operators complete control of layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay network integration.

macvlan:
Macvlan networks allow you to assign a MAC address to a container, making it appear as a physical device on your network. The Docker daemon routes traffic to containers by their MAC addresses. Using the macvlan driver is sometimes the best choice when dealing with legacy applications that expect to be directly connected to the physical network, rather than routed through the Docker host’s network stack.

none: For this container, disable all networking. Usually used in conjunction with a custom network driver. none is not available for swarm services

Network driver summary🔗
User-defined bridge networks are best when you need multiple containers to communicate on the same Docker host.
Host networks are best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
Overlay networks are best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services.
Macvlan networks are best when you are migrating from a VM setup or need your containers to look like physical hosts on your network, each with a unique MAC address.
Third-party network plugins allow you to integrate Docker with specialized network stacks.