DevOps *

Ссылка на пост в телеграм

Лучший стэк для запуска MVP SaaS-стартапа в РФ на 2025 год.

Вот наш боевой стэк, который мы сейчас используем для разработки SaaS-стартапа.

Проверено на собственной шкуре!

✅ Frontend:

- NextJS 15 (+React 19, Turbopack, Server Actions) - актуальный стек для веб-приложений.

- Shadcn UI (сделана на Tailwind) - библиотека UI-компонентов, чтобы сделать крутой интерфейс без дизайнеров.

- Netlify - бесплатный хостинг для тестовой версии продукта.

✅ Backend:

Supabase:

- База данных

- Database SQL Functions (функции сразу в базе PostgreSQL)

- Edge Functions (серверные функции на TypeScript)

Nextauth:

- Авторизация

✅ Инфраструктура:

Kubernetes:

- Репликация БД и сервисов на 3-х Worker-нодах

- Rollout-обновления без простоя

- Политики безопасности и изоляция

- CI/CD из GitHub.

+ Пароли/ключи в KeePass XC.

✅ Инструменты:

- IDEA Ultimate - среда разработки

- Cursor - для вайбкодинга (чистый, без всяких инфоцыганских MCP)

- DBeaver - для работы с БД

- GitHub - репозиторий

✅ Платежка

- Robokassa (РФ + иностранные платежи)

✅ Лендинг + блог

- Tilda (проще сделать сайт на конструкторе, чем все это вайбкодить)

Как мы все настроили

- Развернули проект в облачном хостинге в РФ, чтобы хранить данные в соответствии со 152 ФЗ. Выбрали хостинг с k0s, потому что он дешевле классического k8s.

- Supabase поставили на свой сервер (Cloud не подходит, так как данные хранятся не в РФ).

- Настроили регулярные бэкапы (хотя мы еще не релизились, но 1 раз у нас уже отлетали жесткие диски).

Почему именно такой стэк?

- Проще работать с технологиями, которые ты уже хорошо знаешь.

- Нам важна надежность, быстрое переключение новых версий на проде без простоя и возможность разделить продукт на версию под РФ и "мир".

- Для работы в РФ нужно хранить персональные данные в РФ и избегать трансграничной передачи данных.

- Конструктор сайтов как простой и недорогой вариант для лендингов и блога. Чтобы не вайбкодить целую CMS.

Сейчас мы подключаем платежку, причесываем баги, допиливаем лендинг и готовимся к релизу.

А какие технологии используете вы для разработки MVP?

Как управлять затратами в облаке: 5 уровней

А вы знали, что почти треть компаний не знает, куда уходят их облачные бюджеты? Нет, они, конечно, получают счета и даже по ним платят. Но почему в прошлом месяце было так, а в этом эдак, и кто в этом виноват – не имеют никакого представления.

Естественно, при таком подходе говорить о какой-либо эффективности не приходится. Потому что если одни экономят, а другие забивают на отключение тестовых сред и гоняют MongoDB там, где хватило бы PostgreSQL, толку не будет. Ведь платить-то все равно из общего котла. 

Проблема решается детализацией:

• Уровень 1 - тот самый общий котел, когда выделяется какая-то сумма, и вся она тратится без отслеживания эффективности. На этом уровне прозрачность находится на нуле.

• Уровень 2 - расходы распределяются по провайдерам. На этом уровне уже видно, что VK Cloud выставил столько-то, Яндекс Облако столько-то. Но почему – пока непонятно.

• Уровень 3 – раскладка по услугам. Compute съедает 60-70%, Storage – 20-30%, трафик – 10-15%. Уже появляется понимание, где самые дорогие компоненты.

• Уровень 4 – тегирование ресурсов. Так будет видно, какая команда тратит больше.

• Уровень 5 – cost-центры с реальными бюджетами. Showback показывает командам траты без списания денег. Chargeback списывает реальные суммы с реальных бюджетов. 

Компании, дошедшие до пятого уровня, экономят 20-30% без потери производительности.

Есть примеры обратного или хотите чем-то поделиться? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Почему Kyverno и Gatekeeper: рассказываем об инструментах, сравниваем их и решаем, какой удобнее 🔐

