DevOps

Security Gate (DevSecOps cicd) Хочу начать с кратенького предисловия, почему я решил написать что-нибудь про DevSecOps. Я довольно-таки часто сталкиваюсь с непониманием, что же автоматизируют и для чего нужны DevSecOps инженеры, где их место в компании и в современном ИБ. Да и что далеко ходить, многие коллеги DevOps, сами считают, что с добавлением trivy или sonarqube в пайплайны, ты уже носишь гордое звание DevSecOps. Поэтому в этой статье поговорим о том, как должны выглядеть DevSecOps пайплайны, чтобы они трансформировались во что-то зрелое. В Security Gate! https://habr.com/ru/articles/917970/ #devops #девопс Подпишись 👉 @i_DevOps

🆕💥 Разработчик, получи актуальные знания о микросервисах и Шаблон настроек конфигурации для Spring Boot: Kafka Умение строить архитектуру микросервисов — навык, необходимый разработчикам и тем, кто хочет стать архитектором ПО. Переходи на сайт, чтобы проверить свои знания и посмотреть подходит ли тебе 💥 обновленная программа курса Microservice Architecture от OTUS! Если успешно пройдешь тест, сможешь забронировать место в группе по специальной цене, а так же получить шаблон настроек конфигурации для Spring Boot: Kafka 🎫 Курс можно приобрести в рассрочку. 👉 Пройти тест: https://vk.cc/cMRjqL Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как сократить расходы на мониторинг: замена Prometheus на VictoriaMetrics Мониторинг может оказаться дорогостоящим из-за огромных объёмов данных, которые необходимо обрабатывать. В этой статье ты узнаешь лучшие способы хранения и обработки метрик мониторинга для снижения затрат, а также как в этом может помочь VictoriaMetrics. https://victoriametrics.com/blog/reducing-costs-p1/index.html #devops #девопс Подпишись 👉 @i_DevOps

DevSecOps #devops #девопс Подпишись 👉 @i_DevOps

Вебинар «Анализ требований и их влияние на архитектуру» ✔️ 16 июня в 20:00 МСК в рамках старта курса «System Design» от Otus. Вебинар будет полезен разработчикам, архитекторам, техническим лидам и системным аналитикам. Узнайте, как требования формируют архитектуру систем и почему их правильная проработка критична для стабильности решений. На вебинаре разберем: ✅ Как эффективно собирать и фиксировать требования ✅ Как требования влияют на архитектуру системы ✅ Как учитывать функциональные и нефункциональные требования при проектировании Мы рассмотрим реальные примеры, которые помогут вам построить более стабильные и надежные приложения. 🚀 Регистрация: https://vk.cc/cMQtq1 А еще, успей воспользоваться 🏷10% скидкой на курс «System Design» и 🎁 бонусным промокодом SD_5 . Выгодные условия действуют с 12 по 15 июня включительно! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира На вебинаре разберём, как крупные компании — такие как Netflix, Amazon и другие — делают свои сервисы доступными для пользователей по всему миру без задержек и сбоев. На вебинаре вы: — Как работают балансировщики и «умные» прокси. — Что такое геораспределение и зачем оно критично для масштабируемых сервисов. — Как грамотно распределять трафик между дата-центрами. — Частые ошибки при проектировании глобальных систем — и как их избежать. 👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMOgUE Бесплатное занятие приурочено к старту курса Highload Architect, обучение на котором позволит освоить решения, которые выдерживают большое количество запросов в секунду и правильно оптимизировать работоспособность серверов. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

