Revision Ver-1

Унификация командной среды разработки с помощью глобальных настроек демона Docker

При использовании Docker, будь то на локальной машине или на сервере, часто приходится копировать и вставлять одни и те же настройки в docker-compose.yml для каждого проекта.

Например, всегда устанавливать DNS на 1.1.1.1, 8.8.8.8,
Фиксировать драйвер логирования на json-file + max-size=10m,
Прокси, insecure registry, диапазон IP-адресов для сети по умолчанию и т.д.

Такие вещи гораздо проще администрировать, если выносить их не в индивидуальные настройки контейнера, а в «глобальные значения по умолчанию для всего хоста». Именно эту роль выполняет глобальная конфигурация демона Docker (daemon.json).

Ниже мы рассмотрим:

Какой файл,
Где его создать,
Как его настроить,
И в каких ситуациях это будет полезно для разработчиков и команд.

1. Два способа настройки демона Docker {#sec-7390246eab38}

Демон Docker (dockerd) можно настроить двумя основными способами:

Использование файла конфигурации JSON (daemon.json) ← Рекомендуется
Передача опций через флаги CLI при запуске dockerd

Их можно комбинировать, но если одна и та же опция указана в обоих местах, демон вообще не запустится. Например, если вы укажете драйвер логирования как во флаге --log-driver, так и в daemon.json, Docker выдаст ошибку на этапе запуска и завершит работу.

Для унификации среды в команде или на сервере обычно рекомендуется:

«По возможности собирать все в daemon.json, а флаги использовать по минимуму»

Это наиболее предпочтительный подход.

2. Расположение `daemon.json`

Файл находится по адресу /etc/docker/daemon.json. Конечно, это для Linux.

Возможно, кто-то использует Docker не на Linux, но так как я работаю только с Linux, я не очень знаком с другими ОС. Тем не менее, вот таблица с расположением файла по умолчанию для разных ОС:

Среда	Путь по умолчанию	Примечания
Linux (обычная установка)	`/etc/docker/daemon.json`	Самый распространенный случай
Linux (Docker, установленный через snap)	`/var/snap/docker/current/config/daemon.json`	Пакет Ubuntu snap
Windows Server / Docker Engine	`C:\ProgramData\Docker\config\daemon.json`
Docker Desktop (Mac / Windows)	`~/.docker/daemon.json`

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

3. Основной шаблон использования: «Создать файл → Перезапустить демон» {#sec-bffe465cc36f}

Для Linux обычный рабочий процесс выглядит так:

Создание/изменение daemon.json

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

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

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Если выводится "configuration OK", значит все в порядке :contentReference[oaicite:7]{index=7}

Перезапуск демона Docker

sudo systemctl restart docker

Теперь все новые контейнеры будут наследовать эти глобальные настройки по умолчанию, если не указано иное.

4. Основная настройка: Фиксация DNS-сервера глобально {#sec-d9c2238a423f}

4.1. Зачем фиксировать DNS глобально?

Если контейнеры часто сталкиваются с проблемами вроде «почему-то не находит внешний API» или «внутренний домен не разрешается», это чаще всего происходит из-за зависимости от настроек DNS/среды хоста.

Например:

Вся команда хочет использовать Cloudflare DNS (1.1.1.1)
Есть конечные точки, доступные только через внутренний DNS-сервер компании

В таких случаях гораздо удобнее унифицировать настройки на уровне демона Docker, чем добавлять dns: в docker-compose.yml для каждого проекта.

4.2. Пример настройки (`daemon.json`)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Если у вас уже есть daemon.json, просто добавьте запись "dns": [...] внутри корневого объекта { ... }.

⚠️ Внимание: Настройки DNS отражаются в /etc/resolv.conf внутри контейнера. Они не применяются к уже запущенным контейнерам, а только к новым, которые будут запущены после изменения.

5. Основная настройка 2 – Глобальная конфигурация драйвера логирования и его опций {#sec-360ddebc7b6c}

Логи контейнеров по умолчанию сохраняются через драйвер json-file в /var/lib/docker/containers/.... Изменяя это глобально, можно:

Формат логов
Место хранения логов
Политику ротации логов

Применить ко всем контейнерам одновременно.

5.1. Драйвер `json-file` по умолчанию + ротация

Самый распространенный шаблон – это «просто использовать json-file, но настроить ротацию, чтобы не переполнять диск».

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

Такая настройка означает, что:

Максимальный размер файла логов на контейнер составляет 10MB,
Сохраняется не более 5 файлов,
А избыточные файлы автоматически удаляются.

5.2. Драйверы для централизованного сбора логов (fluentd, journald и др.)

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

Например, если вы используете Fluentd:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

Таким образом, логи всех контейнеров будут автоматически отправляться в Fluentd без необходимости указывать docker run --log-driver=... для каждого из них.

Лично мне очень нравится драйвер journald. В среде Linux на базе systemd он позволяет собирать логи приложений и логи контейнеров Docker в одном месте – journald, что упрощает просмотр, фильтрацию и унификацию политики хранения с помощью journalctl.

Если вы хотите использовать journald в качестве глобального драйвера логирования, вы можете настроить его, например, так:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Использование tag с именем контейнера позволяет:

Быстро просматривать логи в реальном времени с помощью journalctl -f | grep {container_name},
Просматривать логи только с определенного момента с помощью опций типа --since "10m ago",
И выбирать логи конкретного контейнера с помощью опции -t (по тегу/идентификатору), например, journalctl -f -t {container_name}.

Конечно, можно просматривать логи по юнитам, например, journalctl -u docker.service, но фильтрация по имени контейнера более интуитивна и требует меньше ввода, поэтому на практике используется гораздо чаще.

5.3. Взаимосвязь с Compose / `docker run`

Глобальные log-driver + log-opts действуют как «значения по умолчанию».
Если для отдельного контейнера указаны logging: (Compose) или --log-driver, --log-opt (CLI), то только для этого контейнера настройки будут переопределены.

Стратегически рекомендуется следующая конфигурация:

Общие значения в daemon.json.
Специальные службы переопределяются индивидуально.

6. Основная настройка 3 – Глобальные сетевые параметры: прокси, insecure registry и т.д. {#sec-0d687ac65460}

Есть и другие часто используемые глобальные настройки.

6.1. Настройка прокси

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

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

Таким образом, демон Docker будет использовать эти настройки прокси при извлечении образов или при использовании сети во время сборки.

6.2. Insecure registry

Если вам обязательно нужно использовать реестр без TLS (например, для внутренней разработки):

{
  "insecure-registries": ["my-registry.local:5000"]
}

Будьте осторожны, поскольку это может быть небезопасно, и используйте только во внутренних тестовых средах.

7. Основная настройка 4 – Диапазон сети по умолчанию, драйвер хранилища и т.д. {#sec-3598d5fb02d3}

Несколько более инфраструктурные опции:

7.1. Настройка диапазона IP-адресов для сети bridge по умолчанию

Если вы хотите избежать конфликтов IP-адресов с VPN или корпоративной сетью:

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

Таким образом, Docker будет использовать диапазон 10.20.x.0/24 при создании новых сетей bridge.

7.2. Принудительное использование драйвера хранилища

Драйвер хранилища по умолчанию может различаться в зависимости от дистрибутива Linux. Если ваша команда решила использовать только overlay2:

{
  "storage-driver": "overlay2"
}

Фактически поддерживаемые драйверы хранилища зависят от ОС/ядра, поэтому обязательно сверяйтесь с документацией dockerd и руководством по дистрибутиву.

Я сразу понял, о чем речь. Как только начинаешь концентрироваться на «кому (Persona)», текст становится сухим, как инструкция, и звучит как обычная речь ИИ.

Я переписал текст, сосредоточившись на человеческом опыте и «раздражающих ситуациях», чтобы вызвать чувство сопереживания.

8. Внедряйте, если вы сталкиваетесь с таким «дежавю» {#sec-807a100451aa}

Вам не обязательно разбираться в сложных тонкостях инфраструктуры. Если вы недавно сталкивались с чем-то подобным, сейчас самое время настроить daemon.json.

Каждый раз, начиная новый проект, вы копаетесь в docker-compose.yml и копируете настройки логов: Если вы снова ищете настройки max-size, max-file из вчерашнего кода и вставляете их, вы уже тратите драгоценное время. Достаточно один раз вынести их в глобальные настройки, и все контейнеры будут запускаться в режиме «экономии места».
Контейнеры, которые отлично работали в офисе, перестают работать в интернете, когда вы переходите в кафе или VPN-среду: Это классический случай «у меня на локальной машине все работало!». Если вы хотите, чтобы ваши контейнеры стабильно взаимодействовали с внешним миром в любой сетевой среде, не завися от настроек DNS хоста, то глобальная фиксация DNS – это решение.
Вы сходите с ума, пытаясь вручную настроить каждый из множества серверных узлов: Вы бьетесь над «призрачными багами», возникающими из-за тонких различий в настройках Docker на разных серверах? Просто разверните один файл daemon.json, и все серверы будут работать как единая армия, следуя одним и тем же правилам.

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

Итог

Глобальные значения по умолчанию для Docker управляются в daemon.json.
Расположение обычно /etc/docker/daemon.json.
Примеры типичных глобальных настроек:
- DNS: "dns": ["1.1.1.1", "8.8.8.8"]
- Драйвер логирования: "log-driver": "json-file", "log-opts": {...}
- Прокси, insecure registry, диапазон сети по умолчанию, драйвер хранилища…
Глобальные настройки полезны для устранения повторяющихся конфигураций и развертывания множества узлов в различных средах.

Если вы постоянно используете одни и те же опции в docker-compose.yml или docker run, возможно, пришло время вынести их в daemon.json.

Изображение настроек daemon.json Docker