Kris Buytaert discussed the evolution of infrastructure deployment and configuration management over the past 20 years. Early methods involved manual installations and copying config files (1996) while later approaches included tools like Mondo Rescue for single instances (2001), SystemImager for reproducible infrastructures (2003), and Kickstart/FAI for OS installation (2005). The talk advocates treating infrastructure as code using tools like Puppet, Chef, and CFEngine, with best practices like versioning, testing, and separate environments. It acknowledges early challenges in getting operators to adopt new methods but argues they are now essential for managing modern, distributed systems.
2. Kris Buytaert
●In the 90'ies I used to be a Dev ,
●Then Became an Op
●Chief Trolling Officer and Open Source Consultant @inuits.eu
●Everything is an effing DNS Problem
●Building Clouds since before the bookstore
●Some books, some papers, some blogs
●Evangelizing devops
4. This talk
Part 3 of what should have been a 3 part series.
Part 4 is about Culture
5. Why we study history ?
● Because I`m a grumpy old frustrated sysadmin
● Because I`m an old opiniated guy
● Because history repeats
● We need to learn from our mistakes
6. Deploying an Infrastructure
● 1996 : Manual Installations , manually copying around config files and making
changes
● 2001 : Mondo rescue (reproducable single instances)
● 2003 : SystemImager
• Reproducable Infrastructure , with “OVERRIDES”
• Fast Multicast Image deployments
• Image Sprawl (thank you VMware)
7. Deploying an Infrastructure
● 1996 : Manual Installations
● 2001 : Mondo rescue
● 2003 : SystemImager
● 2005 : Kickstart / FAI
• Dreaming of Jeos + IAC (Cfengine)
8. Deploying an Infrastructure
● 1996 : Manual Installations
● 2001 : Mondo rescue
● 2003 : SystemImager
● 2005 : Dreaming of Jeos + IAC
● 2008 : Actual JeOS + IAC
● 2010 : Vagrant for development
9. For years we've tolerated humans to to make structural manual changes to the
infrastructure our critical applications are running on.
Whilst at the same time demanding those critical applications to go trough rigid test
scenarios.
Who let this happen ?
10. Infrastructure as Code
● Treat configuration automation as code
● Development best practices
• Model your infrastructure
• Version your cookbooks / manifests
• Test your cookbooks/ manifests
• Dev/ test /uat / prod for your infra
● Model your infrastructure
● A working service = automated ( Application Code + Infrastructure Code + Security + Monitoring )
● Think Puppet, Chef, Cfengine, ....
20. Ops reaction :
● You want me to write code ?
● Yes shell , perl, python, ..
21. Ops Reaction:
● You want me to use git ?
● Yes it's 2015 .. use git or be looking for a new job.
22. You'd think the previous conversation took place in in 2005.
Sadly it didn't , it still happening in 2015
23. Ops reaction :
● You want me write tests ?
● Yes .. as you are writing code
24. Ops reaction :
● You want me do to continous Integration ?
● Yes .. as you are developing software
25. Ops reaction :
● You want me do to continous deployment ?
● Yes .. as you need to experience how to do it so you can assist the developers with
their own code base.
26. A pipeline
● Checkout code
● Syntax
● Style
● Code Coverage
● Tests
● Build
● More Tests
● Package
● Upload to Repo
● Deploy on Test
● Check Puppetruns
● Check Icinga
● Promote to UAT
27. Share the pain , same tools .. you now know much better how to support the devs..
29. “There is a module ... for that”
● Which of the 60+ apache modules do you want ?
● But it doesn't work on your distro
● But it starts the service while you want your cluster soft to manage it.
● It doesn't use (the upstream) packages
● ...
31. devops : a movement tricking operations people into writing code to automate their
infrastructure since 2007
32. All I wanted was to put this one server, one application in production.
● We are talking datacenters .. it's never just one server , you need to have dev, test,
acceptance, production platforms
● HA, Scaleout ?
33. ● Orchestration ? I need to have access to the database before I can launch the
appliction
● That's a design error
34. NoOps anno 2010
● I've build this app and put it in production on my favourite Saas,
● THEIR ops people will run it for me under strict limitations
35. Quiz :
● I've build this app and wrapped it in a
● I can run it everywere
● Who ?
36. Quiz :
● I've build this app and wrapped it in a
● I can run it everywere
● Sun Microsysystem Announcing Java in 1996
37. Quiz :
● I've build this app and wrapped it in a
● I can run it everywere
● Now I can choose what distro I want and put it in production
●
● Who ?
38. Quiz :
● I've build this app and wrapped it in a
● I can run it everywere
● Now I can choose what distro I want and put it in production
●
● A docker fanboy in front of a room of senior ops people in early 2014
39. If all you know is docker, every whale looks like a private cloud
Image Build by devs,
maintained by nobody
40. Closing the gaps between dev and ops
● How do you even build a container
● How do you build the hosts that run the containers ?
● Infrastructure as code ++
41. I never hated Config Management in the first place .. it was love at first sight ..