«Прогрессивная доставка инфраструктуры с помощью Kargo и Argo CD» – Engin Diri, Pulumi С момента выхода Kargo я изучаю возможность использовать его не только для доставки и продвижения приложений, но и для постепенного развёртывания инфраструктуры. С помощью Kubernetes-ориентированных инструментов, таких как Crossplane или Pulumi, мы описываем инфраструктуру как код и можем плавно развертывать её сначала в наших управляющих кластерах, а затем последовательно продвигать изменения через разные этапы без необходимости в дополнительных скриптах CD. Позвольте показать, как Kargo помогает платформенным инженерам упростить и автоматизировать прогрессивный релиз изменений в инфраструктуре на всех стадиях. В этом докладе будут рассмотрены основы работы с Kargo и примеры интеграции с инструментами Infrastructure as Code. * Описание проблемы: необходимость безопасного и контролируемого релиза изменений в инфраструктуре * Решение: использование Kargo для поэтапного развёртывания (Progressive Delivery) * Инструменты IaC: Crossplane, Pulumi * Преимущества: * автоматизация продвижения конфигурации между окружениями * отказ от «волшебных» CD-скриптов * единый pipeline для приложений и инфраструктуры Настройка Kargo вместе с Argo CD позволяет интегрировать управление приложениями и инфраструктурой в единую платформу progressive delivery, минимизируя риски и ускоряя итерации. источник #devops #девопс Подпишись 👉@i_DevOps

Pipeline инфраструктуры (Infra Pipeline) Этот workflow описывает сквозной CI/CD-pipeline для сборки и деплоя инфраструктуры, включая quality gates (детекторы и оценку рисков). Ветвление (Branching) Рекомендуется создавать короткоживущие feature-ветки (локальные копии основной ветки trunk/main). В них выполняются изолированные изменения. На локальную ветку нет жёстких ограничений, но вы как разработчик обязаны регулярно синхронизировать её с основной (через rebase или merge), чтобы избежать merge conflicts. Основная ветка (mainline/trunk) Mainline (или trunk) служит для сборки и публикации deployable артефактов. Любой merge в неё может автоматически попасть в staging или production. Поэтому ветка должна быть постоянно в deployable-состоянии. Для этого в CI/CD pipeline настраиваются quality gates: статический анализ кода, unit- и интеграционные тесты, security scans, оценка рисков 🔒. Trunk остаётся locked до прохождения всех проверок и подтверждения безопасности изменения. https://medium.com/@tusharmurudkar/devops-infrastructure-pipeline-beab47e7b876 #devops #девопс Подпишись 👉@i_DevOps

Нужно выкатить новую фичу, но нет уверенности, что всё пойдет как надо? А еще… 🔻 Слабый мониторинг или его нет совсем. 🔻 Непонятно, почему система тормозит. 🔻 Клиенты жалуются на ошибки и долгое время ответа. Знакомо? Приглашаем на онлайн-интенсив по Service mesh от Слёрм, на котором вы: 👉 решите реальные бизнес-кейсы; 👉 поймёте принцип работы и в будущем сможете применить знания на любом решении; 👉 научитесь искать причины проблем. Даты проведения: 27-29 июня. Спикеры: – Александр Лукьянченко, руководитель юнита PaaS в Авито – Виталий Лихачев, SRE в крупном голландском тревелтехе – Георг Гаал, CTO AEnix Специальные условия группам от 3-х человек. 👉 Программа и запись на интенсив по ссылке.

Переезд с облака на свои сервера: взгляд со стороны инфраструктуры и бизнеса Привет, коллеги! Сегодня я отойду от прежнего стиля написания статей. До этого момента я писал больше про хард скиллы, но в последнее время я начал расширять свой кругозор и изучать процессы в компании под разными углами, в том числе с точки зрения бизнеса. Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков. https://habr.com/ru/articles/914438/ #devops #девопс Подпишись 👉@i_DevOps

systemd: как писать юниты с элегантной перезагрузкой Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы. Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием. https://www.psdn.io/posts/systemd-shutdown-unit/ #devops #девопс Подпишись 👉@i_DevOps

