Kubernetes ist ein Open-Source-Container-Orchestrator, der 2014 von Google ins Leben gerufen wurde. Er hat sich zu einem unverzichtbaren Werkzeug für Cloud-fähige Anwendungen entwickelt, die in der Cloud oder hybrid gehostet werden sollen!
Seine Vorteile sind wie folgt:
Cloud-natives Design: Kubernetes fördert die Implementierung von Microservices und verteilten Architekturen, was die Agilität, Fehlerresistenz und Skalierbarkeit der Anwendung erhöht
Portabilität: Kubernetes arbeitet auf die gleiche Weise, mit dem gleichen Image und den gleichen Konfigurationen, unabhängig vom Cloud-Anbieter (AWS, Azure, GCP, etc) oder Vmware
Automatisierung des Deployments: Mit Kubernetes können Sie eine Anwendung in Containern modellieren und deren Deployment automatisieren
Open Source: Kubernetes ist ein Open-Source-Projekt mit einer großen Community
KUBERNETES-OUTSOURCING UND MANAGED SERVICES
In einem Ansatz der Agilität, Zuverlässigkeit und Sicherheit, biete ich eine verwaltete Kubernetes-Plattform kann der Host auch bei Ihnen zu Hause importieren.
Ich biete auch einen Managed Service an, um Anwendern volle Flexibilität in ihrer Kubernetes-Infrastruktur mit Managed Services auf völlig transparente Weise zu ermöglichen.
Sie besitzen Ihre Plattform! Alle Arbeiten werden übersichtlich und einfach dokumentiert, so dass sie leicht übertragen werden können.
Ich biete eine Rancher2-Schnittstelle für alle zu verwaltenden Cluster an.
Angebotene Dienstleistungen :
Erstellung des Kubernetes-Clusters bei Ihnen vor Ort oder komplett ausgelagert
Wartung unter Betriebsbedingungen
Vorbeugende Sicherheitswartung
Backups Ihrer Anwendungen
Beaufsichtigung des Kubernetes-Clusters und der Anwendungen
Follow-up und personalisierte Unterstützung bei der Migration von Anwendungen mit Docker- und Kubernetes-Technologien
CI ist der Teil, in dem der Workflow jeden Entwickler-Commit automatisch validieren sollte.
Die automatischen Unit- und Funktionstests werden von der Integrationsmaschine z.B. GitLab CI oder CircleCi validiert. Sobald die Tests bestanden sind, wird ein Build/Artefakt erzeugt und in der TEST-Umgebung bereitgestellt.
Um zu einem Build/Artefakt zu gelangen
Der Code wird bei jedem Commit gebaut
Der Code wird bei jedem Commit automatisch unitgetestet
Jeder hat Zugriff auf den Build- und Testbericht
Tests werden auf einer verkleinerten Version der Produktionsumgebung ausgeführt
Deliverables werden in einem versionskontrollierten Artefakt-Repository gespeichert
Deliverables werden nach einem erfolgreichen Build automatisch in einer Testumgebung bereitgestellt
Wenn einer der Schritte fehlschlägt, erhält der für den Commit verantwortliche Entwickler eine Benachrichtigung, um so schnell wie möglich zu korrigieren.
Die Implementierung eines CIs und aller zu integrierenden Prozesse
Die verschiedenen Arten von Tests
Unit-Tests dienen zum Testen von Methoden oder Funktionen, die nicht für das Projekt erforderlich sind.
Integrationstests dienen dazu, sicherzustellen, dass sich mehrere Komponenten zusammen korrekt verhalten, sie sind für funktionale Regressionen
Abnahmetests ähnlich der Integration, aber mit Fokus auf das Geschäft
Tests der Benutzeroberfläche dienen dazu, sicherzustellen, dass die Aktionen der Benutzeroberfläche aus Sicht des Benutzers funktionieren
Um kontinuierliche Integration einzuführen, müssen Sie Ihre Tests in jedem Zweig, den Sie pushen, ausführen.
Dazu einige einfache Fragen:
Wo wird der Code gehostet? Einschränkung…
welches Betriebssystem und welche Ressourcen benötigen wir für die Anwendung? Abhängigkeiten…
Wie viele Ressourcen benötigen wir für Ihre Tests?
Ist die Anwendung monolithisch oder Microservice?
Verwenden Sie Container? Docker…
Test coverage & complexity
Es ist gut, eine Abdeckung von mehr als 80% anzustreben, aber seien Sie vorsichtig, einen hohen Abdeckungsgrad nicht mit einer guten Testsuite zu verwechseln. Ein Code-Coverage-Tool hilft uns, den ungetesteten Code zu finden. Die Qualität Ihrer Tests wird am Ende des Tages den Unterschied ausmachen. Ein Werkzeug wie SonarQube ist dazu da, Entscheidungen zu treffen, wenn der Code komplex und ungetestet ist.
Duplizierung und toter Code
Duplizierter Code ist der zukünftige tote Code oder der zukünftige doppelt behobene Fehler! Es ist sehr wichtig, Ihren Code zu überprüfen und Duplikation zu reduzieren. Maximal 5% duplizierter Code bei einem großen oder Legacy-Projekt ist akzeptabel, aber versuchen Sie, bei jedem Projekt, das mit Qualitätscode-Metriken beginnt, unter 2% zu bleiben.
Refactoring
Wenn Sie im Begriff sind, signifikante Änderungen an Ihrer Anwendung vorzunehmen, die keine ausreichende Testabdeckung haben, sollten Sie damit beginnen, Akzeptanztests für die Funktionen zu schreiben, die davon betroffen sein könnten. Dies bietet ein Sicherheitsnetz, um sicherzustellen, dass das ursprüngliche Verhalten nach einem Refactoring oder dem Hinzufügen neuer Funktionen nicht beeinträchtigt wurde.
Die Umgebung
Das gesamte IT-Dev/DevOps/Admin-Team sollte darauf achten, überall die gleiche Umgebung beizubehalten. Die Revisionsnummer aller von der Anwendung verwendeten Komponenten sollte in Dev/Build/Test/Integration/Prod die gleiche sein. Hier sind Container (Docker) und Orchestratoren (Kubernetes) nützlich.
Denkweise
Wenn ein Entwickler den CI-Workflow stört, hat die Behebung des Fehlers oberste Priorität.
Um gute Tests zu schreiben, müssen Sie sicherstellen, dass die Entwickler einbezogen werden und Zugriff auf ein Code-Analyse-Tool haben.
Unabhängig davon, ob Sie eine bestehende Code-Basis haben oder gerade erst anfangen, sind Bugs als Teil Ihrer Releases vorprogrammiert. Stellen Sie sicher, dass Sie Tests hinzufügen, wenn Sie die Probleme beheben, um zu verhindern, dass sie wieder auftreten.
CD
Die Bereitstellung der Anwendung wird durch den Code verwaltet. Der Code beschreibt genau, was die Anwendung zum Starten und Ausführen benötigt. Das Artefakt und die Umgebung werden zwischen den Systemen Test/Integration/Production gleich sein, da das Image nur einmal vom CI erzeugt wird.
Continuous Delivery
Nach der Automatisierung der Erstellung und der Unit- und Integrationstests bei der kontinuierlichen Integration automatisiert die kontinuierliche Auslieferung die Veröffentlichung des validierten Codes in einer Registry/einem Repository. Um die Effektivität des Continuous-Delivery-Prozesses zu gewährleisten, muss der Continuous-Delivery-Prozess daher zunächst in die Entwicklungspipeline eingeführt werden. Continuous Delivery stellt sicher, dass die Codebasis immer bereit ist, in einer Produktionsumgebung eingesetzt zu werden.
Bei der kontinuierlichen Bereitstellung umfasst jeder Schritt (vom Zusammenführen der Codeänderungen bis zur Verteilung der produktionsreifen Versionen) die Automatisierung der Code-Test- und Freigabeprozesse. Am Ende dieses Prozesses ist das Betriebsteam in der Lage, eine Anwendung einfach und schnell in einer Produktionsumgebung einzusetzen.
Continuous Deployment
Der letzte Schritt in einer ausgereiften CI/CD-Pipeline ist die kontinuierliche Bereitstellung. Zusätzlich zum Continuous-Delivery-Prozess, der die Freigabe einer produktionsreifen Version in ein Code-Repository automatisiert, automatisiert das Continuous Deployment den Start einer Anwendung in eine Produktionsumgebung. In Ermangelung einer manuellen Brücke zwischen der Produktion und der vorherigen Stufe der Pipeline hängt die kontinuierliche Bereitstellung in erster Linie von der Gestaltung automatisierter Testprozesse ab.
In der Praxis könnte eine Änderung, die ein Entwickler an einer Anwendung vornimmt, unter Continuous Deployment innerhalb von Minuten nach dem Schreiben des betreffenden Codes freigegeben werden (vorausgesetzt, er besteht die automatisierten Tests). Das macht es viel einfacher, kontinuierlich Benutzer-Feedback zu erhalten und zu integrieren. Zusammen reduzieren diese drei CI/CD-Praktiken die Risiken, die mit der Anwendungsbereitstellung verbunden sind, da es einfacher ist, Änderungen in kleinen Inkrementen als in einem einzigen Block zu veröffentlichen. Dieser Ansatz erfordert jedoch eine erhebliche Vorabinvestition, da automatisierte Tests geschrieben werden müssen, um eine Vielzahl von Test- und Freigabestufen in der CI/CD-Pipeline zu berücksichtigen.
Der DevOps-Ingenieur hat eine übergreifende Rolle, die eine gute Beherrschung der IT-Entwicklungsphasen sowie ein gutes Verständnis für die Herausforderungen der kontinuierlichen Bereitstellung und Produktion erfordert. Der DevOps-Job erfordert die Beherrschung verschiedener Fähigkeiten. Zunächst einmal ist es notwendig, die technischen Fähigkeiten zu beherrschen, die der Job erfordert. Der DevOps-Berater muss also :
wissen, wie man Skripte entwickelt und Integration durchführt
Build- und Virtualisierungs-Tools verwenden: Docker, Kubernetes, etc.
wissen, wie man kontinuierliche Integrationsketten (CI/CD) einrichtet
kennen die Betriebssystemumgebung: Linux, Windows-Systeme
Beherrschen automatisierter Test- oder Einsatzüberwachungswerkzeuge
Sie sind akribisch in Bezug auf Datensicherheit und verfügen über ausgezeichnete Kenntnisse von Serversystemen
Arbeiten auf Cloud-Plattformen (AWS, Azure, GCP etc.) und anderen sowie auf On-Premises-Plattformen
Zusätzlich zu den technischen Fähigkeiten muss der DevOps-Ingenieur die Fähigkeit besitzen, die Funktionsweise von Anwendungen zu bewerten, technische Anpassungen vorzunehmen und die Leistung der entwickelten Lösungen zu messen.
Wenn die technische Beherrschung ausschlaggebend ist, stellen die menschlichen Qualitäten des DevOps-Beraters oder -Ingenieurs in seinen Beziehungen zu anderen Teams und der Hierarchie ein großes Plus dar. Zusätzlich zu den Managementfähigkeiten müssen sie in der Lage sein, auf die Anforderungen des Kunden und der Teams einzugehen. Daher ist es wichtig, dass sie über gute zwischenmenschliche Fähigkeiten verfügen, um die Bedürfnisse besser zu verstehen und sich leichter austauschen zu können :
er muss in der Lage sein, die Teams, mit denen er zusammenarbeitet, zu führen und zu leiten
Er muss immer eine gewisse Distanz zum Projekt haben, um es erfolgreich durchführen zu können und die gesetzten Ziele zu respektieren
er muss in der Lage sein, Anfragen in technischer Sprache zu formulieren
Er/sie muss in der Lage sein, alle Beteiligten zusammenzuführen, um eine personalisierte und kohärente Lösung zu entwickeln
Nicht jeder DevOps-Ingenieur beherrscht alle Programmiersprachen, vor allem nicht die Einsteiger. Ein guter Ingenieur muss daher die Fähigkeit haben, Tools oder Deployment-Technologien schnell zu erlernen, damit die digitale Transformation des Unternehmens gelingt.
Außerdem wird sich das Unternehmen, das einen DevOps-Ingenieur oder einen DevOps-Berater einstellen muss, auf DevOps-Praktiken konzentrieren. Mit anderen Worten: Es wird ein besonderes Augenmerk auf die Arbeitsabläufe der betreffenden Person gelegt. Letztere müssen mit verschiedenen Anbietern von Cloud-Computing-Lösungen vertraut sein. Schließlich muss ein guter DevOps-Ingenieur regelmäßig eine Technologiebeobachtung durchführen, um in seinem Bereich an der Spitze zu bleiben. Er muss auf der Suche nach neuen Sprachen und neuen digitalen Tools sein.
