Konteneryzacja Docker Gorzów Wielkopolski

Skąd w gorzowskich firmach biorą się kontenery

Rzadko z decyzji o technologii. Częściej z aplikacji, która powstała na zamówienie: portal zamówień dla stałych odbiorców hurtowni, sklep internetowy podpięty do systemu magazynowego, program do rozliczania zleceń w serwisie albo integracja spinająca dwa systemy, których producenci ze sobą nie rozmawiają. Aplikacja została uruchomiona raz, na serwerze wskazanym przez wykonawcę, i od tamtej pory działa.

Problem pojawia się przy pierwszej większej zmianie. Trzeba przenieść ją na nowszy serwer, przetestować poprawkę albo postawić drugą kopię do wdrożenia nowej wersji systemu. Wtedy okazuje się, że nikt nie wie, jakie biblioteki są zainstalowane, skąd program czyta ustawienia i dlaczego działa tylko na tej jednej maszynie. Kontener jest odpowiedzią na to pytanie, a nie na modę.

Które aplikacje warto pakować, a które nie

Co spotykamy w firmach	Czy warto pakować	Co się przez to zmienia
Portal zamówień pisany na zamówienie	tak	uruchomienie na nowym serwerze zajmuje minuty, nie dzień
Sklep internetowy z integracją do magazynu	tak	zmiany testujemy na kopii, zanim zobaczy je klient
Wewnętrzna aplikacja do zleceń	tak	wraca poprzednia wersja, gdy poprawka okaże się gorsza
System handlowy kupiony od producenta	nie	wsparcie obowiązuje tylko dla instalacji według instrukcji
Program przypięty do klucza sprzętowego	nie	licencja i tak wiąże aplikację z konkretną maszyną
Baza produkcyjna z dużym obciążeniem	zwykle nie	prościej utrzymać ją na maszynie, razem z kopią i strojeniem

Ostatni wiersz bywa zaskoczeniem, bo baza w kontenerze świetnie sprawdza się na środowisku testowym. Na produkcji częściej zostawiamy ją poza kontenerem, żeby odtworzenie danych nie wymagało rozumienia dwóch warstw naraz.

Co się dzieje, gdy wykonawca aplikacji przestaje odbierać telefon

To najczęstszy powód, dla którego gorzowskie firmy dzwonią do nas w tej sprawie. Firma, która pisała program, zmieniła profil, rozpadła się albo po prostu przestała odpowiadać, a aplikacja nadal obsługuje zamówienia. Ryzyko nie polega na tym, że przestanie działać z dnia na dzień. Polega na tym, że gdy padnie dysk w serwerze, nikt nie będzie potrafił postawić jej na nowo.

Po spakowaniu do obrazu ta wiedza przestaje być czyjąkolwiek własnością. Obraz buduje się jednym poleceniem, uruchamia na dowolnej maszynie z Dockerem, a opis środowiska leży w repozytorium razem z listą wersji. Dopiero wtedy rozmowa o nowym wykonawcy jest rozmową o rozwoju aplikacji, a nie o jej odzyskiwaniu.

Gdzie te kontenery pracują u naszych klientów

Najczęściej na maszynie wirtualnej w firmowej serwerowni, bo aplikacja i tak rozmawia z systemem magazynowym stojącym obok. Host stawiamy wtedy na Proxmoksie albo Hyper-V, z limitem zasobów i automatycznym restartem po zaniku zasilania. Serwer stoi u Was, więc dysk, zasilacz czy przełącznik wymieniamy na miejscu, bez czekania na przesyłkę.

Drugi wariant to maszyna w chmurze, wybierany wtedy, gdy z aplikacji korzystają też ludzie spoza biura albo gdy ma działać niezależnie od budynku. Rejestr obrazów prowadzimy w tym samym miejscu co host, żeby wdrożenie nie zależało od usługi, której nikt nie pilnuje.

Na co schodzą te dwa dni pracy

1. Rozpoznanie. Sprawdzamy, na czym aplikacja stoi dzisiaj: wersje bibliotek, sposób konfiguracji, miejsce zapisu danych i to, czego wymaga do pierwszego uruchomienia.
2. Obraz. Powstaje opis budowania z przypiętymi wersjami, tak żeby to samo polecenie dawało ten sam wynik również za dwa lata.
3. Wyprowadzenie ustawień. Hasła, adresy i klucze wychodzą z obrazu do zmiennych i sekretów, dzięki czemu jedna paczka służy testom i produkcji.
4. Uruchomienie obok. Wersja w kontenerze startuje równolegle do obecnej i dopiero po testach przejmuje ruch.
5. Przekazanie. Rejestr, instrukcja uruchomienia od zera i krótkie szkolenie dla osoby, która będzie to wdrażać po naszej stronie umowy.

Czego przy dockeryzacji nie robimy

Nie przepisujemy aplikacji i nie zmieniamy jej działania. Jeśli program trzyma hasła w pliku obok kodu albo zapisuje dane do katalogu, który przy każdej aktualizacji jest kasowany, mówimy o tym w raporcie i proponujemy zmiany do wykonania po stronie autora. Obudowanie takiej aplikacji kontenerem ukryłoby problem na kolejny rok.

Nie wdrażamy też Kubernetesa dla dwóch usług i nie budujemy potoku CI/CD tam, gdzie wdrożenia zdarzają się raz na pół roku. Sprzęt, na którym host ma stanąć, dobieramy osobno, a jego bieżące utrzymanie opisuje administracja serwerami Linux. Jeśli aplikacja ma docelowo pracować poza Waszym budynkiem, właściwą drogą jest migracja do chmury, a całe środowisko warto przy okazji zapisać w kodzie, co pokazujemy przy infrastrukturze jako kodzie.

Treść sprawdzona i zaktualizowana: 31 lipca 2026