Ghid pentru instalarea și configurarea Docker pe Linux

Ghid pentru instalarea și configurarea Docker pe Linux, scris pentru administratorii care vor să ruleze o aplicație izolat de restul serverului: un serviciu de prerandare, un Redis pentru cache, o unealtă internă, un mediu de test identic cu producția. Docker împachetează aplicația cu tot ce are nevoie într-un container care pornește în secunde și nu atinge pachetele sistemului.

Ghidul acoperă instalarea din depozitul oficial pe Ubuntu și AlmaLinux, comenzile de bază, Docker Compose, persistența datelor, rețelele, apoi securitatea și întreținerea, adică partea care lipsește din majoritatea tutorialelor și care contează pe un server cu trafic.

Ghid pentru instalarea și configurarea Docker pe Linux

Ce instalați: pachetele oficiale, nu cele din distribuție

Depozitele distribuțiilor au pachete Docker vechi sau redenumite (docker.io pe Ubuntu, podman-docker pe AlmaLinux). Instalați Docker Engine din depozitul Docker, care aduce și pluginurile compose și buildx, actualizate odată cu restul sistemului.

Pe Ubuntu 22.04 și 24.04

sudo apt update && sudo apt install ca-certificates curl -y
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Pe AlmaLinux 9

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
sudo systemctl enable --now docker

Pe AlmaLinux, SELinux rămâne activ și funcționează cu Docker fără configurare; când montați dosare din sistem în containere, adăugați :z la montare, ca fișierele să primească eticheta potrivită. Contextul este explicat în articolul despre SELinux.

Verificarea și utilizatorul fără sudo

sudo docker run --rm hello-world
sudo usermod -aG docker $USER      # apoi deconectare și reconectare
docker version

Apartenența la grupul docker echivalează cu drepturi de root pe server: oricine din grup poate monta / într-un container și citi orice fișier. Adăugați doar administratorii, niciodată utilizatorii aplicațiilor; regulile pentru conturi limitate sunt în ghidul despre utilizatorii cu acces limitat.

Comenzile pe care le veți folosi

docker pull nginx:1.27                       # descarcă o imagine
docker run -d --name web -p 8080:80 nginx:1.27   # pornește un container în fundal
docker ps                                    # containerele care rulează
docker logs -f web                           # jurnalul containerului
docker exec -it web sh                       # un shell în container
docker stop web && docker rm web             # oprire și ștergere
docker images                                # imaginile de pe disc

Câteva reguli. Fixați versiunea imaginii (nginx:1.27, nu nginx:latest), altfel o actualizare neplanificată schimbă comportamentul. Numiți containerele, ca jurnalele și comenzile să fie lizibile. Publicați porturile doar pe interfața de care aveți nevoie: -p 127.0.0.1:8080:80 lasă serviciul accesibil doar local, pentru un proxy din față, în timp ce -p 8080:80 îl deschide spre internet, ocolind firewall-ul UFW, o surpriză frecventă descrisă în ghidul despre firewall-ul UFW.

Compose: aplicația descrisă într-un fișier

O aplicație reală are mai multe containere: aplicația, baza de date, cache-ul. Compose le descrie într-un fișier YAML și le pornește împreună, cu rețea și volume proprii:

services:
  app:
    image: ghcr.io/firma/aplicatie:2.4.1
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    env_file: .env
    depends_on:
      - db
      - cache
  db:
    image: mariadb:11.4
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root
    volumes:
      - date-db:/var/lib/mysql
    secrets:
      - db_root
  cache:
    image: redis:7-alpine
    restart: unless-stopped
volumes:
  date-db:
secrets:
  db_root:
    file: ./secrete/db_root.txt

docker compose up -d          # pornește tot
docker compose ps             # starea serviciilor
docker compose logs -f app    # jurnalul unui serviciu
docker compose pull && docker compose up -d   # actualizare la versiunile din fișier
docker compose down           # oprește și șterge containerele, păstrează volumele

restart: unless-stopped face containerele să pornească singure după repornirea serverului. Parolele nu se scriu în fișierul Compose, ci în .env sau în secrete, iar .env nu ajunge în depozitul de cod.

Datele: volume și montări

Tot ce scrie un container în propriul sistem de fișiere dispare la ștergerea lui. Datele care trebuie să rămână stau în volume (administrate de Docker, în /var/lib/docker/volumes) sau în montări de dosare din sistem (bind mounts). Volumele sunt potrivite pentru baze de date; montările, pentru fișiere pe care vreți să le editați din exterior, de exemplu configurații.

docker volume ls
docker volume inspect aplicatie_date-db
docker run --rm -v aplicatie_date-db:/date -v $(pwd):/backup alpine tar -czf /backup/date-db.tar.gz -C /date .

Ultima comandă arhivează un volum într-un fișier, metoda de copiere de siguranță pentru volume. Pentru baze de date, exportul logic (mysqldump rulat prin docker exec) rămâne mai sigur decât arhivarea fișierelor la cald; integrarea în rutina de copii este în ghidul despre copiile de siguranță cu cron și rsync.

Rețele

Compose creează o rețea pentru fiecare proiect, în care serviciile se văd după nume: aplicația se conectează la baza de date la adresa db:3306, fără port publicat. Doar serviciul care trebuie accesat din exterior publică un port, de preferat pe 127.0.0.1, cu un server web din față (Nginx sau Apache) care face TLS și trimite cererile mai departe; configurarea proxy-ului este în articolul despre Nginx ca reverse proxy.

