Umstieg auf das offizielle S3-CLI für einen besseren Dateiexport
Seit unserem Start im Jahr 2009 ist Amazon S3 unser wichtigster Weg für Dateiexporte. Damals war das beste Amazon-CLI-Tool, das wir finden konnten, das Werkzeug aws von Tim Kay. Es war ein abhängigkeitsarmes, voll ausgestattetes Toolkit, das einen Großteil unserer Schwerstarbeit mit AWS erledigte.
Sein Tool hat uns 5 Jahre lang gute Dienste geleistet, und wir haben damit fast ein Petabyte an Dateien exportiert. Doch mit der Weiterentwicklung von Amazon ändern sich die Anforderungen. Die Rechenzentren von Amazon in Frankfurt und China beispielsweise unterstützen Signaturversion 2 nicht. Tim Kay hat großartige Arbeit geleistet, um mit solchen Änderungen Schritt zu halten, doch wir können nicht erwarten, dass er Updates veröffentlicht, sobald Amazon etwas ankündigt, da er dieses Projekt kostenlos in seiner Freizeit betreibt. Da Amazon inzwischen zudem ein offizielles CLI-Tool anbietet, haben wir vergangene Woche umgestellt.
Wir haben viele Tests, um bei derartigen Operationen am offenen Herzen Breaking Changes zu vermeiden. Leider waren jedoch einige Anwendungsfälle nicht abgedeckt, und die Umstellung unserer S3-Engine verlief etwas holprig.
Wenn Sie beispielsweise Buckets außerhalb der USA hatten und keine Region explizit angegeben haben,
mussten wir eine Anfrage vom Typ GetBucketLocation an den Bucket senden und den Export
(oder Import) selbst erneut versuchen. So weit, so gut. Wenn Sie jedoch einen dedizierten
Transloadit-IAM-Benutzer eingerichtet hatten, der nur Puts und Lists ausführen darf (wie von uns
empfohlen), hatten wir weder diese Berechtigung noch die regionalen Umleitungen, sodass der gesamte
Export fehlschlug.
Wir haben in der Produktion einen ineffizienten Workaround, um diese Fehler zu verhindern, haben aber
auch unsere Dokumentation aktualisiert, um darauf hinzuweisen, dass
wir die Berechtigung GetBucketLocation benötigen.
Wir empfehlen Ihnen, diese Berechtigung Ihrem Transloadit-IAM-Benutzer zu erteilen.
Unsere Kundinnen und Kunden haben außerdem einige weitere Probleme gemeldet, die auf subtile Unterschiede zwischen den zugrunde liegenden Tools und auf einen – wie wir glauben – utf-8-Bug im neuen Tool zurückzuführen sind.
Update 7. Februar 2015 Der Bug wurde bestätigt. Als Workaround escapen wir Nicht-ASCII-Zeichen
jetzt zu Unicode-Escape-Sequenzen, sodass Renan Gonçalves so lautet: Renan Gon\u00E7alves.
Vermutlich möchten Sie dieses Escaping auf Ihrer Seite wieder rückgängig machen.
Auch wenn über 99 % unserer Exporte währenddessen weiterhin funktionierten, bedauern wir sehr, dass wir es versäumt haben, mehr Tests zu schreiben, die mehr Sonderfälle abdecken.
Wie es weitergeht
Für all diese Probleme sind jetzt Fixes und Workarounds in der Produktion aktiv. Außerdem haben wir die Systemtests geschrieben, die regionale Umleitungen und andere Sonderfälle abdecken, um Regressionen bei künftigen Upgrades oder Änderungen an unserem Stack zu vermeiden.
Zusätzlich haben wir das 24h-Limit für unseren temporären Speicher ausgesetzt, sodass betroffene Assemblies auch darüber hinaus noch erneut ausgeführt werden können. Damit betroffene Kundinnen und Kunden etwas Zeit haben, sich darum zu kümmern, aktivieren wir das automatische Löschen erst in 7 Tagen wieder.
Kundinnen und Kunden, die stark betroffen waren, haben einen erheblichen Rabatt auf die Rechnung dieses Monats erhalten. Wir sollten uns bereits bei Ihnen gemeldet haben. Falls das nicht der Fall war, geben Sie uns bitte Bescheid.
Wir entschuldigen uns für die entstandenen Unannehmlichkeiten, freuen uns aber darauf, die offiziellen S3-Tools in der Produktion einzusetzen. Wir hoffen, künftig einen sicheren Upgrade-Pfad zu neuen S3-Funktionen und Rechenzentren zu haben.