Saint Louis Cloud Foundry Meetup September 24 2015

Saint Louis Cloud Foundry Meetup September 24, 2015

Where did my DEA Go?

Diego Docker on Cloud Foundry Lattice

• Andrew Ripka • @rippmn • State transition negotiator

References • Except were noted material is based upon Diego Design Notes – https: //github. com/cloudfoundry-incubator/diego -design-notes

Caveats • I am not an expert on containerization • I am a Docker novice • The intent here is to introduce these topics – not a deep dive on any of them • I may not have answers to all questions, but ask anyway, at any time

What we will talk about • A little Cloud Foundry History – Elastic Runtime Service – DEAs • • Diego overview Live Dangerously Lattice Live Dangerously - II

What is Cloud Foundry “… Structured Platform for Continuous Innovation” Sam Ramji, CF Summit Keynote, May 2015

Cloud Foundry Elastic Runtime Service Platform cable of running, and monitoring arbitrary code in isolated containers

Cloud Foundry Push Haiku Here is my source code Run it in the cloud for me I do not care how Onsi Fahkouri – CF Summit, May 2015

Cloud Foundry Operator Haiku Give me your source code I will run it in the cloud I will handle how

Cloud Foundry Elastic Runtime Service HA Proxy LB Dynamic Router Cloud Controller Health Manager UAA Login Server DEA Pool Apps Service Broker Service Nodes Service Messaging (NATS) Metrics Collection App Log Aggregator Elastic Runtime BOSH Service Broker Service Nodes Service

Overview: Deploying App to Cloud Foundry Runtime ④ Deploy application DB Service credentials + app MD ② Create and bind services ③ Stage application Blobstore push app Cloud Controller Router ① Upload app bits and metadata DEA DEA Service Broker Node(s) DEA + = Cloud Foundry Runtime (Paa. S)

DEAs • Runtime for warden containerized workloads DEA Pool Apps

Polyglot Languages? ? • Support any language you could run on Linux – – – Java Go PHP Ruby Node. JS Python

. Net? ? • Iron Foundry • DEA’s on Windows Servers Iron Foundry Image source http: //www. ironfoundry. org/help/Legacy-Cloud-Foundry-Windows-Core-Install. html

Iron Foundry • Essentially a complete DEA rewrite for Windows • Non trivial to do Warden containers on Windows

DEA Rewrite • Support for multiple backend implementations without warden rewrite • Remove dependency between components • Might as well be in Go

DEA Rewrite Cloud Controller Garden API Health Manager Garden Backend DEA Pool Apps

Enter Diego (1 year ago) • A distributed system that orchestrates containerized work loads – Self Orchestrated/Managed Cluster • placement by auctions • Collective? http: //www. startrek. com/database_article/borg-cube-at-system-j-25

Some Diego Scale Limitations • At scale there is a lot of cross “cell” communication – Auctions with lots of bidders? – Limitations of size of cluster (+1000 s)

http: //en. memory-alpha. wikia. com/wiki/Borg_history

Enter Diego (Today) • A distributed system that orchestrates containerized workloads • Uses a “Brain” to coordinate orchestration/auctions http: //www. startrek. com/database_article/borg-queen

Containerized Workloads • Tasks – Run at most once • Long Running Process (LRP) – N long-running instances distributed across cells for HA that are monitored & restarted

Containerized Workloads? • Isolation of access to CPU, network, storage – Allows multiple containers (tenants) to run on same runtime • In Linux namespaces – PID – User Namespace – Network – Mount

Core Diego

Key Components • Cell • Brain • Bulletin Board System (BBS)

BBS • Diego’s internal communication mechanism • etcd with Diego schema • “An up-to-date cache of the state of the Diego cluster (including a picture-in-time of all desired LRPs, running LRP instances, and inflight Tasks). . ” https: //github. com/cloudfoundry-incubator/diego-design-notes

Brain • Auctioneer – holds auction to place Tasks and LRPs • Converger – ensures eventual consistency of the system (in BBS) • Metrics-Server – collects Diego metrics and forwards back to Cloud Foundry

Cells • The VM that runs/hosts “garden” containers • Some other stuff – Receptor – Metron – Rep – Executor

Receptor • Restful API to Diego

Metron • forwards logs and metrics into the Loggregator subsystem of Cloud Foundry

Rep • represents Cell in BBS and Auctions

Executor • starts and runs workloads in Garden containers per defined Actions

