Konteneryzacja Docker Toruń

Dlaczego w zakładzie sezonowym program zmienia się raz w roku

Firma pracująca równo przez dwanaście miesięcy wprowadza poprawki wtedy, kiedy są gotowe. Zakład przetwórczy nie ma tej swobody, bo przez tygodnie przyjęć surowca każda przerwa kosztuje partię towaru, a każda zmiana w liczeniu psuje porównywalność zapisów w obrębie jednego sezonu.

Powstaje z tego rytm, który widzimy w Toruniu w kolejnych firmach. Uwagi zbierane są w trakcie kampanii i zapisywane na później. Zimą ktoś siada do programu i wprowadza je wszystkie naraz. Wiosną zmiany są sprawdzane na tyle, na ile da się je sprawdzić bez surowca. Potem zaczynają się przyjęcia i przez kilkanaście tygodni nikt niczego nie dotyka.

Ten rytm ma jedną poważną wadę. Wdrożenie zdarza się na tyle rzadko, że przy kolejnym nikt nie pamięta, jak przebiegło poprzednie, a plan awaryjny sprowadza się do odtworzenia całego serwera z kopii sprzed zmiany.

Co obraz zmienia w każdym z tych okresów

Okres roku	Co dzieje się z programem	Bez obrazu	Z obrazem
Po zakończeniu kampanii	zbiór uwag zamienia się w listę zmian	lista leży w mailach	lista wisi przy oznaczeniu wersji, która ma je objąć
Zima, praca nad zmianami	powstaje nowa wersja	testowana na maszynie ustawionej inaczej niż produkcja	budowana i uruchamiana dokładnie tak, jak wejdzie na halę
Wiosna, sprawdzanie	próba na danych z poprzedniego sezonu	kopiowanie plików na serwer testowy	uruchomienie tego samego obrazu obok pracującego
Tydzień przed przyjęciami	wersja zostaje przyjęta	wdrożenie ręczne, zwykle wieczorem	oznaczenie wydania i uruchomienie, kilkanaście minut
Kampania	nie wolno niczego zmieniać	zmiana bywa wymuszona przez awarię	wersja zamrożona, wycofanie w minutę
Po sezonie, rozliczenie	zapisy idą do dokumentacji	wersja odtwarzana z daty aktualizacji	wersja zapisana obok wyniku

Ostatni wiersz jest tym, przez który ta praca zwraca się poza informatyką. Audytor odbiorcy pyta czasem nie tylko o to, co wyszło, ale też o to, czym zostało policzone. Oznaczenie wydania zapisane razem z zapisami partii zamienia odpowiedź na fakt do pokazania.

Co się dzieje, gdy nowa wersja liczy inaczej niż zeszłoroczna

Zwykle nikt nie zauważa tego pierwszego dnia. Program działa, etykiety wychodzą, zapisy powstają. Różnica wypływa dopiero przy pierwszym zestawieniu, gdy ktoś porównuje wydajność z analogicznym tygodniem poprzedniego sezonu i widzi liczby, których nie potrafi wyjaśnić rzeczywistą pracą hali.

W środowisku bez rejestru wydań zaczyna się wtedy tydzień ustalania, czy zmieniło się liczenie, czy praca. Serwer ma na sobie nową wersję, poprzednia została nadpisana, a jedyna droga powrotu prowadzi przez odtworzenie maszyny z kopii, czyli przez przerwę w środku kampanii.

Z obrazem ta sama sytuacja wygląda inaczej. Uruchamiamy poprzednie wydanie obok, przeliczamy ten sam zestaw danych i widzimy w kilkanaście minut, czy różnica siedzi w programie, czy w surowcu. Decyzja o pozostaniu przy nowej wersji albo o powrocie do starej jest wtedy decyzją opartą na wyniku, a nie na przeczuciu.

Co pakujemy, a co zostaje przy linii

Do obrazu trafia to, co przetwarza dane po ich zebraniu: liczenie wydajności, raporty zmianowe, archiwum zapisów, wymiana z programem handlowym. To warstwa, która zmienia się najczęściej i której nowa wersja jest cała potrzebna albo wcale.

Przy urządzeniach zostaje wszystko, co z nimi rozmawia. Odczyt z wagi, sterownik etykieciarki, usługa zbierająca pomiary z rejestratorów w komorach. Te elementy mają zależność sprzętową i wymagania producenta, więc dokładanie im warstwy niczego nie porządkuje, a dokłada miejsce, w którym coś może pójść nie tak.

Granica przebiega w miejscu, w którym dane przestają być odczytem, a stają się zapisem do dalszego użycia. Ustalamy ją na początku rozpoznania i zapisujemy jednym zdaniem, żeby przy zgłoszeniu nie zaczynać od sporu o zakres.

Gdzie kończy się nasza część tej pracy

Nie przepisujemy programu i nie zmieniamy jego działania przy okazji pakowania, bo to osobne zadanie z własnym ryzykiem i własną wyceną. Nie przenosimy do obrazu bazy pracującej pod stałym obciążeniem bez wyraźnego powodu. Nie stawiamy klastra w firmie, w której infrastrukturą nikt nie zajmuje się na pełny etat, nawet jeśli taka nazwa pada w wymaganiach.

Aktualizacja warstw bazowych, sprawdzanie obrazów pod kątem znanych podatności oraz trzymanie haseł poza obrazem należą natomiast do zakresu zawsze, także w miesiącach, w których program stoi nietknięty.

Rozpoznanie przed sezonem umawiamy z wyprzedzeniem, a rozmowę o zakresie prowadzimy w naszym biurze przy Grudziądzkiej 136 albo u Was, najlepiej razem z osobą, która ten program rozwija.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a podział między halę i subskrypcję opisuje chmura hybrydowa. Powtarzalny opis hosta, sieci i rejestru powstaje przy infrastrukturze jako kodzie, a wyprowadzenie firmy wyżej przy migracji do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026