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!
- Slides: 76