</TECH NEWS>
NEUESTES VON UNSEREN ENTWICKLERN:

15.07.2019 – von Eike Eschmann|

The Google Cloud Initialization – Was haben wir bisher gemacht? (2/3)

Hier geht’s zum ersten Teil: The Google Cloudinitialization – Die Idee (1/3)

Infrastruktur-Tooling

Um die Infrastruktur zu provisionieren, nutzen wir Terraform. Zum einen mausert sich Terraform aktuell zum Industriestandard und zum anderen erlaubt es uns die Infrastruktur als Code (infrastructure-as-code) zu dokumentieren und in Gitlab abzulegen.
Zur Containerorchestrierung nutzen wir Kubernetes. Auch hier war es uns wichtig auf einen Industriestandard zu setzen, welchen Google nativ mit der „Google Kubernetes Engine“ in seine Cloud integriert hat. Es bietet uns Auto-scaling und recovery, Selfhealing und vieles mehr. Um auch im Kubernetes Umfeld entsprechend schnell und einfach Deployments durchzuführen, setzen wir dabei auf Helm. Helm ist ein yaml templating tool, was es uns erlaubt Kubernetes Objekte in so genannten „Charts“ zu gruppieren, zu versionieren, zu dokumentieren und ohne großen Aufwand zu deployen.

Cloud Provisionierung und Deployments

Für Deployments setzen wir auf Gitlab-CI (siehe Migration nach gitlab.com). Durch die Migration wollten wir nicht nur die Repositories vereinheitlichen, sondern auch möglichst die Build pipelines auf einen gemeinsamen und aktuellen Stand bringen. Für die Buildpipelines wurden shell Scripte geschrieben, die als Funktionsbibliotheken dienen, welche in jeder Build Pipeline eingebunden werden können. Diese bedienen sich der Gitlab Umgebungsvariablen und Artifactory, um unsere Deployments auszuführen und sowohl die Development Systeme, als auch die Kubernetes Test und Live Umgebung zu provisionieren.

Initiale Cloud-Konfiguration

cert-manager

Für die Kubernetes Umgebung wollten wir auf einem einfachen Wege trusted SSL Zertifikate verwenden. Dafür entschieden wir uns den cert-manager einzusetzen. Sobald der cert-manager richtig konfiguriert wurde, kümmerte er sich automatisch um die Generierung und Aktualisierung der Zertifikate bei letsencrypt.

weavescope

Weavescope ist ein visuelles Monitoring und  Kubernetes Komponenten Dashboard, über das sich die Services, Controller und Pods verwalten lässt. Weavscope kommt bei uns für die Test und Live Umgebung zum Einsatz. Es erlaubt uns damit direkte Logs aus den Pods/Container zu ziehen, als auch in Realtime Deployments zu verfolgen. Neben diesen Features bietet es natürlich einiges mehr. Es hat uns beim entwickeln, monitoren und debuggen bisher sehr weiter geholfen.

kafka

Um unabhängig zwischen den Systemen kommunizieren zu können, nutzen wir einen Kafka-Cluster, in denen wir die Events ablegen. Legacy Systeme oder 3rd Party Applikationen werden über deren Datenbank per Kafka Connect ausgelesen. Dabei erstellen wir JDBC Source Connectoren und lesen Datenbankänderungen in bestimmten Intervallen aus. Andere Applikationen erhalten eine direkte Implementierung.

Elasticsearch

Für einige Services verwenden wir die Suchfunktionen der Elasticsearch. Dazu gehören Beispielsweise intern genutzte Services für den Kundenbereich als auch einen Address Service. Initial haben wir einen Shared Elasticsearch Cluster aufgesetzt, die von unterschiedlichen Services genutzt werden kann. Der Elasticsearch Cluster ist aktuell mit 2 Ingest, 2 Data und 3 Master Knoten aufgesetzt.

VPNs

Wir haben insgesamt 9 VPN Verbindungen in die Google Cloud stehen, um die aktuellen Systeme bestmöglich migrieren zu können. Auf das Test Kubernetes Cluster haben wir direkten Zugriff aus beiden Standorten, um direkt mit im Cluster laufenden Services zu kommunizieren und auch entsprechende Testfälle direkt vom Entwicklerrechner aus mit Anbindung an die Cloudservices durchführen zu können.
Security Technisch haben wir hier auf eine „Deny All“ Strategie gesetzt. Heißt, es darf erstmal kein Service ins oder aus dem Netzwerk Kommunizieren. Jede gewollte Kommunikation muss explizit durch Firewallregeln erlaubt werden.



WEITERE SPANNENDE BEITRÄGE



Unternehmen Marken Team Presse Karriere Tech-Blog SH Händler-Shop