Continuous deployment of Rails apps on AWS OpsWorks

Post on 23-Aug-2014

225 views 5 download

Tags:

description

A short overview of how Codeable team uses OpsWorks to host their application

Transcript of Continuous deployment of Rails apps on AWS OpsWorks

Continuous deployment of Rails apps on AWS OpsWorks

Slovenia Ruby User group meetup Monday, June 23rd, 2014

Text

$ whoamiTomaž Zaman, founder of Codeable, @TomazZaman, http://zaman.ioGeek, father of four, skydiver

SCRUM FTW!

Sprints (14 days)

Dailys (15 min each day)

User stories (1:1:1)

Only way to do CI!

Git workflowMaster -> Staging

Master -> Feature

Feature -> Staging

Feature -> Master (pull request, once feature done)

Master always deployable!

Gemnasium

One simple task: Report outdated gems

via email

CodeClimateAutomated code review

HipChat + Emails

Foreman (Uncle Bob, cleancoders.com)

SOLID + other principles

recommendations on refactoring

Travis CI.travis.yml - Instructions how to build a testing instance, how to run tests, matrices,…

HipChat webhook

Email web hook

Deploys to staging env.

pings CodeClimate

A bit expensive

Text

AWS OpsWorksMakin’ it easy to deploy stuff

How it compares to Heroku

A bit more work to get started

more moving parts you’re responsible for

similar pricing

Much more control (with great power comes great responsibility, Peter)

More complex CLI

Same integration with other services

Documentation is overly complex, lacking examples

Having all services under the same roof can be good or bad

Doesn’t enforce 12 factors, but not hard to follow them on your own

Primary elements:

Text

StacksA primary entity in OpsWorks, holding all other like Layers, Apps

Text

LayersLayer is a “box” for ordinary EC2 instances that perform the same role, such as host Rails apps.

Text

AppsRepresent an individual app which is also a repo on GitHub

ChefYour worst nightmare.But it’s awesome!

Written in Ruby, it’s an “automation platform”

Deployments (how they work)

A set of instructions to be ran on CLI or Webhook call

All application instances pull application from GitHub

Chef takes over to call deployment hooks (even custom ones)

Unicorn forks without downtime

If any step of the deployment goes wrong, the old app keeps being served (again, no downtime!)

deploy/before_restart.rb & co.

Other AWS toolsAmazon RDS

ElastiCache

Route 53

Virtual Cloud

Elastic IPs

Elastic Load Balancers (with health checking)

S3

Text

LoggingNeed to use external service such as Loggly, Papertrail, so logs need to go into Syslog (not 100% mandatory, but easier)

AsyncMany possibilities to solve this

OpsWorks doesn’t have a dedicated Worker layer

Possibility: Custom Chef recipe

Solution: Rake tasks + deployment hook

bundle exec rake sidekiq:start

ConfigurationCan be tricky, many possible approaches

Hook into Stack JSON and create a YML file on deployment, via deployment hook (tutorial: http://zaman.io)

Recapmerge into staging triggers Travis and Gemnasium

Travis runs tests, reports green or red

Travis reports to HipChat, CodeClimate

Manually run deployment rake task which initiates deployment via CLI

OpsWorks pulls latest master on servers in the layer that app is being deployed to

If no errors, Unicorn forks itself and runs rake tasks that restart async (Sidekiq) workers

Everything visible on Papertrail

Questions?