Ce este Docker și de ce ar trebui developers să o învețe?
O analiză practică a Docker pentru developers: containere vs mașini virtuale, comenzi principale, Dockerfiles și cum să o începi să folosești în proiecte reale.
Docker apare constant în anunțurile de angajare și ghidurile de configurație, iar dacă nu ai lucrat niciodată cu containere poate să pară ca un zid pe care trebuie să-l urci înainte să poți scrie cod adevărat. Nu e atât de complicat odată ce treci peste vocabular.
Ce este de fapt un container
Un container împachetează aplicația ta cu totul ce are nevoie ca să ruleze: codul, runtime, bibliotecile de sistem și fișierele de configurație. Nu e o mașină virtuală. O VM virtualizează un întreg sistem de operare, kernel inclus, ceea ce înseamnă că pornirea ei poate dura un minut și consuma câțiva gigabytes de RAM. Un container împarte kernelul mașinii gazdă și izolează doar procesul, deci pornește în mai puțin de o secundă și folosește de obicei zeci de megabytes în loc de gigabytes.
Acea diferență e motivul pentru care Docker a cucerit rapid dezvoltarea locală și conductele CI. Poți porni o bază de date Postgres, o memorie cache Redis și serverul tău de aplicații pe un singur laptop fără să instalezi nimic direct pe OS.
Piesele principale pe care trebuie să le știi
Există patru termeni care acoperă majoritate a ceea cu ce vei lucra zilnic:
- Image: un șablon read-only construit dintr-un Dockerfile. Gândește-te la el ca la un snapshot al unui sistem de fișiere plus metadate despre cum să-l rulezi.
- Container: o instanță rulând a unei imagini. Poți porni, opri și șterge containere fără a atinge imaginea din care provin.
- Dockerfile: un fișier text cu instrucțiuni pentru a construi o imagine, linie cu linie.
- Registry: unde sunt stocate imaginile și din unde sunt extrase, cel mai des Docker Hub.
Un Dockerfile minim pentru o aplicație Node.js arată așa:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Constructo-l cu docker build -t my-app . și rulează-l cu docker run -p 3000:3000 my-app. Semnul -p mapează un port pe mașina ta la un port în interiorul containerului, ceea ce e cum ajungi de fapt la aplicație din browserul tău.
Comenzi pe care le vei folosi constant
O mână de comenzi acoperă majoritate a lucrului zilnic:
docker ps— listează containerele în curs de rularedocker ps -a— listează toate containerele, inclusiv pe cele opritedocker images— listează imaginile pe mașina tadocker logs <container>— verifică output-ul dintr-un container în curs de rulare sau stricatdocker exec -it <container> sh— deschide o shell în interiorul unui container în curs de rularedocker rm/docker rmi— curăță containerele și imaginile de care nu mai ai nevoie
Acea ultimă pereche contează mai mult decât se așteaptă oamenii. Docker va lăsa cu plăcere spațiul pe disc să dispară în imagini vechi și containere oprite. Rularea docker system prune din când în când recuperează o cantitate surprinzător de mare de spațiu.
De ce docker-compose schimbă fluxul de lucru
Majoritate proiectelor reale au nevoie de mai mult decât un container: un server de aplicații, o bază de date, poate o memorie cache. Scrierea comenzilor docker run pentru fiecare devine obositoare rapid. docker-compose.yml îți permite să definești întreaga stivă într-un singur fișier:
services:
web:
build: .
ports:
- "3000:3000"
depends_on:
- db
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: devpassword
volumes:
- db_data:/var/lib/postgresql/data
volumes:
db_data:
Rulează docker compose up și ambele servicii pornesc împreună, în rețea, deci web poate ajunge la db după numele serviciului. Aceasta e configurația pe care o vei vedea în aproape orice README de repo open-source, iar înțelegerea ei înseamnă că poți clona un proiect și să-l ai rulând în minute în loc să instalezi manual Postgres, Redis și orice altceva are nevoie aplicația.
Unde oamenii se blochez devreme
Volumele confundă aproape pe toată lumea la început. Fără un volum, orice scris în interiorul unui container dispare când containerul e șters, ceea ce e o problemă pentru baze de date. Secțiunea volumes în fișierul compose de mai sus mapează un volum numit la o cale în interiorul containerului, deci datele supraviețuiesc restarturilor.
O altă greșeală comună e copierea node_modules sau .git în imagine pentru că nu există fișier .dockerignore. Adaugă-l exact ca un .gitignore:
node_modules
.git
.env
Aceasta ține construcțiile mai rapide și imaginile mai mici, ceea ce contează odată ce trimiți imagini la un registry sau dezvolți în Kubernetes.
Unde să mergi după noțiunile de bază
Odată ce construirea și rularea containerelor e ceva normal, abilitățile următoare utile sunt construcțiile multi-etapă pentru imagini de producție mai mici, înțelegerea modurilor de rețea Docker și citirea unei ieșiri docker inspect când ceva nu se conectează corect. Nimic nu e greu, e doar necunoscut prima dată.
Pentru mai mult despre containerizarea aplicațiilor reale și conectarea lor la conducte de implementare în cloud, verifică segmentele DevOps și Cloud pe Korra Studio.
Scris cu asistență AI, revizuit și publicat de Michal Pilch (CISSP), Korra Studio.
Aceasta este o notă din baza de cunoștințe Korra Studio — platforma asociază fiecare subiect cu mentorat 1-la-1.
Început gratuitarrow_forward