Der Vortrag von Sven Paulus beleuchtet die Vorteile von Drupal 7 auf Amazon Web Services (AWS), darunter Flexibilität, Skalierbarkeit und Kostentransparenz. Er erläutert verschiedene AWS-Dienste wie EC2, S3 und Route 53, die zur Bereitstellung und Verwaltung von Drupal-Anwendungen verwendet werden können, sowie Beispiele für verschiedene Nutzungsszenarien. Abschließend wird die Integration von Drupal mit AWS diskutiert, wobei mögliche Herausforderungen und Lösungsvorschläge aufgeführt werden.

1. Drupal 7 auf
Amazon Web Services
Drupal User Group Hamburg
2014-04-07
Sven Paulus

2. Warum?
Warum Drupal auf Amazon Web Services?

3. Warum?
Weil Cloud hip ist!

4. Warum?
Weil man sich mit ein paar Mausklicks ein
komplettes Rechenzentrum zusammenbauen
kann!

5. Warum?
• Weil Ressourcen unmittelbal bei Bedarf
unmittelbar zugreifbar sind
– keine Vertragsabschlüsse
– keine langen Laufzeiten
– Stunden- bzw. Verbrauchs-bezogene Abrechnung
– keine Wartezeiten bis Bereitstellung
– zeitnahe Kostentransparenz
– für Neunutzer 1 Jahr Nutzung einiger Dienste in
kleinsten Einheiten kostenlos

6. Warum?
• Und weil sich dadurch extrem schnell
skalieren lässt
– manuell, geplant
– automatisch, nach Bedarf

7. Warum?
• Weil Amazon verteilte und redundante
Infrastruktur bietet
– Ausfallsicherheit
– Skalierbarkeit
– geographische Nähe zu den Nutzern

8. Warum? - Regionen
• z.Z. acht globale Standorte (Regionen)

9. Warum? - Verfügbarkeitszonen
• und an jedem Standort mehrere räumlich
getrennte Rechenzentren (Verfügbarkeitszonen):
– Northern Virginia (us-east-1): vier
– Northern California (us-west-1): zwei
– Oregon (us-west-2): drei
– Ireland (eu-west-1): drei
– Sao Paulo (sa-east-1): zwei
– Tokyo (ap-northeast-1): drei
– Singapore (ap-southeast-1): zwei
– Sydney (ap-southeast-2): zwei

10. Warum?
• Weil viele komplex zu administrierende
Dienste als Services bereitgestellt werden
– z.B. schnell mal eine Datenbank anstarten, ohne
Installation
– oder Filme transcodieren, ohne vorher passende
Software zu suchen und zu lizensieren
• AWS nimmt Arbeit ab, befreit aber nicht von
der Notwendigkeit, Know-How zu den
einzelnen Services zu haben

11. Was ist AWS?
• EC2: Virtuelle Server
• S3: Redundanter, skalierbarer Objekt-Storage
• CloudFront: Content Delivery Network (CDN)
• Route 53: Domain Name Services
• Elastic Load Balancing: Lastverteilung
• RDS: Relational Database Services
• Elasticache: Verteilte Caches
• …

12. Was ist AWS?
• … und vieles mehr …

13. Wie werden AWS genutzt?
• Viele Funktionen der Webservices sind über
die Management Console steuerbar

14. Wie werden AWS genutzt?
• Für zig Programmiersprachen stehen fertige
SDKs bereit, ansonsten ist der Zugriff dank
REST auch leicht implementierbar

15. Wie werden AWS genutzt?
• Für PHP gibt es zwei SDKs:
– das alte 1.x-SDK, sehr gewachsen, für bestehende
Dienste
– moderne 2.x-SDK, Namespaces-basierend,
modular, ordentliches Objektmodell,
zukunftssicher

16. Dienste im Detail: EC2
• virtuelle Maschinen gibt es in verschiedensten
Größen, je nach Anwendungsfall
– winzig (z.B. Tests und Entwicklung)
– moderat (z.B. als genau skalierbare Server)
– mit viel CPU-Power (z.B. Numbercrunching)
– mit viel IO-Performance (z.B. Datenbanken)
– mit hohem Netzwerkdurchsatz
– und Kombinationen (z.Z. 34 Typen)

