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

Всё началось с того, что в 2024 году мне в руки попал интересный экземпляр мини-ПК ( Характеристики: Процессор Intel N100 / RAM 16 GB / SSD 500 GB.) решив, что раз уж основная рабочая лошадка у меня уже есть, этот мики-ПК предстоит переделать в мини-сервер и приспособить к мои pet-проектам. Заказал себе 1Гбит интернет, белый IP адрес и ушел творить.

Первая моя задумка с треком провалилась, т.к изначально я разместил на нем Gitlab Server, NextCloud и пару своих приложений. «Жужжал» он не по-детски, я взаправду подумал, что в какой-то момент он просто отлетит к своим небесным производителям.

Привет, Хабр!

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

Решение нашлось довольно элегантное – интегрировать инструмент semantic-release в наш пайплайн CI/CD. Но оказалось, что найти полноценное руководство по его настройке, особенно с учетом корпоративного GitLab и плагина semantic-release/changelog, не так-то просто. Собирал информацию буквально по крупицам из различных источников, и вот теперь делюсь с вами проверенной пошаговой инструкцией.

Это вторая часть серии статей, где мы шаг за шагом строим PaaS на базе Kubernetes без написания кода. Напомню, для чего мы это делаем: наша цель — выжать максимум из современных технологий и экосистемы Kubernetes, чтобы создать PaaS-решение, которое упростит жизнь разработчикам. Мы хотим, чтобы приложения и сервисы разворачивались быстро, удобно и без глубокого погружения в инфраструктуру.

Если вы читаете этот материал, скорее всего вы уже знаете что поднять свой почтовик это страдание и внезапно нетривиальная задача. Цель статьи - без лишней лирики дать пошаговый мануал тем, кто хочет настроить свой собственный мейлер и не платить деньги mailgun и подобным SMTP-relay сервисам.

Руководителям групп разработки и членам команды часто приходится сталкиваться с проблемой информирования коллег о новых версиях docker image внутренних инструментов. Сообщения в общих чатах не всегда эффективны, а писать вручную — не лучшая практика. И тут мы рассмотрим разработку решения по автоматическому информированию.

Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.

И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.

Технотекст 7 получился необычным: мы провели всего одну рассылку, остальные статьи собирали органически — анонсами, упоминаниями и даже личным общением с авторами (как в личке, так и в оффлайн формате). Для такой активности результат превзошёл все ожидания: мы получили 833 заявки, приняли 763, в шорт-листы попали 499 заявок, из них 132 от частных пользователей, 367 — от компаний.

Почти все статьи оказались качественными — поэтому при скоринге материалов для шорт-листов оставались в первом туре статьи с рейтингом выше +50 и даже выше +100. Из неприятного — две «нейроночные» статьи, они были сняты с конкурса, искренне надеемся, что это был эксперимент и кто-то пробовал нас на прочность. Увы, думаю, что этот год стал последним спокойным с позиций ИИ-шного контента — в новом сезоне проверяться будет каждая статья. 

Скорость сборки Docker-образов играет важную роль в CI/CD, особенно для микросервисов, где частые обновления и тестирования требуют быстрой доставки изменений.

Одним из решений для оптимизации сборок является Docker Buildx — расширение к стандартной команде docker build. Docker Buildx предлагает дополнительные возможности, такие как кэширование слоев образов, что помогает значительно сократить время сборки за счет повторного использования неизменных слоев. В отличие от стандартного процесса сборки, Docker Buildx предоставляет более гибкое управление кэшем, поддерживает мультиархитектурные сборки и работу с несколькими платформами.

В этой статье мы сосредоточимся на том, как эффективно настроить и использовать кэширование с Docker Buildx в CI/CD пайплайнах на GitLab. Мы рассмотрим примеры, когда кэширование позволяет ускорить сборку, и ситуации, когда его лучше отключить для гарантии корректности итогового образа.

Функция rate() в PromQL необходима для вычисления средней скорости изменения метрики в секунду за определённый период времени. Она часто используется для мониторинга таких показателей, как:

