Cloud

Infrastructure as a Service

Cloud Foundry

AWS

vSphere

OpenStack

Platform as a Service

Motivation

Load Balancing

BOSH creates and deploys virtual machines (VMs) on top of a physical computing infrastructure, and deploys and runs Cloud Foundry on top of this cloud. To configure the deployment, BOSH follows a manifest document.

Cloud Controller (aka CC ) runs the apps and other processes on the cloud’s VMs, balancing demand and managing app lifecycles. This allows you to stage and deploy app to CF. 🚩also maintain records of orgs, spaces, user roles, services, and more

Router routes incoming traffic from the world to the VMs that are running the apps that the traffic demands, usually working with a customer-provided load balancer

VM types

Component VMs that constitute the platform’s infrastructure

Host VMs that host apps for the outside world #

Diego system distributes the hosted app load over all of the host VMs, and keeps it running and balanced through demand surges, outages, or other changes. Diego accomplishes this through an auction algorithm.

Before sending an app to a VM, the Cloud Controller stages it for delivery by combining stack, buildpack, and source code ❓ into a droplet that the VM can unpack, compile, and run. For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.

Security, Auth

OAuth2 access control

user database

internal

external

LDAP

SAML

CF Implementation details

Storage

internal component states

MySql

large binary files blobstore

CF components communication

channels

NATS protocol to broadcast the latest routing tables to the routers.

GitHub

Deployment

monitoring

CF system logs

app logs, metrics

The Loggregator system aggregates the component metrics and app logs into a structured, usable form, the Firehose

triggering alerts

analyse user behaviour

apply nozzles

Services (databases or third-party SaaS APIs). To incorporate these into an app, a developer writes a Service Broker, an API that publishes to the Cloud Controller the ability to list service offerings, provision the service, and enable apps to make calls out to it.

prevent vendor lock (framework, set of app services, or cloud)

self-service application execution engine

automation engine for application deployment and lifecycle management

scriptable command line interface (CLI)

integration with development tools to ease deployment processes

open architecture that includes a buildpack mechanism for adding frameworks

routing target

hosted application running on a Diego Cell

periodically queries the Diego Bulletin Board System (BBS) to determine which cells and containers each application currently runs on

Cloud Controller component

Login server

Diego

how it manages apps

BBS = Stores more frequently updated and disposable data such as cell and application status, unallocated work, and heartbeat messages. (Go MySql driver)

CellRep = manages the lifecycle of those containers and the processes running in them, reports their status to the Diego BBS, and emits their logs and metrics to Loggregator.

Application code packages

Buildpacks

Droplets

provider

internal server

S3-compatible

nsync

Diego Cell VM runs

Garden container encapsulate Application instances, application tasks, and staging tasks

When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance

stores at

Diego BBS

Consul (longer-lived control data, such as component IP addresses and distributed locks)

HTTP(S)

Cloud Native Computing Foundation (CNFC) vendor-neutral project home

Kubernetes = open-source system for automating deployment, scaling, and management of containerized applications

Prometheus = monitoring system and time series database

Fluentd = Unified Logging Layer

Helm = Kubernetes Package Manager

Vitess = database clustering system for horizontal scaling of MySQL

Jaeger = Distributed Tracing System

NATS = High-Performance server for NATS, the cloud native messaging system.

OpenTracing

gRPC

Practice

Docker

editions

CE (Community Edition) (free, open)

EE (paid)

releases

stable, once a quarter

edge = beta, valid for a month

types

direct/easyStart = runs on local metal

cloud IaaS, with cloud-specific features

LDAP

GUI

longer support lifecycle

Docker for Windows 10

uses Hyper-V

more features than plain linux VM

PowerShell native

Docker Toolbox for other versions

Docker Windows 2016

YY.MM versioning

Container = instance of Image, running as a process

CLI

old syntax, new syntax using command+subcommand to organise. docker run vs docker container run

Image = binaries, source code, metadata (Dockerfile)

image registries (repository) DockerHub

Linux container

Windows container = Native Windows .exe binaries

Virtual Networks

all containers on a virtual network can talk to each other without being exposed via a port

each container is isolated and uses VPN bridge, only exposed via specific port

can use --net=host to use host IP

useful for testing too

DNS Round Robing = poor man's load balancer, able to map multiple containter to respond to the same URL
--net xox, --net-alias

no kernel or modules

can be as small as GO static binary

can be as big as Ubuntu with PHP, HTTP server and Databass

Tags = pointers to specific commits

latest (default, typically the most current version)

can be identified by

Image Layers = Union File system layering file changes. Performance.

Image Id = SHA hash

repository (similar to maven gropupId+artifact) name + version