Задумываетесь, что лучше выбрать для управления политиками в Kubernetes — Kyverno или Gatekeeper? У нас есть ответ. Приходите на вебинар, где мы поговорим о каждом контроллере, осветим их плюсы и минусы, а еще сценарии, для которых лучше подойдет каждый. Оба инструмента будем разбирать на практике.

О чем расскажем:

• что предлагает рынок для управления политиками в Kubernetes;

• почему выбираем между Kyverno и Gatekeeper, какие у них сильные и слабые стороны;

• под какие задачи лучше подойдет каждый из инструментов, что удобнее в использовании.

Ждем всех, кому интересна безопасность в Kubernetes, в частности DevOps-инженеров, техлидов, директоров по разработке и специалистов по кибербезопасности.

📅 Когда? 13 ноября в 11:00 мск.

📍Где? Онлайн. Зарегистрируйтесь, чтобы обсудить сетевые политики в кубере и задать вопросы экспертам.

FinOps против Excel: кто управляет деньгами в облаке

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

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

А потом пришло облако. Сегодня нагрузка почти нулевая, а завтра конкурента блокируют, и трафик у тебя растет в разы. Автоскейлинг добавляет новые инстансы, счёт за неделю превращается в месячный.

CFO смотрит на это и разводит руками. Финансисты видят цифры, но не понимают, почему всё так скачет.

Проблема не в суммах, а в подходе. Старый финконтроль держится на стабильности, а облако живёт по принципу «всё меняется каждую минуту». Любая мелочь в архитектуре мгновенно отражается в P&L, а привычные отчеты не успевают за скоростью изменений.

FinOps меняет этот подход:

• Вместо квартальных отчетов — короткие кост-ревью

• Вместо агрегированных сумм — расходы по командам и проектам

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

Это уже даже не про “оптимизацию”, а про банальную прозрачность. Или транспарентность. Называйте как хотите.

Главное – что благодаря этому CFO может видеть деньги не в Excel, а прямо в инфраструктуре, и перестает реагировать на факты, а начинает ими реально управлять.

Тут-то баланс и восстанавливается: разработчики понимают цену своего кода, финансисты — динамику расходов, а бухгалтерия наконец перестает удивляться собственным счетам.

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Что будет с фотками, если закроется облако

Облачное хранилище работает отлично, пока работает. Но провайдер может закрыться, подписка закончиться, а аккаунт заблокироваться. Что тогда будет с вашими фотками?

Закрытие сервиса

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

Parse объявил о закрытии за год, а Everpix – за месяц. Но и в том, и в другом случае пользователям дали возможность выгрузить свои данные. Только после этого архивы удалили физически. 

Истечение подписки

У каждого провайдера свои правила хранения после окончания оплаченного периода. iCloud держит данные всего месяц, Dropbox – 2, а Google Drive позволяет загрузить их в течение двух лет.

Часть сервисов блокирует только загрузку новых файлов, оставляя возможность скачать старые. Но после истечения грейс-периода поддержка не восстанавливает ничего.

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Случаи потери данных

Бывает, что данные пропадают случайно. Вероятность такого исхода мала, но не равна нулю. Так, в 2015 году в дата-центр Google в Бельгии молния ударила 4 раза подряд. Пострадало около 0.000001% данных, то есть где-то 10 байт на гигабайт. Тем, кто попал в эту погрешность, конечно, легче не стало. Но цифры показывают, насколько это редкая ситуация.

В целом же, облака остаются более надёжным решением, в отличие от локальных дисков. Главное – оплачивать подписку вовремя.

Вышел релиз программного обеспечения topalias 3.0.0

Установка:
pip3 install -U --upgrade topalias
pipx install --force topalias
python3 -m pip install -U --upgrade topalias
python3.10 -m pip install -U --upgrade topalias

Запуск утилиты topalias:
topalias
python3 -m topalias
python3.10 -m topalias
python3 topalias/cli.py

Изменения:
Поддерживается Ubuntu 25.10/Python 3.13, Kubuntu 22.04/Python 3.10, KDE neon Rolling

Просьба проверить на актуальной версии Python 3.15 в KDE neon

Ссылка на дистрибутив KDE neon Rolling: https://distrowatch.com/table.php?distribution=kdeneon

