Зачем нужны Docker контейнеры?

# Зачем нужны Docker контейнеры

Короткий ответ

Docker контейнеры решают главную проблему в разработке: "У меня работает на машине, но не работает на сервере". Они обеспечивают одинаковую окружение для разработки, тестирования и production.

Основные проблемы, которые решает Docker

1. "It works on my machine" проблема

Девелопер: "Код работает на моей машине на Windows!"
DevOps: "А на сервере Linux, и там всё упало."
Тестер: "На моём MacBook тоже не работает."

Причины:
- Разные версии Java (8 vs 11)
- Разные версии зависимостей
- Разные переменные окружения
- Разные конфигурации ОС

С Docker:

Девелопер: "Вот контейнер, в нём всё нужное."
Все используют ОДИН И ТОТ ЖЕ контейнер:
- На локальной машине
- На staging сервере
- На production

2. Зависимости и версии

Без Docker:

Проект 1: Java 8, PostgreSQL 9.6, Redis 3.2
Проект 2: Java 11, PostgreSQL 12, Redis 6.0
Проект 3: Java 17, PostgreSQL 14, Redis 7.0

Машина девелопера:
- Java 11 установлена (конфликт с Проектом 1)
- PostgreSQL 12 установлена (конфликт с Проектом 1 и 3)
- Redis версии неопределённой

→ Всё конфликтует, ничего не работает

С Docker:

Каждый проект в своём контейнере со своими версиями
Конфликтов нет, всё работает параллельно

3. Быстрое развёртывание

Без Docker:

# На новом сервере нужно
sudo apt-get update
sudo apt-get install java-11-openjdk
sudo apt-get install postgresql-14
# ... скачать, установить, конфигурировать
# ... изменить конфиги, создать пользователей
# ... разобраться с permissions, firewall
# → 2-3 часа работы, вероятность ошибок высокая

С Docker:

docker run my-app:latest
# Готово за 5 секунд, всё уже сконфигурировано

4. Масштабирование

Без Docker:

Нужно обрабатывать 10 млн запросов/день
- Купить ещё серверы
- Установить на них приложение
- Конфигурировать load balancer
- Синхронизировать версии
- Тестировать
→ Недели работы

С Docker + Kubernetes:

kubectl scale deployment my-app --replicas=10
# Готово за минуту, 10 копий контейнера работают параллельно

Архитектура Docker

Как работает контейнеризация

Без контейнеризации (Virtual Machine):
┌─────────────────────┐
│   Host ОС (Linux)   │
│  ┌─────────────────┐│
│  │ Hypervisor      ││
│  │  ┌────────────┐ ││
│  │  │ VM 1       │ ││
│  │  │ ├─ ОС      │ ││  ← Полная ОС (700MB-1GB)
│  │  │ ├─ Java    │ ││
│  │  │ └─ App     │ ││
│  │  └────────────┘ ││
│  │  ┌────────────┐ ││
│  │  │ VM 2       │ ││
│  │  │ ├─ ОС      │ ││  ← Ещё одна полная ОС
│  │  │ ├─ Java    │ ││
│  │  │ └─ App     │ ││
│  │  └────────────┘ ││
│  └─────────────────┘│
└─────────────────────┘

Проблемы: Тяжело, медленно запускается

С Docker контейнеризацией:
┌──────────────────────┐
│   Host ОС (Linux)    │
│  ┌────────────────────┐
│  │ Docker Engine      │
│  │  ┌──────────────┐  │
│  │  │ Container 1  │  │
│  │  │ ├─ Lib/deps  │  │  ← Только нужные файлы (50MB)
│  │  │ ├─ Java      │  │
│  │  │ └─ App       │  │
│  │  └──────────────┘  │
│  │  ┌──────────────┐  │
│  │  │ Container 2  │  │
│  │  │ ├─ Lib/deps  │  │  ← Только нужные файлы
│  │  │ ├─ Java      │  │
│  │  │ └─ App       │  │
│  │  └──────────────┘  │
│  └────────────────────┘
│  ОС ядро (shared)
└──────────────────────┘

Преимущества: Легко, быстро, эффективно

Практические примеры

Пример 1: Простое Java приложение

Dockerfile

# Используем готовый образ с Java
FROM openjdk:11-jre-slim

# Устанавливаем рабочую директорию
WORKDIR /app

# Копируем compiled JAR в контейнер
COPY target/myapp.jar .

# Открываем порт
EXPOSE 8080

# Команда для запуска
CMD ["java", "-jar", "myapp.jar"]

