როგორ მართავთ კონფიგურაციას და საიდუმლოებებს Docker-ში?

Question

IT Interview Practice · Accepted Answer

კონტეინერიზებული აპლიკაციები უნდა იყოს **კონფიგურირებადი** ხელახლა ძე სახის აგების გარეშე — **გარემოს ცვლადების**, კონფიგურაციის ფайლების და სწორი **საიდუმლოებების მართვის** გამოყენებით. კონფიგურაციის და საიდუმლოებების სწორად მართვა მნიშვნელოვანია უსაფრთხოების და ერთი და იგივე ხელმოვლელობის სხვადსხვა გარემოში გაშვების წინააღმდეგ.

## კონფიგურაცია გარემოს ცვლადების მეშვეობით (12-factor)

```bash
# pass config at RUNTIME via environment variables (not baked into the image)
docker run -e DATABASE_URL=postgres://... -e NODE_ENV=production myapp
docker run --env-file .env myapp        # load many from a file
```

```yaml
# in docker-compose.yml
services:
  app:
    image: myapp
    environment:
      - DATABASE_URL=postgres://db:5432/app
    env_file: .env
```

**თორმეტი ფაქტორის** პრინციპების დაცვით, კონფიგურაცია მოდის **გარემოდან** (env ცვლადები) რান-ტაიმ-ზე — ამიტომ იგივე ხელმოვლელობა გაშვებულია dev, staging და production-ში სხვადსხვა კონფიგურაციით, არასოდეს აღდგენილია გარემოზე.

## საიდუმლოებები: არ შეწვეთ მათ ხელმოვლელობებში

```text
⚠️ NEVER put secrets (passwords, API keys, tokens) in the Dockerfile or image layers:
  → image layers are inspectable → secrets can be EXTRACTED (even if "removed" later,
    they remain in earlier layers)
  → anyone with the image gets the secrets
→ This is a serious, common security mistake.
```

## საიდუმლოებების სწორი მართვა

```text
✓ RUNTIME environment variables (better than image, but visible in inspect/env)
✓ DOCKER SECRETS (Swarm) / Kubernetes Secrets — mounted securely at runtime
✓ Secrets MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc. (fetch at runtime)
✓ BuildKit build secrets (--secret) — for build-time secrets without baking into layers
✓ Keep .env files OUT of version control (.gitignore) and out of the image (.dockerignore)
```

## რატომ მნიშვნელოვანია ეს

კონფიგურაციის და საიდუმლოებების სწორი მართვა Docker-ში მნიშვნელოვანია როგორც **უსაფრთხოების**, ასევე **ოპერაციული მოქნილობის** თვალსაზრისით, ამიტომ ეს ღირებული პრაქტიკული ცოდნაა.

კონფიგურაციის პრინციპი — კონფიგურაციის უზრუნველყოფა **გარემოს ცვლადების მეშვეობით რান-ტაიმ-ზე** ხელმოვლელობაში შემწვენის ნაცვლად (თორმეტი ფაქტორის პრინციპების დაცვით) — მნიშვნელოვანია, რადგან ის საშუალებას აძლევს **ერთი და იგივე ხელმოვლელობა გაშვებულიყო ყველა გარემოში** (dev, staging, production) სხვადსხვა კონფიგურაციით, არასოდეს აღდგენილი გარემოზე, რაც საფუძველია განმეორებადი, პორტატული განვითარებისა და კონტეინერიზაციის ცენტრალური პრაქტიკა.

რაც უფრო კრიტიკული, **საიდუმლოებების მართვა** სერიოზული უსაფრთხოების საზრდელია: მთავარი წესი — **არასოდეს შეწვოთ საიდუმლოებები (პაროლი, API გასაღები, ტოკენები) ხელმოვლელობებში** — აუცილებელია, რადგან ხელმოვლელობის ფენები შემოწმებადია და მათში ჩადებული საიდუმლოებები შეიძლება **ამოიღოთ** (და დაკლებული რჩება ადრეულ ფენებში, თუნდაც შემდეგ

კონფიგურაცია გარემოს ცვლადების მეშვეობით (12-factor)

საიდუმლოებები: არ შეწვეთ მათ ხელმოვლელობებში

საიდუმლოებების სწორი მართვა

რატომ მნიშვნელოვანია ეს

დაკავშირებული კითხვები