topalias - утилита для генерации коротких алиасов по истории bash/zsh

На GitHub опубликована открытая утилита для генерации коротких алиасов на основании истории работы в bash или zsh. Утилита анализирует файлы ~/.bash_aliases, ~/.bash_history и ~/.zsh_history с историей выполнения команд в терминале Linux, после чего предлагает короткие аббревиатуры (акронимы) для длинных, долго набираемых и сложно запоминаемых, но часто используемых команд. Также поддерживается вывод статистики по истории работы в командной строке.

Если вы работаете в терминале десятки раз в день, алиасы — это мощный инструмент повышения эффективности. Но с ростом количества проектов и конфигураций .bashrc/.zshrc алиасов становится много: часть дублируется, часть устарела, некоторые перекрывают системные команды. topalias решает три задачи:

• дать метрику использования алиасов (какие используются чаще всего);

• упростить создание/удаление/пакетное управление алиасами;

• находить конфликтные или опасные алиасы и предлагать безопасные альтернативы.

В статье — обзор возможностей, примеры использования, внутренняя архитектура и практические рекомендации для интеграции с bash/zsh/fish.

Ключевые возможности

• Сбор статистики использования алиасов на основе shell-history.

• Команда top — список наиболее часто используемых алиасов.

• Интерактивный режим (TUI) для обзора, включения/выключения и редактирования.

• Поддержка bash, zsh и fish.

• Экспорт/импорт в виде конфигурационных файлов и git-репозиториев.

• Поиск конфликтов (алиас затеняет системную команду) и предупреждения.

• Генератор «умных» алиасов: на основе частых цепочек команд предлагает сокращения.

• Пакетная миграция между машинами (pack/unpack).

• Небольшой daemon/cron для частого обновления статистики (опционально).

# клонируем репозиторий

git clone https://github.com/CSRedRat/topalias.git

cd topalias

# установка в виртуальное окружение (рекомендуется)

python -m venv .venv

source .venv/bin/activate

pip install -e .

# инициализация в shell (одна строчка, добавьте в .bashrc/.zshrc)

topalias init --shell auto >> ~/.topalias-shell-rc && source ~/.topalias-shell-rc

Примечание: init генерирует небольшую обёртку для history-hook, чтобы собирать данные об использовании алиасов без заметной нагрузки.

Подписывайтесь на канал в Telegram: https://t.me/ruopsdev

Второй канал на Телеграм: https://t.me/journal_rbc_pro

• Просмотр самых часто используемых алиасов:

topalias top
topalias top --limit 20 # или с лимитом

• Найти алиас по фрагменту:

topalias find git

• Создать алиас:

topalias add ga='git add --all'

• Удалить алиас:

topalias rm ga

• Интерактивный режим (TUI):

topalias ui

• Экспорт текущих алиасов в файл:

topalias export --format bash > ~/.topalias-export.sh

Импорт из файла:

topalias import ~/.topalias-export.sh

Если вы часто выполняете цепочку:

git add . && git commit -m "WIP" && git push

topalias предложит вариант:

topalias suggest
# suggestion: gpush = git add . && git commit -m "WIP" && git push
topalias add gpush='git add . && git commit -m "WIP" && git push'

Проверим, не перекрывает ли алиас системную команду:

topalias check-conflicts
# output:
# - ls -> aliased to "ls --color=auto" (OK)
# - df -> aliased to "du -h" (DANGER: shadows system df)

Сохраняем пакет алиасов и переносим на другой компьютер:

topalias pack --name work-aliases > work-aliases.tar.gz
# на другом хосте
topalias unpack work-aliases.tar.gz
topalias import unpacked/work-aliases.sh

Как я починил ошибку tokenizers в ComfyUI

Недавно столкнулся с ошибкой при запуске ComfyUI - конфликт версий библиотеки tokenizers. Ошибка выглядела так: ImportError: tokenizers>=0.22.0,<=0.23.0 is required for a normal functioning of this module, but found tokenizers==0.21.4....Рассказываю, как я её исправил без поломки окружения и рабочих workflow.

Описание контекста:
У меня Portable-версия ComfyUI, встроенный Python (папка "python_embeded", папка "update", рабочие workflow и боязнь обновлять всё подряд)

