Blue/Green-Switching in der Cloud Umsetzung von Continuous Deployment in AWS

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:

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.

Switching per Auto Scaling

Eine andere Möglichkeit besteht darin, den AWS Auto Scaling Service für das Switching zu nutzen. Damit kann der Admin bestimme Regel definieren, die Scaling-Ereignisse „antriggern“, um dann die Anzahl aktiver EC2-Instanzen automatisch erhöhen oder zu verringern zu lassen.

Dazu muss der Admin zunächst eine Launch-Konfiguration definieren, die spezifiziert, wie neue Instanzen erzeugt werden. Hierbei gilt es festzulegen, welches AMI zugrunde liegen soll, welcher Instance-Typ, welche Security Group und welches „User-Data-Script“, z. B. via cloudinit (Linux) oder Powershell (Windows/IIS) ausgeführt werden soll.

Diese „launch configuration“ kann dann zum Definieren einer so genannten „Auto Scaling group“ verwendet werden, welche die Anzahl an EC3-Instanzen enthält, die initial verwenden werden sollen. Auto Scaling wird dann die gewünschte Anzahl an Instanzen automatisch launchen.

Ferner wird kontinuierlich überwacht, ob zusätzliche Instanzen benötigt werden, entweder weil eine vorhandene Instanz ausfällt (unhealthy) oder ein anderer Schwellwert (wie z. B. der aktuelle Load) erreicht wird. Auto Scaling wird dann betroffene Instanzen automatisch ersetzen bzw. die Auto Scaling Gruppe herauf- oder herunterskalieren.

Auto-Scaling-Gruppen lassen sich mit ELB verbinden, der dann seinerseits für das Registrieren und Deregistrieren von EC2-Instanzen sorgt und zwar immer dann, wenn ein „automatic-scaling“-Event auftritt. Diese Zuordnung zum ELB lässt sich jedoch nur bei der ersten Erstellung der Auto Scaling Group festlegen und nicht mehr nachdem das Setup „läuft“. Daher lässt sich das Feature zwar für das Implementieren des Blue-Green-Switches heranziehen, das Einrichten erfordert aber, dass folgende Schritte in exakt dieser Reihenfolge durchgeführt werden.

• 1. Erstellen einer Launch-Configuration für die „Green“-Version Ihres Software-Stacks.

• 2. Erstellen einer neuen Auto Scaling Group für das Green-Deployment auf Basis der Launch-Konfiguration von Schritt 1 und Verbinden der Gruppe mit dem gleichen ELB, der auch das Blue-Deployment bereitstellt. Es kann etwas dauern, bis die neuen Instanzen registriert sind den Status „healthy“ haben.

• 3. Updaten der blauen Auto Scaling Group durch Nullsetzen der gewünschte Anzahl an Instanzen und abwarten, bis die Instanzen terminiert sind.

• 4. Löschen der „blauen“ Auto Scaling Group und der zugehörigen Launch Configuration.

Diese Prozedur arbeitet mit ein und demselben ELB, während die EC2–Instanzen und Auto Scaling Groups hinter diesem „ersetzt“ werden. Das größte Problem bei dieser Variante ist das Delay. Der Admin muss warten, bis der Launch der neuen Instanzen vollendet ist, die Auto Scaling Group diese als „healthy“ einstuft und die alten Instanzen terminiert.

Während des Umschaltprozesses gibt es eine Periode, während der der ELB anfallende Requests zu beiden Deployments (Green und Blue) routet, was für bestimmte Instanzen einen unerwünschten Effekt haben kann. Daher bevorzugen die meisten Anwender bei Blue/Green-Deployment in AWS die im zweiten Teil dieses Beitrags erwähnte DNS Redirection via Route 53.

DNS Redirection via Route53

Anstatt Elastic IPs oder gar lange ELB-Hostnamen zu veröffentlichen, kann man auch mit „einem“ Domain-Namen für alle öffentlich sichtbaren URLs arbeiten. Das Switchen des Blue/Green-Deployments erfolgt dann „außerhalb“ von AWS durch Ändern des CNAME records im verwendeten Domain Name Server (DNS).

Einführung in Continuous Deployment, Teil 2

Blue/Green-Deployment in AWS

Das gleiche Ergebnis lässt sich deutlich einfacher mit Route 53, einem DNS als Managed Service in AWS, erzielen. Man erstellt einfach in Route 53 eine „Hosted“ DNS-Zone und definiert seine Ressourcen so, dass der DNS „weiß“, wie der Traffic für die Domain zu routen ist. Der Traffic Flow lässt sich in Route 53 sehr komfortabel einrichten.

AWS veranschlagt Public Hosted Zones mit 0,5 US-Dollar pro Domain und Monat. Das Registrieren von Domains ist direkt aus dem Route-53-Dashboard möglich.

Das grüne Deployment kann hierbei wahlweise eine Single-Instanz oder ein komplettes Elastic Load Balancing sein. In diesem Fall muss man das Ressource Record einfach auf diejenige Domain/Subdomain setzen, welche für ELB die jeweils „neue“ Instanz ist.

Route 53 hat sogar eine AWS-spezifische Erweiterung für DNS, die für eine bessere Integration mit anderen AWS-Komponenten sorgt und darüber hinaus billiger ist, so genannte Alias Resource Record Sets. Diese arbeiten im Wesentlichen genauso, aber anstatt auf jede IP-Adresse im DNS-Record zu zeigen, wird hier eine spezifische AWS-Ressource wie z. B. eine CloudFront-Distribution, einen ELB, ein S3-Bucket, das seinerseits eine statische Webseite ausliefert oder ein anderes Route53-Resource-Record Set in der gleichen Hosted-DNS-Zone referenziert.

(ID:44563915)