00 Breaking Ice

IT solutions constantly feel like: https://youtu.be/C2YZnTL596Q?t=46s

But ever so often, we do make a leap that allows us to deal with problems of a higher order.

From dedicated boxes and expensive data centers to virtualization and now to containers and container management. We constantly evolve new ways of doing our job better.

We are here to grok the basics of a bunch of overlapping technologies. This may be confusing to start with, so we’ll focus on a lot of hands on sessions.

This is in no way a comprehensive survey of the field, nor is it a extremely deep dive into the inner workings of distributed computing, datacenters etc. The goal is to familiarize you with these technologies and give you a solid grounding on Mesos and DC/OS.

Each new technology ‘trend’ must be taken with a grain of salt, a technology that worked well for one type of solution may not work for another. Our sessions here may give you some insights into how to make this decision as well.

01 Install Dependencies

• Ensure that virtualization is enabled on your desk/laptops
• Ensure the following are installed
  • Docker
  • Mingw or Cygwin
  • Git with ssh, add location of the bin folder to your ‘PATH’ (C:\Program Files\Git\bin in my case)
  • Vagrant
  • Oracle Virtual Box
  • others as necessary
• for all config files and others, make sure that you use unix style line ending in Notepad++

02 Why Mesos, DC/OS?

We started with simple applications, monolithic in nature and from there graduated to:

• Web applications where the presentation layer was replaced by the browser
• Scale and high availability forced us to explore horizontal and vertical scaling
• Then came ‘Service Oriented Architecture’ - services were applications with no UI that could be composed in many ways for the presentation layer and for the data layer as well.
• By this time the harware had improved quite a lot and we were looking at warehouse scale computing.
• Along came virtualization. You could run several virtual machines on the same hardware box.
• The microservices were next along with ‘containerized microservices’ - these were descendents of work done on Linux Namespaces and Linux Containers.
  • Where a virtual machine may have millions of lines of code, a linux container could work in as little as a few thousand lines of code. From nearly a GB to just a few megabytes - that a container starts fast and is diposable is also a huge win.
  • …by the way anyone remember https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate this?
• We can now securely isolate processes and applications.
• Services and apps work on top of a container runtime
• Container orchestration enables one to automatically deploy multiple containers and manage their lifecycles.

But that is easier said than done. Let’s look at some of the areas one must attend to in today’s IT ecosystem.

Orchestration: [Service Managment, Scheduling, Resource Management]

Resource Management: [Memory, Disk, Processor, IP, Ports]

Scheduling: [Placement, Replication/Scaling, Resurrection, Rescheduling, Rolling Deployment, Upgrades, Downgrades, Collocation]

Service Management: [Groups, Namespaces, Dependencies, Load Balancing]

Debugging: [Log, Monitoring, Metrics, Shell based remediation]

Maintenance: [Upgrades, Capacity planning, Backups, Disaster Recovery]

… and on and on…

Wait, there’s the non-functional requirements too:

Usability, Scalability, Availability, Portability, Flexibility, Security, Agility

…and you can’t have them all.

So IT becomes a game of tradeoffs and strategies, and we need all the help we can get.

Mesos and DC/OS

• It helps to think of it as the system that runs a bunch of containers on top of a bunch of virtual machines - this may not be strictly technically accurate, but it’s a good mental model to start with.
• Mesos works with containers from the ground up
  • does for containers what windows does for .exe and .dll files
• DC/OS builds on top of Mesos to provide capabilities for managing an entire datacenter
  • uses a YAML based configuration file on top of Vagrant

03 Vagrant Up

Why?

• Virtualization technology, while very valuable, adds a lot of variables to the mix
  • which provider?
  • what capabilities?
  • how to account for a change in the CLI or API of a provider?
• Configuring just the right virtual environment becomes a big ask
• Enter Vagrant
  • allowing one to truly automate the tasks of setup, start/pause and teardown of disposable virtual environments

…and What?

