Konteneryzacja Docker Gdańsk

Dlaczego kalendarz zmian nie należy do Waszej firmy

W większości firm zmiana w oprogramowaniu jest decyzją wewnętrzną. Ktoś uznaje, że warto podnieść wersję, wybiera spokojniejszy tydzień i wykonuje pracę wtedy, gdy jest na nią miejsce. Termin można przesunąć, jeśli wypadnie coś ważniejszego, i zwykle właśnie tak się dzieje.

W firmie, która wymienia komunikaty z systemami celnymi, portowymi i armatorskimi, ta swoboda znika. Datę ogłasza ktoś inny: operator systemu, przewoźnik albo partner zagraniczny wprowadzający nową wersję interfejsu. Komunikat bywa krótki i sprowadza się do jednego zdania: od wskazanego dnia stara droga przestaje odpowiadać.

Skutek jest zawsze ten sam, niezależnie od wielkości firmy. Praca, która w innych warunkach zajęłaby dwa spokojne popołudnia, ląduje w tygodniu przed terminem, obok bieżących spraw, i wykonuje ją zwykle jedna osoba, która akurat zna ten fragment środowiska. Kontener nie zmienia tej daty, natomiast pozwala przygotować się do niej z wyprzedzeniem i sprawdzić efekt, zanim cokolwiek ruszy.

Skąd przychodzą terminy i ile czasu zostawiają

Rodzaj zmiany	Kto ją ogłasza	Ile czasu zwykle daje	Co musi być gotowe wcześniej
Nowa wersja interfejsu wymiany	operator systemu	kilka tygodni do kilku miesięcy	wydanie z nową zależnością i porównanie wyników
Wymiana certyfikatu podpisującego	wystawca albo partner	termin znany z góry, z datą wygaśnięcia	nowy certyfikat poza obrazem i próba przed dniem zmiany
Zmiana formatu przesyłanych plików	kontrahent handlowy	zwykle najkrócej, czasem jeden komunikat	mapowanie pól i przykładowe pliki obu stron
Podniesienie wymaganej wersji szyfrowania	operator systemu	z wyprzedzeniem, ale bez okresu przejściowego	aktualna warstwa bazowa obrazu i test połączenia
Wyłączenie starego adresu docelowego	partner albo jego dostawca	kilka tygodni	adres w konfiguracji, a nie wpisany w kod
Zmiana po Waszej stronie, na przykład nowy klient	Wasz handel	dni	osobna instancja z własnymi kluczami

Ostatni wiersz jest jedynym, w którym decydujecie sami, i właśnie dlatego bywa najgorzej zaplanowany. Nowy zleceniodawca ma zwykle ruszyć od poniedziałku, a przygotowanie łącznika zaczyna się w czwartek. Przy gotowym obrazie jest to uruchomienie kolejnej instancji, a nie kopiowanie katalogu z nadzieją, że nic nie koliduje.

Czego kontener w tej sytuacji nie załatwi

Mówimy to na pierwszym spotkaniu, bo jest to jedyne miejsce, w którym łatwo się rozczarować. Powrót do poprzedniego wydania działa dopóty, dopóki poprzednia wersja po drugiej stronie jeszcze odpowiada. Jeśli operator systemu wyłączył ją tego samego dnia, cofnięcie się niczego nie daje i zostaje naprawianie na bieżąco, przy otwartych sprawach.

Wniosek jest praktyczny i wyznacza cały harmonogram. Przełączamy z zapasem kilku dni przed terminem, a nie w ostatniej możliwej godzinie, żeby powrót w ogóle miał sens. Ten zapas jest jedyną rzeczą, która oddziela zaplanowaną zmianę od nocy spędzonej na poprawianiu czegoś, czego nikt wcześniej nie uruchomił.

Druga rzecz, której obraz nie zrobi, to odpowiedź na pytanie, co dokładnie zmieniło się po drugiej stronie. Dokumentacja partnera bywa krótka, a różnice wychodzą dopiero przy pierwszym prawdziwym komunikacie. Dlatego zawsze pytamy, czy istnieje środowisko próbne, i mówimy wprost, gdy go nie ma.

Jak wygląda przygotowanie do dnia przełączenia

Zaczynamy od zebrania materiału, czyli komunikatów, które przeszły przez stare wydanie w ostatnich tygodniach. Ten zbiór jest później jedynym uczciwym sprawdzianem, ponieważ zawiera także przypadki nietypowe: pozycje odrzucone, korekty i sprawy prowadzone dłużej niż jeden dzień.

Potem powstaje nowe wydanie z przypiętą wersją zależności, oznaczone w prywatnym rejestrze. Uruchamiamy je obok istniejącej instalacji, przepuszczamy zebrany materiał i zestawiamy wyniki pozycja po pozycji. Program potrafi działać bez jednego błędu i wypełniać pole inaczej niż poprzednio, a widać to wyłącznie w porównaniu.

W dniu przełączenia zostaje już tylko wskazanie nowego wydania i obserwacja pierwszych kilkudziesięciu komunikatów: czy przechodzą, czy wracają potwierdzenia i w jakim czasie. Poprzedni obraz leży w rejestrze przez cały ten okres, gotowy do uruchomienia jednym poleceniem, dopóki ma to jeszcze sens.

Co pakujemy, a co zostawiamy w spokoju

Pakujemy łączniki i usługi pisane na własne potrzeby: wysyłkę komunikatów, odbieranie potwierdzeń, przepisywanie danych między systemem spedycyjnym a formatem partnera oraz zadania uruchamiane z harmonogramu. Wszystkie mają tę samą cechę: zmieniają się nie wtedy, gdy Wy chcecie, tylko wtedy, gdy zmienia się coś po drugiej stronie.

Nie pakujemy systemu kupionego od producenta, bo jego wsparcie obowiązuje dla instalacji wykonanej według instrukcji, ani oprogramowania wymagającego klucza sprzętowego wpiętego w serwer. Bazy produkcyjnej zwykle też nie, ponieważ kopie i strojenie są prostsze, gdy stoi obok. W jednej firmie potrafi więc być tak, że dwa łączniki idą do obrazów, a trzeci zostaje na maszynie, i jest to układ normalny, choć w zestawieniu wygląda niekonsekwentnie.

Do zakresu należy natomiast zawsze aktualizowanie warstwy bazowej, sprawdzanie obrazów pod kątem znanych podatności i trzymanie kluczy poza obrazem. Bez tego zamknięcie starej biblioteki w kontenerze tylko ją ukrywa, a przy wymianie danych z systemami zewnętrznymi wymagana wersja szyfrowania i tak wymusi podniesienie warstwy.

Czego przy tej pracy nie robimy

Nie zmieniamy tego, co program liczy, przy okazji jego pakowania, bo to osobne zadanie z własnym ryzykiem i własną wyceną. Nie prowadzimy w Waszym imieniu ustaleń handlowych z partnerem, choć przygotowujemy materiał techniczny do korespondencji. Nie budujemy potoku wdrożeniowego tam, gdzie wydania zdarzają się dwa razy w roku, ponieważ jego utrzymanie kosztuje więcej niż to, co oszczędza.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a decyzję o tym, gdzie stoi punkt wymiany, opisuje chmura hybrydowa. Konta i dostępy w środowisku Microsoftu ustawiamy tak, jak pokazujemy przy Azure dla firm. Host razem z rejestrem wydań zapisujemy w plikach, co pokazujemy przy infrastrukturze jako kodzie, a wyjście firmy z własnej szafy prowadzimy jako migrację do chmury. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026