Mit AWS als Cloud-Provider stehen verschiedene Möglichkeiten zum Implementieren eines Blue/Green-Deployments zur Verfügung. Wie der Switch von Blue auf Green realisiert wird, ist aber von Fall zu Fall unterschiedlich. Für welche Verfahren sich der Nutzer entscheidet, hängt von der Frontend-Infrastruktur ab.
Das einfachste mögliche Szenario besteht darin, dass jeglicher Traffic von nur einer Single-EC2-Instance „beantwortet“ wird. Jede EC2-Instanz in AWS hat per Default stets zwei IP-Adressen, eine private und eine öffentliche. Letztere wird aus dem Pool von AWS bereitgestellt, wobei eine Private-IP nicht aus dem Internet erreichbar ist, die Public-IP sehr wohl.
Single EC2-Instance mit Elastic IP (EIP)
Allerdings bleibt die öffentliche IP nur so lange gültig, wie die Instanz aktiv ist. Wurde die Instanz terminiert, erhält sie beim nächsten Launch eine neue Public-IP aus dem AWS-Pool. Abhilfe schafft eine Elastic IP (EIP). Hierbei handelt es sich um eine statische IP-Adresse von AWS, die quasi „auf Lebenszeit“ mit dem Account verknüpft bleibt, also auch für eine andere Instanz genutzt werden kann.
Erst mit „Associate Adress“ im „Actions“-Menü des EC2-Dashbords lässt sich die EIP einer Instanz zuweisen. EIPs kosten nichts extra, solange die Instanz aktiv ist, weil Amazon dann ja bereits an der Instanz „verdient. Man muss eine EIP lediglich im VPC-Dashboard unter „Elastic IPs“ mit „Allocate new adress“ anfordern.
Bei terminierten Instanzen verursachen EIPs hingegen durchaus Kosten. Amazon will damit ein „Horten“ von Elastic IPs verhindern. Da sich EIPs z. B. per API-Call auch an andere Instanzen vergeben lassen, sind sie die einfachste Lösung zur Realisierung des Blue/Green-Switching. Man „launcht“ einfach eine neue Instanz, konfiguriert sowie testet sie und nimmt sie bei Bedarf durch ein einfaches Re-Assigning der EIP von der bisher aktiven Instanz „in Produktion“.
Multiple EC2-Intanzen hinter Amazons Eleastice Load Balancing (ELB)
Hängt dagegen jeglicher Traffic z. B. eines Web-Server-Tiers „hinter“ einem Load Balancer, scheidet die beschriebene Technik aus, weil sich dem sogenannten Elastic Load Balancer (ELB) keine Elastic IPs zuweisen lassen. In diesem Szenario ist das aktuelle Blue-Deployment ein Pool mehrerer EC2-Instanzen. Dabei routet ELB sämtliche Anfragen an den Pool automatisch an die passenden Instanzen im Pool, sofern diese „gesund“ sind. Überlastete oder nicht einsatzbereite Webserver bleiben automatisch außen vor.
Um das Blue-Green Switching hinter einem LB zu realisieren, muss jeweils der komplette Pool mit einem neuen Instanzen-Set assoziiert werden, das dann die gerade aktuelle Software enthält. Um dies zu erreichen gibt es zwei Methoden, nämlich
- per API-Call oder
- mithilfe einer AWS Autoscaling Group
Jeder Service in AWS verfügt über ein API und einen CLI-„Client“ mit dem sich die Infrastruktur steuern lässt. Die ELB-API erlaubt z. B. das Registrieren und Deregistrieren von EC2-Instanzen, die zum Webserver-Pool hinzugefügt oder entfernt werden. Das Umsetzen des Blue/Green-Switching erfordert das Registrieren der neuen, „grünen“ Instanz am ELB, während die blauen Instanzen zeitgleich deregistriert werden. Das könnte z. B. per API-Call so aussehen:
aws elb register-instances-with-load-balancer –load-balancer-name my-load-balancer –instances i-d6f6fae3
Der Switch vollzieht sich allerdings nicht sofort, weil es eine gewisse Verzögerung zwischen dem Registrieren einer Instanz am ELB und dem Startpunkt, ab dem Anfragen zur jeweils neuen Instanz geroutet werden, gibt. Das liegt wiederum daran, dass ELB-Anfragen stets nur an „gesunde“ Instanzen geroutet werden und es eine Reihe von Health-Checks erfordert, die jeweils neue Instanz als „healthy“ einzustufen.