Мы используем куки и предполагаем, что вы согласны, если продолжите пользоваться сайтом
Понимаю и согласен
Close
Заявка на обратный звонок
Свяжемся с вами в течение рабочего дня
Нажимая кнопку, вы соглашаетесь на обработку ваших персональных данных согласно нашей политике конфиденциальности.
Инженеры Southbridge реализовали уже более 100 проектов по внедрению эффективных DevOps-инструментов и практик, что позволило нашим клиентам повысить устойчивость инфраструктуры высоконагруженных проектов и добиться стабильности процессов CI/CD.

Кейсы клиентов

Мы хотим рассказать про 5 кейсов наших клиентов, в которых наглядно можно увидеть результат нашей работы по оптимизации процессов CI/CD, развёртке кластеров Kubernetes и внедрению новых технических решений в инфраструктуре клиентов.
Ситуация заказчика: У клиента множество микросервисов, написанных на node.js. Нужен был унифицированный подход к CI/CD для всех приложений. Особенностью проекта является сильно плавающая нагрузка от приложений-обработчиков видео. Для деплоя применялся Docker. Gitlab использовался только для хранения кода. Сборка и деплой проводились вручную. Развертывание происходило на ноды ECS в Amazon. Веб-приложения были расположены на Heroku.
Безопасное и надежное администрирование Linux-серверов

Онлайн видео-конструктор с расширенными возможностями

Цель: Построение CI/CD инфраструктуры в kubernetes-кластере Amazon (EKS).
Подробный кейс и результаты работы
Используемый стек технологий: AWS, EKS, Gitlab (CI, registry, gitlab-runner DinD), Helm v3, Prometheus, Grafana, Mongo Atlas.

Решение: Автоматическое масштабирование приложений обработчиков видео реализовано в зависимости от нагрузки CPU. Предприняты следующие действия:
– кластер развернут с помощью eksctl;
– приложения из ECS, перенесли в EKS (k8s в Amazon);
– веб-приложения на Heroku - перенесли в k8s (экономия финансов);
– gitlab раньше использовался только для хранения кода. Сейчас CI запускается автоматически, образ сохраняется в registry, автоматически развертывается новая версия приложения в кластере;
– разработан унифицированный CI для всех микросервисов через Helm;
– сборка и деплой реализован в режиме DinD. Это имеет ряд преимуществ: дополнительную изоляцию, удобное масштабирование, возможность запускать на spot-нодах;
– убраны окружения, настроенные вручную. Подняты 3 окружения dev, prod, stage управляются автоматически;
– используется 2 зоны доступности, минимально необходимое количество для отказоустойчивости.

Результат:
Быстрый и автоматический деплой приложений в кластер без простоя сервиса. Использование нескольких окружений для тестирования и подготовки приложений. Удобный мониторинг потребления ресурсов и доступности сервисов. Планируется сделать автоматическое масштабирование приложений в зависимости от количества заданий в очереди на обработку.

Ситуация заказчика: Инфраструктура представляла собой нагруженный кластер Kubernetes на 3-х физических нодах (с использованием Ceph в качестве общего хранилища) и некоторое количество экземпляров PostgreSQL (до полутерабайта объёмом), также на 3-х серверах. В кластере Kubernetes посредством GitLab CI было развёрнуто два десятка приложений.
Безопасное и надежное администрирование Linux-серверов

Онлайн-платформа для организации независимого торгового аудита и оценки сервиса

Цель: обеспечения стабильной работы инфраструктуры и оптимизации процессов CI/CD.
Подробный кейс и результаты работы
Возможности платформы:
— формирование данных на основе фотографий, аудио записей и ответов на вопросы по продуктовой категории, которые делают потребители с помощью мобильного приложения;
— обработка данных системой распознавания изображений и модераторами, после которой результаты доступны в онлайн-аналитике;
— интеграция аналитики в мотивационную программу полевого персонала и менеджмента для улучшения торговых показателей.

Присутствовали проблемы:
— скрипты деплоя были написаны на Shell и расположены непосредственно в репозиториях приложений; учитывая, что приложения разрабатываются в некотором кол-ве веток (до 10-20) это делало весьма трудоёмким (и чреватым ошибками) внесение правок в систему деплоя;
— в Deployments не были указаны requests/limits, вследствие чего нагрузка распределялась по нодам весьма неравномерно. Readiness/liveness probes также не указывались, что вызывало необходимость ручного перезапуска контейнеров (подов) с приложениями по любому поводу - от подвисания приложения до рестарта БД;
— автоматического фейловера для postgresql не было, при сбоях master'ов приложения падали, пока администратор вручную не поднимет базу или сервер;
— не производилось резервное копирование PostgreSQL (бэкап предыдущим подрядчиком был настроен на свои мощности и ушёл вместе с ним - остался только быстро растущий архива WAL, съедающий место на дисках);
— автоматический vacuum (или repack) для postgresql не был настроен, из-за чего также постоянно возникали проблемы с заканчивающимся местом на дисках (в несколько баз идёт очень интенсивная запись с профилем, вызывающим bloating);
— redis, являющийся необходимым сервисом для работы приложений (большая часть без него просто не запускается, при отказе redis падает) был развёртнут в k8s как StatefulSet в виде кластера на sentinel и sidecar (представлявшем собой шелл-скрипт иногда отрабатывал непредсказуемо); этот sidecar вхолостую расходовал CPU на нодах и не обеспечивал отказоустойчивости (более того, являлся причиной периодических отказов сервиса redis);
— сетевое взаимодействие между физ. нодами и нодами k8s было настроено с наборами одинаковых IP на linux-bridge и правилами ebtables. Эта схема была создана, очевидно, для обеспечения отказоустойчивости при выходе одного из серверов из строя, но была несколько недоработана и крайне трудоёмка в понимании и поддержке.