can be pushed in a git fashion

can be private

Dockerfile

FROM

ENV

RUN

forward logging to stdout stderr, container picks from there

EXPOSE 80 443

CMD = final command to run image

steps are hashed and don't need to be executed if it's already cached = very short build times 🍾

Keep things that change the least the top of your dockerfile

WORKDIR

COPY (from local to image)

Art of melting existing images with your Dockerfile. Iterative (--rm)

Ephemeral, can be disposed at any time and re-summoned elsewhere. But where do we persist data while container is recycled?

Data Volumes = special location outside of container filesystem
🔒 need to be removed manually, outlives container.
⚠ Windows stores this in linux VM, not filesystsm

Bind Mounts = maps host file to container file or dir, 😃 dev-useful. Can't use in dockerfile, be be at container run -v //c/Users/...

VOLUME

practice: named volumes, used for persistent data

Docker Compose: Multi-Container dev tool

docker-compose.yml descriptor

docker-compose command for docker automation for local dev

with docker command in Swarm (built-in orchestration), for prod

version

services

volumes

network

-d

.ro means read only

new container-specific problems #

how to automate container lifecycle?

how to easily scale up/down?

how to ensure recreation if container fails?

hot to replace without downtime? (blue/green deploy = rolling update)

track/control what is running where

cross-node virtual networks

ensure only trusted servers

storing secrets and delivering them to the right container only

not enabled out of the box, docker swarm init

SwarmKit

Stacks = Compose files for prod

Secrets (built-in swarm-only)(with services)

Managers keeping replicated persistence database,encrypted comm, PKI certificat authority, commanding the working containers (gossip network)

docker service replaces docker run in Swarm, to handle scaling

vs Kubernetes 🚩

Hosting options

play-with-docker.com 4-hour session limit

locally docker-machine + VirtualBox (requires gigs of memory)

Digital Ocean + docker install. Cheap

Roll your own

docker-machine can provision machines for Amazon, Azure, Google etc

get.docker.com

Overlay: swarm-wide bridge network, only for intra-swarm comm

Routing Mesh (Scaling)

spans all nodes in swarm

uses IPVS from Linux Kernel

load balances services across their Tasks

stateless load balancing, using Virtual IP network

OSI Layer 3 (TCP, not DNS) load balancer

nginx or HAProxy or Docker EE solves shortcomings

skips build commands, just deploys

multi-service, multi-volume, multi-overlay-network, secrets

runs on one swarm

Tooling

Visualiser (image)

TLS certificates

SSH keys

usenames, passwords

Raft DB encrypted storage, at manager disk, then assigned to services with a Stack file

workers store secrects in memory only

either a file (local development) or via command line

pass the secret to a service and for convenience map the secret value to an environment variable

using secrets

Lifecycle

using secrets = not secure, but works for development (only file-based?)

implemented by

Pivotal Cloud Foundry

Kubernetes

Container Orchestration

Kubernetes

Docker Swarm

Mesos Marathon

Amazon ECS

HashiCorp Nomad

BeanStalk

Route53

EC2

X-Ray

Motivation

scaling

Vertical Scaling = Adding CPUs, RAM and other resources to a single application

Horizontal Scaling - Deploy multiple processes of the application

Stateless micro-services, no sessions

No reliance on server-hosted dependencies

Use environment properties for config (no XML, property files etc.)

Focus on quick startup/shutdown

self-contained jars, embedded servers - or

Log everything to stdout, no files

API-First technique - Agree on the boundaries between the modules and then start implementing them

Self-contained apps may not be practical for enterprise applications, so let's allow the PaaS (e.g. Foundry) to provide the application server, but it should still be 1:1 correlation between application and server. Never have more apps in one server.

Do not use caching, use an external caching service (e.g. Gemfire, Redis)

communication between services

minimize

asynchronous REST endpoints (async JAX-RS)

asynchronous REST clients (HTTP is blocking, need wrapper on both sides)

Frameworks

Spring Cloud Connectors

Spring Boot

pay as you go

Vagrant nastroj pro budovani virtualniho prostredi, treba neco na cem uz je konfigurovanej Docker swarm

click to edit

jednodussi, Kubernetes je slozity na dobre nastaveni

portainer.io

GUI

podava prehled o clusteru

lze pripojit libovolnej docker container a spravoavt ho

neco mezi kubernetes a dockerem

click to edit

pipeline od kodu do deploynutyho kontejneru je metodicky problem, ktery ani nevite ze mate dokud to nezkusite

neni uplne blbej napad vzit nejakou base distribuci linuxu (treba Ubuntu) a rozchodit tam to co potrebuju.
To je asi podobny pristup, ktery poskutuje OpenShift