Instalacja Dockera na Debianie 13 i 12 z repozytorium apt

Jak zainstalować Dockera na Debianie 13 i 12

Dockera na Debianie 13 (trixie) i Debianie 12 (bookworm) instalujesz z oficjalnego repozytorium apt firmy Docker. Klucz trafia do /etc/apt/keyrings/docker.asc, a opis repozytorium do pliku /etc/apt/sources.list.d/docker.sources. Potem instalujesz pakiet docker-ce razem z wtyczką Compose. To kilkanaście poleceń, a ten poradnik wyjaśnia każde z nich.

Poradnik jest dla osoby, która przy zamawianiu VPS (virtual private server, czyli wirtualnego serwera prywatnego) wybrała Debiana i teraz potrzebuje Dockera. Docker zwykle nie jest tu celem. Jest warunkiem dla tego, co chcesz uruchomić, na przykład menedżera haseł albo własnej aplikacji. Poradniki o Compose i o Vaultwarden zakładają, że Docker już działa. Tutaj doprowadzamy serwer do tego punktu.

Wszystkie polecenia wpisujesz na swoim serwerze, jako zwykły użytkownik z dostępem do sudo, chyba że opis mówi inaczej. Polecenia instalacyjne pochodzą z dokumentacji docs.docker.com w wersji z 3 października 2026.

Najpierw sprawdź wersję Debiana

Według dokumentacji Dockera (stan na październik 2026) repozytorium obsługuje dwa wydania: Debian 13 trixie i Debian 12 bookworm. Sprawdź nazwę kodową swojego systemu:

. /etc/os-release && echo "$PRETTY_NAME ($VERSION_CODENAME)"

Ten sam plik /etc/os-release za chwilę wybierze właściwy katalog w repozytorium Dockera, więc warto wiedzieć, co w nim jest.

Jeśli nazwa kodowa to bullseye, serwer działa na Debianie 11. Nie instaluj wtedy Dockera według starych poradników dla Debiana 11, które nadal są wysoko w wynikach wyszukiwania. Repozytorium Dockera nie wspiera już tego wydania. Długoterminowe wsparcie bezpieczeństwa Debiana 11 (LTS, long-term support) skończyło się w sierpniu 2026. Świeży Docker na systemie bez poprawek bezpieczeństwa nie rozwiązuje problemu, tylko go ukrywa. Najpierw zaktualizuj system według instrukcji przejścia z Debiana 11 na nowsze wydanie, a potem wróć do tego poradnika.

Czy na minimalnym Debianie są sudo i curl?

Obrazy Debiana u różnych dostawców VPS nie są takie same. Instalator Debiana nie instaluje sudo, jeśli podczas instalacji ustawiono hasło roota. Niektóre minimalne obrazy nie mają też curl. Nie zakładaj niczego, tylko sprawdź:

command -v sudo curl

command -v wypisuje ścieżkę każdego programu, który znalazł. Jeśli dla któregoś programu nie ma wiersza, tego programu nie ma w systemie. Brak curl nie jest problemem, bo instalujemy go w kroku z repozytorium. Brak sudo trzeba naprawić najpierw, jako root:

su -
apt update
apt install sudo
usermod -aG sudo twoj_uzytkownik
exit

Użyj su - z myślnikiem, a nie samego su. Wersja z myślnikiem ładuje pełne środowisko roota, razem z katalogiem /usr/sbin w zmiennej PATH. Polecenie usermod leży właśnie w /usr/sbin, więc bez myślnika powłoka go nie znajdzie. Jeśli dostawca dał Ci tylko konto root, utwórz najpierw zwykłe konto poleceniem adduser twoj_uzytkownik.

Nowa grupa działa dopiero w nowej sesji, bo Linux przypisuje grupy procesowi w chwili logowania. Wyloguj się więc z SSH (Secure Shell) i zaloguj ponownie. Potem uruchom sudo -v. Jeśli polecenie kończy się bez błędu, sudo działa.

docker.io z Debiana czy docker-ce od Dockera?

To jest wybór, który starsze poradniki pomijają. Na Debianie Docker istnieje w dwóch wersjach, z dwóch różnych źródeł:

