Послуги з контейнеризації додатків за допомогою Docker

Контейнеризація додатків з Docker: написання Dockerfile, Docker Compose, налаштування Registry, оптимізація образів, multi-stage builds та безпека контейнерів.
Показано 30 з 37Усі 1054 послуг
Часті запитання

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139

Як контейнеризація додатків вирішує проблему відтворюваності?

Python-додаток запускається на лептопі розробника. В staging падає з ModuleNotFoundError. В проді — з PermissionError на директорію, якої немає. Три середовища — три набори проблем. Контейнеризація з Docker вирішує саме це: не абстрактну "ізоляцію", а конкретну проблему відтворюваності середовища виконання. Гарантуємо, що ваш сервіс працюватиме однаково на будь-якому хості — від ноутбука до кластера Kubernetes.

Ми працюємо з Docker понад 7 років і контейнеризували більше 50 сервісів — від мікросервісів на Go до монолітів на PHP і важких ML-пайплайнів на Python. У кожному проєкті стикалися з типовими помилками: образи по 2 ГБ, збірка по 15 хвилин на чистому кеші, секрети, запечені в шари, додаток, що працює від root. Розповідаємо, як це виправити.

Multi-stage збірки — стандарт індустрії

Single-stage Dockerfile для Go-додатку тягне весь тулчейн: компілятор, пакети, вихідні коди. Підсумковий образ — 1.1 ГБ і 150+ вразливостей. Multi-stage збірка залишає лише бінарник і CA-сертифікати:

FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o server . FROM scratch COPY --from=builder /app/server /server COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ EXPOSE 8080 ENTRYPOINT ["/server"] 

Розмір образу — 8–15 МБ замість 1.1 ГБ — зменшення до 100 разів. Поверхня атаки мінімальна: немає shell, немає package manager. Trivy знаходить 0 вразливостей у такому образі (якщо бінарник зібраний без CVE-залежностей). Для Node.js застосовуємо аналогічний паттерн: окремі стейджі для залежностей, збірки, фіналу з non-root користувачем. Як зазначено в Wikipedia, док-образи з роздільними етапами будівництва дозволяють значно скоротити кінцевий обсяг.

Як BuildKit прискорює збірку в 6 разів?

BuildKit — активний за замовчуванням в актуальних версіях Docker — додає паралельне виконання незалежних стейджів і mount-кеші, які не потрапляють у фінальний образ. Приклад для Go:

FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN --mount=type=cache,target=/go/pkg/mod \ go mod download COPY . . RUN --mount=type=cache,target=/go/pkg/mod \ --mount=type=cache,target=/root/.cache/go-build \ CGO_ENABLED=0 go build -o server . 

Перша збірка — повна 4 хвилини. Наступні — лише змінені пакети, 40 секунд. В CI можна експортувати кеш через type=registry — він працює на будь-якому runner'і.

Правильний порядок інструкцій для кешу шарів

Docker інвалідує кеш шару і всіх наступних при зміні будь-якого файлу, що використовується в інструкції. Типова помилка: копіювати весь код до встановлення залежностей. Правильна послідовність: спочатку копіювати маніфести (package.json, go.mod), виконувати встановлення, потім копіювати вихідний код. Так зміни в коді не перезапускають npm ci або go mod download. Це прискорює збірку в CI на 30–50% для типового проєкту.

Управління приватними реєстрами

Реєстр Коли використовувати
ECR (AWS) AWS-інфраструктура, нативна інтеграція з EKS
GCR / Artifact Registry GCP-інфраструктура
ACR (Azure) Azure
Harbor On-premise, self-hosted з Trivy і RBAC
GitHub Container Registry Проєкти на GitHub Actions

Harbor — єдиний self-hosted варіант з повним набором: сканування через Trivy, replication між реєстрами, immutable tags. Тег latest в продакшні — антипатерн: Kubernetes не перепулить образ, якщо він вже є на ноді. Правильно — тегувати через git SHA або semver: app:1.4.2.

Безпека контейнерів

Сканування вразливостей у CI — ключовий етап. Trivy сканує OS-пакети, language-залежності та конфігурацію Dockerfile. Мінімальна інтеграція в GitLab CI призводить до зниження критичних вразливостей на 90% за місяць:

trivy-scan: image: aquasec/trivy:latest stage: security script: - trivy image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed --format json --output trivy-report.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA 

--ignore-unfixed — не падати через вразливості без виправлення. --severity HIGH,CRITICAL — не зашумлювати пайплайн. В .trivyignore документуємо прийняті ризики з обґрунтуванням.

Додаткові практики безпеки:

  • Root-користувач. Завжди додавати USER інструкцію. Додаток не повинен працювати від root.
  • Read-only filesystem. docker run --read-only або securityContext.readOnlyRootFilesystem: true в Kubernetes. Записувані директорії — через tmpfs.
  • Secrets. BuildKit з --secret передає секрети в збірку, не записуючи в шар: RUN --mount=type=secret,id=npm_token NPM_TOKEN=$(cat /run/secrets/npm_token) npm ci.
  • Distroless-образи (Google Distroless) — мінімальні образи без shell. Менше CVE, менше поверхня атаки.

Docker Compose для локальної розробки

depends_on з condition: service_healthy — дочекатися реальної готовності сервісу:

services: app: depends_on: db: condition: service_healthy db: image: postgres:15-alpine healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 5s retries: 5 

docker-compose.override.yml — для dev-специфічних налаштувань (volume-монтування, debug-порти), що не потрапляють у production.

Як ми працюємо і що ви отримуєте

  1. Аудит поточних Dockerfile і CI-пайплайнів. Виявляємо вузькі місця: розмір образів, кеш, безпеку. Оцінимо проект за 1 день — зв'яжіться з нами.
  2. Проєктування архітектури multi-stage збірок з урахуванням вашого стеку.
  3. Розробка та оптимізація Dockerfile (кешування, non-root, distroless).
  4. Налаштування приватного реєстру, сканування в CI/CD та політик immutability.
  5. Результати — документація, конфіги CI/CD, доступ до реєстру, runbook для розробників і 1–2 воркшопи для команди.

Середня економія на хмарних ресурсах після впровадження — 35%, що для середнього проєкту становить $1200–2500 на місяць. Якщо ви впізнали свої проблеми — замовте консультацію для аудиту вашої інфраструктури.

Досвід компанії

Понад 7 років роботи з Docker і Kubernetes. 50+ проєктів з контейнеризації — від стартапів до enterprise. Сертифіковані Kubernetes (CKA, CKAD). Досвід з Yandex Cloud, AWS, GCP, Selectel. 5 років на ринку. Кожен проєкт завершуємо з передачею документації та планом експлуатації.

Орієнтири за термінами

Завдання Термін
Контейнеризація одного сервісу з нуля 1–2 дні
Оптимізація існуючих Dockerfile + CI-кеш 1–2 дні
Налаштування Harbor з Trivy і replication 2–4 дні
Налаштування сканування в CI для N сервісів 2–3 дні
Аудит і рекомендації (без правок) 1 день

Вартість розраховується індивідуально після оцінки проєкту. Замовте аудит — ми проаналізуємо вашу інфраструктуру і запропонуємо оптимальне рішення. Скоротіть час збірки та витрати на хмарні ресурси вже зараз.