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

Оповещение об аномалиях в Prometheus

Изучаем, как настраивать оповещения об аномалиях для сезонных данных в Prometheus.

В Auto Trader мы стремимся создавать оповещения, которые большинство сможет использовать «из коробки», а не жестко прописывать их под конкретные сценарии. Мы хотим, чтобы вы могли развернуть сервис и сразу получить отдачу от платформы — особенно когда речь идет об отслеживании и оповещениях по вашим «Golden Signals» или управлении затратами.

https://bookflow.ru/opoveshhenie-ob-anomaliyah-v-prometheus/

#devops #девопс

Подпишись 👉@i_DevOps

Полное руководство по Docker Secrets

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

https://earthly.dev/blog/docker-secrets/

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD на GitHub Actions и GitLab CI для самых маленьких. Часть 3

Как запускать пайплайн только для нужных веток, хранить секреты в безопасности и управлять окружениями — просто, наглядно, с примерами. Если вы уже настроили первый workflow — самое время сделать его умнее 🚀

Если вы дошли до этой части в серии, то вы уже знакомы с базовыми принципами CI/CD и даже настроили свой первый простой пайплайн. Поздравляю! Вы сделали важный шаг в мир автоматизации разработки. Но как и в программировании, где после "Hello World" начинается настоящее обучение, в CI/CD после базовой настройки открывается целый мир возможностей.

Часть 1 https://t.me/i_DevOps/2948
Часть 2 https://t.me/i_DevOps/2950

https://habr.com/ru/articles/915370/

#devops #девопс

Подпишись 👉@i_DevOps

Маленькая утилита для контроля квот в Yandex Cloud

Yandex Cloud использует квоты для мягкого контроля ресурсов. Квоты можно легко увеличить через специальную форму или техническую поддержку. Однако, очень часто бывает, что о необходимости увеличить квоты мы узнаем поздно, например, когда падает джоба с terraform. Это раздражает, а в некоторых случаях даже может сломать стейт и принести ненужные проблемы.

https://habr.com/ru/articles/915606/

#devops #девопс

Подпишись 👉@i_DevOps

Tetragon обеспечивает мощную возможность наблюдения за безопасностью в режиме реального времени на базе eBPF и принудительное исполнение политик во время выполнения.

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

https://github.com/cilium/tetragon

#devops #девопс

Подпишись 👉@i_DevOps

⚙️Автоматизация отслеживания релизов развертывания с помощью Python, Docker и интеграции с Confluence Wiki.

💡Почему стоит автоматизировать документацию релизов?

Ручное обновление заметок о релизах или журналов может быть утомительным и склонным к ошибкам. Автоматизировав этот процесс, можно добиться нескольких ключевых преимуществ:

➡️Последовательность: каждый выпуск документируется одинаково, уменьшая количество ошибок и обеспечивая запись всей релевантной информации.
➡️Экономия времени: разработчики и команды DevOps могут сосредоточиться на кодировании и улучшении приложения вместо обновления заметок о релизах.
➡️Сотрудничество: централизованный журнал выпусков в Confluence упрощает доступ команд к деталям развертывания и их обмен.
➡️Отслеживаемость: автоматическое отслеживание развертываний позволяет легко прослеживать историю версий, что помогает при устранении неполадок или откатах.
➡️Готовность к аудиту: поскольку все развертывания зафиксированы в Confluence, процесс становится готовым к аудиту, обеспечивая соблюдение требований в любое время.

https://medium.com/@pranshu.jain_77905/automating-deployment-release-tracking-with-python-docker-and-confluence-wiki-integration-254cfd9d76fb

#devops #девопс

Подпишись 👉@i_DevOps

🧵Понимание probes в Kubernetes

1/ Что такое probes в Kubernetes?

В Kubernetes probes используются для проверки состояния ваших контейнеров приложений.

Существует три типа:

* Liveness Probe (Проверка живости)
* Readiness Probe (Проверка готовности)
* Startup Probe (Проверка запуска)

Давайте разберёмся на аналогии с рестораном. 🧵👇

2/ Представьте ваше приложение как кухню в ресторане.

* Клиенты = Входящий трафик
* Шеф-повар = Контейнер приложения
* Официант = Kubernetes

