Тестировал вчера open source панель для управления сервером и установки на него софта - Cosmos. Сам автор позиционирует её как Secure and Easy Selfhosted Home Server. Панель и сама работает в Docker, и софт запускает тоже в контейнерах. Это уже не первая подобная панель на канале. Сразу скажу, что ничего особенного в ней не увидел. Она не лучше и не проще всех остальных похожих.

В целом, пользоваться можно. Даже русский язык есть, но переведено кривовато. Я переключился на английский. У всех подобных панелей на базе Docker есть один существенный минус. Они хоть и позиционируют себя как простые и быстрые в настройке, на деле это не так. Запуск приложений в Docker, особенно когда их много на одном сервере, требует от пользователя понимания, как всё это между собой связано и работает. Постоянно возникают небольшие нюансы в работе, которые не решить без этих знаний. А если вы знаете Docker, то и панель вам особо не нужна. Ставишь Portainer и запускаешь всё там.

Cosmos в целом неплоха в сравнении с остальными. Выделю несколько полезных особенностей:

▪️Интерфейс адаптивен, работает и на мобильных устройствах.
▪️Можно создавать пользователей веб панели. Бесплатная версия позволяет создать 5 штук.
▪️Панель нативно поддерживает работу MergerFS и SnapRAID.
▪️Из коробки HTTPS от Let's Encrypt.
▪️Поддержка OAuth 2.0 и OpenID, 2FA через Google аутентификатор или аналоги.
▪️Есть встроенные средства безопасности, на основании которых можно ограничивать доступ к публикуемым ресурсам. Можно ограничивать доступ на основе групп. Блокировать ботов, тех, кто превышает лимиты по запросам или трафику.

Запустить и посмотреть на Cosmos можно так:

# docker run -d --network host --privileged --name cosmos-server -h cosmos-server --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /:/mnt/host -v /var/lib/cosmos:/config azukaar/cosmos-server:latest

Если настроено доменное имя, то можно сразу получить сертификат от Let's Encrypt, а все устанавливаемые службы будут запускаться на поддоменах. Если же сделать установку без HTTPS по IP адресу сервера, то сервисы будут подниматься на отдельных TCP портах. Я и так, и так попробовал.

Аналоги Cosmos:

◽️CasaOS
◽️Runtipi

Мне лично CasaOS больше всего понравилась. Она более целостно смотрится, магазин приложений больше, как и в целом сообщество. Но Cosmos более функциональна в базе.

⇨ 🌐 Сайт / Исходники / Demo

#docker #linux

Когда разбирался с контейнером openvpn-monitor, про который вчера писал, пришлось немного его подебажить, так как он никак не хотел подключаться к консоли OpenVPN сервера. Писал стандартную ошибку в веб интерфейсе - connection timeout и адрес с портом сервера. Я и так, и сяк адреса и доменные имена пробовал, ни в какую.

Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.

Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:

# mkdir ~/cdebug && cd ~/cdebug
# wget https://github.com/iximiuz/cdebug/releases/download/v0.0.18/cdebug_linux_amd64.tar.gz
# tar xzvf cdebug_linux_amd64.tar.gz

Подключаемся к нашему контейнеру:

# ./cdebug exec -it openvpn-monitor

Оказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.

Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.

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

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

#docker #devops

У меня на канале выходит много заметок с использованием Docker. Хочу высказать своё мнение по поводу его использования. Где-то считаю его уместным, а где-то не очень. Расскажу, как к этому отношусь.

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

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

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

# apt install zabbix-server-mysql
# apt update zabbix-server-mysql

И через Docker:

# docker run --name zabbix-server-mysql -e DB_SERVER_HOST="some-mysql-server" -e MYSQL_USER="some-user" -e MYSQL_PASSWORD="some-password" --init -d zabbix/zabbix-server-mysql:tag

Зачем тут лишняя сущность в виде Docker? Он будет иметь смысл для каких-то тестовых сборок из набора контейнеров, чтобы быстро запускать в разных средах, что-то тестировать, удалять и т.д. Тогда да, можно собрать compose и использовать. Но если нужно будет поставить в прод, то я поставлю из пакетов. Мне так проще и удобнее в эксплуатации.

То же самое относится к Nginx, Angie, Mysql, Php-fpm, Prometheus и т.д. То, что по сути состоит из пакета или бинарника и файла конфигурации к нему не вижу смысла запускать в постоянную эксплуатацию в контейнере. Если у разработчиков есть собранные пакеты, то буду использовать их.

Другое дело более сложный в плане установки софт, для которого пакетов нет. Тогда вручную его собирать, устанавливать, обновлять и поддерживать может быть очень хлопотно. Наглядные примеры, с которыми сталкивался сам - Onlyoffice, Webpagetest. У первого хоть и есть пакеты, но с ними много проблем с зависимостями. Часто нельзя обновиться без ошибок. У второго вообще пакетов нет, его ставить вручную – пуд соли съесть. Причём я ставил, вопрос решаемый, но очень трудоёмкий. Не хочется этим заниматься.

❗️Отдельно выделю софт, который может быть полностью сконфигурирован через переменные окружения при запуске контейнера и не требует подключения файлов конфигурации. Тут без вопросов, запустить в одну команду с ключами проще, чем ставить и отдельно готовить файл конфигурации. Пример - Traefik. У него доступно динамическое управление конфигурацией через переменные. Это удобно.

☝️ Подвожу итог. Всё, что не касается микросервисов, я запускаю в Docker только если установка из пакетов невозможна, либо слишком трудоёмка. Продукты, для которых у разработчиков есть репозитории под Debian, будут установлены из репозиториев. Речь идёт именно о промышленной эксплуатации, а не тестовых запусках.

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

А вы что думаете по этому поводу? Знаю популярное мнение, что абсолютно всё запускается в Docker из-за стандартизации и единообразия. Как по мне, это сомнительный аргумент, так как единая система и общий репозиторий к ней это такая же стандартизация.

#docker #мнение

Иногда перед запуском контейнеров в Docker Compose хочется выполнить какой-нибудь скрипт или просто набор команд. У данной задачи может быть много различных решений. Предлагаю одно из них, когда перед запуском основных контейнеров запускается какой-то малюсенький c оболочкой, например, sh.

С помощью такого трюка можно запустить какие-то миграции для БД или залить туда какой-то дамп с данными или схемой, сгенерировать какой-нибудь конфиг, создать нужные директории или просто что-то записать, если по какой-то причине вам это надо сделать именно там (куда же без костылей). Для того, чтобы не тащить внешние скрипты, выполним всё прямо в 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

Для тех, кто ещё не слышал или не знает, расскажу новости про ограничения на загрузку образов из Docker Hub. Вышла какая-то непонятная история, поэтому решил разобраться. Компания Docker анонсировала внедрение новых лимитов на загрузку образов из их хранилища, причём довольно суровых. Обещали только 10 загрузок в час для неаутентифицированных пользователей. То есть сделали в час 10 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

У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:

⇨ Проверка безопасности 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/log

Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.

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

⇨ 🌐 Сайт / Исходники

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

#docker #devops #cicd #security