Как только поднимается тема контейнеров, неизменно начинается обсуждение производительности. Что туда можно засунуть, что нет и т.д. Особое внимание уделяют СУБД. Когда-то давно я увидел тесты работы форка MySQL - Percona:
⇨ Measuring Percona Server Docker CPU/network overhead
Там запускают СУБД в разных режимах. Приведу сразу результаты:
1️⃣ Железо - 7100 транзакций в секунду. Это максимум.
2️⃣ БД в контейнере, подключение с хоста через замапленный tcp порт - 2200 транз/c. Самый слабый результат, так как подключение идет через проброс порта в iptables.
3️⃣ БД в контейнере, который подключен напрямую в сеть хоста через net=host, подключение с хоста. Результат - те же самые 7100 транз/c.
4️⃣ БД в контейнере, подключение из другого контейнера. Контейнеры соединены между собой через docker bridge. Результат - 6300 транз/c.
Судя по этим тестам, сама по себе работа в контейнере никакого статистически значимого штрафа производительности не добавляет. Накладные расходы появляются там, где возникают дополнительные промежуточные звенья в виде NAT или Bridge, что в общем то логично. Запуск через
Казалось бы всё просто и понятно, можно не париться и не переживать по этому поводу. Минимизирует сетевые прослойки и получаем, как везде говорят, маленькие накладные расходы, которые можно игнорировать. Но не так давно смотрел другие тесты:
▶️ Насколько тормозит Docker? Тестируем сетевые режимы
Там автор провёл прикладные тесты таких же режимов работы, только для веб сервера Angie с разными статическими страницами (большая и маленькая). Результаты немного другие:
- Запуск на хосте - 100% производительности
- Docker c
- Docker с
Картина уже совсем другая. И даже с
При этом нельзя выделить какую-то универсальную величину, на которую можно ссылаться при вычислении накладных расходов. Они очень сильно разнятся от характера нагрузки. В тестах с СУБД, насколько я понимаю, основная нагрузка была на CPU при выполнении сложных запросов. А в веб сервере отдавались несжатые данные маленькими объёмами, нагрузки на CPU было меньше, а вот системных вызовов в разы больше.
Так что с контейнерами не всё так однозначно, чтобы можно было сказать, что штраф незначительный, можно не учитывать. Где-то может быть значительный. Тот же прокси сервер для веб проектов имеет смысл запускать не в контейнере, а напрямую на хосте. Никаких особых проблем с деплоем и настройкой не будет, но сходу можно получить 20-30% прироста производительности на ровном месте.
И в завершении подытожу, что если с контейнерами хотите получить максимальную производительность, то точно нужно использовать сетевой режим
#docker #devops
⇨ Measuring Percona Server Docker CPU/network overhead
Там запускают СУБД в разных режимах. Приведу сразу результаты:
Судя по этим тестам, сама по себе работа в контейнере никакого статистически значимого штрафа производительности не добавляет. Накладные расходы появляются там, где возникают дополнительные промежуточные звенья в виде NAT или Bridge, что в общем то логично. Запуск через
docker run -p 8080:8080, добавляет новую прослойку в виде iptables и его проброса портов через DNAT. Надо ещё понимать, что эти же прослойки и вне контейнера возникнут, если у вас нагрузка, например, распределена между виртуальными машинами.Казалось бы всё просто и понятно, можно не париться и не переживать по этому поводу. Минимизирует сетевые прослойки и получаем, как везде говорят, маленькие накладные расходы, которые можно игнорировать. Но не так давно смотрел другие тесты:
Там автор провёл прикладные тесты таких же режимов работы, только для веб сервера Angie с разными статическими страницами (большая и маленькая). Результаты немного другие:
- Запуск на хосте - 100% производительности
- Docker c
net=host - 67% и 79% от хоста в зависимости от страницы- Docker с
-p 8080:80 45% и 54%Картина уже совсем другая. И даже с
net=host разница с запуском на хосте значительная. При этом плавает от характера нагрузки. Чем больше rps, тем более заметна разница. При этом нельзя выделить какую-то универсальную величину, на которую можно ссылаться при вычислении накладных расходов. Они очень сильно разнятся от характера нагрузки. В тестах с СУБД, насколько я понимаю, основная нагрузка была на CPU при выполнении сложных запросов. А в веб сервере отдавались несжатые данные маленькими объёмами, нагрузки на CPU было меньше, а вот системных вызовов в разы больше.
Так что с контейнерами не всё так однозначно, чтобы можно было сказать, что штраф незначительный, можно не учитывать. Где-то может быть значительный. Тот же прокси сервер для веб проектов имеет смысл запускать не в контейнере, а напрямую на хосте. Никаких особых проблем с деплоем и настройкой не будет, но сходу можно получить 20-30% прироста производительности на ровном месте.
И в завершении подытожу, что если с контейнерами хотите получить максимальную производительность, то точно нужно использовать сетевой режим
host.#docker #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Percona Database Performance Blog
Measuring Percona Server Docker CPU/network overhead
Now that we have Percona Server Docker images, I wanted to measure performance when we run database in the container. In theory there should be very light overhead.
22👍107👎6
Иногда перед запуском контейнеров в Docker Compose хочется выполнить какой-нибудь скрипт или просто набор команд. У данной задачи может быть много различных решений. Предлагаю одно из них, когда перед запуском основных контейнеров запускается какой-то малюсенький c оболочкой, например, sh.
С помощью такого трюка можно запустить какие-то миграции для БД или залить туда какой-то дамп с данными или схемой, сгенерировать какой-нибудь конфиг, создать нужные директории или просто что-то записать, если по какой-то причине вам это надо сделать именно там (куда же без костылей). Для того, чтобы не тащить внешние скрипты, выполним всё прямо в command первого контейнера.
Удобно для этого взять busybox, потому что там много всего есть и он маленький. Но можно обойтись и голым alpine.
Прямо в compose файле создали конфигурацию Nginx и добавили статическую страничку. Вместо длинной строки command можно записать более наглядно:
Если что-то пойдёт не так и команда не будет выполнена успешно, то второй контейнер не запустится из-за
Если надо что-то сделать на самом хосте перед запуском контейнеров, то просто через volumes подключаем директорию хоста и делаем там всё, что нам надо.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
С помощью такого трюка можно запустить какие-то миграции для БД или залить туда какой-то дамп с данными или схемой, сгенерировать какой-нибудь конфиг, создать нужные директории или просто что-то записать, если по какой-то причине вам это надо сделать именно там (куда же без костылей). Для того, чтобы не тащить внешние скрипты, выполним всё прямо в command первого контейнера.
Удобно для этого взять busybox, потому что там много всего есть и он маленький. Но можно обойтись и голым alpine.
services:
init-nginx:
image: alpine
command: ["/bin/sh", "-c", "echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf && echo 'Compose Exec' > /html/index.html"]
volumes:
- nginx_config:/config
- nginx_html:/html
nginx:
image: nginx:latest
volumes:
- nginx_config:/etc/nginx/conf.d
- nginx_html:/usr/share/nginx/html
ports:
- "8080:80"
depends_on:
init-nginx:
condition: service_completed_successfully
volumes:
nginx_config:
nginx_html:
Прямо в compose файле создали конфигурацию Nginx и добавили статическую страничку. Вместо длинной строки command можно записать более наглядно:
entrypoint: /bin/sh
command:
- "-c"
- |
echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf
echo 'Compose Exec' > /html/index.html
Если что-то пойдёт не так и команда не будет выполнена успешно, то второй контейнер не запустится из-за
condition: service_completed_successfully.Если надо что-то сделать на самом хосте перед запуском контейнеров, то просто через volumes подключаем директорию хоста и делаем там всё, что нам надо.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
1👍104👎2
Для тех, кто ещё не слышал или не знает, расскажу новости про ограничения на загрузку образов из Docker Hub. Вышла какая-то непонятная история, поэтому решил разобраться. Компания Docker анонсировала внедрение новых лимитов на загрузку образов из их хранилища, причём довольно суровых. Обещали только 10 загрузок в час для неаутентифицированных пользователей. То есть сделали в час 10
Ограничение довольно суровое даже для каких-то личных историй с тестами локально, не говоря уже об использовании в пайплайнах. Прогнал несколько отладочных тестов и всё. Для аутентифицированных пользователей, даже бесплатных, обещали 100 запросов в час, что в целом уже приемлемо и можно пользоваться, как прежде.
Я собрался рассказать, как по-быстрому настроить аутентификацию как локально, так и в том же Gitlab. Последние уже запланировали изменение в веб интерфейсе, чтобы можно было легко указать учётные данные для Docker. Также хотел упомянуть про локальные хранилища образов, которые можно развернуть у себя.
Зашёл на днях на страничку с лимитами и удивился, так как никаких новых лимитов там нет, можно не суетиться. Хотя я своими глазами видел, что они были, и даже отдельно была выделена новость, что с 1-го апреля они изменились. По факту сейчас всё так же, как и было: 100 запросов за 6 часов без аутентификации и 200 с ней. Протёр глаза и понял, что мне не мерещится. Реально изменений нет.
Сходу как-то даже новости на нашёл на эту тему. Практически молча всё откатили обратно, как было. Немного поискав, нашёл обновлённую старую новость от 21 февраля:
April 8, 2025: No changes to Docker Hub rate limits at this time
Не знаю, по какой причине, но они передумали вводить новые лимиты. И пообещали, что если опять надумают, то предупредят минимум за 6 месяцев.
Для того, чтобы не зависеть от каких-либо ограничений со стороны Docker Hub, можно использовать свои registry. Настроить их очень просто и быстро. Вообще никаких проблем:
▪️Nexus
▪️Harbor
▪️Gitlab Registry
▪️Docker Registry + UI
Для того, чтобы туда автоматом закидывать образы с Docker Hub, можно воспользоваться, к примеру, Sinker. Или чем-то ещё. Таких утилит много. Можно настроить обращения к Docker Hub так, чтобы не выходить за лимиты, и держать свой локальный registry с актуальными образами.
#docker #devops
docker pull и получили временный бан, пока лимит не сбросится. Ограничение довольно суровое даже для каких-то личных историй с тестами локально, не говоря уже об использовании в пайплайнах. Прогнал несколько отладочных тестов и всё. Для аутентифицированных пользователей, даже бесплатных, обещали 100 запросов в час, что в целом уже приемлемо и можно пользоваться, как прежде.
Я собрался рассказать, как по-быстрому настроить аутентификацию как локально, так и в том же Gitlab. Последние уже запланировали изменение в веб интерфейсе, чтобы можно было легко указать учётные данные для Docker. Также хотел упомянуть про локальные хранилища образов, которые можно развернуть у себя.
Зашёл на днях на страничку с лимитами и удивился, так как никаких новых лимитов там нет, можно не суетиться. Хотя я своими глазами видел, что они были, и даже отдельно была выделена новость, что с 1-го апреля они изменились. По факту сейчас всё так же, как и было: 100 запросов за 6 часов без аутентификации и 200 с ней. Протёр глаза и понял, что мне не мерещится. Реально изменений нет.
Сходу как-то даже новости на нашёл на эту тему. Практически молча всё откатили обратно, как было. Немного поискав, нашёл обновлённую старую новость от 21 февраля:
April 8, 2025: No changes to Docker Hub rate limits at this time
Не знаю, по какой причине, но они передумали вводить новые лимиты. И пообещали, что если опять надумают, то предупредят минимум за 6 месяцев.
Для того, чтобы не зависеть от каких-либо ограничений со стороны Docker Hub, можно использовать свои registry. Настроить их очень просто и быстро. Вообще никаких проблем:
▪️Nexus
▪️Harbor
▪️Gitlab Registry
▪️Docker Registry + UI
Для того, чтобы туда автоматом закидывать образы с Docker Hub, можно воспользоваться, к примеру, Sinker. Или чем-то ещё. Таких утилит много. Можно настроить обращения к Docker Hub так, чтобы не выходить за лимиты, и держать свой локальный registry с актуальными образами.
#docker #devops
👍80👎2
Искал на днях материалы на тему Playwright. Это фреймворк для веб тестирования и автоматизации, более современный аналог Selenium. Последний я немного учил, но он довольно замороченный, с полтычка не освоишь. Playwright показался немного попроще в каких-то базовых вещах.
Рассказать сегодня хотел не об этом. Я попал на сайт к какому-то девопсу, где были материалы по Playwright. Я немного походил по нему и набрёл на раздел DevTools. Он там собрал то ли свои, то ли просто open source инструменты для решения простых прикладных задач. Вроде ничего особенного, но некоторые вещи я просто не знал, что вообще существуют. Всегда их делал вручную.
Покажу сразу на примерах, что мне показалось полезным:
- Docker Run to Docker Compose Converter
Отправляем в форму однострочник с
- Docker Compose to Docker Run Converter
И соответственно в обратную сторону преобразование из docker compose в однострочник для
- Bash Command Formatter
Эта штука тоже очень понравилась. Она длинный однострочник разбивает на строки с переходами через \ То есть вот такую колбасу:
Нарезает на кусочки:
Я тоже всегда это вручную делал, особенно для публикации сюда. Можно упростить себе задачу.
- URL Extractor
Просто кидаешь сюда любой текст, а на выходе получаешь набор ссылок, если они в нём присутствуют.
Там много всяких конвертеров и анализаторов синтаксиса для json, yaml, toml, csv. Не стал обращать на них внимание, так как их существует десятки. Обычно просто в гугле ищут что-то подобное, когда надо преобразовать. Посмотрите список, может вам что-то ещё приглянётся. Меня впечатлили только эти четыре штуки.
#devops #docker #bash
Рассказать сегодня хотел не об этом. Я попал на сайт к какому-то девопсу, где были материалы по Playwright. Я немного походил по нему и набрёл на раздел DevTools. Он там собрал то ли свои, то ли просто open source инструменты для решения простых прикладных задач. Вроде ничего особенного, но некоторые вещи я просто не знал, что вообще существуют. Всегда их делал вручную.
Покажу сразу на примерах, что мне показалось полезным:
- Docker Run to Docker Compose Converter
Отправляем в форму однострочник с
docker run и получаем файл для docker compose. Вроде мелочь, но я всегда это делал вручную. Не думал, что кому-то придёт в голову написать конвертер.- Docker Compose to Docker Run Converter
И соответственно в обратную сторону преобразование из docker compose в однострочник для
docker run. Не припоминаю, чтобы мне приходилось такие преобразования делать, но в тему к первому упоминаю.- Bash Command Formatter
Эта штука тоже очень понравилась. Она длинный однострочник разбивает на строки с переходами через \ То есть вот такую колбасу:
curl -v --url "smtp://mail.server.ru:25" --mail-from "root@server.ru" --mail-rcpt "user@gmail.com" --user 'root@server.ru:password123' --upload-file ~/mail.txtНарезает на кусочки:
curl -v \ --url "smtp://mail.server.ru:25" \ --mail-from "root@server.ru" \ --mail-rcpt "user@gmail.com" \ --user 'root@server.ru:password123' \ --upload-file ~/mail.txtЯ тоже всегда это вручную делал, особенно для публикации сюда. Можно упростить себе задачу.
- URL Extractor
Просто кидаешь сюда любой текст, а на выходе получаешь набор ссылок, если они в нём присутствуют.
Там много всяких конвертеров и анализаторов синтаксиса для json, yaml, toml, csv. Не стал обращать на них внимание, так как их существует десятки. Обычно просто в гугле ищут что-то подобное, когда надо преобразовать. Посмотрите список, может вам что-то ещё приглянётся. Меня впечатлили только эти четыре штуки.
#devops #docker #bash
👍111👎2
Современная веб разработка и частично эксплуатация плотно завязаны на Docker контейнеры. Они используются повсеместно. Недавние истории с временной блокировкой docker hub и внедрением новых лимитов одним днём усложнили жизнь тем, кто завязан на публичное хранилище образов в виде Docker Hub. При этом нет никаких проблем использовать своё Docker Registry, причём как для хранения своих образов, так и кэширования запросов с Docker Hub.
Использовать своё хранилище образов имеет смысл уже при наличии хотя бы пары разработчиков, которые с ними работают. Я уже кратенько упоминал, что существуют различные бесплатные self-hosted решения:
🔹Gitlab Registry или Gitea Registry. Их имеет смысл использовать, если у вас используется одноимённая инфраструктура для хранения кода. С Gitlab Registry проблем особых нет, кроме некоторых заморочек с проксированием, а у Gitea Registry после релиза были некоторые баги. Сейчас не знаю как, наверное уже поправили.
🔹Nexus - известное хранилище для репозиториев и Docker образов. Это комбайн, где можно хранить всё, что угодно: deb и rpm репы, репозиторий контейнеров, npm репозиторий, pypi и многие другие. Если у вас задача только для Docker, то наверное такой комбайн большого смысла использовать нет. Хотя каких-то особых проблем с установкой и настройкой не будет. Я не раз его настраивал. Установить и запустить в работу относительно просто. Всё управление через веб интерфейс.
🔹Docker Registry - продукт от самого Docker. Это был маленький легковесный проект без GUI. Сейчас глянул, а он уже deprecated, его кому-то отдали и переименовали в Distribution. Не знаю даже, что про него сказать. Описание куцее. Посмотрел документацию. На вид это продолжение того же небольшого проекта без GUI, что не очень удобно. Есть веб интерфейс от стороннего разработчика - docker-registry-ui.
🔹Harbor. На нём я хочу остановиться подробно. Это самостоятельное open source хранилище для образов Docker с встроенным веб интерфейсом и хорошим набором возможностей в open source версии. Вот основные:
◽️управление доступом на основе ролей (RBAC)
◽️поддержка LDAP для аутентификации
◽️автоматическая проверка образов с помощью Trivy
◽️режим работы как proxy/кэш-сервер для Docker Hub или других Registry
Имеем универсальное, бесплатное и функциональное решение для собственного хранилища образов. Для небольшой установки подойдёт обычная VPS с 2CPU и 4GB оперативной памяти. Показываю пошаговую установку:
В конфигурации надо указать:
Для использования HTTPS надо предварительно получить сертификаты и указать их:
Можно получить как бесплатные от Let's Encrypt, так и использовать самоподписанные. Я получил бесплатные так:
Укажите пароль для admin и место для хранилища образов. Остальные настройки можно не трогать.
Устанавливаем Harbor:
Дожидаемся загрузки и запуска всех контейнеров. После этого идём в веб интерфейс по настроенному ранее домену. Логинимся под учётной записью admin и паролем из конфигурации.
В разделе Registries добавляем Endpoint и указываем Provider - Docker Hub. Cоздаём новый проект, ставим галочку Proxy Cache, указываем созданный Endpoint.
На рабочей машине логинимся:
Сache - имя созданного проекта. Образ nginx будет скачан через Harbor и останется там в кэше.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#devops #docker
Использовать своё хранилище образов имеет смысл уже при наличии хотя бы пары разработчиков, которые с ними работают. Я уже кратенько упоминал, что существуют различные бесплатные self-hosted решения:
🔹Gitlab Registry или Gitea Registry. Их имеет смысл использовать, если у вас используется одноимённая инфраструктура для хранения кода. С Gitlab Registry проблем особых нет, кроме некоторых заморочек с проксированием, а у Gitea Registry после релиза были некоторые баги. Сейчас не знаю как, наверное уже поправили.
🔹Nexus - известное хранилище для репозиториев и Docker образов. Это комбайн, где можно хранить всё, что угодно: deb и rpm репы, репозиторий контейнеров, npm репозиторий, pypi и многие другие. Если у вас задача только для Docker, то наверное такой комбайн большого смысла использовать нет. Хотя каких-то особых проблем с установкой и настройкой не будет. Я не раз его настраивал. Установить и запустить в работу относительно просто. Всё управление через веб интерфейс.
🔹Docker Registry - продукт от самого Docker. Это был маленький легковесный проект без GUI. Сейчас глянул, а он уже deprecated, его кому-то отдали и переименовали в Distribution. Не знаю даже, что про него сказать. Описание куцее. Посмотрел документацию. На вид это продолжение того же небольшого проекта без GUI, что не очень удобно. Есть веб интерфейс от стороннего разработчика - docker-registry-ui.
🔹Harbor. На нём я хочу остановиться подробно. Это самостоятельное open source хранилище для образов Docker с встроенным веб интерфейсом и хорошим набором возможностей в open source версии. Вот основные:
◽️управление доступом на основе ролей (RBAC)
◽️поддержка LDAP для аутентификации
◽️автоматическая проверка образов с помощью Trivy
◽️режим работы как proxy/кэш-сервер для Docker Hub или других Registry
Имеем универсальное, бесплатное и функциональное решение для собственного хранилища образов. Для небольшой установки подойдёт обычная VPS с 2CPU и 4GB оперативной памяти. Показываю пошаговую установку:
# curl https://get.docker.com | bash -# wget https://github.com/goharbor/harbor/releases/download/v2.12.3/harbor-online-installer-v2.12.3.tgz# tar xzvf harbor-online-installer-v2.12.3.tgz# cd harbor/# cp harbor.yml.tmpl harbor.ymlВ конфигурации надо указать:
hostname: domain.example.com # или IP-адресДля использования HTTPS надо предварительно получить сертификаты и указать их:
https: port: 443 certificate: /etc/letsencrypt/live/338365.simplecloud.ru/fullchain.pem private_key: /etc/letsencrypt/live/338365.simplecloud.ru/privkey.pemМожно получить как бесплатные от Let's Encrypt, так и использовать самоподписанные. Я получил бесплатные так:
# apt install certbot# certbot certonly -d 338365.simplecloud.ruУкажите пароль для admin и место для хранилища образов. Остальные настройки можно не трогать.
harbor_admin_password: Harbor12345data_volume: /dataУстанавливаем Harbor:
# ./prepare# ./install.sh --with-trivyДожидаемся загрузки и запуска всех контейнеров. После этого идём в веб интерфейс по настроенному ранее домену. Логинимся под учётной записью admin и паролем из конфигурации.
В разделе Registries добавляем Endpoint и указываем Provider - Docker Hub. Cоздаём новый проект, ставим галочку Proxy Cache, указываем созданный Endpoint.
На рабочей машине логинимся:
# docker login <harbor-host># docker pull <harbor-host>/cache/nginxСache - имя созданного проекта. Образ nginx будет скачан через Harbor и останется там в кэше.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#devops #docker
👍102👎2
У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
Можно просто в Docker запустить:
Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
# trufflehog git https://github.com/trufflesecurity/test_keysЭто пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/binМожно просто в Docker запустить:
# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keysЕсли запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
# trufflehog filesystem --config=$PWD/generic.yml /var/logTrufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
1👍80👎3
Вчера обновил один из своих тестовых серверов Proxmox версии 8.4 до недавно вышедшей 9.1. Ничего не выдумывал, сделал всё строго по официальной инструкции. Всё совпало до каждого пункта и предупреждения. Причём даже с установленным на этом же хосте PBS прямо на железо вместе с PVE. Никаких конфликтов и проблем не возникло.
Обновиться решил из-за некоторых нововведений релиза 9.1. Когда вышел 9.0, обновляться не стал даже из любопытства, так как не увидел каких-то интересных и полезных обновлений.
А вот в 9.1 как минимум появилась возможность запускать напрямую Docker контейнеры, что хоть и не решает каких-то глобальных проблем, но выглядит интересно. Плюс, у контейнеров в веб интерфейсе виден настроенный IP адрес, чего не хватало. Люди городили костыли для этого, теперь они не нужны.
Попробовал я запуск Docker контейнеров и могу сказать, что пока это всё игрушки и не очень удобно. Работает это так:
1️⃣ В локальное хранилище предварительно загружается Docker контейнер. В том же разделе, где загружаются образы LXC.
2️⃣ Создаётся новый контейнер, где в качестве образа выбирается скачанный ранее контейнер. Настройки все те же, что и в случае с LXC. По факту вы LXC и создаёте, где автоматически запустится контейнер докера.
3️⃣ Переменные вынесены в отдельный раздел в Options в настройках контейнера.
4️⃣ Контейнер запускается на выбранном сетевом бридже и использует настроенный в момент создания IP адрес.
На практике всё это выглядит точно так же, как LXC, только запускается контейнер Docker из Docker Hub. Причём одиночный контейнер фиксированной версии. Я так и не понял, как его обновить, кроме как скачать образ новой версии и снова запустить его, подключив тот же диск.
Получилась некая новая сущность, и не LXC, и не Docker, а что-то между ними. Данные контейнера пишутся и хранятся на подключенный raw образ. То есть контейнер нормально бэкапится и переносится. Но при этом в него не зайти, как в LXC, через веб интерфейс. Не выполнить
В таком виде это удобно только для запуска одиночных Docker контейнеров. С ними можно работать, как с LXC или виртуальными машинами - бэкапить, переносить, выделять ресурсы. Думаю, что это только проба пера и функциональность будут наращивать до уровня взаимодействия Docker Compose. А пока для полноценного запуска нескольких контейнеров придётся действовать как и раньше:
Cоздание контейнера LXC ⇨ установка Docker и Docker Compose ⇨ загрузка YML-файла ⇨ запуск контейнеров.
По идее вот эту цепочку должны в итоге реализовать в более аккуратном и удобном виде в следующих релизах.
❓Если уже используете эту функциональность, то что думаете по этому поводу? Как я уже сказал, для одиночного контейнера всё неплохо. А для связки из нескольких контейнеров пока неприменимо. Ну и обновление надо как-то автоматизировать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#proxmox #docker
Обновиться решил из-за некоторых нововведений релиза 9.1. Когда вышел 9.0, обновляться не стал даже из любопытства, так как не увидел каких-то интересных и полезных обновлений.
А вот в 9.1 как минимум появилась возможность запускать напрямую Docker контейнеры, что хоть и не решает каких-то глобальных проблем, но выглядит интересно. Плюс, у контейнеров в веб интерфейсе виден настроенный IP адрес, чего не хватало. Люди городили костыли для этого, теперь они не нужны.
Попробовал я запуск Docker контейнеров и могу сказать, что пока это всё игрушки и не очень удобно. Работает это так:
На практике всё это выглядит точно так же, как LXC, только запускается контейнер Docker из Docker Hub. Причём одиночный контейнер фиксированной версии. Я так и не понял, как его обновить, кроме как скачать образ новой версии и снова запустить его, подключив тот же диск.
Получилась некая новая сущность, и не LXC, и не Docker, а что-то между ними. Данные контейнера пишутся и хранятся на подключенный raw образ. То есть контейнер нормально бэкапится и переносится. Но при этом в него не зайти, как в LXC, через веб интерфейс. Не выполнить
docker ps или docker inspect, как в обычной среде запуска Docker. Контейнеры Docker не связать между собой, как это сделано в Docker Compose.В таком виде это удобно только для запуска одиночных Docker контейнеров. С ними можно работать, как с LXC или виртуальными машинами - бэкапить, переносить, выделять ресурсы. Думаю, что это только проба пера и функциональность будут наращивать до уровня взаимодействия Docker Compose. А пока для полноценного запуска нескольких контейнеров придётся действовать как и раньше:
Cоздание контейнера LXC ⇨ установка Docker и Docker Compose ⇨ загрузка YML-файла ⇨ запуск контейнеров.
По идее вот эту цепочку должны в итоге реализовать в более аккуратном и удобном виде в следующих релизах.
❓Если уже используете эту функциональность, то что думаете по этому поводу? Как я уже сказал, для одиночного контейнера всё неплохо. А для связки из нескольких контейнеров пока неприменимо. Ну и обновление надо как-то автоматизировать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#proxmox #docker
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍95👎5