Torsten Laser - IT Service Management

Artikel und Berichte für einen sicheren und stabilen IT Betrieb

Seite 2 von 6

DevOps Glossar – Teil 2

Hier folgt der zweite Teil des DevOps Glossars (der erste Teil findet sich hier). Ein einheitliches Verständnis der Begrifflichkeiten fördert und vereinfacht die tägliche Zusammenarbeit.

Continuous Deployment

Continuous Deployment ist die Automatisierung der Schritte, um Änderungen am Quellcode in definierter und wiederholbarer Art und Weise zu veröffentlichen. Dadurch wird die Vorlaufzeit für neue Features einer Software verkürzt und ermöglicht, vollautomatisiert neue Software-Releases zu veröffentlichen. Es ist kein manueller Verteilungsprozess mehr erforderlich.

Produkte wie Jenkins, Ant und Travis CI unterstützen das Continuous Deployment von Software.

Continuous Integration

Mit einer kontinuerlichen Integration meint man, das täglich mehrfach durchzuführende „Mergen“ von Code-Änderungen in die „Main Version“ des Versionkontrollsystems. Dadurch will man erreichen, dass Integrationsprobleme bereits nach geringen Code-Anpassungen erkannt werden.  Im Nachgang ist sichergestellt, dass die Entwickler immer auf der gleichen „Baseline“ des Codes arbeiten. Versionskonflikte werden so verringert oder ganz eliminiert. 

Continuous Integration profitiert vom Auftrennen der Funktionalitäten in kleinere Teile oder Aspekte, die vollständig programmiert werden und dann einfacher in die „Main Version“ übernommen werden können.

Continuous Learning

Lernen durch die bei der täglichen Arbeit gemachten Erfahrungen und die Notwendigkeit sich lebenslang weiterzubilden und die eigenen Fähigkeiten zu verbessern, wird unter dem Begriff „ContinuousLearning“ zusammengefasst.

„Continuous Learning“ kann auf drei Ebenen stattfinden:

Auf der individuellen Ebene, wo ein einzelner Mitarbeiter daran arbeitet, seine Fähigkeiten zu erweitern und zu verbessern. Das kann durch einfaches Fragenstellenerfolgen, wenn der Mitarbeiter eine Aufgabe nicht versteht oder wenn er an einer Schulung oder einem Weiterbildungsprogramm teilnimmt.

„Continuous Learning“ bezieht sich jedoch keineswegs nur auf das individuelle Lernen. Mentoring und Lehre kann ebenfalls eine Rolle in der eigenen Weiterentwicklung durch „Continuous Learning“ spielen.

Auf Team-Ebene nutzen und teilen die Team-Mitglieder ihr gemeinsames Wissen und ihre Erfahrungen, um das Team voranzubringen. Dies kann auch bedeuten, „Best Practices“ zu implementieren, die das Lernen und den Wissenstranfer erleichtern. Dazu zählen sog. Retrospektiven oder Team-Fragestunden.

Schließlich gibt es die unternehmensweite Ebene, auf der „Continuous Learning“ die Überprüfung und Erstellung von Policies und Prozessen bedeutet, um die Geschäftsziele zu erreichen. Dazu muss internes und externes Feedback von Mitarbeitern und Kunden gesammelt, zusammengetragen und ausgewertet werden.

Idempotency

Idempotency beschreibt die Möglichkeit im Konfigurationsmanagement, eine Operation oder einen Code mehrfach auszuführen, ohne unbeabsichtigte oder unerwünschte Auswirkungen. Wenn man beispielsweise auf seiner Konfigurationsmanagement-Plattform festgelegt hat, dass die Webserver den Apache installieren, wird der Apache nur genau einmal installiert, unabhängig davon, wie oft der Konfigurationsmanager gegen einen Server in dieser Gruppe ausgeführt wird.

Die meisten Tools für das Konfigurationsmanagement sind idempotent, z.B. Ansible, Chef, Puppet und Salt.

Infrastructure as Code

Hiermit ist die Möglichkeit gemeint, Infrastruktur durch maschinenlesbare Dateien zu beschreiben und damit alle Parameter eines Systems oder einer Serverumgebung eindeutig zu definieren und beliebig oft  wiederherstellen zu können.

Bei Chef heißen die Dateien Recipes, bei Puppet Manifeste.

Das Konfigurationsmanagement-Werkzeug ist in der Lage, die Parameter zu ermitteln und neu erzeugte Server mit diesen Parameter zu installieren.

Ansible, Chef, Puppet und Salt implementieren alle das Konzept von „Infrastructure as code“, um Systeme zu konfigurieren, bereitzustellen und zu warten.

