Для тех, кто работает с 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