Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Einmal war Noah im Meer, als eine Welle über ihm zusammenbrach und ihm den Atem raubte, als sie ihn tiefer ins Meer zog. Gerade als er wieder zu Atem kommen wollte, kam eine weitere Welle auf ihn zu. Sie raubte ihm einen Großteil seiner verbliebenen Energie. Sie zog ihn noch tiefer in den Ozean. Gerade als er sich wieder erholen wollte, brach eine weitere Welle über ihn herein. Je mehr er gegen die Wellen und das Meer ankämpfte, desto mehr Energie wurde ihm entzogen. Er fragte sich ernsthaft, ob er in diesem Moment sterben würde. Er konnte nicht mehr atmen, sein Körper schmerzte und er hatte Angst zu ertrinken. Dem Tod nahe zu sein, half ihm, sich auf das Einzige zu konzentrieren, was ihn retten konnte, nämlich seine Energie zu sparen und die Wellen zu nutzen, anstatt sie zu bekämpfen.

In einem Startup, das kein DevOps praktiziert, ist es wie an diesem Tag am Strand. Es gibt Produktionsfeuer, die monatelang brennen; alles ist manuell, Alarme wecken dich tagelang auf und schaden deiner Gesundheit. Der einzige Ausweg aus dieser Todesspirale ist der DevOps-Weg.

Mach eine richtige Sache, dann eine andere, bis du Klarheit findest. Als erstes solltest du einen Build-Server einrichten, deinen Code testen und manuelle Aufgaben automatisieren. Tu etwas; das kann alles Mögliche sein, aber sei "handlungsfreudig". Mach die erste Sache richtig und sorge dafür, dass sie automatisiert wird.

Eine häufige Falle in Start-ups oder anderen Unternehmen ist die Suche nach Superhelden. "Wir brauchen einen Performance Engineer", weil er unsere Performance-Probleme lösen wird. "Wir brauchen einen Chief Revenue Officer", weil er alle Verkaufsprobleme lösen wird. "Wir brauchen DevOps-Ingenieure", weil sie unseren Bereitstellungsprozess verbessern werden.

Bei einem Unternehmen hatte Noah ein Projekt, das über ein Jahr in Verzug war, und die Webanwendung war bereits dreimal in mehreren Sprachen neu geschrieben worden. Für die nächste Version brauchte er nur noch einen "Performance Engineer", um sie fertigzustellen. Ich erinnere mich, dass ich der einzige war, der mutig oder dumm genug war zu fragen: "Was ist ein Performance Engineer?" Dieser Ingenieur sorgte dafür, dass alles in großem Umfang funktionierte. In diesem Moment wurde ihm klar, dass sie einen Superhelden suchten, der sie retten sollte. Das Superhelden-Einstellungssyndrom ist der beste Weg, um herauszufinden, ob bei einem neuen Produkt oder einem neuen Startup etwas schief läuft. Kein Mitarbeiter wird ein Unternehmen retten, wenn er nicht zuerst sich selbst rettet.

In anderen Unternehmen hörte Noah ähnliche Dinge: "Wenn wir nur einen leitenden Erlang-Ingenieur einstellen könnten", oder "Wenn wir nur jemanden einstellen könnten, der uns Umsatz bringt", oder "Wenn wir nur jemanden einstellen könnten, der uns beibringt, finanziell diszipliniert zu sein", oder "Wenn wir nur einen Swift-Entwickler einstellen könnten", usw. Diese Einstellung ist das Letzte, was dein Startup oder dein neues Produkt braucht - es muss verstehen, was es falsch macht und dass nur ein Superheld den Tag retten kann.

Im Fall des Unternehmens, das einen Leistungsingenieur einstellen wollte, stellte sich heraus, dass das eigentliche Problem in der unzureichenden technischen Überwachung lag. Die falschen Leute hatten das Sagen (und beschimpften die Leute, die das Problem lösen könnten). Indem ein schlechter Mitarbeiter entlassen wurde, ein bestehendes Teammitglied angehört wurde, das die ganze Zeit wusste, wie das Problem zu lösen war, die Stellenausschreibung gestrichen wurde, eine richtige Sache nach der anderen getan wurde und ein qualifiziertes technisches Management eingesetzt wurde, löste sich das Problem von selbst, ohne dass ein Superheld eingestellt werden musste.