Используемый стек технологий: CentOS GNU/Linux, Kubernetes, Gitlab, Ceph, PostgreSQL, Redis, Pacemaker, Ansible.

Решение: Для обеспечения поставленной цели были предприняты следующие действия:
— разработан отказоустойчивый сетап с автофейловером для PostgreSQL на базе Pacemaker с ресурс-агентом pgsql, развернуто несколько трёхнодовых кластеров и на них смигрированы все БД;
— настроена непрерывная архивация PostgreSQL, позволяющая восстановить состояние любой базы на любой момент времени за несколько дней назад;
настроен pg_repack по расписанию для таблиц с выраженным bloating (написан скрипт-обёртка для обхода проблемы незакрытых транзакций и вычисления необходимого дискового пространства);
— развёрнут новый кластер Kubernetes, в него смигрированы все приложения, старый кластер уничтожен;
— для обработки отказов вида "падение ноды с ingress" применена кластеризация Pacemaker с ресурс-агентом kumina-hetzner-ip для управления Hetzner Failover IP;
redis вынесен из k8s, для него разработан фейловер на Pacemaker + HA redis;
— деплой приложений в k8s был полностью переписан на ansible, применены resource requests и limits; также по просьбе разработчиков была применена схема blue-green deploy, позволяющая мгновенно и без простоя переключать трафик со "старого" кода на "новый".

Результат: Стабильность работы приложений значительно выросла, простои по вине инфраструктуры значительно сократились (пока не в 0, но мы продолжаем поиски решения комплексных проблем, связанных с растущей нагрузкой от приложений), трудоёмкость обслуживания уменьшилась в десятки раз (в основном, всё "просто работает").
Инфраструктура активно развивается, были развернуты новые экземпляры приложений и баз в других локациях (и планируется ещё).

Ситуация заказчика: Кластер заказчика пришел к нам в неработоспособном состоянии. Не стартовали поды, отсутствовали данные в кластере ElasticSearch.
Безопасное и надежное администрирование Linux-серверов

Платформа объединяет в себе сервис для заказа, доставки еды и онлайн-академию рестораторов

Цель: Возвращение работоспособности кластера, поддержка 24/7.
Подробный кейс и результаты работы
Используемый стек технологий: Gitlab, Kubernetes, Helm, Kafka, Hazelcast, Elasticsearch, Cassandra, Ceph, Prometheus, Grafana, Clickhouse, Minio, KVM.

Решение: Проведен аудит серверов и выполнен пул следующих работ:
– когда серверы и кластер k8s был запущен, оказалось что в кластере elasticsearch на одном из трех узлов отсутствовали данные. В настройках узла elasticsearch не был убран параметр: "cluster.initial_master_nodes: elastic-0". В результате узел не мог добавиться в существующий кластер, и создавал новый из одного узла. Опцию убрали, и узел успешно присоединился к кластеру.
– появилась задача ручного управления кластерами Hazelcast. Развернут managment-center, интегрирован в кластер. Он предоставляет веб-интерфейс для ручного управления кластером. Работы успешно проведены.
– не запускалась Kafka. Причина была в исчерпании места на PV в кластере. Место добавили.
– некоторые приложения в окружениях dev и prod использовали единый кластер Kafka. Внесены изменения в helm-чарты для разделения окружений.
– по просьбе клиента был заполнен индекс в elasticsearch на основании данных из cassandra. Типы данных и структура индекса приведены к необходимым для приложения.

Результат: В рамках разовых работ сервера и кластер приведены в работоспособное состояние. Данные в кластере Hazelcast успешно восстановлены. В рамках поддержки произведены следующие дополнительные работы:- по просьбе клиента часто приходилось вручную редактировать данные в кластере cassandra, вносить изменения в схему. Поэтому было принято решение реализовать ежедневный бэкап кластеров cassandra на удаленный сервер. Восстановление данных из бэкапа cassandra уже использовалось при откате на предыдущую версию в dev-окружении.- клиентом было разработано приложение на Flask, которое позволяет удобно проводить обслуживание внутренних данных основного приложения через веб-интерфейс. Для приложения написан helm-chart, настроен CI без использования werf. Персистентные данные приложения хранятся в ceph rbd.