Securitate pe un server de producție

• Nu rulați containere cu --privileged și nu montați /var/run/docker.sock în containere decât dacă știți exact de ce.
• Rulați procesele din container ca utilizator neprivilegiat (directiva USER în Dockerfile sau user: în Compose). Majoritatea imaginilor oficiale o permit.
• Folosiți imagini oficiale sau verificate și scanați-le: docker scout cves imagine arată vulnerabilitățile cunoscute.
• Limitați resursele: mem_limit și cpus în Compose opresc un container scăpat de sub control să oprească serverul.
• Actualizați imaginile lunar, cu docker compose pull și up -d, după ce ați citit notele versiunii.
• Porturile publicate de Docker ocolesc UFW și firewalld. Publicați pe 127.0.0.1 sau configurați lanțul DOCKER-USER din iptables.

Jurnale, întreținere, curățare

Jurnalele containerelor cresc fără limită cu driverul implicit. Setați rotația global în /etc/docker/daemon.json și reporniți serviciul:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "5" }
}

Imaginile vechi, containerele oprite și volumele orfane ocupă zeci de GB după câteva luni. Verificați și curățați periodic:

docker system df
docker system prune -a --volumes   # atenție: șterge și volumele nefolosite de niciun container
docker image prune -a              # doar imaginile nefolosite

Consumul containerelor se vede cu docker stats, iar la nivel de sistem cu htop și atop; jurnalul serviciului Docker se citește cu journalctl -u docker, după metoda din ghidul journalctl.

Un exemplu complet: serviciu de prerandare pentru un site

Un caz pe care îl întâlnim la clienții cu aplicații scrise în JavaScript, unde motoarele de căutare au nevoie de HTML gata randat, iar aplicația îl produce doar în browser. Un serviciu de prerandare rulează într-un container, pe portul 3001, doar local, iar serverul web trimite spre el cererile roboților. Fișierul Compose are un singur serviciu, cu limită de memorie și repornire automată:

services:
  prerender:
    image: tvanro/prerender-alpine:5.9.1
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3000"
    environment:
      MEMORY_CACHE: "1"
      CACHE_MAXSIZE: "2000"
      CACHE_TTL: "3600"
    mem_limit: 1g
    cpus: "1.0"

Serviciul pornește cu docker compose up -d, se verifică cu curl pe 127.0.0.1:3001 urmat de adresa unei pagini, iar jurnalul se citește cu docker compose logs. Când imaginea primește o versiune nouă, schimbați eticheta în fișier, rulați pull și up -d; containerul vechi este înlocuit în câteva secunde, iar dacă noua versiune nu pornește, reveniți la eticheta veche cu aceleași două comenzi. Această rutină, identică pentru orice serviciu, este motivul pentru care preferăm containerele pentru uneltele auxiliare ale unui site.

Dockerfile: propria imagine

Când aplicația nu are o imagine publică, o construiți dintr-un Dockerfile: o imagine de bază, dependențele, codul, utilizatorul de rulare și comanda de pornire. Trei reguli scurtează timpul de construire și mărimea imaginii: folosiți imagini de bază mici (alpine sau slim), copiați întâi fișierele de dependențe și instalați-le, abia apoi restul codului (ca stratul cu dependențe să fie refolosit din cache), și adăugați un fișier .dockerignore cu tot ce nu trebuie în imagine (.git, node_modules, fișiere locale). Construirea se face cu docker build -t firma/aplicatie:1.0 . și imaginea se folosește în Compose exact ca una publică.

Întrebări pe care le primim

1. Docker încetinește aplicația? Pe Linux, containerele rulează direct pe nucleul gazdei, fără virtualizare; diferența de performanță față de instalarea nativă este de obicei sub câteva procente.
2. Pot rula Docker pe o găzduire partajată? Nu; are nevoie de drepturi de root pe server. Este pentru servere virtuale sau dedicate.
3. Podman în loc de Docker? Pe AlmaLinux, Podman este alternativa preinstalată, compatibilă la nivel de comenzi și fără daemon; pentru Compose există podman-compose. Dacă echipa știe Docker, rămâneți la Docker; dacă începeți de la zero pe AlmaLinux, Podman merită încercat.
4. Ce fac cu datele când șterg un container? Nimic nu se pierde dacă datele sunt în volume sau în montări; verificați cu docker volume ls înainte de prune.

Când Docker nu este alegerea potrivită

Pentru un singur site PHP pe un server mic, stiva instalată direct, ca în ghidul despre LAMP pe Ubuntu, este mai simplu de administrat și de depanat. Docker aduce valoare când aveți mai multe aplicații cu dependențe diferite, când mediul de test trebuie să fie identic cu producția sau când aplicația vine deja împachetată. Pe serverele cu cPanel, containerele rulează în paralel cu panoul, dar nu sunt administrate de el; pentru servicii precum cache-ul, instalarea Redis se face de obicei nativ.

Surse

• Documentația Docker, instalarea Docker Engine: pașii oficiali pe fiecare distribuție și pașii de după instalare.
• Documentația Ubuntu Server: administrarea pachetelor, a serviciilor și a firewall-ului pe serverul gazdă.