Storage Server z WordPressem: co działa, a co nie

Katalog wp-content/uploads to ta część WordPressa, która rośnie bez hamulców. Zdjęcia, pliki PDF, filmy, a do tego z każdego zdjęcia po kilka rozmiarów, które WordPress generuje automatycznie. Po paru latach leżą tam dziesiątki gigabajtów, a miejsce na serwerze WWW jest najdroższe, jakie można kupić.

Storage Server kosztuje ułamek tego. Pytanie tylko, co naprawdę da się wynieść. W sieci można o tym przeczytać dużo rzeczy, które w praktyce nie działają. Ten artykuł porządnie rozdziela trzy przypadki.

Trzy przypadki w skrócie

Ostatni punkt jest tym, na którym większość się potyka. Dlatego najpierw niewygodna prawda.

Dlaczego dla biblioteki mediów nie ma wtyczki

Znane wtyczki do wynoszenia plików z WordPressa wszystkie mówią tym samym językiem: S3. Łączą się z Amazon S3 albo z usługą z nim zgodną, wgrywają tam plik, usuwają kopię lokalną i podmieniają adres w treści wpisu na publiczny adres tej usługi.

Dokładnie tego nie da się przenieść na Storage Server, i to z dwóch powodów:

• Przestrzeń dyskowa mówi w SMB, SFTP i WebDAV, ale nie w S3.
• Nie ma publicznego adresu dla każdego pliku. Każdy dostęp wymaga zalogowania, nie może więc istnieć odnośnik, który przeglądarka odwiedzającego wywoła bezpośrednio.

Istnieją pojedyncze wtyczki pracujące przez FTP, ale żadna z godnym uwagi rozpowszechnieniem i bieżącym utrzymaniem, która wynosi bibliotekę mediów w całości przez SFTP albo WebDAV. Kto taką znajdzie, powinien przed użyciem spojrzeć na datę ostatniej aktualizacji i na liczbę aktywnych instalacji.

Droga, która działa: montować, a nie wynosić

Na własnym serwerze z uprawnieniami root odwraca się tę sprawę. Zamiast uczyć WordPressa, jak rozmawiać z obcą przestrzenią dyskową, przynosi się tę przestrzeń na miejsce, w które WordPress i tak zapisuje:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=TWOJE_HASLO\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Wpis w /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Potem przenosisz istniejące pliki i zastępujesz katalog:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

WordPress nic z tego nie zauważa, dla aplikacji to zupełnie zwykła ścieżka. Stary katalog zostaje jako uploads.alt, dopóki nie sprawdzisz, że wszystko działa. Usuwać dopiero wtedy, nie wcześniej.

Pułapka przy tym: miniatury

WordPress generuje z każdego zdjęcia po kilka rozmiarów i ładuje je przy każdym wywołaniu strony. Jeśli te małe pliki leżą na przestrzeni dyskowej w sieci, do każdego pliku dochodzi opóźnienie sieci, a galeria z czterdziestoma zdjęciami czeka czterdzieści razy.

Dwa rozwiązania, oba dobre:

• Postawić przed tym pamięć podręczną, na przykład cache w serwerze WWW, który trzyma wydawane pliki lokalnie.
• Położyć na przestrzeni dyskowej tylko oryginały, a wygenerowane rozmiary zostawić lokalnie. To trochę więcej pracy, ale najczystsza droga dla stron z wieloma zdjęciami.

Kopie zapasowe: najszybszy pożytek

Jeśli zrobisz tylko jedną rzecz, to właśnie tę. Kopia zapasowa na tym samym serwerze nie jest kopią zapasową: jeśli dysk zostanie usunięty albo strona zaszyfrowana, przepada razem z nimi. Na osobnej przestrzeni dyskowej przeżyje.

Darmowa wtyczka WPvivid potrafi w wersji podstawowej robić kopie przez SFTP na przestrzeń dyskową, z harmonogramem i regułą przechowywania. Pełną instrukcję do tego znajdziesz w artykule Kopie zapasowe WordPressa na Storage Server.

Na własnym serwerze idzie to jeszcze lepiej, a mianowicie przez rsync albo BorgBackup wprost z harmonogramu. Wtedy przesyłasz tylko zmiany, a BorgBackup dodatkowo deduplikuje.

Wydawanie dużych plików do pobrania

Dla plików, które odwiedzający mają pobierać, przestrzeń dyskowa jest idealna: są czytane rzadko, są duże i nie muszą być szybkie, muszą tylko dojść. Dostęp idzie przez mały skrypt, który wcześniej sprawdza uprawnienie:

<?php
// w pliku functions.php albo jako własna wtyczka
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Zaloguj się', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Nie znaleziono pliku', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

Przykład wychodzi z założenia, że przestrzeń dyskowa jest zamontowana. Bez montowania zastępujesz readfile() odwołaniem przez SFTP albo WebDAV, tak jak opisuje to artykuł Storage Server dla własnej strony.

Efekt uboczny jest przyjemny: ponieważ plik nigdy nie ma publicznego adresu, nikt nie przekaże dalej odnośnika. Sprawdzenia uprawnień nie da się obejść.

Co zostaje na hostingu współdzielonym

Na hostingu współdzielonym WebDAV przez HTTPS jest najpewniejszą drogą, bo port 443 praktycznie nigdy nie jest zablokowany. SFTP też działa, u nas jednak na porcie 23, a nie każdy dostawca dopuszcza wychodzące połączenia na takich portach. Warto to krótko sprawdzić przed zamówieniem.

Jedno subkonto na każdy cel

Każdy Storage Server pozwala na maksymalnie 100 subkont, każde z własnym katalogiem startowym, własnym hasłem i własnymi uprawnieniami protokołów. Dla WordPressa znaczy to co najmniej dwa:

• Jedno konto dla strony, które widzi tylko /uploads.
• Jedno konto dla kopii zapasowych, które widzi tylko /backup.

Jeśli strona zostanie kiedyś przejęta, napastnik znajdzie w wp-config.php dane dostępowe pierwszego konta. Kopie zapasowe zostaną nietknięte, bo to konto wcale ich nie zna. Przy jednym jedynym koncie głównym w tym miejscu przepadłoby wszystko.

Gdy wielu użytkowników potrzebuje własnego miejsca

Storage Server nie zna limitu miejsca na subkonto. Konto zostaje w swoim katalogu, ale może stamtąd wypełnić cały pakiet. Kto chce dać klientom, fotografom albo redaktorom po jednym ograniczonym przydziale, stawia dlatego przed Storage Serverem aplikację, która to przejmie. Nextcloud jest do tego najbardziej oczywisty, przynosi użytkowników, limity i odnośniki do udostępniania: Połączenie Nextcloud ze Storage Serverem.

Który pakiet pasuje

Dla jednej strony na WordPressie z kopiami zapasowymi Storage-1 z reguły wystarcza na długo. Kto wynosi biblioteki mediów kilku stron albo pracuje z wideo, szybko wyląduje przy Storage-2 albo Storage-3. Wszystkie pakiety stoją w Niemczech, nie mają opłaty instalacyjnej, rozliczane są w modelu PrePaid i nie wiążą cię minimalnym okresem umowy. Zmiana na następny większy pakiet jest możliwa w każdej chwili, bez ruszania danych.