Какую проблему решает Docker?

Docker: основная проблема и решение

Проблема: "It works on my machine"

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

• ОС: Windows vs Linux
• Версии зависимостей: Java 8 на машине разработчика, Java 11 на сервере
• Конфигурация: переменные окружения, порты, базы данных
• Системные библиотеки: openssl, libc версии

Как Docker решает эту проблему

Docker обеспечивает полную изоляцию приложения от хост-системы через контейнеризацию. Контейнер — это упакованное приложение со всеми зависимостями, которое работает одинаково везде:

# Dockerfile — полное описание окружения
FROM openjdk:17-slim

WORKDIR /app

COPY target/application.jar application.jar
COPY config/application.yml config/

ENV JAVA_OPTS="-Xms256m -Xmx512m"
ENV SPRING_CONFIG_LOCATION=file:config/application.yml

EXPOSE 8080

ENTRYPOINT ["java", "${JAVA_OPTS}", "-jar", "application.jar"]

Этот Dockerfile гарантирует, что приложение запустится с точно такой же средой везде.

Практические преимущества для Java-разработчика

1. Консистентность между локалью и production

# На машине разработчика
docker run -p 8080:8080 -e SPRING_PROFILES_ACTIVE=dev my-app:latest

# На production сервере — ДА ЖЕ САМАЯ КОМАНДА
docker run -p 8080:8080 -e SPRING_PROFILES_ACTIVE=prod my-app:latest

2. Зависимости внутри контейнера

Вместо установки на сервер MySQL, Redis, PostgreSQL отдельно:

# docker-compose.yml
version: 3.8
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
      - redis
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/mydb
      REDIS_HOST: redis
  
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine

volumes:
  postgres_data:

Вся инфраструктура поднимается одной командой:

docker-compose up -d

3. Мгновенное масштабирование

В Kubernetes можно запустить несколько копий контейнера за секунды без переустановки зависимостей:

# kubernetes-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app
spec:
  replicas: 3  # 3 копии приложения
  selector:
    matchLabels:
      app: java-app
  template:
    spec:
      containers:
      - name: app
        image: my-app:1.0
        ports:
        - containerPort: 8080
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: "prod"

4. CI/CD без средств на сервере

Не нужно устанавливать Maven, Gradle на production-сервер. Docker-образ уже содержит собранное приложение:

# Build образа
docker build -t my-app:1.0 .

# Push в реестр
docker push registry.example.com/my-app:1.0

# Pull и запуск на любом сервере
docker pull registry.example.com/my-app:1.0
docker run -d registry.example.com/my-app:1.0

Слои контейнера (оптимизация)

У Docker есть механизм кеширования слоёв — каждая строка в Dockerfile это слой:

# Неоптимально — пересборка Maven при любом изменении кода
FROM maven:3.8
COPY . /app
WORKDIR /app
RUN mvn clean package

# ✓ Оптимально — кэш зависимостей сохраняется
FROM maven:3.8 as builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:resolve  # Кэшируется если pom не изменился
COPY src .
RUN mvn package

FROM openjdk:17-slim
COPY --from=builder /app/target/*.jar application.jar
ENTRYPOINT ["java", "-jar", "application.jar"]

Безопасность и изоляция

Каждый контейнер работает в изолированном окружении, что снижает риск конфликтов между приложениями на одном хосте и улучшает безопасность.

Вывод

Docker превращает вопрос "почему это работает дома, но не на сервере?" в пережиток прошлого. Это стандарт де факто для современной разработки и основа для автоматизации, масштабирования и надёжности production-приложений.