2. Agenda
• Warum dieses DevOps überhaupt?
• Wetware-Refactoring
• Operations-Refactoring
• Bewertung & Spassfaktur für uns
PHPler
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
3. Wer seid Ihr?
Developer?
Sysadmin?
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
4. Das bin ich.
Johann-Peter Hartmann
@johannhartmann
hartmann@mayflower.de
IRC: Freenode, EFNet
johann__
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
5. Und das auch.
Johann-Peter Hartmann
PHP Developer
CTO of 55 developers
Likes PHP, Agility, System
Administration and
Security
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
6. (Zeit schinden durch Publikumsfragen)
Agile?
Scrum?
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
7. (noch mehr Zeit schinden)
Releases / Jahr?
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
8. (in Wahrheit wirds eh wieder knapp am
Tage im Mittel für
Idee ->
Produktion?
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
9. Waterfallization of Scrum- wie gemein ist das
http://dev2ops.org/blog/2010/2/22/what-is-
devops.html Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
10. „It‘s not our
machines, it‘s
your Code!“
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 10
11. „It‘s not our code,
it‘s your
machines“
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 11
12. Betrieb:
Stabilität und
Zuverlässigkeit
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 12
23. Unit Tests
Acceptance
Tests
Metrics
Coding Style
... you get the
idea.
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 23
24. ... and even
more ...
Packaging
Releasing
Deployment
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 24
33. Mccloud
Wrapper around
Vagrant and Fog
Transparent local &
cloud usage
https://github.com/jedi4ever/
mccloud
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 33
36. • Dokumentation = Konfiguration
• DSL für Systemkonfiguration
• Server „puppetmaster“ -
serverdaemon
• Client „puppetd“
– runs as root
– polls every few minutes
– configures everything as needed
– starts services etc
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 36
37. • SSL als Verschlüsselung
– bringt eine eigene CA mit
• Nutzt die vorhandenen Tools:
– apt, RPM, gem, (noch kein PEAR)
• Facter: Tool um Informationen über
das System zu sammeln
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 37
38. class web {
package {“httpd“:
ensure => present,
notify => Service[“httpd“]
}
file {“/etc/httpd/conf/httpd.conf“:
owner => root,
group => root,
mode => 664,
source => puppet:///modules/apache/httpd.conf,
require => Package[“httpd“]
}
service {“httpd“:
ensure => running,
enable => true,
require => File[“/etc/httpd/conf/httpd.conf“]
}
}
node “web01.mydomain.test“ {
include web
}
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 38
40. Puppet-Modules
• apache, nginx, varnish
• php, ruby, tomcat
• mysql, postgresql, memcache,
ejabberd
• apt, zypper, gem
• heartbeat, dns
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 40
41. mCollective
ssh-for-loop on steroids
fast management for loads
of servers
uses puppet/facter, MQ-
based
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 41
42. $ mc-package -W "architecture=x86" status apache
*
[ ============================================================>
] 10 / 10
host01.example.com version = apache-2.2.9-7
host02.example.com version = apache-2.2.9-7
host03.example.com version = apache-2.2.9-7
host04.example.com version = apache-2.2.9-7
host05.example.com version = apache-2.2.9-7
host06.example.com version = apache-2.2.9-7
host07.example.com version = apache-2.2.9-7
host08.example.com version = apache-2.2.9-7
host09.example.com version = apache-2.2.9-7
host10.example.com version = apache-2.2.9-7
---- package agent summary ----
Nodes: 10 / 10
Versions: 10 * 0.25.5-1.el5
Elapsed Time: 1.03 s
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 42
43. The most dangerous
vegetable on earth!
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 43
44. • eigentlich ein BDD-Tool
• trotzdem Bestandteil in DevOps
• und Bestandteil in Lean Startup
• cucumber-nagios
• cucumber-puppet
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
45. Feature: Manualsearch
In order to find an article
As an developer
I want to use the search function
Scenario: Search for bdd and check resulting page
Given I go to "http://it-republik.de/php/"
When I fill in "search_itr" with "bdd"
And I click "search2"
Then I should see "Suche"
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 45
46. Given /^I go to "([^"]*)"$/ do |url|
visit url
end
When /^I fill in "([^"]*)" with "([^"]*)"$/ do |field, value|
fill_in field, :with => value
end
When /^I click "([^"]*)"$/ do |button|
click_button(button)
end
Then /^I should see "([^"]*)"$/ do |text|
response_body.should include(text)
end
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 46
47. johann$ cucumber
Feature: Manualsearch
In order to find an article
As an developer
I want to use the search function
Scenario: Search for bdd and check resulting page # features/
search.feature:5
Given I go to "http://it-republik.de/php/" # features/
step_definitions/search_steps.rb:1
When I fill in "search_itr" with "bdd" # features/
step_definitions/search_steps.rb:5
And I click "search2" # features/
step_definitions/search_steps.rb:9
Then I should see "Suche" # features/
step_definitions/search_steps.rb:13
1 scenario (1 passed)
4 steps (4 passed)
0m1.615s
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 47
49. Das verstehe sogar ich!
Und ich bin seit 20
Jahren im Marketing!
Kontinuierliche Entiwcklung - und dann? I Mayflower GmbH I 28. Oktober 2010 I 49
50. Mehr Spass mit Devops
• Behavior-Driven Infrastructure
– nagios-cucumber
„SchXXX auf Ping, funktioniert die
Anwendung?“
– MCollective mit Cucumber
• BDD-Testing von Cloud-Konfiguration
•
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
51. DevOpsification of Mayflower (Wetware)
1-2 Admins pro Team
–Admin & Development-
Aufgaben
–Vollzeit dem Team
zugeordnet
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
52. DevOpsification of Mayflower (Wetware)
Enge Zusammenarbeit mit zentralem
Admin
Volle Root-Rechte auf Developer-
Infrastruktur
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
53. DevOpsification of Mayflower (Software)
1+n Puppet-Master
– zentraler Firmenmaster
– Teammaster pro Team / Projekt
– Firmenmaster ist Startpunkt der
Teamkonfiguration
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
54. DevOpsification of Mayflower (Software)
Beispiel-Setup:
– lokale Developer-VM
– CI-Deployment-Server in der DMZ
– Staging in der private Cloud
– Beta in Amazon-Cloud
– Production bei Amazon
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
55. DevOpsification of Mayflower (Software)
lokaler GIT- / Gitorious-
Server
Eucalyptus-Cloud in der
DMZ
- im Self-Service!
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
56. DevOpsification of Mayflower (Future)
Vagrant für das
Development
Scrum => KanBan
Puppet Nagios
Unternehmensportrait I Mayflower GmbH I January 29, 2010 I
Notas del editor
\n
\n
\n
\n
\n
Wer von euch arbeitet agil? \nWer von macht SCRUM? \n\n
Wenn Ihr agil seid, wieviele Releases kommen da pro Jahr raus? Wenn es viele sind, wieviele Releases haben Bugs? Welche manuellen Tests werden vor der Produktivnahme gefahren? \n
Wie lange braucht Ihr, um von einer Idee in Produktion zu kommen? \n\n
Wenn man in die PHP-Welt schaut, findet das Development bei den Entwicklern meistens kontinuierliche statt, dh. die Software läuft immer oder zumindest meistens - lokal beim Entwickler.\nScrum taktet das ganze auf den Sprint, an dessen Ende immer das sogenannte „Potentially shippable Product“ stehen sollte. \nDer nachgelagerte Prozess sorgt dafür, dass nicht jede Version per se online geht - sondern nur die, die stabil, getestet und verlässlich werden.\n
Die Jungs vom Betrieb wissen Bescheid: Schuld sind die Entwickler. \n,Es sind nicht unsere Maschinen oder Setups, es ist Dein Code, der hier nicht funktioniert.“\n
Spiegelbildlich gilt das gleiche: „Es ist nicht unser Code, es sind Deine Maschinen!“\n
Der Betrieb stellt Stabilität und Verlässlichkeit in den Vordergrund. Er sorgt dafür, dass alles rund läuft, keine Fehler zum Kunden passieren und die Zugriffe performant und zuverlässig kommen. Fehler werden nicht gerne gesehen, schließlich bedeuten sie Arbeit am Wochenende.\n
Die Developer fokussieren währenddessen auf neue Features - schliesslich ist es das, für das Sie Geld bekommen. Für sie - wie auch für den Businesskunden - steht vor allem der Wandel im Vordergrund, mit dem sich Geld verdienen lässt.\n
Wir haben es also mit zwei grundlegend unterschiedlichen Interessen zu tun. Der Administrator möchte jede Änderung der Software vermeiden, weil sein Chef von Ihm verlangt, die Systeme stabil zu halten. Der Developer möchte Änderung produzieren, weil sein Chef von Ihm neue Features erwartet. Dazu kommen sauber getrennte Verantwortlichkeiten: Der Administrator hat sich in der Programmierung nicht einzumischen, der Developer nicht in die Administration. \n
Genau dieses Thema wird von der DevOps-Bewegung aufgegriffen. Hier wurde ein Toolset erarbeitet, dass eine schnelle Umsetzung von Themen und eine optimale Unterstützung des Business durch Ops und Development ermöglicht. Aber wie erreicht man das? \n
\n
- gemeinsame Standups\n- gegenseitige Teilnahme an den Sprint Plannings & Retros\n- gleiche Räume, wenn möglich\n
Der Code gehört auch den Admins, die Konfiguration und die Verlässlichkeit auch den Developern.\n
Wie bekommt man Respekt hin?\n- Soziale Interaktion, Feiern, Teambuilding\nWenn ich jemand persönliche kenne nehme ich auf seine Interessen Rücksicht\n
Die langfristige Planung wird gemeinsam gemacht. Es werden gemeinsame Ziele definiert, und die Lösungsstrategien gemeinsam erstellt.\n
DevOps ist so definiert von der eigenen Toolwelt, dass viele Leute es als Kern sehen. Und es gibt in der Tat ein paar Sachen dabei, die richtig Spass machen.\n
Vorsicht - die Tools sind meist aus der Ruby-Welt. \nAber: DSL, kein Ruby-Knowhow nötigMayflower: Ruby für Administration, PHP für WebApps.\n
\n
\n
Sebastian wird hierüber noch mehr erzählen. \n
\n
Wir bei Mayflower machen das so. \nBenutzt das ganze Team die gleiche VM? \nWie viele unterschiedliche Maschinen sind in Produktion?\nWie werden Updates gehandhabt? \nWie reproduziert man den alten Stand der Software? Und wie den der Konfiguration? \n
Damit lassen sich VMs automatisch erzeugen. Das ist geil weil ... \n
- jeder Developer kann on Demand welche bekommen\n- das setup das er gerade braucht in Multi-VM-Environments\n- Admin braucht nicht aktiv zu werden. Keine 8 Wochen bis der neue Testrechner bestellt ist :-)\n
\n
\n
Alle Konfiguration findet in Code statt. \n- ein Verzeichnis mit den Vagrant-Konfigurationen\n- versioniert mit der Software \n