Обсудить проект_
Если у вас есть ИТ-проблема, напишите нам в Telegram или оставьте ваши контакты, и мы свяжется с вами для детального обсуждения задачи
Аудит инфраструктуры телемедицинского сервиса: блочная схема, версии и узкие места
Проект нашего клиента — веб-сервис для медицинской сферы. В него входят клиентские части для клиник и телемедицины, сервис расписания, сервис классификаторов и основной API с backoffice. Инфраструктура сервиса работала на Kubernetes и виртуальных машинах, и перед дальнейшими изменениями требовалось описать её состав и состояние.
Задача:
Изучить инфраструктуру и сервисы клиента и подготовить данные для последующего рефакторинга: понять, где что размещено, как связаны части системы, какие версии и слабые места в ней есть.
Результаты нужно было зафиксировать в документации аудита, чтобы у клиента была наглядная картина проекта.
Результаты нужно было зафиксировать в документации аудита, чтобы у клиента была наглядная картина проекта.
Итоги:
У заказчика появилась документация аудита: блочная схема проекта, описание инфраструктуры и сервисов, зафиксированные версии и узкие места, рекомендации по улучшению. По результатам аудита сформирован перечень первоочередных работ.
Период работы:
Март 2024 года
Команда:
DevOps-инженеры — 2
Инструменты:
- Kubernetes
- Notion
Решение:
Аудит охватывал архитектуру проекта и состояние кластера Kubernetes, сервисов и виртуальных машин.
Что нашли
- Резервное копирование. Отдельных резервных копий базы данных, файлового хранилища кластера, хранилища секретов и конфигурации кластера не было. Виртуальные машины копировались целиком на стороне провайдера, но данных о проверке восстановления из этих копий не было. Восстановить только часть данных было бы затруднительно.
- Единые точки отказа. Кластером управлял один мастер-узел, хотя для рабочей среды рекомендуют минимум три. Хранилище секретов работало в одном экземпляре, а постоянные данные приложений лежали на одной виртуальной машине с сетевым хранилищем (NFS). При отказе этой машины или хранилища секретов не запустился бы ни один из зависящих от них сервисов.
- Устаревшее ПО. На узлах кластера стояли устаревшие версии операционной системы и Kubernetes.
- Открытые служебные точки. Часть служебных конечных точек кластера и служебных сервисов была доступна из внешней сети. Точка входа в кластер пропускала все запросы, белого списка разрешённых адресов не было.
- Нет проверок работоспособности и лимитов. Не были настроены проверки состояния подов (liveness и readiness: по ним Kubernetes узнаёт, что приложение живо и готово принимать запросы, и перезапускает его при сбое). Не было и лёгкой проверки доступности, которую мог бы использовать мониторинг. Ограничений по ресурсам у подов не было.
- Мониторинг отдельно от кластера. Мониторинг работал вне кластера, часть его конечных точек была выставлена наружу. Канала оповещений для команды не было.
- Подсистема вне кластера. Одна из подсистем, отвечающая за видеосвязь и телефонию, работала вне кластера, с нестандартными доработками в деплое. Она делила виртуальную машину с системой сбора логов, и оба сервиса активно нагружали процессор. Клиент считал эту подсистему самым уязвимым местом проекта. Мы подтвердили эту гипотезу: в дальнейших работах подсистему связи переработали и стабилизировали с наивысшим приоритетом.
- Публикация без стандарта. Новые версии выкатывались набором манифестов, номер версии образа подставлялся в них при сборке. Секреты хранились по-разному: часть в хранилище секретов, часть в описании деплоя. В репозиториях остались скрипты публикации прошлых команд.
- Сервис картинок без кэша. Сервис не кэшировал результат изменения размера: при каждом обращении картинка обрабатывалась заново.
Что сделали
На основе изученного составили блочную схему проекта: она показывает, где размещены сервисы и как они связаны. Результаты аудита оформили в одной документации в Notion. В ней описаны стек и размещение сервисов, устройство кластера и конфигурация узлов, внешние точки входа, виртуальные машины, самые активные репозитории и процесс публикации, зафиксированы версии компонентов и узкие места.
Что рекомендовали
- Перейти с публикации манифестами на Helm-чарты (пакеты для развёртывания приложений в Kubernetes): так развёртывание стандартизируется, а откат и запуск новых окружений упрощаются.
- Описать инфраструктуру кодом (Infrastructure as Code), чтобы контролировать конфигурацию серверов и быстрее подключать к работе новых инженеров.
- Настроить резервное копирование базы данных, файлового хранилища, конфигурации кластера и хранилища секретов.
- Сделать хранилище секретов отказоустойчивым.
- Перенести мониторинг в кластер и закрыть доступ к его служебным точкам извне.
- Вместе с разработчиками составить список используемых точек входа и закрыть доступ ко всем остальным.
- Ограничить ресурсы приложений и настроить обработку PHP для работы в Kubernetes.
- Перевести сборку образов на многоэтапную, с кэшем, чтобы образы собирались быстрее.
- Убрать из репозиториев артефакты прошлых команд.
Обсудить проект _
Если у вас есть ИТ-проблема, оставьте свои контакты, и мы поможем спланировать ее решение. Обещаем не рассылать спам.
Нажимая, я говорю «Да» конфиденциальности и соглашаюсь с обработкой персональных данных
Контакты _
