Konteneryzacja Docker Bydgoszcz

Co zostaje po człowieku, który napisał ten program

W bydgoskich firmach produkcyjnych i usługowych bardzo często pracuje program napisany na miejscu. Zbiera dane z linii, składa raport zmianowy, prowadzi zlecenia serwisowe albo wystawia dokumenty w formie, której żaden kupiony system nie robi tak, jak trzeba. Powstał, bo ktoś potrafił i miał czas. Działa od lat i nikt go nie rusza.

Ryzyko nie leży w tym, że program jest niedoskonały, bo zwykle robi dokładnie to, czego firma potrzebuje. Leży w tym, że istnieje w jednym egzemplarzu, na jednej maszynie, a wiedza o tym, jak go uruchomić, istnieje w jednej głowie. Dopóki obie te rzeczy są na miejscu, wszystko jest w porządku.

Moment, w którym przestaje być, jest zawsze jednym z trzech. Autor przechodzi na emeryturę albo zmienia pracę. Kończy się wsparcie dla serwera i trzeba przenieść program gdzie indziej. Firma zmienia właściciela lub przechodzi na następne pokolenie, a nowy zarząd pyta, co się stanie, jeśli ta maszyna przestanie się uruchamiać.

Sześć pytań, na które trzeba znaleźć odpowiedź przed pakowaniem

Rozpoznanie jest tu ważniejsze od samego pakowania i zajmuje zwykle więcej czasu. Poniżej pytania, które zadajemy w każdym takim zleceniu, razem z tym, co robimy, gdy odpowiedzi nie ma.

Pytanie	Gdzie szukamy odpowiedzi	Gdy odpowiedzi nie ma
Skąd program bierze ustawienia	pliki obok kodu, wpisy w rejestrze systemu, zmienne	wyprowadzamy je na zewnątrz i opisujemy każdą pozycję
Gdzie zapisuje dane i pliki	katalogi na dysku, udziały sieciowe, baza	wskazujemy wolumeny i obejmujemy je kopią
Jakich wersji bibliotek wymaga	lista zainstalowanych składników na maszynie	przypinamy wersje z działającego serwera, nie najnowsze
Z czym rozmawia w sieci zakładu	reguły na zaporze, dzienniki połączeń	odtwarzamy zależności z ruchu obserwowanego przez tydzień
Kto zna hasła, których używa	konfiguracja, pamięć jednej osoby	zmieniamy je i przenosimy do sekretów przed pierwszym startem
Co się dzieje, gdy się nie uruchomi	doświadczenie autora	opisujemy procedurę powrotu do poprzedniego wydania

Ostatni wiersz jest tym, o który nikt nie pyta przed awarią i o który wszyscy pytają w jej trakcie. Program, który da się cofnąć do wersji sprzed zmiany, przestaje wymagać odwagi przy każdej aktualizacji.

Dlaczego wymiana serwera jest najlepszym momentem

Ponieważ i tak trzeba wtedy odpowiedzieć na wszystkie sześć pytań z tabeli. Przeniesienie programu na nową maszynę bez spakowania go oznacza wykonanie tej samej pracy rozpoznawczej i zmarnowanie jej, bo za pięć lat sytuacja się powtórzy, a wiedza znów zostanie w głowie osoby, która akurat to robiła.

Różnica w nakładzie jest niewielka, różnica w efekcie jest zasadnicza. Po przeniesieniu bez obrazu macie działający program na nowym sprzęcie. Po przeniesieniu z obrazem macie program, który da się uruchomić na dowolnym kolejnym serwerze poleceniem, razem z opisem tego, czego do tego potrzeba.

Ten sam argument dotyczy przejęcia firmy przez następne pokolenie. Spis środowiska robi się wtedy i tak, więc dołożenie do niego jednej aplikacji jest tańsze niż osobne zlecenie za dwa lata.

Co robimy, gdy program rozmawia z urządzeniem na hali

Odmawiamy pakowania i mówimy to na pierwszym spotkaniu. Klucz sprzętowy wpięty w serwer, sterownik od producenta urządzenia albo bezpośrednia komunikacja z maszyną po kablu przesądzają sprawę: kontener niczego tu nie upraszcza, za to dokłada warstwę, którą ktoś musi utrzymywać.

Taki program zostaje na maszynie i prowadzimy go zwykłą opieką nad serwerem: aktualizacje, kopie, podgląd stanu i dzienniki wynoszone poza host. Zdarza się, że w tej samej firmie jedna aplikacja idzie do obrazu, a druga zostaje, i jest to układ całkowicie normalny, mimo że w ofercie wygląda niekonsekwentnie.

Jak wygląda wydanie po zmianie

Wcześniej wygląda to zwykle tak: ktoś kopiuje pliki na serwer, przestawia ustawienia, restartuje usługę i przez kolejną godzinę sprawdza, czy niczego nie pominął. Gdy coś nie zadziała, powrót polega na odtworzeniu maszyny z kopii albo na cofaniu zmian z pamięci.

Później wydanie to zbudowanie obrazu, oznaczenie go wersją, wysłanie do rejestru i uruchomienie. Powrót do poprzedniej wersji jest uruchomieniem poprzedniego obrazu. Ta jedna właściwość zmienia sposób pracy bardziej niż cała reszta, bo aktualizacja przestaje być czynnością, którą odkłada się na koniec tygodnia.

Czego przy tej pracy nie robimy

Nie zmieniamy sposobu działania programu przy okazji jego pakowania, bo to osobne zadanie z własnym ryzykiem i własną wyceną. Nie przenosimy do obrazu bazy pracującej na produkcji, o ile nie ma ku temu wyraźnego powodu, ponieważ kopie i strojenie są prostsze, gdy baza stoi obok. Nie wdrażamy klastra w firmie, w której nikt nie zajmuje się infrastrukturą na pełny etat.

Aktualizacja warstw bazowych, sprawdzanie obrazów pod kątem znanych podatności i trzymanie haseł poza obrazem należą natomiast do zakresu zawsze, bo bez nich kontener jest tylko wygodniejszym sposobem uruchomienia starej biblioteki.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a układ z częścią systemów przy hali przy chmurze hybrydowej. Powtarzalny opis hosta, sieci i rejestru powstaje przy infrastrukturze jako kodzie, a przeniesienie firmy wyżej przy migracji do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026