Привет! Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному.

В этом материале речь пойдёт о том, что помогает избежать конфликтов зависимостей и проблем с изоляцией, возникающих при запуске нескольких приложений на одном сервере. Для решения этих задач используются технологии контейнеризации, которые позволяют создавать изолированные окружения для приложений, устраняя проблемы совместимости и упрощая процесс развёртывания. Рассмотрим, как работает контейнеризация и какие инструменты помогают сделать её максимально эффективной.

Проблемы запуска приложений в одном окружении

Во время разработки программы необходимо выполнять её в средах, где используются специфичные версии библиотек и системных компонентов.

Запуск одного приложения на физическом сервере может быть слишком затратным, поэтому зачастую на одном сервере работают несколько приложений одновременно. Это приводит к следующим проблемам.

• У каждого приложения свои версии зависимостей, которые могут конфликтовать между собой. Например, для одного приложения нужна системная библиотека glibc 2.19, а для другого — glibc 2.34. При этом в операционной системе glibc обновилась только до версии 2.30. Конечно, можно жёстко завязаться на определённую версию и обозначить, что запускать сможем только на ОС, например, CentOS 6-й версии, но теряем переносимость приложения.

• Необходима изоляция, чтобы одно приложение не могло повредить данные другого. К примеру, одна программа периодически удаляет временные файлы и может случайно удалить временные файлы другой. Или, если в одной из них происходит утечка памяти, это может привести к тому, что все программы на сервере перестанут работать, поскольку одно займёт всю доступную память.  Также возможна ситуация, когда приложение заполнит логами весь жёсткий диск, что приведет к сбоям всех остальных.

Изоляция через chroot

Одним из первых способов решения этих проблем стал запуск приложений в chroot-окружении. В Unix-подобных системах действует принцип «всё есть файл», поэтому работающую систему можно поделить на две части: ядро ОС и корневая файловая система. Утилита chroot позволяет изменить точку монтирования корневой файловой системы, создавая новое окружение для приложений.

Как работает chroot

С помощью chroot можно сделать следующее.

1. Создать минимальную корневую файловую систему в отдельной директории.

2. Переместить туда библиотеки, необходимые приложению.

3. Использовать утилиту chroot для подмены корневой файловой системы и запуска приложения, которое «думает», что работает в своей системе.

4. Запускать приложение в изолированном окружении chroot.

Преимущества использования chroot

В результате применения chroot.

• Приложение работает в изолированной среде.

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

• Приложение не знает, что оно работает в общей системе, и «думает», что запущено в отдельной операционной системе.

• Одно приложение не может получить доступ к файлам другого.

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

Проблемы и ограничения chroot

Но не всё так просто, и, помимо нерешённых проблем, возникают новые.

• Программа по-прежнему видит процессы других приложений на сервере.

• Нет управления ресурсами, и утечки памяти одной программы могут привести к сбою всех остальных на сервере.

• Архивы окружений могут занимать много места, и не всегда удобно пересылать их, если изменения касаются всего лишь нескольких килобайт данных.

Развитие технологий изоляции: Jail и LXC

В ответ на описанные выше проблемы в операционной системе FreeBSD появилась система виртуализации Jail, которая использует системный вызов chroot для изоляции приложений. А в ОС Linux были созданы подсистемы namespaces и cgroups.

• Namespaces: обеспечивают изоляцию процессов, файловых систем, сетевых интерфейсов и других ресурсов.

• Cgroups: позволяют управлять квотами на CPU, память и сеть, делая так, что процессы не могут использовать больше выделенных им ресурсов.

На базе этих двух подсистем была создана LXC (Linux Containers), которая позволила запускать контейнеры в изолированных окружениях. LXC до сих пор используется наряду с системой Jail. Компания Ubuntu разработала инструмент LXD для управления контейнерами LXC.

Появление Docker

Компания Docker тоже решила создать собственное решение для контейнеризации. Первоначально Docker был построен на LXC, но в последующих версиях разработчики отказались от LXC и начали напрямую использовать namespaces и cgroups. Docker добавил несколько полезных инструментов, которые сделали его популярным.