17. Dienste im Detail: EC2
Instanzentyp CPU RAM/GB HD/GB $/h $/mon
t1.micro/Linux 1 0.6 - 0.020 14.40
m1.small/Linux 1 1.7 240 0.044 31.68
m1.large/Linux 2 7.5 840 0.175 126.00
i2.8xlarge/Linux 32 244 6400 (SSD) 6.820 4910.40
m1.large/Windows 2 7.5 840 0.299 215.28
• Instanzen sind jederzeit stopp- und wieder startbar
• Start dauert ca. 5 Minuten
• nur reale Laufzeit wird bezahlt
• alternative Preismodelle:
• für 1 oder 3 Jahre im Voraus buchen (für langfristige Serveraufgaben)
• im Spotmarkt auf freie Instanzen bieten (für Batch-Jobs)
• zu obigen Kosten kommt Traffic

18. Dienste im Detail: EC2
• Verschiedene Basis-Images verfügbar
– Amazon Linux, Redhat-basierend
– Ubuntu Linux
– RHEL 7, SLES mit Lizenz
– Windows mit Lizenz
– … hunderte "Appliances" im Marketplace
• Login via SSH
• Administration als root wie auf normalem
Server

19. Dienste im Detail: EC2
• Eine einzelne Instanz kann jederzeit wegfallen
• Software auf Ausfall hin entwerfen
• Daten ausserhalb der Instanz speichern
(EBS/S3/RDS)
• Skalierungsmöglichkeit kann genutzt werden,
um auf "1" zu skalieren -> immer genau ein
Host ist verfügbar, auch wenn mal einer
wegkippt

20. Dienste im Detail: S3
• S3 ist ein Object Storage (Key-Value)
• S3 ist kein Filesystem, aber Keys können auch
Slashes ('/') enthalten, so sieht es nach außen
wie ein Filesystem aus
• individuelle S3-Instanzen sind Buckets, in
diese passen quasi unbegrenzt Objekte
• S3 kann sowohl als interner Storage für einen
Dienst dienen als auch seine gespeicherten
Inhalte direkt via HTTP ausliefern

21. Dienste im Detail: S3
• S3 ist lahm (GETs dauern im Schnitt 70msec,
können aber nach oben ausreißen)  für
performante Auslieferung immer ein CDN davor
• S3 wird automatisch über Verfügbarkeitszonen
repliziert
• S3 kann neben Daten an einem Objekt auch
Metadaten speichern, z.B. HTTP-Header, die bei
der Auslieferung via HTTP gesandt werden sollen
- wichtig z.B. für Cache-Parametrisierung

22. Dienste im Detail: S3

23. Dienste im Detail: Route 53
• Name Server, auch delegierbar für Zonen und
Subzonen
• Amazon selbst verkauft keine Domains
• Zoneninhalte nicht als Dateien (traditioneller
Nameserver), sondern via Management
Console oder SDK pflegbar, damit leicht
dynamisch updatebar
• Integriert in Amazon-Services-Welt

24. Dienste im Detail: Route 53

25. Dienste im Detail: CloudFront
• CloudFront ist ein CDN – ein globales Content
Delivery Network
• aber auch ohne globalen Anteil als
vorgeschalteter HTTP-Cache einsetzbar
– vor EC2-Instanzen
– vor S3-Buckets
• CloudFront kostet nur den Traffic

26. Drupal und AWS
Und was ist jetzt mit Drupal?

27. Drupal auf AWS: Use-Case Demo-Site
Szenario:
• Abnahme durch Kunden
• gemeinsame Entwicklung via Internet
Typische Lösung:
• EC2-Micro-Instanz mit allem "an Bord"
(Dateisystem, Datenbank, Storage)
• Bei Bedarf gestartet/gestoppt
• Drupal läuft einfach so "out of the box"

28. Einschub: Wie fester Hostname bei wechselnder IP?
• Route 53 to the rescue
#! /bin/sh
export AWS_USER=drupal
export AWS_ACCESS_KEY_ID="<IDENTIFIER_DES_SCHLUESSELS>"
export AWS_SECRET_ACCESS_KEY="<GEHEIMER_KEY>"
PUBLIC_IP=`ec2metadata | awk '/^public-ipv4/{print $2}'`
/usr/local/bin/cli53 rrcreate aws.wayforward.de '' A
$PUBLIC_IP --ttl 60 --replace
echo "Updated aws.wayforward.de to $PUBLIC_IP - $?"
echo "$PUBLIC_IP" | mail -s "[AWS] aws.wayforward.de is
now at $PUBLIC_IP" sven@karlsruhe.org
mit https://github.com/barnybug/cli53

29. Drupal auf AWS: Use-Case Demo-Site
Route 53
EC2-
Instance
Users

30. Drupal auf AWS: Use-Case Testballon
Szenario:
• Kleine Site, zunächt langsam startend
• Soll durchgehend laufen, aber gff. schnell wieder
gekillt werden
Typische Lösung:
• eine EC2-Instanz mit passendem Profil
• Entweder alles an Bord (Storage auf EBS)
• oder MySQL nach RDS ausgelagert
• mit Auto Scaling sichergestellt, dass permament
online

