Продолжая использовать сайт, вы соглашаетесь с нашими Политика cookie. Чтобы узнать больше о том, как мы обрабатываем ваши персональные данные, прочитайте нашу Политика конфиденциальности.
Я принимаю cookie
Нет

Дата публикации: 01/06/2023

Многие заказчики с приходом облачных сервисов продолжают разворачивать и поддерживать собственные решения. В некоторых случаях это обусловлено требованиями к безопасности, а в некоторых с целью экономии денежных средств. На первый взгляд может показаться, что поддерживать собственные решения не так сложно, например, один из наших заказчиков решил реализовать собственный кластер узлов NGINX для балансировки нагрузки на кластер с бэкендом.

Кластер серверов NGINX показался для заказчика простым в конфигурации решением, однако с увеличением загрузки NGINX терял возможность обрабатывать трафик. При изучении лог-журнала обнаружилась очевидная причина: не хватало свободных worker_connections, что привело к сбросу пакетов. Но что всех удивляло, так это то, что кол-во worker_connections * кол-во worker процессов было в 4 раза больше количества запросов клиентов, что должно быть очевидно достаточно.

На этом этапе заказчик обратился к нашей компании для диагностики данной проблемы. В ходе диагностики мы обнаружили, что NGINX имеет архитектурные особенности, из-за которых распределение запросов пользователей между worker процессами происходит неравномерно. По этой причине на одном из worker процессов из-за бОльшей нагрузки и истощался резерв worker_connections.

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

Дата публикации: 23/05/2023

Проект: Рефакторинг инфраструктуры Kubernetes для повышения доступности, поддерживаемости и надежности

Цель: Улучшить доступность, поддерживаемость и надежность сервисов в инфраструктуре Kubernetes.

Решение: Для достижения поставленных целей были реализованы следующие решения:

  1. Интеграция Kustomize: В проект был интегрирован шаблонизатор Kustomize. Были переработаны деплойменты и созданы базовые деплойменты для каждого сервиса. Кроме того, были разработаны специфичные оверлеи для каждой среды. Это улучшило понимание проекта и упростило поддержку кода.
  2. Управление динамическими секретами: Были введены bash-скрипты для динамического получения секретов из Secret Manager. Этот подход заменил захардкоженные секреты в конфигурационных файлах деплойментов, повысив безопасность и упростив доступ к секретам.
  3. Централизованная конфигурация: Был проведен рефакторинг кода, чтобы переменные с одним назначением и значением в сервисах были объединены в одном месте. Эта централизация снизила сложность и улучшила поддерживаемость.
  4. Трансформация пайплайна: Весь пайплайн деплоя был переписан для использования Kustomize. Был установлен непрерывный интеграционный пайплайн (CI) с проверкой валидности манифестов и тестированием их с использованием схемы API-сервера Kubernetes. Это упростило интеграцию новых версий кода, обеспечивая совместимость и упрощение процесса деплоя.
  5. Надежный непрерывный деплоймент: Была организована непрерывная доставка (CD) с тестированием после деплоймента с использованием команды rollout status. В случае сбоя деплоя автоматически запускается механизм отката к предыдущей версии, что повышает надежность деплоев и обеспечивает безшовное восстановление после неожиданных ошибок.

Технологии: Kubernetes, Kustomize, Secret Manager, Bash-скрипты, CI/CD.

Направление: DevOps.

Дата публикации: 18/05/2023

Проект: Соглашение о неразглашении

Цель: Внедрить новое решение мобильного банкинга для крупного финансового учреждения.

Решение: Клиент хотел предоставить своим клиентам современный и удобный мобильный банкинг.

Команда проекта использовала подход DevOps для создания мобильного банковского решения. Это включало автоматизацию развертывания приложения, интеграцию автоматического тестирования в конвейер сборки и развертывание приложения в нескольких облачных средах. Команда также реализовала конвейер непрерывной доставки с автоматическим контролем качества, чтобы гарантировать, что приложение полностью протестировано и готово к работе.

Успешный подход DevOps позволил клиенту быстро внедрить решение для мобильного банкинга, что позволило ему быстро вывести его на рынок. Это позволило им запустить решение мобильного банкинга с уверенностью, что оно стабильно и безопасно. Клиент также смог получить представление об использовании и производительности, что позволило ему улучшить качество обслуживания клиентов.

Технологии: Amazon Web Services, контейнеры Docker, непрерывная интеграция и непрерывная доставка, автоматическое тестирование, Kubernetes, Prometheus и Grafana для мониторинга и метрик.

Направление: DevOps

Дата публикации: 10/05/2023

Проект: Соглашение о неразглашении

Цель: Создание шаблонного пайплайна jenkins для сборки сервисов API и UI с помощью различных инструментов.

Решение: Используя практики devops, мы создали пайплайны шаблонов для сборок с использованием gradle, yarn, python и .net, интегрировав в них тесты кода и проверки sonarqube, что позволило привести их к единообразию и уменьшить количество ошибок сборки для существующих и новых сервисов и , соответственно, выпускать стабильные релизы.

Технологии: Jenkins, Gradle, Yarn, Python, .Net

Направление: DevOps

Дата публикации: 02/05/2023

Проект: Соглашение о неразглашении

Цель: Оптимизировать сценарии ansible для создания контейнеров Jenkins-master.

Решение: Переработаны ansible-скрипты создания контейнеров Jenkins-master для организации многопоточных изменений конфигурации, что позволило сократить время простоя на обновление и обслуживание 200+ контейнеров Jenkins-slaves на 90%.

Технологии: Ansible, Jinja2, Jenkins.

Направление: DevOps

Дата публикации: 25/04/2023

Проект: Соглашение о неразглашении

Цель: Заказчику необходимо было анализировать данные о количестве пользователях и разграничить их по категориям.

Решение: Мы реализовали методологию gitops для автоматизации развертывания приложений в kubernetes и обеспечения сохранности архитектуры. Мы разработали собственное приложение на python, которое преобразовывает эти данные в метрики и передает их в систему мониторинга
Мы применили Thanos для долгосрочного хранения данных системы мониторинга с целью дальнейшего анализа развития инфраструктуры и приложения