Infrastructure as a Service (Iaas)

Bei der Nutzung von IaaS wird kein eigenes Rechenzentrum benötigt, auch ein Housing in einem fremdem Rechenzentrum ist nicht mehr erforderlich. Anbieter von „Infrastructure as a Service“ betreiben Hardware, Server und Speicher, der kundenspezifisch angepasst werden kann. Auf dieser Plattform lassen sich Applikationen, Websites, Datenbanken, Cloudspeicher u.ä. betreiben. Der Aufwand für das Management der Plattform, des Netzwerkes und der Server liegt beim IaaS-Anbieter. Die Anbieter haben meistens nur reine Server-Instanzen mit einer Basisinstallation eines Betriebssystems im Angebot. Darauf müssen Kunden ihre Anwendungen dann selbst installieren, konfigurieren und für eine ausreichende IT-Security sorgen.

Microservices

Unter Microservices versteht man eine Service-orientierte Architektur, die die verschiedenen Komponenten einer Applikation nur lose koppelt. Kleinere Services können vielfältiger genutzt und wiederverwendet werden als komplexe Servicestrukturen. Microservices bilden die Grundlage für das Konzept der „Continous Integration“, da Entwickler kleinere Teile einer Applikation risikoloser und schneller in die Produktion bringen können als komplexe Software-Module.

Mutable/Immutable Infrastructure

Mutable Infrastructure bezeichnet eine Infrastruktur, die aktualisiert, geändert und adaptiert werden kann. Mutable Infrastructure ist langlebig und wird nicht vollständig ausgetauscht im Falle einer Aktualisierung der darauf betriebenen Softwarekomponenten. Im Gegensatz dazu gibt es „Immutable infrastructure“, die nicht geändert wird. Stattdessen wird die Instanz oder der Container neu aufgebaut, wenn Änderungen durchzuführen sind. Die alte Instanz wird dann beendet bzw. gelöscht.

Orchestration

Das automatisierte Management von Serverlandschaften, Software oder IT-Services wird als Orchestration bezeichnet. Dazu werden vorbereitend sog. Policies definiert und später genutzt, um Workflows, Serverinstallationen, Server-Wartungen und -skalierungen, je nach Anforderung, automatisch durchführen zu können.

Bekannte Werkzeuge zur Orchestrierung sind Chef und Puppet, für die Orchestrierung von Containern wird Kubernetes oder Docker genutzt.

Provisioning

Provisioningbezeichnet sämtliche Vorbereitungen und Tätigkeiten, um einen Server bereitzustellen. Dazu gehören die Installation des Betriebssystems und der benötigten Dienste sowie Konfigurationseinstellungen und weitere Aufgaben, bevor ein Server in die Produktionsumgebung integriert wird.

Serverless

Serverlose (serverless) Architekturen erlauben es Entwicklern ihren Code direkt an einen Service abzugeben, der die erforderliche Infrastruktur bereitstellt. Serverless Architekturen nutzen Dienste wie „Backend as a service“ oder „Function as a service“ von Drittanbietern. Damit müssen sich Entwickler nur noch um ihren Code kümmern und nicht mehr um die zugrundeliegende Infrastruktur.

AWS Lambda and Azure Functions von Microsoft sind zwei populäre Serverless-Dienste.

Test-Driven Development

Hierunter versteht man einen Ansatz in der Softwareentwicklung bei dem zuerst ein Test programmiert wird, danach wird die Funktionalität programmiert und gegen den erstellten Testfall geprüft. Wenn der Testfall nicht bestanden wird, wird der Code iterativ verbessert, bis der Testfall erfolgreich durchlaufen wird. Durch dieses Vorgehen werden Entwickler ermutigt, die Anforderungen zunächst zu durchdenken und vollständig zu verstehen, bevor die erste Zeile Code geschrieben wird.

DevOps – Was ist das?

