configuration management devops practices
Was ist Konfigurationsmanagement in DevOps-Praktiken?
Konzept von Kontinuierliches Testen in DevOps wurde in unserem vorherigen Tutorial ausführlich erklärt.
Das wichtigste Highlight des Konfigurationsmanagements in DevOps ist Folgendes:
- Infrastruktur als Code
- Konfiguration als Code
Muss durchlesen => Exklusive DevOps-Tutorialserie
Wie viele E-Mail-Anbieter gibt es?
In der DevOps-Praxis gibt es zahlreiche Vorteile von 'Infrastruktur als Code' und 'Konfiguration als Code'.
-
- Konfigurationen sind versioniert
- Automatisiert und standardisiert
- Entfernt die Abhängigkeit
- Fehlerfreie Infra-Setups
- Verbessert die Zusammenarbeit zwischen dem Operations- und dem Entwicklungsteam
- Konfigurationsdrift korrigieren
- Infrastruktur als flexible Ressource behandeln
- Automatisierte Skalierung der Infrastruktur
- Aufrechterhaltung der Konsistenz in den Setups
VIDEO Teil 4 Block 1: Konfigurationsmanagement- 23 Minuten 7 Sekunden
Transkript:
In diesem Teil werden wir etwas darüber lernen Konfigurationsmanagement, Release-Management und Überwachung der Anwendungsleistung in DevOps.
In Block 1 konzentrieren wir uns auf das Konfigurationsmanagement und verstehen, was Konfigurationsmanagement ist und wie es sich in DevOps und den traditionellen Methoden unterscheidet.
Lassen Sie uns zunächst wissen, was Konfigurationsmanagement ist.
Das Konfigurationsmanagement ist, wie der Name selbst erklärt, nichts anderes als das Verwalten aller Konfigurationen der Umgebungen, in denen die Softwareanwendung gehostet wird.
Wie wir wissen, gibt es in DevOps im gesamten SDLC unterschiedliche Umgebungen, angefangen bei Unit-Tests, Integrationstests, Systemtests, Abnahmetests und Endbenutzertests.
In meinen früheren Tutorials habe ich auch erklärt, dass die für diese Tests eingerichteten Umgebungen zunehmend komplexer werden, wenn sie sich in Richtung Vorproduktion und Produktionsumgebung bewegen.
Konfigurationsmanagement ist also im Grunde der automatisierte Prozess zum Verwalten aller Konfigurationen jeder dieser Umgebungen.
Was ist dann der Unterschied zwischen herkömmlichem Konfigurationsmanagement und DevOps-Konfigurationsmanagement?
Bei unseren herkömmlichen Konfigurationsverwaltungsmethoden verwaltete das Team diese Konfigurationen verschiedener Umgebungen über eine formale Dokumentation, wobei jede der Konfigurationen in den Dokumenten aufgezeichnet wurde und das Konfigurationsteam oder der Manager die Versionskontrolle dieser Dokumente übernahm.
Und wenn sich Änderungen ergeben, übernimmt er auch die Verantwortung für die Einrichtung der Umgebung und die manuelle Verwaltung der Konfigurationen
In DevOps sind normalerweise alle diese Konfigurationsverwaltungsprozesse ziemlich gut automatisiert und die Konfigurationen werden in Form von Code oder Skripten gekapselt und über das Versionskontrolltool gesteuert.
In diesem Zusammenhang können wir davon ausgehen, dass das Operations-Team in die Entwicklung integriert ist, um die Umgebungen über das Tool zur Steuerung der einzelnen Versionskontrolle zu verwalten.
Das wichtigste Highlight des Konfigurationsmanagements in DevOps ist also Folgendes:
-
-
- Infrastruktur als Code
- Konfiguration als Code
-
Was bedeutet eigentlich 'Infrastruktur als Code'? Es definiert die gesamte Umgebungsdefinition als Code oder Skript, anstatt sie in einem formalen Dokument aufzuzeichnen.
Was beinhaltet dann die Umgebungsdefinition? Die Umgebungsdefinition umfasst im Allgemeinen das Einrichten von Servern, das Konfigurieren von Netzwerken und das Einrichten anderer Computerressourcen, die Teil der eingerichteten IT-Infrastruktur sind. Alle diese Details würden also als Datei oder in Form eines Codes geschrieben und in das Versionskontroll-Tool eingecheckt.
Dieses Skript oder dieser Code, der in die Versionskontrolle eingecheckt wird, wird zur einzigen Quelle für die Definition der Umgebung oder sogar für die Aktualisierung dieser Umgebungen.
Nur um eine einfache zu geben Beispiel Wenn wir der spezifischen Umgebung einen Server hinzufügen müssen, müssen wir diese Informationen lediglich in den Umgebungsskripten aktualisieren und die Übermittlungspipeline ausführen, anstatt manuell eine neue Umgebung mit dem hinzugefügten Server zu erstellen oder zu suchen oder zu suchen die Hilfe der Systemadministratoren, um dies zu tun.
Das Schöne daran ist, dass der Entwickler oder Tester kein Systemadministrator sein muss, um seine Server für Entwicklungs- oder Testaktivitäten einzurichten.
Die in DevOps eingerichtete Infrastruktur wird also vollständig automatisiert und folgt im Wesentlichen dem Skript, das zur Versionskontrolle eingecheckt wird, beginnend mit der Installation der Server, deren Konfiguration und Installation des Betriebssystems, bis die Kommunikationskanäle dieser Instanzen mit dem bereitgestellten eingerichtet sind Software.
Was ist die Konfiguration als Code?
Die Konfiguration als Code ist nichts anderes, als alle Konfigurationen der Server oder anderer Ressourcen als Code oder Skript zu definieren und in die Versionskontrolle einzuchecken.
Diese Konfigurationsskripte, die in die Versionskontrolle eingecheckt werden, werden als Teil der Bereitstellungspipeline ausgeführt, um die Infrastruktur und ihre Konfigurationen automatisiert einzurichten.
Das Definieren von Konfigurationen umfasst Parameter, die die empfohlenen Einstellungen für die erfolgreiche Ausführung der Software definieren. Oder eine Reihe von Befehlen, die anfänglich ausgeführt werden müssen, um die Softwareanwendung einzurichten. Oder es können sogar Konfigurationen jeder der zu setzenden Komponenten der Software oder bestimmte Benutzerrollen, Benutzerrechte usw. sein.
Einfach Beispiel Dies wäre, die Feature-Toggles festzulegen, bei denen Standardwerte als Teil des Konfigurationsparameters eingerichtet werden.
Das Hinzufügen eines weiteren Ports zu einer Firewall wäre ein anderer Beispiel , die im Skript aktualisiert werden können, und später werden diese Skripte als Teil der Übermittlungspipeline ausgeführt.
Für die Durchführung der Infrastrukturautomatisierung auf dem Markt stehen verschiedene Tools zur Verfügung. Nur wenige von ihnen sind Chef, Puppet, Terraform usw., Chef und Puppet sind rubinbasierte Konfigurationsmanagement-Tools, während Terraform ein Provisioning-Tool ist.
Da heutzutage fast alle Anwendungen in der Cloud AWS gehostet werden, bieten sie selbst RESTAPIs an, die für diesen Zweck genutzt werden können.
Ich habe eine große Liste von Vorteilen des Konfigurationsmanagements in DevOps, anstatt die Infrastruktur und Konfigurationen als Code zu definieren.
Lassen Sie uns sie einzeln durchgehen.
Alle Konfigurationen und Infrastrukturdetails sind versioniert, was ein großer Vorteil bei der DevOps-Implementierung ist.
# 1) Dies hilft dem Team, die Änderungen an den Servern und der Konfiguration automatisiert zu verwalten, und hilft beim schnellen Debuggen, wenn etwas fehlschlägt, innerhalb kurzer Zeit und ermöglicht auch ein schnelles Zurücksetzen auf die vorherige Version, ohne die Kunden zu unterbrechen.
#zwei) Da sich diese Skripte auf dem zentralen Server befinden und jeder im Team weiß, was in jedem dieser Skripte enthalten ist und welche Änderungen in jeder dieser Versionen vorgenommen wurden. Auf diese Weise kann das Team auch zur älteren Version zurückkehren, wenn in den neuesten Versionen Probleme auftreten.
Stellen Sie sich bei einem Serverabsturz vor, wie viel Zeit für die manuelle Wiederherstellung benötigt worden wäre. Und jetzt, indem wir die Infrastruktur als Skript und Versionskontrolle definieren, können wir sofort wiederherstellen, indem wir zur früheren Version wechseln.
#3) Das Verwalten der Konfigurationen als Code verhindert auch, dass jemand versehentlich Änderungen am System vornimmt, und verhindert, dass später in der Produktion Schäden entstehen.
Da das Konfigurationsmanagement vollständig automatisiert ist, entfällt der manuelle Eingriff zum Einrichten oder Aktualisieren vollständig.
Stellen Sie sich die Auswirkungen auf Kosten, Qualität und Zeit vor, als die Mitarbeiter früher auf die Personalabteilung angewiesen waren, um diese Konfigurationen manuell durchzuführen, und wenn bestimmte Konfigurationen verpasst oder nicht wie erforderlich festgelegt wurden.
Die Automatisierung des Konfigurationsmanagements hat also nicht nur Zeit gespart, sondern auch solche menschlichen Fehler beseitigt und die Qualität verbessert. Außerdem hat der Codierungsstandard dem Team geholfen, den angegebenen Standard beim Codieren und Automatisieren zu befolgen, anstatt der Fantasie jeder Person zu folgen, die den Konfigurationsleitfaden schreibt.
Wie bereits erwähnt, haben Konfigurationen, die als Code bereitgestellt werden, die Abhängigkeit von einer einzelnen Person oder einem Team namens Konfigurationsmanager oder Konfigurationsteam beseitigt. Das Entwicklungsteam muss nicht warten, bis das Konfigurationsteam kommt, um ein Infra- oder Konfigurationsproblem zu beheben.
Oder sogar zum Einrichten der Infra und Konfigurationen, die vollständig automatisiert und versioniert sind. Jeder im Team, sei es ein Entwickler oder ein Tester, kann einen Server drehen und die Konfigurationen für seine Entwicklungs- und Testzwecke ausführen. Daher ist das Einrichten des Servers und der Konfigurationen personenunabhängig geworden.
Dies stellt auch sicher, dass nicht sowohl das Entwicklungs- als auch das QS-Team dieselben Server für ihre Aktivitäten verwenden, wie dies früher früher der Fall war.
Infrastruktur und Konfigurationen, die als gemeinsamer Code definiert sind, sowie die Automatisierung und Versionskontrolle standardisieren alle Umgebungen und Einstellungen. Dies erleichtert nicht nur den Entwicklern die Debugging-Aufgabe, sondern beseitigt auch die menschlichen Fehler, die zu fehlerfreien Infra-Setups führen. Andernfalls würde dies großen Schaden verursachen, wenn sie nicht frühzeitig erkannt werden.
Hier sehen wir deutlich die klare Zusammenarbeit zwischen Dev und Ops, bei der beide für die Durchführung des Infra-Setups auf eine einzige Quelle angewiesen sind und beide Teams aktiv an der Automatisierung und Einrichtung des gesamten Konfigurationsmanagements beteiligt sind.
Diese Zusammenarbeit zur Erreichung eines gemeinsamen Ziels fördert die Zusammenarbeit zwischen den Teams, der Entwicklung und dem Betrieb.
Konfigurationsdrift korrigieren
Was ist Konfigurationsdrift?
Kleine Unterschiede und Inkonsistenzen zwischen den Servern, die manchmal aufgrund manueller Aktualisierungen auftreten, die sich über einen bestimmten Zeitraum ansammeln, werden als Konfigurationsdrift bezeichnet.
Dies ist keine gute Situation, da diese Inkonsistenz auf den Servern bestimmte Programmdateien wie Manifest und Playbook nicht zuverlässig auf allen Servern laufen lässt und daher zu einem Automatisierungsfehler führt. Dies muss also vermieden werden, damit das Team die Automatisierung von Konfigurationen effektiv nutzen kann.
Die Verwaltung von Infrastruktur und Konfiguration als Code und Versionskontrolle hat dem Team geholfen, jegliche Art von Konfigurationsabweichungen zwischen verschiedenen Umgebungen oder zwischen Entwicklungs- und Produktions-Setups zu vermeiden oder zu korrigieren, indem die Konfigurationen auf allen Servern konsistent beibehalten wurden.
Somit kann ein Team am besten von ähnlichen Konfigurationskonfigurationen in der Entwicklung wie in der Produktion überzeugt werden. Dies hilft ihnen auch, die Produktionsprobleme in der Entwicklungsumgebung zu simulieren.
Dies hilft also, unerwartete Änderungen zu verhindern, die Teammitglieder in der Infra versuchen könnten, wodurch die Einrichtung möglicherweise unterbrochen wird, und das Team dazu zu zwingen, keine Änderungen an der Einrichtung vorzunehmen, es sei denn, sie sind als angemeldet einen Code zum Repository.
Durch die Bereitstellung der Infrastruktur und ihrer Konfiguration als Code konnte das Team sie als flexible Ressource verwalten, um die dynamischen Geschäftsanforderungen des Kunden zu erfüllen.
Es ist jetzt eine Art Plug and Play. Ein Team kann gezielt auf den jeweiligen Server oder das jeweilige Netzwerk zugreifen und Änderungen daran vornehmen. Es kann sich lediglich um die Aktualisierung des Bereitstellungsservers oder das Hinzufügen oder Ändern des Speichers in einem bestimmten Netzwerk oder sogar um das Aktualisieren des Betriebssystems handeln, und alles kann unabhängig als flexible Ressource aktualisiert werden.
Früher dauerte das Ändern eines Konfigurationsparameters sehr viel Zeit, insbesondere während das Aktualisieren auf allen Servern erforderlich war. Jetzt ist es nur noch ein Versuch. Aktualisieren Sie das Skript und laden Sie es in das Versionskontroll-Tool hoch.
Es besteht die Flexibilität, die vorhandene Infrastruktur vollständig zu verschrotten und eine andere vollständig aufzurufen. Die Verwaltung der Infrastruktur und Konfigurationen ist jetzt recht einfach. Dank der Cloud-basierten Lösungen konnte die Infrastruktur automatisch skaliert werden, indem die zusätzlichen Computer- oder Speicherressourcen nach Bedarf hinzugefügt und verkleinert wurden, wenn sie nicht benötigt wurden.
Dies hat die Optimierung der Ressourcennutzung basierend auf der Nachfrage ermöglicht. Wenn wir die Infrastruktur durch Vergrößern der Maschine vergrößern möchten, können wir dies sofort tun. Wenn wir skalieren oder ein anderes Setup hinzufügen oder weitere Frontends hinzufügen möchten, können wir dies in Sekundenschnelle tun, indem wir es einfach im Code aktualisieren und die automatisierte Pipeline ausführen.
Last but not least hilft die Infrastruktur, die als Code in einer kontrollierten Umgebung bereitgestellt wird, dabei, die Konsistenz der Umgebungen über verschiedene Setups hinweg aufrechtzuerhalten. Dies hilft auch beim Debuggen des Problems. Diesen Punkt habe ich bereits teilweise behandelt, während ich über Konfigurationsdrift gesprochen habe.
Das ist es und dies vervollständigt unseren Vortrag über das Konfigurationsmanagement in DevOps, was Infrastruktur und Konfigurationen als Code sind und welche Vorteile sie haben.
In unserem nächsten Tutorial werden wir diskutieren die Release-Management-Aspekte in DevOps.
PREV Tutorial | NÄCHSTES Tutorial
Literatur-Empfehlungen
- Release Management in DevOps
- DevOps-Test-Tutorial: Wie wirkt sich DevOps auf QS-Tests aus?
- Kontinuierliches Testen in DevOps
- Tutorial zum Konfigurationstest mit Beispielen
- Kontinuierliche Bereitstellung in DevOps
- Beste Open Source DevOps Tools (mit Installation und Konfiguration)
- Top 10 Tools für kontinuierliche Tests zum Testen von DevOps (Liste 2021)
- TestLodge Test Management Tool Überprüfung