Konteneryzacja Docker Kraków

Co centrum usług dostaje razem z przejmowanym procesem

Transfer procesu do Krakowa opisuje się zwykle w kategoriach ludzi i procedur. W praktyce razem z procesem przyjeżdża zestaw narzędzi, o których w dokumentacji transferu jest jedno zdanie albo nie ma go wcale. Arkusz z makrami, który przygotowuje zestawienie dla klienta wewnętrznego. Skrypt zaciągający wyciągi i układający je w plik dla systemu księgowego. Mała aplikacja pilnująca terminów, napisana kiedyś przez kogoś, kto miał dość ręcznego pilnowania.

Każde z tych narzędzi działa i to jest cała trudność. Nie ma powodu, żeby je przepisywać, a jednocześnie nie da się ich przenieść przez skopiowanie katalogu, bo pracują na maszynie ustawianej latami przez człowieka, który został w tamtej lokalizacji.

Kontener rozwiązuje dokładnie ten jeden problem. Zamyka narzędzie razem z wersjami, od których ono zależy, i pozwala uruchomić je u Was w postaci, której nikt po drodze nie poprawił. Nie czyni go lepszym, nie usuwa jego wad i tego nie obiecujemy. Sprawia, że przestaje zależeć od jednej maszyny i jednej osoby.

Dlaczego dokumentacja z transferu zwykle nie wystarcza

Opis przekazywany przy przejęciu procesu powstaje po to, żeby człowiek umiał wykonać pracę. Odpowiada więc na pytanie, co się robi i w jakiej kolejności. Nie odpowiada na pytanie, czego program potrzebuje, żeby w ogóle wystartować, bo autor tego nie widział jako części procesu.

Brakujące informacje są zawsze podobne. Która wersja środowiska uruchomieniowego stoi na tamtym serwerze. Które biblioteki zostały doinstalowane doraźnie i nie ma ich w żadnym opisie. Skąd program czyta ustawienia i który plik jest tym właściwym, gdy w katalogu leżą trzy podobne. Czy zadanie odpala się z harmonogramu systemu, czy uruchamia je ktoś ręcznie w piątek.

Odpowiedzi zdejmujemy z pracującej maszyny, a nie z rozmowy, ponieważ maszyna nie ma powodu niczego pominąć. Rozmowa z autorem jest potrzebna dopiero potem i dotyczy rzeczy, których nie da się odczytać z konfiguracji.

Co trafia do obrazu, a co zostaje na zewnątrz

Element narzędzia	W jakim stanie zwykle przychodzi	Co z nim robimy
Kod i pliki programu	archiwum bez historii zmian	trafia do repozytorium, pierwszy wpis opisuje stan zastany
Lista zależności	w pamięci autora albo nigdzie	spis zdejmowany z pracującej maszyny, wersje zapisane wprost
Ustawienia i adresy	wpisane w pliki obok kodu	wyprowadzone do zmiennych podawanych przy uruchomieniu
Hasła i klucze	w tym samym pliku co ustawienia	przeniesione do menedżera sekretów, poza obraz
Dane i pliki wynikowe	katalog na dysku serwera	wolumen poza obrazem, żeby wymiana wersji ich nie dotykała
Harmonogram uruchomień	wpis w harmonogramie systemu	opisany po stronie hosta, razem z resztą konfiguracji
Dostęp do systemów źródłowych	konto imienne autora	konto techniczne ze wskazanym właścicielem po Waszej stronie

Ostatni wiersz bywa najtrudniejszy i najrzadziej przewidziany w planie transferu. Narzędzie logujące się do systemu źródłowego danymi konkretnej osoby przestaje działać w dniu, w którym ta osoba zmienia hasło albo odchodzi, a stanie się to niezależnie od tego, jak dobrze zostało spakowane.

Jak sprawdzamy, że nowa instalacja liczy to samo

Uruchamiamy obie wersje na tym samym materiale i porównujemy wyniki. Brzmi to banalnie i jest jedyną częścią tej pracy, której nie da się pominąć, bo odbiór transferu opiera się właśnie na tym porównaniu.

Różnice pojawiają się prawie zawsze i prawie zawsze mają wytłumaczenie. Inna strefa czasowa serwera przesuwa dobę rozliczeniową. Inne ustawienie regionalne zmienia separator w pliku wynikowym. Inna wersja biblioteki inaczej zaokrągla ostatnie miejsce po przecinku. Każdą z tych rzeczy trzeba znaleźć przed przełączeniem, ponieważ znaleziona po nim staje się sprawą zgłoszoną przez odbiorcę raportu.

Zestawienie z listą różnic i wyjaśnieniem każdej z nich zostaje u Was jako dowód przeprowadzenia transferu tego narzędzia. Bywa to dokument krótszy niż godzina pracy, a zamyka rozmowę, która bez niego wraca co kwartał.

Co robimy, gdy autor przestaje odbierać telefon

Jest to stan docelowy, a nie awaria, i tak go traktujemy. Okno, w którym da się o cokolwiek zapytać, trwa zwykle kilka tygodni po transferze, potem tamta osoba ma własne obowiązki i pytanie z Krakowa czeka.

Dlatego kolejność pracy jest odwrotna od intuicyjnej. Najpierw zdejmujemy wszystko, co da się odczytać bez człowieka, i uruchamiamy narzędzie u Was. Dopiero z pierwszym uruchomieniem za sobą idziemy do autora z listą pytań, których nie dało się rozstrzygnąć samodzielnie. Taka rozmowa trwa godzinę zamiast tygodnia i nie wymaga dobrej woli po drugiej stronie, tylko jej odrobiny.

Kiedy odradzamy tę pracę

Gdy narzędzie ma zostać zastąpione systemem docelowym w ciągu kilku miesięcy. Pakowanie czegoś, co i tak zniknie, jest wydatkiem bez zwrotu i mówimy to, zamiast przyjmować zlecenie. Gdy narzędzie uruchamiane jest raz w roku przez jedną osobę na jej komputerze i nikt nie planuje tego zmieniać. Gdy program wymaga sprzętowego klucza albo urządzenia podłączonego do konkretnej maszyny, bo wtedy rozwiązaniem jest inny układ, opisany przy chmurze hybrydowej.

Co zostaje u Was

Repozytorium z plikami budowania, obrazy w rejestrze, opis uruchomienia i zestawienie z porównania wyników. Do tego lista kont technicznych ze wskazanymi właścicielami, bo to ona najczęściej decyduje o tym, czy narzędzie przeżyje kolejny rok.

Host, na którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a jego konfigurację zapisujemy zgodnie z infrastrukturą jako kodem. Gdy razem z procesem przenosicie także pocztę i pliki, właściwym projektem jest migracja do chmury, a środowisko oparte na kontach Microsoftu opisuje Azure dla firm. Stawkę za opiekę nad całym IT policzy kalkulator.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026