კონტეინერი: Docker და OCI

კონტეინერი: Docker და OCI

1) OCI ძირითადი ცნებები და სტანდარტები

OCI Image Spec - სურათების ფორმატი (მანიფესტი, კონფისკაცია, ფენები, ინდექსი მრავალ-არჩისთვის).
OCI Runtime Spec - როგორ დავიწყოთ კონტეინერი (bundle, 'config. json`); განხორციელება: runc, ასევე gVisor, Kata Containers.
OCI Distribution Spec - ურთიერთქმედება რეესტრებთან (push/pull, საავტორო უფლებები).

Docker = UX და ეკოსისტემა OCI- ს გარშემო: Dockerfile/BuildKit/CLI/Compose/Hub. Kubernetes Docker Engine შეიცვალა Containerd/CRI-O, მაგრამ სურათების ფორმატი იგივეა.

2) სურათები: ფენები, ჭდეები, მეტამონაცემები

Образ = слои (layered filesystem) + config (entrypoint/cmd/env/labels) + manifest.
ჭდეები: არ გამოიყენოთ ': latest' გაყიდვაში; pinning ': 1. 21. 3 ', git-SHA ან თარიღი + SHA.
LABEL: მფლობელი, კონტაქტი, vcs-urg, org. opencontainers. (title, description, revision, source).
Multi-arch: მანიფესტის ინდექსი იძლევა სწორ ვარიანტს 'amd64/arm64'.

3) ასამბლეა: Dockerfile, BuildKit, მრავალჯერადი ეტაპი

3. 1 პრინციპები

მინიმუმამდე დაიყვანეთ ფენები, დააფიქსირეთ ვერსიები, გაასუფთავეთ პაკეტის მენეჯერების ქეში.
ჯერ კოპირება მანიფესტის/ლოკის ფაილები, შემდეგ 'RUN install deps' - აუმჯობესებს ქეშს.
.dockerignore სავალდებულოა (გამორიცხეთ '.git', არტეფაქტები, საიდუმლოებები).
სასურველია distroless/alpine/მინიმალური ბაზების ნიმუშები.

3. 2 BuildKit ჩიპები

პარალელური ბილეთები, შეკრების საიდუმლოებები ('-secret'), ქეშის მთები, buildx multi-arch.

dockerfile syntax=docker/dockerfile:1. 6
RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements. txt

3. 3 მრავალფუნქციური მაგალითები

dockerfile syntax=docker/dockerfile:1. 6
FROM golang:1. 23 AS build
WORKDIR /src
COPY go. mod go. sum./
RUN go mod download
COPY..
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /app

FROM gcr. io/distroless/static:nonroot
USER 65532:65532
COPY --from=build /app /app
ENTRYPOINT ["/app"]

dockerfile syntax=docker/dockerfile:1. 6
FROM node:22-alpine AS deps
WORKDIR /app
COPY package. json./
RUN npm ci --omit=dev

FROM node:22-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules./node_modules
COPY..
RUN npm run build

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules./node_modules
COPY --from=build /app/dist./dist
USER node
CMD ["node","dist/server. js"]

dockerfile syntax=docker/dockerfile:1. 6
FROM python:3. 12-slim AS base
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app

FROM base AS deps
RUN --mount=type=cache,target=/root/.cache/pip pip install --upgrade pip
COPY requirements. txt.
RUN --mount=type=cache,target=/root/.cache/pip pip wheel --wheel-dir=/wheels -r requirements. txt

FROM base
COPY --from=deps /wheels /wheels
RUN pip install --no-index --find-links=/wheels -r /app/requirements. txt && rm -rf /wheels
COPY..
USER 1000:1000
CMD ["python","-m","app"]

dockerfile syntax=docker/dockerfile:1. 6
FROM maven:3. 9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom. xml./
RUN mvn -q -e -DskipTests dependency:go-offline
COPY..
RUN mvn -q -DskipTests package

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/target/app. jar /app/app. jar
ENTRYPOINT ["java","-XX:+UseContainerSupport","-jar","/app/app. jar"]

4) მინიმალური სურათები, PID 1 და სიგნალები

Distroless - თავდასხმის ნაკლები ზედაპირი, პაკეტების მენეჯერი არ არის.

dockerfile
ENTRYPOINT ["tini","--","/app"]

'HEALTHCHECK' გონივრულად განსაზღვრეთ (სიხშირე/ტაიმუტი, ზედმეტი დატვირთვის გარეშე).

5) კონტეინერების სექსუალობა

5. 1 პოლიტიკა და სიძულვილი