Еще больше подробностей в блоге
Ситуация заказчика: У клиента микросервисы, написанные на ruby, sidekiq в качестве брокера сообщений. CI/CD осуществлялся с помощью ansible, в CI/CD использовалось огромное количество самописных скриптов, таким образом процесс завязывался на одном инженере. Был кластер кубернетиса, но из-за неверно выбранной архитектуры поды оказались прибиты к определенным нодам (у haproxy в качестве бэкенда указывались конкретные Ip и порты)
Безопасное и надежное администрирование Linux-серверов

Инструмент для интеграции, анализа и улучшения покупок внутри iOS приложений

Цель: обеспечения стабильной работы инфраструктуры и оптимизации процессов CI/CD.
Подробный кейс и результаты работы
Используемый стек технологий: Gitlab (CI, registry, gitlab-runner), Helm v3, Prometheus, Grafana, PostgreSQL, EFK, Kubernetes, Redis, Kafka, Clickhouse

Решение:
— развернут новый кластер k8s,
— создана репликация master-slave PostgreSQL,
— разработан унифицированный CI для всех микросервисов через Helm,
— добавлены окружения для тестирования,
— дополнительно на серверах вне кластеры были подняты apache Kafka и Clickhouse (необходимо для работы приложения).

Результат: Построен отказоустойчивый кластер с системой мониторинга и логирования. Доступность инфраструктуры вышла на уровень 99.95%, а небольшая доля простоев не связана с проблемами инфраструктуры. Из-за унифицированного CI клиенту стало возможным управлять им самостоятельно без привлечения инженеров, на базе этого CI позже были добавлены другие проекты. В дальнейших планах, при росте нагрузке, настроить масштабирование приложения.
Ситуация заказчика: Рекламная сеть HProfits обрабатывает большой объём трафика, что создаёт высокую нагрузку на инфраструктуру. При этом состояние Kubernetes-кластера не отвечало требованиям отказоустойчивости, не было уверенности в текущей инсталляции, процедура обновления была непрозрачной, при деплое возникали ошибки.
Безопасное и надежное администрирование Linux-серверов

Рекламная сеть

Цель: Повысить быстродействие и отказоустойчивость инфраструктуры и внедрить новые практики CI/CD.
Подробный кейс и результаты работы
Используемый стек технологий:
Gitlab (CI, registry, gitlab-runner), Kubernetes, Helm v3, Prometheus, Grafana, Kafka, Aerospike, Clickhouse.

Решение:
— развернуть новую версию Kubernetes-кластера,
— создать новые процессы CI/CD,
— оптимизировать обработку метрик.

Результат:

— повысили отказоустойчивость кластера Kafka,
— оптимизировали хранение и обработку метрик, пересмотрели подход к алёртингу,
— доработали CI/CD, внедрили канареечный деплой,
— обеспечили надёжность хранения персистентных служебных данных.

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

Компания, у которой выстроен бизнес-процесс на высшем уровне...
1. Постоянный и не текучий штат профессионалов. 2. Молниеносное время реакции и при аварии и при плановой профилактике…
Роман Валухов
Полный отзыв в Google
Артём Султанов
Полный отзыв в Google
«Над любой задачей работает не один сотрудник, а команда, поэтому сервер всегда работает безупречно. Отличный сервис!»

Журнал AstroMeridian
Полный отзыв в Google
«Поддерживать бесперебойную работу серверов очень важно для нашего бизнеса и эта задача успешно решена, за что спасибо Southbridge!»

Кирилл Житников
Полный отзыв в Google
«Все задачи решаются, предлагаются разные варианты, мнение клиента всегда учитывается»

РОС РИЭЛТ
Полный отзыв в Google
«Отличные ребята, знают свое дело. Настройка и тюнинг серверов любого уровня, рекомендую»

Тарас Перцович
Полный отзыв в Google
«Команда Southbridge сделала все по уму, с Kubernetes, автоскейлом, настроили CI через Гитлаб»

Сергей Бабочкин
Полный отзыв в Google
«Работаем с Southbridge более 7 лет и все проекты, которые ведем, стараемся перевести на поддержку именно к этой команде»

Егор Рыболовлев
Полный отзыв в Google
Наши клиенты рекомендуют Southbridge и мы благодарны им за это. В качестве благодарности мы выплачиваем бонус за новых клиентов. Приглашайте своих коллег, партнеров и друзей работать с нами и в течение 6 месяцев мы будем возвращать на ваш счёт 10% от платежей новых клиентов, пришедших по вашей рекомендации.
Партнёрская программа
Заявка на администрирование серверов
Мы также всегда готовы проконсультировать вас по телефону +7 495 665-50-27 или по электронной почте ask@southbridge.io

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

Свяжемся с вами в течение рабочего дня