Der Begriff DevOps, mit dem agile Arbeitsmethoden in den Arbeitsalltag einziehen, beschreibt eine Kombination aus Denkweisen, Praktiken und Tools, die es Unternehmen und Organisationen ermöglichen, Anwendungen und Dienste schneller und einfacher bereitzustellen. Der Begriff bezieht sich auf einen Ansatz zur Prozessverbesserung, der hauptsächlich im IT-Betrieb, vor allem in der Systemadministration im Zusammenspiel mit der Softwareentwicklung, eingesetzt wird. Es ist ein sogenanntes Kofferwort, das sich aus den englischen Begriffen für „Entwicklung“ und „IT-Sicherheitsbetrieb“ ableitet. DevOps hat das Ziel, in den Bereichen Implementierung, IT-Sicherheitsbetrieb und Qualitätssicherung für eine effizientere und effektivere Zusammenarbeit zu sorgen. Zu diesem Zweck werden spezielle Anreize, Instrumente und Prozesse eingesetzt. DevOps richtet sich methodisch sowohl an die Technik als auch auf die Prozessebene und stellt klassische ITIL-Prozesse wie Incident Management, Change Management oder Release Management auf den Prüfstand. ITIL (IT System Infrastructure Library) beschreibt eine strukturierte Prozesssammlung von Best Practices für das Service Management von IT-Systemen. IT Service Management oder ITSM ist seit mindestens 20 Jahren als Best Practice in der IT etabliert. Es ist ein Modell, das die zuverlässige Bereitstellung von Informationstechnologie als Dienstleistung für den Kunden als Ziel propagiert.

Motivation und Entstehung

Der Ansatz entstand aus dem erkenntnistheoretischen Denken, dass standardisierte Prozesse heute nicht mehr ausreichen, um wettbewerbsfähig zu bleiben. Der Übergang dorthin erfordert einen Wandel der Kultur und der Denkweise, denn traditionelle Unternehmen haben ihre, meist vor langer Zeit, etablierten Ansätze. Die Softwareentwickler-Communities auf der einen Seite und die IT/Ops-Experten auf der anderen Seite verfolgten unterschiedliche, oft konkurrierende Ziele, gehörten verschiedenen Abteilungen an, wurden nach verschiedenen KPIs (Key Performance Indicators) bewertet und arbeiteten auf verschiedenen Etagen oder sogar in verschiedenen Gebäuden. Es bedarf eines gemeinsamen Verständnis der Aufgaben, der Akzeptanz und der guten Zusammenarbeit der Entwickler. Der Kern von DevOps ist die Überwindung der Trennlinien zwischen zwei ehemals sehr isolierten Geschäftsbereichen, der Entwicklung und dem IT-Betrieb. Das Konzept basiert auf einer Kultur der Zusammenarbeit zwischen gemeinsamen Teams. Einfache Prozesse werden mit einem DevOps-Ansatz zunehmend programmierbar und dynamisch. Er zielt darauf ab, die Vorhersehbarkeit, Effizienz, Sicherheit und Wartbarkeit von Betriebsprozessen zu maximieren. Die Auswirkungen auf den IT-Betrieb nach der Einführung von DevOps wird in einem Artikel bei Heise Developer beleuchtet.

Praxis

Der Übergang zu DevOps erfordert einen grundlegenden Wandel der Unternehmenskultur und der Denkstrukturen. Unter anderem sind die Entwickler nun für mehr Prozesse verantwortlich. Es verändert die Denkweise, indem es alle Entwicklungsprozesse berücksichtigt und die Grenzen zwischen Entwickler- und Betriebsteam überwindet. Neu ist die Beschäftigung mit Automatisierung sowie die Handhabung von Versionsmanagement und automatisierten Tests. Entwickler im IT-Betrieb müssen sich möglicherweise an neue, bereichsübergreifende Key Performance Indicators (KPIs) und damit an gemeinsame Anreizkennzahlen anpassen. Oftmals agieren Unternehmen dabei in ihren Projekten nach Scrum in kleineren Teams von 5-9 Mitarbeitern, die autonom arbeiten dürfen.

Der DevOps-Kreislauf

Vorteile

Die schlechte Nachricht ist, dass es keine Magie ist und Transformationen nicht über Nacht stattfinden. DevOps selbst ist kein Instrument, aber Softwaretools für die automatisierte Automatisierung und Messung sind wesentliche Bestandteile einer erfolgreichen Implementierung. Aber das Herz dieser Anstrengung sind die Mitarbeiter und die Art und Weise, wie sie mit anderen zusammenarbeiten. Vorbei sind die Zeiten, in denen die IT-Abteilung einmal im Jahr ein größeres Update durchführen konnte. Noch relevanter sind die Konzepte der kontinuierlichen Verbesserung und Fehlerabdeckung. Dank der agilen Entwicklung ist die kontinuierliche Verbesserung zum Thema geworden. Diese Idee finde sich auch in ITIL Version 3 mit dem Prozess „Continual Service Improvement“, wobei dieser Prozess auf den IT-Betrieb gemünzt war. Zu den versprochenen Vorteilen von DevOps gehören mehr Vertrauen, schnellere Software-Releases, eine schnellere Beseitigung kritischer Softwarefehler und eine bessere Verwaltung ungeplanter Aufgaben. Vollständige Transparenz und nahtlose Kommunikation sorgen für minimale technische Ausfallzeiten und eine stark beschleunigte Problemlösung für DevOps-Teams. 

