Drupal 7 auf Amazon Web Services

751 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
751
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
3
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

×