• docker.io to pakiet Debiana. Budują go opiekunowie Debiana i leży w zwykłym repozytorium systemu. Jego wersja jest ustalona w chwili wydania Debiana, a aktualizacje przychodzą tymi samymi kanałami co reszta systemu.
• docker-ce (Community Edition) to pakiet firmy Docker z repozytorium download.docker.com. Idzie za wydaniami Dockera, a nie za cyklem wydań Debiana. To tę wersję opisuje dokumentacja docs.docker.com.

Ten poradnik instaluje docker-ce, bo dokumentacja Dockera i nasze poradniki o Compose zakładają właśnie ten zestaw pakietów, razem z wtyczką docker compose. Pakiet docker.io też jest poprawnym wyborem, jeśli chcesz mieć na serwerze wyłącznie pakiety Debiana. Nie mieszaj jednak obu źródeł. Pakiety Dockera deklarują konflikt z odpowiednikami z Debiana, więc apt nie zainstaluje obu naraz.

Obu kandydatów porównasz za chwilę poleceniem apt policy, gdy repozytorium Dockera będzie już dodane. Ten poradnik celowo nie podaje numerów wersji. Zmieniają się co kilka tygodni, a apt policy zawsze pokazuje stan aktualny dla Twojego serwera.

Usuń pakiety, które kolidują z docker-ce

Dokumentacja Dockera podaje listę pakietów do usunięcia przed instalacją: docker.io, docker-compose, docker-doc, docker-buildx i podman-docker, a także containerd i runc z Debiana. Jedno polecenie usuwa tylko te z nich, które są zainstalowane:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-doc docker-buildx podman-docker containerd runc | cut -f1)

dpkg --get-selections wypisuje tylko pakiety obecne w systemie, a cut -f1 zostawia z każdego wiersza samą nazwę. Na świeżym VPS ta lista jest zwykle pusta i apt nie ma nic do usunięcia.

Skąd te konflikty? Dwa przykłady wyjaśniają mechanizm:

• podman-docker dostarcza plik /usr/bin/docker, który w rzeczywistości uruchamia Podmana. Pakiet docker-ce-cli chce zainstalować ten sam plik, a dwa pakiety nie mogą być właścicielami jednego pliku. Różnice między tymi narzędziami opisuje porównanie Podmana i Dockera na VPS.
• containerd i runc z Debiana zastępuje pakiet containerd.io od Dockera, który zawiera oba programy. Pakiet containerd.io deklaruje konflikt z tymi pakietami, więc apt nie zainstaluje go obok nich.

apt remove nie usuwa obrazów, kontenerów ani wolumenów zapisanych w /var/lib/docker. Jeśli serwer wcześniej uruchamiał docker.io z ważnymi danymi, zrób kopię wolumenów, zanim zmienisz źródło pakietów.

Dodaj repozytorium Dockera w formacie deb822

To jest krok z dokumentacji Dockera, bez zmian:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Co robi każda część:

• ca-certificates i curl pochodzą z repozytorium Debiana. Pierwszy pakiet daje zaufane certyfikaty dla połączeń HTTPS, drugi pobiera klucz.
• install -m 0755 -d tworzy katalog /etc/apt/keyrings na klucze repozytoriów. Jeśli katalog już istnieje, polecenie niczego nie psuje.
• Klucz GPG (GNU Privacy Guard) Dockera trafia do /etc/apt/keyrings/docker.asc jako zwykły plik tekstowy. chmod a+r daje prawo odczytu wszystkim, żeby apt mógł go przeczytać przy sprawdzaniu podpisów.
• Signed-By wiąże ten klucz z tym jednym repozytorium. Klucz dodany do globalnego zestawu zaufanych kluczy mógłby podpisywać pakiety dla każdego repozytorium w systemie. Tutaj podpisuje tylko pakiety z download.docker.com.
• Suites odczytuje nazwę kodową z /etc/os-release, czyli trixie albo bookworm. Architectures pyta dpkg o architekturę serwera, na przykład amd64 albo arm64.

Plik .sources używa formatu deb822: każde ustawienie ma własny wiersz Pole: wartość. Starsze poradniki tworzą zamiast niego plik docker.list z jednym długim wierszem deb [...]. Oba formaty działają. Problem pojawia się wtedy, gdy na serwerze są oba pliki naraz, na przykład po wcześniejszej próbie instalacji według starego poradnika. Sprawdź, które pliki w konfiguracji apt wskazują na Dockera:

