Drupal 7 auf
Amazon Web Services
Drupal User Group Hamburg
2014-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 Lauf...
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ä...
Warum? - Regionen
• z.Z. acht globale Standorte (Regionen)
Warum? - Verfügbarkeitszonen
• und an jedem Standort mehrere räumlich
getrennte Rechenzentren (Verfügbarkeitszonen):
– Nor...
Warum?
• Weil viele komplex zu administrierende
Dienste als Services bereitgestellt werden
– z.B. schnell mal eine Datenba...
Was ist AWS?
• EC2: Virtuelle Server
• S3: Redundanter, skalierbarer Objekt-Storage
• CloudFront: Content Delivery Network...
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...
Wie werden AWS genutzt?
• Für PHP gibt es zwei SDKs:
– das alte 1.x-SDK, sehr gewachsen, für bestehende
Dienste
– moderne ...
Dienste im Detail: EC2
• virtuelle Maschinen gibt es in verschiedensten
Größen, je nach Anwendungsfall
– winzig (z.B. Test...
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...
Dienste im Detail: EC2
• Verschiedene Basis-Images verfügbar
– Amazon Linux, Redhat-basierend
– Ubuntu Linux
– RHEL 7, SLE...
Dienste im Detail: EC2
• Eine einzelne Instanz kann jederzeit wegfallen
• Software auf Ausfall hin entwerfen
• Daten ausse...
Dienste im Detail: S3
• S3 ist ein Object Storage (Key-Value)
• S3 ist kein Filesystem, aber Keys können auch
Slashes ('/'...
Dienste im Detail: S3
• S3 ist lahm (GETs dauern im Schnitt 70msec,
können aber nach oben ausreißen)  für
performante Aus...
Dienste im Detail: S3
Dienste im Detail: Route 53
• Name Server, auch delegierbar für Zonen und
Subzonen
• Amazon selbst verkauft keine Domains
...
Dienste im Detail: Route 53
Dienste im Detail: CloudFront
• CloudFront ist ein CDN – ein globales Content
Delivery Network
• aber auch ohne globalen A...
Drupal und AWS
Und was ist jetzt mit Drupal?
Drupal auf AWS: Use-Case Demo-Site
Szenario:
• Abnahme durch Kunden
• gemeinsame Entwicklung via Internet
Typische Lösung:...
Einschub: Wie fester Hostname bei wechselnder IP?
• Route 53 to the rescue
#! /bin/sh
export AWS_USER=drupal
export AWS_AC...
Drupal auf AWS: Use-Case Demo-Site
Route 53
EC2-
Instance
Users
Drupal auf AWS: Use-Case Testballon
Szenario:
• Kleine Site, zunächt langsam startend
• Soll durchgehend laufen, aber gff....
Drupal auf AWS: Use-Case Testballon
Route 53
EC2-
Instance
Auto scaling Group
Amazon RDS ElastiCache
Users
Drupal auf AWS: Use-Case skalierbare Site
Szenario:
• voll ausgebaute Site mit wechselndem Lastprofil
Typische Lösung:
• d...
Drupal auf AWS: Use-Case skalierbare Site
Route 53
EC2-
Instances
Auto scaling Group
Amazon RDS
ElastiCache
Users
Security...
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:
...
Drupal auf AWS: Storage auf S3
• Installation ist straight forward:
– ggf. libraries-Modul 2.x installieren
– awssdk-Modul...
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. ...
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
Annahme...
Drupal auf AWS: Storage auf S3
• public-StreamWrapper umbiegen
– Es gibt einen Patch "Override the public file
stream with...
Drupal auf AWS: Storage auf S3
• Was broken ist:
– nach Umbiegen des public-Streams auf s3
stimmen die relativen Pfade zu ...
Drupal auf AWS: Storage auf S3
• Was noch unschön ist:
– awssdk-Modul möchte AWS-Key/Secret explizit
konfiguriert, aber be...
Drupal auf AWS: Storage auf S3
• Alternative
– s3fs-Modul, basierend auf AWS SDK 2.x
https://drupal.org/project/s3fs
– For...
Zusammenfassung
• Nutzung von AWS kann je nach
Anwendungsfall sinnvoll sein, muss aber nicht
• AWS kann Arbeit abnehmen, n...
Kontakt/Fragen/Kommentare
Sven Paulus
sven@karlsruhe.org
Nächste SlideShare
Wird geladen in …5
×

Drupal 7 auf Amazon Web Services

791 Aufrufe

Veröffentlicht am

Eine Einführung in einige Kern-Dienste von Amazon Web Services und Use-Cases für den Einsatz von Drupal 7 auf deren Basis

Veröffentlicht in: Internet
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
791
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Drupal 7 auf Amazon Web Services

  1. 1. Drupal 7 auf Amazon Web Services Drupal User Group Hamburg 2014-04-07 Sven Paulus
  2. 2. Warum? Warum Drupal auf Amazon Web Services?
  3. 3. Warum? Weil Cloud hip ist!
  4. 4. Warum? Weil man sich mit ein paar Mausklicks ein komplettes Rechenzentrum zusammenbauen kann!
  5. 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. 6. Warum? • Und weil sich dadurch extrem schnell skalieren lässt – manuell, geplant – automatisch, nach Bedarf
  7. 7. Warum? • Weil Amazon verteilte und redundante Infrastruktur bietet – Ausfallsicherheit – Skalierbarkeit – geographische Nähe zu den Nutzern
  8. 8. Warum? - Regionen • z.Z. acht globale Standorte (Regionen)
  9. 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. 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. 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. 12. Was ist AWS? • … und vieles mehr …
  13. 13. Wie werden AWS genutzt? • Viele Funktionen der Webservices sind über die Management Console steuerbar
  14. 14. Wie werden AWS genutzt? • Für zig Programmiersprachen stehen fertige SDKs bereit, ansonsten ist der Zugriff dank REST auch leicht implementierbar
  15. 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. 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. 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. 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. 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. 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. 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. 22. Dienste im Detail: S3
  23. 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. 24. Dienste im Detail: Route 53
  25. 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. 26. Drupal und AWS Und was ist jetzt mit Drupal?
  27. 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. 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. 29. Drupal auf AWS: Use-Case Demo-Site Route 53 EC2- Instance Users
  30. 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. 31. Drupal auf AWS: Use-Case Testballon Route 53 EC2- Instance Auto scaling Group Amazon RDS ElastiCache Users
  32. 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. 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. 34. Drupal auf AWS: Storage auf S3 Dateien auf S3? Aber S3 ist doch kein Dateisystem?
  35. 35. Drupal auf AWS: Storage auf S3 • Zum Glück abstrahiert Drupal 7 intern Dateizugriffe über StreamWrapper-Klassen
  36. 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. 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. 38. Drupal auf AWS: Storage auf S3 • awssdk-Modul konfigurieren
  39. 39. Drupal auf AWS: Storage auf S3 • amazons3-Modul konfigurieren
  40. 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. 41. Drupal auf AWS: Storage auf S3 • Lustige Randgeschichte: Bilderskalierung im S3-Stream- Wrapper
  42. 42. Drupal auf AWS: Storage auf S3 Reicht das? Das war's?
  43. 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. 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. 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. 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. 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. 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. 49. Kontakt/Fragen/Kommentare Sven Paulus sven@karlsruhe.org

×