Auf kultureller Ebene verspricht DevOps zufriedenere, produktivere Mitarbeiter und Teams, mehr individuelles Engagement und bessere Möglichkeiten zur persönlichen Entfaltung und Weiterentwicklung. Auf der wirtschaftlichen Ebene geht es darum, die Bereitstellung neuer zusätzlicher Funktionen, stabilerer Anwendungen, effizienterer Prozesse und mehr Raum für Innovationen zu beschleunigen. Gerade die wirtschaftlichen Vorteile machen die Einführung von DevOps für viele Unternehmen attraktiv.

Nachteile

Die Vorteile werden ohnehin viel häufiger diskutiert als die Nachteile, da technische, kulturelle und wirtschaftliche Vorteile viel prägnanter behandelt werden können. Nicht alle Mitarbeiter sind immer offen für solche Veränderungen. Meistens sind die noch immer meist strengen Hierarchien in den Unternehmen in Deutschland ein Hindernis auf dem Weg zur erfolgreichen Einführung von DevOps. Dennoch bleibt die Tatsache bestehen, dass es aus dem Wunsch heraus entstanden ist, Softwareentwicklungen schneller zu liefern und damit auf dem deutschen Markt lukrativ zu bleiben.

Erfahrungen mit DevOps

Erfahrungsgemäß braucht eine Umstellung der Unternehmenskultur seine Zeit – und vor allem ist Geduld gefragt, denn oftmals muss DevOps in vielen kleinen Schritten sukzessive eingeführt werden. Wichtig ist vor allem, dass im Unternehmen geeignete Rahmenbedingungen geschaffen werden. Dinge wie Vertrauen und respektvoller Umgang müssen vorgelebt werden. Dann lassen sich die unter dem Punkt „Nachteile“ beschriebenen Bedenken und Probleme leichter aus der Welt schaffen. Oftmals findet es in der Praxis schon statt, ohne dass es so genannt wird und zeigt so, dass es sich immer mehr in den Unternehmen etabliert.

DevOps-Glossar

Was versteht man unter DevOps?

Die Bezeichnung DevOps ist ein Kunstwort aus „Development“ (Entwicklung, insbes. Softwareentwicklung) und „Operations“ (Betrieb). DevOps ist ein Sammelbegriff für eine  Reihe von Prozessen, Werkzeugen und kulturellen Besonderheiten innerhalb eines Unternehmens, die die Zusammenarbeit zwischen der Entwicklung, insbes. der Softwareentwicklung, und des IT-Betriebs, der von Systemadministratoren, Systemarchitekten und der Security verantwortet wird, fördern und verbessern soll.

Kennzeichnend für DevOps sind die oft sehr kurzen Release-Zyklen und der Einsatz  gemeinsamer Tools für das Management, das Testen und Verteilen neuen Quellcodes.

DevOpskann man sich als eine Werkzeugkiste vorstellen, die viele Methoden und Vorgehensweisen anbietet, die jedoch nicht in ihrer Gesatmheiteingesetzt werden müssen. Um kürzere Release-Zyklen zu erreichen, sollte jedoch der gesamte Softwarentwicklungsprozess untersucht werden und mit DevOps-Praktiken bestmöglich unterstützt werden. Insbesondere die Schnittstelle zwischen Entwicklung 

Ziel ist es, die Produktivität der IT durch eine bessere Kommunikation zu steigern und die Probleme zu beseitigen, die oftmals zwischen traditionell getrennten Silos auftreten.

Die folgende Liste umfasst das wichtigste DevOps-Vokabular. Zu jedem Begriff wird eine kurze Erläuterung gegeben, die jedoch keinen Anspruch auf Vollständigkeit erhebt.

Acceptance Testing

Überprüfung eines Systems in Hinblick auf die Umsetzung der vereinbarten Anforderungen. Die Anforderungen können vom Business, von Kunden oder Anwendern stammen. Zu den geprüften Bereichen können Usability, Datenintegrität, Skalierbarkeit und natürlich Funktionalitäten gehören.

Agile

Die Agile Vorgehensweise wird i.A. mit DevOps in Verbindung gebracht. Agile Softwareentwicklung zeichnet sich durch kurze Releasezyklen aus („release early, release often“).

Artifacts

Artifacte sind die entstehenden Nebenprodukte des Softwareentwicklungszyklus. Darunter subsummiert man den kompilierten Code, Skripte und Testfälle, Dokumentationen, User Stories  und Klassendiagramme.

