Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.
Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:
Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:
Вспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.
Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:
Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:
Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:
Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:
У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.
#cis #docker #devops
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.
Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:
# git clone https://github.com/docker/docker-bench-security.git# cd docker-bench-security# sh docker-bench-security.shВот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:
[WARN] 1.1.1 - Ensure a separate partition for containers has been created[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge[WARN] 2.13 - Ensure centralized and remote logging is configured[WARN] 4.5 - Ensure Content trust for Docker is EnabledВспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.
Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:
# docker-compose run --rm docker-bench-securityПроверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:
# sh docker-bench-security.sh -c container_images,container_runtime Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:
# docker image pull nginx# sh docker-bench-security.sh -i nginx -c container_imagesНапомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:
# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2# sh docker-bench-security.sh -i dockle-test -c container_imagesУ Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.
#cis #docker #devops
8👍60👎2
Упустил момент с тем, что компания Gitlab ограничила доступ к своему репозиторию gitlab-ee. Не видел новостей на этот счёт. Но при этом остался доступ к репозиторию gitlab-сe. Поясню различия между этими версиями и репозиториями.
Gitlab позволяет развернуть свой продукт в так называемом режиме self-managed. То есть вы его берёте и ставите на свой сервер. Исходный код сервера открыт. У компании есть репозитории с пакетами под все популярные системы.
При этом существуют две редакции Gitlab:
▪️Community Edition
▪️Enterprise Edition
Редакция Community полностью с открытым исходным кодом. Можно брать и пользоваться. Enterprise построена на базе кода Community, но к ней добавлены возможности на основе закрытого кода. Эта дополнительная функциональность будет работать только если вы заплатите, либо запустите ознакомительную версию.
Таким образом, если для вас недопустимо разворачивать продукт, где присутствует код под проприетарной лицензией, то берите Community Edition. Переход с этой версии на платную невозможен. Нужно будет делать миграцию. Если же вам всё равно на наличие закрытого кода, то можно ставить Enterprise Edition. Без оплаты эта редакция будет работать так же, как и Community. Но если вы захотите воспользоваться платными дополнениями, то просто заплатите и будете пользоваться.
Для простоты и удобства Gitlab рекомендует всем ставить Enterprise Edition. Её пакеты лежат в репозитории https://packages.gitlab.com/gitlab/gitlab-ee. Доступ туда IP адресам из РФ закрыт. Потеря невелика, так как что-то купить всё равно не получится. А доступ к репозиторию с Community Edition открыт - https://packages.gitlab.com/gitlab/gitlab-ce. Оттуда можно выполнить установку. Выглядит это вот так:
Не забудьте указать свой url. Для теста можно использовать IP адрес, примерно так: http://10.20.1.36. Учётка для входа будет root, пароль в файле
Подобным образом вы без проблем можете развернуть бесплатную версию gitlab с открытым исходным кодом на своём сервере. Ни регистраций, ни чего-то ещё не требуется. Можно свободно пользоваться.
#gitlab #devops
Gitlab позволяет развернуть свой продукт в так называемом режиме self-managed. То есть вы его берёте и ставите на свой сервер. Исходный код сервера открыт. У компании есть репозитории с пакетами под все популярные системы.
При этом существуют две редакции Gitlab:
▪️Community Edition
▪️Enterprise Edition
Редакция Community полностью с открытым исходным кодом. Можно брать и пользоваться. Enterprise построена на базе кода Community, но к ней добавлены возможности на основе закрытого кода. Эта дополнительная функциональность будет работать только если вы заплатите, либо запустите ознакомительную версию.
Таким образом, если для вас недопустимо разворачивать продукт, где присутствует код под проприетарной лицензией, то берите Community Edition. Переход с этой версии на платную невозможен. Нужно будет делать миграцию. Если же вам всё равно на наличие закрытого кода, то можно ставить Enterprise Edition. Без оплаты эта редакция будет работать так же, как и Community. Но если вы захотите воспользоваться платными дополнениями, то просто заплатите и будете пользоваться.
Для простоты и удобства Gitlab рекомендует всем ставить Enterprise Edition. Её пакеты лежат в репозитории https://packages.gitlab.com/gitlab/gitlab-ee. Доступ туда IP адресам из РФ закрыт. Потеря невелика, так как что-то купить всё равно не получится. А доступ к репозиторию с Community Edition открыт - https://packages.gitlab.com/gitlab/gitlab-ce. Оттуда можно выполнить установку. Выглядит это вот так:
# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash# EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ceНе забудьте указать свой url. Для теста можно использовать IP адрес, примерно так: http://10.20.1.36. Учётка для входа будет root, пароль в файле
/etc/gitlab/initial_root_password.Подобным образом вы без проблем можете развернуть бесплатную версию gitlab с открытым исходным кодом на своём сервере. Ни регистраций, ни чего-то ещё не требуется. Можно свободно пользоваться.
#gitlab #devops
👍65👎7
⇨ GitLab CI/CD - Главные Основы создания CI/CD Pipeline
Хорошее обзорное видео с примерами построения CI/CD на базе Gitlab. Автор наглядно на конкретном примере всё показывает и рассказывает. Кто не знаком с этим каналом, рекомендую. Там в прошлом есть обучающие курсы из серии видео для базовых вещей в DevOps.
⇨ Restic - решение для твоих бекапов
Пример использования популярного решения для бэкапов - Restic. Это быстрый, функциональный инструмент для бэкапов, состоящий из одного бинарника на Go. Кто не знаком, рекомендую посмотреть на него. Там снэпшоты, дедупликация, проверка целостности, куча бэкендов в поддержке и т.д.
⇨ Разбор падения Reddit – как крупнейший форум оказался в ауте!
Автор рассказал про одно из крупных падений Reddit из-за неудачного обновления Kubernetes. А отката неудачного обновления там не предусмотрено.
⇨ Docker Container Monitoring Dashboards both Open Source and Netdata!
Автор рассмотрел наиболее популярные инструменты для мониторинга контейнеров: cAdviser, Prometheus, Grafana, Netdata. Нравится этот канал, хорошее качество видео.
⇨ Simple HTTPs for Docker! // Traefik Tutorial (updated)
Большое обзорное виде про Traefik. Не знаю, чем его так любят блогеры, но про этот обратный прокси для веб сайтов больше всего роликов. Этот, получается, самый свежий будет. Тут всё: установка, базовая настройка, динамическая конфигурация, метки для Docker, TLS сертификаты и т.д.
⇨ How To Monitor Windows Services with ZABBIX ( Correct Way )
Любой, кто мониторил Windows хосты с помощью Zabbix знает, как там неудобно реализован мониторинг служб. Будет масса бесполезных уведомлений. Лично я всегда отключаю автообнаружение служб. А если надо что-то мониторить, настраиваю отдельно вручную. Автор показывает, как можно не отключая мониторинг всех служб, сделать исключение для некоторых из них. По мне, так сделано очень неудобно. Но пока других простых решений нет.
⇨ САМОПОДПИСАННЫЕ SSL СЕРТИФИКАТЫ ДЛЯ ДОМА.
Наглядное видео, как создать и использовать самоподписные сертификаты. В видео кратко рассмотрена теория по TLS, что содержат сертификаты, что такое цепочки доверия и т.д. Сертификаты автор выпускал с помощью XCA - локального приложения для управления сертификатами. Краткая инструкция по этой теме была у меня на канале. Рекомендую для быстрого копипаста в консоли.
⇨ Настройки WAF на Cloudflare для домашнего сервера
Обзор WAF на бесплатном тарифе от Cloudflare. Он, на удивление, не вводил никаких санкций и по-прежнему работает. Не знаю, насколько оправданно им сейчас пользоваться. Я буквально пару недель назад последнего пользователя отключил от CF. Просто на всякий случай. Никаких проблем в его работе не было. Хорошее бесплатное решение, чтобы скрыть реальные адреса своего проекта.
⇨ ASUS NUC 14 Pro Review // Best Intel NUC for Home Lab?
Обзор небольших minipc. Лично мне всегда нравились нюки за их компактный размер и хорошую производительность. Мечтаю себе купить 3 таких штуки для домашнего кластера, но всё время откладываю, потому что дома полно старого железа. Большой нужды в них нет, поэтому жалко денег. Их не назвать бюджетными устройствами, так как стоят больше аналогов. На авито много предложений за 70к+ р.
⇨ Нейросеть + 1С. RAG системы для бизнеса
Пример того, как может работать нейросеть в связке с БД интернет-магазина, чтобы отвечать на вопросы пользователей на основе актуальной информации. Смотрю подобные ролики просто из любопытства, чтобы иметь представление, как всё это работает.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
GitLab CI/CD - Главные Основы создания CI/CD Pipeline
#devops #gitlab #девопс
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
👍80👎2
Вчера в комментариях посоветовали удобную программу для просмотра серверных логов браузером. Сразу попробовал - очень понравилась утилита. Речь пойдёт про logdy. Это одиночный бинарник на Go. Установить можно так:
Скрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
Вообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
Далее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет http://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
Отправляем в него логи:
В веб интерфейс прилетит этот лог. В него можно stdin отправить:
У logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
# curl https://logdy.dev/install.sh | shСкрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
# tail -f /var/log/syslog | logdy --ui-ip=0.0.0.0По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
# logdy --ui-ip=0.0.0.0 follow /var/log/syslogВообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
# node app.js | logdyДалее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет http://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
# docker logs 761965fa13b2 --follow | logdy --ui-ip=0.0.0.0И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
# logdy --ui-ip=0.0.0.0 socket 8123 8124# docker logs d20339949095 --follow | logdy forward 8123# docker logs 761965fa13b2 --follow | logdy forward 8124Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
# logdy --ui-ip=0.0.0.0 --api-key=secrettokenОтправляем в него логи:
curl --location --request POST 'http://1.2.3.4:8080/api/log' \--header 'Authorization: Bearer secrettoken' \--header 'Content-Type: application/json' \--data '{"logs": [{"log": "this is a log message as a string" }],"source":"machine identifier"}'В веб интерфейс прилетит этот лог. В него можно stdin отправить:
# logdy stdinУ logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
2👍188👎4
Неоднократно видел в комментариях и обсуждениях Ceph упоминание о VitaStor. Автор называет её быстрой и простой распределённой программной СХД. Архитектурно она сильно похожа на Ceph, так что если кто-то с ней знаком, попробовать Vitastor не составит труда. Я где-то за пару часов разобрался, настроил тестовый стенд и проверил в работе.
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
1️⃣ Настраиваем мониторы на основе etcd. Аналог MON в Ceph.
2️⃣ Настраиваем OSD (Object Storage Device). В Ceph так же называется.
3️⃣ Создаём пул.
4️⃣ Создаём образ диска.
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
/dev/vda. Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍102👎2
На днях нужно было вытащить один файл из Docker образа. Не из контейнера, а именно образа, так как не хотелось запускать контейнер. Никак не мог сообразить, как это сделать. Помню, что уже когда-то ломал над этим голову, и там почему-то нет простого решения. По крайней мере я его не знаю.
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
Теперь можно забрать нужный файл:
Либо выгрузить всё содержимое образа:
Заодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
Увидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
Теперь можно просматривать образы так:
Удобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
# docker pull nginx:latest# docker create --name nginx nginx:latestТеперь можно забрать нужный файл:
# docker cp nginx:/docker-entrypoint.d/30-tune-worker-processes.sh ~/Либо выгрузить всё содержимое образа:
# docker export nginx -o ~/nginx-docker.tar.gzЗаодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
# docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive nginx:latestУвидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"Теперь можно просматривать образы так:
# dive nginx:latestУдобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
2👍208👎4
На прошлой неделе посмотрел видео про современную и функциональную open source платформу для управления веб приложениями, запускаемыми в Docker контейнерах. Речь пойдёт про Coolify. Вот видео, о котором я говорю:
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
2👍75👎1
⇨ GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS Lambda
⇨ GitLab - Как работать используя TOKEN
Продолжение начатой ранее автором темы про Gitlab и CI/CD на его основе. Если самостоятельно изучаете эту тему, то видео будут отличным подспорьем. Автор хорошо объясняет, показывает на примерах.
⇨ KEYNOTE by Alexei Vladishev / Zabbix Summit 2024
У Zabbix недавно прошёл масштабный саммит. Они выложили на своём канале кучу видео оттуда. Посмотрите, может вас заинтересуют какие-то темы. Мне очень хочется некоторые видео посмотреть и разобрать, но не знаю, найду ли для этого время. Хотя бы посмотреть надо для начала. Там и мониторинг MariaDB, и новый веб мониторинг, и самописные проверки по tcp, и мониторинг DNS, и тюнинг производительности, и т.д. В общем, интересно.
⇨ Proxmox Network. Обзор и настройка. Bridge, Bond, VLAN.
Очень подробное наглядное видео с картинками и схемами по организации виртуальной сети в Proxmox. Рассмотрены не только тривиальные случаи. Например, автор рассказал, как настроить две изолированные подсети виртуалок, в которой каждая подсеть выходит в инет через свой роутер. Там же он создаёт и тестирует Bond - объединение сетевых адаптеров для отказоустойчивости.
⇨ Настройка мониторинга c помощью Grafana InfluxDB Prometheus Telegraf
Большое видео на тему установки и настройки указанного стэка. Я похожий стэк тестировал и писал об этом: TICK Stack. Из своих изысканий не особо понял, зачем нужно использовать Telegraf и InfluxDB. Из плюсов только то, что это и метрики, и логи в одном месте. Но сейчас есть Loki для этого, и я бы отдал предпочтение ему.
⇨ Какой софт у меня в моей homelab в 2024
Интересно было посмотреть, как всё организовано у автора. У него один общий сервер под Proxmox и там виртуалки с контейнерами: opnsense, truenas, pbs, pi-hole, nut, homapage, plex, sonarr, nextcloud и т.д. Он рассказал не только про софт, но и про организацию сети. Почти по всему софту у него есть отдельные ролики.
⇨ Best Docker Update Image Tools for Automating Container Updates
Обзор софта, который умеет автоматически обновлять образы контейнеров: Watchtower, Shepherd, Portainer, CI/CD pipelines.
⇨ Как быстро определить версию дистрибутива Linux и эффективно управлять пакетами?
Небольшое справочное видео по теме. Заголовок немного некорректно подобран, так как в видео в основном про пакеты речь идёт, а про версию ОС в самом начале. Автор предлагает смотреть так:
cat /etc/*release. Я лично привык использовать hostnamectl. Так не только ОС видно, но тип виртуализации и некоторую другую информацию. ⇨ Reacting to your CURSED Homelab Setups
Длинное развлекательное видео, где автор показывает и обсуждает домашние лаборатории своих пользователей. Ранее он просил прислать картинки и описание своих домашних лабораторий, а теперь обработал всё это и оформил в видео.
⇨ How To Rebrand Zabbix 7.0 ( Replace Logos )
Небольшое обзорное видео на тему брендирования своего сервера Zabbix с заменой логотипа.
⇨ MiniTool ShadowMaker - простая и бесплатная программа для бекапа и восстановления системы
Рекламный обзор небольшой бесплатной версии программы для бэкапа ОС Windows. У программы, соответственно, есть и коммерческая версия. На вид вроде ничего особенного по сравнению с другими подобными программами. Посмотрите, может вам приглянется.
В подписках было много видео с рекламой различных продуктов, типа того, что выше. Понимал об этом по UTM меткам в ссылках с описанием. При этом сами блогеры явно не говорят, что публикуют оплаченный рекламный обзор. Это как-то некрасиво. Привык уже к нашему закону о рекламе, где блогеров обязали маркировать и явно указывать, что они публикуют рекламу. Для конечного пользователя это большой плюс.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS Lambda
#devops #gitlab #девопс
https://gitlab.com/adv4000/myproject2
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
https://gitlab.com/adv4000/myproject2
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
3👍80👎4
Если у вас используется несколько систем мониторинга, сразу возникает задача по централизованному управлению оповещениями. А в мониторинге это самое главное. Я развернул и потестировал open source платформу keephq для объединения и обработки оповещений из различных систем, которые их генерируют. Например, это могут быть такие популярные системы, как:
- Zabbix
- Prometheus/VictoriaMetrics
- Netdata
- UptimeKuma
- Checkmk
- Elastic/Graylog
И многие другие известные системы. Сразу по шагам покажу, как keephq настраивается, чтобы было понятно, что она из себя представляет. Я потестировал её в связке с Zabbix.
1️⃣ Установка очень простая:
В docker-compose.common.yml поменял переменные
Так мы запустили службу с сохранением состояния в базе sqlite3 в директории state.
2️⃣ Зашёл в веб интерфейс по IP адресу на порт 3000. Сразу добавил провайдера Zabbix. Для этого нужен его URL, и API токен для доступа к мониторингу. Предварительно создал его.
3️⃣ Keephq подгрузил активные триггеры из Zabbix. Сразу же можно сделать и сохранить отдельное представление, для отображения триггеров только с этого провайдера. Для триггеров можно настроить какие-то действия, которые можно выбирать для ручного запуска. Например, создать тикет в Jira, Redmine, Gitlab и т.д.
4️⃣ В разделе Correlations создал новое правило, в котором при появлении нового триггера создаётся инцидент. Он, когда сработает, будет виден в разделе Incidents. В инциденты могут быть объединены триггеры с различными признаками.
5️⃣ На основе инцидента в ручном или автоматическом режиме могут выполняться различные действия. Они описываются в разделе Workflows. Самый простой пример действия - добавление в качестве провайдера какой-то сервер с доступом к нему по SSH. И в качестве реакции на инцидент на этом сервере можно запускать какую-то команду или скрипт.
Описал кратко принцип работы keephq. В общем случае эта система умеет аккумулировать в себе множество событий и выдавать на них какие-то реакции со своими действиями или оповещениями.
Например, у вас случился какой-то шторм из алертов из-за того, что поленились настроить в Zabbix зависимость триггеров. Упал какой-то удалённый филиал и все хосты оттуда навалили кучу триггеров. Вы можете в keephq объединить все эти триггеры по какому-то признаку, сделать на их основе инцидент, отправить только одно уведомление ответственному лицу, а инцидент закрыть после закрытия какой-то конкретного триггера в Zabbix, который, к примеру, отвечает за доступность шлюза в удалённом филиале.
Описал простой пример, который связан только с одним сервером Zabbix. Соответственно, если у вас много различных серверов, которые генерируют события, их можно объединять в keephq. Отключать отправку уведомлений в самих сервисах и управлять ими в keephq.
Надеюсь, понятно объяснил. По сути это аналог Grafana OnCall. А сооснователь keephq - Матвей Кукуй, в прошлом — Engineering Director в Grafana Labs, который OnCall и создавал. А до этого он же ex-CEO Amixr.IO, который купила Grafana. Вот интервью с ним.
Keephq монетизируется и развивается за счёт облачной версии. Open Source версия для собственной установки бесплатна. Каких-то ограничений не нашёл.
⇨ 🌐 Сайт / Исходники
#devops #мониторинг
- Zabbix
- Prometheus/VictoriaMetrics
- Netdata
- UptimeKuma
- Checkmk
- Elastic/Graylog
И многие другие известные системы. Сразу по шагам покажу, как keephq настраивается, чтобы было понятно, что она из себя представляет. Я потестировал её в связке с Zabbix.
1️⃣ Установка очень простая:
# git clone https://github.com/keephq/keep.git && cd keep# mkdir -p state && chown -R 999:999 stateВ docker-compose.common.yml поменял переменные
NEXTAUTH_URL и NEXT_PUBLIC_API_URL на свои IP и запустил:# docker compose up -dТак мы запустили службу с сохранением состояния в базе sqlite3 в директории state.
2️⃣ Зашёл в веб интерфейс по IP адресу на порт 3000. Сразу добавил провайдера Zabbix. Для этого нужен его URL, и API токен для доступа к мониторингу. Предварительно создал его.
3️⃣ Keephq подгрузил активные триггеры из Zabbix. Сразу же можно сделать и сохранить отдельное представление, для отображения триггеров только с этого провайдера. Для триггеров можно настроить какие-то действия, которые можно выбирать для ручного запуска. Например, создать тикет в Jira, Redmine, Gitlab и т.д.
4️⃣ В разделе Correlations создал новое правило, в котором при появлении нового триггера создаётся инцидент. Он, когда сработает, будет виден в разделе Incidents. В инциденты могут быть объединены триггеры с различными признаками.
5️⃣ На основе инцидента в ручном или автоматическом режиме могут выполняться различные действия. Они описываются в разделе Workflows. Самый простой пример действия - добавление в качестве провайдера какой-то сервер с доступом к нему по SSH. И в качестве реакции на инцидент на этом сервере можно запускать какую-то команду или скрипт.
Описал кратко принцип работы keephq. В общем случае эта система умеет аккумулировать в себе множество событий и выдавать на них какие-то реакции со своими действиями или оповещениями.
Например, у вас случился какой-то шторм из алертов из-за того, что поленились настроить в Zabbix зависимость триггеров. Упал какой-то удалённый филиал и все хосты оттуда навалили кучу триггеров. Вы можете в keephq объединить все эти триггеры по какому-то признаку, сделать на их основе инцидент, отправить только одно уведомление ответственному лицу, а инцидент закрыть после закрытия какой-то конкретного триггера в Zabbix, который, к примеру, отвечает за доступность шлюза в удалённом филиале.
Описал простой пример, который связан только с одним сервером Zabbix. Соответственно, если у вас много различных серверов, которые генерируют события, их можно объединять в keephq. Отключать отправку уведомлений в самих сервисах и управлять ими в keephq.
Надеюсь, понятно объяснил. По сути это аналог Grafana OnCall. А сооснователь keephq - Матвей Кукуй, в прошлом — Engineering Director в Grafana Labs, который OnCall и создавал. А до этого он же ex-CEO Amixr.IO, который купила Grafana. Вот интервью с ним.
Keephq монетизируется и развивается за счёт облачной версии. Open Source версия для собственной установки бесплатна. Каких-то ограничений не нашёл.
⇨ 🌐 Сайт / Исходники
#devops #мониторинг
3👍114👎4
В комментариях один подписчик поделился open source проектом в виде сервера для управления и использования скриптов - script-server. Штука вроде интересная. Я развернул и начал тестировать. Но всё как-то неинтуитивно и неудобно. В процессе я понял, что уже видел на эту тему готовые продукты, но более функциональные и проработанные. В итоге бросил script-server, вспомнил аналог, которым я когда-то давно пользовался - Rundeck. Решил написать про него.
Кратко скажу, что такое Rundeck. Это веб интерфейс для управления своими костылями в виде различных скриптов. Их можно запускать как вручную, так и по расписанию, заменяя локальные cron на отдельных узлах. Вы добавляете в систему свои сервера, пишите скрипты и связываете эти скрипты с серверами. Это альтернатива крупным CI/CD системам для тех, кому они не нужны, но хочется как-то упорядочить управление своими костылями в небольшой инфраструктуре.
📌 Основные возможности Rundeck:
🔹Запуск составных заданий, которые могут состоять из локальных команд и скриптов, скриптов из централизованного хранилища, HTTP запросов, Ansible плейбуков, задач на копирование файлов.
🔹Задания могут запускаться вручную через веб интерфейс или по расписанию.
🔹Выполнение заданий логируется, после выполнения могут отправляться уведомления.
🔹Функциональность системы расширяется плагинами и интеграциями. Например, можно запускать задачи Rundeck после билдов в Jenkins, или добавлять результат работы команды в комментарии в задачам в Jira. Список плагинов большой.
🔹Различные планы исполнения массовых заданий: последовательные, параллельные сразу на всех хостах, остановка или продолжение исполнения в случае неудач и т.д.
🔹Управление правами доступа в проектах на основе групп и ролей.
🔹На Linux сервера ходит по SSH, на виндовые через WinRM.
Продукт уже зрелый и развитый. Настолько развитый, что загрузку Community версии спрятали за форму регистрации. Я знаю, что есть Docker версия, поэтому просто сходил в hub, посмотрел номер свежего релиза и запустил его:
Можно идти по IP адресу на порт 4440, учётка по умолчанию - admin / admin. Интерфейс и логика работы интуитивно понятны. Создаём job с различными параметрами, добавляем хосты (делается в настройках проекта), настраиваем запуск заданий на хостах. Есть несколько механизмов по автоматическому добавлению хостов. Rundesk их может брать из:
◽️Ansible inventory
◽️Директории, где лежат подготовленные файлы с описанием хостов
◽️Единого конфига, где описаны все хосты
Соответственно, хосты он подгружает из заранее подготовленного места. Пример файла с описанием нод есть в документации. Там всё просто. Надо заполнить основные поля - имя, адрес, архитектура, система, тэги и т.д. То ли я затупил, то ли такую возможность убрали из бесплатной версии. Не понял, как одну ноду вручную добавить в веб интерфейс. Каждый раз редактировать файл неудобно.
В качестве примеров можете посмотреть готовые задания из репозитория. Они в формате yml. Можете скачать и импортировать к себе.
Я пару часов поразбирался с этой системой, в целом, всё получилось, но есть нюансы. Последовательность действий такая:
1️⃣ Добавляем проект.
2️⃣ В свойствах проекта в разделе Default Node Executor указываем SSH Authentication privateKey.
3️⃣ Идём в Key Storage, добавляем ключ. Сохраняем его Storage path.
4️⃣ Готовим файл с нодами
5️⃣ Копируем этот файл в контейнер:
6️⃣ В разделе Edit Nodes добавляем Node Source в виде File. Путь указываем
Всё, теперь можно создавать задания и выполнять их на нодах.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#script #devops
Кратко скажу, что такое Rundeck. Это веб интерфейс для управления своими костылями в виде различных скриптов. Их можно запускать как вручную, так и по расписанию, заменяя локальные cron на отдельных узлах. Вы добавляете в систему свои сервера, пишите скрипты и связываете эти скрипты с серверами. Это альтернатива крупным CI/CD системам для тех, кому они не нужны, но хочется как-то упорядочить управление своими костылями в небольшой инфраструктуре.
📌 Основные возможности Rundeck:
🔹Запуск составных заданий, которые могут состоять из локальных команд и скриптов, скриптов из централизованного хранилища, HTTP запросов, Ansible плейбуков, задач на копирование файлов.
🔹Задания могут запускаться вручную через веб интерфейс или по расписанию.
🔹Выполнение заданий логируется, после выполнения могут отправляться уведомления.
🔹Функциональность системы расширяется плагинами и интеграциями. Например, можно запускать задачи Rundeck после билдов в Jenkins, или добавлять результат работы команды в комментарии в задачам в Jira. Список плагинов большой.
🔹Различные планы исполнения массовых заданий: последовательные, параллельные сразу на всех хостах, остановка или продолжение исполнения в случае неудач и т.д.
🔹Управление правами доступа в проектах на основе групп и ролей.
🔹На Linux сервера ходит по SSH, на виндовые через WinRM.
Продукт уже зрелый и развитый. Настолько развитый, что загрузку Community версии спрятали за форму регистрации. Я знаю, что есть Docker версия, поэтому просто сходил в hub, посмотрел номер свежего релиза и запустил его:
# docker run --name rundeck -e RUNDECK_GRAILS_URL=http://10.20.1.36:4440 -p 4440:4440 -v data:/home/rundeck/server/data rundeck/rundeck:5.7.0Можно идти по IP адресу на порт 4440, учётка по умолчанию - admin / admin. Интерфейс и логика работы интуитивно понятны. Создаём job с различными параметрами, добавляем хосты (делается в настройках проекта), настраиваем запуск заданий на хостах. Есть несколько механизмов по автоматическому добавлению хостов. Rundesk их может брать из:
◽️Ansible inventory
◽️Директории, где лежат подготовленные файлы с описанием хостов
◽️Единого конфига, где описаны все хосты
Соответственно, хосты он подгружает из заранее подготовленного места. Пример файла с описанием нод есть в документации. Там всё просто. Надо заполнить основные поля - имя, адрес, архитектура, система, тэги и т.д. То ли я затупил, то ли такую возможность убрали из бесплатной версии. Не понял, как одну ноду вручную добавить в веб интерфейс. Каждый раз редактировать файл неудобно.
В качестве примеров можете посмотреть готовые задания из репозитория. Они в формате yml. Можете скачать и импортировать к себе.
Я пару часов поразбирался с этой системой, в целом, всё получилось, но есть нюансы. Последовательность действий такая:
resources.yml. Описываем там ноды, в параметре ssh-key-storage-path указываем Storage path из предыдущего пункта.# docker cp ~/resources.yml rundeck:/home/rundeck/resources.yml/home/rundeck/resources.yml. Сохраняем настройку. Всё, теперь можно создавать задания и выполнять их на нодах.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#script #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍104👎6
Популярный open source продукт, который можно развернуть на своём оборудовании, Gitlab требует для своей работы приличное количество ресурсов. Для того, чтобы он в установке по умолчанию работал бодрячком лучше всего начать с 4 CPU и 8 GB оперативной памяти. Можно выделить 4 GB, но будет заметно тормозить, иногда 500-е ошибки выдавать.
Для того, чтобы иметь возможность использовать Gitlab для единоличного использования, либо очень небольшого коллектива, многие из стандартных компонентов и настроек программного комплекса можно безболезненно отключить. В документации есть отдельная статья на этот счёт:
⇨ Running GitLab in a memory-constrained environment (Запуск GitLab в среде с ограниченным объемом памяти)
Следуя этим рекомендация, можно заставить работать систему с использованием всего 2 GB оперативной памяти. Если вы запускаете его для себя на арендованном железе, то можно получить существенную экономию ресурсов.
Я взял виртуальную машину с 1 CPU и 2 GB памяти и попробовал на ней запустить Gitlab. Что для этого нужно сделать?
1️⃣ Подключаем 1 GB свопа.
Добавляем в
2️⃣ Меняем параметр swappiness:
Добавляем в
3️⃣ Устанавливаем Gitlab.
4️⃣ Отключаем службу puma, которая помогает обрабатывает конкурентные запросы. Без большой нагрузки можно обойтись без неё. В
5️⃣ Уменьшаем число фоновых процессов Sidekiq:
6️⃣ Оптимизируем Gitaly. Туда же в конфиг добавляем:
❗️Обращаю ваше внимание, что я убрал из этого раздела настройки, касающиеся cgroups. В инструкции судя по всему какая-то ошибка. Если их оставить, то сокет gitaly не поднимается. А в интерфейсе при создании каких-либо сущностей, например, нового проекта, вылетает 502 ошибка. И это не зависит от выделенных ресурсов.
7️⃣ Отключаем мониторинг:
8️⃣ Уменьшаем потребление памяти процессам GitLab:
9️⃣ Перезапускаем Gitlab:
🔟 Идём в веб интерфейс и отключаем в настройках мониторинга метрики Prometheus: Admin Area ⇨ Settings ⇨ Metrics and profiling ⇨ Metrics - Prometheus ⇨ отключаем Enable Prometheus Metrics.
После перезапуска Gitlab будет очень долго подниматься. Но в итоге заработает. Смотрим потребление памяти и проверяем, как всё работает:
Более подробно всё это описано по ссылке в статье из начала заметки. Для комфортной работы лучше всё же добавить до 2CPU и 3GB памяти. Тогда всё это будет бодро работать с предложенными параметрами. Если этого не сделать, то иногда будете видеть 500-е ошибки.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#gitlab #devops #cicd
Для того, чтобы иметь возможность использовать Gitlab для единоличного использования, либо очень небольшого коллектива, многие из стандартных компонентов и настроек программного комплекса можно безболезненно отключить. В документации есть отдельная статья на этот счёт:
⇨ Running GitLab in a memory-constrained environment (Запуск GitLab в среде с ограниченным объемом памяти)
Следуя этим рекомендация, можно заставить работать систему с использованием всего 2 GB оперативной памяти. Если вы запускаете его для себя на арендованном железе, то можно получить существенную экономию ресурсов.
Я взял виртуальную машину с 1 CPU и 2 GB памяти и попробовал на ней запустить Gitlab. Что для этого нужно сделать?
1️⃣ Подключаем 1 GB свопа.
# dd if=/dev/zero of=/swap bs=1024 count=1000000# mkswap /swap# chmod 0600 /swap# swapon /swapДобавляем в
/etc/fstab:/swap swap swap defaults 0 02️⃣ Меняем параметр swappiness:
# sysctl vm.swappiness=10Добавляем в
/etc/sysctl.conf:vm.swappiness=103️⃣ Устанавливаем Gitlab.
# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash# EXTERNAL_URL="http://10.20.1.36" apt-get install gitlab-ce4️⃣ Отключаем службу puma, которая помогает обрабатывает конкурентные запросы. Без большой нагрузки можно обойтись без неё. В
/etc/gitlab/gitlab.rb добавляем:puma['worker_processes'] = 05️⃣ Уменьшаем число фоновых процессов Sidekiq:
sidekiq['concurrency'] = 106️⃣ Оптимизируем Gitaly. Туда же в конфиг добавляем:
gitaly['configuration'] = { concurrency: [ { 'rpc' => "/gitaly.SmartHTTPService/PostReceivePack", 'max_per_repo' => 3, }, { 'rpc' => "/gitaly.SSHService/SSHUploadPack", 'max_per_repo' => 3, }, ],}gitaly['env'] = { 'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'}❗️Обращаю ваше внимание, что я убрал из этого раздела настройки, касающиеся cgroups. В инструкции судя по всему какая-то ошибка. Если их оставить, то сокет gitaly не поднимается. А в интерфейсе при создании каких-либо сущностей, например, нового проекта, вылетает 502 ошибка. И это не зависит от выделенных ресурсов.
7️⃣ Отключаем мониторинг:
prometheus_monitoring['enable'] = false8️⃣ Уменьшаем потребление памяти процессам GitLab:
gitlab_rails['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'}gitaly['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'}9️⃣ Перезапускаем Gitlab:
# gitlab-ctl reconfigure🔟 Идём в веб интерфейс и отключаем в настройках мониторинга метрики Prometheus: Admin Area ⇨ Settings ⇨ Metrics and profiling ⇨ Metrics - Prometheus ⇨ отключаем Enable Prometheus Metrics.
После перезапуска Gitlab будет очень долго подниматься. Но в итоге заработает. Смотрим потребление памяти и проверяем, как всё работает:
# free -hБолее подробно всё это описано по ссылке в статье из начала заметки. Для комфортной работы лучше всё же добавить до 2CPU и 3GB памяти. Тогда всё это будет бодро работать с предложенными параметрами. Если этого не сделать, то иногда будете видеть 500-е ошибки.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#gitlab #devops #cicd
👍140👎5
🔥Путь в DevOps: полное руководство для новичков с НУЛЯ - 2025
Интересный материал от Дениса Астахова. Автор составил свой список технологий и продуктов, которые по его мнению стоит изучать для движения в сторону DevOps. В целом, ничего особенного, но было интересно послушать Дениса. Там и курсы, и книги, и экзамены, и его видео перечислены. Прям самая что ни на есть конкретика. Неплохо было бы это видео в текст перевести.
⇨ Как я проходил собеседование DevOps
Интересная личная информация автора о том, как он искал себе работу. Для себя можно сделать соответствующие выводы о том, как и что лучше рассказывать. Например, тему здоровья поднимать не надо вообще. Везде, где она затрагивалась, автор получил отказы. А вообще, мне не так давно пришла в голову одна простая мысль - ведение публичной деятельности снижает твои шансы получить работу. Не всем захочется получить в коллективе человека, которые если что, может какую-то информацию вольно или невольно вывести в публичную плоскость на широкую аудиторию. Имейте это в виду, кто активно развивает свои публичные ресурсы. Следите за тем, что вы там пишите.
⇨ Настройка Authentik. Часть 1. Теория
Начало цикла по настройке и использованию Authentik. В данном видео только теория.
⇨ I created a Custom Docker Server Dashboard! Download Now!
Автор написал свою панель отображения информации о Docker контейнерах, как дополнение к Portainer или Komodo. Панель выглядит топорно, но может в едином дашборде объединять несколько хостов и выводить столбцы с дополнительной информацией, которой нет в других панелях.
⇨ Tianji: All-in-One Docker Service for Analytics, Monitoring, and More!
Интересная система сбора статистики посещаемости сайта и одновременно простенький мониторинг на базе Uptime Kuma и Umami - Tianji. Надо будет попробовать. Запускается в Docker контейнере. Есть интеграция с aaPanel.
⇨ HomeLab Hardware Tour (Early 2025)
Обзор домашней серверной от известного блогера Techno Tim. Там, конечно, всё дорого-богато. Можно только позавидовать.
⇨ Почему wireguard — самый простой способ настроить vpn
Краткий ликбез на тему WireGuard от Романа Козлова. Сначала не понял, что он делает на канале Слёрм, а потом вспомнил, что он один из авторов курса по сетям там. Это к вопросу о том, в какой школе хорошие курсы. Указанный курс, кстати, бесплатный.
⇨ PDM. Yовый продукт proxmox - Datacenter Manager
Очередной обзор на Proxmox Datacenter Manager. Этот самый информативный из всех, что я видел. Так что если ещё не смотрели, можете глянуть.
⇨ Сравнение Synology DSM и TerraMaster TOS
Сравнение ОС от двух популярных производителей NAS. TerraMaster последнее время очень сильно вкладывается в маркетинг. Видел кучу обзоров и рекламы от блогеров. Судя по всему, хочет подвинуть Synology на рынке домашних и полупрофессиональных NAS.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Путь в DevOps: полное руководство для новичков с НУЛЯ - 2025
#devops #девопс #ityoutubersru
00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование…
00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование…
1👍86👎3
Когда разбирался с контейнером openvpn-monitor, про который вчера писал, пришлось немного его подебажить, так как он никак не хотел подключаться к консоли OpenVPN сервера. Писал стандартную ошибку в веб интерфейсе - connection timeout и адрес с портом сервера. Я и так, и сяк адреса и доменные имена пробовал, ни в какую.
Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.
Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:
Подключаемся к нашему контейнеру:
Оказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.
Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.
С помощью cdebug можно подключаться к подам кубера. В докере можно пробрасывать новые порты из контейнера на хост без перезапуска контейнера. Можно подцепить к контейнеру образ с tshark на борту и собрать трафик изнутри контейнера. Очень простая и удобная программа. Если работаете с контейнерами, рекомендую сохранить и освоить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.
Есть удобный инструмент 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
Telegram
ServerAdmin.ru
При работе с Docker контейнерами часто хочется зайти туда и посмотреть, что происходит. Но не всегда это возможно. В некоторых контейнерах нет вообще ничего - ни оболочки, ни утилит для диагностики.
Для решения этой задачи создана программа cdebug. С её…
Для решения этой задачи создана программа cdebug. С её…
4👍174👎5
Как только поднимается тема контейнеров, неизменно начинается обсуждение производительности. Что туда можно засунуть, что нет и т.д. Особое внимание уделяют СУБД. Когда-то давно я увидел тесты работы форка 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
На прошлой неделе был на конференции Deckhouse Conf. Это не рекламная публикация, у меня её никто не заказывал. Моё посещение было самостоятельным. Публиковал рекламу о событии на канале и сам записался. Ничего о себе особо не указывал, оставил обычную заявку. Мне её подтвердили, так что съездил. Событие было интересное, поэтому решил поделиться с вами некоторыми новыми для себя вещами.
🟢 Конференция в первую очередь была посвящена программному продукту Deckhouse. А точнее экосистеме, которая состоит из множества компонентов. Основные - Kubernetes Platform и Virtualization Platform. Конференция в основном была посвящена Kubernetes и всему, что с ним связано.
Deckhouse Platform представлена в том числе в бесплатной редакции Community Edition с открытым исходным кодом. Развернуть и использовать можно без ограничений в рамках возможностей этой версии. Не знаю, насколько эта версия в реальности функциональна. Не нашёл табличку со сравнением Enterprise и Community. По картинкам и техническому описанию всё выглядит очень красиво. Много своих разработок, о которых технический директор продукта больше часа рассказывал.
🔥 В рамках построения своей платформы Флант полностью переписали мониторинг Prometheus на C++, чтобы снизить нагрузку, которую он создаёт. По словами разработчиков он потребляет до 10 раз меньше памяти, чем обычный Prometheus и до 3 раз эффективней, чем VictoriaMetrics. Что значит эффективней, не знаю. Проект назвали Prom++, он open source, попробовать может каждый. У него полная совместимость с оригинальным Prometheus, так что можно просто заменить один на другой и попробовать. Очень интересный продукт. Если он реально полностью совместим и в 10 раз легче, то не вижу причин его не использовать.
🔴 На замену Ingress в Kubernetes разработали новый инструмент Gateway API. Самый популярный бесплатный Ingress Controller, или один из самых популярных, Ingress Nginx не будет его поддерживать. Планов по развитию бесплатной версии нет. Вроде как там что-то новое появилось, но я не уточнял. Так что сейчас использовать бесплатный Ingress Nginx большого смысла нет.
🟡 Несмотря на наличие развитых отказоустойчивых сетевых хранилищ для данных и протоколов их доставки, локальные диски остаются вне конкуренции по производительности и отклику. Особенно при использовании современных NVMe дисков. Для Deckhouse написан свой оператор для управления локальными хранилищами с использованием технологии LVM. Для отказоустойчивости можно добавить DRBD.
Вроде всё, что можно в формате короткой заметки написать. Было интересно. Я с Kubernetes вообще не работаю, хотя и знаю его. Могу развернуть и использовать. Знаю основные сущности и принцип работы. Тут за один день получил все обновлённые знания по разным темам: какой CNI-плагин что умеет и что лучше выбрать, как cilium доставляет пакеты в обход стандартной маршрутизации linux с использованием iptables (они всё ещё актуальны в кубере), как решаются вопросы с размещением statefull приложений, из чего состоит типовой кластер Kubernetes, какие актуальны ingress контроллеры и что они умеют, и т.д.
#devops #kuber
🟢 Конференция в первую очередь была посвящена программному продукту Deckhouse. А точнее экосистеме, которая состоит из множества компонентов. Основные - Kubernetes Platform и Virtualization Platform. Конференция в основном была посвящена Kubernetes и всему, что с ним связано.
Deckhouse Platform представлена в том числе в бесплатной редакции Community Edition с открытым исходным кодом. Развернуть и использовать можно без ограничений в рамках возможностей этой версии. Не знаю, насколько эта версия в реальности функциональна. Не нашёл табличку со сравнением Enterprise и Community. По картинкам и техническому описанию всё выглядит очень красиво. Много своих разработок, о которых технический директор продукта больше часа рассказывал.
🔥 В рамках построения своей платформы Флант полностью переписали мониторинг Prometheus на C++, чтобы снизить нагрузку, которую он создаёт. По словами разработчиков он потребляет до 10 раз меньше памяти, чем обычный Prometheus и до 3 раз эффективней, чем VictoriaMetrics. Что значит эффективней, не знаю. Проект назвали Prom++, он open source, попробовать может каждый. У него полная совместимость с оригинальным Prometheus, так что можно просто заменить один на другой и попробовать. Очень интересный продукт. Если он реально полностью совместим и в 10 раз легче, то не вижу причин его не использовать.
🔴 На замену Ingress в Kubernetes разработали новый инструмент Gateway API. Самый популярный бесплатный Ingress Controller, или один из самых популярных, Ingress Nginx не будет его поддерживать. Планов по развитию бесплатной версии нет. Вроде как там что-то новое появилось, но я не уточнял. Так что сейчас использовать бесплатный Ingress Nginx большого смысла нет.
🟡 Несмотря на наличие развитых отказоустойчивых сетевых хранилищ для данных и протоколов их доставки, локальные диски остаются вне конкуренции по производительности и отклику. Особенно при использовании современных NVMe дисков. Для Deckhouse написан свой оператор для управления локальными хранилищами с использованием технологии LVM. Для отказоустойчивости можно добавить DRBD.
Вроде всё, что можно в формате короткой заметки написать. Было интересно. Я с Kubernetes вообще не работаю, хотя и знаю его. Могу развернуть и использовать. Знаю основные сущности и принцип работы. Тут за один день получил все обновлённые знания по разным темам: какой CNI-плагин что умеет и что лучше выбрать, как cilium доставляет пакеты в обход стандартной маршрутизации linux с использованием iptables (они всё ещё актуальны в кубере), как решаются вопросы с размещением statefull приложений, из чего состоит типовой кластер Kubernetes, какие актуальны ingress контроллеры и что они умеют, и т.д.
#devops #kuber
GitHub
GitHub - deckhouse/deckhouse: Kubernetes platform from Flant
Kubernetes platform from Flant. Contribute to deckhouse/deckhouse development by creating an account on GitHub.
2👍60👎3
Очень простая и быстрая в настройке утилита для бэкапа GIT репозиториев. Можно использовать как для бэкапа куда-то локально или в S3, так и для копирования из одного репозитория в другой. Речь пойдёт про open source проект gickup.
Сразу покажу на примере, как я забэкапил к себе локально несколько своих закрытых репозиториев на публичном gitlab.
Создаю конфигурационный файл
Для получения token сходил в Preferences ⇨ Access tokens и создал personal access token с доступом только на чтение. В своём примере я забэкапил только 3 репозитория: gatus, scripts, configs. Если их не указать, забэкапит все.
Запускаю бэкап:
Вот и всё. Gickup поддерживает все популярные платформы для хостинга git, как публичные, так и приватные:
- Github
- Gitlab
- Gitea
- Gogs
- Bitbucket
- Onedev
- Sourcehut
В качестве источников для сохранения или копирования поддерживает их же, плюс:
- локальная директория
- S3 хранилище
Настройка источников и приёмников отражена в документации. Там всё кратко и по делу. Список параметров невелик. У меня сразу всё получилось.
Очень простой и быстрый способ копировать репозитории в одно или несколько мест одновременно. Дополнительно gickup умеет отправлять уведомления о своей работе в ntfy, gotify и apprise. Также может локально логи писать и отправлять метрики в Prometheus. Правда не очень понял какие. Не проверял это.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#git #backup #devops
Сразу покажу на примере, как я забэкапил к себе локально несколько своих закрытых репозиториев на публичном gitlab.
# wget https://github.com/cooperspencer/gickup/releases/download/v0.10.38/gickup_0.10.38_linux_amd64.tar.gz# tar xzvf gickup_0.10.38_linux_amd64.tar.gzСоздаю конфигурационный файл
conf.yml:source:
gitlab:
- token: glpat-GtPuYrBvnxxkTFsq-Y
url: https://gitlab.com/
user: zeroxzed
include:
- gatus
- scripts
- configs
wiki: true
issues: true
destination:
local:
- path: /home/zerox/backup-gitlab
structured: true
keep: 5
Для получения token сходил в Preferences ⇨ Access tokens и создал personal access token с доступом только на чтение. В своём примере я забэкапил только 3 репозитория: gatus, scripts, configs. Если их не указать, забэкапит все.
Запускаю бэкап:
# ./gickup conf.ymlВот и всё. Gickup поддерживает все популярные платформы для хостинга git, как публичные, так и приватные:
- Github
- Gitlab
- Gitea
- Gogs
- Bitbucket
- Onedev
- Sourcehut
В качестве источников для сохранения или копирования поддерживает их же, плюс:
- локальная директория
- S3 хранилище
Настройка источников и приёмников отражена в документации. Там всё кратко и по делу. Список параметров невелик. У меня сразу всё получилось.
Очень простой и быстрый способ копировать репозитории в одно или несколько мест одновременно. Дополнительно gickup умеет отправлять уведомления о своей работе в ntfy, gotify и apprise. Также может локально логи писать и отправлять метрики в Prometheus. Правда не очень понял какие. Не проверял это.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#git #backup #devops
2👍92👎3
Для тех, кто ещё не слышал или не знает, расскажу новости про ограничения на загрузку образов из 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