Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

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

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

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

Deployment von Atlassian Software mit AWS und Spinnaker – Teil 1 Infrastruktur

Die Bereitstellung bzw. Deployment von Atlassian Software kann mit etlichen Tools erfolgen. Hier eignen sich gerade AWS in Kombination mit Kubernetes und Spinnaker eignen sich dafĂŒr hervorragend. Im ersten Teil dieser Reihe konzentrieren wir uns auf die Infrastruktur bei der Bereitstellung von Atlassian Software mit AWS.

Durch die Kombination der Vorteile der ZuverlĂ€ssigkeit und Skalierbarkeit von Kubernetes mit dem Bereitstellungsautomatismus und der Anwendungsverwaltung von Spinnaker erhalten wir eine Umgebung, in der wir verschiedene Arten von Anwendungen frei bereitstellen können. Ohne sich Gedanken darĂŒber machen zu mĂŒssen, wie und wo sie in der Infrastruktur bereitgestellt werden.

Diese Deployment-Lösung definiert Ebenen fĂŒr Entwicklung und Betrieb und Verantwortlichkeiten getrennt. Auf diese Weise weiß jeder ĂŒber die umgebenden Anwendungen und den Bereitstellungsablauf Bescheid. Dadurch kann man sich anschließend auf die Aufgaben in der vorgesehenen Ebene konzentrieren.

Hier ist ein Beispiel fĂŒr diesen Bereitstellungsworkflow:

Bereitstellung / Deployment von Atlassian Software mit AWS und Spinnaker - Workflow und Infrastruktur

In dieser Grafik sehen wir vier Infrastruktur Ebenen der Bereitstellung: Code Repository, Container Registry, Deployment und Infrastructure. Wenn ein Entwickler eine Anwendung bereitstellen oder eine neue Umgebung fĂŒr sein Projekt erstellen muss, sollte er dafĂŒr nicht in den Deployment- oder Infrastructure-Layer gehen mĂŒssen. So sollten vielmehr Operations-Teil Schnittstellen in Form von Code-Repositories bereitstellen, die es einem Entwickler ermöglichen, in seiner Umgebung zu arbeiten. Dadurch wird Operations wird als Administrator fĂŒr die tieferen Deployment-Schichten, Layout-Regeln und die Prozessautomatisierung mit den Deployment-Tools und Pipelines seiner Wahl fungieren. Entwicklung und Operations sollten dennoch den gesamten Deployment-Workflow kennen und Zugriff auf alle Tools haben.

Automatismen auf jeder Ebene

Die Automatismen erstrecken sich ĂŒber alle Ebenen der Infrastruktur. So entsteht eine gepflegte und sorgfĂ€ltig geplante Pipeline, um Anwendungen sicher zu bauen, zu testen und bereitzustellen. Dadurch sind bei jedem Deployment Entwicklung und Betrieb in der Lage, alles, was live passiert, mitzuverfolgen und können ĂŒber Monitoring, Logging und Feedback-Schleifen auch auf aggregierte Informationen zugreifen.

Container fĂŒr alle Anwendungen

Damit dieses ganze Konzept funktioniert, mĂŒssen alle Anwendungen containerisiert werden. Die Idee hinter diesem Konzept ist es, das Deployment von Anwendungen so weit wie möglich zu standardisieren und zu automatisieren, um die Entwicklung und die Veröffentlichung neuer Funktionen zu beschleunigen. Anschließend wird Schritt fĂŒr Schritt der Prozess aufgebaut um Anwendungen nach und nach zu integrieren und um alte Legacy-Installationen zu ersetzen.

Infrastruktur

Kubernetes bietet eine große FlexibilitĂ€t und eine wachsende Anzahl von Möglichkeiten bei der Integration. Dazu gehören mehrere Cloud-Provider, Standorte und Vielfalt von Compute-Nodes, sowie die interne Vernetzung. Daher kann das Big-Picture der Infrastruktur je nach Funktionsanforderungen und AnwendungsfĂ€llen von der unten stehenden Grafik abweichen.

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes - Infrastruktur in AWS

Elastic Kubernetes Service (EKS) von AWS

In diesem Beispiel entscheiden wir uns fĂŒr EKS als Managed Service von AWS, aber auch andere verwaltete oder sogar selbst gehostete Kubernetes-Systeme könnten eine valide Option sein.
Da sich Kubernetes nicht um die Hardwarekonfiguration und -verteilung der zu einem Cluster hinzugefĂŒgten Compute-Nodes kĂŒmmert, können wir eine Vielzahl von AnwendungsfĂ€llen mit unterschiedlichen Anforderungen abdecken. Wir wĂŒrden empfehlen, einen Instanztyp zu wĂ€hlen, mit dem Sie sich wohlfĂŒhlen und der eine stetige Skalierbarkeit fĂŒr Ihre Anwendungen ermöglicht. Die GrĂ¶ĂŸe dieses Instanztyps kann je nach der Anwendung, die Sie einsetzen möchten, unterschiedlich sein. Ein Compute-Node sollte in der Lage sein, mehrere Instanzen der Anwendung, die Sie bereitstellen möchten, zu halten.

Skalierung von Clustern

Um eine horizontale Skalierung des Clusters innerhalb der Infrastruktur zu ermöglichen, haben wir AWS Auto Scaling Groups (spĂ€ter als ASG bezeichnet) verwendet, die in der Lage ist, neue Instanzen zu spawnen und sie automatisch zum Cluster hinzuzufĂŒgen, wenn eine bestimmte Last erreicht wird. Je nach Anwendung können Sie auch hier Trigger implementieren, die auf der gesamten RAM- und/oder CPU-Auslastung aller Compute Nodes basieren und die aktuell Teil des Clusters sind. Auf diese Weise stellen Sie sicher, dass der Cluster immer genĂŒgend Ressourcen fĂŒr die Deployments hat. Außerdem sollten Sie nicht vergessen, einen Trigger hinzuzufĂŒgen, um den Cluster wieder herunterzuskalieren, wenn die Gesamtlast der Compute Nodes wieder sinkt. Auf diese Weise können Sie Lastverschiebungen und -spitzen sicher und kosteneffizient bewĂ€ltigen.

Nutzung von Kubernetes Tags

Da Kubernetes viel mit Tags arbeitet und Deployments auf Basis von Compute-Node-Tags verteilen kann. Mit mehreren ASGs lassen sich unterschiedliche Instanztypen, Konfigurationen und Tags einrichten und hochskalieren. Kubernetes kann dann Projekte oder Anwendungen auf Hosts mit bestimmten Tags deployen.
ErwĂ€hnenswert ist auch, dass die Compute Nodes nicht in der gleichen Cloud wie der Master existieren mĂŒssen. Vielmehr ist es möglich, Nodes aus verschiedenen Clouds und sogar On-Premises-Hardware zu kombinieren. DafĂŒr ist es erforderlich, mehr Arbeit in die gesamte Cluster-Netzwerkkonfiguration zu investieren

Weiter zu Teil 2: Deployment →