Konteneryzacja Docker Lublin

Skąd u przewoźnika bierze się pięć programów, których nikt nie nazwał programami

Pierwszy duży odbiorca prosi o przesyłanie statusów przesyłki w swoim formacie. Ktoś w firmie albo ktoś zaprzyjaźniony pisze skrypt, który raz na kwadrans wystawia plik i wrzuca go tam, gdzie trzeba. Działa, kosztowało tydzień i nikomu nie przeszkadza.

Rok później drugi odbiorca chce tego samego, tylko inaczej. Rok po tym dochodzi giełda transportowa, potem system awizacyjny jednego z magazynów, potem przesyłanie faktur do biura rachunkowego. Za każdym razem powstaje kolejny mały program, każdy pisany w innym momencie, każdy z innym zestawem bibliotek doinstalowanych przy okazji, i wszystkie lądują na tej samej maszynie, bo przecież już stoi.

Firma mówi o tym jako o wymianie danych, nigdy jako o pięciu programach. Widać to dopiero w dniu, w którym aktualizacja potrzebna jednemu odbiorcy psuje coś u drugiego, a nikt nie potrafi wskazać związku.

Co się dzieje, gdy wszystkie mostki stoją na jednej maszynie

Zdarzenie	Na jednej maszynie	W osobnych obrazach
Aktualizacja biblioteki dla jednego odbiorcy	ryzyko dla wszystkich pozostałych wymian	dotyczy wyłącznie tego jednego mostka
Awaria wymiany z dużym odbiorcą	restart usługi zatrzymuje resztę na kilka minut	pozostałe nie zauważają niczego
Dołożenie szóstego kontrahenta	instalacja na maszynie obsługującej pięć działających	nowy kontener obok, bez dotykania reszty
Pytanie, którą wersją poszedł komunikat	data pliku i czyjaś pamięć	oznaczenie wydania zapisane przy komunikacie
Powrót do poprzedniej wersji mostka	odtworzenie maszyny z kopii	uruchomienie poprzedniego obrazu, kilkanaście minut
Przeniesienie wymian na nowy serwer	ponowna instalacja wszystkiego po kolei	pobranie obrazów i podanie ustawień
Odejście autora mostka	nikt nie wie, czego program wymaga do startu	wymagania są w opisie obrazu, nie w niczyjej głowie

Wiersz pierwszy jest tym, przez który firmy odkładają aktualizacje. Skoro każda zmiana może dotknąć wszystkich odbiorców naraz, to najbezpieczniejszą decyzją jest nie zmieniać niczego, aż do dnia, w którym trzeba.

Wiersz ostatni jest z kolei tym, który boli najbardziej i najrzadziej pojawia się w rozmowie przed projektem. Mostek pisany przez jedną osobę zwykle uruchamia się w sposób, którego nikt nie spisał, i to wychodzi dopiero po pierwszym restarcie serwera po jej odejściu.

Dlaczego reklamacja kontrahenta kończy się szukaniem w logach

Duży odbiorca dzwoni i mówi, że nie dostał potwierdzenia dostawy z zeszłego tygodnia. Pytanie brzmi prosto, a odpowiedź w środowisku bez rejestru wydań wymaga pracy detektywistycznej. Ktoś loguje się na maszynę, przegląda katalogi z plikami, sprawdza daty, próbuje ustalić, czy plik w ogóle powstał, i czy wysłanie zakończyło się odpowiedzią systemu odbiorcy.

Trwa to zwykle godzinę i kończy się zdaniem, że u nas wygląda na wysłane. Jest to zdanie prawdziwe i całkowicie bezużyteczne w rozmowie handlowej.

Po spakowaniu ta sama sprawa wygląda inaczej. Dziennik wymiany leży poza hostem, więc jest kompletny także wtedy, gdy maszynę w międzyczasie odtwarzano. Przy każdym komunikacie stoi godzina, odpowiedź systemu odbiorcy i oznaczenie wydania, którym poszedł. Odpowiedź na telefon kontrahenta zajmuje kilka minut i da się ją wysłać na piśmie.

Ma to znaczenie wykraczające poza wygodę. Przewoźnik, który przy każdej niejasności odpowiada faktem, a nie przypuszczeniem, prowadzi zupełnie inną rozmowę o karach umownych niż ten, który odpowiada zapewnieniem.

Co pakujemy, a co zostaje przy urządzeniach

Do obrazów trafia to, co przetwarza dane po ich zebraniu. Wymiany z kontrahentami, mostki do giełd transportowych, przeliczanie zestawień, przygotowanie plików do biura rachunkowego i wszystko inne, co ktoś w firmie dopisał wokół programu spedycyjnego.

Przy urządzeniach zostaje to, co z nimi rozmawia. Odczyt z wagi najazdowej, obsługa odczytu tablic przy bramie, sterowanie dystrybutorem paliwa. Te elementy są związane ze sprzętem i pilnowane przez producenta urządzenia, więc obraz niczego by tam nie uprościł, a przy bramie każdy dodatkowy element to ryzyko.

Sam program spedycyjny również zostaje poza tą pracą, bo jest kupiony u producenta i ma własny sposób wdrażania. Granica przebiega tam, gdzie kończy się to, co dostaliście od dostawcy, a zaczyna to, co dopisaliście sami.

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

Nie przepisujemy mostków i nie zmieniamy tego, co wysyłają, bo za treść komunikatu odpowiada ten, kto go zaprojektował, razem z wymaganiami odbiorcy. My odpowiadamy za obraz, host, rejestr wydań, kopie katalogów wymiany i za to, że uruchomiona jest ta wersja, która została przyjęta. Granicę spisujemy przed startem, bo przy reklamacji nikt nie ma czasu jej ustalać.

Nie stawiamy klastra Kubernetes w firmie, w której infrastrukturą nikt nie zajmuje się na pełny etat, nawet gdy taka nazwa pada w wymaganiach odbiorcy. Przy kilku wymianach wystarcza Docker Compose na jednym hoście i jest to uczciwa odpowiedź, mimo że mniej efektowna.

Aktualizacja warstw bazowych, sprawdzanie obrazów pod kątem znanych podatności i trzymanie haseł poza obrazem należą natomiast do zakresu zawsze, także w miesiącach, w których żaden mostek się nie zmienia.

Rozmowę o zakresie prowadzimy w biurze przy Kresowej 6 albo u Was, najlepiej razem z osobą, która te wymiany rozwija. Umowę i rozliczenia obsługuje biuro główne w Gorzowie Wielkopolskim przy Baczyńskiego 24.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a podział między bazę i część u dostawcy opisuje chmura hybrydowa. Host, sieć i rejestr zapisujemy w plikach tak, jak pokazuje infrastruktura jako kod, a przeniesienie reszty firmy do chmury opisuje migracja do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026