Build  Automation

Unter Build Automation versteht man die automatisierten Aufgaben, die während des Softwareentwicklungszyklus durchlaufen werden. Dazu zählen Aufgaben wie das Ein- und Auschecken des Quellcodes in ein Versionskontrollsystem, das Kompilieren von Code, das Starten und Prüfen von Testabläufen sowie das Paketieren der Ergebnisse. Die bekanntesten Werkzeuge der Build-Automatisierung sind Jenkins, Atlassian’sBamboo, CircleCI.

Client-Server/Client-Only Infrastructure

Eine Client-Server-Architektur umfasst einen oder mehrere primäre Server, die die für den Client erforderlichen Ressourcen verwalten. Ein Beispiel hierfür ist die Kommunikationsbeziehung zwischen einem Puppet Master oder Chef Server und den Puppet Chef-Knoten. Der „Master“-Server teilt dem Client mit, was zu installieren ist, welche S ervice laufen müssen und wie der Client aufgesetzt sein muss.

Im Gegensatz dazu gibt es bei einer Client-onlyInfrastructure keinen „Master“-Server, der die Installationen orchestriert. Stattdessen werden Skripte und Services des Cloudanbieters genutzt, um eine Infrastruktur zu installieren.

Configuration  Drift

Wenn sich Server innerhalb der Infrastruktur von der festgelegten Konfiguration durch manuelle Updates oder  durch allgemeine Nutzung ändern, so spricht man von „Configuration Drift“. Wenn dieser Configuration Drift nicht erkannt und korrigiert  wird, kann dies zu Ausfällen oder anderen Problemen innerhalb des System führen.

Tools wie Chef, Puppet, Ansibleund Saltsollen helfen, Konfigurationsveränderungen zu erkennen und zu verhindern, indem sie regelmäßig auf den Servern „einchecken“, die sie verwalten. So wird geprüft, ob die Client-Konfigurationen den definierten Infrastrukturen entsprechen.

Configuration Management

Configuration Management (CM) beschreibt den Prozess der Schaffung und Aufrechterhaltung einer einheitlichen Infrastruktur. Dies kann eine Kombination von Werkzeugen und Praktiken sein, die sicherstellen, dass ein System oder Produkt innerhalb der erforderlichen Einstellungen bleibt und sich leicht ändern und weiterentwickeln kann, wenn sich diese Anforderungen ändern.

Zu den Werkzeugen des Konfigurationsmanagements gehören Ansible, Chef, Puppet und Salt.

Container

Ein Werkzeug zur Isolierung von Anwendungen und zugehörigen Frameworks und Bibliotheken auf einem System. Container verwenden das Betriebssystem und den Kernel des Hostsystems, um Ressourcen bereitzustellen, während die Anwendung in einer geschlossenen Umgebung läuft und nicht auf das zugrundeliegende System oder andere auf dem System befindliche Container zugreifen kann. 

Das bekannteste Werkzeug ist Docker.

Continuous Delivery

Dies ist eine Erweiterung des Prozesses „Continuous Integration“(siehe unten) und „Deploy early, deploy often“-Philosphie, die DevOps und die Agile Softwareentwicklung auszeichnet. Wenn in einer Versionsverwaltung regelmäßige Änderungen vorgenommen werden, dann soll Continous Delivery dafür sorgen, dass diese Änderungen automatisch geprüft werden und dann in den letzten Softwarestand aufgenommen und veröffentlicht werden können. 

Werkzeuge wie Jenkins, Bamboo, Circle CI helfen bei der Implementierung von Continous Delivery.

Fortsetzung folgt…

Mein Weg zur AWS Zertifizierung – Solutions Architect Associate

In den letzten Monaten habe ich begonnen mich mit den Angeboten von Cloud Service Providern (CSP) wie AWS, Google Cloud Platform und Microsoft Azure zu beschäftigen. Die Planung und der Aufbau von hochverfügbaren und skalierbaren Infrastrukturen in einem klassischen Rechenzentrum gehörte schon seit längerem zu meinem Haupttätigkeiten als Service Manager. Die Ankündigungen der Cloud Provider lassen auf eine schnellere und einfachere Bereitstellung von IT-Infrastruktur hoffen, es war für mich an der Zeit, sich die Cloud-Technologie näher anzusehen.

Weiterlesen

« Ältere Beiträge Neuere Beiträge »
Diese Website benutzt Google Analytics. Bitte klicke hier wenn Du nicht möchtest dass Analytics Dein Surfverhalten mitverfolgt. Hier klicken um dich auszutragen.