Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Develop and Test Configuration Management Scrip...

Develop and Test Configuration Management Scripts with Vagrant

Configuration management and systems automation has really taken off the past few years, and the tooling around this has been rapidly improving as well. However, many engineers working with these tools still write entire scripts, spin up a new server, test them on that server, and then work through any issues they may face. Incremental development is rare or unheard of and basic testing of such scripts is cumbersome.

In this talk I will present using local virtual machines along with Vagrant as a way of enabling incremental development for server provisioning, and how it can be used to provide more stability and predictability during development. Additionally, I will talk about how organizations are using Vagrant as a way to also do basic integration testing of server provisioning scripts.

By enabling incremental development and providing a method for testing these scripts, the entire feedback loop during development is shortened which leads to higher stability and confidence of server provisioning.

Vagrant is an open source tool that has been around for about 2 years now. It provides a command line tool to create and manage virtual machines and is used by companies and organizations such as Rackspace, LivingSocial, EventBrite, Yammer, Nokia, and many more.

Mitchell Hashimoto

June 26, 2012
Tweet

More Decks by Mitchell Hashimoto

Other Decks in Programming

Transcript

  1. A Look at Web Ops Today Let’s take a look

    at what the daily life in web ops looks like today...
  2. “Automate the installation and configuration of Apache.” So your boss

    comes to you and says this... what do you do next? NOTE: We’re going to use Chef for examples because thats what I do, but it shouldn’t get in the way of any understanding.
  3. cookbooks ! mkdir -p apache2/recipes cookbooks ! vim apache2/recipes/default.rb First

    you’ll probably go into some “cookbooks” directory and make an apache2 cookbook and a default recipe.
  4. 1 package "apache2" do 2 action :install 3 end 4

    5 service "apache2" do 6 action :enable 7 end 8 9 template "apache2.conf" do 10 path "#{node[:apache][:dir]}/” + “apache2.conf" 11 mode 0644 12 notifies :restart, resources(:service => "apache2") 13 end You might type something like this into your recipe, using your best guess as to what it takes to install and configure Apache. Or perhaps you have a server somewhere you’re trying this out on as you go via SSH. Either way, you’re kind of guessing here.
  5. cookbooks ! ./start_ec2_instance_for_test.sh So now you have a semi-working cookbook

    and you want to test it. Let’s be generous and assume you have some process for “quickly” bringing up some remote server (in this case EC2) for test. You run that script.
  6. cookbooks ! ssh ubuntu@... Welcome to Ubuntu 12.04 LTS! ubuntu$

    vim config.json You have to configure Chef now to run the cookbook you just made. Note that we’re making more assumptions here that your cookbooks were somehow rsyncced or found their way onto this server.
  7. 1 { 2 "run_list": ["recipe[apache2]"] 3 } Chef configuration to

    run your single recipe that you’re developing.
  8. cookbooks ! ssh ubuntu@... Welcome to Ubuntu 12.04 LTS! ubuntu$

    sudo chef-solo -j config.json Next you run Chef..
  9. cookbooks ! ssh ubuntu@... Welcome to Ubuntu 12.04 LTS! ubuntu$

    sudo chef-solo -j config.json [Sun, 24 Jun 2012 21:33:14 -0700] INFO: *** Chef 0.10.2 *** [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Setting the run_list to ["recipe[apache2]"] from JSON [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List is [recipe[apache2]] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List expands to [apache2] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Starting Chef Run for lucid64 [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Processing execute[apt-get update] action run (apache2::default line 1) [Sun, 24 Jun 2012 21:33:15 -0700] INFO: execute[apt-get update] sh(apt-get update) [Sun, 24 Jun 2012 21:35:29 -0700] INFO: execute[apt-get update] ran successfully [Sun, 24 Jun 2012 21:35:29 -0700] INFO: Processing package[apache2] action install (apache2::default line 3) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: package[apache2] installed version 2.2.14-5ubuntu8.9 [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Processing service[apache2] action enable (apache2::default line 7) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Chef Run complete in 175.23797 seconds [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Running report handlers [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Report handlers complete And you get output that looks like this. Normal chef output. Looks like things worked! Alright. We’re getting somewhere. So the next step is that you probably need to be able to configure vhosts on the instance, so we want to setup Chef to be able to configure vhosts.
  10. cookbooks ! mkdir -p apache2/definitions cookbooks ! vim apache2/definitions/site.rb So

    you start working on an “ apache2_site” definition, which will be a resource in Chef to create vhosts.
  11. 1 define :apache_site, :enable => true do 2 ... 3

    4 if params[:enable] 5 execute "a2ensite #{params[:name]}" do 6 command "/usr/sbin/a2ensite” + “#{params[:name]}" 8 notifies :restart, resources(:service => "apache2") 9 end 10 else 11 ... 16 end 17 end Here is what it might look like. Don’t worry about understanding this if you don’t know Chef, just know that you’re WRITING CODE.
  12. cookbooks ! ./start_ec2_instance_for_test.sh And nowwwwww we want to test it

    so we need to bring up a new instance. Note: Yes, maybe you can re-use your old instance, because this time we’re just ADDING things to Chef, but what if you were CHANGING previous resources? Chef can’t undo, so you’d need a new instance. Wahhhhh!
  13. Repeat. Again. And again. Anddddd you follow this process and

    repeat it over and over until you get to the state you want and feel its ready for stage/prod.
  14. PRODUCTIVITY FAILURE. This is a huge failure. This process has

    a ton of problems associated with it...
  15. Extreme case? Maybe. Maybe not. Is this an extreme case?

    For some people yes, but for some people no. I assumed a lot of things: * Automated server startup + Chef setup. * Chef somehow configured with cookbooks already on server. * Chef-solo, not chef-client. Therefore, kind of a toss-up. It can be extreme, but I think for a lot of people this rings true.
  16. A Look at Web Dev Today So we saw the

    ops side of things, let’s take a look at the dev side of things. Realizing Velocity is an “Ops” conference, but we’re also responsible for providing sane development environments as well. So let’s see what devs typically go through nowadays...
  17. “You’ve been hired! How about you get the site up

    and running your shiny new MacBook Air?” A developer gets hired, and the boss says THIS! What is the next step?
  18. sites ! git clone git://.../facebook_killer.git Cloning into “facebook_killer”... sites !

    cd facebook_killer facebook_killer ! ... Next, SOMETHING happens. We’ll get back to this, but SOMETHING HAPPENS.
  19. sites ! git clone git://.../facebook_killer.git Cloning into “facebook_killer”... sites !

    cd facebook_killer facebook_killer ! ... facebook_killer ! ./start.sh Server listening on http://localhost:3000/... Then you run some script that starts a server and you’re OFF AND RUNNING! Ready to work!
  20. sites ! git clone git://.../facebook_killer.git Cloning into “facebook_killer”... sites !

    cd facebook_killer facebook_killer ! ... A small sacrifice is made to Flying Spaghetti Monster Well, let’s take a look at this “...” step... Typically this step requires a small sacrifice to some deity. What goes on here?
  21. sites ! git clone git://.../facebook_killer.git Cloning into “facebook_killer”... sites !

    cd facebook_killer facebook_killer ! ... Let’s take a closer look...
  22. Scenario 1: You have a setup script. First potential scenario

    is that you have a setup script, which is a script you run which sets up your environment for development.
  23. facebook_killer ! ./setup.sh Installing some server... Installing some software... Configuring

    it all... Successful sacrifice made to FSM. It MIGHT look like this.
  24. Scenario 1: You have a setup script. UNLIKELY But this

    is an unlikely scenario. Its possible, but unlikely. Even if it does exist, there are some problems.
  25. • Your Mac is not what is running in production.

    Your Mac/Windows machine is not what is running in production. Your linux machine may be pretty similar, but ignoring that. Therefore, you’re trying to install server software on your own machine, in an environment it was not meant to run. You’re asking for trouble.
  26. • Unlikely that all the software you need will work

    the same on your machine Sure, Apache, MySQL, etc. work and compile fine on Windows and Mac. But then you start getting some weird dependencies... or you write your own libraries. Its unlikely you want to spend any serious amount of time working on getting compilation working in every environment.
  27. • Unlikely it is configured the same, which leads to

    pain later Example: MySQL has HUNDREDS of configuration parameters. You may configure them similarly so that it appears to work on your machine, but undoubtedly at some point in the future these slight configuration changes will cause HUGE WEIRD bugs.
  28. • Requires special maintenance And perhaps most importantly, this setup

    script requires individual maintenance. That means that it’ll likely just decay and end up not working for periods of a time without large amounts of developer discipline. Things that require EXTRA WORK, typically don’t work.
  29. • What if people want to work in Windows? Linux?

    So if you have other operating systems out there for dev, you’re going to cater these setup scripts to work in all environments? Yeah, right.
  30. Scenario 2: The Über-README. Next scenario: You have an UBER

    README. This is a README that doesn’t DO anything except tell the developer how to set up his/her environment.
  31. • Extremely prone to user error. Actual execution of the

    setup is left to the user, who will likely do things wrong or differently.
  32. • Heavy Maintenance Very careful steps must be maintained for

    every operating system for every piece of infrastructure. Like I said before, extra work doesn’t usually work.
  33. • Time consuming The time for a new hire to

    get a site up and running goes from hours to days. I’ve heard of larger companies doing this (> 250 employees) where the time for an engineer to get a site up and running actually took 5 days. Whoa.
  34. Development Setup is also an Operations Problem Dev setup is

    also an ops problem, because we’re responsible for making sure they’re environments are working properly. Ops people work very hard to have stable systems up and running in production, why can’t that transfer over to development?
  35. Problems: • Not repeatable • Not verifiably correct • Not

    isolated • Difficult to understand • SLOW, SLOW, SLOW!
  36. Virtual Machines So is there some technology out there that

    can help solve some of this ops/dev pain that exists today? VIRTUAL MACHINES! This has been known for some time, this isn’t revolutionary.
  37. • Isolated • Repeatable • Model complex relationships For Ops:

    VMs allow Ops to work in isolated environments, just how we’d like to test ops things initially. VMs are scriptable, ephemeral. We can use our programming skills to make a repeatable working environment. VMs are full mini-machines that are cheap, so we can just make lots of them to model complex relationships (such as distributed systems).
  38. • Automated • Local • Host-OS agnostic For Dev: For

    dev, VMs are automated, which has numerous benefits: repeatable, easy, verifiable, testable. The VMs are or can be local, so developers can work on their own machine. Most VM providers provide software that works on most major platforms, so developers are free to work on the platform they want.
  39. • Faster on-boarding • Anyone can do it • Less

    bugs For Biz: And there are also BUSINESS benefits. On-boarding times are slashed. When you hire a new employee, they can have a new environment up and running in a matter of minutes rather than hours or days. Anyone can do it, so even designers can bring up development environments if they want to. And there are less bugs, because the development environments are all the same so you get rid of the “works on my machine” bugs.
  40. The Idea: Build local VMs to match production and develop

    there. So the idea to solve our problems is this.
  41. We have many options when it comes down to local

    virtualization... So do we just pick one? LXC
  42. Feature Breakdown • Simple management interface (CLI) • VM Creation

    • Provisioning • Scripted config of VM properties • Scripted config of networks • Scripted config of shared file system • Single command setup
  43. VirtualBox Only, for now. Vagrant is currently VirtualBox only. When

    Vagrant started, VirtualBox is the only freely available virtualization tech that works on every major platform that also has a comprehensive API. It was the best choice to spur adoption. That being said, this will change in the
  44. ~ ! vagrant Usage: vagrant [-v] [-h] command [<args>] -v,

    --version Print the version and exit. -h, --help Print this help. Available subcommands: box destroy gem halt init package provision reload resume ssh ssh-config status suspend up For help on any individual command run `vagrant COMMAND -h`
  45. How does it work? • Vagrantfile • vagrant command line

    interface These are the two components that Vagrant needs to work. We’ll go over each in detail a bit later, the main point now is that there are simply two things that make things work.
  46. Vagrantfile • Per-project configuration • Configure VMs • Configure networking,

    provisioning, shared file system • Ruby DSL, no Ruby knowledge needed
  47. vagrant • Single command to control lifecycle of your virtual

    machines. • git-style. “vagrant <subcommand>”
  48. vagrant up • Single setup command • Creates VM •

    Configures properties of VM • Configures networking and shared file system on both host and guest • Provisions the guest
  49. http://vagrantup.com Vagrant Concepts Now we’re going to go over the

    concepts of Vagrant. This section will be light on sticky notes because the slides are mostly self-explanatory.
  50. Base Boxes • Base images for creating VMs • Minimal

    software set installed - SSH - Chef/Puppet (optional) • Includes VirtualBox Guest Additions
  51. ~ ! vagrant box Usage: vagrant box <command> [<args>] Available

    subcommands: add list remove repackage For help on any individual command run `vagrant box COMMAND -h`
  52. Adding a Box $ vagrant box add <name> <url> •

    Name: Local name referenced in config • URL: File path or HTTP URL.
  53. Finding Boxes • “Official” Boxes: - lucid32, lucid64, precise32, precise64

    - http://files.vagrantup.com/NAME.box • 3rd Party: - http://vagrantbox.es
  54. • Vagrant is project-oriented • VMs exist in the context

    of a “project” • Project denoted by existence of a Vagrantfile Projects?
  55. ~ ! vagrant init lucid32 A `Vagrantfile` has been placed

    in this directory. You are now ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant.
  56. • Configures Vagrant for your project • Ruby DSL •

    No Ruby knowledge needed Vagrantfile?
  57. ~ ! vagrant up [default] Importing base box 'lucid32'... [default]

    Matching MAC address for NAT networking... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
  58. ~ ! vagrant ssh Ubuntu 10.04.3 LTS Welcome to Ubuntu!

    vagrant@lucid32:~$ echo Hello Velocity! Hello Velocity! vagrant@lucid32:~$
  59. • Base box used as a skeleton, but private copy

    is created for each `up` • Therefore, files in your VM don’t affect past/future VMs. A Note on “up”
  60. • vagrant up • vagrant status • vagrant reload •

    vagrant suspend • vagrant halt • vagrant destroy VM Lifecycle
  61. • VirtualBox shared folders • NFS (Depends on host*) •

    Use your preferred editor on the host • No need to sync files manually! File Synchronization
  62. VirtualBox Shared Folders: 5m 14s Host File System: 10s Native

    VM File System: 13s NFS Shared Folders: 22s NFS Shared Folders (warm cache): 14s NFS
  63. NFS • Windows does not support NFS. • Most linux

    distros do, but obscure ones may not.
  64. • Scripted installation of packages • Scripted configuration management •

    Scripted starting of services Provisioning I’m probably preaching to the choir here
  65. • Shell • Puppet (via apply or server) • Chef

    (solo and server) • CFEngine coming soon! Provisioning
  66. • Setup development using same scripts as production. • Test

    scripts prior to putting into production • Without it, just moving the annoying setup of dev environment into a VM... Why Provision?
  67. • First class support in Vagrantfile • Run with `vagrant

    up`, `vagrant reload`, or `vagrant provision` Provisioning
  68. Chef Example 1 config.vm.provision :chef_solo do |c| 2 c.cookbooks_path =

    “cookbooks” 3 c.add_recipe “apache2” 4 end
  69. ~ ! vagrant reload [default] Attempting graceful shutdown of VM...

    ... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant [default] -- v-csc-1: /tmp/vagrant-chef-1/chef-solo-1/cookbooks [default] Running provisioner: Vagrant::Provisioners::ChefSolo... [default] Generating chef JSON and uploading... [default] Running chef-solo... stdin: is not a tty [Sun, 24 Jun 2012 21:33:14 -0700] INFO: *** Chef 0.10.2 *** [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Setting the run_list to ["recipe[apache2]"] from JSON [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List is [recipe[apache2]] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List expands to [apache2] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Starting Chef Run for lucid64 [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Processing execute[apt-get update] action run (apache2::default line 1) [Sun, 24 Jun 2012 21:33:15 -0700] INFO: execute[apt-get update] sh(apt-get update) [Sun, 24 Jun 2012 21:35:29 -0700] INFO: execute[apt-get update] ran successfully [Sun, 24 Jun 2012 21:35:29 -0700] INFO: Processing package[apache2] action install (apache2::default line 3) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: package[apache2] installed version 2.2.14-5ubuntu8.9 [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Processing service[apache2] action enable (apache2::default line 7) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Chef Run complete in 175.23797 seconds [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Running report handlers [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Report handlers complete
  70. We have a code for some service in the VM...

    how do we access it? The Problem
  71. ~ ! vagrant reload [default] Attempting graceful shutdown of VM...

    [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 1234 (adapter 1) [default] -- 80 => 8080 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
  72. ~ ! vagrant reload [default] Attempting graceful shutdown of VM...

    [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 1234 (adapter 1) [default] -- 80 => 8080 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
  73. Pros/Cons • Pro: Simple • Con: Port exposed globally •

    Con: Port-by-port • Con: Host port >= 1024 (*)
  74. ~ ! vagrant reload ... [default] Creating shared folders metadata...

    [default] Clearing any previously set network interfaces... [default] Preparing network interfaces based on configuration... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Configuring and enabling network interfaces... [default] Mounting shared folders... [default] -- v-root: /vagrant
  75. ~ ! vagrant reload ... [default] Creating shared folders metadata...

    [default] Clearing any previously set network interfaces... [default] Preparing network interfaces based on configuration... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Configuring and enabling network interfaces... [default] Mounting shared folders... [default] -- v-root: /vagrant
  76. Common Gotcha: If the static IP you assign collides with

    your internet subnet, it won’t work.
  77. Pros/Cons • Pro: Local-only, secure • Pro: VM can address

    the host • Pro: Multiple VMs can communicate • Con: Local-only
  78. Outside World Host Machine 10.0.1.14 Host Machine 10.0.1.23 Host Machine

    10.0.1.35 LAN - Router VM 10.0.1.10 VM 10.0.1.16
  79. ~ ! vagrant reload ... [default] Available bridged network interfaces:

    1) en0: Wi-Fi (AirPort) 2) p2p0 What interface should the network bridge to? 1 [default] Preparing network interfaces based on configuration... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Configuring and enabling network interfaces... [default] Mounting shared folders... [default] -- v-root: /vagrant
  80. ~ ! vagrant reload ... [default] Available bridged network interfaces:

    1) en0: Wi-Fi (AirPort) 2) p2p0 What interface should the network bridge to? 1 [default] Preparing network interfaces based on configuration... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Configuring and enabling network interfaces... [default] Mounting shared folders... [default] -- v-root: /vagrant
  81. vagrant@lucid32$ ifconfig eth1 Link encap:Ethernet HWaddr 08:00:27:ad:7f:2b inet addr:10.1.10.54 Bcast:10.1.10.255

    Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fead:7f2b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8914 (8.9 KB) TX bytes:1152 (1.1 KB)
  82. vagrant@lucid32$ ifconfig eth1 Link encap:Ethernet HWaddr 08:00:27:ad:7f:2b inet addr:10.1.10.54 Bcast:10.1.10.255

    Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fead:7f2b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8914 (8.9 KB) TX bytes:1152 (1.1 KB)
  83. Pros/Cons • Pro: Other machines on LAN can access the

    VM. • Con: Must select a network device • Con: Doesn’t always work depending on router config
  84. Multi-VM Config 1 config.vm.box = "lucid64" 2 3 config.vm.define :web

    do |web| 4 web.vm.network :hostonly, "10.1.40.5" 5 end 6 7 config.vm.define :db do |db| 8 db.vm.network :hostonly, "10.1.40.6" 9 end
  85. • vagrant up • vagrant status • vagrant reload •

    vagrant suspend • vagrant halt • vagrant destroy VM Lifecycle
  86. • vagrant up <target> • vagrant status <target> • vagrant

    reload <target> • vagrant suspend <target> • vagrant halt <target> • vagrant destroy <target> VM Lifecycle + Multi-VM
  87. ~ ! vagrant up web [web] Importing base box 'lucid64'...

    [web] Matching MAC address for NAT networking... [web] Clearing any previously set forwarded ports... [web] Forwarding ports... [web] -- 22 => 2222 (adapter 1) [web] Creating shared folders metadata... [web] Clearing any previously set network interfaces... [web] Preparing network interfaces based on configuration... [web] Booting VM... [web] Waiting for VM to boot. This can take a few minutes. [web] VM booted and ready for use! [web] Configuring and enabling network interfaces... [web] Mounting shared folders... [web] -- v-root: /vagrant
  88. • Web, DB, queue, etc. on separate machines. • Allow

    developers to work on single service in SOA • Distributed system testing (fault tolerance, network partition, etc.) Use Cases
  89. ~ ! vagrant package [default] Attempting graceful shutdown of VM...

    [default] Clearing any previously set forwarded ports... [default] Creating temporary directory for export... [default] Exporting VM... [default] Compressing package to: /Users/mitchellh/Dropbox/ Documents/presentations/2012_velocity/package.box
  90. ~ ! vagrant box add my_site package.box [vagrant] Downloading with

    Vagrant::Downloaders::File... [vagrant] Copying box to temporary location... [vagrant] Extracting box... [vagrant] Verifying box... [vagrant] Cleaning up downloaded box...
  91. ~ ! vagrant up [default] Importing base box 'my_site'... [default]

    Matching MAC address for NAT networking... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
  92. 1. Manually work in Vagrant 2. Automate a piece 3.

    Test in Vagrant, repeat. 4. Push to stage, then prod
  93. ~ ! vagrant up [default] Importing base box 'lucid32'... [default]

    Matching MAC address for NAT networking... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set network interfaces... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant
  94. ~ ! vagrant ssh Ubuntu 10.04.3 LTS Welcome to Ubuntu!

    vagrant@lucid32:~$ sudo apt-get install apache2 ... vagrant@lucid32:~$ vi /etc/apache2/apache2.conf ...
  95. 1 package "apache2" do 2 action :install 3 end 4

    5 service "apache2" do 6 action :enable 7 end 8 9 template "apache2.conf" do 10 path "#{node[:apache][:dir]}/” + “apache2.conf" 11 mode 0644 12 notifies :restart, resources(:service => "apache2") 13 end
  96. ~ ! vagrant reload [default] Attempting graceful shutdown of VM...

    ... [default] Waiting for VM to boot. This can take a few minutes. [default] VM booted and ready for use! [default] Mounting shared folders... [default] -- v-root: /vagrant [default] -- v-csc-1: /tmp/vagrant-chef-1/chef-solo-1/cookbooks [default] Running provisioner: Vagrant::Provisioners::ChefSolo... [default] Generating chef JSON and uploading... [default] Running chef-solo... stdin: is not a tty [Sun, 24 Jun 2012 21:33:14 -0700] INFO: *** Chef 0.10.2 *** [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Setting the run_list to ["recipe[apache2]"] from JSON [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List is [recipe[apache2]] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Run List expands to [apache2] [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Starting Chef Run for lucid64 [Sun, 24 Jun 2012 21:33:15 -0700] INFO: Processing execute[apt-get update] action run (apache2::default line 1) [Sun, 24 Jun 2012 21:33:15 -0700] INFO: execute[apt-get update] sh(apt-get update) [Sun, 24 Jun 2012 21:35:29 -0700] INFO: execute[apt-get update] ran successfully [Sun, 24 Jun 2012 21:35:29 -0700] INFO: Processing package[apache2] action install (apache2::default line 3) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: package[apache2] installed version 2.2.14-5ubuntu8.9 [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Processing service[apache2] action enable (apache2::default line 7) [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Chef Run complete in 175.23797 seconds [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Running report handlers [Sun, 24 Jun 2012 21:36:10 -0700] INFO: Report handlers complete
  97. Uses (Ops) • Developing Chef/Puppet/etc. scripts • Testing Chef/Puppet/etc. scripts

    • Using production-quality ops scripts to setup dev environments. • QA