Konteneryzacja Docker Poznań

Co w firmie handlowej realnie warto zamknąć w kontenerze

Rozmowa o Dockerze w poznańskiej hurtowni zaczyna się zwykle od sklepu, a kończy przy czymś zupełnie innym. Sklep stoi na gotowej platformie i najczęściej prowadzi go agencja. Pod nim pracuje natomiast kilkanaście drobnych rzeczy, których nie kupiło się nigdzie: import cennika od głównego dostawcy, przeliczanie marż, generowanie feedu do porównywarki, pobieranie numerów listów przewozowych, wysyłanie stanów do dwóch marketplace’ów, przepisywanie zamówień do systemu handlowego.

Każda z tych rzeczy powstała osobno, zwykle w innym roku i często u innej osoby. Jedna jest skryptem uruchamianym z harmonogramu, druga usługą działającą w tle, trzecia zadaniem odpalanym ręcznie przez kogoś z działu zakupów. Wszystkie razem decydują o tym, czy sklep pokazuje właściwą cenę i właściwy stan.

Problem ujawnia się przy pierwszej zmianie po stronie kogoś innego. Dostawca zmienia format pliku z cennikiem, przewoźnik wystawia nową wersję API, marketplace wprowadza nowe pole. Wtedy okazuje się, że nikt nie wie, jakie biblioteki są zainstalowane na serwerze, dlaczego jedna integracja wymaga starszej wersji środowiska niż druga i co się stanie z pozostałymi, jeśli podnieść ją dla jednej.

Które elementy pakujemy, a które zostawiamy w spokoju

Co spotykamy w firmie	Czy warto pakować	Co się przez to zmienia
Import cenników od dostawców	tak	zmiana formatu pliku testowana bez ruszania produkcji
Generator feedów do porównywarek	tak	nowe wydanie wchodzi i wraca w minutę
Integracja z API kurierów	tak	podniesienie biblioteki nie dotyka pozostałych usług
Wymiana danych między sklepem a systemem handlowym	tak	to samo wydanie działa na próbie i na produkcji
System handlowy kupiony od producenta	nie	wsparcie obowiązuje wyłącznie dla instalacji według instrukcji
Baza produkcyjna sklepu	zwykle nie	kopie i strojenie są prostsze, gdy baza stoi obok kontenerów

Czwarty wiersz jest tym, na którym najczęściej zależy właścicielowi, bo to w tym miejscu powstają najbardziej kosztowne pomyłki. Błędny import stanów widać nie w logu, tylko w zamówieniach na towar, którego nie ma. Możliwość puszczenia zmiany najpierw na kopii danych zmienia charakter tej pracy bardziej niż jakiekolwiek przyspieszenie.

Jak wygląda dzień, w którym wchodzi nowa wersja integracji

Przed spakowaniem wydanie wygląda podobnie w każdej firmie. Ktoś kopiuje pliki na serwer, podnosi bibliotekę, restartuje usługę i przez następną godzinę sprawdza, czy nic innego przy okazji nie przestało działać. Powrót do poprzedniego stanu polega na odtwarzaniu serwera z kopii albo na cofaniu zmian z pamięci.

Po spakowaniu wydanie sprowadza się do zbudowania obrazu, oznaczenia go wersją, wysłania do rejestru i uruchomienia. Kolejki i dane leżą poza kontenerem, więc zadania w toku przeżywają wymianę wersji. Powrót do poprzedniego wydania jest uruchomieniem poprzedniego obrazu.

Ta jedna właściwość zmienia rytm pracy bardziej niż cała reszta. Poprawka w integracji przestaje być decyzją odkładaną na spokojniejszy tydzień, bo koszt nieudanej próby spada do minuty.

Gdzie stoi host z tymi kontenerami

Najczęściej na maszynie wirtualnej u dostawcy chmury, obok rejestru obrazów, bo integracje handlowe rozmawiają głównie z usługami dostępnymi przez internet i nie muszą stać w budynku firmy. Wyjątkiem jest wymiana danych z systemem magazynowym: gdy odbywa się co kilka minut i dotyczy dużych porcji danych, host stawiamy w tej samej sieci co serwer systemu, na Proxmoksie albo Hyper-V.

Host traktujemy jak każdy inny serwer: aktualizacje systemu, kopia, alarmy w monitoringu i dzienniki trzymane poza samą maszyną. Żadnej z tych rzeczy kontener nie unieważnia, choć w ofertach bywa tak pokazywany. Postawiony naprędce i porzucony bywa gorszy od zwykłej usługi, bo po roku nikt już nie wie, jakie biblioteki zostały wmurowane w obraz.

Na co schodzą te dwa dni pracy

Pierwszy etap to rozpoznanie: wersje bibliotek, sposób konfiguracji, miejsce zapisu danych, harmonogram uruchamiania i lista systemów, z którymi integracja rozmawia. Drugi to opis budowania obrazu z przypiętymi wersjami. Trzeci to wyprowadzenie kluczy API i adresów do sekretów, dzięki czemu jedno wydanie służy próbom i produkcji. Czwarty to uruchomienie obok istniejącej instalacji i porównanie wyników na tych samych danych wejściowych. Piąty to przekazanie: rejestr, instrukcja uruchomienia od zera i procedura powrotu do poprzedniego wydania.

Sprawdzenie wyników na tych samych danych jest tu punktem, którego nie pomijamy. Integracja handlowa może działać bez błędu i jednocześnie policzyć marżę inaczej niż poprzednia wersja, a to widać wyłącznie w porównaniu.

Czego przy tej pracy nie robimy

Nie przepisujemy aplikacji i nie zmieniamy jej logiki przy okazji pakowania. Jeśli skrypt trzyma hasła obok kodu albo zapisuje dane do katalogu kasowanego przy każdej aktualizacji, piszemy o tym w raporcie i proponujemy poprawki po stronie autora. Nie wdrażamy klastra dla kilku usług i nie budujemy potoku wdrożeniowego tam, gdzie wydania zdarzają się raz na pół roku.

Opis hosta i rejestru w formie, którą da się uruchomić drugi raz, powstaje przy infrastrukturze jako kodzie. Zasoby u dostawcy prowadzimy dalej w ramach administracji chmurą, a wyjście firmy z własnej serwerowni opisuje migracja do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 31 lipca 2026