Deployment
Wird die AWS-Instanz terminiert und neu aufgebaut, so gehen natürlich alle Inhalte verloren. Davon sind auch die Named-Volumes mit dem WordPress-Content betroffen. Soll der Content ein Server-Redeployment überleben, dann müssen die Named-Volumes außerhalb der betroffenen Instanz abgelegt werden. Für AWS bietet sich ein Elastic Block Store an. Das ist ein Volume für persistente Speicherung, das mit der EC2-Instanz verbunden und unter Linux zur Nutzung gemounted werden kann. Die Docker Volumes werden auf das zusätzliche Laufwerk ausgelagert und damit vom Lifecycle der EC2-Instanz entkoppelt.
EBS-Erweiterungen
Die Erweiterungen für Terraform sind in einer zweiten Datei „aws_wordpress-ebs.tf_“ abgelegt. Dort wird ein 2-Gigabyte EBS-Volume angelegt und mit der EC2-Instanz verknüpft.
Neu hinzugekommen ist auch eine Elastic IP. WordPress bekommt ein Problem, wenn sich durch den Neuaufbau der EC2-Instanz die IP-Adresse verändert. Diesen Effekt kann man schön an der ersten Version (ohne EBS) beobachten. Verändert sich die öffentliche IP-Adresse durch einen Neustart, dann funktioniert WordPress anschließend nicht mehr. Bleibt die IP-Adresse unverändert ist alles gut. Durch die Elastic IP wird der EC2-Instanz immer die selbe öffentliche IP-Adresse zugeordnet.
Die Verknüpfungsressource aws_volume_attachment enthält jetzt auch das Bootstrapping aus Teil IV. Es kommt sonst zu Synchronisationsproblemen, da manchmal zunächst die EC2-Instanz erzeugt und erst danach das EBS-Volume angehängt wird. Dann funktioniert das Bootstrapping natürlich nicht richtig. Liegen die Provisioner unter der Verknüpfungsressource, wird dieses Problem verhindert. Die Provisioner werden erst nach der Verknüpfung ausgeführt.
resource "aws_ebs_volume" "demo_wordpress-ebs" {
availability_zone = "eu-central-1a"
size = 2
tags {
Name = "demo_wordpress-ebs"
}
}
resource "aws_volume_attachment" "demo_wordpress-att" {
device_name = "/dev/sdh"
instance_id = "${aws_instance.demo_wordpress.id}"
volume_id = "${aws_ebs_volume.demo_wordpress-ebs.id}"
##### PART IV #####
[...]
}
resource "aws_eip" "demo_wordpress-ip" {
instance = "${aws_instance.demo_wordpress.id}"
}
Auch für das Shellskript sind Erweiterungen nötig. In der Version „bootstrap-ebs.sh“ wird das von Terraform erzeugte EBS-Volume bei Bedarf erst formatiert und dann gemounted. Im Anschluss wird das Verzeichnis mit den Docker-Volumes umgelenkt. Die Daten aus
/var/lib/docker/volumes [EC2]
landen jetzt in
/data/docker/volumes [EBS]
Damit die Änderungen aktiv werden und das EBS-Volume erzeugt wird, muss die erste Terraform-Datei „aws_wordpress.tf“ auskommentiert (Unterstrich „_“ anfügen) und die zweite Terraform-Datei „aws_wordpress-ebs.tf_“ einkommentiert werden (Unterstrich „_“ entfernen). Danach wird die neue Version von Terraform angezogen und bei der Ausführung berücksichtigt.
Jetzt landet der Content auf einem separaten EBS-Volume. Die Docker-Container oder gar die komplette EC2-Instanz können nun ausgetauscht werden, ohne dass die WordPress Inhalte zerstört werden. Vorsicht: die Datenbank sollte vor einem Austausch besser gestoppt werden, damit auch tatsächlich alle Daten persistiert wurden.
Nachtrag
Security wird in diesem Beispiel völlig vernachlässigt. Vor einem produktiven Einsatz sollte dieser Punkt noch gründlich durchleuchtet werden.
Leider kann ich nicht garantieren, dass die in diesem Showcase genutzten AWS-Dienste von dem AWS-Gratis-Kontingent abgedeckt werden. Es könnten Kosten anfallen.
Viel Spaß beim Ausprobieren!