sudo grep -rl download.docker.com /etc/apt/

Na liście powinien zostać tylko /etc/apt/sources.list.d/docker.sources. Jeśli jest na niej też stary docker.list, usuń go i uruchom ponownie sudo apt update. Dwa wpisy dla tego samego repozytorium dają ostrzeżenia o duplikatach. Dwa różne klucze w Signed-By dają błąd, a wtedy apt update się nie udaje. Szczegóły i dokładne komunikaty opisuje poradnik o duplikatach źródeł apt po przejściu na format deb822.

Porównaj docker.io i docker-ce poleceniem apt policy

Teraz apt zna oba źródła, więc możesz porównać obu kandydatów:

apt policy docker.io docker-ce

Dla każdego pakietu apt pokazuje wiersz Candidate, czyli wersję, którą by zainstalował, a pod nią tabelę wersji z adresem repozytorium. Patrz na adresy, nie na numery. Przy docker-ce adres powinien prowadzić do download.docker.com. Przy docker.io będzie to serwer lustrzany Debiana, którego używa Twój VPS. Często to deb.debian.org, ale dostawca może mieć własny serwer lustrzany.

Jeśli docker-ce nie ma kandydata, apt nie przeczytał repozytorium Dockera. apt policy zna tylko pakiety z list pobranych przy ostatnim apt update, więc wróć do wyniku sudo apt update i poszukaj wierszy z błędem przy download.docker.com. Najczęstsza przyczyna to literówka w pliku docker.sources albo brak klucza w /etc/apt/keyrings/docker.asc.

Zainstaluj Docker Engine i wtyczkę Compose

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Nazwy pakietów podajesz wprost, więc apt nie musi wybierać między docker.io a docker-ce. Wszystkie pięć pakietów pochodzi z repozytorium Dockera, download.docker.com:

• docker-ce: silnik Dockera, czyli demon dockerd.
• docker-ce-cli: polecenie docker, którym rozmawiasz z demonem.
• containerd.io: środowisko uruchomieniowe kontenerów containerd razem z runc. To pakiet Dockera, a nie containerd z Debiana.
• docker-buildx-plugin: polecenie docker buildx do budowania obrazów.
• docker-compose-plugin: polecenie docker compose.

Z repozytorium Debiana pochodzą ca-certificates, curl, ewentualnie sudo, oraz zależności, które apt dociągnie sam. Pochodzenie dowolnego pakietu sprawdzisz poleceniem apt policy nazwa_pakietu.

Na Debianie usługa docker startuje automatycznie zaraz po instalacji. Sprawdź, czy obie usługi są włączone przy starcie systemu i czy silnik działa:

systemctl is-enabled docker containerd
systemctl status docker --no-pager

Obie usługi powinny mieć stan enabled, a docker powinien działać (active). Pamiętaj, że to dotyczy samego silnika. Kontenery wracają po restarcie serwera tylko wtedy, gdy mają ustawioną politykę restartu, co opisuje poradnik o automatycznym starcie kontenerów Compose po restarcie serwera.

Ostatni test silnika to krok z dokumentacji Dockera:

sudo docker run hello-world

Polecenie pobiera mały obraz testowy z Docker Hub i uruchamia go w kontenerze. Jeśli kończy się bez błędu, działają silnik i jego połączenie z Docker Hub.

Dlaczego nie skrypt get.docker.com na serwerze

Wiele poradników skraca instalację do jednego polecenia z curl https://get.docker.com. Dokumentacja Dockera mówi wprost, że ten skrypt nie jest zalecany w środowiskach produkcyjnych. Skrypt sam konfiguruje repozytorium i instaluje najnowszą wersję bez pytania. Nie jest też przeznaczony do aktualizacji istniejącej instalacji. Na serwerze, na którym mają działać Twoje dane, lepiej wiedzieć, który plik w /etc/apt za co odpowiada. Ręczna instalacja z tego poradnika daje dokładnie tę wiedzę.

Aktualizacje Dockera na Debianie

Repozytorium Dockera jest teraz zwykłym źródłem apt. Docker aktualizuje się razem z systemem:

sudo apt update && sudo apt upgrade

