DevOps *

Привет, Хабр! У каждого из нас бывает этот момент. Ты нажимаешь кнопку «Заказать», и вот он — твой первый, сияющий, свежеустановленный VPS. Ощущение, как будто получил ключи от собственной цифровой квартиры. Можно ставить что угодно, экспериментировать, запускать свои пет‑проекты... Но есть один нюанс.

Эта «квартира» сейчас стоит с дверью нараспашку посреди самого темного и опасного района интернета. И пока ты радуешься, к этой двери уже тянутся сотни автоматизированных ботов, чтобы проверить, не забыл ли ты закрыть замок.

Я сам прошел через это. Мой первый сервер прожил в «диком» виде около часа, прежде чем я заглянул в логи и увидел непрекращающийся поток попыток входа по SSH. Это было мое «приключение» — превратить уязвимый кусок железа в безопасное убежище. Я наступил на пару граблей, но в итоге собрал «сокровище» — этот чек‑лист, которым хочу поделиться с вами.

Это не исчерпывающее руководство по пентесту, а набор первых, самых важных шагов, которые отсекут 99% автоматических атак и дадут вам спокойно спать по ночам.

В данное статье рассматривается порядок развертывания системы сбора резервных конфигураций сетевых устройств производства Cisco Systems и Juniper Networks, посредством применения «Ansible» и «GitLab». Подробно описан процесс развертывания данных инструментов с помощью docker‑compose.

Меня зовут Михаил, я работаю в Magnit Tech и занимаюсь внедрением 1C платформы на операционную систему Linux. В этой статье я расскажу, как реализовать создание резервных копий бакетов S3-совместимого объектного хранилища MinIO.

(Сразу дам спойлер: нам удалось это сделать с наименьшими затратами места на диске с использованием инкрементальных бэкапов).

В статье — реальный опыт перехода от классических облачных инстансов к Kubernetes и созданию абстракции Serverless, которая полностью избавила разработчиков от забот об инфраструктуре. Узнайте, как это повлияло на скорость релизов и стабильность сервисов Mercado Libre.

Небольшая инструкция, как открыть полноценный JupyterLab-сервер на выделенной A100 / A40 и получить до 4 бесплатных часов в день.

Привет, Хабр! В данной статье хочу разобрать auditd - полезный инструмент аудита в Linux, который записывает каждое действие, а скрипт превратит логи в читаемые отчёты и алерты.

Linux-сервер без мониторинга активности пользователей — как дом с открытыми окнами. Проблемы, которые помогает решить auditd:

• Несанкционированный доступ (кто и когда использовать, например, sudo)
• Подозрительные команды (rm -rf, изменение прав, доступ к каким-либо файлам)
• Расследование инцидентов (кто что натыкал перед падением сервера)
• Соответствие корпоративным стандартам (возможно, ИБ требует логирования действий или вы любите контроль)

Решение: auditd + Python-скрипт для анализа и алертов.

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

Сегодня разберём один из самых гибких инструментов в RabbitMQ — topic exchange. Именно он позволяет не просто отправить сообщение «куда‑то», а превратить очередь в маршрутизатор уровня BGP, но только внутри твоей системы.

В первой части мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование.

Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему.

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

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

Меня зовут Алиса, и я руковожу командой разработки контейнерной платформы «Штурвал». В последнее время мы с командой много работали над реализацией мультитенантности и перепробовали множество разных вариантов. Ниже я расскажу, как тенанты помогают закрыть «боли» при работе с K8s на примере трех проблем и поделюсь полезными инструментами.

Эта статья будет интересна тем, кто:

👉 «с ноги» врывается в свой первый кубер;
👉 самостоятельно строит Kubernetes-платформу;
👉 управляет одним или множеством кластеров K8s.

P. S. 31 июля в Москве состоится первая независимая конфа Kubernetes Community Day. Два пространства с хардкорными докладами и воркшопами от крутых экспертов из VK, МКБ, Yandex Cloud, «Лаборатории Числитель», ecom.tеch, Cloud ru, Luntry, FUN&SUN, Lamoda Tech и др. Участие бесплатное. Регистрация тут.

Привет! 👋 Меня зовут Алина. Я маркетолог и давно работаю в ИТ, но с безопасной разработкой познакомилась только когда пришла в продуктовую студию по кибербезопасности Axel PRO. И знаете, эта область заинтересовала меня в процессе работы. А еще у меня есть интересное хобби — я люблю играть в Dungeons&Dragons, иначе говоря — ДНД 🎭. И вот что я заметила: процесс разработки ПО очень похож на эту игру. Сейчас расскажу, почему.