Конфликт:
ComfyUI или один из плагинов требует tokenizers >= 0.22.0, а установлена старая 0.21.4. Ранее я уже точечно менял wheels и версию torch для работы с Nunchaku.

Решение:
Прямые команды, выполненные через PowerShell в папке ComfyUI:
(Чтобы ввести команды - нужно находясь внутри папки ComfyUI нажать Shift + ПКМ на свободном месте в этой папке и выбрать "Открыть окно PowerShell здесь" и ввести нужные команды)

python_embeded\python.exe -m pip uninstall -y tokenizers
python_embeded\python.exe -m pip install tokenizers==0.22.0

После перезапуска всё заработало:

PS D:\AI\ComfyUI2> python_embeded\python.exe -m pip uninstall -y tokenizers Found existing installation: tokenizers 0.21.4
Uninstalling tokenizers-0.21.4:
Successfully uninstalled tokenizers-0.21.4
и
PS D:\AI\ComfyUI2> python_embeded\python.exe -m pip install tokenizers==0.22.0
Collecting tokenizers==0.22.0
Using cached tokenizers-0.22.0-cp39-abi3-win_amd64.whl.metadata (6.9 kB) Requirement already satisfied: huggingface-hub<1.0,>=0.16.4 in d:\ai\comfyui2\python_embeded\lib\site-packages (from tokenizers==0.22.0) (0.34.4) .....
Successfully installed tokenizers-0.22.0

Как итог - видео с разрешением 364 на 640px, продолжительностью 5 секунд, сгенерировалось за 8,5 минуты на 8гб VRAM + 32гб RAM.

Почему важно не трогать "update_comfyui_and_python_dependencies.bat" ? Чтобы не нарушить совместимость всего окружения.
В таких случаях не стоит паниковать - достаточно понимать, как работают зависимости Python и виртуальные окружения.

Если вы работаете с ComfyUI или подобными пакетами, умение диагностировать и чинить зависимости - ваш надёжный инструмент в арсенале.

#ai #comfyui #python #design #code #workflow #ии

Привет, по случаю прикрутил к kui'ю немного helm'а. Можно посмотреть статус, историю, манифест и откатить релиз.

Творите, выдумывайте, пробуйте!)

Экономим с FinOps: доклады экспертов отрасли

Учиться на чужих ошибках дешевле, чем на своих. Практики FinOps рассказали, как разбирались с облачными расходами.

FinOps без иллюзий

Игорь Гальцев: FinOps – это не должность и не софт, а процесс. Инженеры, финансисты и менеджмент должны работать вместе, а из инструментов – только теги, распределенное бюджетирование и алерты. 

Когда счёт прилетает внезапно

Антон Черноусов из Yandex Cloud запустил проект без лимитов. Как итог – счёт на $2700 за день. Решить проблему помогла настройка бюджетов, алертов и автоматизации.

Практика и культура

Антон Егорушков из Купер (СберМаркет) рассказал, что динамические стенды и скоринг команд напрямую влияют на то, как расходуются бюджеты. Поэтому культуру FinOps строить сразу, иначе потом выйдет дороже.

Простые шаги

Станислав Погоржельский из VK Cloud считает, что экономия приходит как побочный эффект порядка. Добиться этого можно тестированием нагрузки, настройкой лимиты автоскейла и хранением файлов там, где надо. 

FinOps в Kubernetes

Алексей Минаев: 70% переплат сидят в Kubernetes, потому что ресурсов выделяют больше, чем используют. В итоге CPU загружен на 13%, память на 20%. Правильные реквесты и автоскейл поднимают утилизацию до нормальных 70%, и переплата исчезает.

SaaS и лицензии

Дитер Мейсон из Roku: FinOps не ограничивается только облаком. FinOps – это в том числе про управление подписками, аномалии в продлениях лицензий и, конечно, расчёт ROI.

Есть чем поделиться? Вступайте в наше сообщество Практики FinOps.

Как реально экономить на облаке с FinOps: рабочие кейсы

Мы много пишем о FinOps, о том, как он устроен и чем полезен. Но реальный опыт всегда интереснее любой теории. 

Мультиоблака и прозрачность

