Методология разработки программного обеспечения
Однажды к нам пришёл клиент с просьбой настроить approve rules для merge request в бесплатной версии GitLab CE. В статье я подробно расскажу, как мы подошли к решению этой задачи, какие проблемы нам пришлось преодолеть и каким образом мы смогли обеспечить соблюдение всех необходимых процессов проверки и апрувов без перехода на платную версию GitLab.
Недавно мне довелось обновлять старую FreeIPA в большой компании. Эта FreeIPA была установлена в LXC-контейнере на CentOS 7 и находилась в нерабочем состоянии уже несколько месяцев. Мне передали бэкап LXC-контейнера для Proxmox, и я взялся за дело.
Привет, Хабр!
В этом статье рассказываем, как устроена low и no-code автоматизация в Monq и как с ее помощью можно оптимизировать обработку данных высоконагруженных систем. В центре внимания – «работяги» – обработчики автоматизации. На конкретных примерах показываем, какие опции использовать, чтобы нагрузка между ними распределялась равномерно.
Привет, всем! Мы продолжаем наш цикл статей про CI/CD Kubernetes платформу Gitorion. На очереди освещение шагов по построению платформы в Highly Available исполнении. Поскольку все компоненты платформы и пользовательские приложения запускаются в Kubernetes, начнем c построения Highly Avalable кластера Kubernetes. В статье разберем особенности штатной базы данных Kubernetes etcd, не позволившие избежать избыточности. Рассмотрим способ заменить etcd на SQL-базу с помощью Kine от проекта K3S и построить кластер Kubernetes высокой доступности на два дата центра, способный пережить падение любого из них.
Упаковали свой опыт развертывания системы мониторинга транспортного потока — Smart Traffic System — на Rockchip и SOPHON в один стройный R&D пайплайн. Пошагово, со сроками. Как от сердца отрываем.
Сохраняйте, чтобы под рукой иметь план на случай, если задумаете исследовать возможность развертывания системы видеоаналитики на целевом устройстве.
Пока все повально занимаются внедрением ML в SecOps, мы пошли дальше и стали внедрять SecOps в ML. Я Светлана Газизова, работаю в Positive Technologies директором по построению процессов DevSecOps. Кстати, мы знакомы, если вы читали мою статью о том, кто такие специалисты по безопасной разработке и где на них учиться.
Привет! Меня зовут Лев, я руководитель интеграционной разработки в финансовом маркетплейсе Банки.ру.
Больше года назад мы начали переход на микросервисную архитектуру. Секретов становилось всё больше: пароли, токены, сертификаты, ключи. А управлять ими было всё сложнее. Количество команд давно перевалило за несколько десятков, а интеграций с партнерами, которые также защищены секретами, — за сотню.
Перед нами появилась задача выстроить удобную и безопасную структуру хранения и управления секретами. В этой статье поделюсь нашим опытом и расскажу:
1. В чем заключалась проблема в управлении секретами, как мы её решили и как могли бы улучшить этот процесс.
2. Какие способы хранения секретов существуют и как их можно интегрировать.
3. Как можно реализовать хранение через Vault.
4. Что такое политики доступа и как они применяются к структурам секретов.
5. Варианты реализации, которые наилучшим образом подходят для нашей конкретной ситуации.
В июле 2024 вышла версия Kubernetes 1.31, в которой были окончательно устранены встроенные интеграции облачных провайдеров.
Начиная с версии Kubernetes v1.7, проект Kubernetes преследовал амбициозную цель удаления встроенных интеграций облачных провайдеров. Хотя эти интеграции сыграли важную роль в раннем развитии и росте Kubernetes, их удаление было обусловлено двумя ключевыми факторами: растущей сложностью поддержания собственной поддержки для каждого облачного провайдера в миллионах строк кода Go и желанием сделать Kubernetes по-настоящему независимой от поставщика платформой.
После многих релизов, все интеграции облачных провайдеров были успешно перенесены из основного репозитория Kubernetes во внешние плагины. В дополнение к достижению первоначальных целей, удалось значительно оптимизировать Kubernetes, удалив около 1,5 миллионов строк кода и уменьшив двоичные размеры основных компонентов примерно на 40%.
Эта миграция была сложной и длительной из-за многочисленных затронутых компонентов и критических путей кода, которые полагались на встроенные интеграции для пяти первоначальных поставщиков облачных услуг: Google Cloud, AWS, Azure, OpenStack и vSphere. Для успешного завершения этой миграции пришлось построить четыре новые подсистемы с нуля:
MD (Multiple Device) — это технология в Linux, которая позволяет объединять несколько физических дисков в один логический накопитель с помощью различных схем RAID (Redundant Array of Independent Disks). mdXXX (далее md disk) — это одино из устройств, созданных с использованием этой технологии. Для определения влияния проверки состояния (checking) массива md disk на производительность системы необходимо рассмотреть несколько аспектов.
Продолжим наше знакомство с Apache Flink, углубленно проанализировав управление памятью и производительности. После обзора основных концепций в первой части, рассмотрим практические аспекты, которые играют ключевую роль в эффективности и стабильности работы систем.
Вы поймёте, как можно улучшить и оптимизировать работу с Apache Flink. В частности, мы разберём важную концепцию водяных знаков (watermark), которая играет ключевую роль в обработке потоковых данных с временными метками.
CI/CD помогает разработчикам сократить затраты на развертывание и настройку проектов, позволяя им сконцентрироваться на решении бизнес-задач. Gitlab — чрезвычайно мощная платформа, и мы рекомендуем присмотреться к использованию средств CI/CD, которые она представляет.
В этой статье мы рассмотрели один из самых простых сценариев использования Gitlab CI.
Запускать Wasm-приложения в ванильном Kubernetes затруднительно, так как есть неудобства в настройке сред выполнения на рабочих узлах. Штатных средств недостаточно, чтобы легко конфигурировать узлы. Конечно, можно сконфигурировать один узел руками. Но если нужно обкатать различные рантаймы или большое количество приложений, то хочется максимально просто масштабировать кластер и управлять узлами декларативно. Поэтому я решил запустить Wasm-приложение в Deckhouse Kubernetes Platform (DKP). Эта платформа упрощает развёртывание и управление кластерами Kubernetes.
В этой статье я покажу, как запускать Wasm-приложения в Kubernetes с использованием DKP. Мы настроим окружение, установим необходимые компоненты и запустим простой WebAssembly-модуль.
Сейчас мы расскажем вам историю. Историю о том, как мы разработали API и решили написать на него E2E-тесты. Тесты были простыми, описывали и проверяли функциональность API, но оказались мудрёные в плане запуска. Но обо всём по порядку.
В этой статье рассмотрим решение к которому пришли на примере простой Docker Compose конфигурации.
Будучи DevOps-инженером и работая с масштабируемыми облачными решениями, мне часто приходится глубоко погружаться в механизмы работы потоковых платформ. Трудно переоценить важность подробного изучения архитектуры и оптимизации обработки данных, когда речь идёт о системах вроде Apache Flink. Эта технология стала неотъемлемой частью моего инструментария благодаря её возможностям по реализации потоковых приложений.
Мы рассмотрим ключевые аспекты функционирования Apache Flink, от распределённой обработки данных до обеспечения надёжности системы в условиях возможных сбоев. Все эти элементы лежат в основе производительности и масштабируемости приложений, работающих с потоками данных.
Ещё мы подробно рассмотрим использование Apache Flink в задачах, где требуется высокая скорость обработки и точность управления данными. Особое внимание уделим изучению архитектурных основ и методов разработки высокоэффективных потоковых систем.
Материал объёмный, и поэтому я разделил его на две части. Запаситесь чаем и печеньками =)
Для выполнения похожих задач в Docker нередко есть несколько решений. Одна запутанная область касается инструкций RUN, CMD и ENTRYPOINT Dockerfile. В этом переводе обсуждаются различия между этими инструкциями и показываются примеры их использования в форматах shell и exec.
Заводим кворум без фундаментальщины и теории 🤷♂️ (думаю, что по этому поводу статей хватает). Разбираем helm bitnami/rabbitmq-cluster-operator (чуть-чуть).
Есть множество путей развернуть свой Kubernetes. Все они разные, выбор зависит от вашего бюджета, от того, какие задачи вы планируете решать, для каких нагрузок и что в конечном итоге вы планируете получить. В этой статье мы быстро пройдёмся по различным способам инсталляции, а затем попробуем развернуть свой K8s кластер на виртуальных машинах, воспользовавшись гипервизором второго типа (VirtualBox). Но это будет не условная Ubuntu, на которую мы будем ставить необходимые компоненты, а целая операционная система, разработанная специально для Kubernetes — Talos Linux!
В этой статье рассмотрим процесс развертывания инфраструктуры в Yandex Cloud с использованием Terraform-модулей из репозитория nixys/nxs-marketplace-terraform. А ещё расскажем, зачем использовать динамические блоки в Terraform и почему файлы tfstate лучше хранить в S3.
