inSync Cloud & Docker

An experiment in Predictability & Scalability

Faisal Puthuparackat <faisal@druva.com>

inSync Cloud now

  • 2 types of machines: CloudMaster & Nodes
  • Needs MySQL or RDS
  • Needs DynamoDB or Bynamo
  • Needs S3/Object Store/Shared FS

Each Cloud Node...

  • Runs Ubuntu 10.04 LTS
  • Uses tarballs for python, bdb libs and sources
  • Config is stored in /etc/inSync* folders
  • Apps log to syslog-ng, which then log to /var/log/inSync and also remote logger service

  • Uses custom scripts (fabric) for deployment and management

  • A machine is one functional unit.

Old Vagrant (vcloud)

  • Runs 2 VM instances

  • Takes typically 15-30 mins to bring up

  • Network heavy during launch

  • Can’t access/sync from other machines

Issues with current inSync Cloud deployments

  • Need to upgrade packages on the machines to mitigate security issues as we find them

  • Rolling upgrade of individual components on the same machine is difficult

  • M/c environment is built as part of deployment. If components are changed later, dev/testing/deployment  images will differ from each other

Enter Docker.

  • Containers for virtualization

  • Like “chroot” on steroids

  • Private namespaces

  • Works using filesystem layers

  • With COW fs layers on top of that

  • FS layers repository

Vagrant + Docker + inSync

  • For Win/Mac, uses a single Vagrant VM to run a minimal docker environment

  • For Linux, can run using Vagrant - OR natively after installing docker.io

What's the big deal?

  • Each container is Ubuntu 14.04

  • Only one VM needed (if any) to run the cloud locally

  • Much smaller CPU footprint

  • Deployed cloud has a dns-resolvable name and can be reached/synced to from other machines on the LAN

  • Typical deploy time: ~2-4 mins

  • Clean-up all data and restart:  ~30 secs

What about the cloud?

  • Each container could be shipped as a complete entity: OS + Env + code, tagged with version, capable or running any one of our cloud processes. Salt-stack could be used to control what daemons run in each container based on the role the node plays.

  • With above model, a container is a completely predictable, immutable unit. No surprises for QA or staging or production

  • Upgrades in OS/libs etc means just pushing the new version of the container. One container will not interfere with another

  • Salt-stack has docker support - so everyone’s happy

Pets vs Sheep

You can never truly achieve scale in the cloud unless you can stop treating your servers as pets and start treating them as sheep.

~ Author unknown

Docker is a step in converting our pets into sheep.

I want it now!!!!

Quickstart guide

1. Checkout trunk

2. Set your cloud name: contrib/vcloud-docker/config.rb

$cloudname = "fcloud"

3. Fire up vagrant. Should complete in 2-4 mins...

$ vagrant up
-------------------------------------------------------------------------------
Your cloud name is set to: fcloud.drtst.org
-------------------------------------------------------------------------------
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'http://devsource/lcloud/boxes/boot2docker-1.2.box'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vcloud-docker_default_1415606582509_8383
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: bridged
-------------------------------- snipped --------------------------------------
==> default: Spinning up container: node
==> default: Spinning up container: master
==> default: Spinning up container: haproxy
$

4. Wait a couple minutes for DNS to propagate. You're done!

For more info...

Please check http://genie/wiki/Your+Cloud for detailed usage information and other tips...

Questions ???

Made with Slides.com