DevOpsCon Cloud Workshop

Sascha Möllering | zanox AG

Cloud Workshop

About me

Sascha Möllering

[email protected]

Lead Engineer / DevOps Hipster

zanox AG

http://autoscaling.io

@sascha242

About meJava Magazin 11.14

Architektur im Kontext der Cloud: Patterns und Best Practices

AWS Virtual Cloud Summit

Continuous delivery in AWS using Docker

http://aws-summit.de/

Entwickler Spezial: Docker

Über den Wolken: Ein Erfahrungsbericht zum Docker-Einsatz in der Amazon Cloud

Agenda

• AWS Overview

• Creating a cloud service

• Real World example

• Cloud deployment

• Q&A

How can we scale?

RegionRegionUS-WEST (N. California)

US-WEST (N. California) EU-WEST (Ireland)

EU-WEST (Ireland)

ASIA PAC (Tokyo)

ASIA PAC (Tokyo)

ASIA PAC (Singapore)

ASIA PAC (Singapore)

US-WEST (Oregon)US-WEST (Oregon)

SOUTH AMERICA (Sao Paulo)

SOUTH AMERICA (Sao Paulo)

US-EAST (Virginia)US-EAST (Virginia)

GOV CLOUDGOV CLOUD

ASIA PAC (Sydney)

ASIA PAC (Sydney)

Regions

Regions

EU-CENTRAL (Frankfurt)

EU-CENTRAL (Frankfurt)

AWS Overview

ZonesZones

Availability

Zone

Availability

Zone

AWS Overview

AWS Overview

EC2: Resizable compute capacity

AutoScaling: scale up or down

Route 53: Domain Name System

ELB: Load Balancing

Elastic IP: Static IP address

AWS Overview

RDS: Managed database service

DynamoDB: NoSQL implementation

Redshift: data warehouse solution

ElastiCache: Managed cache

Kinesis: Service for streaming data

AWS Overview

S3: Highly-scalable object storage

CloudFront: CDN implementation

CloudWatch: Monitoring service

IAM: Identity and Access Management

EMR: Managed Hadoop

CloudFormation: Configuration Mgmt

Starting point

• How can we leverage the Cloud?

• Our application:– Simple Java based web application

– One application

– One database

– Runs in our own DC

Creating a cloud service

• Initial setup:– Route53 for DNS

– One Elastic IP (static IPs for the Cloud)

– One EC2 instance• Web Application

• Database

– One AZ


Availability Zone


• Simple approach to scale:– Different EC2 instance type

• More RAM• More CPU power• More IOPS

• Approach will hit a barrier


• Problems:– No failover– No redundancy– Database and application on one instance– Does not scale very well


• Separate Web Application from DB– One EC2 instance for the Web Application– One EC2 instance for the DB– Or: Managed DB service (RDS)

• One AZ


Availability Zone

Database


• Problems:– No failover– No redundancy– Does still not scale very well


• Add an ELB

• Add EC2 instance for Web Application

• Different AZs

• Standby DB instance– Multi AZ setup in RDS


Availability Zone

Database

Availability Zone

Database


• Problems:– Still limited scaling capabilities– If one EC2 instance crashes, 50% less

capability


• Add additional EC2 instances

• Add read replicas in RDS


Availability Zone

Database

Availability Zone

Database


• Problems:– Naive implementation– Does not leverage AWS services– Limited scaling– Can be quite expensive


• Refactoring

• Introduce caches to take load from DB

• Use S3 and CloudFront to ship static content

• Store session data in DynamoDB

• Add Autoscaling


• Autoscaling– Automatic resizing of compute clusters

based on demand– Integrated to Amazon CloudWatch– Maximum and minimum pool sizes– Autoscaling policies triggered by

CloudWatch alarms


Requests

Elastic Load Balancing

Latency Metrics CPU Metrics

Amazon CloudWatch

MetricMonitoring

Alarm

Notification

Scale up/down


Availability Zone

Auto Scaling group


• Started with a simple web application

• Added several Amazon services

• Managed to shift load from application to services

• Added caches and CDN

• Added Autoscaling


• Next steps:– SOA/Microservices – Loose coupling: decouple interactions– Amazon services, don‘t reinvent the wheel– Database federation– Database sharding

Docker Deployment

• Amazon Services with Docker support:

– Amazon OpsWorks*

– Elastic Beanstalk

– EC2 Container Service

*by adding a custom Docker Layer

Docker Deployment

• On EC2 level:– Using the Docker remote API

– EC2 User Data

Docker Deployment

• Remote API– API to access Docker daemon

– Can be bound to specific host/port

– E.g. Jenkins can trigger deployments

– GET /containers/json

Docker Deployment

• EC2 User Data– Data to configure instance during launch

• Install Docker

• Start Daemon

• Run Docker container

Demo

• Elastic architecture that grows and shrinks

• Multiple AZs

• Use case: simple web app

• Elastic Beanstalk and Docker

• Postgres RDS DB

• JHipster– Yeoman generator– Yeoman is a scaffolding tool for webapps– Creates Spring Boot/AngularJS projects

Demo

• Support for:– Maven/Gradle– Spring Security– Spring Data JPA– Elasticsearch– MongoDB– Cassandra– ...

Demo

Elastic Beanstalk

• Docker support:– Dockerrun.aws.json specifies runtime– Dockerfile is an alternative

• EC2 instances using Docker 1.6

• No direct port mapping

• Local nginx reverse proxy

• Connects to IP of Docker container

Elastic Beanstalk

• Dockerrun.aws.json:– Specifies Docker image (support for private

registries as well)– Defines port for local nginx– Support for volumes and logging as well

Elastic Beanstalk

Elastic Beanstalk

But … we didn’t specify RDS connection strings in our Container?

• RDS specific values are exposed as ENV-variables

• Mapped into the Docker container

• Used by the application to connect to Postgres

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk

• nginx local proxy

• Config in sites-enabled and conf.d

• proxy-pass is http://docker

• Maps to container-ip

Elastic Beanstalk

DevOpsCon Cloud Workshop

Internet

Transcript of DevOpsCon Cloud Workshop