Распределенные базы данных очень важны, поскольку мы можем распространять наши данные по всему миру и достигать невероятно быстрого времени отклика независимо от того, где находится наш пользователь. Я хотел показать, как это можно сделать совершенно бесплатно, используя HarperDB и бесплатные уровни, предлагаемые провайдерами. Хотя я выбрал AWS и Azure, сейчас есть много других облачных провайдеров, которые предлагают выгодные бесплатные уровни или бесплатные кредиты, такие как Azure.
Чтобы упростить развертывание нескольких облаков, я собираюсь использовать Terraform для управления инфраструктурой и позволять нам развертывать наши контейнеры одной командой. Мы разместим одну базу данных в Европе, используя Azure, одну в Индии, на AWS, и, наконец, мы будем использовать облачный экземпляр HarperDB, работающий в США. После развертывания контейнеров мы перейдем к HarperDB и воспользуемся его функцией кластеризации, чтобы легко синхронизировать наши экземпляры в несколько кликов. Чтобы продемонстрировать кэширование, я создам ретранслятор API данных Формулы-1, чтобы помочь в работе веб-приложения, отображающего последние результаты пилотов. Давайте начнем!
Если вы хотите следовать этому руководству в формате видео, я также подготовил почти 30-минутное пошаговое видео, и HarperDB любезно предложил загрузить его на свой канал YouTube для меня:
Войдите в Терраформ
Terraform — это инструмент IaC с открытым исходным кодом, выпущенный HashiCorp. Terraform не зависит от платформы, поэтому содержит модули для многих разных поставщиков и считается нейтральным подходом к IaC, поскольку некоторые решения требуют привязки к поставщику, например Cloud Formation. Вместо того, чтобы использовать интерфейс командной строки, писать кучу кода для использования API для запуска экземпляров или выполнять кучу кликов в консоли, мы можем использовать Terraform для повторяемого развертывания независимо от ситуации.
Начиная
Если у вас не установлен Terraform CLI, инструкция по его установке находится здесь. Для аутентификации Terraform с нашими учетными записями AWS и Azure самый простой способ — использовать соответствующие интерфейсы командной строки для входа в систему и позволить Terraform пройти аутентификацию таким образом. Вы также можете сохранить учетные данные в переменных среды, для которых есть инструкции здесь и здесь.
Чтобы получить AWS CLI, есть инструкции здесь, а инструкции для Azure CLI можно найти здесь. Для аутентификации AWS CLI вы можете сгенерировать ключи доступа через Консоль, следуя этим инструкциям. В Azure есть команда входа, которую мы можем использовать для аутентификации через наш веб-браузер.
Теперь, когда CLI готовы — мы можем перейти к инфраструктуре!
Файлы Terraform
Terraform работает, анализируя все файлы *.tf
(и некоторые другие) в вашем текущем рабочем каталоге и применяя переменные из файлов *.tfvars
. Вы также можете хранить свои файлы TF в формате JSON как *.tf.json
file, но это не так часто.
Вы можете хранить весь свой код Terraform в одном гигантском файле, но в нем очень легко потеряться, и, по правде говоря, требуется определенная организация, когда вы начинаете создавать более крупные проекты. По этой причине разработчики часто разбивают код IaC на модули, сервисы или провайдеры, но выбор остается за вами. Если вы новичок в Terraform, вот как в целом выглядит код:
Мы объявляем, какой это тип ресурса, в нашем случае это aws_vpc
, а также имя ресурса, который я только что назвал vpc
— не очень оригинально, но сгодится для такого небольшого проекта, как этот, где есть является лишь одним из этих ресурсов. В зависимости от типа ресурса, который вы настраиваете, будет определяться, какие атрибуты требуются или доступны, но именно здесь пригодится отличная документация Terraform, поскольку мы могли бы копаться и смотреть, что еще доступно для ресурса VPC, если это необходимо.
Как упоминалось ранее, необходима некоторая организация, поэтому я разделил код IaC этого проекта на файл AWS, файл Azure, файл DNS, а затем основной файл, который содержит конфигурацию и некоторые переменная информация.
Развертывание
Чтобы начать развертывание, сначала нам нужно клонировать репозиторий GitHub для этого проекта, инициализировать Terraform, а затем развернуть проект:
После того, как он вычислит все необходимые ресурсы, Terraform будет ждать вашего одобрения, прежде чем фактически запустить ресурсы, что очень полезно, поскольку вы можете увидеть, случайно ли он уничтожит ресурс или добавит слишком много ресурсов, среди прочего. После завершения развертывания Terraform вы можете получить общедоступный IP-адрес для контейнеров через интерфейс командной строки или через консоль. Также можно настроить их как вывод с помощью Terraform и сохранить локально.
Для AWS перейдите в Консоль и выберите Служба эластичных контейнеров. Выберите кластер HDB, а затем перейдите на вкладку Задачи. Щелкните единственную задачу в списке и найдите Общедоступный IP-адрес. Для Azure перейдите на Портал и выберите Экземпляры контейнеров. Выберите группу HDB и возьмите IP-адрес (общедоступный).
Гео-маршрутизация
Теперь, когда у нас есть мультиоблачное развертывание, было бы здорово, если бы мы могли автоматически направлять пользователей в их ближайший регион, чтобы наши пользователи получали информацию из нашего API как можно быстрее. К счастью для нас, мы можем достичь этой цели с любым выбранным нами провайдером, но я буду использовать AWS Route53, чтобы легко добавить эту функцию. В каталоге проекта переименуйте пример DNS-файла и заполните его IP-адресами ваших контейнеров:
После сохранения этих изменений мы можем перезапустить Terraform и добавить необходимую дополнительную инфраструктуру DNS:
Теперь, в зависимости от местоположения Пользователя, Route53 будет стратегически маршрутизировать наш запрос — очень просто и круто!
Кластеризация HarperDB
Из HarperDB Studio давайте добавим экземпляры, которые мы развернули ранее. После входа в HarperDB Studio перейдите на страницу Экземпляры и нажмите кнопку Добавить. Мы хотим добавить оба наших контейнера, назвав их соответствующим образом:
Поскольку наши контейнеры небольшие, мы можем обойтись бесплатным уровнем HarperDB, который предлагает 512 МБ памяти. После того, как вы добавили оба экземпляра, давайте, наконец, добавим третий экземпляр для подключения. Вы можете либо установить инстанс, установленный пользователем, либо запустить его локально, но я предпочитаю использовать облачный инстанс HarperDB, так как он полностью управляем, так что одной проблемой меньше.
Облачный экземпляр
Нажмите «Создать экземпляр», а затем «Создать экземпляр AWS или Verizon Wavelength». Я выберу AWS и предоставлю ему некоторые основные сведения, но оставлю учетные данные инстанса прежними, чтобы упростить администрирование. Я также оставлю настройки по умолчанию на следующей странице и запущу экземпляр при появлении запроса. Предоставив HarperDB несколько минут для запуска экземпляра, мы можем нажать на него и начать кластеризацию!
Включение кластеризации
После добавления всех трех экземпляров в HarperDB щелкните только что добавленный облачный экземпляр и перейдите в раздел «Кластер». С левой стороны введите учетные данные кластеризации из файла переменных. После этого нажмите «Установить имя узла кластера», а затем включите, наконец, кластеризацию. Как только это будет завершено, вы увидите список неподключенных экземпляров с левой стороны. Вы можете щелкнуть значок «+» рядом с каждым из экземпляров контейнера, чтобы соединить их вместе.
Как только они будут подключены, вы получите список схем и таблиц, которые вы можете выбрать для публикации или подписки. Это невероятно простой способ синхронизации двух разных экземпляров, чтобы информация была доступна во всем кластере, а не только в одном экземпляре. Мы выберем публикацию и подписку на оба узла, как если бы один узел получил запись, мы хотели бы узнать об этом, а затем опубликовать на другом узле.
Развертывание API
Последней частью головоломки является развертывание нашего кода пользовательских функций на узлах кластера HarperDB. Если у вас уже есть настроенный проект пользовательских функций на одном из ваших узлов, вы можете перенести его с помощью HarperDB Studio. Или, если вы используете необлачный экземпляр, вы можете просто загрузить файлы в каталог данных HarperDB. Поскольку мы используем облачный экземпляр и контейнеры для других наших серверов, проще использовать скрипт для загрузки кода пользовательских функций с помощью HarperDB API.
HarperDB выпустила проект пользовательских функций, который позволяет нам кэшировать удаленный ресурс API локально в экземпляре HarperDB. Это полезно, если информация, которую мы извлекаем, не обновляется часто, и нам не всегда нужна свежая копия информации, поскольку она будет неизменной. Мы будем использовать этот код для быстрого создания утилиты кэширования для API F1, размещенного на Ergast.
В каталоге scripts
есть файл с именем deploy-custom-functions.js
, в этом файле есть некоторые значения конфигурации, которые следует отредактировать вверху:
После редактирования значений мы можем установить зависимости и запустить скрипт следующим образом:
Как только он будет завершен, мы можем перейти в HarperDB Studio и развернуть проект на других экземплярах. В HarperDB Studio выберите экземпляр, в который мы были развернуты, и выберите «Функции». Нажмите «Развернуть» в правом верхнем углу, чтобы увидеть список доступных серверов — затем вы сможете выполнить развертывание на каждом узле HarperDB, который мы настроили для этого проекта.
Наконец, нам нужно запустить маршрут установки на каждом хосте, на котором мы развернули код шлюза API. Мы можем сделать это очень просто через Curl:
Тестирование
Используя Curl (или Postman через его пользовательский интерфейс), вы можете легко протестировать время отклика кэширования, отправив запрос к API и запросив положение водителя у API Ergast:
Количество времени в «реальной» строке — это время в минутах/секундах, которое занял запрос. В зависимости от того, как вы настроите значение MAX_AGE_SECONDS
в хелпере handleRequest, будет зависеть, как долго запрос будет оставаться в кэше. Для нашего варианта использования мы могли бы установить это значение относительно высоким, поскольку гонки случаются не слишком часто (особенно сейчас во время перерыва).
Заключение
Самое замечательное здесь то, что, поскольку у нас настроен кластер данных HarperDB, как только один узел кэширует запись, HarperDB автоматически синхронизирует запись в нашем кластере. Это снижает сложность нашего кода и экономит нам много времени и головной боли. Это был мой первый проект с использованием кластеризации, и я очень рад найти свой следующий проект, в котором я смогу его реализовать.
Чтобы продвинуть проект дальше, мы могли бы реализовать собственный образ, в который загружен наш собственный SSL-сертификат, и изменить порты, настроенные на обычные порты, например, для HTTPS. Мы также могли бы изменить конфигурацию DNS Terraform, чтобы вместо этого использовать выходные значения контейнеров, чтобы он мог автоматически генерировать записи DNS для нас.
Как только вы закончите с проектом, вы можете легко уничтожить все созданные ресурсы с помощью одной простой команды: