This document summarizes a DevOps presentation on using Vagrant and Chef to create consistent development environments. Vagrant allows creating and distributing virtual development environments that mirror production. Chef is a tool for automating server configuration management and provisioning using recipes and attributes. The presentation demonstrates how to set up a basic Vagrant environment and discusses benefits of using Chef such as reusable configurations, versioning, and querying server attributes.
1 of 49
More Related Content
Consistent Development Environment using Vagrant and Chef
1. 2014 DevOps Day – Philippines
February 22, 2014
Microsoft Philippines
8th Floor, 6750 Ayala Ave., Makati City
2. { DevOps Way } : Consistent
Development Environment using
Vagrant and Chef
Gerald Z. Villorente
DevOps Engineer | Drupal Developer | Open-Source Enthusiast
3. About Me
Started to learn how to use computer in 2005
I became a computer technician in 2007
I became a Web Developer in 2009
Drupalista since 2011
Drupal Developer at CNN Travel|KiteSystems 2011-2013
DevOps Engineer at BodogNation 2013-2014
Drupal Engineer at X-Team 2014-present
4. Agenda:
Agenda:
The Traditional Setup
What is Vagrant
Why to use Vagrant
DevOps with Vagrant in Mind
What is Chef
Why to use Chef
5. Your Dev and Prod
environment
are not the same!
Different Operating Systems
Different version of PHP|Python|Ruby|Node.js
Different configuration files
Different libraries and extensions
11. Reasons why we should:
Reasons why we should:
Consistent Operating Systems and PHP|Python|Ruby|Node.js
versions between production and development machine.
New comers can get going with the development right away. No
more painful setups.
Redistributable in case of hardware failure.
12. Reasons why we don't:
Reasons why we don't:
Can never get the networking between host and guest OS.
Scared of the command line.
Massive overhead keeping the VM up to date.
23. That's the OS only.
How about the
packages I needed?
Should I install them manually?
24. Well, you have 2 options.
Package an existing running environment.
$ vagrant package --base VM_ID --output BOX_NAME.box
Use Chef or Puppet to provision that packages and needed config.
32. Bash doesn't scale.
Seriously.
Bash is a wonderful thing, but like all UNIX tools, it is fundamentally
limited by design. Bash doesn't have a code reuse mechanism more
powerful than functions.
33. Maybe you can do this using “sed”. But hey are you sick?
35. NOSQL FTW
One of the virtues that many *nix tools share is that they store their
configurations in text files rather than binary formats or in a
database.
Chef stores your system configurations in text
and in a database. It accomplishes this by using the documentoriented database, CouchDB.
36. Knowing is Half the Battle
Chef uses Ohai to collect data about your system. Your recipes can
access these attributes and make decisions based on them.
For example, you can determine which version of Red Hat you are
using simply by looking up the value of node['platform_version']. You
don't have to cat | grep | awk to find out which release you are on.
37. Search
Search is a feature in Chef Server that allows you to query the
configuration information of all other servers and of globally-defined
databags (global variable). This allows you to do things like configure
clusters where a member of cluster needs to know not only about its
own configuration but about the configurations of the other
members of the cluster.
38. Knife
Knife is one of the truly great command line tools. It is your primary
mechanism for interacting with the chef-server. Knife shares many
usage patterns with git. If you love git, you'll love knife.
39. Shef
Shef works the way you work, in an iterative manner. Most of us
system administrators are self-taught and we learn best by doing.
Fire up shef and you can on the fly play with attributes and create
recipes. Further, you can connect to your server and download the
cookbooks.
40. Chef grows with you.
Chef uses pure Ruby as its configuration language, not a shackled
subset of ruby, nor yet another custom configuration language. You
only have to learn a small amount of ruby to get started with chef.
41. You can stop
reinventing the wheel.
Until Chef, we sysadmins did not have a truly modular way to
abstract and share our system configurations.