Поначалу Купер вообще не применял FinOps в своей работе, но потом привязал теги, CMDB и автоматизацию через Terraform. Результат: 75% расходов распределяются по владельцам, прозрачность и прогнозируемость бюджета. 

Производство и инженерный FinOps

ST Microelectronics работают с маленькой FinOps-командой, но экономят миллионы. Инженеры сами прогнозируют свои расходы и получают бонусы за точность прогнозов. В итоге их экономия – 30% без ущерба для SLA. 

Госсектор и Data Lake

Transport for NSW безуспешно боролись с зомби-ресурсами и ручными выгрузками. А потом запустили FinOps-дашборды и детектор аномалий. Как результат – расходы на Data Lake упали на 22%.

Автоматизация вместо таблиц

inQdo Cloud считали все расходы в Excel. Но когда внедрили FinOps-платформу, автоматизировали биллинг и нашли утечки бюджета, ситуация изменилась. Аналитику они сделали платной услугой для клиентов — и FinOps начал зарабатывать сам на себя.

Еще мы разобрали кейсы Qventus, Sportradar, Лемана Тех и NinjaCat. Проблемы у всех похожие, а решения разные: кто-то внедрил chargeback, кто-то показал разрабам цену запроса, а кто-то просто настроил автовыключение неиспользуемых ресурсов. Но все остались в плюсе.

Есть что рассказать? Залетайте в наше сообщество в Telegram и поделитесь своей историей с единомышленниками.

Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier.

Переведённая нами статья Камиль Фурнье с описанием круга проблем и задач, которые решает книга - Инжиниринг платформ: не CFEngine единым / Хабр

Аннотация книги

Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как  учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный  подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.

Для специалистов DevOps, системных администраторов, руководителей команд

Поделимся итогами исследования State of DevOps Russia 2025 на вебинаре

Команда «Экспресс 42» опросила тысячи инженеров и разработчиков для исследования состояния DevOps в России 2025. И вот анализ ответов завершён, а результаты готовы! Мы поделимся ими на вебинаре, который пройдёт 31 октября в 12:00 по московскому времени.

Зарегистрируйтесь, чтобы узнать, как изменился российский DevOps за год и какие тренды прослеживаются в индустрии — с фокусом на Developer Experience, ИИ и ИБ. Мы расскажем, какие инструменты и практики используют компании и покажем, как применить выводы исследования в ваших командах.

Что обсудим:

• характеристики Developer Experience, которые отличают высокоэффективные команды;

• задачи, для которых компании используют ИИ-инструменты;

• практики внедрения ИБ в процесс разработки;

• изменения в зарплатах и вакансиях DevOps-специалистов за год.

Будем вас ждать!

Привет, подкрутил немного свой kui. Добавил применение фильтра к подам в режиме подсматривания (watch it).

Теперь можно подсматривать только за интересными стрючками.

Творите, выдумывайте, пробуйте!)

Эгегей, kui еще немного окреп! Добавил команду 'rollout to revision'. Теперь можно откатывать деплои на определенную версию а не только на предыдущую.

Творите, выдумывайте, пробуйте!)

🔥 Как это было! Итоги Ansible Security CTF

14 октября мы собрались в уютном Failover Bar (г. Санкт-Петербург) 🏠, чтобы по-настоящему прокачать свои навыки в DevOps и кибербезопасности 🚀

Огромное спасибо всем участникам нашего интенсива "Ansible Security CTF – Защищай и Атакуй!" – вы сделали этот вечер незабываемым! 🙏

Что мы делали:
🛡 Писали Ansible playbooks, чтобы мгновенно закрывать уязвимости
🔎 Активно сканировали, подбирали пароли, искали флаги с помощью nmap, hydra и curl
💬 Общались, обменивались опытом и заводили новые знакомства!

🎉 Поздравляем победителей и напоминаем, что еще месяц в Failover Bar можно потренироваться на кейсах из интенсива! 💡В этом вам поможет бот 🤖 для CTF - https://t.me/DebugProCTF_bot

📆 Не хотите пропустить следующие мероприятия? Подписывайтесь на бота 🤖 DebugSkills - https://t.me/DebugProBot

👀 Ссылка на запись мастер-класса тут - https://vkvideo.ru/playlist/-232485571_2/video-232485571_456239019?linked=1

👀 Все фото в нашем канале - https://t.me/DebugSkills

