Konteneryzacja Docker Białystok

Dlaczego aktualizacja w podlaskim zakładzie jest decyzją na cały wieczór

W firmie, do której można podjechać, wgranie nowej wersji programu jest czynnością odwracalną. Jeśli coś pójdzie nie tak, ktoś przyjeżdża, wchodzi do serwerowni i przywraca stan sprzed zmiany. W zakładzie pod Białymstokiem tej możliwości nie ma, bo najbliższy nasz inżynier zaczyna dzień w Warszawie, a droga na Podlasie liczy się w godzinach.

Skutek jest taki, że aktualizacje odkłada się. Program pracuje na wersji sprzed trzech lat, poprawki producenta czekają, a przy każdej rozmowie o zmianie pada zdanie, że teraz działa i lepiej nie ruszać. Trwa to do momentu, w którym zmiana przestaje być dobrowolna, bo zmienił się przepis, kontrahent albo system operacyjny pod spodem.

Kontener nie sprawia, że nowa wersja jest lepsza. Sprawia, że decyzja o jej uruchomieniu przestaje być nieodwracalna, a to jest dokładnie to, czego brakuje firmie obsługiwanej z odległości.

Co zmienia obraz w codziennej pracy zakładu

Sytuacja	Wdrożenie ręczne na serwerze	Program w obrazie
Nowa wersja psuje wydruk dokumentów	odtwarzanie serwera z kopii, zwykle następnego dnia	uruchomienie poprzedniego obrazu, ta sama godzina
Sprawdzenie zmiany przed produkcją	osobny serwer, konfigurowany osobno i inaczej	ta sama paczka na próbie, różnią się tylko ustawienia
Przeniesienie programu na nowy sprzęt	instalacja od zera z pamięci	uruchomienie obrazu na nowym hoście
Awaria hosta w nocy	usługa czeka do rana	kontener wraca sam, zgłoszenie i tak przychodzi
Pytanie, co dokładnie działa na produkcji	odpowiedź z rozmowy	numer wydania w rejestrze

Wiersz pierwszy jest tym, dla którego ta praca powstaje. Wiersz ostatni bywa niedoceniany, dopóki nie trzeba zgłosić błędu producentowi programu i podać wersji, na której faktycznie pracujecie.

Skąd wiadomo, że powrót do poprzedniej wersji naprawdę zadziała

Z próby, nie z założenia. Zanim zamkniemy zlecenie, uruchamiamy nowe wydanie, a potem świadomie wracamy do poprzedniego i mierzymy czas całej operacji. Wynik zapisujemy w dokumentacji razem z poleceniem, którym się to robi.

Sprawdzamy przy tym trzy rzeczy, które psują powroty najczęściej. Pierwsza to dane: jeśli nowa wersja zmieniła strukturę bazy, sam powrót obrazu nie wystarczy i mówimy to wprost przed aktualizacją. Druga to konfiguracja dopisywana ręcznie po wdrożeniu, bo zostaje wtedy poza paczką i znika przy podmianie. Trzecia to miejsce na dysku, ponieważ dwa wydania muszą się na hoście zmieścić naraz.

Bez tej próby zdanie o powrocie w minutę jest obietnicą, a przy Waszej odległości od naszego biura obietnice sprawdza się w najgorszym możliwym momencie.

Co pakujemy, a co zostaje przy urządzeniach

Do obrazu trafia część programu rozmawiająca po sieci: usługa, do której logują się ludzie, wymiana danych z kontrahentem, moduł raportowy. Przy urządzeniach zostaje to, co jest wpięte kablem, czyli obsługa wagi, czytnika, drukarki etykiet i sterownika linii. Ta granica bywa przesunięta w konkretnym programie inaczej, więc ustalamy ją przed wyceną, oglądając to, co u Was faktycznie pracuje.

Baza danych zwykle zostaje poza kontenerem, na maszynie albo w usłudze zarządzanej. Powód jest praktyczny: kopie, odtwarzanie i strojenie są wtedy prostsze, a przy firmie prowadzonej zdalnie prostsze znaczy możliwe do wykonania bez nikogo na miejscu.

Kiedy mówimy, że nie warto

Gdy program jest wdrażany raz na kilka lat, stoi na dedykowanej maszynie i nikt go nie rusza. Wtedy kontener dokłada warstwę i nie usuwa żadnego problemu.

Gdy producent programu nie dopuszcza innego sposobu instalacji niż własny instalator na Windowsie, bo wsparcie kończy się w dniu, w którym zrobimy inaczej.

Gdy w firmie nie ma nikogo, kto zdecyduje o wersjach. Kontener porządkuje wydania, ale nie zastąpi odpowiedzi na pytanie, kto akceptuje aktualizację i kiedy wolno ją uruchomić.

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

Odpowiadamy za obraz, host, rejestr, uruchomienie i procedurę powrotu. Nie odpowiadamy za logikę programu ani za jego wydajność wynikającą ze sposobu, w jaki został napisany. Nie przepisujemy go i nie zmieniamy jego architektury przy okazji pakowania.

Zostaje u Was repozytorium z opisem budowania, dostęp do rejestru, instrukcja uruchomienia od zera i zmierzony czas powrotu do poprzedniego wydania. Host prowadzimy w ramach opieki nad środowiskiem, co opisuje administracja chmurą. Jeśli program ma docelowo wyjechać z hali, warto zaplanować to razem z migracją do chmury, a cały host i jego otoczenie opisujemy jako infrastrukturę jako kod.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026