Использование

# Собрать контейнер
docker build -t myapp:1.0 .

# Запустить контейнер
docker run -p 8080:8080 myapp:1.0

# Контейнер работает и доступен на localhost:8080

Пример 2: Java приложение с зависимостями

docker-compose.yml

version: '3.8'

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=jdbc:postgresql://db:5432/myapp
      - DATABASE_USER=appuser
      - DATABASE_PASSWORD=secret
    depends_on:
      - db
      - cache

  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=appuser
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Использование

# Запустить всё (Java app + PostgreSQL + Redis)
docker-compose up

# Всё работает без ручной установки и конфигурации!

Пример 3: Multi-stage build (оптимизация)

# Stage 1: Compile
FROM maven:3.8-openjdk-11 AS builder
WORKDIR /build
COPY . .
RUN mvn clean package -DskipTests

# Stage 2: Runtime (меньший размер)
FROM openjdk:11-jre-slim
WORKDIR /app
COPY --from=builder /build/target/myapp.jar .
EXPOSE 8080
CMD ["java", "-jar", "myapp.jar"]

Оптимизация:

• Stage 1: 500MB (с Maven, зависимостями, исходным кодом)
• Stage 2: 150MB (только runtime)
• Результат: контейнер 150MB вместо 500MB

Преимущества Docker

1. Консистентность (Consistency)

Один Dockerfile → одна сборка → один образ → всегда одинаковое поведение

2. Изоляция (Isolation)

Каждый контейнер изолирован:
- Процессы не видят друг друга
- Файловая система отдельная
- Сетевые порты разные
- Переменные окружения не конфликтуют

3. Лёгкость (Lightness)

Легче VMs:
- Меньше памяти (может быть 10000+ контейнеров на одном хосте)
- Быстрее запускаются (миллисекунды vs секунды)
- Меньше дискового пространства

4. Портативность (Portability)

docker run myapp:1.0
→ Работает везде:
  - На ноутбуке разработчика (Windows, Mac, Linux)
  - На staging сервере
  - На production (AWS, GCP, Azure, on-premise)
  - На соседском сервере

5. DevOps-friendly

- Автоматические деплои (CI/CD)
- Версионирование образов
- Откаты за секунду (просто другой образ)
- Легко масштабировать (Kubernetes)

Недостатки Docker

1. Кривая обучения

"Надо ещё изучить Docker, Kubernetes, сетевые плюсы..."

2. Сложность в отладке

// На локальной машине всё работает просто:
User user = new User();
System.out.println(user);  // В консоли видно

// В контейнере нужно:
- Логировать в файл
- Монтировать volumes для доступа
- Или интерактивный режим: docker exec -it

3. Overhead для простых приложений

Если это простой скрипт на Java:
добавление Docker может быть избыточным

4. Некоторый performance overhead

Контейнеры немного медленнее, чем прямая установка
(но обычно это незначительно, несколько процентов)

Когда использовать Docker

✅ Используй Docker

- Enterprise приложения
- Микросервисная архитектура
- Нужна масштабируемость
- Много разработчиков в команде
- CI/CD pipeline
- Production окружение
- Нужна воспроизводимость

❌ Docker может быть не нужен

- Простой скрипт на Java
- Одноразовая утилита
- Очень простой сетап (Java, всё)
- Очень высокие требования к performance

Best Practices

1. Используй slim образы:

   FROM openjdk:11-jre-slim  # 150MB
   # Вместо
   FROM openjdk:11-jdk       # 500MB
   

2. Multi-stage builds для оптимизации:

   # Компиляция в одном stage, runtime в другом
   

3. Кешируй слои:

   COPY pom.xml .
   RUN mvn dependency:resolve  # Кешируется
   COPY src/ .
   RUN mvn package  # Пересобирается часто
   

4. Используй .dockerignore:

   node_modules/
   .git/
   target/
   .idea/
   # Не копировать лишнее
   

5. Логирование в stdout/stderr:

   // Docker автоматически собирает этот вывод
   System.out.println("Something happened");
   // Видно в: docker logs <container>
   

Вывод

Docker контейнеры решают фундаментальную проблему в разработке: обеспечение одинакового окружения для всех. Они позволяют:

• Избежать "работает на моей машине" проблемы
• Быстро развёртывать приложение
• Масштабировать горизонтально
• Управлять зависимостями
• Автоматизировать деплои

Для Java разработчика Docker — это необходимый навык в современной разработке, особенно для production приложений и микросервисной архитектуры.