Konteneryzacja Docker Łódź

Co się dzieje, gdy jeden serwer obsługuje kilkanaście cudzych sklepów

Firma, która pakuje i wysyła towar w imieniu innych, ma jedną rzecz, jakiej nie ma zwykły sklep: te same zadania wykonuje równolegle dla kilkunastu podmiotów, z których każdy przyszedł w innym roku i z innym systemem. Jedna marka sprzedaje na własnej platformie, druga na gotowym silniku sklepowym, trzecia głównie na marketplace, a czwarta w trzech miejscach naraz.

Pod każdą z nich pracuje własny łącznik: coś, co pobiera zamówienia, oddaje stany, zamawia etykietę u przewoźnika i odsyła numer przesyłki. Powstawał osobno, w miesiącu, w którym ta marka weszła na Waszą platformę, i był pisany pod wersję cudzego interfejsu obowiązującą właśnie wtedy.

Wszystkie te łączniki stoją zwykle na jednym serwerze i to jest źródło całego problemu. Podniesienie biblioteki dla jednej marki dotyka pozostałych. Awaria jednego importu potrafi zająć procesor tak, że kompletacja innego zwalnia. A pytanie, dlaczego jeden zleceniodawca ma opóźnienia, a drugi nie, nie ma dobrej odpowiedzi, bo obaj korzystają z tego samego środowiska.

Co się zmienia w konkretnych zdarzeniach

Co się dzieje	Jak wygląda na wspólnym serwerze	Jak wygląda po spakowaniu
Przewoźnik zmienia wersję interfejsu	podniesienie biblioteki dotyka wszystkich marek naraz	nowe wydanie wchodzi u jednej, reszta pracuje na poprzednim
Import cennika wpada w pętlę	serwer zwalnia, wysyłka innych marek czeka	instancja dobija do własnego limitu i zostaje z tym sama
Nowa marka wchodzi na platformę	instalacja zależności i modlitwa, żeby nic nie kolidowało	uruchomienie kolejnej instancji z własnymi parametrami
Poprawka okazuje się gorsza od problemu	odtwarzanie serwera z kopii albo cofanie zmian z pamięci	uruchomienie poprzedniego obrazu, u tej jednej marki
Zleceniodawca odchodzi	ktoś kiedyś usunie jego pliki i klucze, o ile o nich pamięta	gaśnie instancja, sekrety wymieniamy, dane wydajemy
Klient żąda własnego środowiska	osobna instalacja od zera, tygodnie pracy	ten sam obraz uruchomiony na innym hoście

Ostatni wiersz bywa argumentem handlowym, a nie technicznym. Marka, która przy podpisywaniu umowy pyta, czy jej dane i procesy stoją osobno, dostaje wtedy odpowiedź twierdzącą bez rozpoczynania osobnego projektu.

Jak wygląda wejście nowego zleceniodawcy

Przed spakowaniem wygląda to w każdej takiej firmie podobnie. Ktoś kopiuje katalog poprzedniego łącznika, zmienia w nim adresy i klucze, sprawdza, czy biblioteki wymagane przez nowy sklep nie kolidują z tym, co już stoi na serwerze, i przez następny tydzień poprawia rzeczy, które wyszły po drodze. Handel zapowiedział start na poniedziałek, więc część poprawek zostaje na później i zostaje tam na stałe.

Po spakowaniu wejście marki jest uruchomieniem kolejnej instancji z tego samego obrazu. Podajemy jej adres sklepu, klucze z menedżera sekretów, mapowanie pól i własny zbiór na dane trwałe. Instalowanie czegokolwiek na hoście nie wchodzi w grę, bo host nie wie, czym różnią się od siebie obsługiwane firmy.

Zostaje wyłącznie ta część pracy, której żadne narzędzie nie skróci: ustalenie ze zleceniodawcą, jak jego pola przekładają się na Wasze, i doczekanie się od niego dostępów. To zwykle trwa dłużej niż całe uruchomienie i dobrze o tym mówić przy ustalaniu terminu z handlem.

Dlaczego dwa wydania mogą pracować równocześnie

Bo instancja pobiera z rejestru wskazane wydanie, a nie to, które akurat jest najnowsze. W praktyce oznacza to, że nową wersję łącznika uruchamiacie u jednego zleceniodawcy, patrzycie na nią przez tydzień i dopiero potem przenosicie pozostałych. Każda marka ma przy tym zapisane, na czym pracuje, więc pytanie o wersję nie wymaga logowania się na serwer.

Ta właściwość zmienia rytm pracy bardziej niż cokolwiek innego w tym wdrożeniu. Zmiana w łączniku przestaje być decyzją odkładaną do spokojniejszego tygodnia, ponieważ koszt nieudanej próby spada do jednego polecenia i dotyczy jednej firmy zamiast wszystkich.

Warunkiem jest to, żeby stan leżał poza kontenerem. Kolejki zadań, pliki i pozycje w toku trzymamy na wolumenach, dzięki czemu wymiana wersji nie gubi zamówienia, które akurat czekało na numer przesyłki.

Gdzie stoi host i co się na nim mieści

Najczęściej na maszynie wirtualnej u dostawcy chmury, obok rejestru obrazów, ponieważ łączniki rozmawiają głównie z usługami dostępnymi przez internet i nic nie zyskują na staniu w hali. Wyjątkiem jest wymiana danych z systemem magazynowym: kiedy odbywa się co kilka minut i dotyczy dużych porcji, host stawiamy w tej samej sieci co serwer systemu.

Host prowadzimy jak każdy inny serwer: aktualizacje, kopia, alarmy w monitoringu i dzienniki wynoszone poza samą maszynę. Kontener nie unieważnia żadnej z tych rzeczy, choć w ofertach bywa tak pokazywany. Do tego dochodzi aktualizowanie warstwy bazowej i sprawdzanie obrazów pod kątem znanych podatności, bo bez tego zamknięcie starej biblioteki w obrazie tylko ją ukrywa.

Czego przy tej pracy nie robimy

Nie przepisujemy łączników i nie zmieniamy tego, co robią, przy okazji pakowania. Jeśli któryś trzyma klucze obok kodu albo zapisuje pliki w katalogu kasowanym przy aktualizacji, piszemy o tym w raporcie i proponujemy poprawkę po stronie autora. Nie stawiamy klastra dla kilkunastu łączników na jednym hoście i nie budujemy potoku wdrożeniowego tam, gdzie wydania zdarzają się kilka razy w roku.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a układ z systemem magazynowym przy hali przy chmurze hybrydowej. Wgląd dla marek w ich własne dane ustawiamy tak, jak opisujemy to przy Azure dla firm. Powtarzalny opis hosta i rejestru powstaje przy infrastrukturze jako kodzie, a wyprowadzenie firmy z własnej serwerowni przy migracji do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026