TOC

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

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

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

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

Для балансировщиков нагрузки DigitalOcean параметры конфигурации выбираются отдельно, но вам все равно нужно убедиться, что настройки правильные и согласованные. Использование тега Droplet для определения серверной части Load Balancer - это самый прямой путь к успеху, поскольку он позволяет добавлять и удалять Droplets автоматически (а не по отдельному IP) и означает, что ваша конфигурация может обрабатываться исключительно Terraform без Ansible.

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

Наша установка

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

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

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

Понимание конфигурации

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

Конфигурация балансировщика нагрузки

DigitalOcean Load Balancer

Как и в предыдущих главах, мы будем использовать Terraform для управления конфигурацией балансировщика нагрузки. Следующая запись создает балансировщик нагрузки и предоставляет внутренний тег капли, правила пересылки, используемый сертификат TLS и проверки работоспособности, которые будет использовать балансировщик нагрузки. SSL и другие параметры безопасности выходят за рамки данной главы, но они подробно рассмотрены в главе 13.

Вот блок ресурсов, расположенный в файле + example-code / 02-scale / ch05 / init_deploy / main.tf +:

...

resource "digitalocean_loadbalancer" "public" {
 name                   = "${var.project}-lb"
 region                 = "${var.region}"
 droplet_tag            = "${digitalocean_tag.backend_tag.id}"
 redirect_http_to_https = true
 depends_on             = ["digitalocean_tag.backend_tag"]

 forwarding_rule {
   entry_port     = 80
   entry_protocol = "http"

   target_port     = 80
   target_protocol = "http"
 }

 healthcheck {
   port                     = 80
   protocol                 = "http"
   path                     = "/"
   check_interval_seconds   = 5
   response_timeout_seconds = 3
   unhealthy_threshold      = 2
   healthy_threshold        = 2
 }
}

Поскольку Балансировщики Нагрузки являются сервисом, а не неизменным ресурсом (таким как Капелька), изменение аргументов конфигурации не воссоздает весь Балансировщик Нагрузки; он будет обновлен на месте. Подробнее о поддерживаемых аргументах и ​​выходных атрибутах см. В документации Terraform.

Мы используем балансировщик нагрузки DigitalOcean для балансировки нагрузки общедоступного веб-трафика на наши веб-серверы.

HAProxy кластер

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

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

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

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

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

Сессии пользователя

  • Обзор сессий *

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

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

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

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

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

Использование * базы данных * или * хранилища данных в памяти * аналогично. И то, и другое требует от вас создания приложения таким образом, чтобы оно сохраняло пользовательские сеансы либо в базе данных, либо в кеше в памяти, например Redis. Использование базы данных может быть удобным, потому что ваше приложение уже настроено для подключения к ней для других запросов данных. Для высокоактивного сайта это может привести к дополнительным издержкам для самой базы данных, но в большинстве случаев используется дополнительная нагрузка, которая незначительна. Использование кэша в памяти, такого как Redis или Memcached, означает, что вам нужно будет создать еще несколько капель, но это очень быстрые и универсальные решения, которые вы также можете использовать для кэширования ответов на запросы базы данных для повышения производительности.

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

Файловое хранилище

  • _File Storage Review: _ *

_ Файлы, которые использует ваше приложение, должны быть согласованными; все серверы должны иметь доступ к одному и тому же набору ресурсов. Один хороший подход к этой проблеме - отделить функциональность хранилища от ваших внутренних серверов приложений и вместо этого использовать отдельный сервис для хранения файлов. Для статических активов вы можете использовать решение для хранения объектов. DigitalOcean Spaces - это высокодоступная служба хранения объектов со встроенной избыточностью. Мы поговорим больше об опциях хранения, особенно о пробелах, в главе 7. _

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

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

База данных

  • Database Review *

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

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

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

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

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

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

