Deployment von Atlassian Software mit AWS und Spinnaker – Teil 2 Bereitstellung

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

Beitrag teilen

Teilen auf facebook
Teilen auf linkedin
Teilen auf twitter
Teilen auf email

Wie in Teil 1 beschrieben bietet die Bereitstellung / Deployment von Atlassian Software mit AWS und Spinnaker einige essenzielle Vorteile.

Bereitstellung auf Basis von YAML Dateien

Deployments werden in mit YAML-Dateien durchgeführt, in denen die Konfiguration von Anwendungen, Diensten und mehr für Kubernetes festgelegt wird. Diese sollte weiterhin zum einen einen Namen, eine Definition dessen, was man bereitstellen möchte, und zum anderen die Anzahl der Replikate enthalten. Wenn wir zum Beispiel eine Fail-Save-Anwendung auf Kubernetes deployen wollen, würden wir 2 Komponenten einsetzen.

Bereitstellung / Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

1. Die Anwendung

Zunächst die Anwendung selbst. Da wir sie ausfallsicher machen wollen, würden wir sie in Form eines “ Replica-Sets“ mit 3 Replikaten bereitstellen. Kubernetes beginnt dann mit dem Deployment von 3 Pods mit der beschriebenen Anwendung und verteilt diese auf die Compute Nodes. Dies geschieht anhand von Hardwarebeschränkungen und Tags.

2. Der Service

Die zweite Komponente ist ein „Service“. Man kann ihn sich wie einen Loadbalancer innerhalb des Clusters vorstellen. Zudem sorgt dieser Dienst nun für den Lastausgleich auf allen unseren drei Pods. Dies geschieht auf der Grundlage bestimmter Tags, die wir in der Deployment-Yaml angegeben haben. Je nach Service-Typ kann EKS einen AWS Loadbalancer mit einem öffentlichen Domain-Namen erzeugen. Dadurch können wir ohne manuelle Netzwerkanpassungen auf unsere Anwendung zugreifen. Weiterhin ist es auch möglich, Ingress-Controller bereitzustellen und unsere Anwendung mit anderen Tools erreichbar zu machen.

Verwendung von Spinnaker

Jeder, der Zugriff auf den Cluster hat, kann nun Anwendungen manuell bereitstellen. Daher entwickeln wir eine Methode, um alle Deployments für jeden, der damit arbeitet, transparent zu machen und Deployments über einen standardisierten und zuverlässigen Weg zu kanalisieren.

Hier kommen Spinnaker und seine Pipelines ins Spiel. Diese geben uns einen Überblick über die im Cluster laufenden Anwendungen. Außerdem können wir so einfach weitergehende Informationen über Bereitstellungen wie Deployment-Versionen, Pipeline-Läufe oder den Status des Loadbalancers erhalten. Spinnaker selbst wird in den Cluster bereitgestellt. Dadurch profitiert Spinnaker von der gleichen Ausfallsicherheit, die Kubernetes für alle Anwendungen unter dessen Kontrolle bietet.

DevOps hilft ihrem Unternehmen dabei noch effzienter und effektiver Software Lösungen auszuliefern und Ihre Kunden durch konstante Updates von sich zu überzeugen. Mehr über DevOps erfahren.

Infrastruktur aus Microservices

Die Idee ist hier, eine Infrastruktur zu haben, die aus containerisierten Microservices besteht. Jeder Microservice/Applikation wird aus einem dedizierten Repository gebaut und nachdem Änderungen vorgenommen wurden, wird die Applikation gebaut, die dann für den Build eines neuen Docker-Images verwendet wird. Dieses Image wird in eine private Docker-Registry gepusht.

Spinnaker Pipeline

Dies löst eine Spinnaker-Pipeline aus, die nun den geänderten Container mit der bereitgestellten Konfiguration als neue Version in den Cluster einspielt und den Service Loadbalancer so ändert, dass er den Datenverkehr nur auf die neu deployte Version leitet. Wenn diese Version die eingebauten Prüfungen nicht besteht, wird die Änderung rückgängig gemacht und die alte Version wieder über den Service Loadbalancer aktiv gesetzt.

Idealerweise stellt die Spinnakers-Pipeline alle Container zunächst in einer Dev/Stage-Umgebung bereit, um auf Fehler zu prüfen, bevor die Änderungen in der Master/Production-Umgebung bereitgestellt werden. Ein fehlgeschlagenes Update kann dadurch automatisch und auch manuell über die Spinnaker-Web-UI rückgängig gemacht werden.

Sie möchten mehr über Atlassian Hosting auf AWS erfahren? Hier gehts zu unseren Cloud Hosting Services

Das könnte dich auch interessieren

Mario Schaefer 2021-11-30

CALMS Framework

The CALMS Framework for DevOps provides you with measures for your DevOps efforts in your

DevOps
Mario Schaefer 2021-11-23

XALT wird AWS Consulting Partner

Seit 2016 helfen und begleiten wir IT-Teams auf ihrem Weg bei dir Umsetzung von DevOps-Methoden,

XALT News
Mario Schaefer 2021-11-22

Linchpin vs Refined: Confluence Intranet Lösungen im Vergleich

Confluence eignet sich hervorragend als Basis für dein Corporate Intranet. Doch erst zusammen mit Linchpin

Atlassian
Einkaufskorb

B/S/H

Die BSH Hausgeräte GmbH ist der größte Hersteller von Haushaltsgeräten in Europa und eines der weltweit führenden Unternehmen in dieser Branche.

Projekte & Lösungen