DevOps *

Kubernetes сейчас массово используют в ЦОДах и облачных решениях. Какие заслуги у Кубера, что было до него и почему сейчас он едва ли не стандарт отрасли. А ещё, как понять, что Кубер вам ни к чему.

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

Привет! Хочу поделиться, как я с KeyCloak-ом сражался.

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

Шаблоны проектирования распределенных систем предоставляют разработчикам проверенные решения и передовые методы проектирования и внедрения распределенных приложений.

Узнайте о ключевых изменениях в Deckhouse Kubernetes Platform за последние четыре релиза. Внедрение Grafana 10, поддержка Windows для Deckhouse CLI, автоматическая изоляция проблемных узлов с помощью Fencing, отказоустойчивый egress gateway и другие изменения, которые помогут улучшить управление кластерами.

Я кратко познакомлю с инструментом шифрования age (кратко - потому что он простой в использовании - там просто нечего долго объяснять, при этом шифрует по современным стандартам шифрования). Мы научимся в одну простую команду шифровать как личные бэкапы, так и корпоративные (для нескольких асимметричных ключей, не храня ключ на сервере), а затем поспорим на тему того, почему openssl такой плохой инструмент и не пригоден для практического применения обычными пользователями/админами, чье представление о криптоалгоритмах примерно выражено на КДПВ.

Существует множество мифов о поколении Z и о том, как они используют технологии. Пришло время взглянуть на реальные модели поведения, которые выходят за рамки активного использования социальных сетей. Каждое поколение по-своему уникально, у него свои привычки, взгляды, стандарты и ожидания. Так что же нужно учитывать при разработке дизайна для поколения Z? Давайте поближе познакомимся с поколением Z, с тем, как они используют технологии, и с тем, почему, возможно, стоит игнорировать распространённые советы по дизайну и делать противоположное тому, что обычно рекомендуется.

Привет, Хабр! Меня зовут Станислав Савостин, в СберТехе я занимаюсь системой мониторинга «Маяк». Это наш внутренний сервис, который основан на Prometheus, но включает много доработок и «тюнинга» под наши условия и стандарты работы.

Основная задача мониторинга — быстро выявить проблему (до того, как что‑то упало) и отреагировать, чтобы пользователи не заметили. Из‑за высокого темпа уведомлений и реакций часто возникает риск пойти по неправильному сценарию. Например, перезагрузка брокера Kafka или Artemis занимает около 30 секунд, поэтому упустить такую ситуацию легко, хотя для нас это критически важная метрика. Ложная тревога или задержка передачи метрик — максимально неприятные события, так что мы постоянно дорабатываем систему и уже научились отслеживать перезагрузки сервисов.

Я расскажу, как мы дорабатывали мониторинг, как реагируем на действительно опасные ситуации и что помогает нам ловить дзен, когда все кричат: «Волк!»

Гоняем тесты кода на T-SQL в сборке каждого пулл-реквеста, собираем Coverage, проходим Quality Gate. Особенности построения CI-пайплайна для проектов БД MS SQL Server.

Третья статья цикла по асинхронному SQLAlchemy 2 посвящена оптимизации кода, обновлению и удалению данных. Рассмотрены улучшения базового класса, подходы к обновлению записей и методы удаления, с акцентом на повышение производительности. Нажмите «Читать», чтобы ознакомиться с материалом.

Компании, что используют Jenkins в качестве CI/CD‑инструмента, обычно делают несколько экземпляров, если в разработке участвует множество команд или приходится работать с большим количеством проектов. При этом оркестрация Jenkins»ов в командах — не самая простая работа, а во многом ещё и рутинная. С одной стороны, сложно соблюдать все требования сборки и тестирования и вовремя находить согласующих. С другой, одним скриптом невозможно решить всю задачу от получения доступов до вывода релизов в эксплуатацию.

Есть правило, что если система становится слишком сложной, то люди чаще ищут способы обойти алгоритмы, а не следовать им. Чтобы не усложнять систему, а разложить всё по ролям и этапам, мы пришли к созданию собственного инструмента — Orchestra R. С его помощью мы хотели не только автоматизировать работу конвейера CI/CD, но и упростить жизнь всех DevOps‑инженеров. В этом материале поделимся особенностями работы инструмента и опытом эксплуатации в СберТехе.