Aktualizacja pakietu docker-ce restartuje demona dockerd, więc działające kontenery zatrzymują się na chwilę. Kontenery z polityką restartu unless-stopped albo always uruchamiają się ponownie same. Pozostałe trzeba uruchomić ręcznie. Dlatego aktualizacje Dockera planuj tak jak restart serwera, a nie jak drobną zmianę.

Porty kontenerów omijają zaporę: ufw, firewalld i nftables

Dokumentacja Dockera zawiera dwa ostrzeżenia, które na Debianie mają szczególne znaczenie. Pierwsze: jeśli zaporą zarządza ufw albo firewalld, porty opublikowane przez Dockera omijają reguły tej zapory. Drugie: Docker współpracuje tylko z iptables-nft i iptables-legacy, a reguły utworzone bezpośrednio poleceniem nft nie są obsługiwane w systemie z Dockerem.

Pierwsze ostrzeżenie wynika z kolejności przetwarzania pakietów. Opcja -p 8080:80 sprawia, że Docker dodaje regułę DNAT (destination NAT, czyli zmianę adresu docelowego) w tabeli nat. Jądro zmienia adres docelowy pakietu na adres kontenera, zanim pakiet dotrze do łańcucha INPUT. Pakiet idzie więc łańcuchem FORWARD do kontenera, a reguły ufw w łańcuchu INPUT go nie widzą. W efekcie ufw deny 8080 nie blokuje portu kontenera. Pełny opis mechanizmu i sposoby obejścia znajdziesz w poradniku o tym, dlaczego porty Dockera omijają ufw.

Drugie ostrzeżenie dotyczy Debiana bezpośrednio, bo narzędzia zapory w Debianie opierają się na nftables. Na Debianie 12 i 13 polecenie iptables to domyślnie wariant iptables-nft, który zapisuje reguły do tego samego podsystemu nftables w jądrze. Reguły Dockera są więc widoczne w sudo nft list ruleset, obok Twoich. Domyślny plik /etc/nftables.conf w Debianie zawiera polecenie flush ruleset, które usuwa wszystkie tabele, także te założone przez Dockera. Jeśli włączysz albo zrestartujesz usługę nftables z takim plikiem, kontenery stracą reguły sieciowe aż do restartu Dockera. Własne reguły filtrowania ruchu do kontenerów Docker każe dodawać przez iptables do łańcucha DOCKER-USER.

Najprostsza ochrona nie zależy od zapory wcale. Panele administracyjne i aplikacje bez własnego TLS (transport layer security) publikuj tylko na adresie lokalnym:

sudo docker run -d --name test-nginx -p 127.0.0.1:8080:80 nginx
sudo ss -tlnp | grep 8080
sudo docker rm -f test-nginx

W pliku Compose ten sam zapis wygląda tak:

ports:
  - "127.0.0.1:8080:80"

Adres 127.0.0.1 przed numerem portu oznacza, że port nasłuchuje tylko na interfejsie lokalnym serwera. Z internetu nie da się do niego dotrzeć, niezależnie od reguł zapory. W kolumnie adresu lokalnego w wyniku ss sprawdzisz, na jakim adresie port naprawdę nasłuchuje. Do aplikacji dociera wtedy tylko reverse proxy działające na tym samym serwerze, na przykład Caddy albo nginx. Proxy wystawia na zewnątrz porty 80 i 443 i obsługuje certyfikaty TLS. Zapora sieciowa w panelu dostawcy VPS działa poza serwerem, więc jest dobrą dodatkową warstwą, której Docker nie zmienia.

Grupa docker daje uprawnienia roota

Bez sudo polecenie docker nie ma dostępu do demona, bo gniazdo /var/run/docker.sock należy do roota i grupy docker. Pakiet docker-ce tworzy tę grupę przy instalacji. Dokumentacja Dockera pokazuje, jak dodać do niej swoje konto:

sudo usermod -aG docker $USER
newgrp docker

newgrp docker otwiera powłokę z nową grupą w bieżącej sesji. W kolejnych sesjach grupa działa po ponownym zalogowaniu.

Zanim to zrobisz, zrozum koszt. Dokumentacja Dockera mówi wprost, że grupa docker daje uprawnienia na poziomie roota. Mechanizm jest prosty. Demon dockerd działa jako root, a członek grupy docker może kazać mu uruchomić dowolny kontener. Na przykład kontener z całym dyskiem serwera zamontowanym przez -v /:/host, w którym może odczytać /etc/shadow albo zmienić konfigurację sudo. Członkostwo w grupie docker traktuj więc jak sudo bez hasła. Na serwerze z jednym administratorem to świadoma wygoda. Na serwerze z kilkoma kontami nie dodawaj do tej grupy kont, które nie powinny mieć roota.

