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

Мне один раз досталась в наследство компания, где периодически падал локальный DNS сервер. Когда это случилось первый раз, было стрёмно. Я ещё только изучал инфраструктуру. Там и кластер виртуализации был, и DRBD диски, и домен на Samba. Разом всё сломалось, мониторинг спамит, пользователи жалуются техподдержке, она теребит меня. Быстро догадался зайти по IP на сервер и перезапустить тогда ещё использовавшийся Bind, если не ошибаюсь. Потом уже всё перенастроил, но Bind успел упасть ещё пару раз. На серваке, где он работал, как потом выяснилось, банально кончалась память.

Сам я потом тоже использовал какое-то время Bind, потом перешёл на DNSmasq, если в инфре была винда, то использовал её DNS сервер, если есть железный роутер, то DNS сервер обычно на нём. На базе DNSmasq собран небезызвестный Pi-hole. Я немного пользовался им, даже запускал его в контейнере на Mikrotik. В итоге отказался, так как всё это ненадёжно работало на моём железе.

Длинная подводка получилась. Рассказать хотел о новом для меня DNS сервере - Technitium DNS. Впервые увидел его в недавнем обзоре. По описанию понравилось, поэтому решил попробовать. Особенно привлекла простая возможность собрать полноценный (но однонаправленный) кластер. Я всё это развернул у себя, в том числе и кластер, и протестировал. DNS сервер понравился. Думаю, что при необходимости буду использовать именно его, если нужен будет сервер с веб панелью управления, статистикой, разграничением доступа, блокировками по готовым спискам и т.д.

Technitium DNS - современный сервер, который поддерживает всевозможные технологии и настройки:

▪️DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC, DNSSEC.
▪️Блокировки по готовым спискам доменов.
▪️Быстрый запуск через готовый Docker контейнер (есть и другие способы).
▪️Расширение функциональности через встроенный магазин приложений (может, к примеру, логи запросов писать в MySQL).
▪️Встроенный DHCP сервер.
▪️Управление доступом на основе ролей (RBAC).
▪️API с доступом по токенам.
▪️Поддержка работы через HTTP и SOCKS5 прокси.

В этом сервере есть всё, что можно только придумать и желать от современного программного продукта. Я пробежался по огромному списку возможностей и не придумал, чего там не хватает.

При этом, всё это настраивается очень просто, особенно в базовой функциональности. Я развернул на двух нодах и собрал сервер в кластер. Использовал следующий docker-compose.yml, изменив только имя хостов:

services:
 dns-server:
  container_name: technitium-01
  hostname: technitium-01
  image: technitium/dns-server:latest
  ports:
   - "5380:5380/tcp" # Web console (HTTP)
   - "53:53/udp"   # DNS service
   - "53:53/tcp"   # DNS service
   - "53443:53443/tcp" # Web console (HTTPS)
   # - "853:853/udp"   # DNS-over-QUIC
   # - "853:853/tcp"   # DNS-over-TLS
   # - "443:443/udp"   # DNS-over-HTTPS (HTTP/3)
   # - "443:443/tcp"   # DNS-over-HTTPS (HTTP/1.1, HTTP/2)
   # - "67:67/udp"    # DHCP service
  environment:
   - DNS_SERVER_DOMAIN=home.local
   - DNS_SERVER_ADMIN_PASSWORD=your_password
   - DNS_SERVER_PREFER_IPV6=false
   - DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
   - DNS_SERVER_FORWARDERS=62.76.76.62,77.88.8.1,62.76.62.76,77.88.8.8
  volumes:
   - ./config:/etc/dns
  restart: unless-stopped
  sysctls:
   - net.ipv4.ip_local_port_range=1024 65000

Запустил, зашёл на веб интерфейс http://server-ip:5380/, собрал в кластер, настроил списки блокировки и другие настройки. Подключил нескольким пользователям. Проверил - отлично работает, никаких проблем не возникло. Выключил одну ноду, кластер продолжил работать на второй, запросы резолвил.

