Инфраструктура для бизнеса: инструменты развертывания с поддержкой управления конфигурацией

Cloud Server, Development, VPS | Amber | Комментировать запись

Цель этой серии статей – помочь бизнес-клиентам спланировать свои потребности в инфраструктуре, на рабочих примерах объяснить различные технические нюансы, которые делают некоторые решения лучше других.

Читайте также:

• Инфраструктура для бизнеса: вступление
• Основные средства для облачных вычислений
• Начальная настройка среды
• Высокая доступность

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

И фронтенд, и бэкенд могут использовать балансировку нагрузки для распределения трафика между несколькими серверами. Эта структура предоставляет уникальные преимущества для серверной части – это и возможность обновления кода приложения без простоя, и поддержка таких вещей, как A/B-тестирование, канареечное развертывание и blue/green развертывание. Однако это также усложняет инфраструктуру. Вам нужно подумать о том, как поддерживать конфигурацию ваших балансировщиков нагрузки, как управлять приложением и серверами, на которых оно работает, и как поддерживать согласованность пользовательских сеансов, хранилища файлов и базы данных.

Если вы используете набор балансировщиков нагрузки, вы должны поддерживать согласованность его конфигурации. Управление конфигурационными файлами балансировки нагрузки с помощью инструментов управления конфигурацией требует дополнительной работы. Сегодня некоторые провайдеры предоставляют сервис управляемых балансировщиков нагрузки, который автоматически обрабатывает избыточность. Но и в этом случае вам все равно необходимо убедиться, что настройки правильные и согласованные. Ваша конфигурация может обрабатываться исключительно через Terraform без Ansible.

Если ваши требования к балансировке нагрузки выше, возможно, вам лучше использовать свой собственный балансировщик нагрузки (через HAProxy или другое программное обеспечение для балансировки нагрузки). В этом случае для балансировки нагрузки вам потребуется развернуть набор из нескольких серверов с плавающими IP-адресами, чтобы обеспечить избыточность.

Общие сведения о настройке

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

На примере таких ситуаций мы постараемся продемонстрировать вам более эффективное использование программного обеспечения для управления конфигурацией. Чтобы разместить тестовый веб-сайт на основе WordPress, нам нужно подумать, как обеспечить доступ к правильным данным для каждой ноды в нашем кластере. Конечные пользователи должны видеть, что сайт работает согласованно независимо от того, какая из нод обрабатывает запрос. Этого не получится, если одна нода знает о публикации или изображении на нашем сайте WordPress, а другие – нет.

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

Кластер HAProxy

Мы используем кластер HAProxy для управления балансировкой нагрузки нашего кластера базы данных.

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

Ansible использует систему шаблонов Jinja2, которая упрощает процесс создания и обновления ваших файлов конфигурации. Jinja2 поддерживает переменные и управляющие структуры, которые можно найти в языке программирования (это операторы if, циклы, математические операции и большая библиотека встроенных фильтров). Кроме того, в Ansible  отличная система шаблонов, рекомендуем просмотреть документацию Ansible, чтобы узнать о ней больше.

Есть несколько способов вызвать обновление при изменении конфигурации. Если спрос на вашем сайте не сильно колеблется или вы заранее знаете, когда произойдут изменения, автоматическое масштабирование вам может не потребоваться. Вместо этого вы можете запустить плейбук Ansible вручную или настроить его запуск при внесении изменений в сценарии развертывания Terraform в репозиторий git.

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

Пользовательские сеансы

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

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

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

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

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

Использование хранилища базы данных или хранилища в памяти работает одинаково. Оба эти варианта требуют, чтобы вы создавали ваше приложение таким образом, чтобы хранить пользовательские сеансы либо в базе данных, либо в кэше в памяти (например Redis). Использовать БД может быть удобнее, поскольку ваше приложение уже настроено на подключение к ней для обработки запросов данных. В случае высокоактивного сайта это может привести к дополнительным затратам на саму базу данных, но в большинстве случаев дополнительная нагрузка незначительная. Для поддержки in-memory кэша (Redis или Memcached) вам потребуется создать еще несколько сервреов, но это очень быстрые и универсальные решения, которые вы также можете использовать для кэширования ответов на запросы базы данных для повышения производительности.

Поскольку WordPress уже настроен на поддержку базы данных, мы будем использовать это решение.

Хранилище файлов

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

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

Более простое решение – использовать хранилище объектов (особенно потому, что в WordPress есть много встроенных плагинов для поддержки таких хранилищ). Поскольку настройка сводится к установке и настройке одного плагина, мы будем использовать это средство.

База данных

Как и хранилище, ваша база данных должна быть доступна для всех бэкенд серверов. То, как вы реплицируете вставки и обновления базы данных в кластере, играет важную роль в функционировании кластера.

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

В нашем примере для решения этих проблем мы используем кластер MariaDB Galera. Galera выполняет синхронную репликацию каждой ноды базы данных, и каждая из этих нод выступает в качестве полноценного первичного сервера БД. Это означает, что вы можете выполнять операции чтения и записи на любой ноде в кластере, и все будет работать синхронизировано. Существуют и другие способы кластеризации баз данных, включающие первичные и вторичные формы репликации, где в качестве основного сервера записи выбирается конкретная нода.

