Современная веб разработка и частично эксплуатация плотно завязаны на 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
👍91👎5