Niemand wird dich in deinem Startup retten; du und dein Team müsst euch selbst schützen, indem ihr ein gutes Teamwork und einen guten Prozess aufbaut und an eure Organisation glaubt. Die Lösung des Problems liegt nicht in einer Neueinstellung, sondern darin, ehrlich und achtsam mit der Situation umzugehen, in der du dich befindest, wie du dorthin gekommen bist, und eine richtige Sache nach der anderen zu tun, bis du dich herausgearbeitet hast. Es gibt keinen Superhelden, wenn du es nicht selbst bist.

Wie bei einem Sturm im Meer, bei dem du langsam ertrinkst, kann niemand dich oder dein Unternehmen retten, wenn du es nicht selbst bist. Du bist der Superheld, den dein Unternehmen braucht, und vielleicht entdeckst du, dass deine Mitarbeiter/innen das auch sind.

Es gibt einen Weg aus dem Chaos, und dieses Buch kann dein Wegweiser sein. Lass uns loslegen.

Was bedeutet DevOps für die Autorinnen und Autoren?

Viele abstrakte Konzepte in der Softwarebranche sind schwer genau zu definieren. Cloud Computing, Agile und Big Data sind gute Beispiele für Themen, für die es viele Definitionen geben kann, je nachdem, mit wem du sprichst. Anstatt genau zu definieren, was DevOps ist, wollen wir einige Begriffe verwenden, die zeigen, dass DevOps stattfindet:

  • Beidseitige Zusammenarbeit zwischen Entwicklungs- und Betriebsteams.

  • Erledigung von Ops-Aufgaben in Minuten bis Stunden, nicht in Tagen bis Wochen.

  • Starke Beteiligung der Entwickler, sonst heißt es wieder: Devs gegen Ops.

  • Betriebsmitarbeiter brauchen Entwicklungskenntnisse - mindestens Bash und Python.

  • Entwickler/innen brauchen operative Fähigkeiten - ihre Aufgaben enden nicht mit dem Schreiben des Codes, sondern mit dem Einsatz des Systems in der Produktion und der Überwachung von Warnmeldungen.

  • Automatisierung, Automatisierung, Automatisierung: Ohne Kenntnisse in der Entwicklung kannst du nicht akkurat automatisieren, und ohne Kenntnisse in der Verwaltung kannst du nicht korrekt automatisieren.

  • Idealerweise: Selbstbedienung für Entwickler, zumindest was die Bereitstellung von Code angeht.

  • Kann über CI/CD-Pipelines erreicht werden.

  • GitOps.

  • Alles in beide Richtungen zwischen Entwicklung und Betrieb (Werkzeuge, Wissen, etc.).

  • Die ständige Zusammenarbeit bei der Planung, Umsetzung, Einführung - und ja, auch bei der Automatisierung - kann ohne Kooperation nicht erfolgreich sein.

  • Wenn es nicht automatisiert ist, ist es kaputt.

  • Kulturell: Hierarchie < Prozess.

  • Microservices > Monolithisch.

  • Das Continuous-Deployment-System ist das Herz und die Seele des Softwareteams.

  • Es gibt keine Superhelden.

  • Kontinuierliche Lieferung ist keine Option, sondern eine Verpflichtung.

Wie man dieses Buch benutzt

Dieses Buch ist in jeder Reihenfolge nützlich. Du kannst jedes beliebige Kapitel aufschlagen und solltest etwas Hilfreiches finden, das du für deine Arbeit nutzen kannst. Wenn du ein erfahrener Python-Programmierer bist, kannst du Kapitel 1 überfliegen. Wenn du dich für Kriegsgeschichten, Fallstudien und Interviews interessierst, solltest du zuerst Kapitel 16 lesen.

Konzeptionelle Themen

Der Inhalt ist in mehrere konzeptionelle Themen aufgeteilt. Die erste Gruppe sind die Python-Grundlagen, die eine kurze Einführung in die Sprache sowie die Automatisierung von Text, das Schreiben von Kommandozeilen-Tools und die Automatisierung des Dateisystems umfassen.

