Docker

01Image-ներ, container-ներ և ինչով են դրանք տարբերվում VM-ներից

Image-ը միայն կարդալու համար նախատեսված կաղապար է՝ ֆայլային համակարգի snapshot՝ գումարած մետատվյալներ, օրինակ՝ որ հրամանը գործարկել։ Container-ը image-ի գործարկված օրինակն է, որի վրա կա գրելու համար բարակ շերտ։ Image-ը պատկերացրու որպես բաղադրատոմսի քարտ, իսկ container-ը՝ դրանով պատրաստված ուտեստ․ մեկ քարտով կարող ես շատ ուտեստներ պատրաստել։ Վիրտուալ մեքենան (VM) էմուլյացիա է անում ամբողջ համակարգիչը՝ իր սեփական kernel-ով, ուստի բեռնում է ամբողջական օպերացիոն համակարգ և սովորաբար զբաղեցնում է գիգաբայթեր ու տասնյակ վայրկյաններ։ Container-ը սովորական Linux պրոցես է, որը kernel-ը մեկուսացնում է namespace-ներով (ինչ կարող է տեսնել՝ ֆայլեր, ցանց, պրոցեսների ցուցակ) և սահմանափակում cgroup-ներով (որքան CPU և հիշողություն կարող է օգտագործել)։ Այն կիսում է host-ի kernel-ը, ուստի մեկնարկում է միլիվայրկյաններում և քիչ overhead է ավելացնում։ Փոխզիջումը՝ մեկուսացումն ավելի թույլ է, քան VM-ինը, և այդ պատճառով cloud-երը հաճախ container-ները գործարկում են VM-ների ներսում։

• Image = անփոփոխ կաղապար, որը նույնականացվում է name:tag-ով և բովանդակության digest-ով։
• Container = image + գրելու շերտ + մեկուսացված պրոցես։
• Container-ները կիսում են host-ի kernel-ը, իսկ VM-ներն ունեն իրենցը։

02Շերտեր և build-ի քեշավորում

Dockerfile-ի յուրաքանչյուր հրահանգ (FROM, COPY, RUN) ստեղծում է շերտ, իսկ image-ը շերտերի կույտ է, որոնք միավորվում են overlay ֆայլային համակարգով։ Շերտերը քեշավորվում են ըստ բովանդակության․ եթե հրահանգը և դրանից առաջ եղած ամեն ինչ չեն փոխվել, Docker-ը վերօգտագործում է քեշավորված շերտը՝ այն նորից գործարկելու փոխարեն։ Հենց որ մեկ շերտ փոխվում է, դրանից հետո եկող բոլոր շերտերը վերակառուցվում են։ Հենց այս կանոնն է որոշում, թե որքան արագ են քո build-երը։ Սկզբում պատճենիր կախվածությունների manifest-ը (package.json և lockfile-ը, կամ composer.json և composer.lock), տեղադրիր կախվածությունները, և միայն դրանից հետո պատճենիր մնացած կոդը։ Այժմ կոմպոնենտը խմբագրելը ամբողջական npm install չի առաջացնում։ .dockerignore ֆայլը node_modules-ը, .git-ը, լոգերը և .env ֆայլերը դուրս է պահում build context-ից, ինչը build-երն արագացնում է և թույլ չի տալիս գաղտնիքներին արտահոսել image-ների մեջ։

1# .dockerignore
2node_modules
3.next
4.git
5*.log
6.env*
7Dockerfile
8compose*.yaml

03Production Dockerfile՝ multi-stage, փոքր, ոչ root

Multi-stage build-ը մեկ stage-ում՝ կոմպիլյատորներով և dev կախվածություններով, կառուցում է հավելվածը, ապա միայն արդյունքը պատճենում է մաքուր, փոքր runtime stage-ի մեջ։ Վերջնական image-ում չկան ավելորդ source map-եր, build գործիքներ, և patch անելու փաթեթները շատ ավելի քիչ են։ Օգտագործիր slim կամ Alpine բազային image-ներ և ամրագրիր major տարբերակը՝ latest-ի փոխարեն։ Գործարկիր առանց արտոնությունների օգտատիրոջով․ եթե ինչ-որ մեկը շահագործի հավելվածի խոցելիությունը, նա կհայտնվի որպես սովորական օգտատեր, ոչ թե root։ Ստորև օրինակը կառուցում է Next.js հավելված, որի next.config-ում դրված է output: "standalone", ինչը ստեղծում է մինիմալ server.js և միայն անհրաժեշտ node_modules-ը։ Նույն մոտեցումն աշխատում է Laravel-ի համար՝ Composer stage, Node stage՝ asset-ների համար, և վերջնական PHP-FPM stage։