Официанту (K8s) нужно понять:

* Жив ли шеф? (Liveness)
* Готов ли шеф принимать заказы? (Readiness)
* Завершил ли шеф подготовку? (Startup)

3/ 🍳 Liveness Probe = Жив ли шеф?

Эта проверка смотрит, функционирует ли кухня (приложение) вообще.

Если шеф теряет сознание или исчезает, официант (K8s) перезапустит кухню (контейнер).

4/ 🛎️ Readiness Probe = Готов ли шеф готовить?

Возможно, шеф проснулся, но ещё нарезает ингредиенты.

Пока шеф не готов, официант не должен принимать заказы (направлять трафик).
Если проверка не проходит, Kubernetes исключит под из балансировщика нагрузки.

5/ 🕐 Startup Probe = Завершил ли шеф настройку?

Некоторым шефам нужно больше времени, чтобы подготовиться.
Startup Probe даёт им дополнительное время перед началом остальных проверок.
Если эта проверка не проходит, K8s убьёт под, полагая, что он застрял. Полезно для медленно стартующих приложений!

6/ Итого 🧠

* Startup Probe: Приложение завершило запуск?
* Liveness Probe: Приложение всё ещё работает?
* Readiness Probe: Приложение готово обрабатывать трафик?

Используйте все три, чтобы сделать ваши развертывания в K8s максимально надёжными. 💪

#devops #девопс

Подпишись 👉@i_DevOps

🧅 Onionpipe

Перенаправляет порты на локальном хосте на удаленные Onion-адреса как скрытые сервисы Tor и наоборот.

https://github.com/cmars/onionpipe

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD на GitHub Actions и GitLab CI для самых маленьких. Часть 2

Настройка GitHub Actions и GitLab CI – первый workflow и деплой

В первой статье мы разобрались с основами CI/CD: что это такое, зачем нужно и какие инструменты существуют. Теперь пришло время перейти от теории к практике – создадим наши первые рабочие CI/CD-конвейеры на GitHub Actions и GitLab CI.

https://habr.com/ru/articles/914614/

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD на GitHub Actions и GitLab CI для самых маленьких. Часть 1

Основы CI/CD – что это и зачем нужно; обзор GitHub Actions и GitLab CI

В последние годы вы, вероятно, слышали слова "DevOps", "CI", "CD", возможно, даже "GitHub Actions" или "GitLab CI". Но что это всё значит на практике? Нужно ли быть сеньором DevOps-инженером, чтобы с этим разобраться?

https://habr.com/ru/articles/914560/

#devops #девопс

Подпишись 👉@i_DevOps

Профилировщик памяти для Linux

Heaptrack отслеживает все выделения памяти и аннотирует эти события с помощью трассировки стека. Специальные инструменты анализа позволяют интерпретировать профиль памяти кучи, чтобы:

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

https://github.com/KDE/heaptrack

#devops #девопс

Подпишись 👉@i_DevOps

(Почти) каждое инфраструктурное решение, которое я одобряю или о котором жалею после четырёх лет управления инфраструктурой в стартапе

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

https://cep.dev/posts/every-infrastructure-decision-i-endorse-or-regret-after-4-years-running-infrastructure-at-a-startup/

#devops #девопс

Подпишись 👉@i_DevOps

HolmesGPT — опенсорсный DevOps-ассистент

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

Что может HolmesGPT?

👉 Расследует инциденты (AIOps) с помощью PagerDuty/OpsGenie/Prometheus/Jira
👉 Автоматизированная сортировка: отмечайте важные предупреждения и устанавливайте их приоритетность, чтобы ваша команда могла их рассмотреть
👉 Расширение возможностей оповещений: автоматическое добавление контекста к оповещениям, таким как журналы и информация о работоспособности микросервисов, для более быстрого поиска первопричин
👉 Выявляйте проблемы с облаком, задавая вопросы HolmesGPT о неработоспособности инфраструктуры
👉 Автоматизация Runbook простым языком: ускорьте решение известных проблем, проводя расследование в соответствии с предоставленными вами runbook.

https://github.com/robusta-dev/holmesgpt

#devops #девопс

Подпишись 👉@i_DevOps