Привет, меня зовут Всеволод, я разработчик в Yandex Infrastructure — команде, которая создаёт платформу для разработчиков Яндекса. Последние 12 лет я занимаюсь внутренним облаком и за это время писал самые разные его компоненты: от базовой инфраструктуры хостов и до Control Plane.

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

При развертывании пары десятков контейнеров в Podman в rootless-режиме мы внезапно обнаружили, что они не могут одновременно использовать одни и те же порты, как это обычно работает при использовании Docker.

Решений несколько, но в рамках наложенных ограничений стандартные варианты не подходили. В итоге мы обратились к функционалу Podman Kube, который помог нам решить эту проблему. Подробнее о том, как это работает, и чем может быть полезно, ниже.

Руководитель направления безопасной разработки и инфраструктуры делится мнением об обеспечении безопасности разрабатываемых продуктов.

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

Потребность в разработке безопасных продуктов с каждым годом только возрастает. Востребованность продуктов, для которых «из коробки» обеспечивается необходимый уровень безопасности, крайне высока. Но что с возможностями и готовностью рынка?

Меня зовут Максим Набоких, и я один их тех, кто участвовал в разработке Structured Authentication Config. Это крупнейшее изменение в системе аутентификации в Kubernetes за последние годы, которое появилось в версии 1.29. В статье я расскажу о предпосылках появления нового аутентификатора и покажу сценарии, в которых он полезен.

Привет! Меня зовут Игорь Латкин, я управляющий партнер и системный архитектор в KTS. Сегодня расскажу, как мы в компании выстраивали процессы деплоя приложений так, чтобы разработчики могли делать это самостоятельно. 

Поделюсь, как мы формируем регламенты в KTS и на каких «трёх китах» стоит инфраструктура глазами разработчика. Статья написана по мотивам моего доклада на kuberconf.io.

Привет, Хабр! На связи команда безопасности Платформы в лице её тимлида Букина Владимира. Основная задача нашей команды — защита CI/CD и, в частности, GitLab с K8s. Дальше я расскажу вам о том, как мы внедряли, поддерживаем и улучшаем наш плагин авторизации для Docker socket.

Так сложилось в нашей индустрии, что ИБ всегда догоняет технологии, которые внедрили в IT. При внедрении технологии всплывают всевозможные риски, о которых не успели подумать при разработке. Для мира ИБ Docker и K8s — ещё совсем свежие технологии. Исследований не так много. Всё ещё куча уязвимостей (в том числе и необнаруженных), и поэтому поработать с ними особенно интересно.

В статье хочу рассказать о том, как мы сделали наши CI/CD-процессы более безопасными: в частности, про shared Docker executor и использование Open Policy Agent (OPA). Поделюсь нашими правилами для ОРА-плагина, которые можно переиспользовать в любой компании для того, чтобы обезопасить ваши контейнеры.

Статья будет особенно полезна инженерам ИБ, DevOps-инженерам, архитекторам и СТО, но и разработчики найдут для себя что-то интересное, я уверен.
Погнали!

Мы значительно сократили время деплоя: раньше деплой готового или даже частично готового приложения мог занимать от одного дня до недели в зависимости от загрузки команды DevOps. Сейчас этот процесс занимает у разработчика около 30 минут. Конечно, у разработчиков всё ещё возникают мелкие проблемы, такие как опечатки, но это уже не критично.

Мы также разгрузили DevOps-команду: теперь разработчики самостоятельно деплоят свои приложения в dev и staging окружения, а деплой в production проходит через ревью-процесс. Этот подход хорошо зарекомендовал себя на практике. Самое важное — разработчики теперь понимают не только то, как писать код, но и что именно они деплоят и куда.

Построение процесса разработки скриптов на Powershell с линтингом, тестами и Quality Gate. Выбор IDE, фреймворка тестирования и прочих инструментов с примерами.