In der Serie für die Loadbalancer für Artifactory hatten wir ja schon den OnTheFly-Switch vom ClassicELB zum Network Loadbalancer beschrieben (NLB) sowie die Änderungen an der Anzahl der konkurriernden Verbindungen dargestellt, die uns direkt nach der Umstellung auf den NLB aufgefallen sind (AWS - Reverse Proxy mit dem NLB in AWS). Kurz zum Setup Das Setup von Artifactory umfasst drei Instanzen mit einem davor geschaltetem Loadbalancer von AWS. Jede Instanz von Artifactory selbst ist eine Tomcatanwendung und einem NGINX Reverse Proxy davor.

In einem vorherigen Blogbeitrag (AWS - Migrieren eines ELB zum NLB on-the-fly) haben wir geziegt, wie man in AWS einen HA cluster mit Artifactory von einem “deprecated” ELB auf einen modernen NLB ohne Downtime umswitcht. Kurz zum Setup Das Setup von Artifactory umfasst drei Instanzen mit einem davor geschaltetem Loadbalancer von AWS. Jede Instanz von Artifactory selbst ist eine Tomcatanwendung und einem NGINX Reverse Proxy davor. Vorherige Bedenken Bedenken zum Switch von ELB zu NLB, die im Vorfeld vorhanden waren, bewahrheiteten sich nicht.

Das Projekt Aufgabe des DevOps Teams war es Artifact Management auf Basis von jFrog Artifactory (https://jfrog.com/artifactory/) zu betreiben. Das Team war die zentrale Schaltstelle für das Artifact Management innerhalb der Firma. Das System hatte einen 24/7 SLA und sollte wegen ihrer zentralen Bedeutung mit einem Minimum an Downtime, am besten gar keiner Downtime, laufen. Dafür lief Artifactory in einem Cluster mit drei Knoten, einer PostgreSQL Datenbank im Hintergrund und einem davor geschaltenen Reverseproxy auf Basis von NGINX.