Schedulers:
- Mesos & Marathon
- Docker Swarm
- Kubernets (currently most popular)
History of Infrastructure Management
- A trail of historical Configuration Management products : CFEngine, Chef, Puppet, Ansible, Salt....
- Bare metal -> VM -> container
- Infrastructure as Code
- Immutable infrastructure
- Chef, Puppet, Ansible etc. : bring mutable servers to the desired state at runtime
- Immutable infrastructure assumes: nothing can be changed at runtime (replace vs. mutate)
- Full automation backed by immutability
- "An era without needing to SSH into servers"
- Clear division between infrastructure and deployments
- Cloud
- Vendor specific tools (CloudFormation)
- Agnostc (Terraform)
History of Deployment Process
Beginning: no packaging, manual copy, bare metal -> ends up a mess
Configuration Management Tools: improve OS setup & maintenance, still services on same server may clash
Separate VM for each service: too much unused CPU & memory
Docker & containers:
- process isolation
- Docker -> easy to use containers
- Needs beyond just running containers (Schedulers):
- Scale
- Fault tolerant
- Communications
Schedulers (cluster managers)
Why:
- resource management
- health check (services be running)
- fault tolerance & HA
- deployment of replicas
- desired state reached
- imperative -> declarative
Why:
- deployment & scale up & down
- portable
- on public / private cloud
- no vendor lockin
- modular & extensible
- automatic -
- kubernetes decides where to run what
- restart / replicate / scale
- self-healing
- self-adaptation (coming)
- zero-downtime, falut tolerance, HA, scaling, scheduling, self-healing
- volume management
- secret management
- health validation & monitoring
- load balancing
- service discovery
- logging