DevOps-Leitfaden für Anfänger!

1. DevOps-Einführung: Willkommen zu diesem Skillshare-Kurs über DevOps für Anfänger. Wenn Sie neugierig sind, was DevOps ist, Tools und Technologien es beinhaltet und wie es die Technologiebranche prägt, Sie hier genau richtig In diesem Kurs behandeln wir die Grundlagen von DevOps, was es ist und warum es wichtig ist, wichtige Lernziele wie Verständnis von Automatisierung, CSED und Infrastruktur als Code, eine klare Roadmap , die Sie Schritt für Schritt und Infrastruktur als Code, eine klare Roadmap , die Sie Schritt für Schritt auf Ihrer DevOps-Lernreise begleitet, eine Einführung in Tools und Technologien, die DevOps unterstützen, wie Jenkins, Doc oder Kubints and Moore. Wir vermitteln Ihnen ein fundiertes Verständnis dafür, was in der Branche verwendet wird. Dieser Kurs richtet sich an absolute Anfänger, egal ob Sie Student sind, ein Entwickler, der sich weiterentwickeln möchte , oder ganz neu in der Technik sind. In diesem Kurs werden Sie am Ende dieses Kurses die grundlegenden Konzepte von DevOps verstehen, Einblicke in die Tools und Technologien haben und mit der Roadmap ausgestattet sein, mit der Sie Einblicke in die Tools und Technologien haben und mit der weiter lernen und praktische Fähigkeiten aufbauen können , und sind für die Rolle gerüstet Lassen Sie uns also eintauchen und Ihre DevOps-Reise beginnen. 2. 0101 Der Beginn von DevOps-Moment: DevOps-Entwickler operieren für den IT-Betrieb. Entwickler haben in der Regel die folgenden Verantwortlichkeiten Sie programmieren die Anwendung je nach den Anforderungen oder den Anwenderberichten für diesen Sprint. Anschließend erstellen sie das Projekt, um ein Artefakt oder eine ausführbare Datei zu erstellen, die dann auf dem Server oder in der Entwicklungsregistrierung bereitgestellt werden kann , um ihre Änderungen zu testen Sie sind auch dafür verantwortlich, die gesamte Anwendung zu testen und sicherzustellen, dass alle Funktionen wie erwartet funktionieren und dass keine der Funktionen aufgrund der kürzlich eingeführten Änderungen beschädigt wurde aufgrund der kürzlich eingeführten Änderungen beschädigt Wenn Sie ein separates Qualitätssicherungsteam haben, kümmert sich dieses die Anwendung gründlich zu testen. Auf der anderen Seite hätte das IT-Betriebsteam andere Verantwortlichkeiten. Sie sind dafür verantwortlich, die Anwendung in der Staging- oder Produktionsumgebung bereitzustellen die Anwendung in der Staging- oder , sodass die Anwendung nun vom Kunden oder vom Endbenutzer verwendet werden kann Sie sind auch für die Wartung der Infrastruktur verantwortlich , die für die Bereitstellung der Anwendung erforderlich Sie werden sicherstellen, dass sie angemessene Server und Ressourcen verfügen, damit die Anwendung reibungslos ausgeführt werden kann. Außerdem überwachen sie die Anwendung ständig im Hinblick auf Leistung, Zustand, Ressourcenauslastung , Warnungen, Fehler usw. Nein, die Bereitstellung der Anwendung ist keine leichte Aufgabe. Es ist nicht so, dass Sie das Artefakt auf Ihren Server kopieren und es funktioniert wie von Zauberhand Sie müssen sich um die Abhängigkeiten, Bibliotheken und Konfigurationen kümmern , die beim Ausführen der Anwendung helfen Oftmals sind die Ops-Teams mit diesen Schritten nicht vertraut und nehmen daher Hilfe von Daher würden Entwickler einen Bereitstellungsleitfaden mit klaren schrittweisen Anweisungen zur Bereitstellung der Anwendung bereitstellen Ostam würde diese Schritte befolgen, die Anwendung bereitstellen, und die Anwendung würde einwandfrei funktionieren Bis eines Nachts die Anwendung abstürzt oder einige Funktionen nicht mehr funktionieren. Das führt zu dem berüchtigten Schuldzuweisungsspiel, bei dem das OpsTeam sagen würde, dass alle Anweisungen im Bereitstellungshandbuch befolgt Wenn die Anwendung immer noch nicht funktioniert, liegt es an den Entwicklern Auf der anderen Seite werden die Entwickler die Schuld auf OpSteam zurückwerfen und sagen, dass sie die genauen Schritte im Bereitstellungshandbuch befolgt haben und dass es für sie bei der Registrierung als Entwickler funktioniert hat Die Schuld würde also hin und her gehen , eine Menge Zeit verschwenden Aber die Wahrheit ist, dass der Fehler von jedem sein könnte. Es könnte sein, dass Entwickler einen Schritt im Bereitstellungsleitfaden übersehen haben, oder es könnte sein, dass das oder es könnte sein, dass das Ops-Team die Anweisungen nicht genau befolgt hat, oder vielleicht hat es etwas mit der Ressourcenzuweisung zu tun, oder vielleicht hat das OpsTeam eine andere Version der Software installiert , die nicht unterstützt wird, oder vielleicht hat es etwas mit der Ressourcenzuweisung zu tun, oder vielleicht hat das OpsTeam eine andere Version der Software installiert, die nicht unterstützt wird, oder es kann auch ein Bug im Code sein Vielleicht haben Entwickler einen Fehler gemacht. Zum Beispiel könnten Entwickler einen fehlerhaften Code geschrieben haben , der ständig Speicherplatz verbraucht, bis das System nicht Speicher hat und die Anwendung abstürzt Dies ist bei der Registrierung für Entwickler möglicherweise nicht der Fall , da sie die Anwendung nicht lange genug ausführen , damit sie abstürzt, weil sie die Anwendung immer wieder neu bereitstellen, wie bei der Einführung von bei Dies kann jedoch bei der Registrierung in der Produktionsumgebung passieren, bei der die Anwendung über einen längeren Zeitraum ständig ausgeführt wird Da ich in der Vergangenheit selbst Entwickler war, ist es eigentlich sehr frustrierend, so etwas vom Ops-Team zu hören , da Entwickler im Allgemeinen bereits damit beschäftigt sind, Entwickler im Allgemeinen bereits damit beschäftigt sind die neuen Funktionen zu implementieren Sie haben neue Verpflichtungen, sie sind ihrem Chef gegenüber verantwortlich und sie sind nicht bereit, die alten Protokolle zu durchsuchen , was sich auf ihre aktuellen Projektverpflichtungen auswirken könnte auf ihre aktuellen Projektverpflichtungen auswirken Also versuchen sie, diese Probleme zu vermeiden, indem sie einfach der anderen Partei die Schuld geben Und das Gleiche tut auch das Ops-Team. Aber dieses Schuldzuweisungsspiel verschwendet viel Zeit, und viele Probleme würden für einen langen Zeitraum ungelöst bleiben Und so würde sich sogar die Veröffentlichung um Wochen oder manchmal sogar um Monate verzögern , was zu Frustration bei den Kunden führen würde, und Sie können sich vorstellen, welche Folgen das hat Das bedeutet Umsatz- und Reputationsverlust für das Unternehmen. Dies ist der Auslöser und der Ausgangspunkt für den Da WOps-Moment 3. 0102 Was ist DevOps: Was ist also DevOps? Alles, was wir tun können, um die Effizienz des Teams zu verbessern, die Wahrscheinlichkeit von Fehlern während der Produktion zu verringern, die Kommunikation zwischen Teams zu verbessern und Kommunikation zwischen funktionsübergreifenden Teams zu fördern, die Veröffentlichungszeit zu reduzieren oder den Gesamtprozess zu verbessern, ist DevOps Und all dies kann mit einer Kombination aus Denkweise, kulturellen Philosophien und Praktiken, Tools und Automatisierung erreicht mit einer Kombination aus Denkweise, kulturellen Philosophien und Praktiken, Tools und Automatisierung Tools Und wenn Sie mich fragen, hat sich DevOps heutzutage so stark weiterentwickelt , dass es weniger mit Denkweisen und kulturellen Philosophien zu tun hat , sondern mehr Was ursprünglich als Änderung der Denkweise begann , hat sich inzwischen zu Tools und Automatisierung entwickelt, die wir gleich als Nächstes sprechen werden 4. 0103 Mindset-Philosophien und Praktiken: Lassen Sie uns über den Mindset-Aspekt von DevOps sprechen. Vor DevOps gab es eine psychologische Barriere zwischen Entwicklern und dem IT-Betrieb, sodass sich die Entwickler mehr auf das Schreiben des Codes konzentrierten und sich nicht um die Registrierung kümmerten, unter der die Anwendung ausgeführt werden sollte eine psychologische Barriere zwischen Entwicklern und dem IT-Betrieb, sich die Entwickler mehr auf das Schreiben des Codes konzentrierten und sich nicht um die Registrierung kümmerten, unter der die Anwendung ausgeführt werden unter Das Betriebsteam hingegen kümmert sich nie darum, zu verstehen, wie die Anwendung funktioniert, welche Abhängigkeiten sie hat oder was mit der Arbeit der Entwickler zu tun hat . Mit DewOps wäre diese Barriere überwunden, und beide Teams würden sich einig sein, dass sie tatsächlich zusammenarbeiten Sie beginnen jetzt zu glauben, dass sie tatsächlich ein Team sind. Wenn es jemanden gibt, dem man bei einem Problem die Schuld geben kann, dann kann man niemandem außer sich selbst die Schuld geben Sie werden die Probleme gemeinsam als eine Einheit lösen gemeinsam als eine Tatsächlich gibt es in bestimmten Organisationen kein separates Entwickler - und Betriebsteam. Sie mögen sich selbst als Entwickler bezeichnen, aber sie erledigen in Wirklichkeit sowohl die Aufgaben der Entwickler als auch der IT-Abteilung. Nun, das ist der Mindset-Aspekt von DevOps. Lassen Sie uns nun über einige der kulturellen Philosophien und Praktiken von DevOps sprechen kulturellen Philosophien und DevOps fördert eine offene Kommunikation und Zusammenarbeit zwischen den Teams sowie den Wissensaustausch zwischen den Entwickler könnten also eine Sitzung zum Wissensaustausch mit dem Ops-Team abhalten und umgekehrt, OpStem könnte eine Sitzung zum Wissensaustausch mit dem Entwicklungsteam Regelmäßige Treffen mit funktionsübergreifenden Teams wie dem Testteam, Sicherheitsteam usw. Tatsächlich hat sich Optim on vor DevOps nie die Mühe gemacht, an der Entwicklertreffen teilzunehmen Aber jetzt sind sie tatsächlich am gesamten Produktlebenszyklus beteiligt , von der Erfassung der Anforderungen an. Tatsächlich nehmen sie auch an dem Treffen teil, um die Anforderungen zu erörtern. Erweiterung ihrer Fähigkeiten. Entwickler könnten also einige der Betriebsfähigkeiten erwerben und umgekehrt. Hoppla, das Team erwirbt einige der Fähigkeiten von Entwicklern. Einsatz von Tools für die Zusammenarbeit, über die wir gleich sprechen werden. Eine Sache, die ich erwähnen sollte, ist, dass DevOps nicht in jeder Organisation auf die gleiche Weise praktiziert wird Abhängig vom Umfang des Projekts und der Art der verwendeten Technologien können sich DevOp-Praktiken und -Tools unterscheiden 5. 0104 DevOps-Umgebungen und Tools: Entwickler würden eine Dev-Registrierung benötigen ihre Änderungen zu testen oder für ihre In ähnlicher Weise würde das Testteam eine Testregistrierung benötigen , um die Anwendung gründlich zu testen Und ebenso würde IT OpStam auch Staging oder die Registrierung für die Produktion benötigen , um die Anwendung bereitzustellen . Um all diese Anmeldungen zu erhalten , bräuchten wir wahrscheinlich Server. Früher haben wir Server beschafft und sie selbst gewartet. Aber heutzutage verwenden wir Cloud-Dienstanbieter wie AWS Azure GCP Stellen Sie Infrastruktur als Service bereit, was bedeutet, dass sie das für uns erledigen, anstatt dass wir die Server warten , und sie werden Ressourcen als Dienste wie RAM, CPU, Festplatte usw. bereitstellen als Dienste wie RAM, CPU, Festplatte usw. Der Vorteil eines Cloud-Dienstanbieters besteht darin, dass er skalierbarer, sicherer, zuverlässiger und kostengünstiger ist als Kauf physischer Server und deren Wartung selbst Beim Aufbau einer Infrastruktur geht es nicht nur darum, eine Reihe virtueller Maschinen zu starten. Wir müssen uns auch um die Einrichtung der Netzwerkkonfigurationen, das Anhängen von Speichervolumes und sogar die Konfiguration anderer notwendiger Dienste wie Datenbanken usw. kümmern die Einrichtung der Netzwerkkonfigurationen, das Anhängen von Speichervolumes und sogar Konfiguration anderer notwendiger Dienste . also eine sehr herausfordernde und zeitaufwändige Aufgabe, die Infrastruktur für alle Teams einheitlich zu erstellen die Infrastruktur für alle Teams einheitlich ist also eine sehr herausfordernde und zeitaufwändige Aufgabe, die Infrastruktur für alle Teams einheitlich zu erstellen, ohne einen Fehler zu machen , ohne einen Um dieses Problem zu lösen, haben wir Terraform. TerraForm bietet Infrastruktur als Code an, was bedeutet, dass Sie damit Infrastruktur erstellen können, indem Sie Infrastruktur erstellen Sie können beispielsweise Code schreiben, der besagt, dass Sie N Server mit so und so RAM und so und so Festplatte benötigen der besagt, dass Sie N Server mit so und so RAM , und genau das wird er tun Es ermöglicht uns, ähnliche und konsistente Anmeldungen für alle Teams zu erstellen alle Teams Sie können sogar dieselbe Registrierung reproduzieren, indem Sie das Skript erneut ausführen Sobald Sie die Infrastruktur oder die Server haben, wollen wir als Nächstes das Betriebssystem installieren Jetzt stellen uns all diese Cloud-Dienstanbieter ein fertiges VM-Image zur Verfügung, das mit dem Betriebssystem geliefert wird. wir also die Watcher-Computer mit Terraform starten, können wir dieses Image so auswählen , dass die Infrastruktur oder die Server zusammen mit dem Betriebssystem erstellt werden zusammen mit dem Alternativ können Sie auch ein Konfigurationsmanagement-Tool wie NZB verwenden , um Betriebssystem auf den Servern zu installieren Wir werden gleich über Ansib sprechen. Jetzt haben wir die Infrastruktur und das Betriebssystem. Technisch gesehen können wir die Anwendung jetzt bereitstellen und zum Laufen bringen. Als Mitglied des DO-Teams können Sie das ganz einfach tun, da Sie eine technische Person sind. Sie kennen alle Bibliotheken, Abhängigkeiten und Konfigurationen, die für die Ausführung der Anwendung erforderlich sind. Wenn Sie jedoch über einige der technisch nicht versierten Personen sprechen , z. B. aus dem Testteam oder dem IT-Betriebsteam, wissen diese nicht, wie die Anwendung bereitgestellt wird, und verlassen sich daher auf Entwickler, um die Anweisungen zu erhalten. Und wir haben bereits über die Konsequenzen dieses Ansatzes gesprochen . Wenn das DO-Team einen Bereitstellungsleitfaden zur Verfügung stellt, kann es vorkommen , dass der Bereitstellungsleitfaden nicht genügend Anweisungen enthält. Oder es kann vorkommen, dass das Testteam oder das Ops-Team diese Anweisungen nicht genau so umgesetzt haben diese Anweisungen nicht genau so umgesetzt , wie sie sein sollten. Anweisungen genau so , wie sie sein sollten. Und das würde dazu führen, dass die Anwendung nicht wie erwartet funktioniert, und es würde letztendlich dazu führen dass das Spiel verzögert wird, und so weiter. Um dieses Problem zu lösen, haben wir jetzt Docker Anstatt die Anwendung also direkt auf dem Betriebssystem bereitzustellen, direkt auf dem Betriebssystem indem wir Software, Konfigurationen usw. installieren oder den anderen Teams den Bereitstellungsleitfaden zur Verfügung stellen, werden wir jetzt ein sogenanntes Docker-Image erstellen Ein Docker-Image ist im Wesentlichen eine Kombination aus Code, Laufzeitbibliotheken Es ist eigentlich ein eigenständiges Paket , das alle notwendigen Abhängigkeiten, Bibliotheken und Dateien enthält , die zum Ausführen der Anwendung erforderlich sind Und mit diesen Dockerimages können wir Container in verschiedenen Umgebungen einrichten Um nun Container aus diesen Images zu erstellen, benötigen wir eine Plattform, die dies unterstützt, und hier kommt die Docker-Plattform Wir werden die Docker-Plattform auf dem Betriebssystem installieren , und jetzt könnten wir Container oder die Dockery-Images erstellen Ein Docker-Container ist im Wesentlichen eine Laufzeitinstanz eines Wenn Sie mit der VMware-Technologie vertraut sind, entspricht Docker Image VM Snapshot, und Docker Container entspricht einer laufenden Version von Me Im Gegensatz zu einer virtuellen Maschine sind Docker-Images jedoch Docker-Images Es wird nicht mit einem Betriebssystem geliefert. Stattdessen würde es das Host-Betriebssystem verwenden. Wie dem auch sei, das wird ein Thema einer anderen Vorlesung sein. Im Allgemeinen haben wir vielleicht nicht nur ein Dockery-Image, das die gesamte Anwendung enthalten würde Wenn Sie der Microsovice-Architektur folgen, bei Ihre Anwendung in mehrere kleinere Module aufgeteilt wäre , könnten Sie am Ende Hunderte von Dockery-Images haben Diese Docker-Images manuell zu verwalten ist eine schwierige Aufgabe, und aus diesem Grund bieten wir Artefakt-Repository-Lösungen wie Nexus und aus diesem Grund bieten wir Artefakt-Repository-Lösungen wie Nexus oder Docker Hub an. Nexus fungiert als zentrales Repository in dem Entwicklungsteams Softwareartefakte wie Dockery Images speichern, gemeinsam nutzen oder abrufen können gemeinsam nutzen oder abrufen Softwareartefakte Im Grunde ermöglicht es den einfachen Austausch, Zusammenarbeit zwischen Teams und sogar die Versionskontrolle von Artefakten innerhalb der Entwicklungsteams oder im gesamten Unternehmen Und verschiedene Teams in der Organisation werden die dunkleren Bilder von diesen Plattformen auswählen und aus diesen Bildern Container erstellen. Am Ende laufen vielleicht Hunderte von Containern , aber wenn so viele Container laufen, wird es wirklich schwierig, sie manuell zu verwalten, und hier kommt Kubinidis ins Spiel Im Grunde bietet es eine Plattform für die Container-Orchestrierung, wodurch es sehr einfach ist, die Docker-Container von einem einzigen Dashboard aus bereitzustellen, zu skalieren oder zu verwalten Ohne Kubintis ist es wirklich unmöglich, so viele Container zu verwalten Bisher haben wir eine konsistente Teilnehmerzahl in allen Teams Wir haben die Infrastruktur, das Betriebssystem und wir haben sogar die Anwendung zum Laufen Was ist nun, wenn ich bei diesen Registrierungen eine Software installieren oder aktualisieren oder eine Konfiguration ändern oder eine Konfiguration Nun, wir können uns nicht in jedes System einloggen und das manuell machen. Es ist sehr zeitaufwändig und fehleranfällig und wäre sehr inkonsistent Um genau dieses Problem zu lösen, haben wir Tools wie Azb Chef Mit AZB können Sie verschiedene Aufgaben wie die Bereitstellung der Anwendung, die Installation einer Software, das Ändern einer Konfiguration usw. automatisieren verschiedene Aufgaben wie die Bereitstellung der Anwendung, die Installation einer Software, Ändern einer Konfiguration usw. Während Docker es Ihnen ermöglicht, eine isolierte Laufzeitregistrierung mit Anwendungscode, Abhängigkeiten usw. zu erstellen eine isolierte Laufzeitregistrierung , arbeitet NZB auf der anderen Seite auf dem vorhandenen System, um verschiedene Aufgaben auf dem Remote-System auszuführen Wir können NZB verwenden, um das Betriebssystem und sogar die Docker-Plattform zu installieren das Betriebssystem und sogar die Docker-Plattform Dies sind einige der Tools, die in DevOps zur Erstellung der Registrierung verwendet werden DevOps zur Erstellung Wir haben auch eine Reihe anderer Tools, und wir werden darüber sprechen, wenn wir über die Phasen von DevOps sprechen, das gleich als Nächstes kommt 6. 0105 DevOps-Phasen und ihre Tools: Lassen Sie uns über die verschiedenen Phasen von DevOps sprechen und auch die verschiedenen Arten von Tools verstehen , die in jeder dieser Phasen verwendet werden Zunächst haben wir die Planungsphase, es im Wesentlichen darum geht , die Projektanforderungen zu definieren , die Ziele festzulegen, den einzelnen Mitarbeitern Kapazitäten und zu entscheiden, wer was tun wird usw. Und hier könnten wir diese Tools verwenden. Wir benötigen ein Projektverfolgungstool wie zum Beispiel Jira, das eines der beliebtesten Tools zur Nachverfolgung des Projekts ist der beliebtesten Tools zur Nachverfolgung des Projekts Hier könnten wir Benutzerstorys, Bugfixes usw. verfolgen. Und dann haben wir Tools für die Zusammenarbeit wie Slack, Confluence, Google Docs, Microsoft Teams usw. für die Nachrichtenübermittlung zwischen den Mitarbeitern oder zur Verwaltung von Anforderungen, zum Wissensaustausch, zur teamübergreifenden Zusammenarbeit Confluence ist wie Wikipedia für eine Organisation. Als Nächstes haben wir die Codierungsphase, in der Entwickler den Code natürlich schreiben und überprüfen würden Sie werden die Qualität und die Einhaltung der Codierungsstandards sicherstellen Einhaltung der Codierungsstandards Und hier werden sie Versionskontrollsysteme wie Git und Code-Repositorys wie GitHub, Bitbucket, GitLab usw. verwenden Git und Code-Repositorys wie GitHub, Bitbucket, GitLab Und sie tendieren in der Regel dazu, der testgetriebenen Entwicklung zu folgen , indem sie J-Einheiten schreiben oder statische Codeanalysen mit Tools wie Sonar Cube durchführen oder statische Codeanalysen mit Tools statische Codeanalyse würde bedeuten , dass wir den Quellcode auf Qualität, Zuverlässigkeit und Sicherheit analysieren würden , ohne den Code ausführen zu müssen Ganz zu schweigen davon, dass Entwickler, damit sie an ihren täglichen Aktivitäten arbeiten können, eine Registrierung benötigen, und wir können diese Registrierung mit all den Technologien erreichen, über die wir über die Als Nächstes haben wir die Erstellungsphase, wir möglicherweise einige CICD-Tools Wir werden in der kommenden Vorlesung ausführlicher über CICD sprechen kommenden Vorlesung ausführlicher Aber eines der beliebtesten Tools für CICD ist Jenkins. Wir haben auch andere Tools wie Circle CI oder Gitlab CICD, die Im Rahmen der Buildphase würde Jenkins tatsächlich einige der zusätzlichen Tools wie Maven Gradle verwenden , um ein Projekt so zu erstellen, dass wir ein Artefakt oder ein bereitstellbares Artefakt erhalten würde Jenkins tatsächlich einige der zusätzlichen Tools wie Maven Gradle verwenden, um ein Projekt so zu erstellen, dass wir ein Artefakt oder ein bereitstellbares Artefakt erhalten . Jenkins wird auch ein Docker-Image mithilfe der Docker-CLI erstellen. Damit brauchen wir natürlich einen Ort zum Speichern der Images, und dort haben wir Nexus und Docker Hub, um die Artefakte zu hosten und zu verwalten Als nächstes haben wir die Testphase. Hier würden wir die Anwendung gründlich testen . Hier führen wir Regressionstests durch und stellen sicher, dass neue Funktionen keine der vorhandenen Wir führen Akzeptanztests durch. Wir führen auch Sicherheits- und Schwachstellenanalysen durch. Wir führen Leistungstests, Konfigurationstests usw. durch. Selenium ist eines der beliebtesten Tools zur Automatisierung des Testprozesses der Anwendung Apache Jometer ist eines der beliebtesten Tools zur Durchführung von Leistungstests Und noch einmal, um Dinge zu testen, brauchen wir eine Testumgebung , und hier werden wir wieder sehen, wie all diese Technologien ins Spiel kommen. Über all das haben wir bereits früher gesprochen. Als Nächstes haben wir die Bereitstellungsphase , in der wir Jenkins verwenden werden, um den Prozess der Bereitstellung des Artefakts oder speziell des Docker-Images in der Produktionsumgebung zu automatisieren Artefakts oder speziell des Docker-Images in der Produktionsumgebung . Sobald also alles getestet ist und sichergestellt ist, dass alles wie erwartet funktioniert, wählt der Jenkins das Artefakt automatisch aus artifactory-Umgebungen wie Nexus oder Docker Hub aus und stellt es in der Staging - oder Produktionsumgebung bereit wählt der Jenkins das Artefakt automatisch aus artifactory-Umgebungen wie Nexus oder Docker Hub aus und stellt es in der Staging - oder Produktionsumgebung bereit. Wir werden uns noch einmal alle Technologien ansehen, die uns bei der Erstellung der Registrierung helfen werden. Als Nächstes haben wir die Betriebsphase. Sobald die Software bereitgestellt ist, würde das Betriebsteam seine Aufgabe erledigen, die Infrastruktur zu verwalten, alle Probleme zu beheben und die Anwendung zu überwachen. Ihr Hauptaugenmerk liegt auf Aufrechterhaltung einer stabilen und zuverlässigen Registrierung, eine hohe Verfügbarkeit, Leistung und Sicherheit , Leistung und Und als Nächstes folgt die Überwachungsphase, die das Sammeln und Analysieren von Metriken und Protokollen, die Überwachung der Anwendungsleistung, des Zustands und der Ressourcennutzung usw. umfasst Analysieren von Metriken und Protokollen, die Überwachung der Anwendungsleistung, des Zustands . Im Grunde wird das Betriebsteam alles überwachen, und wenn es Probleme findet, wird es diese an die zuständigen Teams weiterleiten Nagios und Prometios sind einige der beliebtesten Tools für die Überwachung, und Dynatrace und App Dynamics sind einige Als nächstes kommt die Lernphase. Und hier sammeln wir im Grunde Feedback von Benutzern, Stakeholdern und Monitoring-Tools um Verbesserungen, Bugfixes oder sogar die Einführung neuer Funktionen vorzuschlagen, mit dem Ziel, die Software zu verfeinern und zu erweitern . Der gesamte Zyklus wiederholt sich nun bereits in der Planungsphase Es ist ein kontinuierlicher Prozess, und neue Versionen würden für immer erscheinen, zumindest bis zu dem Zeitpunkt, an dem das Projekt aufgegeben wird Und das ist der Grund, warum das DevOps-Logo wie ein Unendlichkeitssymbol aussieht , weil dieser Prozess ewig andauern würde und die Software sich jedes Mal weiterentwickeln und verbessern Ein wichtiger Punkt, den ich hier ansprechen möchte den ich bereits erwähnt habe, ist, dass DevOps nicht in jeder Organisation auf die gleiche Weise praktiziert Die Tools und Methoden würden sich je nach Projekt unterscheiden Aber was wir bisher besprochen haben, sind die beliebtesten. Wenn Sie sich nicht sicher sind, was Sie lernen sollen, dann lernen Sie diese beliebten, die ich erwähnt habe. Als Nächstes werden wir über das am meisten hervorgehobene Wort in DevOps sprechen am meisten hervorgehobene Wort in DevOps Kontinuierlich. Ich sehe dich als Nächstes. 7. 0106 Continuous Integration Continuous Delivery: Traditionell haben Entwickler an der Funktion oder Bfix gearbeitet und diese Änderungen dann in ein zentrales Code-Repository wie GitHub, Bitbucket, GitLab übertragen Code-Repository wie GitHub, Bitbucket, GitLab Bitbucket Ich gehe davon aus, dass Sie mit diesen Tools nicht vertraut sind, daher werde ich keine der damit verbundenen Terminologien verwenden der damit verbundenen Terminologien Aber im Grunde würden Entwickler ihre Änderungen einbringen, und erst am Ende des Entwicklungszyklus würden all diese Codeänderungen zusammengeführt werden? Mit anderen Worten, all diese Codeänderungen würden zusammengeführt oder integriert und zu einem Teil der Hauptcodebasis gemacht. Sobald dies erledigt ist, gehen wir unter der Annahme, dass es keine Konflikte gibt , zur nächsten Phase , in der das Testteam alle Änderungen testet , die Anwendung bei der Testregistrierung gründlich testet und davon ausgeht, dass alles gut gelaufen ist und das Testteam keine Probleme gefunden hat, was sehr unwahrscheinlich ist, werden wir die Anwendung bereitstellen auf die Anwendung bereitstellen auf das Staging oder die Registrierung in der Produktionsumgebung . Dies ist jedoch das beste Szenario, aber aller Wahrscheinlichkeit nach werden Sie die Sie werden Integrationsprobleme denn wenn Sie so viele Änderungen auf einmal zusammenführen , besteht die Möglichkeit, dass Sie auf Konflikte stoßen, was bedeutet, dass möglicherweise mehr als ein Entwickler an demselben Code gearbeitet hat, und diese Konflikte müssen und diese Konflikte müssen gelöst werden, bevor Sie fortfahren können. Oder es kann vorkommen , dass Änderungen, die von einem Entwickler vorgenommen wurden, negative Auswirkungen auf Änderungen haben , die von einem anderen Entwickler vorgenommen wurden. Es ist auch sehr schwierig , die Probleme nachzuverfolgen denn wenn Sie so viele Änderungen zusammenfügen, das Problem tatsächlich verursacht hat, falls Sie ein Problem finden ist es wirklich schwierig zu wissen, welche bestimmte Änderung . Daher wird es schwieriger, die Konflikte zu lösen und die Hauptursache von Problemen zu identifizieren , was zu potenziell zeitaufwändigen und fehleranfälligen Integrationsbemühungen führen kann zeitaufwändigen und fehleranfälligen Integrationsbemühungen W, wenn das Testteam ein kritisches Problem feststellt , kann dies sogar zu einer Verzögerung der Veröffentlichung führen, und selbst wenn der Feedback-Zyklus länger ist, werden Entwickler erst in und selbst wenn der Feedback-Zyklus länger ist, der Endphase des Entwicklungszyklus von Konflikten oder Fehlern erfahren , was zu längeren Lösungszeiten führen und die Fähigkeit beeinträchtigen kann , das Problem rechtzeitig zu beheben. Bei der Entwicklung werden wir jedoch einen anderen Ansatz verfolgen, und so läuft es ab Nach der Planungsphase würden die Entwickler also mit dem Programmieren beginnen. Jeder Entwickler würde seine Änderungen in das zentrale Repository einbringen , dann haben wir Jenkins, ein CSCDTOL, das ständig nach neuen Kometen im Repository Ausschau hält. Sobald ein neuer Commit identifiziert wurde, leitet Jenkins einen Build-Prozess ein, um die Artefakte oder das Docker-Image zu erstellen, das dann automatisch in der Testumgebung bereitgestellt leitet Jenkins einen Build-Prozess ein, um die Artefakte oder das Docker-Image zu erstellen, das dann automatisch in der Testumgebung bereitgestellt wird. leitet Jenkins einen Build-Prozess ein, um die Artefakte oder das Docker-Image zu erstellen, das dann automatisch in der Testumgebung bereitgestellt wird. Jenkins wird außerdem automatische Merit-Tests auslösen , um die Anwendung und die Änderungen gründlich zu testen Und sobald dies erledigt ist, wird Jenkins die Prüfer benachrichtigen , damit sie die Codeänderungen überprüfen Die Prüfer werden die Codeänderungen prüfen, erforderliches Feedback geben, Verbesserungen vorschlagen usw., und die Entwickler werden auf das Feedback eingehen, das sie während der Codeüberprüfung sie während der Codeüberprüfung erhalten haben Sie nehmen alle erforderlichen Änderungen vor, fügen Klarstellungen oder erörtern alternative Ansätze. Dieser iterative Prozess wird fortgesetzt, bis die Codeänderungen den erforderlichen Qualitätsstandards entsprechen Sobald alles gut und gut ist, sobald die Prüfer den Code genehmigt haben, gehen wir zur nächsten Phase über, in der wir all diese Änderungen zusammenführen, oder mit anderen Worten, wir werden all diese Änderungen in die Hauptcodebasis integrieren die Hauptcodebasis Und bevor wir die Änderungen tatsächlich zusammenführen, haben wir in Jenkins möglicherweise die Aufgabe, alle zusätzlichen Tests oder Validierungen durchzuführen , bevor wir die haben wir in Jenkins möglicherweise die Aufgabe, alle zusätzlichen Tests oder Validierungen durchzuführen, bevor wir die Änderungen zusammenführen. Nach dem Zusammenführen der Änderungen oder Integration der Änderungen in die Hauptcodebasis können wir den Prozess der Implementierung dieser Änderungen in der Produktions- oder Staging-Umgebung einleiten Implementierung dieser Änderungen der Integration der Änderungen in die Hauptcodebasis können wir den Prozess der Implementierung dieser Änderungen in der Produktions- oder Staging-Umgebung einleiten. Und wieder einmal wird Jenkins die Arbeit für uns erledigen. Es wird das Projekt erstellen, die erforderlichen Artefakte in der Staging- oder Produktionsumgebung bereitstellen der Staging- oder Produktionsumgebung und die Anwendung zum Laufen bringen Jetzt nennen wir den Prozess, den Code beizutragen , automatisierte Tests durchzuführen und schließlich die Änderungen zusammenzuführen oder die Änderungen in die Hauptcodebasis zu integrieren , das was wir als kontinuierliche Integration bezeichnen Oder genauer gesagt, wir haben auch eine kontinuierliche Entwicklung, bei der die Entwickler kontinuierlich Verbesserungen vornehmen und neue Änderungen einführen, und der Prozess des kontinuierlichen Testens der Änderungen mit automatisierten Tests ist kontinuierliches Testen Was wir früher manuell gemacht haben , sind jetzt eine Reihe automatisierter Tests. Und der Prozess, bei dem die Änderungen in die Staging- oder Produktionsumgebung übertragen werden, wird als Continuous Delivery bezeichnet Wir haben auch oft den Begriff Continuous Deployment verwechselt Begriff Continuous Deployment Der Unterschied zwischen Continuous Delivery und Continuous Deployment ist sehr einfach. Wenn wir manuell eingreifen , sodass Jenkins den Code aus der Hauptcodebasis auswählen und die Anwendung schließlich in der Produktionsumgebung bereitstellen kann , spricht man von Continuous Delivery Wenn wir diesen Prozess automatisieren, was bedeutet, dass Jenkins unmittelbar nach der Integration der Änderungen an der Haupt-Codebasis der Integration der Änderungen an der Haupt-Codebasis den Code automatisch aufnimmt und in der Produktionsumgebung bereitstellt , spricht man von kontinuierlicher Bereitstellung , spricht man von Und sobald die Anwendung bereitgestellt ist, würde das Ops-Team eine kontinuierliche Überwachung durchführen, und der gesamte Prozess wiederholt sich als Teil des DevOps-Lebenszyklus Im Gegensatz zu herkömmlichen Ansätzen, bei denen wir die Software in einem großen Batch verbessern, im Fall von DevOps werden Updates im Fall von DevOps kontinuierlich Stück für Stück vorgenommen, sodass der Softwarecode an die Kunden geliefert werden kann , sobald er fertiggestellt und getestet ist Da wir nicht viele Änderungen auf einmal integrieren, werden wir natürlich nicht so viele Konflikte haben, nicht so viele Konflikte haben, und da die Tests fast unmittelbar nach dem Abgeben eines Kommentars durchgeführt werden , würden Entwickler sofort Feedback erhalten, würden Entwickler sofort Feedback erhalten wenn es Probleme mit dem Code gibt, sodass sie genügend Zeit haben, das Problem zu lösen , ohne zu kontaktieren das Ende des Entwicklungszyklus. Also jedes Mal, wenn jemand einen Kometen erzeugt, werden wir den gesamten Prozess wiederholen , weil alles ziemlich automatisiert ist, das wird sehr schnell gehen. Jenkins steht im Mittelpunkt des gesamten Prozesses und verbindet alle Punkte miteinander Als Nächstes werden wir kurz zusammenfassen, was wir mit D Wops erreicht haben 8. 0107 DevOps-Vorteile: Lassen Sie uns über einige der Vorteile von DeWAPS sprechen. verbesserte Zusammenarbeit und verbesserte Kultur, offensichtlich mit einer veränderten Denkweise und Einbeziehung bestimmter kultureller Philosophien und Praktiken sowie kollaborativer Tools, sowie kollaborativer Tools, haben wir die Zusammenarbeit zwischen funktionsübergreifenden Teams und die allgemeine Kultur erheblich verbessert zwischen funktionsübergreifenden Schnellere Innovation und Problemlösung mit viel Schwerpunkt auf Automatisierung und kontinuierlicher Integration und kontinuierlicher Bereitstellung haben wir die Zeit für die Veröffentlichung der Software erheblich reduziert , und aufgrund dieser schnelleren Iterationen können wir schneller innovieren und Probleme auch rechtzeitig lösen. Stabilere Betriebsanmeldungen . Durch den Einsatz verschiedener Tools und Technologien konnten wir für stabile Anmeldungen in allen Teams sorgen Anmeldungen in allen Wenn die Anwendung also in einer Registrierung funktioniert, besteht die Möglichkeit, dass sie auch in einer anderen Umgebung funktioniert, ohne Lassen Sie uns Probleme und Ausfallzeiten bewältigen. Durch die konsequente Durchführung häufiger und regelmäßiger Automerit-Tests und die Aufrechterhaltung stabiler und zuverlässiger Umgebungen können wir die Wahrscheinlichkeit verringern, dass stabiler und zuverlässiger Umgebungen können wir die Wahrscheinlichkeit verringern, Probleme oder Ausfallzeiten während der Produktion auftreten Probleme oder Ausfallzeiten während der Produktion Durch die Verwendung verschiedener Tools wie Ansibl für das Konfigurationsmanagement und durch den Einsatz von Überwachungstools wie Nagios und durch die bessere Zusammenarbeit mit anderen Teammitgliedern haben wir auch die allgemeine betriebliche Effizienz verschiedener Tools wie Ansibl für das Konfigurationsmanagement und durch den Einsatz von Überwachungstools wie Nagios und durch die bessere Zusammenarbeit mit anderen Teammitgliedern verbessert . Kostengünstig. Da wir viel Wert auf Automatisierung legen, was früher manuell oder jetzt automatisiert wurde, und auch durch den Einsatz von Cloud-Dienstanbietern werden wir die Kosten deutlich senken. Und aus diesem Grund müssen Sie ernsthaft in Betracht ziehen , Ihre Fähigkeiten auf DevOps auszuweiten, wenn Sie aus dem Bereich Testing oder IT-Betrieb kommen aus dem Bereich Testing oder IT-Betrieb müssen Sie ernsthaft in Betracht ziehen , Ihre Fähigkeiten auf DevOps auszuweiten, wenn Sie aus dem Bereich Testing oder IT-Betrieb Kundenzufriedenheit. Wenn Sie DevOps-Methoden anwenden, führt dies angesichts all ihrer Vorteile letztendlich natürlich zu einer besseren Kundenzufriedenheit, da sie nicht so lange auf Releases warten müssen, was sich natürlich in da sie nicht so lange auf Releases warten müssen, einem besseren Umsatz und einem besseren Ruf niederschlägt besseren Umsatz und einem besseren Es hilft Ihnen auch dabei, Ihren Mitbewerbern auf dem Markt immer einen Schritt voraus Ihren Mitbewerbern Ich hoffe, Sie haben das Gesamtbild von DevOps verstanden . Ich sehe dich als Nächstes