❕ Приглашаем на урок по работе с чувствительными данными в Kubernetes-кластере! ⏺Открытый урок K8S + Vault — как получать секреты? Бесплатно 17 июня в 20:00 МСК. Урок в рамках старта курса «Инфраструктурная платформа на основе Kubernetes» от Otus. Поймете, как организовать безопасное и масштабируемое взаимодействие между Kubernetes и HashiCorp Vault. Разберём подход dynamic secrets и инструмент External Secrets Operator для интеграции секретов из Vault в кластер. На уроке вы узнаете: - как Kubernetes работает с секретами по умолчанию и его ограничения; - способы интеграции Kubernetes и Vault; - что такое External Secrets Operator и почему его выбирают для production-сред; - пошаговую схему подключения Vault к K8s. ➡️ Регистрация на вебинар: https://vk.cc/cMHhuk Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Почему нельзя парсить вывод ls(1) Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL. Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом). https://habr.com/ru/articles/823298/ #devops #девопс Подпишись 👉@i_DevOps

Bash-совет: анализ неудачных SSH-логинов и бан «горячих» IP 🔒🐚 Хотите быстро узнать, какие IP вызывают максимум неудачных попыток входа в SSH, и оперативно заблокировать самых настырных? Ниже скрипт:

#!/usr/bin/env bash
# ssh_fail_analyzer.sh
# Анализ неудачных SSH-попыток и вывод TOP-10 IP

LOG_FILE="/var/log/auth.log"       # путь к логам (для CentOS: /var/log/secure)
TOPN=10                            # сколько IP показывать

echo "Топ $TOPN IP с неудачными SSH-входами:"
grep -E "Failed password for" "$LOG_FILE" \
  | grep -oP '(?<=from )[\d\.]+' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n "$TOPN"

Как это работает 1. grep -E "Failed password for" Ищем все строки с неудачными попытками. 2. grep -oP '(?<=from )\[\d.]+' С помощью PCRE-регулярки достаём только IP-адреса после слова "from". 3. sort | uniq -c | sort -rn Сортируем, считаем вхождения и выводим в порядке убывания. 4. head -n "\$TOPN" Ограничиваем результат топ-10. 🛠 Можно добавить в crontab ежедневный запуск и автоматическую отправку отчёта на почту или сразу бан «горячих» IP через iptables:

# в crontab: каждый день в 00:10
10 0 * * * /path/to/ssh_fail_analyzer.sh | mail -s "SSH Fail Report" admin@example.com

Или сразу блокировать подозрительные IP, если они превысили порог:

THRESHOLD=50
for ip in $(grep -E "Failed password for" "$LOG_FILE" \
              | grep -oP '(?<=from )[\d\.]+' \
              | sort | uniq -c \
              | awk -v t="$THRESHOLD" '$1 > t {print $2}'); do
  iptables -I INPUT -s "$ip" -j DROP
  echo "$(date): Заблокирован $ip за превышение $THRESHOLD неудачных попыток" >> /var/log/ssh_ban.log
done

👉@bash_srv

Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке Взаимодействие между микросервисами — это больше, чем просто REST или RPC. Это фундамент архитектуры, от которого зависит масштабируемость, надёжность и производительность всей системы. 📌 Что будет на вебинаре: — 5 ключевых стилей взаимодействия микросервисов: REST, gRPC, event-driven, messaging, CQRS; — Сравнение: синхронное vs. асинхронное взаимодействие — плюсы, минусы, типичные ошибки; — Когда использовать брокеры сообщений и какую роль играют очереди; — Советы по построению отказоустойчивых коммуникаций между сервисами; — Как логировать и отслеживать взаимодействия между микросервисами; 👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMHfWt Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

📺 Kubernetes Уроки 1 - Что такое Kubernetes? Запуск локального кластера Kubernetes. Minikube 2 - Запуск Kubernetes кластера на AWS, используя eksctl 3 - Запуск Kubernetes кластера на AWS, используя Terraform 4 - Как использовать kubectl с несколькими Kubernetes кластерами 5 - Как установить Kubernetes Dashboard 6 - Создание объекта Pod. Запуск контейнеров в Kubernetes 7 - Метки, аннотации и пространства имён в Kubernetes 8 - ReplicationController и ReplicaSet в Kubernetes 9 - Deployment в Kubernetes. Стратегии обновления приложенийн 10 - Service в Kubernetes - Часть 1. Type: ClusterIP. Endpoints Всего доступно 49 уроков #devops #девопс Подпишись 👉@i_DevOps

