Ten tekst jest dla małej firmy na 5–50 stanowisk, która ma taką aplikację i waha się, czy w ogóle ją ruszać. Po przeczytaniu zdecydujecie: czy aplikacja nadaje się do kontenera, kto ma pilnować obrazów przez lata i ile z tego zostaje na fakturze.
Docker w małej firmie rozwiązuje jeden kłopot: aplikację, której nikt nie potrafi zainstalować drugi raz, bo jej autor odszedł, a serwer pracuje na systemie bez wsparcia. Kontener pakuje program razem ze wszystkim, czego on potrzebuje, do jednej paczki, więc aplikacja wraca na dowolnej maszynie w kilkanaście minut. Kodu nie naprawia, kopii danych nie zastępuje. Spakowanie jednej aplikacji to dwa dni pracy, od 3 900 zł netto.
Nie znajdziecie tu porównania z Kubernetesem ani wykładu o warstwach obrazu. Zostaje jedna sytuacja, w której kontener realnie coś zmienia, i trzy rozstrzygnięcia: czy Wasza aplikacja się do niego nadaje, kto ma pilnować obrazów przez następne lata i ile z tego zostaje na fakturze.
Taka aplikacja zwykle nie sprawia kłopotów. Wystawia dokumenty albo przyjmuje zamówienia, pracuje siódmy rok i nikt jej nie dotyka, bo nie ma powodu. Powód pojawia się w jednym z trzech momentów: gdy padnie dysk, gdy producent systemu kończy wsparcie dla wydania, na którym ona stoi, albo gdy ubezpieczyciel pyta, czemu serwer nie dostał poprawek od dwóch lat.
Wtedy okazuje się, że najdroższa nie jest ani licencja, ani sprzęt.
Najdroższe jest to, że odtworzenie aplikacji staje się śledztwem. Ktoś musi ustalić, jakich bibliotek ona wymaga, skąd czyta ustawienia, w jakiej wersji języka została napisana i dlaczego nie startuje na nowszym systemie. Wiedza o tym nie leży nigdzie zapisana, bo mieściła się w głowie jednej osoby, która już tu nie pracuje. Firma czeka, a ludzie wracają na papier i arkusz kalkulacyjny.
Te dwa rachunki różnią się nie kwotą, tylko tym, kiedy je płacicie. Spakowanie aplikacji przy działającym systemie to praca zaplanowana, wykonana w oknie, które sami wybraliście, i sprawdzona obok starej instalacji. Ta sama praca po awarii to ta sama liczba godzin, tylko wykonana pod presją, bez możliwości przetestowania, i powiększona o dni, w których firma nie wystawia dokumentów. Drugiego składnika nie ma w żadnej ofercie, bo płaci go klient sam sobie.
Wyobraźcie sobie kamienicę. Maszyna wirtualna to osobny dom postawiony obok: własne fundamenty, własne przyłącza, własny piec. Kosztuje więcej i stawia się go dłużej, ale sąsiad nie ma z nim nic wspólnego.
Kontener to mieszkanie w tej kamienicy. Ma własne ściany, własne drzwi z zamkiem, własne meble i własną numerację, więc lokator urządza je po swojemu i nie widzi, co stoi u sąsiada. Ma jednak wspólne fundamenty i wspólną instalację, bo w kamienicy jest jedna. Ta jedna instalacja nazywa się jądrem systemu i należy do serwera, nie do kontenera.
Z tego jednego obrazu wynika wszystko, co warto o kontenerach wiedzieć, i wrócimy do niego trzy razy w tym tekście.
Mieszkanie da się urządzić inaczej niż resztę budynku. Aplikacja w środku kontenera pracuje na swoich bibliotekach, w swojej wersji języka, ze swoimi ustawieniami, i nie obchodzi jej, co zainstalował administrator na serwerze.
Mieszkanie da się przenieść do innej kamienicy. Obraz kontenera to spis całego wyposażenia, więc odtworzenie go pod innym adresem jest skopiowaniem pliku i uruchomieniem jednego polecenia, a nie przeprowadzką z pakowaniem.
Ściana między mieszkaniami nie jest murem obronnym. Fundament jest jeden, więc kto rozbierze podłogę, ten jest w piwnicy całego budynku. Do tego wrócimy w sekcji z werdyktem, bo to jest rzecz, którą w porównaniach z maszyną wirtualną najczęściej się przekręca.
Zysk jest konkretny i sprowadza się do trzech rzeczy.
Mogę Ci jakoś pomóc?
źródło: Pexels, Jan van der WolfCzego kontener nie robi, trzeba powiedzieć równie wprost.
Kontener nie naprawia aplikacji napisanej źle. Program z hasłem wpisanym na stałe w kod, zapisujący dane tam, gdzie własna aktualizacja je nadpisze, albo czekający po każdym starcie na kliknięcie człowieka, zachowuje się w środku obrazu identycznie. Zmienia się jedno: problem dostaje ładniejsze opakowanie i trudniej go zauważyć.
Kontener nie zwalnia też z kopii zapasowych, i to jest kolejne piętro tej samej kamienicy. Dane w kontenerze nie mieszkają, bo mieszkanie jest umeblowane, ale puste: wszystko, co firma wypracowała, leży w piwnicy budynku, czyli na dysku serwera, podpięte do kontenera jak komórka lokatorska. Ransomware zaszyfruje ją równie łatwo jak zawartość udziału sieciowego obok. Obraz odtwarza aplikację, kopia odtwarza treść, i to są dwie różne rzeczy, których nie da się kupić jedną decyzją. Kopia ma leżeć poza tym serwerem, a raz na jakiś czas ktoś musi ją naprawdę odtworzyć, zamiast patrzeć na zielony status zadania.
Sam mechanizm pakowania opisujemy na stronie usługi konteneryzacji . Tutaj chodzi o decyzję, a nie o zakres prac.
Pięć sytuacji, w których mówimy „tak” bez zastanowienia. Wystarczy jedna z nich.
Odradzamy w trzech układach i mówimy o tym, zanim wystawimy ofertę. Aplikacja kupiona od producenta z umową wsparcia zostaje tam, gdzie jest, bo wsparcie obejmuje instalację zrobioną według dokumentacji, a nie zapakowaną po swojemu. Program przypięty do klucza sprzętowego albo do numeru seryjnego maszyny też nie zyskuje nic, skoro licencja i tak przywiązuje go do jednego pudełka. Trzeci układ jest najczęstszy i najmniej oczywisty.
Firmie, która ma jedną aplikację, wspierany system pod nią i żadnych planów przenosin, odradzamy dockeryzację. Za te pieniądze lepiej kupić dwie inne rzeczy: spisaną procedurę odtworzenia środowiska od zera i test tej procedury raz na pół roku, na czystej maszynie. Kosztuje ułamek wdrożenia i odpowiada na to samo pytanie, czyli „co zrobimy, gdy ten serwer nie wstanie”. Kontener przyda się dopiero wtedy, gdy zmieni się którykolwiek z warunków.
Nie ma też przepisu, który każe Wam używać kontenerów. Ani RODO, ani NIS 2 nie wymieniają Dockera i nikt nie odbierze Wam zgodności za jego brak. Wymagany jest utrzymywany, aktualizowany system, a kontener jest jedną z dróg do niego, nie jedyną.
Kontener to narzędzie, nie zgodność.
Dwa dni pracy inżyniera. Rozkładamy je zwykle na tydzień, bo obraz musi poczekać na Wasze testy, a przełączenie planujemy poza godzinami pracy.
latest nie jest wersją i u nas nie występuje na produkcji.
Mogę Ci jakoś pomóc?
Kontenery wpinamy do tego samego monitoringu co resztę infrastruktury, bo osobny panel dla jednej warstwy nikt nie ogląda. Dlaczego alert ma trafiać w jedno miejsce, opisujemy szerzej we wpisie o monitoringu infrastruktury .
To jest pytanie, którego nikt nie zadaje na wdrożeniu, a które decyduje o tym, czy po dwóch latach wyjdzie z tego coś dobrego. Odpowiedź brzmi: obraz aktualizuje człowiek, ręcznie albo skryptem. Nic nie dzieje się samo.
Obraz jest zamrożony w chwili, w której powstał. W środku siedzi konkretna warstwa bazowa z konkretnym zestawem pakietów, a kontener uruchamiany po roku dostaje dokładnie ten sam zestaw co w dniu budowania. Aktualizacja polega na przebudowaniu obrazu od nowa i podmianie działającego kontenera na nowy, więc zawsze jest czyjąś decyzją i czyjąś godziną pracy. Poprawki wpisane do wnętrza działającego kontenera znikają przy pierwszym restarcie.
Teraz najciekawsze, bo widać to dopiero po roku.
Host jest aktualizowany, monitoring świeci na zielono, a skaner podatności zgłasza serwer jako czysty, ponieważ ogląda pakiety systemu, nie zawartość obrazów. Aplikacja zaś pracuje na warstwie bazowej sprzed roku, ze wszystkim, co przez ten rok w niej znaleziono. Firma, która spakowała aplikację właśnie po to, żeby dało się aktualizować system, po roku bez opieki ma ten sam problem piętro niżej: zamiast serwera bez wsparcia stoi u niej obraz bez wsparcia, tylko już nikt tego nie widzi.
Do tego dochodzą dwie rzeczy, które psują się ciszej.
Logi kontenerów domyślnie rosną bez ograniczenia, a nieużywane obrazy i wolumeny zostają na dysku po każdym wdrożeniu. Host przewraca się wtedy na brak miejsca, w środku nocy, i nie ma to nic wspólnego z awarią samej aplikacji.
Druga rzecz to zależność od cudzego rejestru: jeśli obraz bazowy pobieracie z publicznego repozytorium przy każdej przebudowie, to Wasza zdolność do odtworzenia aplikacji zależy od dostępności serwera, na który nie macie żadnego wpływu, i od limitów pobrań, które jego właściciel może zmienić w dowolnym tygodniu. W największym publicznym rejestrze limit wynosi dziś 100 pobrań na sześć godzin z jednego adresu sieciowego bez zalogowania i 200 na sześć godzin dla darmowego konta (stan na 14 sierpnia 2026, odczytane w dokumentacji rejestru). Ten sam adres wychodzący ma zwykle całe Wasze biuro, więc limit dzielicie ze wszystkimi, którzy tego dnia coś pobierali.
Rozstrzygnięcie jest proste i nie ma trzeciej opcji. Albo aktualizowanie obrazów ma u Was właściciela z imienia i nazwiska oraz miejsce w kalendarzu, albo kupujecie to jako usługę. Zdanie „zrobimy to sami, jak będzie trzeba” oznacza w praktyce, że nie zrobi tego nikt, bo nie ma dnia, w którym „jest trzeba”. U nas ten zakres wchodzi w opiekę nad hostem: przebudowa obrazów na świeżej warstwie bazowej, przegląd znanych podatności, rotacja logów i próba, czy po twardym restarcie hosta całość wraca sama.
Jednej rzeczy w szczególności: Docker sam wpisuje sobie reguły w zaporę i robi to poniżej tego, co zapora pokazuje. Port opublikowany w kontenerze bywa osiągalny z internetu również wtedy, gdy firmowy firewall na tym samym serwerze twierdzi, że wszystko jest zamknięte. Administrator patrzy na regułę, która mówi „zablokowane”, i ma prawo uznać, że temat jest załatwiony.
Mechanizm jest prosty i wart jednego zdania, bo bez niego brzmi to jak oskarżenie bez dowodu. Ruch do opublikowanego portu jest przekierowywany na kontener wcześniej, niż dochodzi do miejsca, w którym zapora sprawdza swoje reguły. Producent pisze to wprost w dokumentacji sieci: ruch do kontenera i z kontenera jest odchylany, zanim przejdzie przez ustawienia zapory systemowej. To nie jest błąd konfiguracji, tylko sposób działania narzędzia, i dlatego kosztuje tylu ludzi bazę danych wystawioną do świata.
Wyłączenie Dockerowi prawa do zapory istnieje jako opcja i nie jest to droga, którą chodzimy: wyłączenie zabiera kontenerom sieć.
U nas kontener nie publikuje portu na wszystkich adresach hosta, chyba że ma być publiczny i ktoś świadomie tak zdecydował. Reszta rozmawia po wewnętrznej sieci kontenerów albo przez proxy, które stoi z przodu. Sprawdzenie jest jedno: skan portów z zewnątrz po wdrożeniu, a nie odczytanie reguł z wnętrza serwera. Czym w ogóle jest ta warstwa i co ona filtruje, tłumaczymy we wpisie o firewallu w firmie .
To pytanie pada na każdym spotkaniu i ma odpowiedź, która nie brzmi „to zależy”. Maszyna wirtualna i kontener nie stoją obok siebie, tylko jedno na drugim.
Werdykt: maszyna wirtualna jest podstawą, kontener wchodzi na nią i nie zastępuje jej. Docker w małej firmie pracuje u nas prawie zawsze na maszynie wirtualnej. Osobnej maszyny nie likwidujemy po to, żeby uruchomić kontenery na gołym sprzęcie, bo traci się przy tym migawki, przenoszenie działającej maszyny między hostami i całą procedurę odtworzenia, którą firma już ma i którą jej ludzie znają.
Mogę Ci jakoś pomóc?
Kiedy zostajemy przy samej maszynie wirtualnej | Kiedy dokładamy na nią kontener |
|---|---|
aplikacja jest kupiona i wspierana przez producenta | zależności aplikacji są nie do odtworzenia |
aplikacja wymaga sterownika albo klucza sprzętowego | potrzebne są dwa środowiska z jednego opisu |
to baza danych z realnym obciążeniem | powrót do poprzedniego wydania ma trwać minutę zamiast godziny |
nie ma nikogo, kto zajmie się obrazami |
|
Wirtualizacja daje w pierwszej kolumnie wszystko, co potrzebne: izolację, migawkę przed zmianą i kopię całej maszyny. Prowadzenie takiego środowiska opisuje strona wirtualizacji serwerów .
Tu wraca kamienica z początku tekstu i tu leży rzecz przekręcana najczęściej. Kontener nie jest lżejszą maszyną wirtualną i nie izoluje tak samo. Dom obok ma własne fundamenty, więc awaria u sąsiada nie rusza Waszych. Mieszkanie w kamienicy ma wspólny fundament z każdym innym mieszkaniem, czyli wspólne jądro systemu, a jądro to jest ten kawałek oprogramowania, który realnie rozdziela procesy na maszynie. Kto znajdzie w nim dziurę, ten wychodzi z kontenera na cały serwer. Praktyczny wniosek jest jeden i nie jest teoretyczny: dwie rzeczy o różnym poziomie zaufania, na przykład firmowy system handlowy i coś wystawionego do internetu dla obcych ludzi, nie stoją u nas na tym samym hoście w dwóch kontenerach. Stoją na dwóch maszynach wirtualnych.
Kubernetes nie jest kolejnym stopniem tej drabiny dla firmy na 5 do 50 stanowisk. Odpowiada on na pytanie, jak prowadzić kilkadziesiąt usług naraz i jak podnosić je bez człowieka po awarii węzła, a przy dwóch aplikacjach jest kolejną warstwą do pilnowania i niczym więcej. Sprzedaje się go dobrze i to jest jedyny powód, dla którego pada w tych rozmowach tak często.
Kwoty aktualne na 14 sierpnia 2026, netto.
Spakowanie jednej aplikacji do kontenera zaczyna się u nas od 3 900 zł jednorazowo. W tej kwocie mieści się rozpoznanie, obraz, wyprowadzenie ustawień i danych, prywatny rejestr, uruchomienie obok działającej instalacji oraz instrukcja postawienia całości od zera. Druga aplikacja w tym samym projekcie jest tańsza, bo rejestr, host i procedury już stoją.
Host z kontenerami kosztuje w abonamencie 250 zł miesięcznie, czyli tyle, ile każdy inny serwer, którym się zajmujemy. Tu siedzi odpowiedź na pytanie o aktualizowanie obrazów, bo bez tej pozycji nie ma jej nigdzie. Stawki i to, co wchodzi w abonament, liczy kalkulator obsługi IT , więc nie przepisujemy ich tutaj w całości.
Czego w tych kwotach nie ma i o co warto zapytać, zanim podpiszecie cokolwiek u kogokolwiek:
Czego nie ma w kwocie | Dlaczego stoi osobno |
|---|---|
Sprzęt albo maszyna, na której to stanie | kontener nie jest serwerem i musi mieć na czym pracować |
Licencje samej aplikacji, jeśli jakieś ma | zmiana sposobu uruchamiania nie zmienia warunków, na jakich ją kupiliście |
Praca po stronie autora aplikacji | gdy rozpoznanie wykaże, że program trzeba zmienić, żeby dał się skonfigurować z zewnątrz |
Przepisanie aplikacji na nowszą wersję języka | osobny projekt, najczęściej u kogoś innego, a kontener jedynie kupuje na niego czas |
Przeniesienie danych między silnikami baz | gdy przy okazji zmienia się wersja albo producent bazy |
Miejsce w cudzym rejestrze obrazów, zamiast rejestru u siebie | płaci się tam za zajętą przestrzeń i za transfer wychodzący, więc rachunek rośnie z każdym wdrożeniem |
Klaster Kubernetes | ma własną wycenę i własny projekt, a przy jednej aplikacji w ogóle o nim nie rozmawiamy |
Osobno stoi dyżur poza godzinami pracy helpdesku. Helpdesk pracuje od poniedziałku do piątku, 8:00 do 18:00, i w tych godzinach biegnie zegar reakcji. Dyżur nocny i weekendowy jest osobno płatną usługą, wycenianą po ustaleniu zakresu. Monitoring infrastruktury działa całą dobę i to jest inna warstwa.
Po stronie producenta są dwie pułapki i obie potrafią zaskoczyć rok po wdrożeniu.
Pierwsza dotyczy programu na komputery, a nie serwera. Silnik uruchamiający kontenery na serwerze z Linuksem nie ma opłaty licencyjnej. Graficzna wersja instalowana na komputerze (Docker Desktop) jest sprzedawana w subskrypcji i darmowa pozostaje wyłącznie dla firm, które mają poniżej 250 pracowników i jednocześnie poniżej 10 milionów dolarów rocznego przychodu (warunek producenta, stan na 14 sierpnia 2026). Firma na 5 do 50 stanowisk mieści się w tym progu z ogromnym zapasem, więc ta pułapka dotyczy Was tylko wtedy, gdy rośniecie albo należycie do większej grupy kapitałowej.
Druga dotyczy publicznych rejestrów obrazów. Pobieranie ma limity, limity bywają zmieniane, więc firma budująca obraz raz na kwartał może pewnego dnia zobaczyć, że przebudowa nie przechodzi. Własny rejestr rozwiązuje to za cenę miejsca na dysku i transferu, i dlatego zakładamy go od razu.
Każdy z nich ma tę samą cechę: nie boli w dniu popełnienia.
latest na produkcji. Nikt nie wie, która wersja pracuje, bo nazwa nic nie mówi, a restart hosta potrafi podnieść inny obraz niż ten sprzed restartu. Powrót do poprzedniego wydania przestaje istnieć jako procedura, skoro nie ma czego przywrócić.Piąty błąd nie jest techniczny i wraca najczęściej: kontener wdrożony bez ustalenia, kto go utrzymuje. Wdrożenie się kończy, faktura jest zapłacona, a rzecz zostaje bez opiekuna.
Siedem rzeczy, wszystkie na piśmie i wszystkie Wasze. Umowa nie zawiera zapisu, który wiązałby to z dalszą współpracą.
Kopie zapasowe tych danych prowadzimy w tej samej logice co resztę infrastruktury i osobno je testujemy, o czym więcej we wpisie o taśmach LTO w backupie firmowym . Zakres administracji nad samym hostem opisuje kategoria administracji chmurą i DevOps .
Silnik uruchamiający kontenery na serwerze z Linuksem nie ma opłaty licencyjnej i wolno go używać komercyjnie. Płatna bywa graficzna wersja instalowana na komputerze: producent zostawia ją bezpłatną dla firm poniżej 250 pracowników i poniżej 10 milionów dolarów przychodu rocznie, a powyżej wymaga subskrypcji. Płatne bywa też miejsce w cudzym rejestrze obrazów. Koszt, który realnie ponosicie, to praca kogoś, kto to prowadzi.
Zwykle odradzamy. Kontenery dla Windows są osobnym światem, wymagają zgodności wersji systemu w kontenerze i na hoście, a większość programów pisanych na zamówienie pod Windows i tak wiąże się z usługami systemu. Taką aplikację częściej zostawiamy na maszynie wirtualnej z migawką przed każdą zmianą.
Zamyka problem, ale go nie usuwa. Zysk jest jeden: przestarzała wersja przestaje blokować aktualizacje całej reszty serwera. Sama poprawek już nie dostanie, więc taki kontener zamykamy w sieci wewnętrznej, bez ani jednego portu widocznego z zewnątrz, i ustalamy datę, do której aplikacja ma zostać przepisana.
Ktoś musi, i zwykle wychodzi na to, że my, w abonamencie za host, czyli 250 zł netto miesięcznie. Wariant drugi to Wasza osoba z listy płac, z tym zadaniem wpisanym w zakres obowiązków i w kalendarz. Wariant, w którym nie robi tego nikt, też istnieje i kończy się obrazem sprzed trzech lat.
Nie. Obraz budujemy i sprawdzamy obok działającej instalacji, która przez cały projekt obsługuje ludzi normalnie. Przełączenie to kilkanaście minut wieczorem, w oknie uzgodnionym wcześniej, a poprzednie uruchomienie czeka nietknięte przez następne dwa tygodnie.
Da się i nie kosztuje to drugiego wdrożenia. Stara instalacja zostaje nietknięta do czasu odbioru, a dane leżą na wolumenach hosta w zwykłych plikach, nie w żadnym zamkniętym formacie. Cena wycofania to godzina pracy i przełączenie adresu z powrotem.
Pierwszy krok jest zawsze ten sam i trwa pół dnia: wchodzimy na Wasz serwer i robimy rozpoznanie jednej aplikacji. Dostajecie z niego trzy rzeczy:
Odpowiedź „nie warto” jest u nas normalną odpowiedzią i nie kosztuje Was nic poza tym pół dniem.
Jeśli werdykt jest na „tak”, całość zamyka się w dwóch dniach pracy rozłożonych na tydzień. Zostaje po nich plik budowania obrazu, prywatny rejestr z ponumerowanymi wydaniami, instrukcja postawienia środowiska od zera i przetestowana procedura odwrotu do wcześniejszego wydania, wszystko Wasze. Napiszcie przez formularz kontaktowy , co to za aplikacja i na czym dziś stoi. Pracujemy zdalnie w całej Polsce, a jeśli wolicie rozmowę na miejscu, biuro główne mamy w Gorzowie Wielkopolskim .
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Błąd w lokalnych wersjach Microsoft SharePoint Server pozwala niezalogowanemu napastnikowi podnieść uprawnienia przez sieć. CISA wpisała go do katalogu aktywnie wykorzystywanych podatności. Tekst zestawia fakty, dwie rozbieżne oceny ryzyka i konkretne kroki ochrony.
Czytaj artykułCVE-2026-3055 to podatność urządzeń Citrix NetScaler ADC i Gateway, wykorzystywana w atakach od dnia publikacji. Tekst wyjaśnia mechanizm błędu, warunek zagrożenia, różnice w danych o wersjach naprawionych oraz działania, które należy podjąć w trybie pilnym.
Czytaj artykułPodatność CVE-2026-35273 w Oracle PeopleSoft może skutkować zdalnym wykonaniem kodu, a CISA wiąże ją z kampaniami ransomware. Z tekstu dowiesz się, co to oznacza dla firmy, jak wygląda atak i jakie działania są pilne.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.