1FROM node:24-alpine AS deps
2WORKDIR /app
3COPY package.json package-lock.json ./
4RUN npm ci
5 
6FROM node:24-alpine AS build
7WORKDIR /app
8COPY --from=deps /app/node_modules ./node_modules
9COPY . .
10RUN npm run build
11 
12FROM node:24-alpine AS run
13WORKDIR /app
14ENV NODE_ENV=production
15COPY --from=build --chown=node:node /app/.next/standalone ./
16COPY --from=build --chown=node:node /app/.next/static ./.next/static
17COPY --from=build --chown=node:node /app/public ./public
18USER node
19CMD ["node", "server.js"]

04Volume-ներ և ցանցեր

Container-ի գրելու շերտն անհետանում է, երբ container-ը ջնջվում է, ուստի այն ամենը, ինչ ուզում ես պահել (բազայի ֆայլեր, վերբեռնումներ), պետք է ապրի volume-ում։ Անվանված volume-ները կառավարում է Docker-ը, և դրանք ճիշտ ընտրություն են տվյալների բազաների համար։ Bind mount-ները host-ի թղթապանակը քարտեզագրում են container-ի մեջ և իդեալական են development-ում, երբ ուզում ես, որ կոդի փոփոխություններն անմիջապես երևան։ Ցանցի կողմից՝ նույն user-defined ցանցում գտնվող container-ները միմյանց գտնում են service-ի անունով՝ Docker-ի ներկառուցված DNS-ի միջոցով․ հավելվածը միանում է db:5432-ին, ոչ թե localhost-ին։ Container-ի ներսում localhost-ը նշանակում է հենց այդ container-ը, և սա սկսնակների ամենատարածված շփոթությունն է։ Publish արա միայն այն port-երը, որոնք իսկապես պետք են արտաքին աշխարհին, սովորաբար միայն 80-ը և 443-ը reverse proxy-ի վրա։

• Անվանված volume՝ մշտական տվյալներ, որոնք պատկանում են Docker-ին (տվյալների բազաներ)։
• Bind mount՝ host-ի թղթապանակ, հիանալի է development-ում կենդանի կոդի համար։
• Publish արված port-երը շատ կոնֆիգուրացիաներում շրջանցում են ufw-ի կանոնները․ մասնավոր port-երը կապիր 127.0.0.1-ին կամ ընդհանրապես մի publish արա։

05Docker Compose ամբողջական հավելվածի համար

Compose-ը մեկ compose.yaml-ում նկարագրում է մի քանի container, դրանց ցանցերն ու volume-ները, իսկ docker compose up -d-ն գործարկում է ամեն ինչ։ Ստորև տիպիկ վեբ հավելված է՝ nginx-ը առջևում՝ որպես միակ հանրային մուտքի կետ, հավելվածի container-ը, queue worker, որը կառուցված է նույն image-ից, բայց այլ հրամանով, PostgreSQL՝ մշտական volume-ով և health check-ով, և Redis՝ քեշի ու հերթերի համար։ depends_on-ը condition: service_healthy-ով ստիպում է հավելվածին սպասել, մինչև բազան իրականում սկսի միացումներ ընդունել, ոչ թե պարզապես մինչև դրա container-ը մեկնարկի։ Ուշադրություն դարձրու, որ բազան և Redis-ը ընդհանրապես port չեն publish անում․ դրսից հասանելի է միայն nginx-ը։ Գաղտնիքները գալիս են env ֆայլից, որը Git-ում commit չի արվում։

1services:
2  nginx:
3    image: nginx:stable-alpine
4    ports: ["80:80", "443:443"]
5    depends_on: [app]
6  app:
7    build: .
8    env_file: .env
9    depends_on:
10      db: { condition: service_healthy }
11  worker:
12    build: .
13    command: php artisan queue:work --tries=3
14  db:
15    image: postgres:17
16    volumes: [db-data:/var/lib/postgresql/data]
17    healthcheck: { test: ["CMD", "pg_isready", "-U", "postgres"], interval: 5s }
18  redis:
19    image: redis:7-alpine
20volumes: { db-data: {} }

06Development-ի և production-ի Compose

