Третья статья цикла по асинхронному 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, фреймворка тестирования и прочих инструментов с примерами.
Привет, Хабр! Расскажу про единый деплой для всех приложений в кластер K8s и поделюсь, как нам удаётся жить без OPA rules и не допускать дичи некорректных манифестов в кластере.
Привет, на связи Олег Казаков из Spectr. Сегодня мы разберем тему параметризованных сборок в GitLab и чем они могут быть полезны.
Доброго дня, уважаемые!
Идём по плану и сегодня делаем обзор требований регуляторов к практикам разработки безопасного ПО (РБПО) для отраслей, относящихся к критической информационной инфраструктуре. Такой регуляторики немного, пройдемся быстро.
В предыдущих статьях я рассказывал как мы перешли на vector.dev с Elastic для обработки логов и как мы теперь считаем метрики по логам с его помощью.
В этой статье я расскажу вам о нашем опыте стандартизации логов. Какие проблемы были, зачем мы это сделали и что нам это дало, как команде и компании.
TL;DR:
Нам помогли наработки по Vector.dev, договоренность с разработчиками и обнаруженная OpenTelemetry Logs Data Model. В итоге это все скомпоновалось в решение которое существенно упростило нам жизнь.
В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?
Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.
Автоматизация деплоя React-приложения на VPS с Jenkins и Nginx: настройка вебхуков GitHub и триггеров для запуска деплоя при каждом изменении в коде.
Скорость сборки Docker-образов играет важную роль в CI/CD, особенно для микросервисов, где частые обновления и тестирования требуют быстрой доставки изменений.
Одним из решений для оптимизации сборок является Docker Buildx — расширение к стандартной команде docker build. Docker Buildx предлагает дополнительные возможности, такие как кэширование слоев образов, что помогает значительно сократить время сборки за счет повторного использования неизменных слоев. В отличие от стандартного процесса сборки, Docker Buildx предоставляет более гибкое управление кэшем, поддерживает мультиархитектурные сборки и работу с несколькими платформами.
В этой статье мы сосредоточимся на том, как эффективно настроить и использовать кэширование с Docker Buildx в CI/CD пайплайнах на GitLab. Мы рассмотрим примеры, когда кэширование позволяет ускорить сборку, и ситуации, когда его лучше отключить для гарантии корректности итогового образа.
Проблема наблюдаемости (observability) возникает во всех организациях. Я помогу вам научиться не на своих, а на моих ошибках, подскажу, как обойти грабли и подводные камни. Здесь вы найдёте подборку антипаттернов, которая поможет избежать проблем в будущем.
Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.
Перевели статью и наглядную инфографику управляющего директора Learnk8s Daniele Polencic о корректном завершении работы подов в Kubernetes. В тексте много примеров и иллюстраций, которые помогут начинающим разобраться, как предотвратить разрыв соединений при запуске или остановке пода. В том числе для долгоживущих соединений и задач.
