Docker Meetup Notes

http://www.meetup.com/Docker-NewYorkCity/events/221586351/  
Presentations / video not yet available online
## Project Calico:
Small startup group inside larger co: Metaswitch  
Pure Layer 3 cloud networking solution - Containers, VM’s, bare metal  
Docker networking solutions:  
 - Port Forwarding / NAT (out of the box) : 
- Simple, out of the box, easily understood, but not real IP networking. Wont work with IPsec. Can’t have multiple apps working on same port
 - Overlay networks
 - Give each container its own private ip address (or subnet)
 - separate “overlay” domain over underlay network with GRE, MPLS, VXLAN or proprietary tunneling protocols

How does it work today:
 - vSwitch virtual switch. 
  - L2 segment implemented in software via virtual switch to talk between different segments, then you need another instance to translate.  Leads to unnecessary complexity, low scale limits, performance issues, inefficient resource util, difficulty troubleshooting, demands on app dev to be networking expert. More complicated with containers (100’s per server).
 - Calico goals:
- Workloads need to communicate with one another
- Base req for IP connectivity
- Enforce policy (e.g. user, group, public)
- Project Calico is to treat this like public internet  

Going into details, losing me...
Note: etcd is distributed highly available datastore
 - Other advantages:
- Simplified diagnostics. Trace route, ping, etc. works as expected
- No on/off ramp required. Path from workload to non-virtual device or public internet (or even between data centers) is just a route 
- Other IP techniques “just work” EG equal cost multi-path (ECMP) & Anycast enable scalable resilience and full utilization of physical links
- CoreOS is what they prefer to use bc it includes XCD

Demo:
- used vagrant up and github to set up machines. github has vagrant file
used busybox docker image
- Calico enables you to give your Docker containers real, routable IP addresses, with security/policy built-in
- Went through pinging containers from each other, showing ability to communicate only with containers with access.

Questions: (did not catch them)


## Mesosphere:

This is early beta software
AWS: DCOS Cloud
Marathon is init for datacenter, Marathon is manager for lots of instances
Docker Swarm: Docker’s native integration for running docker containers in a cluster

Mesosphere is Mesos integration for docker swarm

Demo: SSH into one of the hosts, then run some docker commands (using docker swarm)
Docker communicates via docker remote api (tcp) 
swarm-manager.marathon.mesos

Marathon for working with docker - mature service
Marathon is it’s own language, and you specify how docker container should be run. 

Docker uses BRIDGE networking. Marathon gives you ability to map ports to whatever you want. Looks like you name ports instead of 80:80 it will be “ContainerPort” : 80

An example of a constraint you can set with marathon: MYSql - this task can only run one instance per hostname.
Can specify dependencies on other services. If dependent, then the other service needs to come online first before the dependent service comes online.

Marathon features:
- Port mappings
- Constraints
- App groups
- Deployment strategies

Questions:
- Should you be interacting with Mesos if you are using Marathon. Goal is not to interact w Mesos.
- App groups - mesos or marathon? Marathon.
- How do they access outside world? Marathon provides HA proxy (load balancing). Marathon can publish topology of app, then HA proxy can “do it’s thing.” Mesos DNS is a tool to help services discovery.
- Mesos doesn't let you bind to same 2 ports at one time. No enforcement of naming. Orgs usually have a large list of ports.