• Унифицированный способ сборки образов через Dockerfile.

• Единое хранилище образов — hub.docker.com.

• Git-подобный синтаксис для работы с образами и контейнерами.

• Использование слоёв (layers) для эффективного хранения образов.

Dockerfile: инструкции для создания образа

Dockerfile — это файл с инструкциями, которые описывают, как собрать образ. Помимо комментариев, он содержит команды для сборки образа. Для идентификации образов используются хэш-идентификаторы (sha256) или теги — символические имена, которые можно присваивать одному и тому же образу.

К наиболее часто используемым командам Dockerfile относятся:

• FROM: указывает базовый образ, на основе которого будет собран новый образ. Очень часто берут уже подготовленный кем-то шаблон с набором общих библиотек и инструментов, добавляя только специфичные команды. Однако существует специальная конструкция FROM SCRATCH, где SCRATCH — это заглушка, то есть шаблон, в котором нет никаких данных. Таким образом, сборку базового образа можно представить следующим образом: берётся SCRATCH-образ, в который копируются файлы базового образа (подготовленные, например, утилитой debootstrap в ОС семейства Debian или yum в RedHat-подобных системах);

• WORKDIR: задаёт рабочую директорию внутри образа. По умолчанию равно ‘/’.

• RUN: выполняет команды внутри контейнера. Если в командах используются относительные пути, то текущая директория определяется командой WORKDIR;

• CMD / ENTRYPOINT: задаёт команду, которая будет выполнена при запуске контейнера. CMD обычно используется, чтобы можно было переопределить параметры или команду запуска. На собеседованиях часто спрашивают, в чём различие между этими двумя командами (я сам иногда задаю этот вопрос). Конечно, можно углубиться в обсуждение двух режимов запуска — через exec или shell. Но если упростить, команда, указанная в ENTRYPOINT, всегда имеет приоритет перед CMD, и переопределить её несколько сложнее, чем CMD. Что выбрать при создании образов? Каждый сам решает, какой способ лучше соответствует поставленной задаче. Относительные пути в CMD / ENTRYPOINT задаются относительно WORKDIR;

• ADD / COPY: эти инструкции копируют файлы снаружи внутрь образа. В отличие от COPY, инструкция ADD позволяет не только копировать файлы в образ, но и загружать их из сети;

• ENV / ARG: задают переменные окружения для сборки или запуска контейнера. ARG существует только в процессе сборки образа, а ENV — и во время работы контейнера;

• LABEL / MAINTAINER / EXPOSE: указывают информацию об образе, его создателе и портах, которые использует контейнер. Важно понимать, что EXPOSE не пробрасывает порт при старте контейнера, это всего лишь отметка о том, что для работы приложения требуется этот порт.

Каждая команда Dockerfile создаёт новый слой образа. Образ — это указатель на определённый набор слоёв. Docker хранит два типа данных.

• Layerdb: база данных слоёв

• Imagedb: база данных образов

Такая структура позволяет эффективно управлять образами.

• Скачиваются только отсутствующие слои.

• Слои можно переиспользовать для разных образов.

• Если разместить команду, которая редко меняет данные, в Dockerfile выше, можно ускорить сборку образа, так как команда будет выполняться редко и docker будет использовать чаще уже закешированный готовый слой.

Docker предоставляет команды для работы с образами:

• `docker images` — просмотр локально сохранённых образов;

• `docker rmi` — удаление образов;

• `docker inspect` — просмотр манифеста образа;

• `docker save` / `docker load` — экспорт и импорт образов в виде tar-архивов;

• `docker build` — сборка образа по Dockerfile;

• `docker tag` — присвоение образу символического имени;

• `docker pull` — загрузка образа из удалённого репозитория;

• `docker push` — загрузка локального образа в удалённый репозиторий.

Контейнеры Docker

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

1. «Распаковывает» и объединяет слои образа в отдельную директорию (используя файловую систему overlayFS);

