Wo fange ich an, DevOps zu lernen?

Die Suche nach "wie man mit Devops anfängt" hat nicht wirklich geholfen, da viele von ihnen dies und das sowie viele andere nicht wirklich auf den richtigen Weg zeigen. Jedes Youtube-Video, das ich bisher gesehen habe, hat auch nicht geholfen (da ich keine Videos brauche, die mir erklären, was IS-Entwickler sind). Dieses Video ist die einzig wahre Ausnahme (die zeigt, wie sich die Dinge miteinander integrieren).

Ich bin ein CCNA und auch sehr kompetent mit DBMS (lerne derzeit Parallelitätsausführung und andere Dinge).

Aber ich habe keine Ahnung, was ich zuerst lernen soll (oder wo ich die richtigen Ressourcen für diese Angelegenheit finde ).

Ich bin kurz vor dem Abschluss, daher habe ich keinen Zugang zu Erfahrungen aus der realen Welt.

Irgendwelche Ratschläge oder Hilfe?

Devops beziehen sich auf die Ausführung von Software. Es geht darum, wie eine Anwendung oder ein Dienst ausgeführt wird. Serverkonfigurationstools, virtuelle Maschinen und Container sind daher die nächsten Schritte. Ich schlage vor, die Dokumentation dieser Tools zu betrachten und daraus Dinge wie Entdeckung, Beobachtbarkeit, Skalierbarkeit und Redundanz zu lernen. Um nur einige Beispiele zu nennen:

Serverkonfiguration:

• PXE
• Ansible
• Marionette

VM:

• Landstreicher
• QEMU

Container:

• Docker
• Kubernetes

EDIT: Überblick über Cloud-Technologien:

• CNCF-Landschaft

Wenn es in Ihrer Softwarearchitektur um Microservices geht, sind Container eine gute Wahl. Wenn Sie alte monolithische Anwendungen verwenden, sind VMs keine schlechte Option. Es kommt also immer auf den Kontext an, was Sie speziell lernen müssen. Das Thema ist ziemlich weit gefasst, um es zusammenzufassen. Ein Buch könnte dabei helfen, aber leider kann ich kein gutes breites vorschlagen. "Kubernetes in Action" bietet Ihnen jedoch einen guten Start in Kubernetes.

Zunächst möchte ich betonen, dass DevOps eine Kultur und keine Rolle ist. Meiner Meinung nach könnte man es mit einem Team von Kommandos vergleichen, die über eigenes Fachwissen verfügen, z. B. Scharfschützen, Marinesoldaten und Pioniere (denken Sie an die Kommandoserie). Die Kombination dieser Fachkenntnisse, die im Wesentlichen zusammenarbeiten, ermöglicht es, Missionen zu erfüllen oder so schnell wie möglich geschäftlichen Wert zu schaffen.

LowOps und NoOps

Seit ein paar Wochen habe ich festgestellt, dass nach vielen Gesprächen mit Menschen heutzutage eher über LowOps gesprochen wird. Wenn ich eine Lösung implementiere, bedeutet dies, dass sie vollständig automatisiert ist und dass ein Kollege Maschinen selbst bereitstellen kann, anstatt mich zu fragen. Manchmal ist es nicht sofort möglich, es vollständig zu automatisieren, aber dann stelle ich sicher, dass es für mich selbst automatisiert ist, um sicherzustellen, dass ich nur einen Befehl ausführen muss, um die Arbeit zu erledigen (LowOps), anstatt ein paar Stunden zu verschwenden. Wenn ich eine solche Lösung erstellt habe, stelle ich sicher, dass ein Ticket für einen Kollegen erstellt wurde, um meine persönliche Lösung für alle zu automatisieren. Beispiel: Ein Kollege von mir hat eines meiner Bash-Skripte in einen Bot umgewandelt, den es jetzt jede Nacht ausführt.

Abbildung 1: https://www.gslab.com/blog-post/what-is-noops/

"wie man mit devops anfängt"

