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

1. Continuous deployment
of Rails apps
on AWS OpsWorks
Slovenia Ruby User group meetup Monday, June 23rd,
2014

2. Text
$ whoami
Tomaž Zaman, founder of Codeable, @TomazZaman,
http://zaman.io
Geek, father of four, skydiver

3. SCRUM FTW!
Sprints (14 days)
Dailys (15 min each
day)
User stories (1:1:1)
Only way to do CI!

4. Git workflow
Master -> Staging
Master -> Feature
Feature -> Staging
Feature -> Master (pull
request, once feature
done)
Master always deployable!

5. Gemnasium
One simple task: Report
outdated gems
via email

6. CodeClimate
Automated code review
HipChat + Emails
Foreman (Uncle Bob,
cleancoders.com)
SOLID + other principles
recommendations on
refactoring

7. 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

8. Text
AWS OpsWorks
Makin’ it easy to deploy stuff

9. 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:

10. Text
Stacks
A primary entity in OpsWorks, holding all other
like Layers, Apps

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

12. Text
Apps
Represent an individual app which is also a
repo on GitHub

13. Chef
Your worst nightmare.
But it’s awesome!
Written in Ruby, it’s an
“automation platform”

14. 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.

15. Other AWS tools
Amazon RDS
ElastiCache
Route 53
Virtual Cloud
Elastic IPs
Elastic Load Balancers (with
health checking)
S3

16. Text
Logging
Need to use external service such as Loggly, Papertrail, so
logs need to go into Syslog (not 100% mandatory, but
easier)

17. Async
Many 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

18. Configuration
Can be tricky, many
possible approaches
Hook into Stack JSON
and create a YML file on
deployment, via
deployment hook
(tutorial: http://zaman.io)

19. Recap
merge 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

20. Questions?