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. Die Artifakte waren physisch in einem S3-Bucket gespeichert.
Die REST-API Anfragen wurde über ein Classic Loadbalancer (ELB) von AWS auf die verschiedenen Knoten im Artifactory Cluster verteilt. Die Loadbalancer ist so organisiert, dass dieser automatisch die Anfragen auf die übrigen Knoten verteilt, falls ein Knoten ausfallen sollte. Damit ist es möglich Artifactory in einem HA-setup zu betreiben.
Die Anbindung des Clusters bzw. des ELB in der von AWS Umgebung war über DirectConnect und VPC-peering möglich.
Die Aufgabe
Das DevOps-team wurde angefragt ob man Artifactory nicht auch über AWS Private Link (https://aws.amazon.com/privatelink/) connections nutzen könnte, so dass Nutzer, die nicht über Direct Connect oder VPC peering an Artifactory angebunden sind, auch zugreifen können. Grundsätzlich war dies kein Problem. Man musste aber von dem Classic Loadbalancer (ELB) von AWS zu einem Network Loadbalancer (NLB) umswitchen, da dies AWS Private Link voraussetzt.
In einem ersten Plan war klar, dass es die folgenden Aufgaben bedarf um den ELB on-the-fly zu einem NLB umzustellen:
- Provisionierung eines neuen NLB mit der target group in AWS
- Übernahme der laufenden Artifactory-Instanzen (als EC2 Instanzen) vom ELB zur Target Group
- Umstellung des Route53-A-record vom ELB auf den NLB
- Abschaltung des ELB
Es hat sich herausgestellt, dass die gerade skizzierten Schritte noch weitere Feinheiten beinhalteten, die die Umstellung nicht ganz so einfach machten.
Das Setup mit einem AWS ELB erlaubte die Nutzung des AWS Certifacte Managers (ACM) um signierte SSL-Verbindungen zu erlauben (“HTTPS”). ACM ist die Certifcate Authority (CA) von AWS zur Bereitstellung signierter Zertifikate. Artifactory selbst, oder besser der davor geschaltete NGINX Reverse Proxy wurde über HTTP, d.h. ohne SSL verschlüsselung vom ELB angesprochen. Über eine Security Group wurde sichergestellt, dass nur Anfragen, die vom ELB kommen, an Artifactory gesendet werden konnten, alle anderen werden durch die Security Group geblockt.
Das Weiterleiten der https-Anfrage an den ELB als http-Anfrage an NGINX / Artifactory wurde von dem ELB übernommen. Der NLB funktioniert jetzt aber etwas anders. Er funktioniert nach dem Prinzip, wie es reinkommt, kommt es auch wieder heraus. Sprich: Die Anfragen per HTTPS werden auch als HTTPS an Artifactory weitergeleitet. Der NLB erlaubt keine Änderung des Protokolls, wie es der ELB erlaubt.
Aber einfach die signierte Zertifikate von ACM für den NGINX Reverse Proxy verwenden? Nope. So einfach ist es leider nicht, da AWS das einfach nicht unterstützt. Als muss man einen anderen Weg wählen.
Der einfachste Weg war die Nutzung “selbst-signierter” Zertifikate für alle drei NGINX Proxy. Es zeigte sich, dass dies vollkommen ausreichend ist. Da der NLB selbst über ein von einer certificate authority (ACM) signiertes Zertifikat verfügt, erscheinen auch nicht die hässlichen Sicherheitswarnung im Browser, wenn Artifactory angesprochen wird, trotz selbst-signierter Zertifikate im NGINX.
Weitere Aufgaben sind daher:
- Erstelle und füge selbst signierte Zertifikate dem Reverse Proxy hinzu
- Erweitere den NGINX Reverse Proxy um den HTTPS listener (Port 443)
In dem Projekt wurde für die das Deployen, das Provisionieren usw. das folgende Toolset verwendet:
- AWS: Das Projekt war Cloud ONly. Alles lief in einem breiten Spektrum von Services von AWS.
- Terraform: Alle AWS services wurden with HashiCorp Terraform als dem bevorzugten IaC (Infrastructure as Code) Tool deployed.
- Ansible: Ansible war das bevorzugte Werkzeug zum provisionieren von der EC2 Instanzen mit Software (Artifactory, Docker, NGINX, config files …)
- Jenkins: Die CI/CD Pipelines liefen in Jenkins
Wie bereits erwähnt, gab es die Anforderung die Migration des Loadbalancers ohne Downtime zu organisieren. Alles zu stoppen, umzustellen und wieder zu starten war keine Option. Zu viele Teams waren vom System abhängig. Die Frage war deswegen, wie können wir die Umstellung on-the-fly ohne Downtime organisieren.
Der Prozess
Wir haben eine Ansatz mit mehreren Schritten gewählt:
Im ersten Schritt werden alle NLB bezogen Umstellungen durchgeführt. Der NLB läuft parallel mit dem bestehenden ELB. Die Route53-DNS-Auflösung ist wie vorher auf den ELB gemappt. Der NLB ist aber bereits nutzbar für AWS Private Link Verbindungen.
Im zweiten Schritt wird die Route53-DNS-Auflösung vom ELB auf den NLB gemappt. Ab jetzt ist der NLB der alleinige Loadbalancer der Anfragen erhält.
Im dritten Schritt wird der ELB mit allen abhängigen Funktionen zurückgebaut.
Die Schritte im Detail:
1. Schritt:
- Deploy NLB zusätzlich zum ELB. ELB und NLB laufen nun parallel miteinander. Im Projekt haben wir dafür HashiCorp terraform genutzt.
- Deploy der Target Group und hinzufügen aller im ELB laufenden EC2 Instanzen für Artifactory.
- Erstellen und Hinzufügen der selbst-signierten Zertifikate zu NGINX and Hinzufügen des HTTPS listeners (Port 443). NGINX hört jetzt auf Port 80 (für die ELB requests) und Port 443 (fürd die NLB Anfragen). Diese Umstellung wurde mit Ansible bzw. OpenSSL organisiert.
- Provisionierung weiterer Security Groups und dem Endpoint Service für die Möglichkeit der Aufnahme von AWS Private Links. Erstellung mit Terraform.
2. Schritt:
Wenn Route53 im Einsatz um den komplizierten DNS Name des ELB oder auch NLB mit einer etwas einfacheren strukturierten host zone aufzulösen, z.B. “.yotron.de.” muss man das A record der Route53-Host Zone nur vom ELB auf den NLB umswitchen. Dieser Prozess ist auch sehr einfach mit Terraform zu erledigen gewesen.
3. Schritt:
Alle Services mit Bezug zum ELB (wie der ELB selbst, die Security Groups, usw.) werden nicht mehr benötigt und können deswegen gelöscht werden. Auch dieser Schritt ist einfach mit Terraform möglich.