• tool for building and managing virtual machine environments
• supports multiple:
  • Providers - infrastructure providers like VirtualBox, VMWare, AWS etc.
  • Provisioning tools - configuration management tools like Chef, Puppet etc.
• enables environments (entire virtual machines) that are:
  • configurable in a consistent, unified workflow
  • reproducible
  • portable

Aside: Vagrant and Docker

• Vagrant is a workflow tool for setting up virtual environments in a consistent manner. It provides a wrapper on top of the CLI provided by the various vitual environment hosts.
• Docker is a container management tool - containers are very lightweight, so starting and stopping them is more efficient, this is really attractive for microservices scenarios. Later we’ll see how one can use the docker provider with Vagrant.

Vagrant vocabulary

• Boxes - Package format for the Vagrant environment. Just like a ‘class’ in Object oriented programming. One just needs a box to consistently bring any environment up.

• Provisioners - allow one to automatically install software, alter configurations, and more on the machine as part of the vagrant up process.
  • Provisioners are available for Chef, Puppet, Ansible, Docker etc.

• Synced folders - enable Vagrant to sync a folder on the host machine to the guest machine. This allows you to continue working on your project’s files on your host machine, but use the resources in the guest machine to compile or run your project. By default, Vagrant will share your project directory (the directory with the Vagrantfile) to /vagrant. We can use a type of synced folders type: “smb” (SMB stands for Server Message Block) to work with synced folders on Windows, bear in mind that this is new and hence has some limitations. It does not clean up the shared folders automatically. To clean up SMB synced folder shares, periodically run net share in a command prompt, find the shares you do not want, then run net share NAME /delete for each, where NAME is the name of the share..

• Multi-machine - allows one to setup multiple machine environments - such as a database and a web server.

How? - Hands On: Vagrant

Let’s try our hand at Vagrant so we build a fair level of comfort with the technology. In future, this will give us insights into DC/OS and will also give us a good grounding for installing a small DC/OS cluster on our local machines. Please follow along closely and ensure that you complete all the steps.

Basics

• For this part of the session, please create a new folder. For e.g. I created C:\1\v1 for this part of the session.

• To use Vagrant, one simply needs to create a VagrantFile and call vagrant up. Everything is installed and configured for you to work, consistently.

• To create a sample VagrantFile, run:

vagrant init

• precise32 and precise64 are very commonly used boxes.

• Let’s add the precise32 box, to do so run:

  vagrant box add hashicorp/precise32
  

• Vagrant will download the box to your machine

• Let’s now modify the VagrantFile, so it picks up this new box:

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "hashicorp/precise32"
  end

• notice how the do is really assigning a variable name to a complex object in the code above.

• You can explore other boxes on the Hashicorp Atlas, which serves as a registry of boxes: https://atlas.hashicorp.com/boxes/search

• Now we can start the VM by using:

vagrant up

• To ‘pause’ the VM, run:

vagrant suspend

• To resume again, run:

vagrant resume

• To shut down the VM completely, run:

vagrant halt

• To shut down the VM completely and destroy all resources that were created during machine creation, run

vagrant destroy

Forwarded Ports

• For this next bit, we’ll configure ‘Forwarded Ports’
• Edit your VagrantFile to add the following information, if you’ve used the default file, you should be able to uncomment the port forwarding line.

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "hashicorp/precise32"
  config.vm.network "forwarded_port", guest: 80, host: 8080
  end

• This enables public access on your vagrant VM. If you get to localhost:8080 on your machine, it’ll connect to port 80 on the VM.

• Let’s install Apache real quick to confirm that this works.

• Start your VM again.

vagrant up

• Configure ssh

  vagrant ssh
  

• SSH into the vagrant VM using

   vagrant ssh
  

• first we update precise32

sudo apt-get -y update

• now we install apache2

sudo apt-get -y install apache2

• let’s sudo up to a priviledged role so we can start Apache easily

sudo su

• start apache2

   /etc/init.d/apache2 start
  

• now open a browser in windows (chrome?) and go to http://localhost:8080/ you should see the “It works!” page.

