osdc 2015: kris buytaert | from configmanagementsucks to configmanagementlove
TRANSCRIPT
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
#devops=~C(L)AMS ● Culture
● (Lean)
● Automation
• Packaging
• IAC
● Monitoring and Measurement
● Sharing
● Damon Edwards and John Willis
Gene Kim
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
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)
Deploying an Infrastructure
● 1996 : Manual Installations
● 2001 : Mondo rescue
● 2003 : SystemImager
● 2005 : Kickstart / FAI
• Dreaming of Jeos + IAC (Cfengine)
Deploying an Infrastructure
● 1996 : Manual Installations
● 2001 : Mondo rescue
● 2003 : SystemImager
● 2005 : Dreaming of Jeos + IAC
● 2008 : Actual JeOS + IAC
● 2010 : Vagrant for development
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 ?
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, ....
for $tool in “bcfg2 lcfg cfengine puppet chef “
$tool is user-friendly it's just picky about who its friends are.
You'd think the previous conversation took place in in 2005.
Sadly it didn't , it still happening in 2015
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.
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
“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
● ...
devops : a movement tricking operations people into writing code to automate their infrastructure since 2007
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 ?
● Orchestration ? I need to have access to the database before I can launch the
appliction
● That's a design error
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
Quiz : ● I've build this app and wrapped it in a
● I can run it everywere
● Sun Microsysystem Announcing Java in 1996
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 ?
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
If all you know is docker, every whale looks like a private cloud
Image Build by devs, maintained by nobody
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 ++
Contact Kris Buytaert [email protected] Further Reading @krisbuytaert http://www.krisbuytaert.be/blog/ http://www.inuits.be/
Inuits Duboistraat 50 2060 Antwerpen Belgium 891.514.231 +32 475 961221