Продукт однозначно хорош. Я не знаю, что сейчас есть лучше для рекурсивного кэширующего DNS сервера. Если знаете - подскажите.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#dns

Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство по этой теме.

Проект относительно новый, стартовал в 2018 году в противовес стеку ELK. Grafana решила сделать более простой и легковесный вариант хранения логов немного с другой моделью анализа, без полной индексации текстов логов, используя вместо этого метки для потоков. На деле получился хороший продукт, интегрированный в стек Grafana + Prometheus с похожей идеологией хранения и поиска (язык запросов LogQL по аналогии с PromQL).

Для начала выполню базовые действия для запуска Loki и Grafana и настрою отправку логов в Loki от различных Docker контейнеров. Большее в одну заметку не уместить. Думаю, что далее я эту тему разовью.

Я не буду запускать Loki и Grafana в одном Docker Compose файле, так как им не обязательно быть установленными вместе. Grafana поддерживает весь стек своих продуктов, так что нет особого смысла поднимать её рядом со сборщиком логов.

Сначала запустим Loki. Готовим для него compose.yaml и конфигурацию в config.yaml. Не буду приводить здесь содержимое. Оно будет отправлено следующим сообщением в архиве со всеми остальными конфигурациями. Для удобства скопировал её же в gitflic.

# curl https://get.docker.com | bash -
# git clone https://gitflic.ru/project/serveradmin/grafana-loki.git
# cd grafana-loki/loki/

В файле compose.yaml укажите актуальную версию image на момент установки. Запускаем проект:

# docker compose up -d

Проверим, что сервис стартовал:

# curl http://192.168.137.29:3100
404 page not found

Это нормальный ответ. 404 нам ответил Loki. Запустим теперь Grafana:

# cd ../grafana

Указываем нужную версию в compose.yaml и запускаем:

# docker compose up -d

Идём браузером по IP сервера, где запущена Grafana на порт 3000. Учётка по умолчанию - admin / admin. Заходим в Grafana, идём в раздел Connections ⇨ Data sources ⇨ Add data source. Выбираем Loki. В качестве настроек достаточно указать только url. В моём случае это http://192.168.137.30:3100/. Мотаем страничку в самый низ и нажимаем Save & Test. Ошибок быть не должно.

Стек поднят и готов к приёму логов. Отправим туда логи контейнеров Docker. Для этого у Docker существует драйвер. Его необходимо установить на хосте:

# docker plugin install grafana/loki-docker-driver:3.6.0-amd64 --alias loki --grant-all-permissions

Проверяем, что он установился:

# docker plugin ls
018395707e37  loki:latest  Loki Logging Driver  true

Всё в порядке. Теперь мы можем в самом демоне Docker настроить отправку всех логов в Loki через правку его конфигурации в /etc/docker/daemon.json. Для этого туда надо добавить:

{
  "debug": true,
  "log-driver": "loki",
  "log-opts": {
    "loki-url": "http://192.168.137.30:3100//loki/api/v1/push",
    "loki-batch-size": "400"
  }
}

Это не очень удобно, если у нас нет желания собирать логи абсолютно всех контейнеров. Удобнее управлять этим для каждого контейнера отдельно. Для этого в compose файл достаточно добавить ещё одну секцию logging. Покажу сразу итоговый пример для запуска Grafana из этой публикации:

services:
 grafana:
  image: docker.io/grafana/grafana-oss:12.3.1
  container_name: grafana
  logging:
   driver: loki
   options:
    loki-url: "http://192.168.137.30:3100/loki/api/v1/push"
    loki-retries: 2
    loki-max-backoff: 800ms
    loki-timeout: 1s
    keep-file: "true"
    mode: "non-blocking"
  ports:
   - "3000:3000"
  volumes:
   - grafana-data:/var/lib/grafana
  restart: unless-stopped
volumes:
 grafana-data:
  driver: local

Перезапускаем проект:

# docker compose stop
# docker compose up -d

Идём в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service имя контейнера и смотрим его логи.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #devops