Современная веб разработка и частично эксплуатация плотно завязаны на 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
Расскажу про одну интересную утилиту, которая поможет в строительстве своих велосипедов и костылей как на одиночных серверах, так и в пайплайнах. Речь пойдёт про сервер для вебхуков, который так и называется - webhook. С его помощью можно инициировать запуск локальных команд или скриптов через HTTP запросы.
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
Пишем простенький скрипт
Пишем конфиг в формате yaml для webhook в файл
Запускаем сервер с этим вебхуком:
По умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#cicd #devops
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
# apt install webhookПишем простенький скрипт
top-proc.sh, который будет записывать в текстовый файл отсортированный по нагрузке список процессов в системе:#!/usr/bin/env bash/usr/bin/mkdir -p /var/log/proclog/usr/bin/ps aux --sort=-pcpu,+pmem > /var/log/proclog/ps-$(date +%F_%H%M%S)Пишем конфиг в формате yaml для webhook в файл
hooks.json:- id: proclog-webhook execute-command: "/var/webhooks/top-proc.sh" command-working-directory: "/var/webhooks/"Запускаем сервер с этим вебхуком:
# /usr/bin/webhook -hooks /var/webhooks/hooks.json -verboseПо умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
/var/webhooks/top-proc.sh, который создаёт логи в директории /var/log/proclog. Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#cicd #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍121👎3