Non-root (USER), rootless Docker/containers.
Capabilities: ამოიღეთ ზედმეტი ('-cap-drop = ALL -cap-add = NET _ BIND _ SERVER' და ა.შ.).
seccomp/AppARmor/SELinux: ჩართეთ პროფილები ნაგულისხმევი ან მკაცრი.
Read-only FS + `tmpfs` для `/tmp`, no-new-privileges.
საიდუმლოებები: არა სურათებში; დამონტაჟეთ საიდუმლოების მენეჯერისგან (K8s/vault/docker secrets).

5. 2 Supply chain

SBOM (CycloneDX/SPDX) და სკანირება (Trivy/Grype).
ხელმოწერა (cosign, sigstore) და პოლიტიკა pull (verify).
განახლების რეპეტიციები: ძირითადი გამოსახულებები CVE პატჩებით რეგულარულად იბეჭდება.

6) შენახვა და ფაილური დრაივერები

სტანდარტულად, overlay2 (სწრაფი და სტაბილური). rootless მედიაში, ხშირად fuse-overlayfs.
volumes მონაცემებისა და ქეში, განვითარების bind-mount.
არ ჩაწეროთ '/' - გამოიყენეთ მონაცემთა გზა ('/მონაცემთა '), გამოყავით სახელმწიფო გამოსახულებისგან.

7) ქსელი და DNS

Docker ქსელები: bridge (ნაგულისხმევი), host (მინიმალური ზეგანაკვეთური, პორტების კონფლიქტი), none, macvlan/ipvlan (L2/L3 ინტეგრაცია).
DNS Docker საჭრელი იღებს მასპინძელ/დემონს. json; იმ ადგილობრივი ქეშის საჭრელის პარამეტრების დასადგენად.
K8s- ში ქსელს მართავს CNI (Calico/Cilium/Flannel). sidecar/mesh- ისთვის - iptables.

8) რესურსები და QoS (cgroups v2)

შეზღუდვები: '--cpus', '-mory', '--pids-limit', '--cpuset-cpus'.
დაამონტაჟეთ requests/limits (K8s- ში), რაც გავლენას ახდენს დაგეგმვაზე და QoS- ზე.
დააკვირდით OOMKilled, throttling, latence spikes GC/IO- ს გამო.

bash docker run --cpus=1. 5 --memory=512m --pids-limit=256 --read-only --tmpfs /tmp:rw,size=64m...

9) ლოგოები და დაკვირვება

ლოგოების დრაივერები: 'json file' (როტაციით), 'journald', 'gelf', 'awslogs', 'syslog'.

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

მეტრიკი: Docker Engine API, cadisor, node ექსპორტიორი; აკრეფა აგენტის მეშვეობით კონტეინერში ან sidecar.

10) რეესტრები და ავთენტიფიკაცია

კერძო რეესტრები: ECR/GCR/ACR/Harbor/GitHub Container Registry.
Rate-limits Docker Hub; გამოიყენეთ სარკეები/ქეში (registry-cache).
Retention/immutable tags პოლიტიკა, რეპლიკაცია რეგიონებს შორის.
'docklogin' არ ინახავთ სკრიპტებში; გამოიყენეთ CI საიდუმლოებები და OIDC ფედერაცია.

11) docker compose vs ორკესტრორები

კომპოზიცია - ადგილობრივი განვითარება/ინტეგრაციის სტენდები.
Прод: Kubernetes (Deployment/StatefulSet/DaemonSet, Ingress, Secrets, PVC) с containerd/CRI-O; უსაფრთხოების პოლიტიკა და rollout სტრატეგიები.
Swarm მოძველებულია დიდი გაყიდვებისთვის, შესაფერისია მარტივი მტევნებისთვის.

yaml version: "3. 9"
services:
api:
build:.
ports: ["8080:8080"]
environment: ["DB_URL=postgres://pg/DB"]
depends_on: ["pg"]
pg:
image: postgres:16-alpine volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: {} }

12) Healthcheck, დაწყება/გაჩერება, graceful shutdown

გამოიყენეთ 'HEALTHCHECK „ტაიმაუტებითა და შეზღუდვებით“.
სწორი გრაკეტი: დაჭერით SIGTERM, დაასრულეთ შემომავალი, დახურეთ ნაერთები, შემდეგ გამოსავალი.
В K8s: `preStop` hook + `terminationGracePeriodSeconds`, readiness перед liveness.

13) საუკეთესო პრაქტიკა ენებზე/დასტის (შეჯამება)