Garden • Platform Independent API to manage containers • Defines interface for container runners (Garden backend implementations) – Garden Linux –. Net

Executor • Calls Garden to create containers and assign work • Does not care about Tasks vs LRPs • Work is done by backend agnostic Action API

Action API • • Run. Action Download. Action Upload. Action Parallel. Action Serial. Action Emit. Progress. Action Timeout. Action Try. Action

What about existing Cloud Foundry?

CC Bridge

CC Bridge • Interface for Cloud Controller • Translates Cloud Foundry App Specific notions into Diego generic task and LRP context • Calls Receptor API

CC Bridge Components Stager – converts Cloud Controller staging requests to Tasks

CC Bridge Components Nsync – creates/updates apps as LRPs, ensures Cloud Controller desired state is represented in Diego

CC Bridge Components TPS – provides info on Apps running as LRPs in Diego to CC

CC Bridge Components File-server – returns “staged” container packages (droplets) to CC – serves static app related content (App Lifecycles)

Route Emitter

Route Emitter • Bridge between Receptor and Router • Monitors LRP desired/actual and updates ERS Router accordingly • Periodic bulk update

Also need to get Legacy model cf push

App Lifecycles Binaries that represent implementation of Cloud Foundry Lifecycle in Diego

App Lifecycles Builder • runs task to stage an CF App • Static analysis of code • Any other necessary preprocessing

App Lifecycles Launcher • run App as containerized LRP • executes the user's start command with the correct system context

App Lifecycles Healthcheck • Checks stats of app • set as Monitor action on the CF application's Desired. LRP

Lifecycles • Buildpack (What DEAs use today) • Docker Image

Buildpack Lifecycle • Builder - downloads buildpacks and app bits, and produces a droplet. • Launcher - runs the start command using a standard rootfs and environment • Healthcheck – tcp port check on 8080

Droplet LRP Definition { memory: 128 mb, Create Container rootfs: “preloaded: cflinuxfs 2”, setup: <download-droplet>, } run: {metadata}. start-command Container Contents Start Command

Docker Lifecycle • Builder - extracts the start command execution metadata from the Docker image. • Launcher - executes the start command with the correct cloudfoundry and Docker environment • Healthcheck – tcp port check on 8080

Docker LRP Definition { memory: 128 mb, Create Container rootfs: “docker: //docker-image”, } run: {docker metadata}. start-command Container Contents Start Command

. Net?

First Thing to understand • Diego allows non-homogenous Cells – Garden API call a Garden Backend implementation • Today this means – Start with cluster of Linux Cells – Add Windows 2012 R 2 Cells

What about Containers? Garden-Linux resource isolation cgroups namespace isolation PID Network User Mount Garden-Windows resource isolation kernel job object disk quotas namespace isolation user profiles Host Web Core (an isolated IIS instance)

. Net Lifecycle • Builder - Nothing • Launcher - runs the start command using a standard rootfs and environment • Healthcheck – tcp port check on 8080

. Net LRP Definition { memory: 128 mb, Create Container rootfs: “preloaded: windows 2012 R 2”, setup: <download-application> } run: {metadata}. start-command Container Contents Start Command

So What?

One Polyglot Cluster

Live Demo

Lattice

Lattice Subset of CF designed to get introduced to Diego http: //lattice. cf

Why Lattice? • …need useful low-entry-barrier solution to real-world problems • …make exploring Diego easy • …is a softer onramp to the CF tech stack • …allows us to efficiently prototype new ideas for Diego’s future

Why Lattice? • I think Lattice is better suited to work on building containerized distributed applications • Particularly where the buildpack model is stretched, • Or other non full CF use cases

What is Lattice really • Interact with Receptor API • What good are LRPs if I cannot reach it? • Or if I cannot debug/see logs of it?

Lattice • Lets start with Diego Cluster (Cells/Brain/BBS) • Add Router – endpoint reachability • Add Loggregator – streaming logs

Lattice

Where can I run? • Locally – Vagrant File • In the cloud (Terraform Templates) – Digital Ocean – AWS – Google Compute Cloud – Open Stack

Lattice Demo

Links • Diego Design Notes- https: //github. com/cloudfoundryincubator/diego-design-notes • Lattice – http: //lattice. cf • Onsi Fakhouri CF Summit Presentation - https: //youtu. be/1 Okm. VTFhf. LY

Thank you!