Рефакторинг инфраструктуры для проекта в сфере телемедицины

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

Дополнительной сложностью стало то, что проект “подвис” в процессе переезда между двумя датацентрами и, кроме этого, попадает под ФЗ-152, что требует наличия СЗИ на продакшен окружении.

В рамках аудита были рассмотрены:

• кодовая база проектов — проведена инвентаризация, создан актуальный список на базе запущенных сервисов;
• CI\CD, пайплайны;
• мониторинг;
• IaC.

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

Результатами KZ: Экспресс докторухода от ручных операций и использования лучших практик стали стабильная работа системы, сокращение времени на сборку, деплой и откат модулей проекта, снижение трудозатрат на онбординг новых сотрудников при знакомстве с инфраструктурой.

Изначально была предпринята попытка развертывания кластера k8s на ресурсах текущего хостинг провайдера, который предоставлял ВМ с предустановленными СЗИ в “ручном режиме”.

Для описания инфраструктуры как кода был использован проект Kubespray (Ansible).

Первым вызовом стало обнаружение того, что k8s не совместим с СЗИ (Dr. Web) и при развертывании виртуальная сеть не работает (использовался calico). Создание пула настроек и исключений, совместно с провайдером, заняло несколько дней.

После развертывания кластера и настройки мониторинга выяснилось, диски на предоставленных серверах в произвольное время "подвисают" (время отклика резко вырастает). Это стало причиной отказа etcd. После нескольких итераций отладки и общения с технической поддержкой было принято решение менять хостинг провайдера.

При смене провайдера появилась возможность описать инфраструктуру как код полностью (новый хостер предоставлял для этого API и Terraform провайдер).

Для проекта были подготовлены базовые образы, после чего сборка кодовой базы была унифицирована. У разработчиков появилась возможность обновлять многомодульный проект со значительно меньшими трудозатратами; время, затрачиваемое на сборку образов, было сокращено в несколько раз.

Также деплой при помощи манифестов был заменен на Helm чарты, что дало возможность управлять версиями проектов и произвести быстрый откат, если во время обновления возникли ошибки.

Управление чувствительными параметрами перенесли в Vault.