Каждое кластерное решение имеет свои преимущества. В нашем случае Galera дает больше преимуществ: согласованность данных обрабатывается автоматически, каждая нода в кластере может служить ведущим сервером, а настраивать восстановление после сбоя нет необходимости.

WordPress полагается на свою базу данных почти во всех вопросах, и один внешний сервер базы данных – это единая точка отказа. Существует несколько вариантов настройки для кластеров базы данных (их можно легко комбинировать в зависимости от того, что работает лучше всего в вашем случае).

В этой главе мы создадим кластер Galera на MariaDB (форк MySQL), который будет работать за несколькими нодми HAProxy с плавающими IP-адресами.

Вы можете посетить исходный репозиторий. Он настраивает TCP-маршрутизацию к кластеру, который по умолчанию имеет три ноды. Если бы мы использовали менее трех нод, нам бы понадобилась нода Galera Arbitrator, чтобы избежать возникновения двух ведущих серверов в системе и сохранить кластер в рабочем состоянии. Вы также можете увеличить количество нод, добавив следующую строку в блок кода module в основной файл terraform (example-code/02-scale/ch05/init_deploy/main.tf). Обратите внимание, что вам нужно иметь нечетное количество нод, чтобы кластер мог получить большинство при голосовании кворума. Например, если две ноды считают, что запись должна существовать, а две другие ноды, что нет, требуется дополнительная нода, голос которой станет решающим.

module "sippin_db" {
...
db_node_count = "5"
}

Настройка кластера WordPress

В нашем проекте настройка кластера WordPress выполняется всего в несколько команд. Мы будем работать с каталогом /root/navigators-guide/example-code/02-scale/ch05/init_deploy на контрольной ноде, где содержится пример кода.

В этом каталоге можно запустить такой скрипт инициализации. Он проведет вас через все настройки и переменные, которые вам нужно установить.

./bin/init_config

Вы можете просмотреть код скрипта инициализации на GitHub. Вы увидите, что скрипт выполняет целый ряд функций. На самом деле он автоматически создает необходимые файлы переменных Terraform и Ansible и гарантирует устранение перечисленных выше проблем. Первое, что сделает скрипт, это запросит действительный токен API. После этого он создаст несколько уникальных ключей, необходимых для создания кластера. Следующее диалоговое окно, которое вы увидите, предложит выбрать имя проекта и регион. Если ключ SSH уже настроен, скрипт позволит Terraform использовать его. Если ключ SSH еще не настроен, он будет создан и автоматически добавлен в вашу учетную запись. Наконец, скрипт запросит все необходимые пароли.

Как только сценарий закончит работу, план Terraform и плейбук Ansible будут готовы к выполнению.

Если бы вы все настраивали вручную, вам понадобились бы переменные Terraform из файла terraform.tvfars. Ansible хранит обязательные переменные в нескольких папках внутри папки group_vars.

Скрипт инициализации выведет инструкции о том, как продолжить работу с Terraform.

Сначала команда terraform plan создаст в вашей учетной записи следующие элементы:

• Один балансировщик нагрузки, который обеспечит доступ к вашему сайту WordPress.
• Три сервера для использования в качестве нод WordPress.
• Три ноды, которые будут использоваться в качестве серверов БД.
• Две ноды для балансировки нагрузки HAProxy.
• один плавающий IP-адрес для балансировщика нагрузки БД.

terraform plan

Затем обработайте файлы плана и модули, чтобы подготовить развертывание Terraform, используя init.

terraform init

Команда apply выполнит запросы на создание через API.

terraform apply

Как только Terraform завершит создание всех компонентов инфраструктуры, вы сможете использовать Ansible для их настройки. Для этого необходимо выполнить три роли Ansible: одну для настройки серверов БД, одну для настройки балансировщиков нагрузки и одну для настройки WordPress на всех трех нодах.

Вы можете запустить все три роли одной командой:

ansible-playbook -i /usr/local/bin/terraform-inventory site.yml

После этого вам нужно будет завершить настройку WordPress.

Посетите IP-адрес вашего балансировщика нагрузки в браузере и следуйте инструкциям на экране.

Настройка хранилища

Затем вам нужно настроить свое хранилище объектов. Настройка будет зависеть от вашего провайдера. Желательно выбрать такого провайдера, для которого в WordPress есть готовый плагин.

Настройте свое хранилище самостоятельно.

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

Возможно, ваша настройка по умолчанию не поддерживает CDN. В среде производства рекомендуем использовать CDN, поскольку это позволит быстрее обслуживать контент.

Проверка настройки

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

Конечный результат – полнофункциональный сайт WordPress. Вы можете проверить работу сайта, настроив блог или создав пару записей. Для проверки вы также можете отключить два веб-сервера, один из серверов HAProxy и одну ноду базы данных, а веб-сайт по-прежнему должен быть полностью функциональным.

После тестирования вы можете удалить все компоненты инфраструктуры с помощью одной команды.

terraform destroy

Эта команда удалит весь кластер.

Заключение

Итак, мы применили понятия высокой доступности ко всем элементам кластера.

В этом мануале мы создали избыточный и масштабируемый веб-сайт WordPress. Такая инфраструктура была достигнута благодаря инструментам управления конфигурацией.