Quality software engineering for your data centre - RubyConf Brasil 2014

DevOps is the melding of minds between the development/engineering and operations communities to form a super-discipline with the best of the experience of both sides as a force for stability, flexibility, efficiency and agility in the management of large-scale application or service deployments. DevOps is about automating out day-to-day monotony, and then going further to bridge many of the things operations people are used to doing manually with the best-practices developed on the other side of the fence, particularly around automated testing and agility.

Go! But wait a minute! That's not enough for everyone to know what they should be doing, you say. You're right, it's not. There is a wealth of information on specific DevOps issues on the internet, and some good introductory material, but few comprehensive, opinionated overviews of what you *should* do. This talk will solve that problem and have you 100% ready to embark on or fix-up your DevOps journey to blissful nights sleep while rocking regular new features for your users.

We'll talk Puppet & Chef, testing and turbulence, robots and thermo-nuclear weapons. If you've just started with DevOps and need to know what you need to know, or have been muddling for a little while with some Puppets but the show always turns into a fight, then this is for you!

Transcript

1. QUALITY SOFTWARE ENGINEERING FOR YOUR DATA CENTRE @BENLANGFELD LANGFELD.ME
2. OPERATIONS OR COMPUTER SYSTEMS ENGINEERING
3. Who cares?
4. Who cares? A B Mostly distributed systems
5. Who cares? A B Mostly distributed systems Only systems which matter A B
6. Who cares? A B Mostly distributed systems Only systems which matter A
7. YOU QUALIFIED!
8. Why operations at RubyConf?
9. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here.
10. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here. Rubyists like shiny things.
11. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here. Rubyists like shiny things. Rubyists typically are looking for simple yet powerful.
12. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here. Rubyists like shiny things. Rubyists typically are looking for simple yet powerful. Rubyists understand testing.
13. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here. Rubyists like shiny things. Rubyists typically are looking for simple yet powerful. Rubyists understand testing. Rails people understand convention over configuration.
14. Why operations at RubyConf? It's not just operations. We're talking about modern computer systems architecture here. Rubyists like shiny things. Rubyists typically are looking for simple yet powerful. Rubyists understand testing. Rails people understand convention over configuration. You guys are developers!
15. But Ops is a dirty word
16. But Ops is a dirty word Ops guys work in the middle of the night
17. But Ops is a dirty word Ops guys work in the middle of the night Ops is about putting out fires and helping users who forgot their passwords
18. But Ops is a dirty word Ops guys work in the middle of the night Ops is about putting out fires and helping users who forgot their passwords I only care about beautiful code!
19. Devs doing ops = DevOps
20. Devs doing ops = DevOps Trolololol
21. Devs doing ops = DevOps Trolololol Ops doing dev?
22. Devs doing ops = DevOps Trolololol Ops doing dev? Automation?
23. Devs doing ops = DevOps Trolololol Ops doing dev? Automation? Everyone does everything?
24. DevOps is simple
25. DevOps is simple Not a title
26. DevOps is simple Not a title Not a department
27. DevOps is simple Not a title Not a department Ruby developers didn't invent it
28. DevOps is simple Not a title Not a department Ruby developers didn't invent it Simply refers to the idea of cooperation vs segmentation
29. Why "do DevOps"?
30. Why "do DevOps"? The alternative is segment people on a project, set them off in different directions with different goals and hope for the best.
31. Why "do DevOps"? The alternative is segment people on a project, set them off in different directions with different goals and hope for the best.
32. Why "do DevOps"? The alternative is segment people on a project, set them off in different directions with different goals and hope for the best. Loucura!
33. Ops is a turtle too Everything is a product for someone
34. $$$ Ops can be a commercial advantage
35. $$$ Understanding ops makes you a better engineer
36. Basic ops
37. Basic ops Server Packages Software Users Commands Processes Files Disks Processors Memory NIC
38. Basic ops Server
39. Basic ops Server Server Server Server
40. Basic ops Server Switches Load balancers Routers Server Server Server
41. Changes
42. Changes PQP!@&*
43. Let’s automate this!
44. Let’s automate this! CFEngine (1993)
45. Let’s automate this! CFEngine (1993) Puppet (2005)
46. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009)
47. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011)
48. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012)
49. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010)
50. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management
51. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software
52. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config
53. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config Ensure services are running
54. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config Ensure services are running Managing users
55. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config Ensure services are running Managing users Introspect cluster layout
56. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config Ensure services are running Managing users Introspect cluster layout Prevent configuration drift
57. Let’s automate this! CFEngine (1993) Puppet (2005) Chef (2009) Salt (2011) Ansible (2012) BOSH (2010) Configuration Management Install software Set config Ensure services are running Managing users Introspect cluster layout Prevent configuration drift Monitor changes
58. Installing Software package 'apache' do action :install end
59. Setting config file '/etc/apache2/apache2.conf' do content 'some_apache_config' owner 'www-data' group 'www-data' mode 550 end ifconfig '192.168.0.1' do device 'eth0' end
60. Managing services service 'httpd' do action :start end
61. Managing users user 'random' do uid 1234 gid 'users' password '$1$JJsvHslV$szsCjVEroftprNn4JHtDi.' end
62. Introspection webservers = search(:node, 'role:webserver') ! template '/tmp/list_of_webservers' do source 'list_of_webservers.erb' variables webservers: webservers end
63. file '/etc/apache2/apache2.conf' do content 'some_apache_config' owner 'www-data' group 'www-data' mode 557 end Configuration Drift
64. file '/etc/apache2/apache2.conf' do content 'some_apache_config' owner 'www-data' group 'www-data' mode 550 end Configuration Drift
65. Monitor Changes
66. Monitor Changes
67. Monitor Changes
68. Monitor Changes
69. Infrastructure as Code require 'spec_helper' ! describe package('apache2') do it { should be_installed } end ! describe service('apache2') do it { should be_enabled } it { should be_running } end ! describe port(80) do it { should be_listening } end ---! driver_plugin: vagrant! driver_config:! require_chef_omnibus: true! ! platforms:! - name: ubuntu-14.04! ! suites:! - name: default! run_list:! - recipe[apache]
70. Building Clusters
71. Building Clusters Facility
72. Building Clusters Facility Network
73. Building Clusters Facility Compute & Storage Network
74. Building Clusters Facility Compute & Storage Network Hypervisor
75. Building Clusters Facility Compute & Storage Network Hypervisor VM
76. Building Clusters Facility Compute & Storage Network Hypervisor VM OS
77. Building Clusters Facility Compute & Storage Network Hypervisor VM OS Solutions / Services
78. Building Clusters Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App
79. Building Clusters Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API
80. Building Clusters AWS OpenStack CloudStack VMWare vSphere Eucalyptus etc… Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API
81. Building Clusters AWS OpenStack CloudStack VMWare vSphere Eucalyptus etc… Chef Metal The Foreman libvirt Fog (Ruby) Libcloud (Python) etc… Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API
82. Building Clusters machine 'mario' do recipe 'apache' tag 'mydb_master' end
83. Now we’re (auto-)scaling
84. Now we’re (auto-)scaling Config management / orchestration can dynamically reconfigure load balancers etc
85. Now we’re (auto-)scaling Config management / orchestration can dynamically reconfigure load balancers etc Layers on top of this to determine required instance count are now (relatively) easy to build
86. Now we’re (auto-)scaling Config management / orchestration can dynamically reconfigure load balancers etc Layers on top of this to determine required instance count are now (relatively) easy to build Combined with performance monitoring can put the auto in auto-scaling
87. Fault-tolerance
88. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements
89. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements Care in locating state
90. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements Care in locating state Multiple homogenous instances
91. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements Care in locating state Multiple homogenous instances Tiered architecture
92. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements Care in locating state Multiple homogenous instances Tiered architecture Get the app right and deploy the right number of instances and you’re 90% of the way to a fault tolerant architecture
93. Fault-tolerance Horizontal scaling and fault tolerance have many of the same requirements Care in locating state Multiple homogenous instances Tiered architecture Get the app right and deploy the right number of instances and you’re 90% of the way to a fault tolerant architecture Now blow it up on purpose!
94. Test everything
95. Test everything Testing should not be constrained to development pipeline
96. Test everything Testing should not be constrained to development pipeline Test production
97. Test everything Testing should not be constrained to development pipeline Test production Test the good and the bad. Go on, try and hurt it!
98. Core ideas
99. Core ideas Focus on servers (Bare-metal or Virtual)
100. Core ideas Focus on servers (Bare-metal or Virtual) Mutability
101. Core ideas Focus on servers (Bare-metal or Virtual) Mutability Idempotence
102. Core ideas Focus on servers (Bare-metal or Virtual) Mutability Idempotence Heterogeneity
103. Core ideas Mutability Idempotence Heterogeneity Focus on services
104. Core ideas Idempotence Heterogeneity Focus on services Immutability
105. Images Core ideas Heterogeneity Focus on services Immutability
106. Images Core ideas Focus on services Immutability Homogeneity
107. Focus on services Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API
108. Focus on services Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API Servers become a cluster of (potentially unidentifiable) task runners
109. Focus on services Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API Servers become a cluster of (potentially unidentifiable) task runners Abstract further the interface to the execution environment
110. Focus on services Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API Servers become a cluster of (potentially unidentifiable) task runners This is akin to Grid Computing or Utility Computing Abstract further the interface to the execution environment
111. Focus on services Facility Compute & Storage Network Hypervisor VM OS Solutions / Services App GUI / API Servers become a cluster of (potentially unidentifiable) task runners This is akin to Grid Computing or Utility Computing Abstract further the interface to the execution environment In the web world we call this PaaS
112. Immutability Once a deployment is made it cannot be altered
113. Immutability Once a deployment is made it cannot be altered No editing of config files
114. Immutability Once a deployment is made it cannot be altered No editing of config files No installation of extra software
115. Immutability Once a deployment is made it cannot be altered No editing of config files No installation of extra software No adding or removing system users
116. Images
117. Images Deployments are based on images
118. Images Deployments are based on images Images are built deterministicly
119. Images Deployments are based on images Images are built deterministicly Images are read only
120. Homogeneity
121. Homogeneity All apps follow a set of strict rules or standards
122. Homogeneity All apps follow a set of strict rules or standards Every app is executed in the same way
123. Homogeneity All apps follow a set of strict rules or standards Every app is executed in the same way Every app behaves similarly
124. VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes Twelve-Factor Apps I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing Services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes
125. How does a PaaS work?
126. How does a PaaS work? Addressable
127. How does a PaaS work? Addressable Volatile
128. How does a PaaS work? Addressable Volatile Stateful
129. How does a PaaS work? Addressable Volatile Stateful App source code
130. How does a PaaS work? Addressable Volatile Stateful App source code Build scripts
131. How does a PaaS work? Addressable Volatile Stateful App source code Build scripts
132. How does a PaaS work? Addressable Volatile Stateful Build App source code Build scripts
133. How does a PaaS work? Addressable Volatile Stateful Build App source code Build scripts
134. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Build scripts
135. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Build scripts
136. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts
137. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution request
138. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution request
139. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution container Execution request
140. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution container Execution request Platform addressable layer
141. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution container Execution request Platform addressable layer
142. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution container Execution request Platform addressable layer
143. How does a PaaS work? Addressable Volatile Stateful Build App source code App image Store Build scripts Execution container Execution request Platform stateful layer Platform addressable layer
144. What parts do I need for a PaaS? Scheduler Image store Image builder Execution agents Stateful services Addressable services Health monitor Log aggregator Config store API Server
145. I want to build a PaaS!
146. I want to build a PaaS! Don't!
147. I want to build a PaaS! Don't! CoreOS
148. I want to build a PaaS! Don't! CoreOS Docker
149. I want to build a PaaS! Don't! CoreOS Docker etcd
150. I want to build a PaaS! Don't! CoreOS Docker etcd Heroku buildpacks
151. I want to build a PaaS! Don't! CoreOS Docker etcd Heroku buildpacks Heroku logplex
152. I want to build a PaaS! Don't! CoreOS Docker etcd Heroku buildpacks Heroku logplex Custom scheduler, API server, health monitor and services implementations
153. I want to deploy a PaaS!
154. I want to deploy a PaaS! CloudFoundry
155. I want to deploy a PaaS! CloudFoundry OpenShift
156. I want to deploy a PaaS! CloudFoundry OpenShift Dokku
157. I want to deploy a PaaS! CloudFoundry OpenShift Dokku Deis
158. I want to deploy a PaaS! CloudFoundry OpenShift Dokku Deis Flynn
159. I want to deploy a PaaS! CloudFoundry OpenShift Dokku Deis Flynn Octohost
160. Key ideas
161. Key ideas Learn from experienced sysadmins and standards
162. Key ideas Learn from experienced sysadmins and standards Create abstractions
163. Key ideas Learn from experienced sysadmins and standards Create abstractions Use automation
164. Key ideas Learn from experienced sysadmins and standards Create abstractions Use automation Test everything
165. Key ideas Learn from experienced sysadmins and standards Create abstractions Use automation Test everything Move fast
166. Key ideas Learn from experienced sysadmins and standards Create abstractions Use automation Test everything Move fast Prioritise organisational refinement over tool adoption
167. What should I do? I promised to tell you what you should do. This presentation is the start of the message, not the end.
169. Utopian Computing is a project with the aim of clearly defining what an ideal computer system would look like.
170. Utopian Computing is a project with the aim of clearly defining what an ideal computer system would look like. This vision intends to take into account the present-day reality, but to guide from it rather than be constrained by it.
171. HTTP://UTOPIANCOMPUTING.VISION
172. HTTP://UTOPIANCOMPUTING.VISION DÚVIDAS? @BENLANGFELD LANGFELD.ME