Целостность и безопасность конвейера в DevSecOps Это третий пост из серии глубокого погружения в архитектуру программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как совокупности ориентированных на технологии и автоматизированных процессов. Обязательно ознакомься также с первой и второй частью! На данном этапе мы разобрали, как управлять уже существующими уязвимостями и как предотвращать появление новых. Теперь у нас есть жизненный цикл разработки ПО (SDLC), который обеспечивает создание программного обеспечения, безопасного «с самого начала». Осталось лишь разобраться, как обеспечить исполнение и защиту созданной нами архитектуры. В этой статье мы узнаем, как добавить целостность и безопасность в системы, задействованные в нашем SDLC. Эти процессы должны быть незаметны для наших разработчиков — они просто выступают в роли предохранительных ограждений, гарантируя, что остальная часть архитектуры используется правильно и не подвергается нежелательным вмешательствам. https://blog.gitguardian.com/pipeline-integrity-and-security-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

Безопасность по умолчанию: программное обеспечение в DevSecOps Это второй пост в серии, посвящённой архитектуре программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как набора технологически управляемых автоматизированных процессов. Если вы не читали первый пост, обязательно ознакомьтесь с ним! В этой статье речь пойдёт скорее не о принятии решений, а об опыте разработчиков. Мы узнаем, как снабдить наших инженеров программного обеспечения инструментами, которые позволят им самостоятельно обеспечивать безопасность своего кода, и как поддержать их с помощью автоматизации. Прежде чем приступать, хочу ещё раз озвучить своё основное утверждение по DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения с безопасностью по умолчанию, который даст командам инженерии возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха с помощью контролей и обучения, а также снизим трение и сохраним скорость разработки благодаря технологически управляемой автоматизированной архитектуре DevSecOps.»

https://blog.gitguardian.com/secure-by-design-software-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

Жизненный цикл управления уязвимостями в DevSecOps Это первый пост из серии, которая будет глубоко погружаться в архитектуру программы DevSecOps. Цель этой серии — представить целостный обзор DevSecOps как совокупности технологически управляемых, автоматизированных процессов. Какие инструменты и технологии играют роль в DevSecOps? Как мы можем использовать технологии, чтобы настроить команды разработчиков на успех? Как мы выстраиваем роли и зоны ответственности для обеспечения слаженности, безопасности и скорости? На эти и другие вопросы мы ответим по мере развития серии. Последние три года я в профессиональной роли строил программу DevSecOps в своей компании с нуля. Возможно, отдельные части этой серии не будут напрямую применимы к вашей организации, но её ключевые идеи и общий подход всё равно могут оказаться полезными. Следующее заявление о миссии отражает мой подход к DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения по принципу secure-by-design, который предоставляет командам разработчиков возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха за счёт контроля и обучения, а благодаря технологически ориентированной и автоматизированной архитектуре DevSecOps снизим трение и сохраним высокую скорость работы.»

https://blog.gitguardian.com/vulnerability-management-lifecycle-in-devsecops/ #devops #девопс Подпишись 👉@i_DevOps

❔ Как серверные приложения и микросервисы взаимодействуют через сеть? Хотите научиться подбирать правильные протоколы для вашей системы? Откройте для себя все особенности работы с сетевыми протоколами на открытом уроке курса «System Design». Мы подробно рассмотрим HTTP/2, HTTP/3, gRPC и WebSocket, а также научим выбирать оптимальные технологии для вашего проекта. 🚀 Знание сетевых протоколов — ключ к построению стабильных, быстрых и масштабируемых веб-приложений. Пройдите урок и получите навыки, которые улучшат архитектуру ваших решений. ⏺ Встречаемся 10 июня в 20:00 МСК ➡️ Регистрация уже открыта: https://vk.cc/cMCIx6 Урок проходит в преддверии старта курса «System Design». Участники вебинара получат скидку на курс, плюс дополнительный 🎁 промокод SD_5 до 16.06. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576