Slide Deck from our 2013 SANDCamp presentation. More of the content was likely captured in the conversation, as we used this deck as a jumping off point for the chat, but there's still some worthwhile concepts in there.

1. Drupal Integrated
DevOps Workflow
make yr shit right, son
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

2. About The Presenters
Steve Rifkin
Site Architect, Consultant, leans toward front end UI / UX
But not afraid of the backend?...ahem...can whip up some mean php when called upon)
7+ years building sites and data modeling (RoR)
LA Drupal User Group Organizer
Nicer than Craig
Craig McEldowney
Backend ninja, SOLR maven, Level 36 lawful evil Drupal mage
14 years building content management systems, 7+ years Drupal
Baby's got back-end development. not so keen on UI / UX
Crankier than Steve
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

3. About Crifkin
Craig McEldowney + Steve Rifkin = crifkin
Craig gets less namespace, but more clout
● Virtual CTO/CIO Services
● Cloud architecture / turnkey HA/HP solutions
● Developers looking for interesting problems to solve
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

4. Agenda
● Framing the Problem
● Playing the DevOps workflow game
○ Vagrant
○ Chef Server
● "The Cloud Mentality" -- HA/HP from local dev to
production
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

5. In the beginning
YOU build sites.
YOU do quality work.
More people hire YOU.
...
YOU become the limiting factor in this equation.
YOU need to scale yourself, your process, your team,
your clients.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

6. Framing the Problem
Developer/Process side
How do I support Client K who is running in
infrastructure Y while still supporting Client 4 who is
running in infrastructure 11.
How do I ingest new clients, yet still be able to support
older ongoing clients without getting cranky?
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

7. Framing the Problem
Team side
I need to hand off some coding/theming/support
responsibilities to another resource...
What's the fastest/cheapest/most effective way to get
them up and running so I can scale development
efforts?
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

8. Framing the Problem
Client side
I need to be able to handle configuration changes,
scale for traffic, address and balance High
Performance/High Availability requirements, and
provide a platform to grow with the client.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

9. Playing the DevOps
workflow game
Let's flip the problem on its head. If we
know where we're headed, we can make
some smart choices on the way to solving
them.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

10. In a perfect world...
How do we meet the client's needs for
HA/HP/scaling?
Configuration management and a supporting cloud
platform.
Crifkin spells this Chef + AWS = ChAWS.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

11. Huh?
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

12. Huh? (Chef Server)
● Chef = Configuration Management System
● Written in Ruby
● Idempotent execution -- e.g. running recipe(s)
multiple times will result in the same outcome
● Track stack architecture and allow servers to
register with the stack and query for specific
resources
● Other options: Puppet, Ansible, bash scripts and/or
hating your life
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

13. How does this help me?
I wrote all this cool chef stuff (recipes, roles). How
does this help me with my process/team and my own
efforts working for multiple clients?
The answer rhymes with Ragrant
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

14. Huh? (Vagrant)
● Ruby command-line toolset for managing VirtualBox
VMs
● Already built to pull configuration from Chef,
Puppet, Bash, and other scripting methodologies
● Package Virtual Environments
● Multi-VM Host Environments-- e.g. run a scaled out
production-like stack on your local environment
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

15. How does it fit together?
Why spend a bunch of time putting together a stack
and methodology for your production environment,
without giving yourself options and tools to manage
your local development efforts?
Let's talk about environments...
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

16. Chef: Environments
Chef allows you to create and assign nodes/servers to
environments. Environments allow you to override
server attributes/metadata, configuration parameters,
recipe run lists, etc.
So what if...
We break up our deployment into environments, with
resources to match each environment's needs.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

17. Chef: Environments
But instead of doing it in a stupid and boring way
● Lovingly handcraft servers and back them up
hourly, daily, weekly, never?
● Rats nest of client environment on local machine
● Steve doesn't understand what I do. I don't
understand what he does...custom scripting.
Let's use the "Cloud Mentality"
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

18. The Cloud Mentality
Some hard realities of cloud computing...
● Your servers are not beautiful and unique
snowflakes
● Things will break and you will cry
● Steve is nicer about these things than I am
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

19. The Cloud Mentality
The most important thing about your server is its
configuration. Chef takes care of this.
Chef has recipes and roles to define what a Webhead is, what
a Reverse Proxy is, what a BananaFarm is.
So crunch all you want, we'll make more.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

20. The Cloud Mentality
The difference between production and staging is the
number of servers. The difference between staging
and dev is the number of servers. The difference
between dev and your local machine is....
The number of Virtual Machines!
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

21. Prod/Live
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

22. Staging
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

23. Local Dev
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

24. Chef Server is the glue
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

25. Huh? (Howzit fit together?)
Local Dev Setup:
Install VirtualBox
Install Vagrant
Edit Vagrantfile and point it at your chef server
Spin up virtual machine(s)
Download DB/file assets from S3 or local-- use drush aliases to take DB dumps
from DB slaves where possible
Edit code on local machine IDE by either mounting WebDAV drive, or setting up nfs
share into Vagrant
Extra credit for running this all from a bash script and/or through a recipe in Chef!
Double credit for writing a homebrew...you Mac nerds
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

26. Um...right, this is Drupal
Gotchas and considerations when using templated
configuration for Drupal:
1. DB credentials/discovery
2. Other resources:
i. memcached
ii. SOLR
iii. Reverse Proxy
iv. etc...
3. Providing options for environment specific overrides -- e.g. no preprocess css in
Dev, etc.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

27. More advanced use-cases
Set up Continuous Integration
Use Jenkins or other post commit hooks to automagically
spin up a stack in a dedicated testing environment, and run
load, smoke, other tests
Dashboard controls for controlling environments-- a la Aegir,
but with Chef Server controlling the system configuration, and
manage scaling parameters (autoscale), scheduling scaling,
etc.
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

28. In a less perfect world...
Client is committed to existing
resources/deployment strategies?
● If this doesn't pose a business risk over an acceptable time frame,
then save that fight for another day...
● Migrate some portion of their stack to new environment-- e.g. dev
server/staging server?
OR
● Use smart DevOps magic for you and your developer(s) to your side
of this part of the process tight and efficient. Build up
recipes/configurations so that they can be used in prod later on
Craig McEldowney
crifkin.com @crifkin SandCAMP 2013 1/25/12 Steve Rifkin

29. Questions/Demo