Repeatable and Sharable Development Environments with Vagrant

Why are repeatable and sharable development environments worthwhile? An introduction to Vagrant and virtual machines in the context of setting up a development environment, followed by a walk-through of the steps to follow to get started.

Transcript

1. Repeatable and shareable development environments With Vagrant Andrew Donaldson / Harmonypark.net @adonaldson HELLO AGAIN. BORING INTRO ! I realise that I say ‘development environment’ and what I mean is ‘web development environment’. It may work for other purposes, but that is the angle i’m coming from.
2. Historically Historically, your development environment was more or less the same thing as your machine.
3. The fresh install • Yum, new car smell! • Install the software dependencies • Create a folder, commence coding Brand new machine Go into a frenzy `apt-get`ting and `brew installing` Make your folder and boom, we’re off!
4. Congratulations Your computer is now a skip It might not look like it now, but you are going down a dirty path.
5. Hey buddy, where do you get off calling my computer a skip • Multiple dependencies, installed ad-hoc. • No idea what project is using what dependency • Every project will have access to dependencies it doesn’t strictly depend on Every dependency you install is accidentally available to every other project. Install a new version? Uh oh, the old project may not like it.
6. Future difficulties • Reinstall machine from scratch • Deploying to another machine • Setting up the project again after you deleted it because you said that the client was idle and they totally wouldn’t be getting in touch this year • Your team has a new member It boils down to being a faff to set up your machine in future. Or your server. Or your new colleagues machine. ! As an aside, if you don’t specify in your project what dependencies your project depends on (even so far as major/minor versions), you are making it hard for future you and future you HATES that.
7. Future you politely requests that you try harder This is future you btw.
8. It’s not all bad • Upgrading an early Rails 2.X application (pre- bundler, pre-declaring dependencies) was horrible • Upgrading a Rails app that uses rbenv/rvm and Bundler is less horrible It’s not all bad. I mainly know Rails. ! Upgrading a Rails 2.x app, pre bundler was horrible. Describe eCops. ! Bundler makes things easier. rbenv/rvm make things easier.
9. –Andrew Donaldson “Declaring dependencies and storing that information within your project is the sort of act bards will sing of in centuries to come” Read quote It’s a form of documentation. It defines how your project is set up. This alone will help others get started with your project.
10. Level up • Using virtual machines allows you to set up development environment’s for each of your projects • No dependency overlap Level up by using virtual machines. ! Each project gets it’s own machine ! No dependency overlap
11. –Andrew Donaldson “But, *resigned shrug gesture*.” Huff. ! Virtual machines are slow! I use virtualbox to look at IE on my mac and it takes ages to start. ! YES, this is true. But.
12. Vagrant • Define a manifest that builds your virtual machine for you • Based off publicly shared ‘base machines’ so you don’t have to do too much work • From there, set up dependencies Vagrant let’s you programmatically create [headless] virtual machines.
13. Vagrant • Edit files from “your machine” using your normal editors • Access your web server like it’s running on your machine Vagrant let’s you work like you did before, more or less.
14. Vagrant demo - tmux, start webserver - create a project folder, init vagrant - review vagrantfile: box - start the VM - SSH onto VM - mess about - show that editing files locally changes server files - stop the VM ! - start the VM - provisioning: bootstrap_lite - show networking / apache - show more complicated bootstrapping script - mention chef/puppet, point at schwuk
15. Post demo • It’s more hassle up front (when you are familiar with the project) • It’s less hassle later (when you have forgotten everything) It’s harder at first, but future you will not harp on about this all the time.
16. Post demo • To share your setup, simply commit the Vagrantfile to source control • Bonus points: Set up your virtual machine specs to mimic your production server (e.g. Heroku) • This is documentation and process FOR FREE* To share with your team, simply give them the Vagrantfile (or better yet, commit to source control) ! It’s great to see production problems before they hit production.
17. Vagrant tips • Small HD? Store images on external HD • Slow connection? Images / dependencies can be big, so why not experiment on a VPS?
 
 Referral link klaxon: 
 https://www.digitalocean.com/? refcode=d6ac7849d0c1 Small SSD? Run virtualbox from external HD ! Slow connection? Make use of the fat-pipe of your VPS
18. Thanks! Any questions? Andrew Donaldson / Harmonypark.net @adonaldson links on next page
19. Links / Notes • Vagrant - http://www.vagrantup.com/ • Vagrantfile from this demo: Ask me • Chef / Puppet: Speak to @schwuk