DevOps für PHP (und andere)

Hinweis der Redaktion

• #2: DevOps: \n- Organisationsgeprägt, Wall of Confusion \n- Test, Software und Deployment-geprägt (siehe Sebastian)\n- Kanban / Lean-Startup-Motiviert (habe ich dabei, mach ich aber nicht)\nFazit: Tools mit ein bischen Organisation\n
• #3: Warnung: Leute mit empfindlichen Magen haben jetzt die Gelegenheit, den Raum zu verlassen.\n
• #4: Meine Geschichte heute beginnt lange vor unserer Zeit. Eine Zeit, in der vieles grundlegend anders war, vieles überraschend und wenige Dinge so wie heute.\n
• #5: Konkret geht es etwa um das Jahr 2007. \nJepp, unsere Branche ist da etwas schnelllebiger als die anderen.\nIn unserer Branche haben sich zwei Dinge geändert:\n
• #6: Zum einen haben Consultants auf einmal damit angefangen, den ganzen Tag von Wolken zu reden.\n
• #7: Zum anderen mussten einige Dinge auf einmal schnell gehen.\n
• #8: Die Cloud war erst mal ein typisches IT-Ding. \nWir haben eine Lösung, die ist echt super. \nWir haben bloss kein Problem dafür. \n
• #9: Das hat auch den Consultants, die so begeistert von der Cloud erzählt haben, ein Problem gebracht.\n
• #10: \n
• #11: Nach einer Weile gab es dann auch einen ganzen Haufen Cloudplattformen, die unserer Web-Applikationen unterstützt haben - IaaS per se, manche PaaS explizit und spezialisiert - nur wir wussten nicht, was wir damit machen sollten.\n
• #12: Kommen wir zum Thema Geschwindigkeit: \nDinge, die auf einmal schnell gehen müssen. Und damit ist nicht Responsivität oder Request per Minute gemeint, sondern wie schnell die Unternehmen ticken.\n
• #13: Die Jungs sind zum Beispiel nicht so schnell\n
• #14: Die wiederum sind schnell. Facebook kann Features in wenigen Tagen durchbringen. Es gibt Dinge wie Code von neuen Kollegen, der nach 2 Tagen in Produktion ist. Auf ein paar 100.000 Servern.\n
• #15: Die sind auch schnell. Und die sind nicht nur schnell in Features wie Facebook, sondern auch schnell in wachsen.\n
• #16: Scalarium: DevOps-Firma, die genau das für Kunden macht.\n
• #17: Wie die das machen, erzähl ich hier heute.\n
• #18: \n
• #19: \n
• #20: \n
• #21: Wer von euch arbeitet agil? \nWer von macht SCRUM? \n\n
• #22: 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
• #23: Wie lange braucht Ihr, um von einer Idee in Produktion zu kommen? \n\n
• #24: Hinter der Cloud steht die Idee - speziell bei IaaS - Hardware wie Software zu behandeln.\n
• #25: Und zwar ganz konkret. Bei Amazon habe ich genau ein WebFrontend oder eine API. Ob die Server dann auf einem Mainframe emuliere, auf Marsbakterien oder per Hand von sehr schnellen Indern ausrechnen lassen weiss ich nicht.\n
• #26: In der Praxis wurde es trotzdem weiter wie Hardware behandelt. Eine Virtualisierung, die nicht bei uns im Keller, sondern eben woanders steht. Nach Maschine abgerechnet und individuell per SSH gepflegt.\n
• #27: In 2009, nach also 2 Jahren nachdenken, kamen ein paar clevere Admins zu dem Schluss, dass das vielleicht nicht die richtige Strategie ist. \n
• #28: Und da sind sie rausgekommen: Wenn meine Hardware wie Software ist, dann kann ich die auch Automatisieren. Konkret: ich schreibe auf, was ich eigentlich haben will, und dann macht die Automatisierung, dass ich genau das bekomme.\n
• #29: Neben Puppet gibt es noch Chef. Ist genauso gut, etwas flexibler, ich kann es nur nicht. Die Prinzipien sind aber die gleichen.\n
• #30: Puppet ist eine DSL für Systembeschreibungen. Das beginnt mit der IP-Adresse bishin zur Konfiguration der Software. \n\n
• #31: Puppet besteht aus zwei Kernkomponenten - einem Puppetmaster, der als Server irgendwo in der Mitte steht - und einem lokalen PuppetD, der zB alle 30 minuten die Konfiguration anpasst.\n
• #32: Puppet sagt an. Der Status wird definiert, und der Puppetd macht, dass der Rechner den dann hat. Egal wie es vorher aussah.\n
• #33: Wie macht er das? Über Facter wird der aktuelle Status - Versionen, laufen Services, sind die benötigten Files da - gegen das Puppet-Manifest geprüft. Wenn irgendetwas nicht stimmt, weiss PuppetD aus dem Manifest, wie er es zu machen hat.\n
• #34: Und so sieht so eine Beschreibung konkret aus. Wie man sieht: das ist gar nicht so ruby, das tut gar nicht weh.\n\n
• #35: \n
• #36: Wenn ich eh schon weiss, wie es aussehen soll, und mit facter prüfe, ob das wirklich so aussieht, kann ich ja auch zentral wissen, ob alles ok ist.\n
• #37: Das ist das Puppetlabs-Dashboard. Das zeigt mir in diversen Ansichten, wie die kritischen Dienste auf meinen Servern aussehen.\n
• #38: Über puppet-Nagios kann ich das ganze sogar in mein vorhandenes Monitoring einbinden.\n
• #39: Wenn ich eh alles in Code habe, und weiss, wie meine Server aussehen sollen. Und wenn mein Development genauso aussehen soll wie die Produktion - mit abstrichen - dann kann ich doch einfach die Konfiguration übernehmen?\n
• #40: Damit lassen sich VMs automatisch erzeugen. Virtualbox = läuft überall & OpenSource.\nDas ist geil weil ... \n
• #41: - 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
• #42: \n
• #43: \n
• #44: \n
• #45: \n
• #46: \n
• #47: architecture=x86 ist facter-wissen als filter. das geht auch über klassen, services, speichergröße, cloud-zone etc.\n
• #48: \n
• #49: \n
• #50: \n
• #51: \n
• #52: \n
• #53: \n
• #54: Danke an Jimdo für das Beispiel.. \n
• #55: \n
• #56: Wer setzt Jenkins ein? (sonst erklären)\n
• #57: \n
• #58: Sebastian wird hierüber noch mehr erzählen. \n
• #59: \n
• #60: \n
• #61: - gemeinsame Standups\n- gegenseitige Teilnahme an den Sprint Plannings & Retros\n- gleiche Räume, wenn möglich\n
• #62: Der Code gehört auch den Admins, die Konfiguration und die Verlässlichkeit auch den Developern.\n
• #63: Wie bekommt man Respekt hin?\n- Soziale Interaktion, Feiern, Teambuilding\nWenn ich jemand persönliche kenne nehme ich auf seine Interessen Rücksicht\n
• #64: Die langfristige Planung wird gemeinsam gemacht. Es werden gemeinsame Ziele definiert, und die Lösungsstrategien gemeinsam erstellt.\n
• #65: \n
• #66: \n
• #67: \n
• #68: \n
• #69: \n
• #70: \n
• #71: \n