Node: 'npm ci', 'NODE _ ENV = წარმოება', გამორთეთ dev-deps runtime, '-heapsnapshot' off, 'uWS/GZip' L7 მარიონეტული.
პითონი: wheels, 'gunicorn -graceful-timeout', 'GTHREADS '/' UVICorn' CPU- სთვის, არ შეინახოთ ვენები საერთო ფენის შიგნით საჭიროების გარეშე.
Go: CGO off (თუ შესაძლებელია), '-ldflags = "-s -w" ", distroless/static,' GOMAXPROCS '- ში.
Java: Slave JAR, '-XX: MaxRAMPercentage', CDS/Layered JAR ქეში.

14) Supply chain და სურათების პოლიტიკა

SBOM გენერირება CI- ზე, შეინახეთ არტეფაქტის გვერდით.
სკანირება სურათები ყველა პუშზე; კარიბჭე კრიტიკულ CVE- სთვის.
ხელი მოაწერეთ სურათებს, ჩართეთ პოლიტიკის კონტროლი (K8s - Kyverno/Conftest/Gatekeeper).
გამოყავით build და run ანგარიშები/ქსელები; გაითვალისწინეთ დამოკიდებულება კერძო რეესტრში.

15) ანტი შაბლონები

': latest' გაყიდვაში; იმუნური ჭდეების არარსებობა.
შეკრება „Pro host- ის შიგნით“ იზოლაციის გარეშე; საიდუმლოებების შენახვა Dockerfile- ში.
გაშვება root, '-privileged', ფართო capabilities.
სქელი სურათები (> 1-2 GB), არარსებობა. dockerignore.
ENTRYPOINT- ში ინიტის ლოგიკა შელის ფორმით არის სიგნალებთან დაკავშირებული პრობლემები.
დაწერეთ მუდმივი მონაცემები კონტეინერის ფენაში, volume- ის ნაცვლად.
Healthcheck, რომელიც აკეთებს ძვირადღირებულ მოთხოვნებს prod BD- სთვის.

16) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

Dockerfile (multi სცენა, .dockerignore, LABEL, pinned base) სტანდარტიზაცია.
ჩართეთ BuildKit/buildx, პაკეტის მენეჯერების ქეში.
ნაგულისხმევი პროფილების გადასვლა non-root და 'seccomp '/AppARmor/SELinux.

11-25 დღე

runtime გამოსახულებების მინიმუმამდე შემცირება (alpine/distroless), შეკეთება ლოგებით (როტაცია).
რესურსების ლიმიტების კონფიგურაცია, healthchecks, სწორი PID 1/tini.
აამაღლეთ პირადი რეესტრი/ქეში, დააკავშიროთ CVE სკანერი და SBOM წარმოება.

26-45 დღე

შემოიტანეთ სურათების ხელმოწერა და კლასტერში ჩასვლის პოლიტიკა.
ორგანიზება multi-arch (amd64/arm64) სწორი მომსახურებისთვის.
runbook ასამბლეის/გამოშვების დოკუმენტაცია, მოხსენება შეკრების ზომების/დაუცველობის/დროის შესახებ.

17) სიმწიფის მეტრიკა

უსაფრთხო ჭდეები და რეპროდუქციული შეკრებები სერვისების 95% -ით.
runtime გამოსახულების საშუალო ზომაა <200-300 MB (დასტის მიხედვით).
კონტეინერების 100% - არა-ოთახი, შეზღუდული კაპიტალიზაციით და read-only FS.
SBOM და CVE სკანირება თითოეული push; კრიტიკული CVE დაბლოკილია.
სურათების ხელმოწერა და გარშემორტყმული პოლიცია.
კონტეინერის ცივი გაშვების დრო არის სამიზნე SLO (მაგ., 2-5 წამი), სწორი გრაფიკული shutdown.

18) დასკვნა

კონტეინერი მოზრდილებში არის OCI + შეკრების დისციპლინის სტანდარტები + ნაგულისხმევი უსაფრთხოება + დაკვირვება და მიწოდების პოლიტიკა. გამოიყენეთ multi-stage და BuildKit, მინიმუმამდე დაიყვანეთ runtime სურათები, დაიწყეთ non-root მკაცრი პროფილების ქვეშ, დააფიქსირეთ ჭდეები, სკანირება და ხელი მოაწერეთ, შეინახეთ ლოგები/რესურსები/ქსელი კონტროლის ქვეშ. ასე რომ, კონტეინერები გახდებიან თქვენი პლატფორმის პროგნოზირებადი და კონტროლირებადი საფუძველი - დეველოპერიდან წარმოებამდე.