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

Речь пойдёт про skopeo. Ставится так:

# apt install skopeo
# dnf install skopeo
# brew install skopeo

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

Смотрим информацию о контейнере и о конфигурации, по аналогии с докеровской командой inspect. Сам образ при этом не скачивается:

# skopeo inspect docker://docker.io/twinproduction/gatus
# skopeo inspect --config docker://docker.io/twinproduction/gatus

# skopeo inspect docker://registry.rocket.chat/rocketchat/rocket.chat
# skopeo inspect --config docker://registry.rocket.chat/rocketchat/rocket.chat

Увидели всю основную информацию о контейнере: версии, когда последний релиз был, слои, порты, Entrypoint и т.д. На самом деле удобно даже для нечастой работы с контейнерами. Я обычно в hub иду руками смотреть последний релиз, если надо уточнить для какого-то нового контейнера. Можно skopeo себе на рабочую машину поставить и пользоваться. Правда если контейнер с большой историей, там огромная портянка тэгов тянется.

Можно образ к себе скачать в виде архива:

# skopeo copy docker://docker.io/nginx:latest --override-os linux docker-archive:/tmp/nginx/nginx-latest.tar

Из архива можно забрать какие-то файлы образа, если они нужны, что-то изменить. Не требуется запуск контейнера. Можно образ залить обратно в свой локальный репозиторий.

# skopeo copy docker-archive:/tmp/nginx/nginx-latest.tar docker://registry.local/nginx:latest

🛡 Подобный трюк с выгрузкой в директорию можно использовать для передачи образов в какой-то закрытый контур без доступа к интернету, да и вообще без лишнего доступа откуда бы то ни было. Можно использовать какую-то сетевую директорию как обменник для образов между внешней средой и закрытой.

Skopeo удобно использовать в CI/CD для некоторых задач. Можно скопировать образ из одного репозитория в другой, например, с публичного в локальный перед запуском других задач:

# skopeo copy docker://docker.io/nginx:latest docker://registry.local/nginx:latest

Можно проверить наличие какой-то тэга перед дальнейшими задачами:

# skopeo list-tags docker://docker.io/twinproduction/gatus

Так же можно подписать образ, выполнить синхронизацию двух репозиториев с набором различных версий контейнеров, пометить образы в репозитории на удаление. Skopeo поддерживает аутентификацию в registry.

Все доступные команды описаны в man:

◽️inspect, list-tags
◽️copy, delete, sync
◽️login, logout
◽️standalone-sign, standalone-verify
◽️generate-sigstore-key, manifest-digest

Там же и некоторые пояснения к формату команд. Этого будет достаточно, чтобы начать пользоваться.

Некоторые полезные ссылки по теме на другие инструменты для Docker:
▪️Sinker для синхронизации образов
▪️Nexus - локальный репозиторий docker образов
▪️Harbor - ещё один локальный registry только для образов
▪️Диагностика работы контейнеров с помощью cdebug
▪️Линтер для Dockerfile - Hadolint
📊Сtop - top для контейнеров
🛡 Проверка образов на уязвимости с помощью Trivy
🛡 Автоматическое закрытие уязвимостей с помощью Copacetic
🛡 Проверка образов с помощью Dockle

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

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

#docker #devops

Я часто упоминал в различных заметках систему по сбору логов 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

Продолжу тему со сбором логов в Loki. Хочу написать законченный цикл заметок, в которых будет показан сбор логов популярных сервисов. В прошлой заметке я установил Loki + Grafana и отправил в Loki логи контейнеров Docker. Сегодня передам туда системные логи формата journald или текстовых файлов от syslog. Я покажу пример с обоими типами логов, а вы уже по месту сможете выбрать, какие использовать.

Изначально у Grafana для сбора логов с хостов была небольшая программа Promtail. Её и сейчас можно использовать, но больше её не развивают и не обновляют. На замену предложен Alloy - огромный комбайн, который включает в себя и сбор логов, их обработку и насыщение дополнительными данными, и преобразование, сбор трейсов, а также отправку системных метрик в Prometheus вместо Node Exporter. То есть Alloy объединяет логи и метрики.

