Konteneryzacja Docker Olsztyn

Co się dzieje z programem, którego przez pół roku nikt nie uruchamiał

W obiekcie nad jeziorem prawie zawsze stoi jakieś własne oprogramowanie i prawie nigdy nie jest tak nazywane. Formularz zapisów na obozy albo kolonie. Panel wypożyczalni kajaków i rowerów, z rezerwacją sprzętu na godziny. Ekran z planem dnia wiszący w holu. Wtyczka spinająca stronę z systemem rezerwacji, napisana kiedyś na zamówienie, bo gotowa nie obsługiwała domków.

Wszystkie mają wspólną cechę: pracują od maja do września i nie są uruchamiane przez resztę roku. W kwietniu ktoś włącza je z powrotem i wtedy zaczyna się rozmowa, która w tym mieście powtarza się co roku. Nie działa. Nikt nie pamięta, na czym to stało. Osoba, która to pisała, odpisała ostatni raz dwa lata temu.

Rzecz w tym, że przez te osiem miesięcy nikt aplikacji nie tknął, a mimo to przestała działać. Zmieniło się otoczenie: system na serwerze dostał aktualizacje, wygasł certyfikat, przestała odpowiadać usługa, z której korzystała, ktoś zmienił hasło do bazy. Aplikacja jest tu ofiarą, nie sprawcą, i dlatego samo znalezienie autora niczego by nie załatwiło.

Dlaczego nikt nie chce ruszyć serwera, na którym on stoi

Bo wszyscy w firmie wiedzą, że po aktualizacji ten program przestanie działać, a nikt nie potrafi powiedzieć, dlaczego. Serwer, na którym pracuje taka aplikacja, jest w związku z tym wyjęty spod wszystkich rozsądnych zasad. Nie dostaje poprawek, nie zmienia się na nim wersji, a przy każdej propozycji zmiany pada zdanie, że lepiej poczekać do listopada.

Do listopada zwykle się nie czeka, bo w listopadzie nikt o tym nie myśli.

Kontener rozwiązuje dokładnie ten węzeł i tylko ten. Aplikacja przestaje być wpięta w system maszyny, bo dostaje własne, zamknięte otoczenie z wersjami zapisanymi w jednym pliku. Serwer można wtedy aktualizować, wymienić albo przenieść w inne miejsce, a aplikacja uruchomi się na nim tak samo, bo niczego ze swojego otoczenia nie bierze z zewnątrz.

Co zamykamy w obrazie, gdy autora nie ma już pod telefonem

Zaczynamy od rozpoznania, bo pakowanie czegoś, czego nie znamy, sprowadza się do trzech pytań. Czego aplikacja potrzebuje, żeby wstać, czyli jakiego środowiska uruchomieniowego i jakich bibliotek. Gdzie dopisuje dane, czyli co przetrwa usunięcie samej aplikacji. Z czym rozmawia na zewnątrz, czyli jaka baza, jaka poczta, jaki system rezerwacji i pod jakimi adresami.

Odpowiedzi na wszystkie trzy da się zebrać bez znajomości kodu, uruchamiając aplikację w osobnym środowisku i obserwując, czego szuka. Trwa to zwykle kilka godzin i kończy się listą, której w firmie nikt wcześniej nie miał.

Potem powstaje obraz z zapisanymi wersjami, ustawienia i hasła wychodzą poza niego, a dane lądują na wolumenie objętym kopią zapasową. Na koniec obraz trafia do prywatnego rejestru i dostaje numer wydania, dzięki czemu za rok będzie wiadomo, co dokładnie pracowało w tym sezonie.

Co się zmienia w kwietniu po tej pracy

Sytuacja	Jak wygląda dziś	Jak wygląda po spakowaniu
Uruchomienie przed sezonem	ktoś próbuje odtworzyć ustawienia z pamięci	pobranie obrazu i jedno polecenie
Aktualizacja serwera	odkładana, bo aplikacja tego nie przeżyje	niezależna od aplikacji, robiona planowo
Przeniesienie na nowy sprzęt	praktycznie drugie wdrożenie	ten sam obraz, inna maszyna
Nieudana zmiana w aplikacji	powrót przez odtworzenie serwera z kopii	uruchomienie poprzedniego wydania
Próba przed sezonem	robiona na tym, co działa naprawdę	osobne środowisko z tego samego obrazu
Awaria w środku lipca	ktoś loguje się na serwer i szuka logów	restart dzieje się sam, logi leżą poza maszyną

Wiersz przedostatni jest w obiekcie sezonowym ważniejszy, niż się wydaje. Bez osobnego środowiska każda próba przed sezonem odbywa się na tym samym, na czym za dwa tygodnie będą zapisywać się goście, więc w praktyce nie odbywa się wcale.

Wiersz ostatni odpowiada z kolei na to, jak wygląda lipiec. W szczycie nikt w obiekcie nie ma czasu wchodzić na serwer i przeglądać w nim logów, a każda minuta spędzona przy konsoli jest minutą zabraną recepcji.

Kiedy odradzamy pakowanie takiej aplikacji

Gdy aplikacja jest gotowym produktem kupionym od producenta, który wspiera ją w swój sposób. Wtedy pakowanie jej po swojemu odbiera Wam prawo do wsparcia, a nam nie daje niczego poza wygodą.

Gdy program i tak ma zniknąć w przyszłym roku, bo obiekt przechodzi na inny system rezerwacji, który robi to samo. Praca wykonana pod coś, co za sezon zostanie wyłączone, jest pracą wykonaną dwa razy.

Gdy aplikacja nie da się skonfigurować z zewnątrz i trzyma dane pomieszane z kodem. Wtedy mówimy o tym po rozpoznaniu i pokazujemy, co musi zmienić się po stronie autora, zanim pakowanie w ogóle będzie miało sens. Zdarza się, że na tym kończymy i tak jest uczciwiej, niż oddać coś, co uruchomi się raz.

Czego przy tej pracy nie bierzemy na siebie

Nie odpowiadamy za to, jak aplikacja liczy, co wyświetla i czy jej logika jest poprawna, bo tego nie pisaliśmy i nie zmieniamy. Odpowiadamy za to, że da się ją uruchomić, że jej dane są objęte kopią, że maszyna pod nią jest aktualna i że powrót do poprzedniego wydania trwa minutę, a nie wieczór.

Nie prowadzimy też rozwoju takiej aplikacji. Jeżeli w obiekcie potrzebna jest zmiana w tym, co program robi, rozmowa dotyczy innego zakresu i innej wyceny, a my mówimy to przed rozpoczęciem, nie w połowie.

Maszynę, na której te kontenery pracują, prowadzimy w ramach opieki opisanej przy administracji chmurą. Jeśli aplikacja ma docelowo pracować poza obiektem, warto zaplanować to razem z migracją do chmury, a układ, w którym część rzeczy zostaje na miejscu, prowadzimy jako chmurę hybrydową. Środowisko pod kontenery opisujemy w plikach, co wyjaśnia infrastruktura jako kod, a obiektom stojącym na kontach Microsoftu pokazujemy Azure dla firm. Stawkę za opiekę nad całym IT policzy kalkulator.

Treść sprawdzona i zaktualizowana: 7 września 2026