Self-hosting UnoPIM na VPS - wymagania, koszty i decyzje które musisz podjąć zanim zlecisz instalację

Jednym z argumentów który najczęściej słyszę przy rozmowach o migracji z Akeneo CE jest infrastruktura. "Mamy już serwer skonfigurowany pod Akeneo, to co - zaczynamy od nowa?"

Odpowiedź jest przeważnie: tak, ale to dobra wiadomość. Bo serwer skonfigurowany pod Akeneo CE jest prawie na pewno przewymiarowany dla UnoPIM.

Zacznijmy od twardego porównania

Zanim przejdę do tego co potrzeba - zestawienie wymagań obu systemów, żeby mieć punkt odniesienia:

Elasticsearch startuje i od razu rezerwuje pamięć - nawet pusty węzeł ES zjada 2-4 GB RAM zanim obsłuży pierwsze zapytanie. To jest powód dla którego tanie VPS-y po prostu nie dają rady z Akeneo CE. UnoPIM tego problemu nie ma.

Co konkretnie musisz mieć na serwerze

Stack produkcyjny UnoPIM to pięć komponentów. Każdy robi coś konkretnego i każdy jest potrzebny:

PHP 8.2+ z rozszerzeniami: BCMath, Ctype, cURL, DOM, Fileinfo, GD lub Imagick, JSON, Mbstring, OpenSSL, PCRE, PDO, Tokenizer, XML, Zip. Imagick jest ważniejszy niż GD jeśli planujesz duże wolumeny zdjęć - lepiej radzi sobie z konwersją formatów i generowaniem miniatur.

MySQL 8.0+ - baza danych, nic zaskakującego. Upewnij się że masz ustawione innodb_buffer_pool_size na minimum 25-30% dostępnego RAM. Domyślna wartość w wielu dystrybucjach to 128MB, co przy katalogu kilku tysięcy SKU spowoduje że każde zapytanie będzie szło na dysk zamiast z cache.

Redis - obsługuje cache aplikacyjny i kolejkę zadań. Działa jako pośrednik między aplikacją a queue workerami. Bez Redis import 10 000 SKU próbowałby się wykonać w ramach zapytania HTTP i skończyłby się timeoutem po 30-60 sekundach.

Supervisor - i tu wiele "wdrożeń" odpada przy pierwszym większym imporcie. Supervisor to process manager który pilnuje żeby queue worker działał nieprzerwanie. Bez niego: restartujesz serwer, worker nie wstaje, import leży, nikt nie wie dlaczego. Z Supervisorem: worker startuje automatycznie, crashuje - Supervisor restartuje, logi w jednym miejscu. Konfiguracja zajmuje 15 minut i oszczędza godzin debugowania.

nginx jako reverse proxy przed PHP-FPM. Apache też działa, ale nginx lepiej radzi sobie z obsługą dużych plików przy uploadzie mediów i ma niższe zużycie pamięci przy wielu połączeniach jednocześnie.

Minimalne vs produkcyjne wymagania sprzętowe

Dwie konfiguracje które rekomenduję w zależności od skali:

Demo / pierwsze wdrożenie (do 2000 SKU, kilku użytkowników): 2 vCPU, 4 GB RAM, 40 GB SSD. To jest VPS za 80-100 zł miesięcznie u większości dostawców. Wystarczy żeby zobaczyć system w działaniu i przeprowadzić pierwsze testy integracji.

Produkcja (5000-50 000 SKU, 10-30 użytkowników jednocześnie): 4 vCPU, 8 GB RAM, 80-100 GB SSD. Orientacyjnie 150-200 zł miesięcznie. Przy takim setupie import kilku tysięcy produktów z mediami to kwestia minut, nie godzin.

SSD to nie jest opcja - to wymaganie. MySQL na dysku HDD przy katalogu kilku tysięcy SKU to przepis na frustrację. Różnica w czasie odpowiedzi między HDD a SSD przy operacjach I/O bazodanowych to często rząd wielkości.

Decyzja architektoniczna której nie możesz odłożyć: storage mediów

Zanim zlecisz instalację musisz podjąć jedną decyzję, bo jej zmiana po fakcie jest bolesna: gdzie trzymasz media.

Lokalny dysk VPS jest OK dla małych katalogów. Przy e-commerce z tysiącami zdjęć w wysokiej rozdzielczości staje się problemem szybciej niż myślisz. Trzy powody:

Po pierwsze, dysk się zapycha. Kilka tysięcy produktów z 5-8 zdjęciami per SKU w jakości do druku to łatwo 50-100 GB. Plus miniatury generowane przez system - każde zdjęcie jest zapisywane w kilku rozmiarach. VPS z 80 GB dysku zapełniasz w kilka miesięcy.

Po drugie, backup rośnie do nieporęcznych rozmiarów. Backup bazy danych ma kilka MB - szybko, tanio, codziennie. Backup 80 GB mediów to zupełnie inna rozmowa z dostawcą hostingu.