В итоге вместо легковесного и простого в настройке продукта мы получаем комбайн всё в одном. Если используется полный стек Grafana в виде мониторинга, логов и трассировки, то наверное это удобно. Если собираются только логи, то не очень. Вместо Alloy можно взять Fluent Bit, Fluentd или Vector. Последние два легковесны, популярны, с простой настройкой. Можно взять и их. Но я в своём примере ограничусь стеком Grafana и буду использовать Alloy.

Репозиторий Grafana для IP адресов из России заблокирован. В общем случае он добавляется вот так:

# mkdir -p /etc/apt/keyrings
# wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
# chmod 644 /etc/apt/keyrings/grafana.asc
# echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" > /etc/apt/sources.list.d/grafana.list

Мы же подключим копию репозитория из зеркала Яндекса. Для краткости я подключу его без ключа. Если вам это не подходит, то скачайте ключ и как-то передайте его на целевые машины:

# echo "deb [trusted=yes] https://mirror.yandex.ru/mirrors/packages.grafana.com/oss/deb/ stable main" > /etc/apt/sources.list.d/grafana.list
# apt update
# apt install alloy

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

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

Забирайте config.alloy из моего репозитория, копируйте в /etc/alloy и перезапускайте службу. Заодно добавьте в автозагрузку. По умолчанию она вроде не делает этого:

# systemctl restart alloy
# systemctl enable alloy

Больше ничего делать не надо. На все хосты Alloy устанавливается и настраивается аналогично. В Loki логи будут прилетать с метками в виде %hostname%-logs и %hostname%-journal. Соответственно, по именам серверов вы и сможете их там выбирать. Метки, если что, можно изменить. Они настраиваются в параметрах labels и job соответственно. В конфигурации это всё наглядно видно.

По аналогии можно добавить любые текстовые логи. Тут никакой привязки к syslog нет. Просто забираем текстовые логи, определённые параметром:

  __path__  = "/var/log/{syslog,messages,*.log}",

Теперь можно идти в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service с нужным именем и типом логов и смотрим.

Единственное, что мне не нравится тут, так это то, что в тексте лога есть метки времени, и в самом хранилище есть метки времени, когда запись была добавлена. Иногда они не совпадают и это неудобно. В Logstash есть модуль date для того, чтобы выделять дату из текста поступающих логов и использовать ее в качестве даты документа в Elasticsearch.
❓Кто-нибудь настраивал подобное в Loki, чтобы время документа совпадало со временем в логе?

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

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

#loki #logs #devops

Прорабатываю тему централизованного хранения логов в Loki. Потом для удобства объединю её в большую статью. Уже наметил план. Решил, чтобы вечно не откладывать, резать слона по частям, а не пытаться сразу всё сделать.

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

1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них

Сегодня разберу вопрос отправки журналов с логами Windows. Как бы не пытались аврально импортозаместиться, всё равно инфраструктура на Windows - значительная часть. А может и бóльшая, смотря как считать.

На удивление, настройка Alloy оказалась довольно замороченной, несмотря на то, что есть документация. ИИ по какой-то причине предлагает постоянно неработающие конфигурации. Я что с Linux, что с Windows в итоге разбирался сам.

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

Установка Alloy в Windows максимально простая - скачиваем установщик из репозитория и запускаем. Нужен будет файл alloy-installer-windows-amd64.exe.

Alloy устанавливается как служба с автозапуском. После установки нужно отредактировать конфигурацию. К сожалению, если я правильно понял, для логов Windows не работает автообнаружение всех системных журналов, в том числе служб и сервисов с автоматическим назначением меток к ним. Их нужно явно указывать в конфигурации.

Покажу пример с тремя стандартными журналами: System, Application и Security. Положил работающий и отлаженный файл конфигурации в репозиторий. На винде отлаживать неудобно, так как если в конфигурации была ошибка, служба тупо не запускалась с неинформативной ошибкой. Приходилось вручную всё проверять и пробовать разные варианты.

В итоге получил то, что хотел. Для логов назначил две метки:

◽️instance = "имя сервера", например WINSRV01.
◽️job = "имя сервера"-"имя журнала", то есть WINSRV01-application.

