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 ???