Dev ops for developers

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: I am johann. a few people already know me. a warm welcome to you, too! I‘ll leave the boring company stuff out.\n
• #6: Because you are more interesting.\n
• #7: Who is a developer? \nWho is a administrator? Should you wear a beard?\nWho is neither a developer nor a system administrator? \nHey, nice, what are you? And why are you here? \n\n
• #8: Let‘s see what the development background is. How many of you are php developers? You can tell the truth, i am a PHP developer, too. sounds a bit like the alcoholics anonymous - „Hi, i am johann, and i am a PHP developer“.\nA java developer? Are there still jobs around for java developers? \n
• #9: \n
• #10: \n
• #11: Obviously You should do it because it‘s cool. DevOps is much of a hype right now, and you can be part of it! It‘s like the Google Wave developer hype without the disappointment later\n
• #12: The truth is a lot more boring - it‘s because we need it. Let me tell you a story about the dark age.\n
• #13: Do You remember the dark ages of development? How did development happen that days? \n(by the way: he does look a bit like benjamin eberlei, doesn‘t he?)\n
• #14: We used an basic vmware image. it was downloadable at some local fileserver, several gigabytes big and everything you needed for development was already installed. \n
• #15: This golden image always looked good in the beginning, but your application started to change. stuff was added, some kind of improvements were made. a default database was supplied, too. there was a default user used by everybody. \n
• #16: - but changes were needed - bash scripts to change the configuration\n- database update scripts - versioned database update scripts\n- a lot of bugs were solved by „you need to run the update script“\n- and the same amount of bugs were created by running the update script. \n- from time to time a new golden image was needed and some of the devs used it.\n
• #17: - after a while every developer had his own improved version of the image\n- incompatible, different versions, only the local version management sandbox was up to date\n\n
• #18: \n
• #19: \n
• #20: And in the good old days our application infrastructure was simple 3-tier\nweb server and database server were happening on one host.\n
• #21: Suddenly we had to add stuff. Like a hip NoSQL Server\n
• #22: And a memcache server, for Caching.\n
• #23: memcache became unhip, so it was replaced by redis\nan asynchronous messagequeue like gearman was introduced\n
• #24: Gearman wasn‘t so enterprisey in the end, so it was replaced by ActiveMQ. \nAn eJabberD was introduced for browser-side pubsub.\n
• #25: And actually it was 4 Servers now. \n
• #26: Ending up in 4 different bash scripted setup routines based on a set of 3 golden images.\n
• #27: On the other hand side, there wasn‘t just development, there was continious integration and production as well. sometimes with a different deployment mechanism.\n
• #28: And there were different Versions deployed, anyway. \n
• #29: With different tools, and software versions to work with different tools. Your application version happens in your version management system, your configuration in some adminstrators bash script. both are not in sync. \n
• #30: This wasn‘t any fun anymore. the number of wtf/minute was constantly increasing. We did not like it a lot.\n
• #31: 10th floor test: throw a random computer out of the windows and wait how long it takes everything is up & running again. We did not actually do it, since we are in a 5 store building. If your building is higher, try it out, it‘s a good benchmark.\n
• #32: That‘s our collection of fails. No simplicity, no failsafety - if a configuration is screwed it‘s screwed. \n
• #33: But how do we get there?\n
• #34: DevOps for the win!\n
• #35: (Danger: Code ahead)\n
• #36: (Danger: Code ahead). It works good on any linux, bsd etc. including Mac. Windows, especially with 64 bits is a bit hard to do, you have to use jruby. \n
• #37: With a cool logo!\n
• #38: First install vagrant and veewee. this is done using the default ruby gem install. \nlist baseboxes, choose yours and use it as your default box.\n\n
• #39: \n
• #40: \n
• #41: \n
• #42: First thing to know: configuration is code. it‘s not a setup anymore. \n
• #43: That are the two main players. like linux and freebsd, like gnome and kde everything opensource gets better when there are two of a kind. Does anyone still know cfengine?\n
• #44: On first sight chef and puppet look like twins. (Those are my sons, btw, sorry to show you, you know how proud parents are :-) )\n\n
• #45: \n
• #46: \n
• #47: \n
• #48: There are several tests and comparisons available online. half of the time puppet wins, half of the time chef does. there is no winner. have a look at it and take the tool you like. if you are an experenced ruby developer, chef is the better choice, if not, puppet can be. \n
• #49: That‘s how the puppet DSL looks like. You‘ll see some more examples later.\n
• #50: And that‘s how chef syntax looks like. The difference is:\nThis is ruby code. You have the full flexibility of the language available.\n
• #51: \n
• #52: That is the first Vagrantfile generated by vagrant init\n
• #53: Here we are talking vagrant. \n- puppet as a machine provisioner, with a link to the puppet directory and the default manifest for this machine - and more machines are possible\n- name of the server, network configuration, port forwarding and mount points.\n\n
• #54: This is the puppet configuration file for my nodes ( servers). i can include directores, and i can include other classes in my classes. \n
• #55: That‘s the included definition of the web class. see, there is inheritance.\nThe apache-include is a puppet module and provides for example the vhost configuration\nThe package is a resource wrapper for apt here, since this is an ubuntu natty setup.\n
• #56: This is an example for a custom package provider for pear packages.\n
• #57: \n
• #58: This is an example based on the zend framework default directory layout. Two parts are going to change - the configs will contain the server setup as well, and there is a new vms folder within the scripts directory, containing a Vagrantfile. let‘s cd into scripts/configuration and start to work\n
• #59: \n
• #60: That‘s our collection of fails. No simplicity, no failsafety - if a configuration is screwed it‘s screwed. \n
• #61: \n
• #62: \n
• #63: And all the developer has to do is a vagrant up to get his vms from the source\nif there have been configuration changes just do a vagrant provision\nno more. \nNO NEED TO SAVE YOUR VM ANYMORE!\n
• #64: \n
• #65: this is an additional module for vagrant to give you a chance to screw your vms.\n
• #66: \n
• #67: \n
• #68: \n
• #69: \n
• #70: \n
• #71: Right now libvirt-based, in future ec2-support is going to happen\n
• #72: \n
• #73: That‘s how you create a new machine. Or your developers do in self service. \nDo you remember how long this took before? \n\n
• #74: \n
• #75: \n
• #76: \n
• #77: \n
• #78: \n
• #79: \n
• #80: \n
• #81: \n
• #82: \n
• #83: \n
• #84: \n
• #85: \n
• #86: \n
• #87: \n
• #88: \n
• #89: \n
• #90: \n
• #91: \n
• #92: \n
• #93: \n
• #94: Danke an Jimdo für das Beispiel.. \n
• #95: \n
• #96: Wer setzt Jenkins ein? (sonst erklären)\n
• #97: \n
• #98: Sebastian wird hierüber noch mehr erzählen. \n
• #99: \n
• #100: \n
• #101: - gemeinsame Standups\n- gegenseitige Teilnahme an den Sprint Plannings & Retros\n- gleiche Räume, wenn möglich\n
• #102: Der Code gehört auch den Admins, die Konfiguration und die Verlässlichkeit auch den Developern.\n
• #103: Wie bekommt man Respekt hin?\n- Soziale Interaktion, Feiern, Teambuilding\nWenn ich jemand persönliche kenne nehme ich auf seine Interessen Rücksicht\n
• #104: Die langfristige Planung wird gemeinsam gemacht. Es werden gemeinsame Ziele definiert, und die Lösungsstrategien gemeinsam erstellt.\n
• #105: \n
• #106: \n
• #107: \n
• #108: \n
• #109: \n
• #110: \n
• #111: \n