Drupal 7 auf Amazon Web Services

transcript

Drupal User Group Hamburg2014-04-07

Sven Paulus

Warum?

Warum Drupal auf Amazon Web Services?

Warum?

Weil Cloud hip ist!

Warum?

Weil man sich mit ein paar Mausklicks ein komplettes Rechenzentrum zusammenbauen

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

Warum?

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

Warum?

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

Warum? - Regionen

• z.Z. acht globale Standorte (Regionen)

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

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

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• …

Was ist AWS?

• … und vieles mehr …

Wie werden AWS genutzt?

• Viele Funktionen der Webservices sind über die Management Console steuerbar

• Für zig Programmiersprachen stehen fertige SDKs bereit, ansonsten ist der Zugriff dank REST auch leicht implementierbar

• 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

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)

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

• 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

• 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

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

• 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

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

Dienste im Detail: Route 53

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

Drupal und AWS

Und was ist jetzt mit Drupal?

Drupal auf AWS: Use-Case Demo-Site

Szenario:• Abnahme durch Kunden• gemeinsame Entwicklung via InternetTypische 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"

Einschub: Wie fester Hostname bei wechselnder IP?

• Route 53 to the rescue#! /bin/sh

export AWS_USER=drupalexport 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

Drupal auf AWS: Use-Case Demo-Site

Route 53EC2-

Instance

Drupal auf AWS: Use-Case Testballon

Szenario:• Kleine Site, zunächt langsam startend• Soll durchgehend laufen, aber gff. schnell wieder

gekillt werdenTypische 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

Drupal auf AWS: Use-Case Testballon

Route 53EC2-

InstanceAuto scaling Group

Amazon RDS ElastiCache

Drupal auf AWS: Use-Case skalierbare Site

Szenario:• voll ausgebaute Site mit wechselndem LastprofilTypische 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

Drupal auf AWS: Use-Case skalierbare Site

Route 53

EC2-Instances

Auto scaling Group

Amazon RDS

ElastiCache

Security Group

Elastic LoadBalancing

CloudFront

Amazon S3

CloudFront

Drupal auf AWS: Storage auf S3

Dateien auf S3?Aber S3 ist doch kein Dateisystem?

• Zum Glück abstrahiert Drupal 7 intern Dateizugriffe über StreamWrapper-Klassen

• 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

• 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!!!

• awssdk-Modul konfigurieren

• amazons3-Modul konfigurieren

• 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!)

• Lustige Randgeschichte: Bilderskalierung im S3-Stream-Wrapper

Reicht das? Das war's?

Es werden noch immer Dinge ins lokale Filesystem geschrieben aka hardgecodete

Annahmen in core sind doof.

• 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!

• 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

• 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

• 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

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

Kontakt/Fragen/Kommentare

Sven Paulussven@karlsruhe.org