Представьте, что разработка ПО — это ваша игра в Dungeons&Dragons. Вы собрали отряд: разработчиков, тестировщиков, продакт‑менеджеров, выбрали для них роли и отправились в приключение — создавать крутой продукт 🚀.

Но вот загвоздка: пока вы исследуете подземелья (пишете код) 🏰, на каждом шагу вас поджидает разная нечисть — уязвимости‑ловушки 🕳️, баги‑драконы 🐉 и орки‑ошибки конфигурации 🪓. Если вы не взяли с собой защитные свитки с политиками и шаблонами безопасности 📜, зелья исправления уязвимостей 🧪 и доспехи из безопасных практик 🛡️ — ваша команда рискует быстро проиграть.

Собираем команду

Как и в мире ДНД, в безопасной разработке у каждого участника команды есть своя уникальная роль и задачи. Например:

⚔️ Бэкенд‑разработчик — это воин, который создает и защищает код, отражая атаки.

🧙‍♂️ Тестировщик — маг, исследующий систему с помощью «заклинаний» тестов, чтобы найти слабые места.

⛩️ Администратор инфраструктуры — жрец, поддерживающий стабильность и безопасность серверов и окружения

🎶 HR‑менеджеры и менеджеры проекта — подобно бардам, поддерживают коммуникацию и помогают команде достигать общих целей.

Перевели для вас цикл статей об эволюции технологической платформы Mercado Libre — от монолитной архитектуры начала 2000-х к современной мультиоблачной платформе Fury, которая обеспечивает разработчикам удобную, масштабируемую и безопасную среду для создания, развёртывания и управления приложениями. В этой первой части описывается переход компании от единой базы и медленных релизов к микросервисам и облачным технологиям, что позволило значительно ускорить разработку и повысить надежность систем.

Раскрываем Docs as Code: как этот подход меняет создание документации, какие инструменты стоит изучить в первую очередь, и с чего начать внедрение.

В статье рассматривается подход к снижению энергозатрат Kubernetes-кластера путём динамической подстройки ресурсов под реальный профиль нагрузки. Описан опыт внедрения системы сбора показателей энергопотребления, построения модели потребления сервисов и разработки «умного» контроллера на Go. Приведены примеры кода для Python и Go, а также разбор неожиданных подводных камней, с которыми столкнулся инженер.

От хаоса в Markdown-файлах до стильного, быстрого сайта с поиском, темами и мультиязычностью за один вечер.
В жизни почти каждого IT-проекта наступает момент, когда количество файлов README.md, GUIDE.md, docs.txt и заметок в Confluence достигает критической массы. Документация становится фрагментированной, поиск нужной информации превращается в квест, а новые члены команды тратят часы на то, чтобы просто понять, "что где лежит".

В этой статье мы подробно рассмотрим процесс установки и настройки всех необходимых инструментов для эффективной разработки Python-приложений с использованием FastAPI, Docker и Docker Compose. Вы узнаете, как создать изолированную среду для вашего проекта, настроить отладку и обеспечить бесперебойную работу вашего приложения.

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

Всем привет! Сегодня я хочу поделиться полным руководством по развертыванию на своем сервере замечательного open-source инструмента для мониторинга — Uptime Kuma.

Всем привет, меня зовут Кирилл и я Android-разработчик в Scanny. В прошлых статьях мы разобрали, как будет выглядеть наш CI/CD, научились запускать статический анализатор кода, выполнять Android (Marathon Labs и Firebase Test Lab) и Unit-тестирование, собирать различные Build Flavors и отправлять их в нашу Telegram-группу.

В этой статье мы настроим публикацию свежих версий в Play Market на примере Gradle Play Publisher и Fastlane, а так же поработаем с Gitlab Tag'ами.

Так же улучшим наш CI/CD, собрав свой Docker-образ со всем необходимым окружением.

Привет, Хабр! Ручной мониторинг серверов и логов - это как разжигать костёр вместо использования микроволновки. Если вы вручную проверяете логи, доступность сервисов или реагируете на алерты посредством почты - попробуйте перейти на автоматизацию.

Почему скрипты?

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

Автоматизированный мониторинг - это не про сложные системы в стиле Zabbix или Prometheus (они очень хороши для масштабируемых решений, данного факта не отрицаю). Это простые скрипты, которые делают ровно то, что вам нужно. Нет лишних зависимостей, сложных конфигов или чего-то лишнего.