Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps introduction with ansible, vagrant, and docker


Published on

slide show on devops with ansible, vagrant, and docker

Published in: Software

DevOps introduction with ansible, vagrant, and docker

  1. 1. DevOps: What is it and why is it important? Mark Stillwell September 28, 2014
  2. 2. Traditional Development/Deployment best practices I source code only in vcs I static release as versioned archive I unit testing of code in development environment I
  3. 3. nal product not installed on developer machine I deployment instructions via howto or interactive application I time consuming I dicult to replicate
  4. 4. Similar Work ows I Collaborating on a paper by emailing Word .doc
  5. 5. les I Developing software without vcs, periodically creating versioned/dated zip
  6. 6. le in a backup/ directory
  7. 7. Issues With These Approaches I Coordination, Communication, Documentation: I I'll edit the document and email you when I'm done. I I had to tinker with /etc/foo to get things working. I Handling of con icts I No automating of merges I Lack of one true authoritative latest version. I Culture of Fear I I know generally what needs to be done, but I'm afraid to try because I might break it and not be able to get things working again.
  8. 8. Software Speci
  9. 9. c Issues I Diculty verifying complicated interaction between multiple parts. I Brittle deployment: It works, mostly, but don't touch it! I Experts-Only install discourages end-users, results in lower adoption/mindshare.
  10. 10. DevOps I deployment as code in vcs I continuously tested I test environment similar to deployment environment I enabled by virtual machines and containers I regular deployments to production I industry standard practice! I NetFlix, Etsy, Twitter, etc tear down infrastructure and redeploy multiple times per day. . . I culture of fearless development
  11. 11. Enabling Technologies I ansible I vagrant I docker
  12. 12. Ansible I tool for managing distributed software deployments I similar tools: puppet, chef, salt, cfengine I free software (for command line, commercial web-based management interface) I written in python I con
  13. 13. guration as list of idempotent tasks in yaml based con
  14. 14. guration I really only pseudo-idempotent I push model that only requires administrator's computer have ansible software and client machines have sshd and python I all other require some kind of bootstrapping process on clients I some (e.g., puppet) require server setup
  15. 15. Example Playbook - hosts: all sudo: True tasks: - name: ensure sysctl is configured sysctl: name: vm.swappiness value: 10 state: present - name: ensure latest version is installed apt: pkg: etckeeper state: latest
  16. 16. Vagrant I command line wrapper to virtualisation tools like virtualbox/kvm I sets up disks / networking etc. I all con
  17. 17. guration in text Vagrant
  18. 18. le I can bring up and network multiple vms with dierent operating systems I can invoke provisioning tools like ansible, or shell scripts I user just needs to cd to right directory, type vagrant up
  19. 19. Example Vagrant
  20. 20. le Vagrant.configure(2) do |config| = ubuntu/trusty forwarded_port, guest: 80, host: 80 config.vm.provider virtualbox do |v| v.memory = 1280 end config.vm.provision ansible do |ansible| ansible.playbook = site.yml end end
  21. 21. Docker I interface for managing container based deployments I light-weight environment virtualisation that makes use of linux-kernel features I like chroot on steroids I currently uses lxc, but this may change in the future I also manages layered
  22. 22. le sytems using aufs copy-on-write I disk-space ecient I has a repository of of layers, e.g. docker pull ubuntu I can be used to provide lightweight linux virtual machines, but this isn't the most ecient approach I no need to run multiple copies of system services I preference is one process per container, single responsibility principle I inter-process communication enabled by mapping directories / ports between containers and/or host
  23. 23. Websites I I I