DevOps & 8000 Server - heinlein-support.de · 4 DevOps & 8000 Server - Theorie Was ist eigentlich … DevOps? Kultur (Verhalten untereinander, Verantwortung gegenüber dem Projekt,

DevOps & 8000 ServerMatthias Klein

2

DevOps & 8000 Server – About Me

About Me

● Seit 2009 in der Administration von Browsergames tätig● TeamLead Backend Operations bei InnoGames● Früher Sysadmin bei „Die Stämme“● Aktuell zuständig für: Payment, Conversion, MySQL, Mail ...

3

DevOps & 8000 Server - Topics

Vergangenheit2

Theorie1

Gegenwart3

Zukunft4

4

DevOps & 8000 Server - Theorie

Was ist eigentlich … DevOps?

● Kultur (Verhalten untereinander, Verantwortung gegenüber dem Projekt, gegenseitiges Vertrauen)

● Praktiken (Regeln, Rollen, Prozesse, Metriken)● Tools (Nutzung gemeinsamer Technologien, Erstellung von

Tools füreinander)

5


Was ist eigentlich … Kultur?

● Alle Beteiligten bilden ein Team (auch der SysAdmin)● Das Produkt steht im Vordergrund, nicht die Einzelleistung● Es gibt kein „Fingerpointing“, im Fehlerfall werden

Möglichkeiten zur Verbesserung erarbeitet und implementiert● Teamentscheidungen werden vom Team getragen

6


Was ist eigentlich … Praktiken?

● Vor Projektstart werden Zuständigkeiten zugewiesen● Der Workflow wird einheitlich für das Projekt abgesprochen

(auch über mehrere Komponenten)● Definition der Prozesse von der Anfrage bis zur Auslieferung● Woran wird der Erfolg gemessen und wie

7


Was ist eigentlich … Tools?

● Festlegung der Grundtechnologien (z.B. git oder svn, php oder java, python oder bash)

● „Helferlein“ werden allen zur Verfügung gestellt (z.B. scripte)● Erstellung von Tools, die man selbst zwar nicht braucht, die

aber anderen die Arbeit erleichtern

8

DevOps & 8000 Server - Vergangenheit

Meine persönlichen Erfahrungen (I)

● Starke Trennung von Teams (Dev / Ops / QA)● Starre Prozesse (z.B. Abzeichnen vor Deployments)● Devs dürfen nicht auf Produktion zugreifen Deployment →

nur durch Ops● Devs erstellen ihre Testumgebung selbständig● Ops verwalten die Produktion selbständig Devs müssen →

nachfragen, wenn sie Konfigurationen von dort wollen● Bei Problemen mußte immer ein Schuldiger gefunden

werden

9


Meine persönlichen Erfahrungen (I)

● Der Rollout von Bugfixes dauert unnötig lang● Nervige Anfragen nach logfiles, configs, etc.● Unterschiedliche Konfigurationen von Produktion, Test und

lokalen Umgebungen● Keine gemeinsamen Ziele, individuelle Ziele widersprechen

sich häufig● Sehr wenig Automatisierung (z.B. simples Kopieren von

Konfigurationen)

10


Meine persönlichen Erfahrungen (II)

● Devs haben /root auf der Produktion● Devs deployen selbständig und ohne Ankündigung an Ops● Devs installieren und konfigurieren benötigte Software

selbständig in der Produktion● Nur Standardsoftware wird von Puppet verwaltet● Wenig Kommunikation zwischen Devs und Ops

11


Meine persönlichen Erfahrungen (II)

● Devs zerstören die Produktionsumgebung, weil sie für die Installation einer Software die Anweisungen vom ersten GoogleTreffer befolgen

● Die Server laufen plötzlich Amok, nach längerer Fehlersuche findet man das letzte Release als Ursache

● Server lassen sich nicht neu aufsetzen, weil benötigte Software nicht von Puppet verwaltet wird

● Die Anwendung funktioniert nicht mehr, weil ein „unnötiges“ Paket entfernt wurde

12

DevOps & 8000 Server - Gegenwart

Mit DevOps wird alles besser ;)

