Внедрение DevOps-методологии для обновления и актуализации окружений

В рамках работы над проектом ТимЛид предложил реализовать механизм для обновления и актуализации данных на окружениях разработки, который автоматизирует процесс настройки CMS: 1С-Битрикс: Управление сайтом. Он самостоятельно определяет и устанавливает параметры всех обменов и другие специфические настройки, необходимые для конкретной среды, по команде.

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

В рамках внедрения DevOps-методологии разработан скрипт для обновления и актуализации предпродуктовых стендов в соответствии с производственной средой (prod). Скрипт охватывает несколько окружений: продакшн, предпродакшн, dev и test.

В общем случае, процесс актуализации данных является фактически резервным копированием с последующим развертыванием резервной копии в другом контуре, но с нюансами. Дело в том, что необходимо соблюдать требования информационной безопасности, поэтому нельзя просто так “взять и развернуть копию”. Особенно, если мы работаем с чувствительными данными, повреждение или утечка которых могут привести к крайне негативным последствиям. Для соответствия всем требованиям применена концепция, при которой происходит односторонний доступ с продуктовой среды в актуализируемое окружение.

А теперь подробно рассмотрим технические детали:

Скрипт написан на языке командной оболочки bash, что позволяет избавиться от необходимости предустановки дополнительного ПО: на сегодняшний день наличие данной командной оболочки на сервере является стандартом “де-факто” (исключения составляют легковесные контейнеризованные окружения). Он состоит из двух частей, которые предполагают последовательное выполнение на разных стендах. При этом вторая часть запускается только после успешного выполнения первой.

Первая часть, выполняемая на продуктовом окружении, производит следующие действия:

Снятие данных из БД: на данном этапе создается обезличенный сжатый SQL-дамп базы данных производственного окружения, исключающий таблицы с историческими данными и интеграции с Active Directory (AD).

Трансляция дампа в целевое окружение: дамп передается на целевой стенд с помощью утилиты rsync, которая в свою очередь использует протокол SSH. Так как протокол SSH поддерживает аутентификацию по ключевой паре, публичная часть предварительно сгенерированного rsa-ключа продуктового окружения заранее размещена на всех целевых серверах для безопасного доступа: согласно политикам безопасности парольный доступ к окружениям запрещен.

Доставка файлового хранилища: каталоги, содержащие рабочие наборы данных (например, медиафайлы) полностью синхронизируются посредством утилиты rsync с аналогичным каталогами на целевом стенде, после чего также проходят обезличивание.

Вторая часть, выполняемая на целевом стенде:

Остановка сервисов: перед началом обновления останавливаются сервисы, отвечающие за поддержку обмена данными с другими смежными системами - например, cron, supervisor и т.п. для избежания коллизий, синхронизации с устаревшими данными или идентификаторами (например, попыток обработать старые события cron).

Резервное копирование таблиц БД, исключенных из архива в продуктовой среде: это дешевле по вычислительным ресурсам, в отличие от необходимости постоянной генерации новых наборов тестовых данных, и проще, чем хранить эти данные заготовленными заранее: тестовые данные могут меняться в зависимости от потребностей непосредственно на стенде через веб-интерфейс системы, загрузка же одних и тех же данных будет означать постоянный “сброс к заводским настройкам”.

Обновление базы данных: удаляется БД целевого окружения, так как восстановление из SQL-дампа не удаляет дополнительные таблицы, которые могут содержаться в тестовом или предпродакшн окружении, но отсутствуют на продуктовой среде; восстанавливается дамп, полученный с продуктового сервера; восстанавливается резервная копия ранее сохраненных таблиц с тестовыми историческими данными.

Настройка Битрикс: скрипты автоматической настройки CMS Битрикс запускаются для текущей среды. Эти скрипты обновляют пути, ключи API и интеграционные параметры, как в конфигурационных файлах, так и непосредственно в БД.

На последнем этапе запускаются миграции, применяемые к БД и обновляющие её схему, чтобы соответствовать новой кодовой базе и новым возможностям, которые будут проходить тестирование.

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

В процессе выполнения команды в терминале выводится подробный отчет. Логи сохраняются для диагностики возможных ошибок, таких как пропущенные файлы или проблемы с правами доступа. Отсутствие ошибок в файле лога свидетельствует о том, что процесс прошел успешно.

Механизм обезличивания данных

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

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

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

Как выглядит встроенный механизм обезличивания: 

1.Фильтрация данных: При создании дампа исключаются чувствительные таблицы. 

2. Маскировка данных в БД: Например, имена пользователей заменяются на `user_001`, email — на `test@example.com`, а платежные данные — на тестовые шаблоны.

3. Очистка метаданных: Удаляются файлы в хранилищах, связанные с реальными пользователями. 

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

Какие можно выделить преимущества в рамках данных работ?

1. Автоматизация и скорость 

- Процесс обновления сред занимает несколько минут вместо часов ручной настройки. 

2. Безопасность 

- Трансляция данных через SSH-ключи минимизирует уязвимости. 

- Обезличивание предотвращает доступ тестовых команд к реальным данным пользователей. 

3. Согласованность окружений 

- Предпродуктовые и тестовые среды точно отражают производственную инфраструктуру, что снижает риски неработающих обновлений в проде. 

4. Единообразие настроек Битрикс

- Механизм автоматической конфигурации платформы исключает ошибки вручную прописанных параметров (например, ключей API или путей к бэкенд-сервисам). 

Разработанный скрипт и механизм обезличивания данных обеспечивают гладкое обновление пре-prod окружения с минимальными рисками для данных. Внедрение DevOps-методологии повышает эффективность, безопасность и согласованность окружений, что способствует успешному тестированию и обновлению производственной инфраструктуры.