Container Operations - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2016 Mesosphere, Inc. All Rights Reserved. LINUX  CONTAINERS 5 • Containers are not VMs • app-level dependency management • lightweight (startup time, footprint, average runtime) • isolation & security (kinda, getting better)

Slide 6

Slide 6 text

© 2016 Mesosphere, Inc. All Rights Reserved. LINUX  CONTAINERS 6 • namespaces • Isolate PIDs between processes • Isolate process to network resources • Isolate the hostname to fake it out (UTS) • Isolate the filesystem mount points (chroot) • Isolate inter process communication (IPC) • Isolate specific users to specific processes • cgroups  https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2016 Mesosphere, Inc. All Rights Reserved. DC/OS BENEFITS 16 • One cluster for • stateless services such as Web servers & app servers (via Marathon) • stateful services like PostgreSQL, MemSQL, Kafka, Cassandra, etc. • elastic data processing via Spark, Akka, etc. • CI/CD, for example Jenkins+Marathon • Dynamic partitioning of your cluster, depending on your needs • Increased utilization (10% → 80%+)

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2016 Mesosphere, Inc. All Rights Reserved. APACHE MESOS 20 • A top-level ASF project • A cluster resource negotiator • Scalable to 10,000s of nodes but also useful for a handful of nodes • Fault-tolerant, battle-tested • An SDK for distributed apps • Native Docker support mesos.apache.org

Slide 21

Slide 21 text

© 2016 Mesosphere, Inc. All Rights Reserved. MESOS  ARCHITECTURE 21 http://mesos.berkeley.edu/mesos_tech_report.pdf Marathon  scheduler Spark  scheduler Spark  executor Marathon  executor Spark  executor Marathon  executor Mesos Agent Mesos Agent Mesos Agent Mesos  Master Standby  Master Standby  Master Framework

Slide 22

Slide 22 text

© 2016 Mesosphere, Inc. All Rights Reserved. RESOURCES 22 • resource: anything a task consumes to do its work • standard resources: cpu  mem  disk  ports • Dominant Resource Fairness (DRF) algorithm guarantees fair allocation across resource types

Slide 23

Slide 23 text

© 2016 Mesosphere, Inc. All Rights Reserved. MARATHON 23 The DC/OS 'init system' • starts instances of a long-running services • restarts the instances if they crash • provides composition primitives • supports health checks • supports rolling upgrades

Slide 24

Slide 24 text

© 2016 Mesosphere, Inc. All Rights Reserved. MARATHON  GROUPS 24 • Groups can contain one or more apps/groups • Dependency management • Scaling https://mesosphere.com/blog/2015/06/21/web-application-analytics-using-docker-and-marathon/

Slide 25

Slide 25 text

© 2016 Mesosphere, Inc. All Rights Reserved. MARATHON  APP SPEC 25 { "id": "/webserver", "instances": 5, "cpus": 0.1, "mem": 128, "container": { "type": "DOCKER", "docker": { "image": "nginx:1.9.14", "network": "BRIDGE", "portMappings": [ { "containerPort": 80, "hostPort": 0 } ] } }, "upgradeStrategy": { "minimumHealthCapacity": 0.9 }, "acceptedResourceRoles": [ "slave_public" ] }

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2016 Mesosphere, Inc. All Rights Reserved. DC/OS SERVICE DISCOVERY 31 DNS-based easy to integrate SRV records no health checks TTL Proxy-based no port conflicts fast failover no UDP management of VIPs (Minuteman) or service ports (Marathon-lb) Application-aware developer fully in control and full-feature implementation effort requires distributed state management (ZK, etcd or Consul) examples:  Mesos-DNS,Consul examples:  Minuteman, Marathon-lb examples:  Roll-your-own, Finagle

Slide 32

Slide 32 text

© 2016 Mesosphere, Inc. All Rights Reserved. LOAD BALANCING TERMINOLOGY 32 rolling deployment bring up N instances of new app & terminate N instances of old app until all old instances are gone goal: minimize capacity requirements blue-green deployment launch a new stack and switch traffic from old to new when the new instances are healthy goal: minimize impact of regressions, friction, delays, and allow easy rollbacks canary deployment bring up a new stack, start by routing a small portion of traffic to the new app, and slowly increase goal: test production traffic slowly & safely

Slide 33

Slide 33 text

© 2016 Mesosphere, Inc. All Rights Reserved. DC/OS LOAD BALANCING 33 • Cluster-internal: Minuteman, a L4 distributed LB, usage via VIP in Marathon • Internal or edge: Marathon-lb, dynamically updates HAProxy, usage via package+service ports in Marathon • External, for example Azure's offerings

Slide 34

Slide 34 text

© 2016 Mesosphere, Inc. All Rights Reserved. DEPLOYMENT STRATEGIES 34 • Based on health checks • Policy via • minimumHealthCapacity float value between 0—1, specifies % of app instances to maintain healthy while performing deployment • maximumOverCapacity float value between 0 — 1, specifies the maximum % of instances that can be over capacity during deployment