● Gemeinsames Analysieren von Problemen/Anforderungen und Erarbeitung von Strategien zur Verbesserung

● „Jammern auf hohem Niveau“ ist explizit erwünscht● Jeder muß die DevOpsKultur (vor)leben

● Wir sind ein Team, jeder ist für den Erfolg verantwortlich● Wenn Fehler passieren, ist nicht das Individuum, sondern

das Team schuld – erstmal ;)

13


Wie wird DevOps zum Erfolg?

● Jeder muß sich selbst zurücknehmen und die DevOps Kultur verinnerlichen

● Devs machen so wenig Ops wie möglich● Weil sie kein Interesse daran haben● Weil es unnötig ist

● Durch bereitgestellte Informationen● Durch bereitgestellte Tools

14


DevOps und Entwicklerteams (persönliche Erfahrungen)

● Je größer das Team, desto schlechter die Aussicht auf Erfolg● Ideal sind bis zu 6 Entwickler, kann je nach Team auch mit

mehr funktionieren● Bei großen Teams sollten einige aus verschiedenen

Bereichen ein DevOps Team bilden und dann in den jeweiligen Bereich weitertragen

15


Unsere Maßnahmen

● Jeder SysAdmin arbeitet mindestens 1 Tag/Woche im Büro des Entwicklerteams und ist dann nur für deren Belange da

● Teilnahme an StandUp, Retro und Planungsmeetings● Entwickler sorgen dafür, daß ihre Software redundant

lauffähig ist● Admins sorgen dafür, daß Server automatisiert (neu)

aufgesetzt werden können● Alle sorgen für ein reproduzierbares Deployment

16


Puppet

● Jede Maschine muß allein mit puppet zur Produktionsreife kommen (funktioniert nicht, wenn backups eingespielt werden müssen)

● Jede Entwicklungsstufe verwendet die selben Manifeste und Templates, Variablen werden über hiera verwaltet

● Puppet Environments und git branches ermöglichen das Testen von Änderungen

● External Nodes und ein Admintool sorgen für die Zuordnung

17


Paketmanagement

18


Paketmanagement

● Verhindert in Kombination mit Nagios checks, daß unbekannte/unerwünschte Pakete installiert sind

● Stellt einen einheitlichen PatchStand über alle Systeme sicher

● Mittels aptmirror, aptftparchive und einem selbst entwickelten Repomanager werden Pakete zur Verfügung gestellt

19


Jenkins

● Devs haben die Testabdeckung und qualität auf nahezu 100% erhöht

● Jenkins wird als Jobstarter benutzt, um Probleme mit unterschiedlichen Versionsanforderungen zu umgehen

● Jobs werden in VM‘s ausgeführt, nicht in … weil● Vagrant: sehr schlechte Performance, undefiniertes

Verhalten bei mehreren gleichzeitig startenden boxen● Docker: bildet die Produktion nicht korrekt genug ab, soll

nicht als VM mißbraucht werden● Erstellen von .deb Paketen

20


Vagrant

● Einfache Konfigurationshilfe: https://github.com/innogames/invade

● Bildet die Produktionsumgebung so gut wie möglich auf dem Entwicklerrechner ab

● Provisionierung via Puppet

https://github.com/innogames/invade

21


Live Demo

22

DevOps & 8000 Server - Zukunft

ToDo / WiP

● Entwickler erhalten die Möglichkeit, eigene Änderungen in Puppet vorzunhemen

● Refactoring und Veröffentlichung der Puppetmodule auf GitHub

● Erstellen und Provisionieren von Maschinen nach Bedarf

23

DevOps & 8000 Server - Ende

Documents

DevOps & 8000 Server - heinlein-support.de · 4 DevOps & 8000 Server - Theorie Was ist eigentlich … DevOps? Kultur (Verhalten untereinander, Verantwortung gegenüber dem Projekt,