Download - Drupal 7 auf Amazon Web Services
Drupal 7 auf Amazon Web Services
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
kann!
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
Wie werden AWS genutzt?
• Für zig Programmiersprachen stehen fertige SDKs bereit, ansonsten ist der Zugriff dank REST auch leicht implementierbar
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
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)
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
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
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
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
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
Dienste im Detail: S3
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" [email protected]
mit https://github.com/barnybug/cli53
Drupal auf AWS: Use-Case Demo-Site
Route 53EC2-
Instance
Users
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
Users
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
Users
Security Group
Elastic LoadBalancing
CloudFront
Amazon S3
CloudFront
Drupal auf AWS: Storage auf S3
Dateien auf S3?Aber S3 ist doch kein Dateisystem?
Drupal auf AWS: Storage auf S3
• Zum Glück abstrahiert Drupal 7 intern Dateizugriffe über StreamWrapper-Klassen
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
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!!!
Drupal auf AWS: Storage auf S3
• awssdk-Modul konfigurieren
Drupal auf AWS: Storage auf S3
• 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!)
Drupal auf AWS: Storage auf S3
• Lustige Randgeschichte: Bilderskalierung im S3-Stream-Wrapper
Drupal auf AWS: Storage auf S3
Reicht das? Das war's?
Drupal auf AWS: Storage auf S3
Nein!
Es werden noch immer Dinge ins lokale Filesystem geschrieben aka hardgecodete
Annahmen in core sind doof.
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!
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
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
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
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 [email protected]