Als Nächstes folgt der Bereich Operations, der nützliche Linux-Dienstprogramme, Paketmanagement, Build-Systeme, Überwachung und Instrumentierung sowie automatisierte Tests umfasst. Dies sind alles wichtige Themen, die du beherrschen musst, um ein kompetenter DevOps-Praktiker zu werden.

Im nächsten Abschnitt geht es um Cloud-Grundlagen, und es gibt Kapitel über Cloud Computing, Infrastructure as Code, Kubernetes und Serverless. In der Softwarebranche gibt es derzeit eine Krise, wenn es darum geht, genügend in der Cloud ausgebildete Talente zu finden. Wenn du diesen Abschnitt beherrschst, wird sich das sofort auf dein Gehalt und deine Karriere auswirken.

Als Nächstes kommt der Bereich Daten. Machine Learning Operations und Data Engineering werden beide aus der Perspektive von DevOps behandelt. Es gibt auch eine komplette Anleitung für ein Machine Learning-Projekt, die dich durch die Erstellung, den Einsatz und die Inbetriebnahme eines Machine Learning-Modells mit Flask, Sklearn, Docker und Kubernetes führt.

Der letzte Abschnitt ist Kapitel 16 über Fallstudien, Interviews und DevOps-Kriegsgeschichten. Dieses Kapitel ist eine gute Bettlektüre.

Python-Grundlagen
Betrieb
Cloud-Grundlagen
Daten
Fallstudien

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch vom Kontext bestimmte Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

Code-Beispiele verwenden

Zusätzliches Material (Codebeispiele, Übungen usw.) steht unter https://pythondevops.com zum Download bereit . Du kannst dir auch DevOps-Inhalte, die mit dem Code im Buch zusammenhängen, auf dem YouTube-Kanal von Pragmatic AI Labs ansehen.

Wenn du eine technische Frage an die Autoren hast oder ein Problem bei der Verwendung der Code-Beispiele, schreibe bitte eine E-Mail an

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus O'Reilly-Büchern erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Genehmigung erforderlich .

Wir freuen uns über eine Namensnennung, verlangen sie aber in der Regel nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: "Python für DevOps von Noah Gift, Kennedy Behrman, Alfredo Deza und Grig Gheorghiu. (O'Reilly). Copyright 2020 Noah Gift, Kennedy Behrman, Alfredo Deza, Grig Gheorghiu, 978-1-492-05769-7."

Wenn du der Meinung bist, dass deine Verwendung von Codebeispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter kontaktieren

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen findest du unter http://oreilly.com.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

  • O'Reilly Media, Inc.
  • 1005 Gravenstein Highway Nord
  • Sebastopol, CA 95472
  • 800-998-9938 (in den Vereinigten Staaten oder Kanada)
  • 707-829-0515 (international oder lokal)
  • 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter oreil.ly/python-for-devops aufrufen.

Schreib eine E-Mail an , um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Neuigkeiten und weitere Informationen zu unseren Büchern und Kursen findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Zunächst möchten die Autorinnen und Autoren den beiden wichtigsten technischen Gutachtern des Buches danken:

Wes Novack ist ein Architekt und Ingenieur, der sich auf öffentliche Cloud-Systeme und SaaS-Anwendungen im Web spezialisiert hat. Er entwirft, baut und verwaltet komplexe Systeme, die eine hochverfügbare Infrastruktur, kontinuierliche Bereitstellungspipelines und schnelle Releases in großen, polyglotten Microservice-Ökosystemen auf AWS und GCP ermöglichen. Wes macht ausgiebig Gebrauch von Sprachen, Frameworks und Tools, um Infrastructure as Code zu definieren, die Automatisierung voranzutreiben und Mühen zu vermeiden. Er engagiert sich in der Tech-Community, indem er an Mentorentreffen, Workshops und Konferenzen teilnimmt, und ist außerdem Autor von Pluralsight-Videokursen. Wes ist ein Verfechter der CALMS von DevOps: Culture, Automation, Lean, Measurement, and Sharing. Du kannst ihn auf Twitter @WesleyTech finden oder seinen persönlichen Blog besuchen.

