Всем привет! Мы уже все понимаем, что блокировка Telegram будет в этом году. Сейчас власти делает это этапами, чтобы люди понемногу и без кипиша, мигрировали на Max. Понятно, что не все смогут или захотят это, но тут либо VPN либо более гуманная альтернатива - MTProxy.
Kubernetes взламывают не «эксплойтом века», а банальностями: открытый доступ, cluster-admin «на время», default serviceAccount, секреты в манифестах (да, base64 не защита). Дальше сценарий предсказуемый — от тихого майнинга до утечки ключей, как в истории с Tesla.
В статье разберу три базовых опоры k8s-безопасности: минимизация прав через RBAC, нормальная работа с секретами и изоляция workload’ов через securityContext и политики — с типовыми ошибками и практиками, которые реально внедрить.
Месяц назад я закинул задачу на рефакторинг модуля авторизации и пошёл варить кофе. Кофе я допить не успел. Через двадцать минут пришло уведомление в ТГ: «staging обновлён, 94 теста пройдено, 0 упало».
Открыл репозиторий. Ветка, diff на два экрана. Code review от второго агента. Три замечания, два по делу. Третий агент прогнал тесты и задеплоил.
Код был чище, чем я обычно пишу по пятницам.
Но до этого момента были три месяца граблей, упавший продакшен, и одна ночь, когда агенты сделали десятки бесполезных коммитов. Обо всём по порядку.
Observability — это не просто логи или метрики по отдельности, а целостная картина поведения системы. В этой статье разберём минимальный, но полноценный стек OpenTelemetry для Go-приложений: соберём метрики, трейсы и логи, прокинем их через otel-collector и посмотрим результат в Grafana (Prometheus + Tempo + Loki).
Без лишней теории — только практический пример: docker-compose, инициализация OTel в Go, инструментирование HTTP-клиента и сервера и просмотр данных в UI. В итоге получится рабочий шаблон, который можно использовать как основу для своих сервисов.
Fail2Ban долго был про «поставил и забыл», но сейчас он всё чаще работает как сигнализация, которая орёт уже после того, как дверь подёргали десятки раз — и каждый рывок остаётся в логах. Мы перевели сервер управления Netbird с Fail2Ban на CrowdSec и собрали это в практический разбор: как читать JSON-логи Caddy без плясок с регулярками, как вешать блокировки на nftables, и почему community threat intel позволяет отрезать часть сканеров ещё до того, как они успевают что-то «прощупать». По ходу рассмотрим конфиги, команды и наблюдения, что именно меняется в шуме, банах и нагрузке.
За последние восемь лет более 15 популярных баз данных изменили лицензии с открытых (BSD, Apache) на модели с ограничениями, которые запрещают коммерческое использование или требуют раскрыть весь программный стек. Разработчики выбирают открытые БД, а через несколько лет сталкиваются с необходимостью покупать лицензии или мигрировать — обычно в самый неподходящий момент.
Если вы думаете «сейчас выберем open source, а там разберемся» — этот пост для вас. Я не буду разбирать юридические тонкости, а попробую ответить на простой вопрос — какие БД сегодня опасно брать в прод и чем их можно заменить, если это уже случилось.
Дисклеймер: хронологии и технические характеристики — это факты, которые я собрал из публичных источников. Списки рисков, красные флаги и прогнозы по конкретным вендорам — моя аналитика на основе наблюдаемых паттернов. Ваши выводы могут отличаться, и это нормально.
Привет, Хабр!
Это продолжение серии про обход блокировок Telegram. В первой части мы подняли MTProxy на nineseconds/mtg с Fake TLS. Работает, подключаешь и забываешь. Но есть нюанс.
Fake TLS маскирует протокол. DPI смотрит на пакеты и видит обычный TLS к 1c. Всё красиво, пока к вашему серверу не придёт краулер и не попробует на него зайти.
Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. Я решил написать о работе с инцидентами, ведь мы часто говорим, что "тушим пожары". Так вот мне стало интересно, можно ли что-то полезного взять у реальных пожарных и чрезвычайных служб к нам в IT.
И знаете, многое похоже, но кое-что прям явно хочется забрать.
Вести одно расширение 1С сразу для нескольких конфигураций (УНФ, Розница, УТ, КА, ERP) и не сойти с ума на каждом merge — реально. В статье разбираю рабочую схему, которую мы применили в опенсорс-проекте 1C AI Autofill.
Ключевая идея: main — ядро (логика и «истина»), ветки конфигураций — тонкие адаптеры с отличиями в Configuration.xml. Плюс git worktree, чтобы держать несколько сборок рядом, чистая XML-выгрузка вместо EDT для предсказуемого diff/merge и автоматическая сборка .cfe через PowerShell и 1cv8 DESIGNER — без ручного LoadCfg / UpdateDBCfg.
В статье — структура веток, правила разрешения конфликтов, фрагменты кода (HTTP + JSON, длительные операции) и пример скрипта сборки. Если вы хотите «как в нормальном мире»: GitHub, релизы и воспроизводимая сборка — будет полезно.
Репозиторий: https://github.com/msrv-tech/1c-ai-autofill
Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.
С тех пор вышло несколько релизов. Мы исправили много ошибок, переписали рантайм и добавили недостающие инструменты. Хочу рассказать, что изменилось.
Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM
Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)
Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL
Типы: strict mode, flow-sensitive typing
Тулинг: LSP и дебаггер
Embedding: встраивание Funxy в Go-приложения как скриптовый движок
А вы тоже слышали байку о том, что облако по сравнению с онпрем-инфраструктурой получается едва ли не дешевле электричества из розетки, а PAYG – справедливее коммунизма? Нет, в целом принцип и правда выглядит очень честно: сколько заказал – столько и заплати. Как в ресторане. На практике такого, конечно, чаще всего бывает. Но чего всегда бывает в избытке – так это претензий финотдела, который кого угодно сведет с ума, допытываясь, почему растут счета. А кто бы их знал? Продакшн стабилен, метрики зеленые, архитектура давно устоялась – причин для роста как будто и нет. Но компании то и дело выходят за рамки бюджетов.
Привет, Хабр!
Telegram блокируют всё активнее. VPN детектят и режут. Обычные прокси живут неделю. Что делать? Ответ MTProto Proxy с Fake TLS: специализированный прокси, который маскируется под обычный HTTPS-трафик к легитимным сайтам вроде 1c или sberbank. Для DPI это выглядит как обычный визит на сайт, а на деле стабильный Telegram.
Сегодня разберём полную инструкцию: от выбора правильного VPS до эффективной маскировки и мониторинга.
Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.
Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.
Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.
Привет, Хабр!
Меня зовут Никита Шехов, я руковожу командой разработки «Единой цифровой платформы» (ЕЦП) в РСХБ.Цифра. В этой статье хочу рассказать, как мы создавали платформу для автоматизации бизнес-процессов банка, с какими вызовами столкнулись и какие решения оказались ключевыми. Вайб того времени: у нас было два часа на сон, семьдесят пять созвонов в день, пять бизнес-линий или стримов, план, целиком наполненный большими амбициями, целое море разношерстных систем, продуктов и групп разработки, а также ящик прогхантерского энергетика, литры чистого адреналина, ящик зеленого мерча и 12 пузырьков жидкого магния.
В современных условиях любая растущая компания рано или поздно сталкивается с необходимостью централизованного управления доступом сотрудников к информационным системам. Какое решение выбрать в такой ситуации?
В мире информационных технологий нет ничего постоянного. Стандарты меняются: если раньше стандартом было развертывание локальных серверов и отдельных учетных записей, то сейчас фокус сместился в сторону централизованного управления идентификацией. Современным базовым стандартом для любой развитой IT-инфраструктуры стал Единый Вход или SSO (Single Sign-On).
SSO — это метод аутентификации, который позволяет пользователю один раз войти в систему и получить доступ к нескольким связанным приложениям или сервисам без необходимости повторного ввода учетных данных.
Наша команда на практике прошла путь интеграции с различными SSO. Мы работали с такими решениями, как WSO2 и ADFS, и каждый раз убеждались в том, насколько SSO важен для инфраструктуры.
Этот опыт позволил определить требования к Identity Provider’у: открытость, масштабируемость и возможность адаптации под быстро меняющиеся бизнес-задачи. И здесь на первый план выходит Keycloak.
Почему именно Keycloak?
В отличие от многих аналогов, Keycloak — это решение с рядом преимуществ:
Возможно, я проклята. Иначе как объяснить, что снова и снова мне приходится собирать команды? Интервью — привычная часть моей работы, даже если прямо сейчас своей команды нет. Такая уж роль — «Technical Product». В какой-то момент я неизбежно становлюсь нанимающим менеджером, а значит, снова нужно тратить время на поиск, воронку, собеседования и онбординг.
В некоторых компаниях с этим проще: есть сильная HR-функция, и HR действительно помогают — продумывают онбординг, соединяют корпоративную часть и командную, следят, чтобы ничего не упало по пути. Но бывает и по-другому: есть рекрутеры, но нет HR-департамента, потому что компания ещё просто не доросла. И тогда весь онбординг — ваша личная головная боль. Если хотите, чтобы новые ребята не просто вышли на работу, а вросли в команду — придётся делать всё самостоятельно. У меня как раз такой кейс.
Тема CI/CD уже давно набила оскомину — если не вам, дорогой читатель, то уж точно мне. Впервые я столкнулся с этим ещё 15 лет назад, когда поставил свой первый Jenkins. Потом были TeamCity, Travis CI, GitLab CI и другие. Из всего этого зоопарка единственное решение, которое оставило тёплые воспоминания, — это Drone CI.
А что интересного сейчас? После недолгих поисков и чтения документаций я наткнулся на Woodpecker CI — лёгкий, open-source инструмент для непрерывной интеграции, форк Drone CI и "Github Actions" платформы Codeberg.org.
Привет, Хабр! Меня зовут Андрей Качетов, я эксперт и партнер по ML-платформам.
Пару лет назад я писал статью о «молодом и подающем надежды» подходе MLOps, и по сей день продолжаю внедрять его в жизнь наших дата-сайентистов. С тех пор ландшафт в мире машинного обучения заметно изменился. Многие компании уже понимают ценность MLOps и внедряют у себя MLflow, Airflow и другие подобные решения. Сегодня я расскажу о практическом кейсе одной из таких компаний.
Я много лет мечтал построить свою облачную платформу — и если раньше я пытался реализовать эту мечту в рамках нескольких компаний и проектов, то в последние годы я запустил собственный проект, Cozystack. В своей статье я расскажу о нашем опыте и о том, как, на мой взгляд, стоит подходить к созданию современной инфраструктурной платформы, в основе которой — Kubernetes и Kubernetes API.
Я разберу платформенный подход: что такое платформы, как они работают, кому нужны и как построить свою. А также сравню разные архитектуры для платформ, расскажу, почему мы остановились именно на K8s как на ключевой технологии, и покажу, как мы собрали на его основе production-решение.
Если вы собираете метрики через VictoriaMetrics, вы работаете в облаках, у вас большая инфраструктура, развернутая в нескольких зонах доступности, то в какой-то момент заметите, что счета за метрики начинают составлять ощутимый процент в счете за инфраструктуру.
Иногда этот момент совпадает с провалами в графиках, из за того, что вы перегрузили сервис мониторинга своего облачного провайдера.
