Konteneryzacja Docker Szczecin

Co w firmie spedycyjnej warto zamknąć w obrazie

Nie system spedycyjny, bo ten zwykle należy do producenta i ma własne zasady wsparcia. Nie stronę firmową, bo stoi u hostingodawcy i nikomu nie przeszkadza. W praktyce chodzi o coś, co w każdej takiej firmie wygląda podobnie: zestaw niewielkich programów, które przyjmują dane od partnerów, przerabiają je na format zrozumiały dla systemu i odsyłają potwierdzenia.

Każdy z nich powstawał w innym roku, u innego wykonawcy i pod inny wymóg. Jeden potrzebuje starej wersji biblioteki, bo tak działa protokół u odbiorcy. Drugi chce najnowszej, bo tego wymaga certyfikat. Trzeci zapisuje pliki w katalogu obok siebie i przestaje działać, gdy ktoś zmieni uprawnienia. Wszystkie stoją na jednym serwerze i każda aktualizacja jest ruletką.

Kontener rozdziela je bez przepisywania czegokolwiek. Każdy program dostaje własne środowisko z własnym kompletem zależności, a serwer przestaje być miejscem, w którym cztery integracje walczą o jedną wersję biblioteki.

Które elementy pakujemy, a które zostawiamy w spokoju

Element środowiska	Czy pakujemy	Dlaczego
Program przyjmujący komunikaty od partnera	tak	własne wersje bibliotek i szybki powrót do poprzedniego wydania
Konwerter formatów dokumentów	tak	zmienia się przy każdej nowej umowie z odbiorcą
Panel podglądowy dla dyspozytury	tak	wdrażany często, a przerwa w nim nie zatrzymuje ruchu
Baza systemu spedycyjnego	nie	kopie i strojenie są prostsze na maszynie, a producent i tak tego nie wspiera
Obsługa wagi i bramy	nie	rozmawia ze sprzętem podłączonym lokalnie, kontener niczego tu nie upraszcza
Wydruk etykiet przy rampie	nie	zależy od sterowników drukarki i portu w tym samym budynku

Ta tabela jest punktem wyjścia do rozmowy, nie regułą. Zdarza się, że baza w kontenerze ma sens na środowisku próbnym, bo pozwala postawić kopię układu w kilka minut, a na produkcji zostaje na maszynie.

Jak wygląda wydanie nowej wersji

Budujemy obraz, oznaczamy go wersją i wysyłamy do prywatnego rejestru. Na serwerze uruchamiamy nową wersję obok starej, przepuszczamy przez nią komplet danych próbnych od tego partnera i porównujemy wynik z tym, co produkuje wersja działająca. Dopiero potem przełączamy ruch.

Jeżeli po przełączeniu coś zachowuje się inaczej, wracamy do poprzedniego obrazu jednym poleceniem. Trwa to minutę i nie wymaga odtwarzania serwera ani szukania, co dokładnie zostało nadpisane. Ten jeden szczegół zmienia sposób podejmowania decyzji: wdrożenie przestaje być wydarzeniem, na które trzeba się umawiać z wyprzedzeniem tygodnia.

Przy firmach pracujących bez przerwy i tak umawiamy zamianę na przerwę między zmianami. Nie dlatego, że jest ryzykowna, tylko dlatego, że każdy moment zamieszania lepiej trafić w godzinę, w której na placu stoi jedno auto, a nie dwanaście.

Gdzie stoi host z tymi kontenerami

Najczęściej na maszynie w AWS albo Google Cloud, bo tam rejestr obrazów i usługi kontenerowe są zintegrowane z resztą, a koszt działającej usługi łatwo przypisać do konkretnej integracji. Na Azure wtedy, gdy firma ma tam już całe środowisko i chce jedną tożsamość.

Kontenery pracują też na zwykłym serwerze stojącym u Was i w takim układzie prowadzimy je równie chętnie. Ma to nawet przewagę tam, gdzie program musi rozmawiać z czymś w tej samej sieci: z systemem spedycyjnym, z serwerem plików albo z urządzeniem na placu. Wtedy wyprowadzanie go wyżej dokłada opóźnienie i kolejne miejsce, w którym można stracić połączenie.

Host opisujemy w Terraformie razem z resztą środowiska, więc odtworzenie go po awarii nie polega na przypominaniu sobie, co było zainstalowane.

Na co schodzą te dwa dni pracy

Pierwszy dzień to przegląd i obraz. Sprawdzamy, jak program jest konfigurowany, gdzie trzyma dane, czego wymaga do startu i czy da się to wyprowadzić na zewnątrz. Potem powstaje Dockerfile z konkretnymi wersjami, budowany powtarzalnie, z możliwie małą warstwą bazową.

Drugi dzień to uruchomienie i wszystko dookoła: sekrety, wolumeny na dane trwałe, rejestr z wersjonowaniem, limity zasobów, restart automatyczny, zbieranie logów poza hostem i pierwszy przebieg na danych próbnych. Na koniec zostaje u Was opis uruchomienia środowiska od zera i procedura powrotu do poprzedniego wydania.

Czego przy tej pracy nie robimy

Nie przepisujemy aplikacji i nie zmieniamy jej architektury przy okazji. Nie odpowiadamy za treść komunikatów wymienianych z partnerem ani za to, że jego system zmienił format bez uprzedzenia. Nie stawiamy klastra dlatego, że wypada, bo jego utrzymanie kosztuje więcej niż to, co miałby rozwiązać.

Miejsce, w którym te kontenery pracują, opisaliśmy przy administracji chmurą, a układ z częścią systemów na miejscu przy chmurze hybrydowej. Powtarzalny opis hosta i sieci powstaje przy infrastrukturze jako kodzie.

Treść sprawdzona i zaktualizowana: 31 lipca 2026