Привет, небольшой апдейт. Добавил еще один тип k8s объектов который теперь можно тыкать kui'ем - volumeattachment

Творите, выдумывайте, пробуйте!)

Привет, как узнать % использования PVC? Kui поможет! Добавил команду PVC Usage

PVC это абстракция поэтому прямого пути (команды) узнать использование PVC нет. Как сделано? Ищем стручек (pod) который использует искомый PVC:

pvc_used_in=$(
    kubectl -n $namespace get po -o \
    jsonpath='{range .items[*]}{.metadata.name}{" "}{range .spec.volumes[*]}{.name}{" "}{.persistentVolumeClaim.claimName}{" \n"}{end}{end}' | \
    grep " $pvc_name "
)
raw=($pvc_used_in)
pod_name=${raw[0]}
mnt_name=${raw[1]}

Находим точку g монтирования:

pod_mount_name=$(
    kubectl -n $namespace get po/$pod_name -o \
    jsonpath='{range .spec.containers[*]}{range .volumeMounts[*]}{.name}{" "}{.mountPath}{"\n"}{end}{end}' | \
    awk "/$mnt_name /"'{print $2}'
)

Проверяем использование диска (PVC):

pvc_usage=$(
    kubectl -n $namespace exec po/$pod_name -- df -h $pod_mount_name
)

Выводим результат:

echo "PVC capacity: $pvc_capacity"
echo "PVC used in:"; echo "$pvc_used_in"
echo "PVC usage:"  ; echo "$pvc_usage"
PVC capacity: 750Gi
PVC used in:
kafka-dev-broker-1 data data-kafka-dev-broker-1 
PVC usage:
Filesystem      Size  Used Avail Use% Mounted on
/dev/rbd4       738G   44G  695G   6% /bitnami/kafka

Бонусом добавил возможность прибивать PVCишки kui'ем, добавил команды Delete и Terminate.

Творите, выдумывайте, пробуйте!)

Роли в FinOps

Как бы странно это ни звучало, но главное, на чем держится FinOps, — это общий язык, на котором говорят и финансисты, и технари. При этом у каждого из них есть своя роль:

➖  инженеры и DevOps, которые запускают ресурсы и должны видеть их стоимость

➖  продакты и бизнес-менеджеры, которые отвечают за ценность и окупаемость

➖  финансисты и закупки, которые смотрят на бюджеты и договоры

➖  руководители и C-level, которые принимают стратегические решения

В каждой компании распределение может отличаться. Но идея одна: никто не работает в вакууме. Инженеры понимают, во сколько обходятся их сервисы, финансисты знают, за что платят, а топы видят, какую отдачу приносит облако.

Такой подход убирает вечный спор, кто сколько тратит, и превращает расходы в совместную ответственность.

Близка тема, где финансы и инженеры наконец говорят на одном языке? Заглядываем в «Практики FinOps», там выходят кейсы, доклады, лайфхаки и немного самоиронии про жизнь в облаке.

Просто напоминаю про багбаунти от Selectel с призами до 30 000 рублей

В центре внимания — сам образ, его конфигурация, скрипты для автоматизации, настройки операционной системы и Keycloak. Всё остальное, включая DDoS-атаки, фишинг и внешние угрозы, находится вне рамок мероприятия.

Количество участников ограничено: 30 человек, из которых будут выбраны 3 победителя. Регистрация уже открыта, стартуем в октябре — присоединяйтесь и покажите, на что вы способны! 

Призы:

1 место: 30 000 бонусных рублей

2 место: 20 000 бонусных рублей

3 место: 10 000 бонусных рублей

Как устроено под капотом

Мы сделали образ Keycloak в облаке Selectel. Он содержит docker-compose c Keycloak, Postgres, Nginx и скриптами бэкапов. Настраивается через cloud-init: все подставляется из user-data. Поддержка cron-задач, логика запуска, безопасность по умолчанию. Образ рассчитан на стабильную работу из коробки.

Внутри образа Nginx работает как обратный прокси, Certbot выпускает сертификаты. Есть cron-задачи для обновлений и создания дампов. Закрытые URL’ы, доступ по white-list — ради безопасности админского контура. Настройка происходит автоматически при запуске образа.