Development-ը և production-ը տարբեր բաներ են ուզում։ Development-ում ուզում ես bind mount արված կոդ, hot reload, debug գործիքներ և գուցե mail catcher։ Production-ում ուզում ես կառուցված image-ներ՝ ներսում «թխված» կոդով, restart: unless-stopped, ռեսուրսների սահմանափակումներ, լոգերի ռոտացիա, TLS և մոնիթորինգ։ Մի պահիր երկու իրարից շեղվող ֆայլ։ Պահիր բազային compose.yaml՝ ընդհանուրով, և դրա վրա դիր override ֆայլեր․ compose.override.yaml-ը development-ում բեռնվում է ավտոմատ, իսկ production-ը գործարկվում է բացահայտ՝ բազային ֆայլով և production ֆայլով։ Կարող ես ավելացնել նաև այլ շերտեր, օրինակ՝ TLS ֆայլ կամ observability ֆայլ, որն ավելացնում է Prometheus, Grafana և Loki։ Deploy անելուց առաջ միավորված արդյունքը ստուգիր docker compose config-ով։

1# development: compose.yaml + compose.override.yaml (auto-loaded)
2docker compose up -d
3 
4# production: explicit files, no override
5docker compose -f compose.yaml -f compose.prod.yaml config --quiet
6docker compose -f compose.yaml -f compose.prod.yaml up -d --build
7 
8# useful day to day
9docker compose ps
10docker compose logs -f --tail=100 app
11docker compose exec app sh

07Ինչ է իրականում container-ը․ runtime-ի շղթան և PID 1-ը

Երբ գրում ես docker run, CLI-ը դիմում է Docker daemon-ին (dockerd), որն աշխատանքը փոխանցում է containerd-ին, իսկ սա էլ ցածր մակարդակի OCI runtime-ով, սովորաբար runc-ով, ստեղծում է պրոցեսը։ runc-ը kernel-ից խնդրում է նոր namespace-ներ, պրոցեսը կցում է cgroup-ի, overlayfs-ով mount է անում image-ի շերտերը և հետո հեռանում է ճանապարհից։ Image-ի և runtime-ի ձևաչափերը բաց OCI ստանդարտներ են, այդ պատճառով Podman-ը, Kubernetes-ը և Docker-ը կարող են գործարկել նույն image-ը։ Մի մանրուք production-ում հաճախ է խայթում․ container-ի առաջին պրոցեսը PID 1-ն է։ Kernel-ը PID 1-ին լռելյայն signal handler-ներ չի տալիս, ուստի SIGTERM-ի handler չտեղադրած պրոցեսը պարզապես անտեսում է այն, և PID 1-ից նաև սպասվում է, որ «հավաքի» zombie child պրոցեսները։ Փոքրիկ init-ը, օրինակ՝ tini-ն, որը Compose-ում միացվում է init: true-ով, քո փոխարեն փոխանցում է ազդանշանները և հավաքում zombie-ները։

1services:
2  app:
3    image: registry.example.com/app:1.8.0
4    init: true               # tini as PID 1: forwards signals, reaps zombies
5    stop_grace_period: 30s   # time between SIGTERM and SIGKILL (default 10s)
6    stop_signal: SIGTERM

08Container-ի պաշտպանության ամրացում runtime-ում

Non-root user-ը առաջին քայլն է, ոչ թե վերջինը։ Լռելյայն container-ը դեռ ստանում է Linux capability-ների հավաքածու, գրելու հնարավորությամբ root ֆայլային համակարգ և setuid binary-ների միջոցով արտոնություններ ձեռք բերելու հնարավորություն։ Հանիր բոլոր capability-ները և ետ ավելացրու միայն անհրաժեշտը (80 port-ին կապվող web սերվերին պետք է NET_BIND_SERVICE, իսկ proxy-ի հետևում աշխատող Node և PHP հավելվածների մեծ մասին ոչինչ պետք չէ)։ Root ֆայլային համակարգը դարձրու read-only և հավելվածին տուր փոքր tmpfs ժամանակավոր ֆայլերի համար, որպեսզի հարձակվողը չկարողանա գործիքներ գցել դիսկի վրա։ Միացրու no-new-privileges, որպեսզի setuid հնարքները ձախողվեն։ Docker-ի լռելյայն seccomp profile-ն արդեն արգելափակում է տասնյակ վտանգավոր system call-եր․ երբեք մի անջատիր այն seccomp=unconfined-ով։ Ամենակարևորը՝ երբեք /var/run/docker.sock-ը mount մի արա հավելվածի container-ի մեջ․ socket-ի հասանելիությունը համարժեք է host-ի վրա root լինելուն։ Լրացուցիչ շերտի համար rootless ռեժիմը daemon-ն ինքն էլ գործարկում է որպես սովորական user։

