Amazon S3 dla TYPO3

aus_driver_amazon_s3 to standardowe rozwiązanie, gdy zasoby TYPO3 nie mogą już leżeć na serwerze WWW, rozszerzenie wprowadza buckety S3 jako pełnoprawny sterownik FAL do stosu TYPO3

Klasyczna konfiguracja TYPO3 przechowuje wszystkie dane medialne pod fileadmin na serwerze WWW. To działa, dopóki projekt działa na jednej maszynie i pamięć wystarcza. Gdy jednak w grę wchodzą konfiguracje multi-serwerowe, klastry kontenerów, auto-scaling lub Content Delivery Networks, ten model się załamuje. Każda instancja potrzebowałaby identycznej kopii wszystkich plików, synchronizacja staje się stałym problemem, a wdrożenia są wolne. aus_driver_amazon_s3 rozwiązuje to, osadzając Amazon S3 jako zewnętrzny storage FAL. Pliki leżą w bucket, TYPO3 czyta i pisze przez API S3, a każda instancja serwera ma dostęp do tego samego spójnego zbioru danych. Dla projektów z wymaganiami wysokiej dostępności to standardowa droga.

Obok technicznej konieczności dla konfiguracji multi-serwerowych istnieje drugi ważny driver: backup i redundancja. S3 zapisuje każdy plik automatycznie wielokrotnie, rozłożony po różnych centrach danych, i osiąga tym samym poziom przechowywania danych, którego klasyczny serwer WWW nie może zagwarantować. Dla firm, których dane medialne są krytyczne dla biznesu, to już samo w sobie powód, aby przejść na S3.

Typowe scenariusze zastosowania

Pierwszym przypadkiem są wdrożenia Cloud-Native na AWS, Kubernetes lub Docker Swarm. TYPO3 działa w kilku kontenerach za load-balancerem, każdy kontener jest bezstanowy. fileadmin jako katalog lokalny oznaczałoby, że uploady lądują tylko w jednym kontenerze, a inne ich nie widzą. aus_driver_amazon_s3 trzyma zbiór zasobów centralnie i czyni scale-out w ogóle praktykowalnym.

Drugim przypadkiem są projekty z bardzo dużymi wolumenami danych. Platforma medialna, archiwum zdjęć lub portal pobrań szybko rośnie do kilkuset gigabajtów lub terabajtów. Lokalna pamięć serwera staje się droga i nieelastyczna, S3 skaluje transparentnie i kosztuje tylko to, co jest rzeczywiście zajęte. Podłączenie przez FAL pozwala przy tym przejść na nowy storage bez zmian w kodzie TYPO3.

Trzecie zastosowanie: integracja CDN. Kto chce dostarczać obrazy i pobrania przez Cloudfront, Cloudflare lub własne CDN, używa S3 jako origin. aus_driver_amazon_s3 czyni pliki bezpośrednio dostępnymi w bucket, TYPO3 generuje poprawne URL-e, a CDN cache’uje je globalnie. To mierzalnie poprawia czasy ładowania dla odwiedzających międzynarodowych.

Architektura techniczna

aus_driver_amazon_s3 implementuje interfejs FAL-Driver TYPO3 i używa oficjalnego AWS SDK for PHP do komunikacji z S3. Każdy bucket jest konfigurowany jako własny “File Storage” w backendzie TYPO3, z podaniem nazwy bucket, regionu, Access Key i Secret Key. Alternatywnie można użyć ról IAM, gdy TYPO3 działa na instancji EC2 lub w task ECS, to jest czystsze, bo w konfiguracji nie stoją statyczne credentials.

Rozszerzenie wspiera zarówno Amazon S3, jak i usługi kompatybilne z S3 jak MinIO, Backblaze B2, DigitalOcean Spaces lub Scaleway Object Storage. Dla projektów, które z powodów ochrony danych nie mogą leżeć u AWS, ta elastyczność jest ważna, europejski provider kompatybilny z S3 zachowuje się z punktu widzenia TYPO3 tak samo jak usługa AWS.

W bieżącym działaniu TYPO3 czyta i pisze bezpośrednio wobec S3. Processed Files (czyli przycięte i zoptymalizowane warianty obrazów) są domyślnie również zapisywane w bucket. Alternatywnie można skonfigurować lokalny katalog dla Processed Files, co przyspiesza przetwarzanie obrazów, bo GIFBUILDER nie musi ciągnąć każdego obrazu źródłowego z S3.

Konfiguracja odbywa się przez moduł backendowy “File Storages” i uzupełniające ustawienia TypoScript dla URL bucket i prefiksów CDN. Deweloperzy muszą dodatkowo zainstalować zależność AWS-SDK przez Composer i ustawić prawidłowe uprawnienia w bucket.

Częste problemy i rozwiązania

Pierwszym problemem jest wydajność przy dużych listach obrazów. Gdy strona musi jednocześnie przycinać dziesiątki obrazów, a pliki źródłowe są ciągnięte z S3, budowa strony trwa zauważalnie dłużej. Rozwiązanie leży w lokalnym cache dla Processed Files, ewentualnie w połączeniu z skryptem pre-warming, który po nowych uploadach tworzy wcześniej najpopularniejsze warianty.

Drugi problem: błędy uprawnień przy uploadzie. Gdy TYPO3 chce pisać do bucket, ale polityka IAM dopuszcza tylko odczyt, upload zawiesza się z tajemniczym komunikatem błędu. Rozwiązaniem jest precyzyjna polityka z s3:GetObject, s3:PutObject, s3:DeleteObject i s3:ListBucket dla dokładnie tego bucket TYPO3, idealnie ograniczona do prefiksu, żeby inne aplikacje na tym samym bucket nie były przypadkowo dotknięte.

Trzeci problem: ochrona danych i wybór regionu. Projekty, które muszą pracować zgodnie z RODO, powinny wybrać regiony AWS w UE, zazwyczaj eu-central-1 we Frankfurcie lub eu-west-1 w Irlandii. Dla wyższych wymagań lub klientów, którzy wykluczają AWS z zasady, europejski provider kompatybilny z S3 jak Hetzner, IONOS lub Scaleway jest właściwą drogą. Rozszerzenie pracuje ze wszystkimi tymi providerami.

Migracja i kompatybilność wersji

aus_driver_amazon_s3 jest kompatybilne z TYPO3 v11, v12 i v13 i jest aktywnie rozwijane. Przy upgrade należy uważać na wersję AWS SDK, nowsze wersje TYPO3 często wymagają aktualnych wersji SDK, które z kolei wymagają PHP 8.1 lub wyższego.

Migracja z lokalnego fileadmin do S3 to wyraźnie wydzielalny projekt: pliki początkowo skopiować do bucket przez aws s3 sync, w backendzie TYPO3 skonfigurować nową File Storage, istniejące rekordy sys_file przez skrypt przekierować na nowy storage, lokalne pliki po pomyślnym teście usunąć. Rozszerzenie nie przynosi gotowej rutyny migracji, bo dokładna procedura jest specyficzna dla projektu.

W zasobie przed migracją obowiązuje obowiązek inwentaryzacji. Ile plików leży w fileadmin, jak duży jest zasób danych, które z nich są osierocone, a które rzeczywiście jeszcze zlinkowane? Często przy takich audytach okazuje się, że większość starych danych nigdy więcej nie jest wywoływana i migracja może ograniczyć się do aktywnie używanych plików. To redukuje ryzyko, nakład i koszty bucket.

Gosign towarzyszy migracjom S3 dla projektów TYPO3 i projektuje architektury multi-cloud, które jednocześnie spełniają wymagania ochrony danych i cele wydajnościowe.