31. Drupal auf AWS: Use-Case Testballon
Route 53
EC2-
Instance
Auto scaling Group
Amazon RDS ElastiCache
Users

32. Drupal auf AWS: Use-Case skalierbare Site
Szenario:
• voll ausgebaute Site mit wechselndem Lastprofil
Typische Lösung:
• dynamische skalierendes Set von EC2-Small-
Instanzen mit vorgeschaltetem LoadBalancer und
CloudFront-CDN
• alle Storage-Dinge auf Services verlagert
– Datenbank: RDS
– Memcache: ElastiCache
– Dateien: S3

33. Drupal auf AWS: Use-Case skalierbare Site
Route 53
EC2-
Instances
Auto scaling Group
Amazon RDS
ElastiCache
Users
Security Group
Elastic Load
Balancing
CloudFront
Amazon S3
CloudFront

34. Drupal auf AWS: Storage auf S3
Dateien auf S3?
Aber S3 ist doch kein Dateisystem?

35. Drupal auf AWS: Storage auf S3
• Zum Glück abstrahiert Drupal 7 intern
Dateizugriffe über StreamWrapper-Klassen

36. Drupal auf AWS: Storage auf S3
• Und zum Glück hat sich schon jemand die
Arbeit gemacht, einen S3-StreamWrapper zu
bauen:
– https://drupal.org/project/amazons3
– aufbauend auf https://drupal.org/project/awssdk
• dies basiert auf der AWS SDK 1.x for PHP

37. Drupal auf AWS: Storage auf S3
• Installation ist straight forward:
– ggf. libraries-Modul 2.x installieren
– awssdk-Modul installieren
– unter sites/all/libraries/awssdk das AWS SDK for
PHP ablegen (z.B. in Version 1.6.2)
– amazons3-Modul installieren
– Module aktivieren
– Module konfigurieren
– ???
– PROFIT!!!

38. Drupal auf AWS: Storage auf S3
• awssdk-Modul konfigurieren

39. Drupal auf AWS: Storage auf S3
• amazons3-Modul konfigurieren

40. • In Configuration/Media/File System S3 als
Default-Speicherort wählen
(ach so, die untere Option ist ein Vorgriff um ca. 5 Folien, einfach ignorieren!)

41. Drupal auf AWS: Storage auf S3
• Lustige
Randgeschichte:
Bilderskalierung
im S3-Stream-
Wrapper

42. Drupal auf AWS: Storage auf S3
Reicht das? Das war's?

43. Drupal auf AWS: Storage auf S3
Nein!
Es werden noch immer Dinge ins lokale
Filesystem geschrieben aka hardgecodete
Annahmen in core sind doof.

44. Drupal auf AWS: Storage auf S3
• public-StreamWrapper umbiegen
– Es gibt einen Patch "Override the public file
stream with S3" für das amazons3-Modul:
https://drupal.org/node/2044509
– Damit landen auch minifyte und combinete CSS-
und JavaScript-Dateien brav auf dem S3
– Existierende Dateien aus sites/default/files
müssen manuell nach S3 übertragen werden!

45. Drupal auf AWS: Storage auf S3
• Was broken ist:
– nach Umbiegen des public-Streams auf s3
stimmen die relativen Pfade zu aus CSS-
referenzierten Icons nicht mehr (anderer Host),
d.h. die Icons im Admin-Mode sind fehlend

46. Drupal auf AWS: Storage auf S3
• Was noch unschön ist:
– awssdk-Modul möchte AWS-Key/Secret explizit
konfiguriert, aber besser gäbe man der EC2-
Instanz über Rollen die Servicezugriffsrechte
– awssdk- und amazons3-Module basieren auf der
ältlichen AWS SDK for PHP 1.x, nicht auf der 2.x
– das Umbiegen des public-Streams ist ein Patch auf
das amazons3-Modul
– kein Support für ggf. einen zweiten Bucket für den
private-Stream

47. Drupal auf AWS: Storage auf S3
• Alternative
– s3fs-Modul, basierend auf AWS SDK 2.x
https://drupal.org/project/s3fs
– Fork von amazons3-Modul, umgearbeitet auf AWS
SDK 2.x
– Verspricht mehr Performance

48. Zusammenfassung
• Nutzung von AWS kann je nach
Anwendungsfall sinnvoll sein, muss aber nicht
• AWS kann Arbeit abnehmen, nicht aber Know-
How
• Drupal lässt sich auf AWS in verschiedenen
Formen betreiben

49. Kontakt/Fragen/Kommentare
Sven Paulus
sven@karlsruhe.org