Stellen Sie sicher, dass Sie Teil eines Teams mit gemischten Kompetenzen sind und dass das Team die Software selbst bereitstellen muss. Sprechen Sie mit allen Teammitgliedern und beginnen Sie mit Aufgaben, die niemand erledigen möchte, da es an Wissen oder Bereitschaft mangelt. Wenn Sie mit einer Aufgabe beginnen, werden Sie auf Dinge stoßen, die Sie nicht kennen. Sehen Sie sich Videos an, besuchen Sie Meetups , kaufen und lesen Sie Bücher, lesen Sie Blogs und offizielle Dokumentationen über Tools, bitten Sie Kollegen, Ihre Pull-Anfragen zu überprüfen und zu kommunizieren und gut zuzuhören, Dinge gut zu dokumentieren und Lösungen vorzubereiten und Kollegen zu demonstrieren (Wissensaustausch) . Der letzte Vorschlag ist, die Work-Life-Balance im Auge zu behalten .

Andere Antworten hier haben sich auf Werkzeuge konzentriert. Meiner Meinung nach ist es natürlich eine gute Sache, Kompetenz in einem Toolkit zu erlangen, aber Sie passen nicht gut in eine DevOps-Kultur. DevOps ist zunächst eine Reihe von Praktiken oder Methoden .

Zu verstehen, warum diese Praktiken und Methoden nützlich sind, hängt von der Erfahrung ab, aber Sie haben diesen Luxus nicht. Ich würde Sie daher darauf hinweisen

• die DevOps Handboox
• Beschleunigen

als Grundlagentexte.

Die Continuous Delivery-Website enthält außerdem eine Reihe von Grundsätzen und Grundlagen, die Ihnen beim Start die entsprechenden Grundlagen geben.

Ausgehend von diesen werden Sie Praxis und Methoden lernen, die informieren , wie Sie zusammenarbeiten und benutzerfreundlichen Tools.

Alles, was Sie lernen müssen, ist Linux, Docker, Networking, Git, Jenkins usw. Sie können sie hier interaktiv lernen

Wenn Sie nach Video-Tutorials suchen, hat pluralsight etwas Gutes für Sie.

Dies ist die Art von Frage, die ich mir schon oft gestellt habe und die mir tendenziell folgt (jetzt, da ich kaum noch "Anfänger" bin, frage ich mich, wo ich fortgeschrittenere Themen lernen kann). Wie Sie bereits betont haben , überschwemmt das Stellen dieser Fragen in Suchmaschinen leider häufig Websites, die sich an Führungskräfte richten und versuchen zu erklären, was Devops sind. und warum sollten wir den Software-Zyklus mit Devops industrialisieren?

Um Ihre Frage zu beantworten, kann ich jedoch nur aus persönlicher Erfahrung sprechen: Ich habe meine Lernreise mit dem hervorragenden Docker-Leitfaden begonnen .

"Learning DevOps" scheint mir eine zu breite Frage zu sein, wie Sie auch herausgefunden haben, aber ich kann mich daran erinnern, dass ich dasselbe googeln musste.

Um die Antwort von @ jhamfler zu ergänzen: Fragen Sie sich, warum Sie mehr darüber erfahren möchten. Aus welchem ​​Kontext kommst du? DevOps hat normalerweise mit dem Abbau manueller Hürden oder auch mit Silostrukturen in Teams zu tun (jeder erledigt nur seine eigene Aufgabe und verlässt sich darauf, dass jemand anderes über die Integration der Ergebnisse nachdenkt). Gibt es solche "Lücken" in Ihrem Projekt (ich nehme an, Sie haben eine)? Welche Teile davon könnten von der Automatisierung profitieren?

Typische Probleme, die ich vorschlagen könnte, sind:

• Manuelle Serverwartung VS-Skriptlösungen
• Zuverlässigkeit und Backups
• Integrationstests automatisieren
• Automatisierung der kontinuierlichen Bereitstellung (z. B. eines Webdienstes)
• ...

Vielleicht könnte Ihnen auch eine Suche nach "kontinuierlicher Bereitstellung" und "kontinuierlicher Integration" (CI / CD) helfen.

Die allerersten Dinge, die Sie lernen und sich damit vertraut machen müssen:

• Unix (Dateisystem, Berechtigungen, Prozesse, Dienste, Protokolle, Netzwerke usw.)
• SSH & Reverse Tunneling
• Nano / Vim
• Python
• git

Dann könnten Sie zu spezifischeren Themen übergehen:

• Containerisierung (zB Docker)
• Konfigurationsmanagement (zB ansible)
• kontinuierlicher Einsatz (zB Jenkins)
• Überwachung (zB Prometheus / Grafana)