Работаем с Haproxy, маршрутизация по GeoIP и ограничения, настройка mTLS для защиты сервисов, выгрузка метрик в Prometheus. Настройка панели 3X-UI для работы с Unix Socket и персональный DNS over HTTPS.

Хочу рассказать о своём проекте - Single Sign-On плагин для Sonatype Nexus Repository. Плагин реализует аутентификацию через SSO и пользовательские токены для Nexus редакции "Community Edition". Если вам интересна эта тема, то добро пожаловать под кат.

Всем привет! Меня зовут Артемий Иванов, и это моя первая статья на Хабре. В ней я хочу поделиться опытом, который получил, работая над задачей кастомизации поиска.

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

Разобраться во всех нюансах было непросто — приходилось вникать в обилие терминов и тонкостей «на ходу». В этой статье я покажу, как можно сделать поиск гибче с помощью Spring Data Elasticsearch — и всё это на конкретных примерах из практики.

Всем привет! Недавно закончился PGConf, где большая часть докладов была посвящена новым фичам PostgreSQL Pro, и лишь немногие касались ванильной версии. В прометей Лаб я влился с октября 2024 года и начал развивать сервис администрирования баз данных. Сегодня я хочу поделиться нашим подходом к мониторингу, который не требует лицензий, при этом экономит время и нервы.

Если вы DBA, то вы наверняка сталкивались с задачей мониторинга разных инстансов баз данных — PostgreSQL, MSSQL, MariaDB, Oracle или что-то из NoSQL — на разных ОС, от bare metal до PaaS. Настройка мониторинга в таких условиях может занять недели, а ошибки в алертинге приводят к простоям.

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

Я тоже через это проходил, поэтому в Prometey Lab мы сфокусировались на переносимом, масштабируемом, k8s ready решении, на типовых компонентах которое можно оперативно развернуть и с минимальной болью занести в разрешенный техстек. На последней демо, при наличии тех учеток в бд, весь процесс подключения нового клиента к мониторингу занимает 40 минут и поддерживает кастомизацию под любые нужды.

В этой статье я расскажу, как мы этого добились, поделюсь нашим стеком, примерами конфигураций и планами на будущее. Если вы сталкивались с подобными задачами, возможно эта статья натолкнет вас на мысли как «расшить» направление мониторинга и сократить время реакции на инциденты.

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

DevOps‑метрики — это количественные показатели, которые позволяют оценить эффективность, производительность и общее состояние DevOps‑процессов. Они предлагают аналитический взгляд на конвейер поставки программного обеспечения, позволяя командам разработчиков выявлять проблемные места, повышать производительность и принимать решения на основе реальных данных.

В этой статье мы поговорим о важности мониторинга DevOps‑метрик и о том, что именно нужно отслеживать. От широко известных метрик, которые приобрели статус стандартных благодаря DORA (DevOps Research and Assessment), до других важных индикаторов — мы предлагаем вашему вниманию исчерпывающее руководство, которое поможет вам измерить и оптимизировать ваши DevOps‑практики.

Я: хочу автодополнение кода
Также я: у нас уже есть автодополнение кода дома
Автодополнение кода дома:

Привет, Хабр! Я Саша, разработчик из Cloud4Y. Хочу поделиться с вами своей идеей локального развёртывания нейросети для автодополнения кода. В этом примере мы будем использовать модель Qwen2.5-Coder на 14B параметров. Есть идеи, как можно сделать это ещё лучше? С радостью послушаю.

Про информационную безопасность Kubernetes-кластеров много пишут с позиции специалистов ИБ. Но полезно взглянуть на эту тему глазами обычных пользователей K8s — инженеров и разработчиков. Тех, кто много работает со своими приложениями в подах, но не управляет служебными частями кластера.

Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.

Привет, Хабр!

Сегодня рассмотрим, как NGINX работает с DNS и почему proxy_pass не резолвит домены на ходу.

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"