Po trzecie, inodes. Systemy plików Linux mają limit liczby plików (inodes), który jest niezależny od wolnego miejsca na dysku. Przy dziesiątkach tysięcy plików miniatur możesz dobić do limitu inodes i nie być w stanie zapisać nowego pliku mimo że dysk "ma miejsce".

UnoPIM obsługuje storage S3-compatible natywnie - AWS S3, Backblaze B2, Hetzner Object Storage, Cloudflare R2. Koszt przechowywania 100 GB na Backblaze B2 to kilka dolarów miesięcznie. Przy nowym wdrożeniu zawsze rekomenduje S3 od pierwszego dnia.

Managed vs unmanaged VPS

Druga decyzja którą musisz podjąć zanim powiesz devopsowi "postaw mi to".

Unmanaged VPS - dostajesz czysty system operacyjny, reszta należy do Ciebie. Tańszy o 30-50%, pełna kontrola, ale konfiguracja bezpieczeństwa, aktualizacje systemu i monitoring to Twoja odpowiedzialność.

Managed VPS - provider zajmuje się aktualizacjami systemu, podstawowym monitoringiem i często wstępną konfiguracją stosu. Droższy, mniej elastyczny, ale sensowny jeśli nie masz dedykowanego devopsa.

Dla większości wdrożeń SME rekomenduję managed VPS od dostawcy który zna PHP/Laravel (Forge-compatible, Ploi, RunCloud) i unmanaged dysk do mediów w S3. To jest rozsądny kompromis między kosztem a bezpieczeństwem operacyjnym.

Gdzie są pułapki które znajdziesz dopiero na produkcji

Kilka rzeczy które wyglądają dobrze na środowisku testowym i sprawiają problemy po uruchomieniu produkcji:

Queue worker który nie startuje po restarcie. Klasyczna pułapka. Na testach wszystko działa, bo worker był uruchomiony ręcznie. Serwer się restartuje po aktualizacji kernela - worker nie wstaje - import leży. Supervisor skonfigurowany na autostart=true i autorestart=true rozwiązuje to raz na zawsze. Sprawdź to zanim ogłosisz że wdrożenie jest gotowe.

Brak OPcache. PHP bez OPcache kompiluje każdy plik przy każdym zapytaniu. Z OPcache kompiluje raz i trzyma w pamięci. Różnica w czasie odpowiedzi to 3-5x. OPcache jest dostępny w każdej instalacji PHP, wystarczy odkomentować w php.ini. Zaskakująco często się o tym zapomina.

Storage permissions. UnoPIM potrzebuje uprawnień do zapisu w katalogach storage i bootstrap/cache. Przy złej konfiguracji uprawnień system działa ale nie może zapisać logów, cache ani uploadowanych mediów. Błąd wychodzi przy pierwszym uploaderze zdjęcia, nie przy instalacji.

Import mediów przez HTTP przy dużych katalogach. Przy migracji z innego systemu możesz importować zdjęcia podając URL - UnoPIM pobiera je sam. Przy kilku tysiącach zdjęć to setki zapytań HTTP do zewnętrznego serwera. Wolniejsze niż lokalny import, zależne od dostępności źródła, może prowadzić do timeoutów przy masowych operacjach. Jeśli masz możliwość skopiowania mediów lokalnie przed importem - zrób to.

Kiedy VPS przestaje wystarczać

Standardowy setup sprawdza się przy katalogach do kilkudziesięciu tysięcy SKU i kilkudziesięciu użytkownikach. Sygnały że trzeba myśleć o skalowaniu:

• Import kilkuset produktów trwa ponad 10-15 minut mimo że queue worker działa

• Czas odpowiedzi panelu rośnie powyżej 2-3 sekund przy normalnym użytkowaniu

• MySQL regularnie zjada ponad 80% dostępnego RAM

• Masowe operacje na katalogu (bulk edit, eksport do kanału) blokują interfejs dla innych użytkowników

W takich przypadkach następny krok to osobny serwer bazy danych, Redis Cluster i load balancer przed aplikacją. Ale to jest problem który pojawia się przy skali, nie przy starcie.

Co konkretnie zlecasz devopsowi

Jeśli masz już VPS i podjęte decyzje architektoniczne (S3 tak/nie, managed tak/nie), lista rzeczy do zrobienia jest przewidywalna: instalacja stosu (PHP, MySQL, Redis, nginx), konfiguracja Supervisora pod queue workery, instalacja UnoPIM przez Composer, konfiguracja .env, migracje bazy, konfiguracja SSL, ustawienie storage (lokalny lub S3), podstawowy hardening (firewall, fail2ban, wyłączone zbędne porty).

Dla sprawnego devopsa który zna Laravel to jeden dzień pracy. Większość czasu idzie na konfigurację i testy, nie na samą instalację.

Jeśli planujesz wdrożenie i chcesz żebym to zrobił jako część projektu - konfiguracja serwera wchodzi w standardowy zakres. Możesz też rzucić okiem na kalkulator TCO żeby zobaczyć jak koszt infrastruktury wygląda w porównaniu do alternatyw licencyjnych. Napisz jeśli masz pytania →