Forwarded from do IT right
Сегодня я к вам с загадкой 🕵️♂️
Некий злодей взломал наш домен Active Directory. Но почему-то единственное, что он сделал — создал две рядовые учётные записи: одну для компьютера, другую для пользователя. Вот как на скриншотах.
С виду — обычные непривилегированные учётки.
Но на деле — у них самые большие права в домене.
⚡Вопрос: как такое возможно? Назовите хотя бы два способа.
Некий злодей взломал наш домен Active Directory. Но почему-то единственное, что он сделал — создал две рядовые учётные записи: одну для компьютера, другую для пользователя. Вот как на скриншотах.
С виду — обычные непривилегированные учётки.
Но на деле — у них самые большие права в домене.
⚡Вопрос: как такое возможно? Назовите хотя бы два способа.
1❤3👍2 1
Forwarded from Уютный IT адочек
CD и Фаулер: что на самом деле означает “Continuous Delivery”
Когда говорят “CI/CD”, обычно имеют в виду: “я запушил код — он магически оказался в проде”. Но это не Continuous Delivery. Настоящий CD — это не про кнопки “Deploy” и не про джобы в GitLab CI. Это про то, как код попадает к пользователям быстро, безопасно и непрерывно.
❓ Что такое CD по Фаулеру ❓
Continuous Delivery (CD) — это подход, при котором каждое изменение кода потенциально готово к продакшену. Это не значит, что код выкатывается мгновенно, но если понадобится — он может быть развернут в любой момент.
Фаулер выделяет три ключевых аспекта CD:
1. Код готов к деплою в любой момент, а значит:
- Каждая фича или фикс проходят полный цикл тестирования.
- Код хранится в рабочем состоянии в любой момент времени.
- Нет отделения “стабильного кода в main” и “свалки разного в develop” — код в принципе можно катнуть всегда (хотя фича и не всегда в нём будет доступна пользователям).
2. У вас есть автоматизация доставки
- Тесты, сборки, деплой — всё автоматизировано. Если нет — вы не сможете дешёво принимать решение о стабильности кода каждый раз, когда это вам надо.
- Минимум ручного труда: нажал кнопку — код улетел в прод.
3. Вы не боитесь деплоить
- Можно катить обновления хоть десять раз в день, потому что всё контролируемо.
- Есть откаты, фичетогглы, канареечные релизы.
Прийти к такому идеальному состоянию не просто, он требует экстремальной технологической диктатуры. Однако, у Фаулера можно многому вдохновиться, особенно если:
💩 Ваш код накапливается в develop или — ещё хуже — в feature-ветках и неделями ждёт релиза.
🧎 Деплой идёт вручную, с “ночным окном” и мантрами “ну давай, родимый”, или требует сложных приседаний в том, в какой очерёдности что катить.
🤣 Миграций схемы базы данных или автоотката релиза у вас нет, а если что-то сломалось — специально обученные эксперты чинят на горячую.
😳 Релизить по пятницам нельзя — ведь тогда ой-ой-ой — придётся работать в выходные
Когда говорят “CI/CD”, обычно имеют в виду: “я запушил код — он магически оказался в проде”. Но это не Continuous Delivery. Настоящий CD — это не про кнопки “Deploy” и не про джобы в GitLab CI. Это про то, как код попадает к пользователям быстро, безопасно и непрерывно.
Continuous Delivery (CD) — это подход, при котором каждое изменение кода потенциально готово к продакшену. Это не значит, что код выкатывается мгновенно, но если понадобится — он может быть развернут в любой момент.
Фаулер выделяет три ключевых аспекта CD:
1. Код готов к деплою в любой момент, а значит:
- Каждая фича или фикс проходят полный цикл тестирования.
- Код хранится в рабочем состоянии в любой момент времени.
- Нет отделения “стабильного кода в main” и “свалки разного в develop” — код в принципе можно катнуть всегда (хотя фича и не всегда в нём будет доступна пользователям).
2. У вас есть автоматизация доставки
- Тесты, сборки, деплой — всё автоматизировано. Если нет — вы не сможете дешёво принимать решение о стабильности кода каждый раз, когда это вам надо.
- Минимум ручного труда: нажал кнопку — код улетел в прод.
3. Вы не боитесь деплоить
- Можно катить обновления хоть десять раз в день, потому что всё контролируемо.
- Есть откаты, фичетогглы, канареечные релизы.
Прийти к такому идеальному состоянию не просто, он требует экстремальной технологической диктатуры. Однако, у Фаулера можно многому вдохновиться, особенно если:
💩 Ваш код накапливается в develop или — ещё хуже — в feature-ветках и неделями ждёт релиза.
🧎 Деплой идёт вручную, с “ночным окном” и мантрами “ну давай, родимый”, или требует сложных приседаний в том, в какой очерёдности что катить.
Please open Telegram to view this post
VIEW IN TELEGRAM
8 6 2 2
Abstraction Debt в IaC — когда абстракции начинают мешать
Прочитал заметку про то, как абстракции в Infrastructure as Code могут выйти боком: [тут]
Суть в чём: на каком-то этапе поддерживать и дебажить эти слои абстракций становится дороже, чем вся польза от их переиспользования.
🚨 Пример из жизни
Смотришь в
🔧 Или ещё хуже
Нельзя просто взять и поменять версию рантайма. Новый образ для пайплайна не воткнёшь — приходится перелопачивать всю цепочку этой адовой конструкции.
✅ Выводы
Слои абстракций — это круто, пока они не превращаются в головняк. Если деплой или дебаг занимает больше времени, чем написание с нуля — пора резать лишнее. И да, держите документацию на такие "гениальные" задумки, а то потом сам не разберёшь.
Прочитал заметку про то, как абстракции в Infrastructure as Code могут выйти боком: [тут]
At some point, abstraction reaches a point of diminishing returns, where the overhead required to maintain and debug it outweighs the benefits of reuse.
Суть в чём: на каком-то этапе поддерживать и дебажить эти слои абстракций становится дороже, чем вся польза от их переиспользования.
🚨 Пример из жизни
Смотришь в
.gitlab-ci.yml — стадия деплоя вызывает кастомный образ. В нём обязателен конкретный entrypoint, который запускает питоновский cd-deployment-install. А тот ещё и шаблонизируется через Ansible с Jinja2. Поди задебажь, где оно сломалось, когда всё в кучу. 🔧 Или ещё хуже
Нельзя просто взять и поменять версию рантайма. Новый образ для пайплайна не воткнёшь — приходится перелопачивать всю цепочку этой адовой конструкции.
✅ Выводы
Слои абстракций — это круто, пока они не превращаются в головняк. Если деплой или дебаг занимает больше времени, чем написание с нуля — пора резать лишнее. И да, держите документацию на такие "гениальные" задумки, а то потом сам не разберёшь.
5👍6❤2 2
Forwarded from ZVLB. Tech (Vladimir Zemtsov)
Grafana OnCall - все. Поигрались 3 годика, и хватит)
Grafana Labs объявила, что с 11 марта 2025 года OnCall (OSS) переходит в режим maintenance, а через год и вовсе отправится в архив. Для тех, кто, как и я, уже обжёгся на его настройке, это не стало неожиданностью.
Для начала пару моментов, почему, по моему мнению, OnCall не взлетел:
1. Зоопарк зависимостей
Для работы требовались Grafana, MySQL, Redis, RabbitMQ, а ещё — куча времени на их интеграцию.
2. Сложность настройки уведомлений
SMS и push-нотификации зависели от Grafana Cloud, что убивало идею self-hosted.
3. Отсутствие удобных и знакомых подходов
Лично меня сильно оттолкнуло 2 года назад, что у алертов не было никаких label'ов, по которым их можно было бы группировать и объеденять. После моих тестов этот функционал был внедрен, но для меня - уже было поздно. Первое впечатление - негатив
4. Деньги
По факту никто не отказывется от OnCall's. Просто он станет частью Grafana IRM, для пользования которым надо... Заплатить. ТО ЕСТЬ! Эти ребята выкинули в OpenSource сырой продукт. Подкрутили его вместе с сообществом, Чтобы он стал удобным, и мигрируют его в свой Cloud на платную основу. КРАСАВЦЫ! (Да. Вы можете форкнуть OnCall и самостоятельно вести его развитие, но каммон...)
___
Что значит «maintenance mode» для пользователей?
- До 24 марта 2026 OnCall (OSS) будет получать только критические фиксы (CVSS ≥ 7.0).
- Мобильное приложение IRM перестанет работать с self-hosted OnCall через год.
- SMS и push-уведомления отвалятся, так как они завязаны на Grafana Cloud.
Grafana предлагает перейти на Cloud IRM — гибрид OnCall и Incident с «единым интерфейсом». Но если вы, как и я, не хотите зависеть от облака - это не выход.
В общем, для тех, кто как и я особо не двигался с AlertManager-стека все круто. Не двигаемся дальше ;)
#zvlb_musle #grafana #oncall
Grafana Labs объявила, что с 11 марта 2025 года OnCall (OSS) переходит в режим maintenance, а через год и вовсе отправится в архив. Для тех, кто, как и я, уже обжёгся на его настройке, это не стало неожиданностью.
Для начала пару моментов, почему, по моему мнению, OnCall не взлетел:
1. Зоопарк зависимостей
Для работы требовались Grafana, MySQL, Redis, RabbitMQ, а ещё — куча времени на их интеграцию.
2. Сложность настройки уведомлений
SMS и push-нотификации зависели от Grafana Cloud, что убивало идею self-hosted.
3. Отсутствие удобных и знакомых подходов
Лично меня сильно оттолкнуло 2 года назад, что у алертов не было никаких label'ов, по которым их можно было бы группировать и объеденять. После моих тестов этот функционал был внедрен, но для меня - уже было поздно. Первое впечатление - негатив
4. Деньги
По факту никто не отказывется от OnCall's. Просто он станет частью Grafana IRM, для пользования которым надо... Заплатить. ТО ЕСТЬ! Эти ребята выкинули в OpenSource сырой продукт. Подкрутили его вместе с сообществом, Чтобы он стал удобным, и мигрируют его в свой Cloud на платную основу. КРАСАВЦЫ! (Да. Вы можете форкнуть OnCall и самостоятельно вести его развитие, но каммон...)
___
Что значит «maintenance mode» для пользователей?
- До 24 марта 2026 OnCall (OSS) будет получать только критические фиксы (CVSS ≥ 7.0).
- Мобильное приложение IRM перестанет работать с self-hosted OnCall через год.
- SMS и push-уведомления отвалятся, так как они завязаны на Grafana Cloud.
Grafana предлагает перейти на Cloud IRM — гибрид OnCall и Incident с «единым интерфейсом». Но если вы, как и я, не хотите зависеть от облака - это не выход.
В общем, для тех, кто как и я особо не двигался с AlertManager-стека все круто. Не двигаемся дальше ;)
#zvlb_musle #grafana #oncall
Grafana Labs
Grafana OnCall OSS in maintenance mode: your questions answered | Grafana Labs
Grafana Labs has put Grafana OnCall (OSS) into read-only, maintenance mode, and will archive the project in one year on 2026-03-24. Here's what you need to know about the transition.
👍7👎2
Kaniuse — визуализация Kubernetes API для каждой из версий
"Инфографика" изменений Kubernetes API по версиям. Теперь можно глянуть, как стадии фич меняются, без тонны текста.
🚀 Смотрите, какие фичи в Alpha, Beta или GA, и как они меняются между версиями. Всё наглядно, с цветами и фильтрами.
✅ Чтобы не копаться в доках часами — открыл, увидел, понял. Плюс, если пишете что-то под K8s, сразу видно, что нужно и можно использовать.
"Инфографика" изменений Kubernetes API по версиям. Теперь можно глянуть, как стадии фич меняются, без тонны текста.
Please open Telegram to view this post
VIEW IN TELEGRAM
1 7👍2❤1
STUN/TURN в Kubernetes
Вы хотите принять входящий RTP-трафик по UDP в приватном кластере Kubernetes. Что делать?
Динамические порты для VoIP (RTP) в приватном кластере — интересная задачка. Особенно если ноды без публичных IP, а трафик нужно принять снаружи. А еще в Kubernetes открыть диапазон портов для сервиса можно, например, с hostNetwork: true, потому что NodePort не поддерживает диапазоны портов. Кстати, с 2016 года висит issue — диапазоны портов на NodePort так и не подвезли.
🚀 Тут выручают STUN и TURN.
☎️ VoIP-сессии (RTP) используют диапазон портов, а NAT и фаерволы могут это осложнить. STUN помогает клиентам узнать свой публичный IP и порт через NAT. TURN берёт на себя роль релея, если прямой путь заблокирован.
🌎 STUN: клиент отправляет запрос на STUN-сервер, получает ответ с внешним IP и портом. Потом сам решает, как отправлять пакеты. Быстро и просто, но не работает с симметричным NAT.
🔗 TURN: клиент подключается к TURN-серверу, тот выделяет порт и перенаправляет трафик.
🔧 Есть coturn — проверенный opensource-сервер для STUN и TURN. Разворачиваете с двумя сетевыми интерфейсами (приватным и публичным), настраиваете порты (обычно 3478 для STUN, плюс релейные для TURN), добавляете TLS для защиты. Поды VoIP-сервиса в K8s цепляются к нему через конфиги.
✅ STUN хорош для простых сценариев, TURN — для сложных. В приватном K8s они спасают RTP от проблем с NAT и фаерволами. Coturn выручает, если хочется свой сервер вместо облачных сервисов.
Вы хотите принять входящий RTP-трафик по UDP в приватном кластере Kubernetes. Что делать?
Динамические порты для VoIP (RTP) в приватном кластере — интересная задачка. Особенно если ноды без публичных IP, а трафик нужно принять снаружи. А еще в Kubernetes открыть диапазон портов для сервиса можно, например, с hostNetwork: true, потому что NodePort не поддерживает диапазоны портов. Кстати, с 2016 года висит issue — диапазоны портов на NodePort так и не подвезли.
☎️ VoIP-сессии (RTP) используют диапазон портов, а NAT и фаерволы могут это осложнить. STUN помогает клиентам узнать свой публичный IP и порт через NAT. TURN берёт на себя роль релея, если прямой путь заблокирован.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Support port ranges or whole IPs in services · Issue #23864 · kubernetes/kubernetes
There are several applications like SIP apps or RTP which needs a lot of ports to run multiple calls or media streams. Currently there is no way to allow a range in ports in spec. So essentially I ...
1👍4❤3 3🦄2
А вы знали, что
kubectl explain выдает полную спеку ресурса с описанием всех параметров?Например
kubectl explain pods.spec.containers--recursive, то покажет все возможные поля с описанием.
А так же, есть плагин https://github.com/keisku/kubectl-explore
What’s lacking in the original kubectl-explain?
- kubectl explain requires knowing in advance the resource name/fields.
- kubectl explain requires typing the accurate path to the resource name/field, which is a tedious and typo-prone.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9 3❤1
Linux-поды теперь поддерживают user namespaces. Безопасность через ядро для ограничения привилегий.
Stateful-процессы масштабируются вверх без остановки. Увеличение ресурсов без перезапусков.
Альфа-фичу из 1.26 (KEP-3503) убирают — containerd не поддерживает это, как выяснилось.
Картинку сгенерил с помощью ChatGPT с четвертого раза своим дегенским промптом
Please open Telegram to view this post
VIEW IN TELEGRAM
6 5 2👍1 1
Forwarded from Лемана Тех
Как сократить время разработки дата-продуктов в 1,5 раза? 🤔
Рассказываем в карточках, как и зачем мы создали централизованную MLOps-платформу.
Полный доклад с HighLoad++ от Елизаветы Гавриловой можно посмотреть здесь👀
Рассказываем в карточках, как и зачем мы создали централизованную MLOps-платформу.
Полный доклад с HighLoad++ от Елизаветы Гавриловой можно посмотреть здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2 3👎2🦄2
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 syncgit — ClickOps + GitOps без дрифта
Любопытная тула для обьединения ClickOps и GitOps подходов к управлению ресурсами в Kubernetes.
🙏 Теперь можно делать изменения напрямую в кластере, не переживая, что тот же ArgoCD отклонит эти изменения, так как они сразу попадут в git-репозиторий, а оттуда через ArgoCD синхронизируются в кластере. Таким образом мы исключаем configration drift, оставляя возможность ручного управления.
📖 подробнее объяснение концепции тут и как это работает с ArgoCD тут
Любопытная тула для обьединения ClickOps и GitOps подходов к управлению ресурсами в Kubernetes.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤5👍3 2
«Экспресс 42» запустил ежегодный опрос про состояние DevOps. Цель — собрать 4000+ ответов от инженеров, разработчиков, админов, тестировщиков и IT-руководителей.
- Доступ к результатам исследования.
- Шанс выиграть мерч, промокоды или билеты на Highload++ и DevOpsConf.
Если вы связаны с DevOps — пройдите опрос. Чем больше ответов, тем точнее картина.
Please open Telegram to view this post
VIEW IN TELEGRAM
1 1 1 1