Konteneryzacja Docker Białystok

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

Wgranie nowej wersji programu bezpośrednio na serwer jest czynnością, którą łatwo wykonać i trudno odwrócić. Gdy coś pójdzie nie tak, powrót oznacza odtworzenie całej maszyny z kopii, a to praca na godziny, nie na minuty. W zakładzie przetwórczym pracującym na zmiany te godziny wypadają w środku produkcji, bo linia nie czeka na to, aż serwer wstanie.

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 ten warunek, którego brakuje firmie bojącej się ruszyć działający program.

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. Ta próba mieści się w dwóch dniach pracy, z których składa się całe zlecenie, i nie jest pozycją, którą wycinamy, gdy termin się skraca.

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 obietnice tego rodzaju sprawdza się zawsze w najgorszym możliwym momencie, czyli wtedy, gdy produkcja stoi i ktoś czeka na decyzję.

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 prostsze znaczy wykonalne w nocy przez jedną osobę, bez zwoływania nikogo dodatkowego.

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. Odbiór i przejście przez procedurę powrotu robimy przy ludziach, którzy będą z niej korzystać, u Was albo w naszym białostockim biurze. 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: 7 września 2026