Distributing uniform development environments with Vagrant

By virtualising your whole dev environment, you can make it similar to production, avoiding issues that have to do with versions and compatibility.

Oh and also, Vagrant rules.

Transcript

1. knowledge sharing talks
2. Distributing Uniform Development Environments with Vagrant
3. @yamilurbina DevOps at CodeRoad
4. The Problem(s)
5. First day at new team A new and wild developer appears! First task: install the app locally “Use the documentation they said, it will be easy, they said” What about this new technology I know nothing about?
6. Learning the insides of a new app can be a pain in the @$$. Problem #1
7. “Yeah, just play with it, but don’t modify anything just yet”
8. A new developer is allowed to see, but nothing more. Problem #2
9. Finally, the app is installed! but… • New dev: “hey, feature X is not working on my machine” • Older dev: “Oh, that version is not compatible with the app. Install v1.4.5” • Elder dev: “Also, your configuration file is outdated, we changed X setting months ago”
10. Configuration and versions become problematic. Problem #3
11. How do we solve this?
12. “well, developers should work on the same OS and with the same tools” an failed solution
13. The right tools for the developer varies from person to person (and even OS) Truth #1
14. “ok then, let’s virtualise every development environment” getting closer
15. The virtualisation ecosystem is diverse • Several solutions, different ways of managing settings, drives and memory • And that leads to even more differences between dev environments • They should be identical
16. “so we need a uniform virtualisation environment, that uses the same configuration to run an app”
17. WHAT IF I TELL YOU… YOU CAN RUN YOU APP IN A PROPERLY CONFIGURED DEV ENVIRONMENT?
18. The Solution
20. Windows, Linux and OS X Vagrant acts as an intermediary between your virtualisation software and you Use you command line to start, stop and reboot your virtual machine Don’t worry about settings, Vagrant configures them for you
21. Packaged .box files Are virtual machines already configured for your app They have the same software as production Same configuration and settings Redistributable; edit it and package it again Lighter than other VMs (less than 4GB) 21
22. Use the same OS as production Using Ubuntu Server on production? Vagrant has the same machine version for you Install your app, dependencies and modify the proper settings there Package your own Vagrant machine and distribute it over HTTP
23. A Vagrantfile to rule them all A single configuration file manages memory, folders and ports Include it on your source tree to distribute it No need to open GUIs
24. Vagrant machines are indestructible Vagrant boots a VM copy that can be destroyed and rebuilt in a matter of minutes Perfect for noobies and new developers Also for experimenting, editing and pretty much doing whatever you want with it
25. What about my files? Sync folders from host to vm Use rsync to detect changes Or use scp on Windows Exclude files and folders (kind of like git)
26. Tell me more Imports a packaged .box file from the interwebz Vagrant creates a copy of the .box file Opens configured ports and local connections Starts the virtual machine That’s it
27. Open ports and connections • Using HTTP? no problem, map port 80 from vm to the local machine • And access it via localhost • It uses your machine’s local internet connection
28. Can I share my work? • Use your internal IP if you want to show it locally • Or, use vagrant share to create a public server • Anyone gets to see what you are working on
29. Some downsides • While RAM consumption is low, it can affect performance on not so new machines • Updating .box files is a manual task • If mismanaged, the .box size can become pretty large (>20GB)
30. Demo time you’ll see what I’m talking about
31. Instead of a non- productive new developer, we can get this:
32. First day at new team A new and wild developer appears! First task: boot Vagrant and experiment with the app New dev: “Oh, so that’s how it works!” Happiness :)
33. First week at new team New developer is now familiar with the app They can start making small changes with confidence Or big experiments without fear
34. And the new developer starts being productive sooner than expected
35. Questions?
37. @yamilurbina DevOps at CodeRoad
38. knowledge sharing talks