Вы можете посетить исходный репозиторий для этого здесь: https://github.com/DO-Solutions/galera-tf-mod. Он устанавливает TCP-маршрутизацию к кластеру, который по умолчанию имеет три узла. Если бы мы использовали менее трех узлов, узел Galera Arbitrator потребовался бы для того, чтобы избежать проблем с разделением мозга и поддерживать работу кластера. Вы также можете увеличить количество узлов, добавив следующую строку в блок кода модуля в нашем главном файле 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 + над элементом управления Droplet, который содержит пример кода для этой главы.

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

./bin/init_config

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

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

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

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

Во-первых, запуск + terraform plan + создаст следующие элементы в вашей учетной записи DigitalOcean:

  1. One Load Balancer, который обеспечит доступ к вашему сайту WordPress.

  2. Три капли, которые будут использоваться в качестве веб-узлов WordPress.

  3. Три капли для использования в качестве узлов базы данных.

  4. Два узла балансировки нагрузки HAProxy для кластера базы данных.

  5. Один Плавающий IP-адрес для балансировщика нагрузки базы данных.

terraform plan

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

terraform init

Наконец, выполните запросы на создание через API DigitalOcean, используя + apply +.

terraform apply

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

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

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

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

Посетите IP-адрес своего балансировщика нагрузки в браузере и следуйте инструкциям на экране, чтобы завершить настройку WordPress. Обратите внимание, что в главе 13 рассказывается, как защитить установку WordPress с помощью HTTPS.

Настройка пробелов

Мы будем использовать плагин DigitalOcean Spaces Sync для синхронизации медиафайлов с серверов приложений WordPress в хранилище объектов. Пространство выступает в качестве центрального места для хранения любых носителей, которые вы решили загрузить.

Плагин DigitalOcean Spaces Sync был предварительно установлен как часть Ansible playbook. Чтобы использовать этот плагин, вам сначала необходимо create Space с помощью панели управления.

Как только пространство будет создано, create ключ доступа к Spaces на странице «API» на панели управления. , После генерации ключа вы увидите главный ключ вместе с секретом. Запишите их, так как они понадобятся вам для настройки плагина WordPress.

Теперь, возвращаясь к WordPress, посетите страницу плагинов, и вы увидите уже установленную синхронизацию DigitalOcean Spaces Sync благодаря нашей книге игр Ansible. Нажмите на ссылку Активировать, чтобы включить этот плагин. После включения в настройках появится новая ссылка «Синхронизация DigitalOcean Spaces».

На этой странице настроек введите ключ пробелов, секрет пробелов, имя пробела (помеченное на этой странице настроек как «DO Spaces Container») и конечную точку. Имейте в виду, что конечная точка будет зависеть от того, какой центр данных вы выбрали для своего пространства: например, NYC3 будет «https: //nyc3.digitaloceanspaces.com».

После проверки соединения добавьте полный URL-адрес своего пространства под заголовком «Полный URL-путь к файлам:». Для пространства в NYC3 это будет «https: //space-name.nyc3.digitaloceanspaces.com» (где + space-name + - имя вашего пространства). После того, как это введено, самое время сохранить ваши настройки и протестировать плагин, загрузив файл.

Когда вы загружаете файл на вкладке «Медиа», вы должны автоматически синхронизировать его с вашим пространством. Вы можете проверить это, просмотрев список файлов Space на панели управления DigitalOcean.

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

Если вы добавите CDN позже, имейте в виду, что вам нужно будет указать «Полный URL-путь к файлам» на адрес этого нового CDN. Мы также работаем над CDN, который интегрируется с Spaces. Это в настоящее время в бета-версии, но, пожалуйста, не стесняйтесь спросить вашего менеджера аккаунта для доступа, если вы заинтересованы.

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

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

изображение: https: //raw.githubusercontent.com/digitalocean/navigators-guide/master/book/02-scale/ch05-wordpress-screenshot.png [Скриншот установки WordPress по умолчанию]

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

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

terraform destroy

Вы можете повторно запустить + apply +, а затем повторно запустить Ansible playbook, чтобы восстановить кластер.

Что дальше?

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

Related