Azure Storage dla TYPO3

Przedsiębiorstwa ze stosem Microsoft potrzebują Azure Storage zamiast lokalnych systemów plików

Gdy infrastruktura IT działa na Azure, Active Directory zarządza użytkownikami, a SharePoint przechowuje dokumenty, system plików TYPO3 również powinien znajdować się w chmurze Azure. EXT:azurestorage integruje Azure Blob Storage jako sterownik FAL (File Abstraction Layer) w TYPO3. Redaktorzy nie zauważają różnicy, ale pliki zamiast na serwerze WWW znajdują się w infrastrukturze chmurowej Microsoft z CDN, georedundancją i praktycznie nieograniczoną przestrzenią dyskową.

To rozszerzenie jest odpowiednikiem Azure dla EXT:aus_driver_amazon_s3. Wybór między nimi rzadko zapada na podstawie kryteriów technicznych, lecz wzdłuż istniejącej strategii chmurowej. Kto już korzysta z Azure, oszczędza złożoność, kontrakty i koszty sieciowe przez pozostanie w ekosystemie Microsoft.

Typowe scenariusze zastosowania

Witryny korporacyjne z konfiguracją wieloserwerową. Duże instalacje TYPO3 działają na wielu serwerach za load balancerem. Bez chmurowego przechowywania pliki muszą być synchronizowane między serwerami - przez rsync, NFS lub GlusterFS. Każde z tych rozwiązań niesie własne problemy. Azure Blob Storage jako sterownik FAL eliminuje potrzebę synchronizacji plików: wszystkie serwery sięgają do tego samego kontenera Blob. U klienta z 4 serwerami WWW i 180 000 plików migracja na Azure wyeliminowała całą infrastrukturę NFS.

Portale z dużą ilością mediów i globalną publicznością. Przedsiębiorstwa z klientami w Europie, Azji i Ameryce Północnej potrzebują szybkich czasów ładowania na całym świecie. Azure CDN dostarcza obrazy i pliki do pobrania przez serwery Edge w ponad 130 miastach. Integracja odbywa się przez konfigurację endpointu CDN w portalu Azure, TYPO3 automatycznie generuje odpowiednie adresy URL CDN.

Wymagania compliance dotyczące przechowywania danych. Niektóre branże wymagają, aby pliki były przechowywane w określonym kraju. Azure oferuje centra danych we Frankfurcie, Zurychu i Wiedniu. Przez konfigurację Storage Account można dokładnie określić, gdzie dane fizycznie się znajdują. Jest to przewaga nad generycznymi dostawcami kompatybilnymi z S3, gdzie geokonfiguracja jest często nieprzejrzysta.

Architektura techniczna

EXT:azurestorage implementuje interfejs sterownika TYPO3 FAL. Oznacza to, że rozszerzenie rejestruje się jako sterownik w File Abstraction Layer i nadpisuje standardowe operacje systemu plików (odczyt, zapis, usuwanie, listowanie) wywołaniami API Azure Blob Storage.

Konfiguracja odbywa się przez ustawienia File Storage TYPO3 w backendzie. Tworzy się nowy obiekt Storage ze sterownikiem “Azure Blob Storage”. Dane dostępowe (nazwa Storage Account, Access Key lub SAS Token) są podawane w konfiguracji Storage. Zalecenie: SAS Token z ograniczoną ważnością i uprawnieniami odczytu/zapisu zamiast głównego Access Key.

Komunikacja między TYPO3 a Azure odbywa się przez Azure Storage REST API. Przesyłane pliki są zapisywane jako Block Blobs, duże pliki (powyżej 256 MB) są automatycznie dzielone na bloki. Do integracji po stronie PHP rozszerzenie wykorzystuje Azure SDK for PHP lub lekką implementację klienta REST.

Obrazy są przetwarzane w razie potrzeby przez Image Processing TYPO3 (GraphicsMagick/ImageMagick). Przetworzone warianty są również przechowywane w Azure, zazwyczaj w oddzielnym kontenerze (processed). Cachowanie przetworzonych plików skraca czas obróbki przy powtórnych żądaniach.

Częste problemy i rozwiązania

Wolna wydajność backendu przy przeglądaniu dużych katalogów. Azure Blob Storage nie ma prawdziwej struktury katalogów, lecz emuluje ją przez prefiksy ścieżek. Listowanie 10 000 plików w “folderze” wymaga paginacji API i trwa zauważalnie dłużej niż na lokalnym systemie plików. Rozwiązanie: poprawna konfiguracja indeksera FAL TYPO3 i regularna aktualizacja indeksu, zamiast sprawdzania na żywo w Azure przy każdym dostępie do backendu.

Przetwarzanie obrazów kończy się niepowodzeniem. TYPO3 musi pobrać obrazy do przetworzenia, przetworzyć je i ponownie przesłać. Przy niestabilnym połączeniu lub dużych obrazach (pliki TIFF o rozmiarze 200 MB) proces się przerywa. Rozwiązanie: przetwarzanie na serwerze z lokalnym katalogiem tymczasowym i przesyłanie tylko wyniku. Konfiguracja processingFolder powinna wskazywać na ścieżkę lokalną.

Eksplozja kosztów przez niepotrzebne wywołania API. Każdy dostęp do pliku to wywołanie API, a Azure rozlicza się za każde 10 000 transakcji. Źle skonfigurowany indekser TYPO3 może generować tysiące wywołań na minutę. Należy skonfigurować monitoring przez Azure Cost Management i przestawić indekser FAL na interwały oparte na Schedulerze (zamiast czasu rzeczywistego).

Migracja i kompatybilność wersji

EXT:azurestorage jest produktem niszowym z ograniczoną społecznością. Dostępne wersje w TER i na Packagist obsługują TYPO3 v10 i v11. Dla v12 istnieją forki na GitHubie o różnym stopniu dojrzałości. Dla TYPO3 v13 nie ma aktualnie gotowego rozwiązania.

Alternatywa dla v12/v13: EXT:aus_driver_amazon_s3 z kompatybilnym z S3 endpointem Azure. Azure Blob Storage oferuje od 2020 roku warstwę API kompatybilną z S3. Dzięki temu lepiej utrzymywane rozszerzenie S3 można używać również z Azure. Konfiguracja wymaga Storage Account Azure z aktywowaną funkcją “S3-Compatible API” i skonfigurowania rozszerzenia S3 z endpointem Azure.

Kto migruje z lokalnego systemu plików na Azure, powinien zaplanować przeprowadzkę w trzech fazach: po pierwsze przesłanie istniejących plików przez AzCopy lub Storage Explorer do kontenera Blob, po drugie przełączenie konfiguracji File Storage TYPO3 i po trzecie odbudowa indeksu FAL. Przy 50 000 plików cały proces trwa zazwyczaj jeden dzień roboczy. Gosign przeprowadził migracje Azure dla projektów TYPO3 z maksymalnie 400 000 plików i doradza zarówno w zakresie natywnego rozszerzenia, jak i obejścia kompatybilnego z S3.