Brad Andersen ist Softwareentwickler und Architekt. Er entwirft und entwickelt seit 30 Jahren professionell Software. Er arbeitet als Katalysator für Veränderung und Innovation und hat Führungs- und Entwicklungsaufgaben in einem breiten Spektrum von Unternehmen bis hin zu Start-ups übernommen. Brad macht derzeit einen Master in Datenwissenschaften an der University of California, Berkeley. Weitere Informationen findest du auf Brads LinkedIn-Profil.

Wir möchten uns auch bei Jeremy Yabrow und Colin B. Erdman bedanken, die uns mit vielen tollen Ideen und Rückmeldungen unterstützt haben.

Noah

Ich möchte mich bei den Mitautoren des Buches bedanken: Grig, Kennedy und Alfredo. Es war unglaublich, mit einem so effektiven Team zu arbeiten.

Kennedy

Danke an meine Co-Autoren, es war mir ein Vergnügen, mit euch zu arbeiten. Und danke für die Geduld und das Verständnis meiner Familie.

Alfredo

2010, also vor neun Jahren, als ich diesen Artikel schrieb, bekam ich meinen ersten Job als Softwareentwickler. Ich war 31 Jahre alt, hatte keine Hochschulausbildung und keine Erfahrung als Ingenieur. Dieser Job bedeutete, dass ich ein geringeres Gehalt und keine Krankenversicherung akzeptieren musste. Ich habe viel gelernt, tolle Leute kennengelernt und mir durch unermüdliche Entschlossenheit Fachwissen angeeignet. In all diesen Jahren wäre es unmöglich gewesen, hierher zu kommen, wenn mir nicht Menschen Möglichkeiten eröffnet und mir die richtige Richtung gezeigt hätten.

Danke an Chris Benson, der gesehen hat, dass ich lernbegierig war und immer wieder Gelegenheiten gefunden hat, mich dabei zu haben.

Danke an Alejandro Cadavid, der erkannt hat, dass ich Dinge reparieren kann, die sonst niemand reparieren will. Du hast mir geholfen, Arbeit zu finden, als niemand (auch ich nicht) dachte, dass ich nützlich sein könnte.

Carlos Coll hat mich zum Programmieren gebracht und mich nicht aufgeben lassen, selbst als ich ihn darum gebeten habe. Programmieren zu lernen hat mein Leben verändert, und Carlos hatte die Geduld, mich zu drängen, zu lernen und mein erstes Programm in Produktion zu bringen.

An Joni Benton, weil er an mich geglaubt und mir geholfen hat, meinen ersten Vollzeitjob zu bekommen.

Danke an Jonathan LaCour, einen inspirierenden Chef, der mir immer wieder hilft, besser zu werden. Dein Rat war für mich immer von unschätzbarem Wert.

Noah, danke für deine Freundschaft und Führung, du bist eine enorme Quelle der Motivation für mich. Es macht mir immer wieder Spaß, mit dir zusammenzuarbeiten, wie das eine Mal, als wir die Infrastruktur von Grund auf neu aufgebaut haben. Deine Geduld und Anleitung, als ich keine Ahnung von Python hatte, war lebensverändernd.

Zu guter Letzt möchte ich meiner Familie einen großen Dank aussprechen. Meiner Frau Claudia, die nie an meiner Fähigkeit zweifelt, zu lernen und sich zu verbessern, und die so großzügig und verständnisvoll ist, wenn ich Zeit für dieses Buch aufbringe. Meinen Kindern, Efrain, Ignacio und Alana: Ich liebe euch alle.

Grig

Mein Dank gilt allen Entwicklern von Open-Source-Software. Ohne sie wäre unsere Arbeit so viel trostloser und unerfüllter. Mein Dank geht auch an alle, die bloggen und ihr Wissen bereitwillig teilen. Zu guter Letzt möchte ich auch den Koautoren dieses Buches danken. Es war eine wirklich lustige Reise.

Get Python für DevOps now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial