Некоторое время назад я написал здесь статью о том, как начать работу с NuoDB, предоставив домен . Большая часть этого была сфокусирована на том, что такое домен, как подключить пару хостов к сети и работать вместе, а также как использовать командную строку для управления этими хостами. С тех пор я услышал большой интерес к последующему материалу, в котором рассказывается о том, что делать после завершения базовой установки.
NuoDB разработан, чтобы быть довольно простым для запуска из коробки. Однако после того, как вы поработали над шинами, ознакомились с нашими примерами и увидели, что это настоящий сервис SQL, вы, вероятно, захотите выяснить, как настроить основные компоненты нашей системы для вашей среды. Вот что я попытаюсь осветить здесь.
Основные свойства домена
Когда вы устанавливаете NuoDB, в первую очередь происходит запуск локального агента управления. Как я объяснил в моей предыдущей записи, этот агент настраивается по умолчанию из локального файла свойств. Для большинства развертываний программного обеспечения есть пара этих свойств, которые вы хотите настроить.
В моих предыдущих примерах я всегда показывал локальный агент, работающий в качестве посредника соединений. Это потому, что продукт поставляется с этим набором свойств:
# A flag specifying whether this agent should be run as a connection broker broker = true
Мы поставляем продукт таким образом, чтобы его было легко запустить из коробки, но в реальном развертывании обычно требуется, чтобы только несколько агентов работали в качестве посредников соединений. Пока у вас есть несколько брокеров, вы работаете в избыточном режиме. Если вы установите для этого свойства значение false (или просто закомментируете его), на вашем хосте будет агент, который отслеживает и управляет только тем, что происходит на локальном хосте, и сообщает обо всем обратно некоторому посреднику в домене. Подробнее о том, как подключить ваши хосты, смотрите обсуждение свойства «peer» в предыдущей записи.
Еще одно свойство, которое вы можете изменить, это допустимый диапазон портов. Когда агент запускает Transaction Engine или Storage Manager, он запускает процесс сервера, который должен прослушивать какой-либо порт. Если у вас есть правила брандмауэра, вы, вероятно, захотите заблокировать, какие порты разрешены для использования процессами базы данных. Вот свойство для этого:
# A range of port numbers that nuodb instances should be confined to. This is # of the form start[,end] #portRange =
Так, например, если вы установите portRange = 48010,48020, это ограничит процессы локальной базы данных использованием 11 портов (включительно) в этом диапазоне. Конечно, это также ограничивает вас в общей сложности 11 процессами на хосте, поэтому тщательно продумайте, насколько сильно вы хотите заблокировать брандмауэр по сравнению с тем, сколько баз данных вам нужно поддерживать.
Обратите внимание, что если вы действительно хотите заблокировать хост для запуска только одного TE или SM, вы также можете установить для этого свойства одно значение. Например, установка portRange = 48010 будет означать, что вы можете запустить только один процесс, который будет прослушивать порт 48010.
Последнее свойство, которое стоит отметить, — это имя вашего домена:
# The name used to identify the domain that this agent is a part of domain = domain
Это действительно просто способ присвоения имени вашему домену, чтобы было проще работать с нашими инструментами. Если вы измените эту строку, перезапустите брокера, а затем повторно подключитесь в веб-консоли, и вы увидите, как это имя отражено в интерфейсе администратора. Если вы не пытаетесь управлять несколькими доменами, вам, вероятно, никогда не придется беспокоиться об изменении этого свойства.
Учетные записи администрирования домена
Начиная с версии 1.1 NuoDB использует простую модель авторизации для управления доменом. Вы можете создать столько административных учетных записей, сколько захотите, но все они по сути являются «корневыми» пользователями, которые имеют равные привилегии.
По умолчанию всегда есть пользователь с именем «домен». Это идентичность, используемая агентами, которые связаны вместе для поддержки вашего домена. Пароль этого пользователя настраивается здесь:
# The default administrative password, and the secret used by agents to # setup and maintain the domain securely domainPassword = bird
Все агенты должны быть настроены с одним и тем же паролем. Да, мы знаем, что это не идеально. Сожалею. Мы работаем над гораздо более гибкой и надежной моделью для нашего следующего выпуска. В то же время это свойство, почему из коробки вы можете войти в веб-консоль с именем пользователя «домен» и паролем «птица».
Мы предлагаем вам пару вещей. Во-первых, измените этот пароль на что-то сложнее угадать. Фактически, если вы посмотрите на наши примеры Amazon Web Services (и пример формирования облака, и предоставления Python), мы используем длинную случайную строку в качестве пароля и никогда не сообщаем пользователю, что это за пароль. Это подводит нас ко второму, что вы должны сделать.
Инструмент менеджера командной строки позволяет создавать дополнительные учетные записи администратора домена. В нашей документации есть пример (пропустите шаг 1, так как у вас уже работает брокер). Мы предлагаем вам создать дополнительные административные учетные записи и использовать их для управления системой. Как сказано в документации, вы также можете создать учетную запись специально для веб-консоли, а затем обновить настройки webapp.properties для использования этой новой учетной записи.
Учетные записи, которые вы создаете здесь, предназначены только для домена . Эти учетные записи не дают вам доступа к внутренним частям данной базы данных. Независимо от того, сколько учетных записей администрирования домена вы создадите, вы все равно выберете имя пользователя и пароль администратора базы данных при первом запуске базы данных, и оттуда вы будете использовать обычные команды SQL для создания дополнительных учетных записей или ролей, а также для предоставления или отзыва привилегий.
Альтернативная адресация
Допустим, вы находитесь на веб-сервисах Amazon. Каждый экземпляр, который вы запускаете, имеет два адреса, связанных с ним. Одним из них является внутренний адрес (или частный адрес), который имеет смысл только в сети Amazon. Например, если вы видите 10. * IP-адрес, это что-то внутреннее. Другой — это внешний адрес (или публичный адрес), доступный из общедоступного Интернета В случае с AWS также есть имя, связанное с каждым адресом.
Дело в том, что операционная система, работающая на вашем экземпляре, знает только о внутреннем адресе, потому что это то, что она была настроена для использования при общении с остальной частью сети. Внешний адрес является частью инфраструктуры AWS. Это также то, что вы увидите, если вы находитесь за NAT или работаете в любой аналогичной защищенной сети.
Если у вас есть клиент управления или SQL, работающий за пределами AWS и подключающийся к AWS, вам нужен ваш брокер подключений для объявления внешних адресов. Простейший способ сообщить NuoDB о внешнем адресе с помощью этого свойства:
# An alternate address to use in identifying this host, which is not actually # advertised unless the advertiseAlt property is set. #altAddr =
Так, например, в AWS вы можете установить altAddr = ec2-54-224-104-158.compute-1.amazonaws.com для хоста с внутренним адресом ip-10-245-81-49.ec2.internal. Теперь все процессы, запущенные на этом хосте, будут иметь оба адреса, связанные с ними. По умолчанию они объявляются с использованием внутреннего адреса, но у них также будет внешняя версия в качестве альтернативного адреса. Я рекомендую установить это свойство на любом хосте AWS, с которым вы хотите работать, за пределами региона AWS.
Чтобы увидеть один адрес по сравнению с другим с точки зрения управления или клиента SQL, вам также необходимо установить это:
# A flag specifying whether the alternate address should be advertised instead # of the locally observed network addresses. This is only meaningful for # brokers, because only brokers advertise addresses to clients and admins. #advertiseAlt = false
Этот флаг нужен только для брокера. Брокер объявляет агентов и процессы базы данных с одним адресом и по умолчанию использует адрес, известный ОС. В этом примере это внутренний адрес.
Если вы установите этот флаг в «true», то брокер будет рекламировать альтернативный адрес. В данном случае это внешний адрес AWS. Это позволит вашим внешним клиентам взаимодействовать с вашими внутренними сервисами. Если все или ваше взаимодействие с NuoDB относится к одному региону, вам не нужно это настраивать. Во всех других случаях я настоятельно рекомендую использовать альтернативную адресацию.
Чтобы упростить вашу жизнь, если вы используете наш сценарий формирования облака на изображении на нашей торговой площадке или предоставите его с помощью сценария Python, который входит в комплект поставки, мы настроим для вас альтернативную адресацию. Итак, вы знаете, вы будете все готово из коробки.
Следующие шаги
Используя то, что вы узнали здесь, и предыдущие записи о начале работы с доменами и базами данных, у вас должно быть все необходимое для настройки реального развертывания. Ура!
В ближайшие несколько месяцев мы будем говорить о некоторых захватывающих новых функциях, которые мы добавим в следующий выпуск. Они будут включать обновления модели безопасности и конфигурации, более простой способ работы с базами данных и лучшую интеграцию с такими сервисами, как AWS. А пока мы бы очень хотели, чтобы вы провели тест-драйв для конфигурации с несколькими хостами и рассказали нам, что вы думаете!