Alternatywą jest tryb rootless. Demon Dockera działa wtedy jako zwykły użytkownik, więc przejęty kontener nie dostaje uprawnień roota na serwerze. Według dokumentacji Dockera najpierw instalujesz uidmap i docker-ce-rootless-extras, potem wyłączasz systemowego demona. Na końcu uruchamiasz instalator jako zwykły użytkownik, bez sudo:

sudo apt install uidmap docker-ce-rootless-extras
sudo systemctl disable --now docker.service docker.socket
sudo rm /var/run/docker.sock
dockerd-rootless-setuptool.sh install

Tryb rootless ma ograniczenia, na przykład przy publikowaniu portów poniżej 1024. Zanim wybierzesz go na serwer produkcyjny, przeczytaj dokumentację trybu rootless.

Ostatni krok: docker compose version

Na koniec sprawdź wtyczkę Compose, bo od niej zaczyna się większość poradników o self-hostingu:

docker compose version
apt policy docker-compose-plugin

Bez członkostwa w grupie docker pierwsze polecenie uruchom z sudo. Zwróć uwagę na spację: docker compose to wtyczka z pakietu docker-compose-plugin, a nie dawne polecenie docker-compose z myślnikiem, które usunęliśmy razem z pakietem Debiana. apt policy potwierdza, że wtyczka pochodzi z download.docker.com, tak jak reszta silnika.

Jeśli oba polecenia działają, serwer jest gotowy. Dalej warto przejść przez podstawy Docker Compose na VPS, a potem uruchomić pierwszą prawdziwą usługę, na przykład własny menedżer haseł Vaultwarden na VPS. Szerszy obraz pracy z kontenerami na serwerze, od wolumenów po kopie zapasowe, daje poradnik Docker na VPS w praktyce.

FAQ

Czy mogę zainstalować Dockera na Debianie 11?

Repozytorium Dockera, według dokumentacji z października 2026, obsługuje tylko Debiana 13 trixie i Debiana 12 bookworm. Debian 11 bullseye nie dostaje już też poprawek bezpieczeństwa z programu LTS, który skończył się w sierpniu 2026. Stare poradniki dla Debiana 11 nadal są w wynikach wyszukiwania, ale nie warto ich używać. Najpierw zaktualizuj system do Debiana 12 lub 13, a potem zainstaluj Dockera z repozytorium download.docker.com.

Czym różni się docker.io od docker-ce na Debianie?

docker.io to pakiet Debiana z repozytorium systemu, z wersją ustaloną w chwili wydania Debiana. docker-ce to pakiet firmy Docker z repozytorium download.docker.com, który idzie za wydaniami Dockera i który opisuje dokumentacja docs.docker.com. Pakiety deklarują wzajemny konflikt, więc wybierz jedno źródło. Polecenie apt policy docker.io docker-ce pokazuje, z którego repozytorium pochodzi kandydat każdego z nich.

Dlaczego ufw nie blokuje portu kontenera Dockera na Debianie?

Docker publikuje port przez regułę DNAT w tabeli nat, więc pakiet dostaje adres kontenera, zanim dotrze do łańcucha INPUT, w którym działają reguły ufw. Pakiet przechodzi łańcuchem FORWARD i reguła ufw deny go nie zatrzymuje. Panele administracyjne publikuj jako 127.0.0.1:8080:80 i udostępniaj je przez reverse proxy. Na serwerze z Dockerem nie używaj też pliku nftables z flush ruleset, bo usuwa on także reguły Dockera.

Czy dodanie użytkownika do grupy docker jest bezpieczne?

Grupa docker daje uprawnienia na poziomie roota, co dokumentacja Dockera mówi wprost. Członek grupy może uruchomić kontener z zamontowanym całym dyskiem serwera i zmienić w nim dowolny plik. Dodawaj do tej grupy tylko konta, które i tak mają prawo do sudo. Jeśli potrzebujesz izolacji, użyj trybu rootless, w którym demon Dockera działa jako zwykły użytkownik.