Konteneryzacja Docker Kielce

Co się dzieje z aplikacją, która wyjeżdża z firmy na cztery dni

Kielecki producent maszyn, konstrukcji albo wyposażenia często ma własny program: konfigurator wyrobu, kalkulator wyceny, katalog z doborem elementów. Powstał, bo handlowiec potrzebował policzyć coś przy kliencie, a arkusz kalkulacyjny przestał wystarczać. Działa na serwerze w firmie i tam wszystko jest w porządku.

Problem zaczyna się wtedy, gdy program ma pojechać na stoisko. Ośrodek targowy stoi w tym mieście, więc kielecka firma bywa wystawcą częściej niż firma z dowolnego innego miasta tej wielkości, a wystawca ma cztery dni, cudzą sieć i rozmowę, przy której nikt nie czeka, aż coś się doinstaluje.

Rozwiązania są zwykle dwa i oba są złe. Albo ktoś instaluje kopię programu na laptopie tydzień wcześniej, albo laptop łączy się przez tunel z serwerem w firmie. Pierwsze daje wersję, która nie jest wersją produkcyjną. Drugie daje pokaz zależny od sieci w hali i od tego, czy w firmie akurat działa łącze, a przy okazji wpuszcza dane wymyślone przy stoisku prosto do bazy.

Dlaczego kopia zainstalowana osobno nigdy nie jest tą samą wersją

Bo instalacja to nie plik, tylko zbiór warunków. Wersja środowiska uruchomieniowego, wersje bibliotek, ustawienia regionalne, sposób zaokrąglania, ścieżki do szablonów wydruku. Wystarczy, że laptop ma nowszą wersję jednej biblioteki, a wynik potrafi różnić się o grosze albo o sposób formatowania, którego nikt wcześniej nie zauważył.

Przy pokazie handlowym to nie jest usterka techniczna, tylko rozmowa z klientem, w której wycena z laptopa nie zgadza się z wyceną, którą ten sam klient dostanie potem pocztą. Obraz kontenera usuwa całą tę klasę różnic, bo zawiera aplikację razem ze wszystkim, czego potrzebuje do uruchomienia. Na stoisku uruchamia się to samo, co na serwerze, tylko na innym sprzęcie.

Ta sama zaleta działa poza targami. Program pokazywany u klienta na próbę, druga instancja dla podwykonawcy, środowisko do przetestowania zmiany przed wdrożeniem: wszystkie startują z jednego obrazu i wszystkie zachowują się tak samo.

Co wchodzi do obrazu, a co zostaje poza nim

Element	Gdzie mieszka	Dlaczego akurat tam
Kod aplikacji i biblioteki	w obrazie	to jest cała rzecz, która ma być wszędzie identyczna
Adresy, tryb pracy, język	zmienne środowiskowe	ten sam obraz musi działać na serwerze i na laptopie
Hasła, klucze, dostępy	sekrety poza obrazem	obraz bywa kopiowany, sekret w nim jest sekretem rozdanym
Dane produkcyjne	wolumen na serwerze, z kopią	mają przeżyć każdą wymianę wersji aplikacji
Dane pokazowe	osobny wolumen zestawu wyjazdowego	żeby zamówienie wpisane przy stoisku nigdzie nie trafiło
Pliki wgrywane przez użytkowników	wolumen objęty kopią	są danymi firmy, a nie częścią programu
Klucz sprzętowy licencji	przy urządzeniu, poza kontenerem	rozmawia po porcie i nie zniesie żadnej warstwy pośredniej
Wydruki i szablony	wolumen albo obraz, zależnie od tego, kto je zmienia	zmieniane przez firmę zostają na zewnątrz

Wiersz piąty jest tym, dla którego warto przeczytać całą tabelę. Rozdzielenie danych pokazowych od produkcyjnych kosztuje przy wdrożeniu kilkanaście minut, a jego brak kosztuje kilka godzin szukania w bazie po każdych targach.

Skąd wiadomo, że wydanie sprzed lat jeszcze się uruchomi

Pytanie o starą wersję nie jest ćwiczeniem teoretycznym w firmie, która sprzedaje wyroby z długim okresem gwarancji. Wraca przy reklamacji, przy sporze o zakres albo przy zamówieniu uzupełniającym, kiedy trzeba pokazać, jak wyliczono coś trzy lata wcześniej i według jakich danych katalogowych.

Rejestr obrazów odpowiada na to jednym poleceniem, o ile wydania są w nim oznaczone wersjami, a nie nadpisywane etykietą oznaczającą najnowsze. Dlatego przy wdrożeniu zawsze robimy próbę odwrotną: pobieramy poprzednie wydanie, uruchamiamy je obok bieżącego i sprawdzamy, że wstaje. Próba, której nikt nie wykonał, jest procedurą, a nie zabezpieczeniem.

Kiedy mówimy, że kontener niczego tu nie poprawi

Gdy wszystkie programy kupujecie od producenta i nie macie ani jednej aplikacji własnej. Producent dostarcza wtedy swój instalator i swoje wymagania, a opakowywanie tego w obraz nie daje nic poza dodatkową warstwą do utrzymania.

Gdy aplikacja jest jedna, wdrażana raz w roku, stoi na dedykowanej maszynie i nikt jej nie rusza. Gdy program musi rozmawiać z urządzeniem podłączonym kablem, bo wtedy i tak zostaje przy tym urządzeniu. Mówimy to na pierwszym spotkaniu, ponieważ te trzy sytuacje wykluczają całą korzyść, a nie zmniejszają ją o połowę.

Za co odpowiada autor aplikacji, a za co my

Nie przepisujemy programu i nie zmieniamy jego budowy przy okazji pakowania. Jeśli trzyma dane w katalogu obok kodu albo nie da się go skonfigurować z zewnątrz, opisujemy zmiany do wykonania po stronie autora i czekamy na nie, zamiast obchodzić problem. Odpowiadamy za obraz, rejestr, wolumeny, host, kopie i za to, że powrót do poprzedniego wydania naprawdę działa. Za logikę wyliczeń, za treść katalogu i za poprawność wyceny odpowiada ten, kto napisał program.

Nie prowadzimy w Kielcach biura ani magazynu części. Wyjazdy umawiamy z wyprzedzeniem, z Krakowa, z biura przy Reducie 26a, a umowę i faktury prowadzi biuro główne w Gorzowie Wielkopolskim przy Baczyńskiego 24.

Host z kontenerami prowadzimy tak samo jak każdy inny serwer, co opisuje administracja chmurą. Jeśli aplikacja ma docelowo pracować poza firmą, warto zaplanować to razem z migracją do chmury, a przy układzie, w którym część zostaje przy biurkach, z chmurą hybrydową. Środowisko oparte na kontach Microsoftu prowadzimy jako Azure dla firm, a host i rejestr opisujemy w plikach zgodnie z tym, co robimy przy infrastrukturze jako kodzie. Stawkę za opiekę nad całym IT policzy kalkulator.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026