Vagrant for Effective DevOps Culture
3 likes1,598 views
This document discusses how Vagrant was implemented at Wingify Engineering to help establish a DevOps culture. Previously, Wingify had issues with environments not matching production, difficult setups, and isolation between devs and ops. Vagrant provided developers similar environments to production using the same OS and configuration management. It simplified management through tools like "vagrant up", "vagrant ssh", and "vagrant destroy". This improved testing and reduced issues in production. It also improved collaboration by allowing ops to test configurations and devs to better understand infrastructure. Overall Vagrant helped establish closer alignment between devs and ops through shared responsibility of infrastructure.
![Azure DevOps Overview [Arabic]](https://cdn.slidesharecdn.com/ss_thumbnails/azuredevopsoverview-arabic-200209072147-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Similar to Vagrant for Effective DevOps Culture (20)
Ad
Recently uploaded (20)
Ad
Vagrant for Effective DevOps Culture
- 1. Vagrant for Effective DevOps Culture Vaidik Kapoor @vaidikkapoor
- 2. Me? • I work at Wingify • Software Engineer for first few months • Infrastructure and Operations after that • github.com/vaidik • twitter.com/vaidikkapoor
- 3. Wingify Engineering Back when I joined: • ~12 people • Two teams: backend and frontend • Multiple services, but only a few with active development • Random bash scripts everywhere to setup things
- 4. Wingify Engineering Today: • ~25 people • Multiple teams: backend, frontend, JS library, mobile, operations • Lots of overlap between teams • Multiple services ~ very SOAish
- 5. Problems • Things work fine locally but not when deployed • Things work fine in testing / staging environment but not in production • All the services are not available locally while development is on going • Too many services • Too difficult to setup because everyone has a different dev environment • Testing end-to-end was not possible for developers • Releases take a lot of time
- 7. Similar Environments • Closer to production • Staging should be as similar as possible • Use similar procedures for setting up every environment
- 8. Configuration Management • Formalize your infrastructure • Use same modules / recipes / playbooks / whatever everywhere • Many out there: • Puppet! • Chef • CFEngine • Ansible • Salt Stack
- 9. Problems Solved • Issues that were caught in production started getting caught early on • End-to-end testing was made possible • More confident releases • Faster releases
- 10. New Problems?
- 11. New Problems • Only Ops people writing / maintaining Puppet code base i.e. only two guys • Dependency and bottleneck • Ops and devs working in isolation - details shared at a very high level • Slow feedback, slow releases and slow resolutions • Not scalable
- 12. Changes Were Required Devs Ops OpsDevs Shared Responsibility Isolation
- 13. How to get there?
- 14. For Developers • Give developers environments for development which closely resemble production infrastructure. • Same OS as used in production • Possible to re-use configuration management for dev environments
- 15. Virtual Machines • As dev environments • Distributable • Re-usable • Cheap • Develop -> Test -> Deploy -> Destroy… Repeat! • We did this for a while!
- 16. Drawbacks with VMs • Lack of flexibility to choose your own tools, IDEs, etc. • Was still too much manual work for setting these up - lack of tooling • Intimidating at first
- 17. vagrant
- 18. vagrant • A super cool wrapper around: • Virtual Machine providers (VirtualBox, VMWare, etc.) • Docker • Support for provisioning using configuration management tools • Bunch of awesome tooling to make life easy • synced folders
- 19. vagrant up to start a VM and provision it if not already done
- 20. vagrant ssh to ssh into the VM
- 21. vagrant provision to run your configuration management scripts again
- 22. vagrant destroy to throw away your VM
- 23. vagrant package to package an existing VM and distribute
- 24. For Developers • Give developers environments for development which closely resemble production infrastructure. • Same OS as used in production • Possible to re-use configuration management for dev environments • synced folders make it possible for you to use the tools you love • Vagrant’s tooling makes management of dev environment really simple
- 25. For Ops?
- 26. For Ops • Use vagrant for testing out configuration management setup • From small modules to complete scripts • Faster feedback loop between developers and operations
- 27. Devs and Ops Together • Ops get control of tooling for infrastructure and managing configuration • Ops’ work gets tested out first in dev environments • Developers get a closer and more up-to-date replica of production systems • End-to-end testing is possible because all or most important services are setup using configuration management
- 28. Devs and Ops Together • Tighter feedback loop between devs and ops • Reasons of failures can be pin pointed faster • Resolutions can be made faster • Helps with better testing of applications - what works locally has higher chances of working everywhere • Helps with better testing of configuration management - strives for a more modular formalization of infrastructure
- 29. More Stability
- 30. New Possibilities? • For developers to actually know how things work in production • Slowly have developers own parts of configuration management • Start giving developers a share of responsibility to handle infrastructure
- 32. Vagrant Multi-Machine • Capable of setting up multiple machines in a cluster and controlling them. ! $ vagrant up webserver $ vagrant ssh dbserver !
- 33. Vagrant Multi-Machine • Have all your services running across multiple VMs • Example: web application and memcached on one VM, postgres and redis on another, elasticsearch on another. • Test REAL ISSUES with infrastructure on your machine • Simulate network issues in distributed systems • Jepsen? • Your playground!
- 34. Vagrantfile Ruby DSL - very flexible and programmable
- 35. It’s a long journey • Get Vagrant in place to give common playgrounds to both developers and operations • Have infrastructure formalized in some way - choose configuration management of your choice and have everyone use it • Take small steps • Do it for small projects and show success stories • Replicate across projects • Improve along the way • Try to get developers also contribute