• port forwarding is working! :)

• let’s stop Vagrant again before we move on.

vagrant halt

NB: Another approach to installing Apache2 using a shell script at startup is described here: https://www.vagrantup.com/intro/getting-started/provisioning.html

Multi-machine setup

There may be scenarios where you’d want to setup more than one VM at the same time. Some really good reasons listed on Vagrant’s site:

• Accurately modeling a multi-server production topology, such as separating a web and database server.

• Modeling a distributed system and how they interact with each other.

• Testing an interface, such as an API to a service component.

• Disaster-case testing: machines dying, network partitions, slow networks, inconsistent world views, etc.

As I am sure you can see, there may be more.

Let’s see how simple it is to setup two machines at the same time.

• In the Vagrant file one can easily define more ‘boxes’. Look at the sample code below (it wouldn’t run just yet, we’ll do that when we move on to DCOS).

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.provision "shell", inline: "echo Hello"

  config.vm.define "web" do |web|
    web.vm.box = "apache"
  end

  config.vm.define "db" do |db|
    db.vm.box = "mysql"
  end
end

• A few key aspects jump out:
  • One can define many VMs using multiple define .. end loops.
  • The order in which the VMs will be instantiated is:
    • Outside-in for machines listed in different scopes, the outermost machine being worked upon first
    • In-order for machines listed in the same scope, the topmost machine being worked upon first.

Exercise - ideally 30 minutes, not exceeding 45 minutes

• Create two VMs, one web and another data. Install Apache2 on the web and MySQL on data (or any other database).
• Ensure that web is up and running before data comes up.
• Use forwarded ports and show any information, absolutely any information about the database in the Apache2 index page. You should be able to open your brownser
• You may use the Vagrant Atlas to explore which boxes to use.
• If you choose to use the precise32 box, feel free to install Apache2 and MySQL separately on the VMs.

04 Hands On: Setup a DC/OS cluster locally

We’ll use: https://github.com/dcos/dcos-vagrant/

• Before starting let’s ensure that we have the latest versions of Git, Vagrant and Virtual Box

• First, let’s completely shut-down and clean up earlier machine (or you can halt the earlier machine and create a new folder for this part)

vagrant halt

or

vagrant destroy

• Install the vagrant hostmanager plugin:

vagrant plugin install vagrant-hostmanager

• now clone the git repo into your folder:

git clone https://github.com/dcos/dcos-vagrant

• move into the new directory

cd dcos-vagrant

• copy one of the available vagrant configurations into the VagrantConfig.yaml file. This will be read by the VagrantFile script during vagrant up

copy VagrantConfig-1m-1a-1p.yaml VagrantConfig.yaml

• Each machine in VagrantConfig.yaml must specify one of the following node types that governs how that machine will be * provisioned:*

  • master - Master node that runs the DC/OS core components (e.g. m1)
  • agent-private - Agent node that runs the Mesos agent with the * role (e.g. a1)
  • agent-public - Agent node that runs the Mesos agent with the slave_public role (e.g. p1)
  • boot - Bootstrap node that runs the installer (e.g. boot)

• I have only done the simplest one, but please choose the one that your laptop/machine can handle. As an added exercise try to setup a 1 master, 3 private agent, 1 public agent, 1 boot node configuration on a desktop with a good amount of RAM and hard drive space.

• Let’s start vagrant now, it will download and install DC/OS and will setup the entire cluster:

vagrant up

• If you are prompted for a password, use your local machine’s password.

• Once it’s up and running navigate to http://m1.dcos/ in a browser to check out the UI for the cluster you’ve just setup.

• Now vagrant halt for the master nodes has been disabled by dcos-vagrant, so the right way to shut down this cluster is:

vagrant destroy -f

That is it for today! :)

05: Day 02

We’ll look at:

• Docker providers in Vagrant
• Using our DC/OS cluster in meaningful ways
• Get a close look at Marathon, Chronos and Zookeeper