The document discusses the use of Vagrant and Ansible for DevOps practices, emphasizing the benefits of treating code as infrastructure to improve team efficiency and minimize deployment errors. It outlines a certification program for application code compilation, testing, and version control. Additionally, it compares various tools for provisioning, deployment, and system configuration while offering guidelines on best practices and the advantages of Ansible over other tools like Puppet and Chef.

1. DevOps
Vagrant & Ansible

2. Why ?

3. Code As Infrastructure

4. Because luck has no place

5. WHY ?

6. Installing development environment –
no worries

7. Prevent your computer from being
ruined

8. Team efficiency

9. Remove the pain of software
deployment

10. Prevents inadvertent errors

11. Avoids annoying tasks

12. It works on my machine !

13. Certification program
• Compile your application code. Getting the latest version of
any recent code changes from other developers is purely
optional and not a requirement for certification.
• Launch the application or website that has just been
compiled.
• Cause one code path in the code you're checking in to be
executed. The preferred way to do this is with ad-hoc
manual testing of the simplest possible case for the feature
in question. Omit this step if the code change was less than
five lines, or if, in the developer's professional opinion, the
code change could not possibly result in an error.
• Check the code changes into your version control system.
http://blog.codinghorror.com/the-works-on-my-machine-certification-program/

14. HOW ?

15. Know State & Consistency
State A
Provisioning
State B

16. Idempotence & Repeatability
State B
Provisioning
State B

17. Now you should say

18. Meet the tools
a very opinionated presentation

19. The VM manager
Vagrant

20. The provisioning tool
• It configures the machine (installs stuff, push
config files, etc.)
– Puppet
– Chef
– Ansible
– Salt
– … ?

21. The deployment tool
• It pushes the project on the server (&
configures it, runs migration, clears caches, …)
– Capistrano (and it can deploy non ruby
applications)
– Two ways informations transferts (DB sync, logs…)

22. Summary
VMmanagement
Vagrant
Systemconfiguration
Ansible
Applicationdeployment
Capistrano

23. Where is Docker ?

24. Well…Pre-provisionedVM
Docker
Applicationdeployment
Capistrano

25. Why we don’t use docker ?

26. • Because you need a specific cloud provider…
And we deploy our apps in the customer
datacenter on various systems.
• But maybe, one day…

27. So why Ansible and not
puppet/chef/… ?

28. • Simple (its just Yaml)
• Agent less
• Runs on every dev machine (python +
openssh, yeah that means you don’t need
ruby)
• Push based
• Made in Durham

29. How it works ?

30. Vagrant
• A Vagrant File contains :
– Provider
– Sharing folder instruction
– Networking configuration (port forwarding)
– (optionnal) Provisionner

32. Ansible
• Hosts
• Variables
• Roles

33. Playbook.yml

34. Rôles

35. Rôles (again)

36. Tasks

37. Templates

38. Handlers

39. Files
• It’s just for copy/paste !

42. Vagrant + ansible skeleton
• https://github.com/Ibsciss/vagrant-ansible-php

43. Where do I put all of this stuff ?
in its own branch

44. Does & Don’ts
It’s also opinionated

46. • Don’t: Make snowflake VM : you become
dependant of the VM management tool
• Do: Separate provisioning
• Don’t: Use Vagrant default SSH key in
production !
• Don’t: Separate dev & ops
• Don’t: Try to eliminate admin sys (you need
hero)
• Do: Use same environment for Dev/test/prod

47. Let’s deploy !

48. Questions ?

49. Thank you !