С этими метками можно просто открыть все логи сервера по имени и в нём по меткам открыть нужные потоки. Но если будет необходимость сразу из общего списка взять отдельный job конкретного сервера, это тоже можно сделать, так как в названии job будет имя сервера.

Редактируем конфигурацию, перезапускаем службу Alloy и идём в Grafana смотреть логи. Никаких дополнительных настроек делать не надо. Loki сам парсит виндовые логи и выделяет в них стандартные поля: event_id, channel, level, security_userId, timeCreated и т.д. По ним сразу можно делать выборку.

Несмотря на некоторые трудности и неудобства стека на базе Loki и Alloy, пользоваться им приятно в том плане, что базовые настройки относительно просты и функциональны. Можно особо не заморачиваясь просто отправлять логи в Loki и с ними тут будет удобно работать. Он сам распарсит стандартные типы, что позволит сразу выборки делать и рисовать дашборды. Когда изучал ELK с парсингом больше ковырялся. Тут он как-то проще работает.

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

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

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

#loki #logs #devops

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

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

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

Для установки минимальной конфигурации Deckhouse понадобится управляющий компьютер и хотя бы две ноды - master и worker. Я взял 3 виртуальные машины с Debian 13. Управляющая может быть минимальной конфигурации. У меня заработало с 2CPU, 4GB RAM. А вот рабочие ноды - минимум 4CPU и 8GB RAM. На меньшем установка не пойдёт.

На управляющий компьютер установил Docker и открыл руководство установщика. Достаточно просто запустить контейнер и пройти в браузер:

# docker run --rm --pull always -v $HOME/.d8installer:$HOME/.d8installer -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 registry.deckhouse.ru/deckhouse/installer:latest -r $HOME/.d8installer

В руководстве контейнер биндится на 127.0.0.1. Я убрал это, чтобы получить к установщику доступ по сети. Дальше всё сделал по инструкции. Там ничего сложного:

- выбрал редакцию community;
- сгенерировал ssh ключи;
- добавил 2 ноды, указал ip адреса;
- настройки сети и доменного имени не менял, использовал по умолчанию.

Запустил установщик и сразу получил неведомую ошибку ssh - execute on remote: exit status 127. По смыслу понял, что по ssh какая-то команда не запускалась. Так как это было самое начало, то сразу сообразил, что на узлах не хватает sudo. Может это и было где-то указано в руководстве, но я пропустил, сразу не установил. После того, как сделал это, установка пошла.

На master ноду всё установилось без проблем. А вот с worker опять затык. Установка стоит на 50%, в логах ошибок нет. Просто ничего не идёт. Пошёл на ноду разбираться. Установка организована в привычном мне стиле - куча костылей на bash скриптах, залиты по ssh с мастера. Их там около сотни 😁.

Заметил, что висит в вечном цикле скрипт /var/lib/bashible/bashible-new.sh. Посмотрел его содержимое, запустил сам вручную. Увидел, что он ругается на скрипт 000_discover_node_ip.sh. Посмотрел, что он делает - определяет ip ноды и записывает в текстовый файл. Сам не отрабатывает, ругается на несуществующие команды. Не стал разбираться с ним, просто вручную записал ip адрес ноды в текстовый файл, куда он должен записываться.

После этого установка пошла и успешно завершилась. Я получил настроенную работающую платформу. Сразу сходил в раздел Модули и запустил модуль virtualization. Он позволяет управлять виртуальными машинами.

Кластер после запуска минут 10-15 подтупливал и сыпал ошибками. Потом вроде прочихался и неспешно заработал. К сожалению, ничего толком на нём проверить я не смог. Во-первых, там надо разбираться и всё настраивать, что требует какое-то время. А во-вторых, кластеру надо гораздо больше ресурсов. Того, что дал ему я, едва хватает, чтобы самому шевелиться. Он запускает очень много своих сервисов - запущено 95 своих подов.

В целом, у меня всё получилось. Поднял кластер без посторонней помощи, но помогла чуйка. Посоздавал там поды, replicasets. Посмотрел, как всё работает, управляется. На первый взгляд удобно. Установка как-то костыльно сделана с плохой обратной связью и без моих пинков не завелась.

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

#kuber #devops