1services:
2  app:
3    user: "1000:1000"
4    read_only: true
5    tmpfs: [/tmp]
6    cap_drop: [ALL]
7    security_opt: ["no-new-privileges:true"]
8    deploy:
9      resources:
10        limits: { cpus: "1.0", memory: 512M }
11    pids_limit: 200

09Docker-ը, iptables-ը և firewall-ի անակնկալը

Երբ port-ը publish ես անում ports: "5432:5432"-ով, Docker-ը iptables-ում գրում է NAT կանոններ, որպեսզի host-ի port-ին եկող տրաֆիկը փոխանցվի container-ին։ Այդ կանոնները ստուգվում են PREROUTING և FORWARD ուղիներում՝ ավելի շուտ, քան INPUT chain-ը, որտեղ ufw-ն պահում է իր կանոնները։ Արդյունքում ufw status-ը ասում է, որ 5432 port-ը արգելված է, իսկ բազան պատասխանում է ինտերնետից։ Կա երեք անվտանգ լուծում։ Ներքին service-ները ընդհանրապես publish մի արա․ նույն ցանցի container-ներին դա պետք չէ։ Եթե host-ի ինչ-որ գործիքի պետք է հասնել container-ին, կապիր loopback-ին՝ 127.0.0.1:5432:5432։ Եթե իսկապես պետք է ֆիլտրել publish արված port-երը, կանոններդ դիր DOCKER-USER chain-ում, որը Docker-ը ստուգում է իր կանոններից առաջ և երբեք չի վերագրում։ Ցանկացած փոփոխությունից հետո ստուգիր դրսից՝ port scan-ով, այլ ոչ թե վստահիր firewall-ի սեփական հաշվետվությանը։

1services:
2  db:
3    image: postgres:17
4    # reachable only from the host itself, never from the internet
5    ports: ["127.0.0.1:5432:5432"]
6  redis:
7    image: redis:7-alpine
8    # no ports at all: only containers on the same network can connect
9 
10# from another machine: nmap -Pn -p 5432,6379 203.0.113.10

10Ավելի արագ և անվտանգ build-եր BuildKit-ով

BuildKit-ը, որը Docker-ի ընթացիկ տարբերակներում լռելյայն builder-ն է, ավելացնում է հնարավորություններ, որոնք սովորական շերտային քեշավորումը չունի։ Cache mount-ը package manager-ի ներբեռնումների քեշը պահում է build-երի միջև՝ առանց այն որևէ շերտի մեջ դնելու, ուստի lockfile-ի փոփոխությունից հետո տեղադրումը կատարվում է տաք քեշից, ոչ թե ցանցից։ Secret mount-ը token-ը (մասնավոր npm registry-ի կամ Composer auth-ի համար) հասանելի է դարձնում միայն մեկ RUN քայլի․ այն երբեք չի հայտնվում image-ի պատմության մեջ, ի տարբերություն ARG կամ ENV արժեքների, որոնք ցանկացածը կարող է կարդալ docker history-ով։ CI-ում runner-ները մեկնարկում են դատարկ, ուստի քեշը export արա registry և import արա հաջորդ գործարկման ժամանակ։ Վերարտադրելիության համար base image-ները ամրագրիր ոչ միայն tag-ով, այլև digest-ով, և թող ավտոմատացումը, օրինակ՝ Renovate-ը կամ Dependabot-ը, pull request բացի, երբ digest-ը փոխվում է։ BuildKit-ը կարող է նաև կցել SBOM և provenance attestation, որոնք անվտանգության scanner-ներն ու աուդիտորներն ավելի ու ավելի հաճախ են ակնկալում։

1# syntax=docker/dockerfile:1
2FROM node:24-alpine AS deps
3WORKDIR /app
4COPY package.json package-lock.json ./
5RUN --mount=type=cache,target=/root/.npm \
6    --mount=type=secret,id=npmrc,target=/root/.npmrc \
7    npm ci
8 
9# build: docker build --secret id=npmrc,src=$HOME/.npmrc .
10# CI:    docker buildx build --cache-from type=registry,ref=registry.example.com/app:cache \
11#          --cache-to type=registry,ref=registry.example.com/app:cache,mode=max --push .