2. Выполняет команду `chroot` для изоляции процесса в этой директории;

3. Ограничивает процесс с помощью namespaces и cgroups.

Для работы с контейнерами используются команды:

• `docker run` — создать и запустить контейнер;

• `docker start` / `docker stop` — запустить или остановить контейнер;

• `docker ps` — показать список контейнеров;

• `docker exec` — выполнить команду внутри контейнера;

• `docker rm` — удалить контейнер;

• `docker logs` — просмотреть логи контейнера;

• `docker stats` — аналог `htop` для контейнеров;

• `docker cp` — скопировать файлы внутрь или из контейнера.

При использовании команды docker run часто указывают следующие опции:

• ‘-v’ — пробросить директорию внутрь контейнера. Поскольку контейнер эфемерен и может быть остановлен в любой момент, проброс директории обеспечивает сохранность файлов;

• ‘-p‘ — пробросить порт контейнера;

• ‘-e’ — задать переменную окружения.

Для флагов ‘-v’ и ‘-p’ аргумент имеет вид «снаружи»:«внутри». Например, аргумент ‘-v /opt/svc/data:/app/data’ пробрасывает директорию /opt/svc/data на внешней ОС в директорию /app/data внутри контейнера. С портами аналогично: флаг ‘-p 8080:8090’ означает, что порт 8090 внутри контейнера будет пробрасываться на порт 8080 снаружи.

Docker Compose: работа с несколькими контейнерами

Docker Compose — это утилита, упрощающая работу с множеством контейнеров. Приложение может состоять из нескольких контейнеров, таких как база данных, кеш, Nginx в качестве балансировщика нагрузки и сервис, выполняющий бизнес-логику. Для запуска такого приложения нужно выполнить несколько команд docker run, каждая из которых включает десятки аргументов, несколько портов, а также требует проброса нескольких директорий. В итоге запуск превращается в набор длинных команд, с которыми неудобно работать. Для решения этой проблемы была создана утилита Docker Compose. Вместо использования длинных команд docker run все параметры запуска выносятся в файл docker-compose.yaml.

Пример структуры файла `docker-compose.yaml`:

```yaml
services:
  my-db:
    container_name: db
    image: my-repo.domain.com/repo/db:2.4.0
    environment:
      ARG1: VAL1
    volumes:
      - /opt/data:/app/data
    ports:
      - "5432:5432"

  my-service:
    container_name: service
    image: my-repo.domain.com/repo/svc:1.2.0
    environment:
      DB_URL: db
    ports:
      - "8080:8080"
      - "9090:8090"
```

Для упрощения управления версиями и настройками можно использовать переменные. Переменные задаются в файле `.env`, а в `docker-compose.yaml` они указываются через `${VAR_NAME}`.

Docker Compose предоставляет следующие команды:

• `docker compose up` / `docker compose up -d` — запустить или обновить все сервисы, флаг ‘-d’ указывает, что запуск надо выполнять в фоне;

• `docker compose ps` — показать список запущенных контейнеров;

• `docker compose logs` — посмотреть логи сервисов;

• `docker compose down` — остановить и удалить контейнеры;

• `docker compose rm` — удалить контейнер.

Ограничения Docker Compose

Несмотря на удобство Docker Compose, у него есть ограничения.

• Он не поддерживает балансировку нагрузки и не умеет запускать контейнеры на разных серверах.

• Проверка состояния (health checks) ограничена, и для автоматического восстановления требуется использовать сторонние инструменты, например, [docker-autoheal].

• Конструкция `depends_on` не учитывает задержку запуска сервисов внутри контейнеров, она ждёт, когда запустится контейнер, а не сервис в нём.

Итоги

Docker Compose — удобный инструмент для локального развёртывания сервисов, но для задач оркестрации на продакшене часто применяются более сложные инструменты, такие как Kubernetes. Он позволяют автоматически управлять, масштабировать и восстанавливать сервисы в больших системах. Про него поговорим в следующей статье.