Konteneryzacja Docker Warszawa

Kto odpowiada za serwer pod aplikacją, którą sami napisaliście

W warszawskich firmach z własnym produktem cyfrowym układ powtarza się niezależnie od tego, czy jest to agencja, dostawca oprogramowania dla jednej branży, czy dział rozwijający system używany wewnątrz grupy. Jest zespół, który pisze kod, i jest serwer, na którym ten kod działa. Zespół zna aplikację. Serwer zna zwykle jedna osoba, często ta sama, która go kiedyś uruchomiła, i zwykle nie jest to jej główne zadanie.

Dopóki wszystko działa, podział nie przeszkadza. Zaczyna przeszkadzać przy pierwszej awarii, której przyczyna nie jest oczywista. Zespół twierdzi, że aplikacja się nie zmieniła. Osoba od serwera twierdzi, że nie zmieniła się konfiguracja. Obie strony mówią prawdę, bo zmieniła się wersja biblioteki doinstalowanej przy okazji czegoś innego.

Drugi moment to rotacja. W Warszawie zespoły zmieniają się szybciej niż gdziekolwiek indziej, a wraz z odejściem jednej osoby znika wiedza o tym, co i dlaczego zostało zainstalowane na maszynie. Aplikacja nadal działa, tylko nikt nie potrafi jej postawić drugi raz.

Co pakujemy, a czego nie ruszamy

Element środowiska	Czy pakujemy	Dlaczego
Usługa aplikacyjna Waszego produktu	tak	wydania są częste, a powrót do poprzedniej wersji musi trwać chwilę
Zadania uruchamiane z harmonogramu	tak	mają własne zależności i najczęściej gryzą się z usługą główną
Usługa pomocnicza pisana pod jednego klienta	tak	powstaje i znika razem z projektem, więc nie powinna zostawiać śladu na hoście
Baza produkcyjna	zwykle nie	kopie, strojenie i wsparcie są prostsze na maszynie albo w usłudze zarządzanej
System kupiony od producenta	nie	wsparcie obowiązuje dla instalacji wykonanej według jego instrukcji
Usługa zależna od sprzętu w biurze	nie	rozmawia z urządzeniem po lokalnej sieci, kontener niczego tu nie upraszcza

Trzeci wiersz bywa najbardziej niedoceniany. Usługa napisana na potrzeby jednego wdrożenia zostaje na serwerze latami po zakończeniu projektu, bo nikt nie ma pewności, czy można ją usunąć. W obrazie widać wprost, kiedy powstała, czego wymaga i co przestanie działać po jej wyłączeniu.

Gdzie przebiega granica odpowiedzialności po spakowaniu

Przed spakowaniem granica jest umowna i przesuwa się w zależności od tego, kto akurat ma czas. Po spakowaniu daje się ją zapisać jednym zdaniem: zespół produktu dostarcza obraz z oznaczeniem wersji, my dostarczamy miejsce, w którym ten obraz się uruchamia, i wszystko, czego do tego trzeba.

Po naszej stronie zostaje host razem z systemem, sieć, certyfikaty, rejestr obrazów, kopie danych trwałych, limity zasobów, monitoring i dzienniki. Po stronie zespołu zostaje zawartość obrazu, czyli kod, biblioteki i sposób uruchomienia procesu. Konfiguracja jest wspólna i to jedyne miejsce, w którym podział wymaga rozmowy: adresy i parametry środowiskowe ustalamy razem, a dane dostępowe trzymamy w sekretach, do których obie strony mają wskazany zakres.

Podział spisujemy przed startem. Nie dlatego, że spodziewamy się sporu, tylko dlatego, że przy zgłoszeniu o drugiej po południu nikt nie ma czasu ustalać, kto powinien się nim zająć.

Skąd bierze się różnica między próbami a produkcją

Z instalowania obu środowisk osobno, zwykle w odstępie kilku miesięcy i przez różne osoby. Serwer prób dostaje wersję biblioteki dostępną w dniu instalacji, produkcja tę z dnia swojego uruchomienia, a po roku różnic jest kilkanaście i żadna nie została zapisana.

Obraz zdejmuje tę kategorię problemów, bo oba środowiska powstają z tego samego pliku i różnią się wyłącznie podanymi wartościami. Zostają dwie różnice, których kontener nie usuwa i o których mówimy wprost: dane oraz moc sprzętu. Próba na kopii sprzed miesiąca zachowa się inaczej niż produkcja z pełnym zbiorem, a maszyna o połowie zasobów pokaże inne czasy odpowiedzi.

Na co idą te dwa dni pracy

Pierwszy dzień to rozpoznanie i obraz. Sprawdzamy, jak usługa jest konfigurowana, gdzie zapisuje dane, czego wymaga przy starcie i czy da się to wyprowadzić na zewnątrz. Potem powstaje opis budowania z przypiętymi wersjami i możliwie małą warstwą bazową, sprawdzany przez zbudowanie go dwa razy z rzędu.

Drugi dzień to uruchomienie i wszystko dookoła: sekrety, wolumeny, rejestr z oznaczeniami wydań, limity zasobów, restart automatyczny, zbieranie dzienników poza hostem i pierwszy przebieg obok istniejącej instalacji. Porównanie wyników obu wersji na tych samych danych wejściowych jest krokiem, którego nie pomijamy, bo usługa potrafi działać bez błędu i liczyć inaczej niż poprzednio.

Na koniec zostaje u Was opis uruchomienia środowiska od zera oraz procedura powrotu do poprzedniego wydania.

Kiedy odradzamy klaster, mimo że pada w wymaganiach

Gdy usług jest kilka, a nie kilkadziesiąt, i pracują na jednym hoście. Klaster odpowiada na problem skali oraz samodzielnego podnoszenia usług, a płaci się za to złożonością, którą ktoś musi potem pilnować. W firmie bez osoby zajmującej się infrastrukturą na pełny etat ta złożoność wraca jako koszt, a nie jako zysk.

Gdy w wymaganiach klienta pada nazwa narzędzia, pytamy o cel zapisu. Zwykle chodzi o to, żeby usługa nie znikała przy awarii jednej maszyny i żeby dało się ją odtworzyć. Oba warunki da się spełnić dwiema instancjami za rozdzielaczem ruchu i opisem środowiska w repozytorium, a to jest wielokrotnie tańsze w utrzymaniu.

Czego przy tej pracy nie robimy

Nie przepisujemy aplikacji i nie zmieniamy jej architektury przy okazji pakowania. Nie odpowiadamy za wydajność kodu ani za decyzje projektowe zespołu, choć mówimy, kiedy problem leży tam, a nie w infrastrukturze. Nie budujemy potoku wdrożeniowego tam, gdzie wydania zdarzają się raz na pół roku, bo koszt jego utrzymania przewyższy oszczędność.

Miejsce, w którym te kontenery pracują, prowadzimy w ramach administracji chmurą, a układ z częścią systemów w biurze albo w kolokacji przy chmurze hybrydowej. Powtarzalny opis hosta, sieci i rejestru powstaje przy infrastrukturze jako kodzie. Zakres ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026