Konteneryzacja Docker Katowice

Jak jeden program zamienia się w trzy różne

Zaczyna się niewinnie i zawsze tak samo. Aplikacja powstaje w jednym zakładzie, bo tam była potrzebna: zbiera odczyty z linii, składa raport zmianowy albo prowadzi zlecenia serwisowe. Po roku okazuje się, że przydałaby się także w drugim zakładzie, więc ktoś kopiuje ją na tamtejszy serwer i poprawia dwie rzeczy, żeby pasowała do miejscowego ustawienia. Po dwóch latach to samo dzieje się w magazynie.

Od tego momentu firma ma trzy programy, mimo że wszyscy mówią o jednym. Każdy stoi na innym systemie, każdy ma inny zestaw bibliotek doinstalowanych przy okazji różnych spraw, a poprawka zgłoszona w jednym zakładzie trafia do pozostałych wtedy, gdy ktoś o niej pamięta.

Nikt tego nie planował i nikt nie zawinił. Kopiowanie było w swoim momencie najszybszym rozwiązaniem, a rozjazd narastał po jednej drobnej decyzji na kwartał.

Co dokładnie się rozjeżdża między kopiami

Element	Dlaczego się rozchodzi	Co widać w firmie	Co robi z tym obraz
Wersje bibliotek	instalowane w dniu uruchomienia, czyli w trzech różnych latach	ten sam błąd występuje w jednym zakładzie, w drugim nie	zależności przypięte, identyczne w każdej lokalizacji
Poprawki logiki	zgłoszone lokalnie i lokalnie naprawione	dwa zakłady liczą przestój inaczej	jedno źródło kodu, poprawka wchodzi wszędzie
Ustawienia i ścieżki	wpisane na sztywno przy kopiowaniu	przeniesienie programu wymaga edycji plików	parametry podawane przy starcie, kod się nie zmienia
Sposób uruchamiania	opisany w pamięci trzech różnych osób	po restarcie serwera coś nie wstaje i nikt nie wie co	jedno polecenie, zapisane w repozytorium
Miejsce zapisu danych	wybrane przez tego, kto akurat instalował	kopia zapasowa nie obejmuje wszystkiego	wolumeny wskazane wprost i objęte kopią
Wersja, która akurat pracuje	nieodnotowana nigdzie	pytanie „co macie uruchomione” nie ma odpowiedzi	oznaczenie wydania widoczne w rejestrze

Wiersz o wersjach bibliotek jest tym, przez który zgłoszenia bywają nierozwiązywalne. Program zachowuje się inaczej w dwóch miejscach, kod jest ten sam, a przyczyna leży w składniku, którego nikt nie zmieniał świadomie i którego nie ma na żadnej liście.

Dlaczego widać to dopiero przy raporcie zbiorczym

Dopóki każdy zakład ogląda własne liczby, rozjazd nikomu nie przeszkadza. Problem pojawia się w dniu, w którym zarząd chce zobaczyć trzy lokalizacje obok siebie w jednym zestawieniu, a suma nie zgadza się z niczym.

Wtedy zaczyna się szukanie winnego w danych, choć dane są w porządku. Jeden zakład liczy postój od zatrzymania linii, drugi od zgłoszenia usterki, bo tak go kiedyś poproszono i tak zostało poprawione tylko u niego. Firma spędza tydzień na uzgadnianiu liczb zamiast na wyciąganiu z nich wniosków.

Jeden obraz zamyka tę sprawę definitywnie, bo różnica w wyniku może wtedy pochodzić już wyłącznie z danych albo z ustawień, a jedno i drugie da się sprawdzić w kilka minut.

Co robimy z różnicami, które są uzasadnione

Nie każda różnica jest błędem. Zakład ma inne wydziały niż magazyn, inne oznaczenia stanowisk i czasem inny sposób rozliczania zmiany, wynikający z faktycznej organizacji pracy. Kasowanie tego w imię jednolitości byłoby psuciem działającego rozwiązania.

Dlatego pierwszym krokiem jest rozdzielenie listy różnic na dwie części. To, co wynika ze specyfiki miejsca, wychodzi z kodu do ustawień podawanych przy uruchomieniu. To, co jest zwykłą poprawką, która nie dotarła wszędzie, wraca do wspólnego źródła. Po tym zabiegu każda lokalizacja uruchamia ten sam obraz i podaje mu własne parametry.

Rozpoznanie zajmuje tu więcej czasu niż samo pakowanie i tak to wyceniamy. Dwie kopie porównuje się szybko, trzy wymagają cierpliwości.

Jak wygląda wydanie po tej zmianie

Wcześniej wyglądało to na Śląsku bardzo konkretnie: ktoś wsiadał w samochód, jechał do jednego zakładu, potem do drugiego, po drodze wpadał do magazynu, a w każdym miejscu kopiował pliki i sprawdzał, czy usługa wstała. Cała operacja zajmowała dzień i kończyła się trzema instalacjami, które od tej chwili znów zaczynały się różnić.

Po spakowaniu wydanie polega na zbudowaniu obrazu, oznaczeniu go wersją i wysłaniu do rejestru. Lokalizacje pobierają go same, w kolejności, którą ustalacie. Powrót do poprzedniej wersji jest uruchomieniem poprzedniego obrazu i można wykonać go tylko tam, gdzie coś poszło nie tak.

Dzień pracy zamienia się w kilkanaście minut, ale nie to jest tu najważniejsze. Najważniejsze jest, że aktualizacja przestaje być czynnością, którą odkłada się do momentu, gdy naprawdę trzeba.

Czego przy tej pracy nie robimy

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 na produkcji bez wyraźnego powodu. Nie stawiamy klastra w firmie, w której infrastrukturą nikt nie zajmuje się na pełny etat, choćby padła taka nazwa w wymaganiach.

Aktualizacja warstw bazowych, sprawdzanie obrazów pod kątem znanych podatności i trzymanie haseł poza obrazem należą natomiast do zakresu zawsze.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a podział między budynki i subskrypcję opisuje chmura hybrydowa. Powtarzalny opis hostów, 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: 2 sierpnia 2026